- Boost - lists.boost.org

Re: [boost] [serialization] documentation for xml archive usage
by Robert Ramey 28 Sep '04

28 Sep '04

>> Oh - no. Use the variable name for the tag not the name of the type. >> This is encouraged by usage of the idiom >> >> ar & BOOST_SERIALIZATION_NVP(my_variable); >Might I also suggest a similar interface which allows the caller to specify >the name to go with the value: >BOOST_SERIALIZATION_NAME_VALUE ("variable", m_variable); The following already exists. make_nvp("variable", m_variable); The above macro was only created to avoid retyping the variable name in the Most common case. Robert Ramey

1 0

[Thread] GCC 2.95/STLPort/Linux static lib failures
by Aleksey Gurtovoy 28 Sep '04

28 Sep '04

Is it the test environment that is at failt here (from http://tinyurl.com/5t5mf) /usr/bin/ld: cannot find -lstlport_gcc_stldebug_static collect2: ld returned 1 exit status set -e LD_LIBRARY_PATH=/usr/local/gcc-2.95.3/stlport-4.5.3/lib:/usr/local/gcc-2.95.3/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH "/usr/local/gcc-2.95.3/bin/g++" -static -g -pthread -pthread -o "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/test_barrier_lib" -L"../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi" -L"../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi" -L"/usr/local/gcc-2.95.3/stlport-4.5.3/lib" -L"/usr/local/gcc-2.95.3/lib" "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/test_barrier.o" "../bin/boost/libs/thread/test/test_barrier_lib.test/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/tss_null.o" "../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_thread-gcc295-mt-sgdp-1_32.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_unit_test_framework.a" "../bin/boost/libs/thread/build/libboost_thread.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_thread-gcc295-mt-sgdp-1_32.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc-2.95.3-stlport-4.5.3-linux/debug/runtime-link-static/threading-multi/libboost_unit_test_framework.a" -lrt -lstlport_gcc_stldebug_static -lrt -Wl,-rpath-link,. ? -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

Re:[boost] [serialization] documentation for xml archive usage
by Robert Ramey 28 Sep '04

28 Sep '04

>However, this triggers a BOOST_STATIC_ASSERT in >basic_xml_oarchive<Archive>::save_override<T>(const T&, BOOST_PFTO int). >The implementation insists that all serialized types be wrapped in a >nvp<T>. That is the intent. >But I couldn't find an >explanation in the docs what special steps a user is supposed to take >if the data shall be serialized into an xml archive. (The only hint >that xml archives need special care that I found was the description >of the header file nvp.hpp libs/serialization/doc/headers.html: "To >associate a name tag with a serializable object. This is necessary to >properly render an xml archive which includes the object name." BTW, >this webpage claims nvp.hpp is in boost/archive, but in fact it is in >boost/serialization.) >Do I need to write > ar & nvp<MyMemberType>("my_member_tag", this->my_member); >in my serialization functions for every variable I want to > (de-)serialize? Can I choose an arbitrary tag for each variable or is >it supposed to be consistent for all variables of a specific type? Oh - no. Use the variable name for the tag not the name of the type. This is encouraged by usage of the idiom ar & BOOST_SERIALIZATION_NVP(my_variable); >Am I correct to assume that the code will still work if I serialize into >a "normal" text archive and the nvp will essentially be ignored? And all other archives as well - with no extra runtime overhead (assuming a decent optimizing compiler) There a section Reference:Class Serialization:Serialization Wrappers:Name-Value pairs where this is described. Perhaps this isn't obvious from contents. >May I suggest that a section explaining the issues with xml archives be >added to the docs before the 1.32 release? Yes you may.

4 3

The Smart Container library
by brangdon＠cix.compulink.co.uk 28 Sep '04

28 Sep '04

In-Reply-To: <1256163046.20040926162826(a)topmail.sk> I'm very dubious about using: vec.begin()->bar(); instead of: (*vec.begin())->bar(); It means that ptr_vector<T> is not syntactically a drop-in replacement for vector<T *> or vector<shared_ptr<T> >. Won't that make it unnecessarily difficult to "upgrade" existing classes, and harder to switch back again should the need arise? Doesn't it also obscure what is going on? It seems a fundamentally wrong notation to me. -- Dave Harris, Nottingham, UK

2 1

repost: [mpl] bad interaction with Boost.Bind
by Joaquín Mª López Muñoz 28 Sep '04

28 Sep '04

Alexsey, do you think something must/can be done to solve this? http://lists.boost.org/MailArchives/boost/msg72210.php I think I cannot commit the patch myself since the affected code is automatically generated by some tools of yours. Otherwise, please tell me so and I'll be happy to proceed. Thanks Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [boost] Re: [review] Formal review of the Smart Container
by brangdon＠cix.compulink.co.uk 28 Sep '04

28 Sep '04

In-Reply-To: <cj6o3i$rgn$1(a)sea.gmane.org> pavel_vozenilek(a)hotmail.com (Pavel Vozenilek) wrote (abridged): > 0. Name of the library should be "Smart Containers" > (note the plural). Also I'm not keen on anything calling itself "smart". It's too vague - smart in what way? Wouldn't "Pointer Container(s)" be better? -- Dave Harris, Nottingham, UK

1 0

Fw: Boost License Permission
by John Maddock 28 Sep '04

28 Sep '04

Another permission received: ----- Original Message ----- From: <SCleary(a)jerviswebb.com> To: <boost-owner(a)lists.boost.org> Sent: Tuesday, September 28, 2004 12:53 PM Subject: Boost License Permission > I, Stephen Cleary, give permission for all my contributions to Boost to be > moved to the Boost Software License Version 1. > > -Steve > > P.S. Sorry for the late reply; I've been on sabbatical. >

1 0

[Optional] Borland failures
by Aleksey Gurtovoy 28 Sep '04

28 Sep '04

Could somebody who cares about Borland take a look/comment of these two: http://tinyurl.com/5uw9x http://tinyurl.com/6jse9 ? Judging from the errors, they seem like a low-hanging fruit. -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

regression problems
by Victor A. Wagner Jr. 28 Sep '04

28 Sep '04

I've had to remove mingw from my regression testing since it's creating .lib files which cause bjam to "except" when running the tests. I can see _what_ the problem is, but not _why_ it is. Here's the call stack (well what appears relevant... the top when the error occurs) bjam.exe!_chvalidator(int c=-128, int mask=8) Line 56 + 0x2a bytes C > bjam.exe!file_archscan(char * archive=0x02fd82c0, void (void *, char *, int, long)* func=0x00412400, void * closure=0x00500458) Line 266 + 0x36 bytes C bjam.exe!timestamp(char * target=0x02fd86e0, long * time=0x0097ab8c) Line 164 + 0x15 bytes C bjam.exe!search(char * target=0x00b3247c, long * time=0x0097ab8c, char * * another_target=0x00000000) Line 130 + 0xd bytes C bjam.exe!bind_explicitly_located_target(void * xtarget=0x0097ab64, void * data=0x00000000) Line 165 + 0x14 bytes C bjam.exe!hashenumerate(hash * hp=0x004ffd08, void (void *, void *)* f=0x0040f9d0, void * data=0x00000000) Line 251 + 0xe bytes C bjam.exe!bind_explicitly_located_targets() Line 176 + 0x12 bytes C bjam.exe!make(int n_targets=1, const char * * targets=0x0012f6bc, int anyhow=0) Line 128 C bjam.exe!main(int argc=0, char * * argv=0x003213c0, char * * arg_environ=0x00321470) Line 434 + 0x15 bytes C Here's a memory dump of the variable "name"...note the two \n\n near the end (just before the FD FD FD FD) and NO trailing '\0' to stop the strlen() 0x02FD9EA8 65 78 65 63 75 74 69 6f 6e 5f 6d 6f 6e 69 74 6f execution_monito 0x02FD9EB8 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 r.obj/.unit_test 0x02FD9EC8 5f 70 61 72 61 6d 65 74 65 72 73 2e 6f 62 6a 2f _parameters.obj/ 0x02FD9ED8 0a 75 6e 69 74 5f 74 65 73 74 5f 6c 6f 67 2e 6f .unit_test_log.o 0x02FD9EE8 62 6a 2f 0a 75 6e 69 74 5f 74 65 73 74 5f 6d 6f bj/.unit_test_mo 0x02FD9EF8 6e 69 74 6f 72 2e 6f 62 6a 2f 0a 75 6e 69 74 5f nitor.obj/.unit_ 0x02FD9F08 74 65 73 74 5f 72 65 73 75 6c 74 2e 6f 62 6a 2f test_result.obj/ 0x02FD9F18 0a 75 6e 69 74 5f 74 65 73 74 5f 73 75 69 74 65 .unit_test_suite 0x02FD9F28 2e 6f 62 6a 2f 0a 73 75 70 70 6c 69 65 64 5f 6c .obj/.supplied_l 0x02FD9F38 6f 67 5f 66 6f 72 6d 61 74 74 65 72 73 2e 6f 62 og_formatters.ob 0x02FD9F48 6a 2f 0a 0a fd fd fd fd 80 00 1a 00 dd 00 dd 06 j/..ýýýý...Ý.Ý. 0x02FD9F58 d8 f6 fd 02 78 01 32 00 dd dd dd dd dd dd dd dd Øöý.x.2.ÝÝÝÝÝÝÝÝ Further debug information available upon request. It would be nice to get the mingw tests back in my testing...this system has a fair chunk of free time right now. Oh, as for the white space in the report? I have NO idea were to even start looking. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

3 6

GUI Windowing Framework in C++
by Reece Dunn 28 Sep '04

28 Sep '04

A windowing framework should abstract the windowing facilities of a particular platform. Here are my list of requirements for this type of framework: [1] Support constructor-based window creation, e.g.: frame.add( new gui::button( "Boost!" )); The justification for this is that I find using an OnCreate + Create style for creating windows (MFC and WTL) or similar is too complex: the above method for creating a component is 1 line compared to many lines in other frameworks. For the record, I have a basic version of the above implemented in Windows where the add function changes the parent of the child component. This would make it easy to implement advanced GUI like docking controls. [2] Support for lightweight components: components that do not use native window handles. This will allow for advanced facilities like layout managers. The infrastructure should be such that using native and lightweight components is transparent. Component positioning should be allowed to be set explicitly (absolute position - using the units library?) or set using layout managers. There should be wrapping, clipping and stretching position schemes for the various layout managers. [3] The event manager should be platform independent, flexible and extensible. That is to say, if you are using Windows, you should be able to register a handler for a Windows-specific message. In general, the library should match system messages to an independent version wherever possible. It should also support message reflection where a message for a component is handled by a different window or object (e.g. responding to a close message on an application object). When an event is handled, the handler should inform the manager how to process the event: (1) the event has been handled (e.g. focus events); (2) the event was not handled - try the next handler; (3) the event was handled, but processing should continue (e.g. draw events) There has been discussions in earlier threads (Java style GUI in C++) about using boost::signal as an event handler. I have two questions regarding this: (1) if I have n message types, do I need n boost::signal objects? If so, this would increase the size of each component. Also, what if you want a "handle all events" handler. (2) if generic events are defined in an 'event' object, and a handler function has the form: event_handled_type eventfn( const event & e ); what if you want to support: event_handled_type pressed( const mouse_event & me ); event_handled_type key_down( const key_event & ke ); Regards, Reece

6 13