- Boost - lists.boost.org

Re: [boost] But it would Re: [gil] [announcement] New IO lib
by Tom Brinkman 27 Apr '08

27 Apr '08

> Tom Brinkman wrote: >>>> But it would introduce the dependency to boost::filesystem >> >> That would be a show-stopper for shur. I definately could not use >> your IO library if it had a boost::filesystem dependency. PLEASE - >> keep it header only. >> I have no interest in boost::filesystem or gil. Just trying to >> understand your requirement for being header-only: You *want* to compile >> the same code over and over rather than just once? >> >> No, he's probably using a pre-compiled header. :-) No, we generally dont use pre-compiled headers on UNIX. If at all. You must be using dev-studio on windows. The trend is for all "new" libraries to be header only, unless there is an overwhelming, and I mean absolutely overwhelming reason not too. Also, you should not have unecessary dependencies. The filesystem library is not a necessity in this case, and becouse the filesystem library is is not a header only library, it makes using it by other libraries very problematic.

3 8

Re: [boost] Can you please elaborate on what makes a non-header-only library so very Re: But it would Re: [gil] [announcement] New IO lib
by Tom Brinkman 26 Apr '08

26 Apr '08

Sorry about the long subject line. lol. Also, I just took a look at your blog. Nice. I've added it to my bookmarks of blogs that I read. >> Why don't you rebuild your dependent libraries along with your code? >> Then you are guaranteed to have the right stuff. I mean, you already >> said you would like to recompile everything over and over with >> header-only stuff. Might as well make it official. You make a good valid point. It guess it really just comes down to the "hastle" factor. Managing libraries is just a pain. I cant tell you how many times that I've had to track down stupid things related to making sure that all the current libraries are in place for the library to compile. My experience with header only libraries is much more pleasant.

2 1

Can you please elaborate on what makes a non-header-only library so very Re: But it would Re: [gil] [announcement] New IO lib
by Tom Brinkman 26 Apr '08

26 Apr '08

>> Can you please elaborate on what makes a non-header-only library so very >> problematic? Its probably more a UNIX thing, I'm not sure if windows developers could care one way or another. But on LINUX/UNIX, there is a central repository of pre-built libraries that we syncronize our builds against. Uncecessarily adding new libraries makes the process that much more to manage. It is "so" much easier to not have to bother with that and just have the compiler link in any functions that are used at compile time from the headers. You would be surprised to now how much compiler technology has improved in the last 3-4 years. The old reasons for making libraries are no longer always valid. Compilers are very smart and very fast, and thats how I pefer to code.

3 2

"runtime" binding
by Sean Hunt 26 Apr '08

26 Apr '08

While writing code for Init, my new static initialization library, I discovered that I need to be able to dynamically bind a series of parameters (the types are not known by my code - they will be passed through a template function) and store the functor, so as to defer the actual function call (a constructor in this case, so the return type is known). I haven't used Boost.Bind all that often, but I don't think it supports dynamic polymorphism on the return type. A template is not an option in this case, because I can't use argument deduction on class types, and you can't call functions from global scope. If anyone knows a useable substitute that I can use to avoid having to rewrite the binding system, that would be exceptional! Sean Hunt

3 4

[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