- Boost - lists.boost.org

[smart_ptr] refactored enable_shared_from_this
by Daniel Frey 26 Apr '08

26 Apr '08

I refactored enable_shared_from_this in order to remove the _owner flag. To test it, you need a small and straight-forward addition to detail::weak_count: It needs .empty(), similar to detail::shared_count. The attached version also hides all internal stuff from the public interface, using 'friend' - maybe some compiler would need a workaround for that. If someone objects to this (maybe because it might cause trouble with some compilers) I could leave this part out or fix it later where it breaks. The good thing of this is, that we no longer need _internal_-prefixes. OK to commit? Regards, Daniel

3 17

[serialization] Building failure
by Andrey Semashev 26 Apr '08

26 Apr '08

Hi, For quite a long time updating to boost trunk makes Boost.Serialization not able to build. I've seen the conversation between Peter and Robert about this failure but it seems there was no final resolution reached. Right now I solve the problem by removing dependencies on Boost.Config from Boost.Serialization Jamfile every time I update to trunk. Is there something I should do on my local machine to make the library build without doing so or the issue should be solved in the repository (either by fixing the Jamfile or some another way)? I've attached the bjam output. The configuration is gcc 4.2.1 on SUSE Linux, if that matters. warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. lib.jam: No such file or directory libs/config/test/Jamfile.v2:41: in modules.load rule compile-fail unknown in module Jamfile</home/lastique/src/boost/trunk/libs/config/test>. /home/lastique/src/boost/trunk/tools/build/v2/build/project.jam:307: in load-jamfile /home/lastique/src/boost/trunk/tools/build/v2/build/project.jam:63: in load /home/lastique/src/boost/trunk/tools/build/v2/build/project.jam:116: in load-parent /home/lastique/src/boost/trunk/tools/build/v2/build/project.jam:443: in initialize /home/lastique/src/boost/trunk/tools/build/v2/build/project.jam:297: in load-jamfile /home/lastique/src/boost/trunk/tools/build/v2/build/project.jam:63: in load /home/lastique/src/boost/trunk/tools/build/v2/build/project.jam:167: in project.find /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:354: in find-really /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:408: in object(project-target)(a)221.find /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:827: in resolve-reference /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:843: in targets.generate-from-reference /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:1129: in generate-dependencies /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:1176: in object(typed-target)(a)226.generate /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:742: in generate-really /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:715: in object(main-target)(a)898.generate /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:254: in object(project-target)(a)221.generate /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:858: in targets.generate-from-reference /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:1129: in generate-dependencies /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:1179: in object(install-target-class)(a)94.generate /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:742: in generate-really /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:715: in object(main-target)(a)331.generate /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:858: in targets.generate-from-reference /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:1129: in generate-dependencies /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:1179: in object(alias-target-class)(a)100.generate /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:742: in generate-really /home/lastique/src/boost/trunk/tools/build/v2/build/targets.jam:715: in object(main-target)(a)335.generate /home/lastique/src/boost/trunk/tools/build/v2/build-system.jam:663: in load /home/lastique/src/boost/trunk/tools/build/v2/kernel/modules.jam:267: in import /home/lastique/src/boost/trunk/tools/build/v2/kernel/bootstrap.jam:134: in boost-build /home/lastique/src/boost/trunk/boost-build.jam:11: in module scope

2 2

Summer of Code 2008 Ideas
by Mikael Olenfalk 26 Apr '08

26 Apr '08

Hi everybody! I saw that you are starting to think about SoC 08 and I have a couple of ideas: I cannot vouch for the usefulness of any of these proposals :) 1. Boost.Asio 1. add support for SCTP (Stream Control Transmission Protocol) besides TCP and UDP - more information on SCTP can be found on http://www.sctp.org/rfcs.html - I have not yet used SCTP anywhere so I cannot actually judge its importance, the *NIXes seem to support SCTP for some time now, I am unsure about Windows but it looks like Vista and Server 2008 do support SCTP - All *NIXes use the SCTP socket api - I do not know what the API on windows for SCTP looks like 1. add support for BEEP on top of TCP - BEEP is an "application protocol framework", basically it is just a set of guidelines packaged for application protocol design, which solves common problems one faces when designing new application protocols - http://beepcore.org/doc.html contains more information - http://beepcore.org/beep-toolkits.html lists current toolkits for BEEP 2. Boost.Serialization 1. add archive types for ASN.1 encoding rules, e.g. BER, DER, EDER, XER, etc. to be used together with Boost.Asio or perhaps even Boost.Asio.Beep (not that beep forces you to use any specific encoding) 2. Wikipedia has links and information: 1. http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_One 2. http://en.wikipedia.org/wiki/Basic_Encoding_Rules 3. http://en.wikipedia.org/wiki/Canonical_Encoding_Rules 4. http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules 5. http://en.wikipedia.org/wiki/XML_Encoding_Rules 6. http://en.wikipedia.org/wiki/Packed_Encoding_Rules 7. http://en.wikipedia.org/wiki/Generic_String_Encoding_Rules 3. Boost.Asn1 (for lack of better name) 1. Boost.Spirit-like DSEL for embedding ASN.1 notation directly in C++; then you could "easily" implement ASN.1 based protocols without the need for code generation outside of your C++ compiler 2. see http://en.wikipedia.org/wiki/Abstract_Syntax_Notation_Onefor more information on ASN.1 3. This might overlap with proposal 2 for Boost.Serialization 4. Finish Boost.Process (I think that it was a SoC 2007 or 2006 project) With kind regards, Mikael Olenfalk

16 25

[smart_ptr] documentation
by Daniel Frey 26 Apr '08

26 Apr '08

Peter, shall I write a patch for the documentation for get_shared_count() and the new ctors? Or would you like to take care of that? Frank, is there any documentation for the improved enable_shared_from_this in trunk? It's hard to think about removing _owner with no documentation of what the expected behaviour is and what features/use-cases need to be supported. Regards, Daniel

3 6

circular_buffer iterator start/stop positions
by David Tapia 26 Apr '08

26 Apr '08

I've started using the circular_buffer container and I am a little confused by its behavior with regard to start and stop positions for iterators. As implemented, the iterator::begin() call always returns the fixed position at element 0 and the iterator::end() call always returns the fixed position past the last element of the circular_buffer. A more intuitive approach might appear to be that the iterator::begin() should return the oldest element in the buffer and iterator::end should return the newest (most recently pushed) element. Thus, in the case where the circular_buffer were NOT full, begin() would return the position at element 0. After the circular buffer became full, begin() should return the position of the next insertion point, again the oldest element in the buffer. When I think of the context of a circular buffer, it seems that absolute positions (element 1, 2, 3, and so on) have little meaning. Under this behavior, existing iterators would then be invalidated whenever a new element is pushed into the buffer, as is the case for other STL containers. No confusing hard/soft invalidation of iterators that exists now. David

2 1

Policy about release branch?
by Roland Schwarz 26 Apr '08

26 Apr '08

Despite lot of discussions I lost track what the agreed release branch policy is. I just checked in a change to Jamroot file which should go to 1.35.1. Who is in charge of doing this? Is there a summary page where this is written down? I just was not able to find it. If there is one, please someone point me at. Thank you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

1 0

[mirror] a question
by Matus Chochlik 26 Apr '08

26 Apr '08

Hi, I would also like to hear your opinions on one thing, concerning the implementation of mirror. Mirror currently uses several typedefined types like bchar (char/wchar_t) bstring (string/wstring) and global variables like bcin (cin/wcin), bcout (cout/wcout), etc. Which form is used, depends on the definition of the PP symbol BOOST_USE_WIDE_CHARS. If this symbol is defined then wchar_t/wstring/wcout/... are used otherwise char/string/cout/.. are used. I use this approach because I know from my experience that it can save a great deal of trouble when switching from chars to wchars and vice versa, mainly on Windows where a similar approach is used by the WinAPI. Since bchar is always the same type as the TCHAR type defined by WinAPI, you can use the 'recomended versions' of the winapi functions, like LoadLibrary with bchar vs. the char-type-specific versions like LoadLibraryA with ascii chars and LoadLibraryW with wchars. When testing the library and the examples I always compile them with both chars and wchar_ts to check whether everthing works as expected. BUT, currently all the types and global variables like bchar, bstring, bcout, bcin, etc. are defined in the scope of the boost namespace and all the preprocessor symbols have only the BOOST_ prefix. The sources related to this char type switching are placed in a separate directory called [boost/]char_type_switch/ . I am aware that boost library authors, maintainers and users could object against this. So I would like to ask: Does this approach sound reasonable to You and is it Ok for You that the symbols are defined in the boost namespace and the files placed in a separate folder ? Would You even like to use this or similar approach in Your library ? Or, is it NOT OK and do You want me to place them into the mirror namespace and prefix all the preprocessor symbols with BOOST_MIRROR_ ? I would like to have this issue resolved ASAP in order to avoid to have rewrite everything in case this library is officialy proposed in the (distant) future and there are objections against this. Thanks in advance for your opinions. -- matus

1 0

[mirror] new version
by Matus Chochlik 26 Apr '08

26 Apr '08

Hello, I would like to announce that a new version of 'mirror' library is available in the sandbox, at http://svn.boost.org/svn/boost/sandbox/mirror/ with several new features, including: - full_name() getter (returns the type or namespace name with nested name specifier), which works even for types like pointers etc. - meta-type for std::pair<> (a meta-class allowing to inspect the attributes will be comming soon) // this means that you can now define a type T like this: using namespace ::std; using namespace ::boost; using namespace ::boost::mirror; // typedef pair<const int*, double [321]> T1; typedef pair<float, const long&> T2; typedef pair<T1 const volatile, T2 volatile const> T3; typedef pair<T2, T1 volatile> T4; typedef pair<T3 const * volatile, const T4&> T; // get the meta data typedef BOOST_MIRROR_REFLECT_TYPE(T) meta_T; // and query the base name (without nested type specifiers) cout << meta_T::base_name(); /** printing out (newlines added): * pair< pair< pair< int const *, double [321] > const volatile, pair< float, long const & > const volatile > const * volatile, pair< pair< float, long const & >, pair< int const *, double [321] > volatile > const & > */ // or the full name cout << meta_T::full_name(); /** printing out (newlines added): * ::std::pair< ::std::pair< ::std::pair< int const *, double [321] > const volatile, ::std::pair< float, long const & > const volatile > const * volatile, ::std::pair< ::std::pair< float, long const & >, ::std::pair < int const *, double [321] > volatile > const & > */ Please see http://svn.boost.org/svn/boost/sandbox/mirror/libs/examples/special/std_pai… for a complete example. Since it has been tested only with MSVC++ 2008 there may be some problems compiling the samples with other compilers (mainly missing typename keywords here and there). Next week I'm going to fix this. There are still no jamfiles nor makefiles so you'll have to write some yourselves if you want to try the examples. Sorry, I hope this'll be fixed soon, too. Some of the other examples have been updated to show the using of the full_name() function. See http://svn.boost.org/svn/boost/sandbox/mirror/libs/examples/registering/ For those interested, there is also an example, showing how to use mirror with Boost.Serialization at: http://svn.boost.org/svn/boost/sandbox/mirror/libs/examples/serialization/c… It is rather clumsy and currently it can't be compiled with gcc (I couldn't find the reason why yet). Note that it's just a first shot and most of the code ensuring the cooperation with Boost.Serialization will be rewritten and hidden in a header file in the future. Best, -- matus

1 0

What plans to handle _SCEURE_SCL in the boost build system?
by James Talbut 25 Apr '08

25 Apr '08

Hi, There have been various discussions on here about the problems caused by _SECURE_SCL, but I haven't seen any concrete plans for changes to boost build to handle it. At a minimum the build system should be changed to enable those users wanting _SECURE_SCL=0 to do so easily - ideally by providing an argument to bjam. Is someone working on this? Thanks. Jim P Consider the environment. Please don't print this email. ________________________________________________________________________ This e-mail, and any attachment, is confidential. If you have received it in error, do not use or disclose the information in any way, notify me immediately, and please delete it from your system. ________________________________________________________________________

5 6

[gil] [announcement] New IO lib
by Christian Henning 25 Apr '08

25 Apr '08

John, > > I really think that all of the other formats are important. Hopefully > Lubomir does make them an official part of gil, or an official extension > that can be part of the boost svn. I'll discuss it with Lubomir. I rather believe that we should divide gil into seperate modules. One for the core part, meaning the infrastructure code without specific code for color spaces, etc. And then, there should be extensions for all the color spaces, io, image variants, algorithms, etc. Also, gil might consider having it's own review procedure. This might fasten up inclusion of new extensions and also takes burden away from boost. After all the extensions are gil-specific and don't impact boost very much. What do you think? > > > > Can you try to compile again? > > I fixed some parts, but it still fails. > > g++ is really picky about dependant names. When a base class is > dependant on a template parameter, I think you need to use 'this->' in > order to let the compiler know that the symbol comes from a base class > instead of the global scope. I attached a patch, which was created > inside the io_new folder. I'll change the code, asap. > > Also, there are references to deail::read_and_no_convert used in > read_image.hpp. I can not find a declaration for read_and_no_convert, > did you forget to add a file to svn? read_and _no_convert is defined in conversion_policies.hpp. > > > > Are you planning on using the lib? > > I will probably use the library, but I am not ready to switch yet > (timing issues). > Is it possible to have read_image deduce the file format from the file / > filename itself? That feature would make a gil io lib. perfect for me. I was thinking of adding that, as well. But it would introduce the dependency to boost::filesystem. Not sure if that's advisable since the io lib wouldn't be header only anymore. Thanks for your effort, Christian

2 1