- Boost - lists.boost.org

Re: [boost] Re: Re: char[] support in Boost.Range
by brangdon＠cix.compulink.co.uk 20 May '05

20 May '05

In-Reply-To: <d6dhiu$hai$1(a)sea.gmane.org> technews(a)kangaroologic.com (Jonathan Turkanis) wrote (abridged): > > Are we going to generalise it to allow any (compile-time constant) > > terminator? > > Why does the terminator have to be a compile-time constant? I was hesitant about suggesting a generalisation which added run-time overhead over only supporting '\0'. Also, the need is not very common in my experience. -- Dave Harris, Nottingham, UK.

3 4

RE: [boost] Logging Library -- Formal Review Request
by Spencer.Collyer＠barclayscapital.com 19 May '05

19 May '05

> >Thanks!!! > > > >Also, an application should have multiple levels at the same > time (i.e., > >an app may want to have a different level of debug logging per > >component, library, class, whatever). > >_______________________________________________ > > > > > This is an interesting request, and I assume it'll change the way I > implement multiple levels. > > Is this a desireable feature? What do you all think? > > In other words, if I understand correctly, you want to be able to set > the level of each log (independently of other logs). > In this case, instead of enabling/disabling logs, I can > simply set the > level of the logs -- and have a level called DISABLED (which is > equivalent to disabling one log) Just de-lurking for a moment here, but I'd like to add my vote for a form of this. At my work we have a logging library that has concepts of log topics and log levels. These are orthogonal - any particular log message is associated with one topic and has one level, but the messages for a given topic can have any level specified. The topics are arranged in a tree-like hierarchy, and if a minimum logging level is specified for a topic it also affects any subtopics of that topic which have not had a logging level specifically set. This allows us to easily tune the amount of logging information produced so that only the items we are specifically working on get logged at a high debugging level, without interference from components we are not interested in. This makes tracking problems considerably easier, as only the relevant information is output. Just my twopen'orth. S> ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------

2 1

RE: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

> -----Original Message----- > From: Robert Ramey [mailto:ramey@rrsd.com] > Sent: 19 May 2005 16:34 > To: boost(a)lists.boost.org > Subject: [boost] Re: Re: Non-intrusive serialization with VC2003 (7.1) > > Marcin Tustin wrote: > > c:\new_boost\boost\boost\archive\detail\oserializer.hpp(152) : > > > The choice is made here. Yes, and for the moment my understanding of function selection in C++ is not enough to understand why the choice is made. > >>>> namespace boost { > >>>> namespace serialization { > >>>> template<class Archive > > >>>> static void serialize(Archive & ar, const > >>> D2::Message& g, const > >>>> unsigned int version) > >>>> { > >>>> //... > >>>> } > >>>> > >>>> } }; > >>>> > > Note that your serialize template above uses datatype > D2::Message while one is trying to serialize D2::MessagePtr. I've changed the function to use D2::MessagePtr already. The move to D2::MessagePtr (Which is a typedef for Jrs::SmartPtr<D2::Message>) is for other reasons. In any case, the problem still obtains. The new code is: template<class Archive> void serialize(Archive & ar, const Jrs::SmartPtr<D2::Message>& g, const unsigned int version) { //ar & g.stdString(); ar & g.px; // contained pointer ar & g.pn; // reference counter } And yes, I am aware that there is a whole load of extra complexity in correctly serialising smart pointers, and I will deal with that once I can get any non-intrusive serialisation to work. Thanks again for your help and attention.

1 0

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

> -----Original Message----- > From: Jason Earl [mailto:Jason@hybd.net] > Sent: 19 May 2005 16:20 > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Non-intrusive serialization with VC2003 (7.1) > > I'm probably completely wrong, but but am I right in thinking > the problem is due Jrs::SmartPtr<T> and not the fact that > VS.NET or the serialization library is not find the right > serialize method. If so I'm surprised no one else has pointed > this out before! The big deal is that there is a non-intrusive serialize function (i.e. an external function) rather than a method on SmartPtr. The problem is that this function is not being detected, so the template library falls through to trying to use a serialize method, which does not exist. Because I'm building on another library, there is no possibility of going over to any other kind of smart pointer.

1 0

RE: [boost] Logging Library -- Formal Review Request
by Spencer.Collyer＠barclayscapital.com 19 May '05

19 May '05

> > At my work we have a logging library that has concepts of > log topics and > > log levels. These are orthogonal - any particular log message is > > associated with one topic and has one level, but the messages for a > > given topic can have any level specified. The topics are > arranged in a > > tree-like hierarchy, and if a minimum logging level is > specified for a > > topic it also affects any subtopics of that topic which > have not had a > > logging level specifically set. > > I would assume what you call "topic" here, is what I've done by using > loggers/hierarchy. Have you read the docs? John, what we call topics are indeed analogous to your loggers. I have indeed read the docs and found a lot to like in the proposed library, but it does need the ability to specify different levels for different messages on a particular log (IMHO, of course :) ) Spencer ------------------------------------------------------------------------ For more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. ------------------------------------------------------------------------

1 0

RE: [boost] Re: Non-intrusive serialization with VC2003 (7.1)
by Marcin Tustin 19 May '05

19 May '05

I've been looking through the template instantiation trace, and I can't figure out where the choice to use the intrusive mechanism is made. I'll keep looking a little more, and I've appended the trace below: ------ Build started: Project: NewClient, Configuration: Debug Win32 ------ Compiling... EnhancedMessageHandler.cpp c:\D2\API\NewClient\EnhancedMessageHandler.cpp(151) : warning C4244: '=' : conversion from 'uintptr_t' to 'unsigned long', possible loss of data c:\new_boost\boost\boost\serialization\access.hpp(107) : error C2039: 'serialize' : is not a member of 'Jrs::SmartPtr<T>' with [ T=D2::Message ] c:\new_boost\boost\boost\serialization\serialization.hpp(81) : see reference to function template instantiation 'void boost::serialization::access::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\serialization\serialization.hpp(140) : see reference to function template instantiation 'void boost::serialization::serialize<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(152) : see reference to function template instantiation 'void boost::serialization::serialize_adl<Archive,T>(Archive &,T &,const unsigned int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\serialization\extended_type_info_typeid.hpp(71) : while compiling class-template member function 'void boost::archive::detail::oserializer<Archive,T>::save_object_data(boost:: archive::detail::basic_oarchive &,const void *) const' with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(236) : see reference to class template instantiation 'boost::archive::detail::oserializer<Archive,T>' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(235) : while compiling class-template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard: :invoke(Archive &,const Jrs::SmartPtr<D2::Message> &)' with [ Archive=boost::archive::text_oarchive, T=D2::MessageP tr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(294) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>::save_standard ' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(282) : while compiling class-template member function 'void boost::archive::detail::save_non_pointer_type<Archive,T>::invoke(Archive &,const Jrs::SmartPtr<D2::Message> &)' with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\oserializer.hpp(534) : see reference to class template instantiation 'boost::archive::detail::save_non_pointer_type<Archive,T>' being compiled with [ Archive=boost::archive::text_oarchive, T=D2::MessagePtr ] c:\new_boost\boost\boost\archive\basic_text_oarchive.hpp(78) : see reference to function template instantiation 'void boost::archive::save<Archive,T>(Archive &,T &)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\new_boost\boost\boost\archive\detail\interface_oarchive.hpp(89) : see reference to function template instantiation 'void boost::archive::basic_text_oarchive<Archive>::save_override<T>(T &,int)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ] c:\D2\API\NewClient\EnhancedMessageHandler.cpp(115) : see reference to function template instantiation 'Archive &boost::archive::detail::interface_oarchive<Archive>::operator <<<const D2::MessagePtr>(T &)' being compiled with [ Archive=boost::archive::text_oarchive, T=const D2::MessagePtr ]

3 2

[iostreams] example_test and newline_test loop on gcc-3_3-darwin
by Douglas Gregor 19 May '05

19 May '05

The iostreams example_test and newline_test seem to be looping. I've killed them on the OSL tester, but now symmetric_filter_test is currently taking a really long time to run... with the exception of newline_test (which has been failing for a while), all of these tests were passing before yesterday's flurry of iostream modifications. Doug

5 19

Big integer library
by Marcin Kalici�ski 19 May '05

19 May '05

Tracking the disussion on n1774 'Big integer library proposal for C++0x' I see there is a lot of controversy about it, and it will probably need much tweaking before (if ever) it is accepted. Wouldn't that be a good idea to have a big integer added to boost so that we can create a 'working practice' before anything gets standarised? I have some preliminary source code, some spare time, and would volunteer to work on it if there's enough interest. cheers, M.

11 10

[Iterator] advance and distance that understand new iterator concepts?
by Douglas Gregor 19 May '05

19 May '05

Do we have counterparts to std::advance and std::distance that are optimized for random_access_traversal_tag instead of std::random_access_iterator_tag? Doug

2 1

[Wave] Boost Inspection Report
by Hartmut Kaiser 19 May '05

19 May '05

Hi all, the boost inspection report claims that one of the Wave test files contains tabs. And this is correct! But: it needs to contain tabs because it's a testcase... Should I ignore this warning? Or is there a way to tell the inspect program to ignore tabs in this particular file? Regards Hartmut

4 10