- Boost - lists.boost.org

cw9.4 & slist
by Pavol Droba 12 Apr '05

12 Apr '05

Hi all, It seems, that there is a problem in the cw9.4 configuration. BOOST_HAS_SLIST macro is defined, but no <slist> header is present. See: http://tinyurl.com/3rv9h Any idea what to do? Regards, Pavol

4 5

[config] BOOST_GCC
by Gennadiy Rozental 12 Apr '05

12 Apr '05

Why don't we have single BOOST_GCC macro which defines version of gcc compiler. In numerous places around boost we need to check for specific versions on gcc and required to use complex expressions involving up to 3 gcc variables. Gennadiy

4 6

Re: async socket i/o [long]
by Don G 12 Apr '05

12 Apr '05

Hi Caleb, I'll try to address both topics since they are mushed together (as in, I'm not sure they are independent questions after all<g>). > Not sure what you mean here. Connections may be either > synchronous or asynchronous? This seems too limiting IMHO. I meant "the connection process", not the whole object. :) All activities have sync/async forms and I/O methods also have non-blocking. See the sandbox, network.zip/network.html for details. http://boost-sandbox.sourceforge.net/vault > Some of these are semi-portable (e.g. select, poll) but the > others are very specific to the platform. As a user I want > the ability to choose the one that is most suitable to the > task at hand. I'm not sure I understand "suitable to the task at hand". By this do you mean: "I'm writing a simple app that makes a single stream connection" vs. "I'm writing a server that accepts 10,000 connections"? That kind of task? If so, this doesn't sound like an argument for epoll vs. select vs. kqueue. It rather sounds like a desire for the interface to make simple things simple and hard things possible. In other words, why should one care "how" operations are accomplished? It sounds akin to the user selecting Windows API CreateFile flags when opening an ifstream. As soon as we start down this path, the user must code to platform-specific behaviors and interfaces. Exposing such details, IMHO, is a big problem for the user for no benefit that I can see (yet? <g>). I believe that instead of chosing between say epoll and kqueue, the user should chose to block or get callbacks, etc.. I would suggest that for any given platform, there is a best/good_enough choice that would shield the user from these non-portable concerns. If the mechanism seems important, perhaps being involved in the implementation of the interface for a given platform would address these concerns? >From my perspective, understanding network concepts is hard enough for novices. I really believe that we would be best served by a portable, clean abstraction of these primitives that provides synchronous and asynchronous forms of all time consuming operations, and non-blocking I/O. Other concerns, IMHO, are implementation details. Best regards, Don --- Caleb Epstein <caleb.epstein(a)gmail.com> wrote: > On Apr 12, 2005 12:17 AM, Don G <dongryphon(a)yahoo.com> wrote: >> 1. Should the network library provide different choices of >> implementation to the user? For the most part, the platform >> will dictate the available solutions, so having the user >> decide would make their code non-portable. [my thought so >> far is no] > > I disagree. On some platforms, there are multiple choices > for the underlying event dispatching implementation. For > example, on Linux you can use select, poll, or on newer > kernels, epoll and kqueue. > > Even on Windows, there is more than one implementation that > can be used (e.g. WaitForMultipleObjects, select (which I > assume just wraps WFMO), and IO Completion Ports). > > Some of these are semi-portable (e.g. select, poll) but the > others are very specific to the platform. As a user I want > the ability to choose the one that is most suitable to the > task at hand. > >> 2. Would it be better perhaps to only provide behavior >> choices (sync, async, non-blocking) as part of the >> interface? [my thought is yes] > > Not sure what you mean here. Connections may be either > synchronous or asynchronous? This seems too limiting IMHO. > > -- > Caleb Epstein > caleb dot epstein at gmail dot com __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Serializing using RTTI
by tcmichals 12 Apr '05

12 Apr '05

I'm creating a simple file that is serializing several classes to a file. The problem is the order and the number of the of the objects saved in the file, depending on the options the user selects, 1 or 3 classes can be stored, I'm confused on how to call deserializer process for this case? Maybe use the rtti type and then call the correct deserializer? For example: class baseObj { // Code // serialize code }; class optionObj : public baseObj { //Code // Serial // BOOST_SERIALIZATION_BASE_OBJECT_NVP(baseObj); // etc }; class configObj : public baseObj { //Code // Serial // BOOST_SERIALIZATION_BASE_OBJECT_NVP(baseObj); // etc }; saveData( std::string fileInfo) { // code if (userSaveConfig ) os << saveConfig; if (optionSave) os < saveOptions; } getData(std::string fileInfo) { // clueless.. 1. how to determine the order the class has been saved? }

3 3

[Filesystem] Feature Request: One more implementation using .NET
by Pavel Chikulaev 12 Apr '05

12 Apr '05

Dear all, IMO in C++ .NET it's not good idea to use "windows.h"'s plain C functions because someday Microsoft will call them all deprecated or current implementation will not allow make client's code purely managed. .NET implementation of boost::filesystem will make usage of library more safe. Plus, .NET implementaion will possibly work on other platforms than Windows where such classes are available. Actually I don't know any, but I believe Microsoft or somebody else will find a way to do it. So, may be add one more implementation? Sooner or later it should be done. Any thoughts? -- Pavel Chikulaev

6 16

Archive * This() and the most derived class.
by George M. Garner Jr. 12 Apr '05

12 Apr '05

Robert, A comment in interface_oarchive.hpp states that interface_oarchive<Archive>::This() is supposed to return the a pointer to the most derived class. Actually, it gives you a pointer to the "Archive" template parameter which may or may not be the most derived class, depending on how your internal "invoke" plumbing resolves the type. In the following case I was able to get the most derived class only by overriding both operator<<(const T & t) and save_override()(using VC2k3): class fau_xml_woarchive : public boost::archive::xml_woarchive { public: [...] template<class T> void save_override(const ::boost::serialization::nvp<T> & t, int i) { save_start(t.name()); boost::archive::save(*this, t.value()); save_end(t.name()); } template<class T> _Mytype& operator<<(const T & t) { save_override(t, 0); return *this; } [...] }; Was that your intention? Regards, George.

1 1

[mpl] annoying warning for mpl::long_<LONG_MAX>
by Yariv Tal 12 Apr '05

12 Apr '05

On Visual Studio.NET / VC7.1 the following code: #include <boost/mpl/long.hpp> #include <climits> boost::mpl::long_<LONG_MAX> lll; Gives the following warning: ...\boost_1_32_0\boost\mpl\aux_\integral_wrapper.hpp(72) : warning C4307: '+' : integral constant overflow ...\main.cpp(39) : see reference to class template instantiation 'boost::mpl::long_<N>' being compiled with [ N=2147483647 ] . . . (warning goes on and on...) Is this a known issue? When would this lead to errornous program behaviour? (maybe never?) Are there plans to fix it? (i.e. by specializng long<LONG_MAX> to not use the '+') Yariv Tal.

2 1

Problem with xml_woarchive_impl<Archive>::save(const wchar_t * ws)
by George M. Garner Jr. 12 Apr '05

12 Apr '05

Robert, The implementation of xml_woarchive_impl<Archive>::save(const wchar_t * ws) may be found beginning on line 122 of xml_woarchive_impl.ipp. The code serializes the given wide character string twice into the stream, the first time without and the second time with escaping. Compare this with the implementation of save(const std::wstring & ws) a few lines above which correctly serializes the wide character string only once with escaping. Regards, George.

1 0

[ptr_container] post review comments
by Pavel Chikulaev 12 Apr '05

12 Apr '05

Thorsten, 1. Since we can iterate over elements in container using pair of begin end or pair of ptr_begin ptr_end it's not enough to provide member-functions which take only iterators as arguments, we also need overloads which take ptr_iterators. Motivation example: ptr_vector<int> v; //... ptr_vector<int>::iterator i = std::find(v.begin(), v.end(), 5); if (i != v.end()) v.erase(i); //works just fine, but int k = 5; int * pk = &k; ptr_vector<int>::ptr_iterator i = std::find(v.ptr_begin(), v.ptr_end(), pk); if (i != v.ptr_end()) //here we can just write simple erase, we need to write something like that: v.erase(v.begin() + std::distance(v.ptr_begin(), i)); //and it's really no good. I'd like to list all the functions that need to have a twin, but I'd better say shorter - at least every public function that have one or more parameters with type iterator. Differently, ptr_iterators seem to be sick, petty and harmed. We just can't use them anywhere. Another, more simple approach is to provide function that returns iterator of the corresponding ptr_iterator. The funny thing is that we already can get ptr_iterator from iterator, but it's not so needed as the backward transformation. But I do think this is not a good solution, because with this approach we can achive the required functionality, but the syntax will be very very bad. One more approach is to simply get rid of ptr_iterators, but provide user with adapters he will ever need. I like it, but sometimes (or more oftener) I (and you) still simply need ptr_iterators. IMO the best solution is the hardest solution - approach number 1. 2. The next drill is on templated functions and constructors. If we will decide to keep ptr_iterators, consider the following code: ptr_vector<int> v; ptr_vector<int> v2(v.ptr_begin(), v.ptr_end()); IMO user (that was I) expects this compiling. But it's not. Why can't I construct ptr_vector from ptr_iterators? It's good iterators, just any else, but I can, because they need special care to handle them. IMO it's nonsense not to enable such support. The same applies to templated insert, assign, and other functions. So, all of them need an overload for templated ptr_iterators. I think the library should either supply the user of ptr_iterators all he will every need or get rid of them completely. No some more remarks, but they are not so important as the above. 4. IMO header <boost/ptr_container/clone_allocator.hpp> deserves to be higher in folder hierarchy since its' contents can be widely used by other libraries/people. 5. IMO header <boost/ptr_container/exception.hpp> contents doesn't follow good naming scheme. What do other people think when they see boost::bad_index & ? Some class, maybe exception, since it has prefix bad, but how knows that this class comes with ptr_container library? No-one. BTW why don't you use std::out_of_range? At least please change its' name. The same for boost::bad_pointer in the same header file. 6. What a funny name!! boost::ptr_container_ptr_container_detail in <boost/ptr_container/nullable.hpp> Maybe this header also deserves more fame(I mean nullable<T>)? 7. Why don't you throw std::out_of_range exception like std containers when ptr_sequence_adapter::at is out of bounds? Instead, you throw unknown boost::bad_index. 8. It's seems you didn't put contents of detail headers in detail namespace so we have boost::map_config class in <boost/ptr_container/ptr_map_adapter.hpp>. Why don't you put all adapters and their config classes to ptr_container::detail namespace? I don't think anyone will use them. 9. <boost/ptr_container/ptr_predicate.hpp> contents derserve to be documented. And it's better to make ptr versions to all <functional> functions and add these classes: template<typename T, typename U, typename R> class boost::ptr_binary_function : std::binary_funtion<T *, U *, R> {}; template<typename T, typename R> class boost::ptr_unary_function : std::unary_funtion<T *, R> {}; It will simplify your code and IMO it will be useful for users who wants to make their own ptr functions/predicates. 10. indirected1, indirected2 are not good names, don't you think? 11. std::set doesn't have set::at, why does boost::ptr_set have one(even two)? Sorry to dig so deep. P.S. BTW, have you fixed that const_ptr_iterator bug yet? -- Pavel Chikulaev

2 15

Problem with string_algo/range
by Martin 12 Apr '05

12 Apr '05

The updated version of string_algo (using boost.range library) no longer works with VC70. trim_copy_if(std::string(" abc "), is_any_of(" ")); generates the following error: boost\range\detail\begin.hpp(114) : error C2027: use of undefined type 'boost::range_detail::range_begin<T>' with [ T=boost::range_detail::range<const char [2]>::type ] boost\algorithm\string\detail\classification.hpp(68) : see reference to function template instantiation 'boost::range_result_iterator<C>::type boost::begin(C (&))' being compiled with [ C=const char [2] ] boost\algorithm\string\classification.hpp(203) : see reference to function template instantiation 'boost::algorithm::detail::is_any_ofF<CharT>::is_any_ofF (SeqT (&))' being compiled with [ CharT=boost::range_value<C>::type, SeqT=const char [2] ]

2 1