- Boost - lists.boost.org

[static_assert] Bad compiler message
by Vladimir Prus 25 Apr '04

25 Apr '04

Hello, I've just found out that the following program: #include <boost/static_assert.hpp> int main() { BOOST_STATIC_ASSERT(false); return 0; } compiled with gcc 3.3 produces: sa.cpp:6: error: invalid application of `sizeof' to an incomplete type which is not as nice as sa.cpp:6: `sizeof' applied to incomplete type `boost::STATIC_ASSERTION_FAILURE<false>' that gcc 2.95 generates and sa.cpp:6: `sizeof' applied to incomplete type ` boost::STATIC_ASSERTION_FAILURE<false>' That 3.2 generates. The behaviour of 3.4 is the same as for 3.3. So, there are some questions: 1. Should I bug gcc developers about this? 2. Anybody knows another way to force better diagnostic? 3. Is it possible to make regression tests for static_assert always include compiler messages, so that we know the diagnostic is OK? - Volodya

6 7

Re: [boost] [serialization+date_time] Serialization Review: serialization of dates
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Jeff Garland <jeff(a)crystalclearsoftware.com> Fecha: Domingo, Abril 25, 2004 0:37 am Asunto: [boost] [serialization+date_time] Serialization Review: serialization of dates > All - > > Since I'm the review manager I'm not doing a formal review of the > library, but > I thought I'd share some code and a few thoughts. If > serialization is > accepted users people will ask me and other library authors to provide > serialization support for some of the types in their libraries. So > to get a > feel for the difficulty of extending serialization for new types I > wrote the > serialization code for gregorian::date and some example code to > try it out. Regarding the need to include "greg_serialize.hpp", I think a better approach, from the point of view of the user, is that serialization support is already embedded into "boost/date_time/gregorian/gregorian_types.hpp" and automatically provided if one of the archive headers are included by the user program: // case 1 "boost/date_time/gregorian/gregorian.hpp" int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // does not work, text_oarchive not defined. oa << d; } // case 2 "boost/date_time/gregorian/gregorian.hpp" #include <boost/archive/text_oarchive.hpp> int main() { date d(2004,Apr,25); boost::archive::text_oarchive oa(ofs); // OK, no need to include anything else fromd date-time oa << d; } See what I mean? For this to work with minimum overhead, we'd need some forward headers for serialize, save, load, etc. to be included by "boost/date_time/gregorian/gregorian.hpp". I'm not sure whether this forward headers are already provided by Robert's library. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

Re:Re: [boost] [serialization+date_time] Serialization Review:serialization of dates
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: >Well, I think it belongs in the library supplying the data type not in > serialization. Few reasons for this... ... good reasons listed 4) Many serialization implementations will turn out to be trivial. An example is Thorsten O? pointer container wrapper class which resulted in 6 lines of code. Furthermore these six lines were inline template member functions (two functions 3 lines each) which required no header inclusion at all. In cases such as this, the compiler/runtime cost is zero if the application doesn't use serialization. I believe that this will be a common case for many of the "utility" classes. FWIW - this gets my vote: > So for the particular case I posted I was planning on putting this code in > boost/date_time/gregorian/greg_serialize.hpp > Time could would go into > boost/date_time/posix_time/time_serialize.hpp Considering the above, you might want to think about tweaking date time. By making a default constructor (that initializes as "not a date"), you could implement serialization as template member functions along the lines of the above. In this way adding serialization would: a) no extra compile time overhead b) no extra run-time overhead c) no extra file inclusion d) no extra "conceptual" overhead. That is one would never have to even think about it - it would always be there just lurking waiting to be of service. It would just work when used. Robert Ramey

3 3

Re:Re:Re: [boost] [serialization+date_time] Serialization
by Robert Ramey 25 Apr '04

25 Apr '04

Jeff Garland wrote: > > a) no extra compile time overhead > > b) no extra run-time overhead > > c) no extra file inclusion > > d) no extra "conceptual" overhead. That is one would never have to even > > think about it - it would always be there just lurking waiting to be > > of service. It would just work when used. > > Are you saying there is actually extra runtime overhead with the way I've > implemented serialization? If so, that needs to be in the docs b/c I was > under the impression that external versus internal implementations would > be > the same... > I didn't mean to imply your method had any runtime overhead - I was just restating all the features. However, the other points are real advantages of just putting it in with the class definition. BTW the non - intrusive version could also be put in the normal class header. However if its too complicated it might end up requiring more file inclusion so it would have to be considered on a case by case basis. I personally don't have a strong position on this. As far as serialization is concerned the alternatives are all equivalent. The decision where to but the serialization templates can be decided on other factors. Robert Ramey

2 1

New dynamic_bitset
by Gennaro Prota 25 Apr '04

25 Apr '04

Hi everybody, as I have mentioned in some post here, a new version of dynamic_bitset is in the sandbox. I've finished everything 4/5 days ago (including new and more tests) and thought to move it to the main repository, as Jeremy asked too. But I've had an important familiar problem and I'm looking for a job and an apartment at the same time. With all likelihood I'll be at my old home, where is my pc, just for a couple of hours on Saturday and Sunday (except for this weekend, where Monday is holidays too). There could be other free mornings here and there but I can't guarantee. So I ask: should I move everything to the main repository or should I wait until I can devote more time to follow discussions and fix possible regressions? If the next release is far away then 5 or 6 hours a week should be adequate to review the regression logs and fix any problems that could arise. I'll check the list again tomorrow. Sorry for the inconvenience. PS: I had a (very) quick look at the thread about the FC++ review result. Just want to say that I think Brian is a great asset to the C++ community at large. His only mistake is that he isn't posting anymore to the groups, if not sporadically. Please, come back soon, Brian :) Genny.

6 23

Re: [boost] [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

----- Mensaje original ----- De: Brian McNamara <lorgon(a)cc.gatech.edu> Fecha: Domingo, Abril 25, 2004 6:05 am Asunto: Re: [boost] [multi_index] composite keys: request for advice > On Sun, Apr 25, 2004 at 03:54:31AM +0200, JOAQUIN LOPEZ MU?Z wrote: > > > that if you call these two object "k" and "t" (key and tuple), > > > then you should have > > > k < t false > > > t < k false > > > t == k does not compile > > > That's just my quick hunch based on what I've quoted above; I > haven't> > considered what consequences it has for the library, > but that's my > > > intuitive notion of how tuples as "partial keys" ought to work. > > > > I guess I agree with you, but I wanted to bring this > > in to the list to gather some opinions. Following your > > approach, what should we do with > > > > k <= t > > t <= k > > > > The options are: > > > > a. they hold true > > b. they do not compile > > > > I don't have any strong argument in favor of any option. > > If there are other std:: or boost:: types which model the > StrictWeakOrdering concept (without having total orders), I would see > what they do and follow their lead. > > If not, I would make the "<=" operators not compile, since > k <= t > can always be rewritten by clients as > !(t < k) > and the narrower interface reduces the likelihood of someone > mistakenlygetting the impression that there's a total ordering > here (IMO). > I've scanned Boost and results are not conclusive. At least one class (shared_ptr) does define operator< and does not define <=, >= etc. so I'm not alone. I think I'll follow your advice and be conservative here (we'll always have time to extend this; the other way around is more problematic). So, the rules I'll stick with are: 1. if k and t have the same number of elements then k==t, k!=t, k<t, k>t, k<=t, k>=t, t==k, t!=k, t<k, t>k, t<=k, t>=k, are all defined and follow the lexicographical convention. 2. If k and t have different number of elements, then k<t,k>t, t<k,t>k are the only operators defined and follow the "clipping rule" (compare lexicographically taking the minimum of the lengths of the operands.) 3. std::less and std::greater are specialized to accept comparison between composite_key results and tuples, according to the previous definition. No other std comparison object is specialized. If nobody finds a problem with this, these are the rules that'll go into the implementation of composite_key. Thanks, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[serialization+date_time] Serialization Review: serialization of dates
by Jeff Garland 25 Apr '04

25 Apr '04

All - Since I'm the review manager I'm not doing a formal review of the library, but I thought I'd share some code and a few thoughts. If serialization is accepted users people will ask me and other library authors to provide serialization support for some of the types in their libraries. So to get a feel for the difficulty of extending serialization for new types I wrote the serialization code for gregorian::date and some example code to try it out. Of course this sort of extension is a critical aspect of the library design since everyone with a unique type will need to write serialization code. Overall I felt the docs did a pretty good job of explaining what need to be done and the code turns out to be reasonably trivial. Note that the code is more verbose than required as I did not use all of Robert's macros. Also, gregorian::date doesn't currently have a default constructor and hence it is a more challenging case (as I recall the first submission of the serialization lib required default constructors). When programming with dates and times putting them into collections is quite common. Fortunately, one of the most impressive aspects of the current serialization library is the ability to handle stl collections. So I was glad to find (as I expected) that by enabling the serialization of gregorian::date serialization of collections of date's comes along for free. I've attached the code and the serialized file for your reading enjoyment :-) Jeff

2 4

Boost Unicode support ideas
by Jeremy Maitin-Shepard 25 Apr '04

25 Apr '04

It seems that Unicode support in Boost (which could lead to Unicode support in the C++ language and standard library) would be quite desirable. The IBM International Components for Unicode (ICU) library (http://oss.software.ibm.com/icu/) is an existing C++ library with what appears to be a Boost-compatible license, which provides all or most of the Unicode support that would be desired in Boost or the C++ standard library, in addition to Unicode-equivalents of libraries already either in the standard library or in Boost, including number/currency formatting, date formatting, message formatting, and a regular expression library. Unfortunately, it does not use C++ exceptions to signal exceptional conditions (but rather it uses an error code return mechanism), it does not follow Boost naming conventions, and although there are some C++-specific facilities, most of the C++ API is the same as the C API, thus resulting in a less-than-optimal C++ interface. Nonetheless, I think Boostifying the ICU library would be quite feasible, whereas attempting to reimplement all of the desired functionality that the ICU library provides would be extremely time consuming, since the collating and other services in the ICU library already support a large number of locales, and the character-set conversion facilities support a large number of character sets. The representation of locales does present an issue that needs to be considered. The existing C++ standard locale facets are not very suitable for a variety of reasons: - The standard facets (and the locale class itself, in that it is a functor for comparing basic_strings) are tied to facilities such as std::basic_string and std::ios_base which are not suitable for Unicode support. - The interface of std::collate<Ch> is not at all suitable for providing all of the functionality desired for Unicode string collation. A suitable Unicode collation facility should at least allow for user-selection of the strength level used (refer to http://www.unicode.org/unicode/reports/tr10/) and would ideally also support customizations as extensive as the ICU library does (refer to http://oss.software.ibm.com/icu/userguide/Collate_ServiceArchitecture.html and http://oss.software.ibm.com/icu/userguide/Collate_Customization.html) - Facilities such as Unicode string collation are heavily data-driven, and it would be inefficient to load the data for facilities that are not used. This could be avoided by using some sort of lazy loading mechanism. It would still be possible to use the standard locale object as a container of an entirely new set of facets, which could be loaded from the data sources based on the name of the locale, and ``injected'' into an existing locale object, by calling some function. It is not clear, however, what advantage this would serve over simply using a thin-wrapper over a locale name to represent a ``locale,'' as is done in the ICU library. -- Jeremy Maitin-Shepard

9 36

Re: [boost] Re: [multi_index] composite keys: request for advice
by JOAQUIN LOPEZ MU?Z 25 Apr '04

25 Apr '04

Hi Pavel ----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Domingo, Abril 25, 2004 10:11 am Asunto: [boost] Re: [multi_index] composite keys: request for advice > > "Joaquin M Lopez Munoz" <joaquin(a)tid.es> wrote: > > > Composite keys can be specified by a new construct > > called composite_key in the following manner: > > > OT question 1: will it be possible to specify calculated > index as part of composite index? I take you mean "calculated key" and "composite key". Yes, it is possible, composite_key does accept any key extractor, it needs not be multi_index::member. > > > OT question 2 (I could had asked already): would it be somehow > possible for calculated index to use user supplied functor > and then sorting sequenced index according this index? > > This would create 'dynamic index', modifiable during runtime. I'm not quite getting you; the following shows how to specifiy the comparison predicate at run time, I don't know if this is what you are asking. typedef multi_index_container< employee, indexed_by< ordered_unique< identity<employee>, boost::function<bool (const employee&)> > > > employee_set; ... bool foo(const employee&); ... employee_set::ctor_args_list cal; cal.get<0>.get<1>=foo; // 2nd argument of the first index employee_set es(cal); Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] regex lib: bug with sets and back ref
by Benzinger, Ralph 25 Apr '04

25 Apr '04

> > The following behavior seems to be a bug: > > > > * regex '([a-c]+)\1' finds 'abcabc' at offset 0 in text 'abcabc' > > That looks correct. > > > * regex '([abc]+)\1' finds 'bcbc' at offset 1 in text 'abcbc' > > That looks correct. > > > * regex '([a-c]+)\1' finds nothing in text 'abcbc' ??? > > It should 'bcbc' if you're calling regex_search and nothing if you're > calling regex_match. Sorry if I wasn't clear enough. All tests use regex_grep. In the last example, however, regex_grep _doesn't_ find "bcbc", even though it should. I would assume it's an issue with regex_compile, as the only difference between (2) and (3) is the way the set is defined. Ralph

2 1