- Boost - lists.preview.boost.org

RE: [boost] Re: Re: Long toolset names
by Stefan Seefeld 01 Oct '04

01 Oct '04

> From: Tony Juricic [mailto:tonygeek@yahoo.com] > Sent: October 1, 2004 12:03 > Even MS IDE has problems in some cases (very inconsistent) when space > characters are present but I thought that in most Wintel and also UNIX > command tools these issues are easily solved with adding quotes? well, that sounds simpler as it is. It's all those little details such as one shell eating quotes, another passing them through when called in a nested way that makes it really hairy. It's a … [View More]

1 0

White spaces in regression
by Victor A. Wagner Jr. 01 Oct '04

01 Oct '04

As part of my script before I run any of the regression code, I delete all the *.xml files from the results directory. This is done because if there is a _severe_ crash while running the regressions, the *.xml files will still exist when things are "collected". I've been told that it is the responsibility of process_jam_log to create these, BUT: C:\Projects\boost\tools\regression\build>C:\Projects\boost\tools\build\jam_src\bin.ntx86\bjam.exe -sTOOLS=vc7.1 ...found 481 targets... … [View More]

1 0

[Signals] New regressions
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

Doug, It seems that your last checkin broke things on a number of platforms -- see http://tinyurl.com/69npt. -- Aleksey Gurtovoy MetaCommunications Engineering

2 2

Compilation problem with boost on SunCC (Forte 6.2 & 8)
by Puverle, Tomas (IT) 01 Oct '04

01 Oct '04

Please find attached a small program and a the resulting compilation errors on SunCC. This occurs in iterator_facade.hpp, operator != (), calling to interator_core_access::equal. I have tracked this down to the following problem: f(mpl::true_); f(mpl::false_); f(is_convertible<>()); //will not work is_convertible<> derives from mpl::bool<>, however it seems that a bug in the compiler prevents it from converting to mpl::true_/mpl::false_ in the above scenario (and in the … [View More]

1 0

1.32 Status?
by Brian Braatz 01 Oct '04

01 Oct '04

I am anxiously awaiting 1.32 as there are features there that I need. I am holding off though on using them until that is officially released. My question is - is there a target timeframe as to when 1.32 looks like it will be ready. My Suggestion would be that the website (boost.org) have a place on the front page that has the current rough timeframe for when 1.32 may be ready. Thanks Brian Braatz

3 3

[Thread] The last step
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

Gentlemen, Seems like we've just cleared up Boost.Thread failures/regressions on all but one required toolset! See http://tinyurl.com/6h56q. Congratulations on the great job to everyone involved. You can probably guess what I'm about to ask -- can we do something about Intel 8.0/Linux failures? Looking at the output below (from http://tinyurl.com/6mnzn) it seems to me that the test was attempted to be linked against *both* GCC and Intel runtimes: /usr/lib/libc.a(strtol.o)(.text+0x50): In … [View More]

1 0

RE: [boost] Re: [shared_ptr] Interlocked* - possible bug?
by Ben Hutchings 01 Oct '04

01 Oct '04

Alexander Terekhov <terekhov(a)web.de> wrote: > Ben Hutchings wrote: > [...] > > If atomic_read > > returns 0 that means the use count has dropped to 0 [*] and can > > never increase again, so it must be the latest version. Otherwise > > weak_ptr makes a second test that is properly protected. So it can > > never use an old value. > > > > [*] I think this is right but I'm not certain … [View More]

3 17

Re:Re: [boost] Output formatters: different approaches
by Robert Ramey 01 Oct '04

01 Oct '04

>Vladimir Prus wrote: >> During the review of the output formatters library, there were suggested >> several alternative approaches. For example, Gennadiy thinks the library is >> too complicated, and Hartmut suggests creating a library dual to Spirit -- >> which would be extra powerfull. > >> That's not all. Independently, I've talked with Vaclav Blazek, who's the >> author of the Teng text template engine (http://teng.sourceforge.net/) which &… [View More]gt;> is also a similiar domain -- it's too about formatting objects. >I will try to take a look at it next week. >> >> It would be great if we had some common foundation, so that I could output >> ptr_vector<Function> using both a simple formatter, or a flexible one, or >> even some template engine. > > >> 2. A mechanism to iterate over elements of composite type. After some though, >> I believe that the mechanism should be boost::serializaton. >This sounds nice, but I don't know how achievable it is. >Basically, when writing a composite type, you might want to write things >in-between. Like, for a pair, you might want to write: > [first, second] >or ><<first | second>> > (where first and second are the members of the pair) >Same goes for each composite type. >I'm not very familiar with boost::serialize - still it is something to >think about ;) The serialization library provides formatting/recovery for all composite types with no special effort by the programmer. This is usually suitable for the type of output file being used. In cases where it isn't, the output/input can be overloaded on a type by type basis. In practice few have found it necessary or valuable to do this. >> The idea of the library, as I see it, is to provide object serialization, but >> - without the overhead serialization library has >> - with extra layout tweaks >Yes, it would be nice. For objects of the type being discussed, (i.e. no pointers, no class versioning, no memory tracking of duplicates, etc) the serialization library has no extra runtime overhead. I would be very surprised if the serialization library did not result in smaller and faster code than the libraries being discussed. >> I don't see why it's necessary to reinvent the object traversal code which is >> already in boost::serialization. For example, boost::serialization support >> scoped_ptr. It would not make sense to add separate support for scoped_ptr in >> outfmt. The serialization library has all that and much, much more. >I would need to delve further into boost::serialize to have an oppoinion >- and the unfortunate thing is that I won't have any available time soon :( Too bad, it would have consumed much less time than has been already spent on this topic If function output formatters is helpful for making output more easily presentable, fine. Though G. Rozenthal's, experiment makes me doubt this. If the purpose is to save and restore the state of some assortment of class instances - it's the same as the serialization system and should evaluated as an alternative with a full blown comparison. I believe the demos and documentation in the serialization package show that it to be much, much easier to use than the proposed library for this purpose. Robert Ramey [View Less]

3 2

Thread VC 7.1 failures (Bronek Kozicki)
by Stefan Slapeta 01 Oct '04

01 Oct '04

Any idea why some tests fail in this environment? They do all pass on my machine and appearantly also on Victor's. Stefan

4 4

Python/GCC 3.4.1/Linux failures
by Aleksey Gurtovoy 01 Oct '04

01 Oct '04

There are a few of them, see http://tinyurl.com/5z3hy. What we are going to do about it? -- Aleksey Gurtovoy MetaCommunications Engineering

5 13