Boost logo

Boost :

From: Samuel Krempp (krempp_at_[hidden])
Date: 2003-04-22 08:57:39

Dear Giovanni, first I'm glad you took the time to write down those
precise critics, I have good answers (at least I think so :) for several
of them, though not all (I cant pretend the library's complexity was
intended by design :-(

I have another mail underway, but I'd like to fix right now the problem
of segfaults you raise here :

Le mar 22/04/2003 à 04:27, Giovanni Bajo a écrit :
> - Don't ever try to use string conversion on a temporary object returned by
> a function, you get a segfault. Sorry, I didn't have time to track down the
> bug. I realize I'm unfair here since every program can have some bugs, but
> complexity is _the_ issue with Boost.Format, and usually complexity leads to
> a higher likeness of bugs.

can you tell me which compiler you are using, and what is the line of
code that results in sgefault ?

I suspect this comes from the const/non-const reference overload scheme,
which should work according to the C++ norm, but fails to compile or to
execute correctly on some (well, many) platforms.
until now, I had just written workarounds for those that fail to
compile, but obviously I surely missed some run-time issues..

In fact, the non-const reference overloads are here just to avoid
restricting the use of
 format(..) % x
to objects x that are formatted by calling an
operator<<( stream, CONST& X)

It sounds like a safe restriction, but the const/non-const overload in
the code manages to avoid this unneccessary restriction, so I have
chosen to let the user of the library free of providing only non-const
formatting operators...



Boost list run by bdawes at, gregod at, cpdaniel at, john at