- Boost - lists.boost.org

[c++-sig] A question regarding arguments bindings
by Sandeep Gupta 13 Nov '08

13 Nov '08

Hi, My question is regarding the default behavior of the compiler when there is mismatch in the argument type between binding declaration and function declaration. By default no warning is generated. Consider following example: class A{ public: A(const B&); }; In wrapper, if by mistake (which I made in my code), i write class_<A>("A", init<B>) ; The compiler does not complain about no constructor found. Instead for reasons, beyond my understanding of boost.python, B get passed by value. My question why doesn't compiler issue at least a warning. Needless to say i am new to boost.python. My apologies if this is something trivial or well known. Thanks sandeep

2 2

[flyweight] key value with objects not constructible from a key
by Michael Marcin 13 Nov '08

13 Nov '08

The flyweight factory concept seems to be missing a key part of the GoF Flyweight pattern's FlyweightFactory participant. The GoF factory supplies the flyweight if one exists. This is what the current boost flyweight Factory concept does. If no flyweight exists the GoF flyweight factory creates one. In the boost flyweight library this functionality is somewhere else that doesn't seem to be described in the documentation. The name factory for what is currently in place is misleading. Isn't it really just an associative container? I'm trying to use flyweight to represent texture objects right now. These are surely a good candidate for use with flyweight as they are one of the examples given. My textures are fairly simple objects, with low coupling. Creating a texture is however expensive and has a lot of dependencies (libjpeg,libpng,etc). I typically have a TextureFactory which decouples the construction of a texture from the actual texture object and allows the work required to setup the various libraries to read images to be reused by all textures constructed from the same TextureFactory instance. It doesn't seem possible to have this decoupling with flyweight. Am I missing something? -- Michael Marcin

5 20

[Chrono] Boost.Chrono added to sandbox
by Beman Dawes 13 Nov '08

13 Nov '08

Work-in-progress for the Boost.Chrono library has been added to the sandbox. See http://svn.boost.org/svn/boost/sandbox/chrono This work is in a very preliminary state. The only testing has been with VC++ 9.0 on XP-64 and a tiny bit on Ubuntu 8.04 Linux. There has been no work done yet on C++0x headers. The Jamfiles are there, but haven't been tested; I've been developing using the provided VC++ solution. The implementation of the clocks is going to be very system specific. If anyone would like to try .../libs/chrono/example/await_keystroke.cpp and report whether or not it compiles and works on their system, it would be appreciated. Patches to make .../libs/chrono/src/chrono.cpp work for various operating systems would be even more appreciated! I'm still unsure about even some of the basics, such as how to partition the three parts for boost. Are the time utilities, the compile-time rational arithmetic, and the type trait common_type three boost libraries, one boost library, or three parts of a larger boost library? There was some discussion of this in a prior thread, but I thought having the actual code available might move the discussion forward. There is a tiny bit of documentation; see .../libs/chrono/doc/index.html. Comments welcome! --Beman

4 6

[TR1] Sun problems (again)
by Ling Li 13 Nov '08

13 Nov '08

(The related thread is http://lists.boost.org/Archives/boost/2006/08/109450.php) Sun CC seems to have #include guards automatically for standard headers like <memory>. This somehow causes problems to Boost::TR1. Here is a simple example (call it sun-test.cpp) that doesn't compile with Sun's compiler: #include <string> #include <memory> void f() { std::tr1::shared_ptr<int> p(new int()); } The command line is: CC -c -library=stlport4 -I<BOOST_TOP>/boost/tr1/tr1/sun -I<BOOST_TOP>/boost/tr1/tr1 -I<BOOST_TOP> sun-test.cpp And the error msgs: "sun-test.cpp", line 5: Error: tr1 is not a member of std. "sun-test.cpp", line 5: Error: shared_ptr is not defined. "sun-test.cpp", line 5: Error: Badly formed expression. The reason is that the 2nd include, "#include <memory>," is not honored since Sun's <string> (included from Boost::TR1's string) somehow loads <memory> inside it. Although the <memory> header it loads is the Boost::TR1 version, Boost is smart enough not to include the TR1 extension part. That is actually the correct thing to do, and other compilers (VS and GCC) will get the TR1 extension via the 2nd include. But for Sun's CC, since the 2nd include is not honored, std::tr1 is missing. Sun CC doesn't do that auto #include guards for user headers. I am wondering if there is a way to turn off that auto guards for Sun CC (I haven't found a way yet). Or is there some way to change Boost::TR1 to accommodate this special behavior?

3 6

Re: [boost] llvm anyone?
by Giovanni Piero Deretta 13 Nov '08

13 Nov '08

On Wed, Nov 12, 2008 at 4:34 PM, Marshall Clow <marshall(a)idio.com> wrote: > At 10:29 AM -0500 11/12/08, Neal Becker wrote: >> >> Anyone testing on llvm compiler? (I'm trying it now on linux F9 x86_64 >> llvm-2.4) > > I believe that the llvm support for C++ is best described as "currently > quite limited". > I expect this to change over the next year or so, though. The clang front end is certainly only in an experimental stage, but LLVM also support the gcc front end (LLVM-gcc) which means that its C++ support should be about as good as native GCC. As the backend is quite different and there might be some small differences in the front end, it might still make sense to test on it. -- gpd

6 5

[OT] Contact with Jeff Garland
by Robert Kawulak 13 Nov '08

13 Nov '08

Hi Jeff, I was not able to contact you via e-mail -- could you please write to me how can I reach you? Best regards, Robert

1 0

[spirit] Where is SPIRIT_VERSION?
by Robert Ramey 12 Nov '08

12 Nov '08

In the new headers for spirit - I only find SPIRIT_VERSION in some "classic" file. Basically I would like to compile something conditionally on SPIRIT_VERSION. Another point: Wouldn't it have made a lot more sense just to make a new directory and namespace "spirit2" and avoid the the convolution that occurs now and the associated warning. The warning doesn't work for all compilers. Robert Ramey

2 3

Compiling program_options v1.35 on msvc9.0 fix
by Okko Willeboordse 12 Nov '08

12 Nov '08

Hi All, My co-worker Evert van de Waal noticed the following; I have had some problems compiling program_options v1.35 on visual C++ 9.0 (2008) Express. It seems that this compiler does not correctly export some global variables when compiling to DLL, leading to unresolved dependencies. I have had to make a few changes: In file *options_description.hpp*, line 158: Replaced static const unsigned m_default_line_length; with BOOST_STATIC_CONSTANT (unsigned, m_default_line_length = 80); This is an old fix that I found in the mail archives (2005), seems to have been erroneously dropped from the base-line. In file *options_description.cpp*: removed the declaration of m_default_line_length. In file *value_semantic.cpp*: a singleton variable was defined but not properly linked by vc9.0. I changed the implementation to (line 17) BOOST_PROGRAM_OPTIONS_DECL string& arg() { static string* str=0; if (!str) { str = new string; *str = "arg"; } return *str; } >From line 79 (after making the change above), I changed the only use of arg to: std::string untyped_value::name() const { return arg(); } In file *details/value_semantic.hpp*: I changed the declaration of the variable arg to (line 13): BOOST_PROGRAM_OPTIONS_DECL std::string& arg(); After these changes, program_options links properly, and I was able to run the demo code. Please note that also the pre-compiled version of boost 1.35 for the vc9.0 compiler from http://www.boost-consulting.com/download/windows suffers from these problems: the program_options DLL is unlinkable due to unresolved references to m_default_line_length and arg. Cheerio, Evert van de Waal

1 0

Silent change in boost 1.36 alignment_of<> template with gcc 4.3
by Jon Biggar 12 Nov '08

12 Nov '08

In boost 1.36, boost::alignment_of<> was changed to use the builtin __alignof__() if gcc version was 4.3 or greater rather than using calculating alignement using: template <typename T> struct alignment_of_hack { char c; T t; alignment_of_hack(); }; Unfortunately, this broke some code I had written that did structure introspection, because gcc's __alignof__() returns 8 for double on the x86 architecture, but actually only aligns doubles on 4 byte boundaries inside structures. What do people think about adding a struct_alignment_of<> template that uses the old logic to compute alignment inside a struct? -- Jon Biggar jon(a)floorboard.com jon(a)biggar.org jonbiggar(a)gmail.com

6 12

[serialization] non-tracking wrapper?
by David Abrahams 12 Nov '08

12 Nov '08

I'm wondering if it's even possible to create a wrapper that turns off tracking for the type it wraps. Is tracking "scoped" so that subobjects of non-tracked types are also not tracked? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 6