- Boost - lists.preview.boost.org

boost/format/format_class.hpp workaround for aC++
by DY, JERRY U (SBCSI) 03 Jun '04

03 Jun '04

Would the experts let me know if there's a better way of accomplishing the same effect below? I have modified boost/format/format_class.hpp and added a line 93 (See attached) && !BOOST_WORKAROUND( __HP_aCC, != 0) <<format_class.hpp>> Thanks! -Jerry

1 0

RE: [boost] [assignment library post review]
by Rozental, Gennadiy 03 Jun '04

03 Jun '04

> The post review version can be downloaded from > > http://tinyurl.com/38c7d Does not work Gennadiy

1 0

RE: [boost] static sized strings
by Reece Dunn 03 Jun '04

03 Jun '04

Martin wrote: >I have tested the sandbox version of the static sized strings. It works >fine >but there are a few inconveniences that I want to point out. I have been writing a series of test cases (boost-sandbox/libs/test) and fixing several bugs. Have you tried these? Also, what compiler(s) are you using? >1. The abstract base class. >--------------------------- >Having an ABC to handle fixed strings of various lengths is a good idea but >it >is not very practical. I understand that the main purpose is to allow fixed >strings to be passed to functions without using templates. > >int countwords(const boost::char_string & str); > >unfortunatly the ABC makes it difficult to pass anything but fixed strings. >If >you want to pass a string literal, a character array or a std::string you >must >create a temporary fixed_string<>. > >countwords(boost::fixed_string<20>("The quick brown fox")); This is an unfortunate side-affect of using the ABC technique that affects John's implementation as well. Your proposed solution looks interesting, but I don't know how practical it will be for the string manipulation operations (w.r.t. buffer safety). Rob proposed a "make_string" function, which would simplify this a little. >2. Substrings >------------- >One of the applications I can see for fixed_string is when you want to >avoid >dynamic allocation but still want to use the std::string interface and >algorithms. In that perspective it seems strange that substr returns a >std::string instead of a fixed_string. This is related to the above problem. You cannot create an instance of boost::char_string, etc. and as such cannot implement substr in the usual way (this is the proplem I was having with operator+). The solution would be to defione an alternate substr function in fixed_string, but this would not solve the problem for boost::char_string, etc. The alternative would be to use a ranged string (pointer to the fixed_string buffer and length), but the problem with this is null-termination. I do not see an easy way around this without removing the ABC design, since it is not possible to do fixed_string< length() > or something similar. >3. resize >--------- >Still missing a method to update the length to reflect the current string >length. I think a resize without arguments would be a good solution. > >boost::fixed_string str<10> >strtime(str.buffer()); >str.resize(); I'll add this soon. I have mainly been focusing on getting documentation and the test cases up. >4. operator[] >------------------------- >I don't have the standard basic_string interface available but I am pretty >sure that operator[] doesn't throw an exception if the argument is outside >max_size(). This is a deviation from the standard. If i > capacity() then the index will be out of the string buffer range and a buffer overrun can occur. This generates an exception to prevent the overrun. I should add this to the docs. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1

Re: [boost] Re: static sized strings
by Reece Dunn 03 Jun '04

03 Jun '04

Rob Stewart wrote: >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > Rob Stewart wrote: > > >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > > > John Nagle wrote: > > [snip] > > I think you misunderstand what I am trying to say. See my comments >below. > >Actually, I think you misunderstood my points. ok. > > [1] You need to specify the size of the buffer. You cannot declare an >object > > of type fixed_string_base (as it is abstract), you can only have >references > > and pointers to it so you can operate on variable-capacity strings. > >Ah, but you missed that I was declaring a fixed_string_base, >where string capacity is not known. I was relying on >make_fixed_string() to deduce the array length and create an >appropriate fixed_string for it. I didn't miss it, just misunderstood what you intended. > > [2] This is the point that we are discussing. Should this line be: > > > > fixed_string< LENGTH > t; > > > > as will work with the current sandbox implementation (my suggestion #2), >or > > should it be: > > > > fixed_string< LENGTH + 1 > t; > >And that's exactly my point. It should be the former as shown by >my equivalencies. > > > Different programmers favour the different semantics, so I ask: why not > > parameterise it, providing a default behaviour. > >I'm not so sure they do and I'm not sure you need to allow for >it. If you do, I suspect you'll encourage off-by-one mistakes. >Granted, those mistakes won't result in overruns, but they will >be annoying. Furthermore that will result in different >fixed_string types; will you provide for conversions among them? >(That is, for example, from a fixed_string that adds one to the >capacity to one that doesn't?) It is the former in the implementation I have, but if you have char data[ 100 ]; // manipulate and use the data buffer in this example, the buffer is 100 characters, but only 99 are writable, with the 100th being a null character (assuming this is a C-style string). Using the current implementation, this would lead to fixed_string< 100 > data; having an extra character. This would transfer to the other model. > > >(I know there is no make_fixed_string() -- yet -- but such a > > >facility would be appropriate.) > > > > Er... the fixed_string constructors! When you declare the object, you >should > > know the size of the buffer you are using, e.g.: > > > > fixed_string< 100 > data; > >The problem is that you don't know the length of the string. >That is, with this code: > > char s[] = "1234"; > >s is a fixed size array of char with five elements. The >programmer didn't have to write: > > char s[5] = "1234"; > >Instead, the compiler figured out the length. > >That's what I'm trying to provide an equivalence for: > > fixed_string_base & s = make_fixed_string("1234"); > >With that approach, the client doesn't need to precompute the >length of the literal and can rely on the compiler (and template >magic) to deduce it and use it to create a fixed_string<5>. > >I've shown returning by value (with the temporary bound to the >reference s), but it could return a smart pointer just as well. Your original example didn't have fixed_string_base as a reference. It should be easy to implement a make_fixed_string function. > > >I think this clearer reveals that fixed_string's size parameter > ^^^^^^^ >That should have been "clearly." > > > >should specify the number of characters. Remember, one can use > > >boost::array to manage a fixed size, non-string buffer. If > > >buffer overrun protection is insufficient in boost::array, that > > >should be fixed (or a new class should be added to Boost). Thus, > > >fixed_string can ignore that usage. I am not disputing this. The question is, is the null terminator counted as a character. For the example you show, it is, but for buffers (see the example above) it isn't. I haven't got a conversion between the two models because I am only implementing the one model at the moment, but conversion would be automatic because the functions that take strings as arguments take fixed_string_base & arguments, so they should be usable regardless, consider: boost::fixed_string< 20 > str1( "This is a long string!" ); boost::fixed_string< 10 > str2; str2.assign( str1 ); This will work (cutting the string short in str2) even though the strings are of different capacities. Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

3 5

A question on serialization library
by Virendra Verma 03 Jun '04

03 Jun '04

If a class has a pointer to an object, how does class know that the pointer was created by library or the class itself before serialization?

1 0

Re:[boost] NEW lib: Named Variable - safe & convenient output of expressions together with their name
by Robert Ramey 03 Jun '04

03 Jun '04

M G wrote: > the "Named Variable Lib" is a lightweight macro & > template library which allows you to write: This looks equivalent to the Name-Value Pair implemented as part of the serialization library already accepted into boost. It not documented separately as other candidates for separate boost components are - maybe it should have been. I don't see this as a problem. The one in the serialization library only has the functionality required to support serialization and I have often expressed the desire that appropriate pieces be moved out of the serialization library and into boost generally - along with the responsibilities of maintenance, documentation, testing, etc. So please look at the serialization library one and see if you can reconcile all of this. Robert Ramey

1 0

Bug, signals, use of default Combiner
by Ville Varis 03 Jun '04

03 Jun '04

Hi, The next piece of code fails with assertion when calling signals without any connections attached to it. <code> #include <boost/signal.hpp> void test_signaling() { ::boost::signal0<int> sig; /* Next call asserts in boost/last_value.hpp line 29 assert(first != last); */ sig(); } </code> This is due to usage of default Combiner boost::last_value<R>. The problem occures when using non-void return values in signals. I use boost version 1.30.0 but I didn't noticed any changes for this in version 1.31.0. Quick workaround is to use other Combiner as default, where this problem is removed. for example <code> ... last_value .... T operator()(InputIterator first, InputIterator last) const { if (first == last) return T(); ... </code> best regards, Ville Varis ville.varis(a)bonum.biz mail.bonum.biz

2 1

[Boost-bugs] [ boost-Support Requests-965747 ] problem with debug builds on Solaris
by SourceForge.net 03 Jun '04

03 Jun '04

Support Requests item #965747, was opened at 2004-06-03 06:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: problem with debug builds on Solaris Initial Comment: When I build an application with -g option (Solaris, Forte compiler), I get undefined symbol errors when it tries to link with Boost. I've tried rebuilding boost with -g, but get undefined sybols at link time from within boost - failing to find symbols in other parts of boost. Without -g option everything is fine Boost version 1.28.0 dlowry_uk(a)yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=965747&group_i… ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

NEW lib: Named Variable - safe & convenient output of expressions together with their name
by M G 03 Jun '04

03 Jun '04

Greetings BOOST developers, the "Named Variable Lib" is a lightweight macro & template library which allows you to write: os << NV(character) << NV(std_string); os << NV(array_char_text) << NV(array_char_null); os << NV(p_float)<< NVP(p_float); p_float = 0; os << NVP(p_float); os << NV(the_answer_over_pi); os << NVB(((p_device==0) || f > 1.2) && name=="rsd0a"); to get e.g. character='A' std_string="test" array_char_text[]="text" array_char_null=NULL p_float=0012FD9C *p_float=1.234 p_float=NULL the_answer_over_pi=13.36901522 (((p_device_name==0) || f > 1.2) && name=="rsd0a")=1 written to the std::ostream os (" << std::endl" in C++ source omitted for better readability). Its main goal is to standardize the 5 macros NV,NVP,NVB,NVM,NVMP to let one output variable/expression together with their names conveniently (just one very short macro per expression) and safely (e.g. prevents os << "x1=" << x2;). Apart from that the NV concept could be used for other applications, where one needs a variable/expression and its name as a string. For more info & download of the library goto http://groups.yahoo.com/group/boost/files/Named%20Variable/ Feel free to try & comment ;-) Markus __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/

1 0

weak_ptr doc problem
by Daniel Wallin 03 Jun '04

03 Jun '04

The weak_ptr docs says this: weak_ptr(); Effects: Constructs an **empty** weak_ptr. Postconditions: use_count() == 0. long use_count() const; Returns: if *this is **empty**, an unspecified nonnegative value; otherwise, the number of shared_ptr objects that share ownership with *this. use_count() seems underspecified and contradicts weak_ptr(). It should return exactly 0 when *this is empty. -- Daniel Wallin

2 1