Re: [boost] ublas regression test problems

[Joerg Walter]

- Original Message -
From: "Beman Dawes" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>; "'Boost mailing list'"
<[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 9:41 PM
Subject: RE: [boost] ublas regression test problems


> At 06:35 AM 11/20/2002, Aleksey Gurtovoy wrote:
>
>
>  >> because ublas doesn't depend from mpl. So I've to assume,
>  >> that somebody is changing either boost.config, boost.type_traits,
>  >> boost.smart_ptr or boost.timer.
>  >
>  >Hmm, compiles fine for me on the clean CVS get (ignoring "test31/32.cpp"
>  >errors, see the attached log). Are you sure you are in sync with the
main
>  >trunk?
>
> I've just cleared off all old Win32 test bin directories, in case testing
> artifacts are causing those failures.  Running the tests now, but they
take
> several hours when starting from scratch, so it will be awhile before they
> are posted.

OK. The mpl::if_ problem vanished, the remaining problems with VC7 are
home-grown (I'll look into these later). But now all ublas GCC tests fail to
compile due to

In file included from C:/boost/site/boost/type_traits.hpp:43,
 from C:/boost/site/boost/numeric/ublas/config.hpp:24,
 from C:/boost/site/libs/numeric/ublas/concepts.cpp:12:
C:/boost/site/boost/type_traits/is_polymorphic.hpp:20: warning: `typename
   boost::remove_cv::type' is implicitly a typename
C:/boost/site/boost/type_traits/is_polymorphic.hpp:20: warning: implicit
   typename is deprecated, please see the documentation for details
C:/boost/site/boost/type_traits/is_polymorphic.hpp:28: duplicate base type `
   boost::remove_cv::type' invalid

I'm lost again.

Thanks

Joerg





___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: [MPL] Several Questions

[David A. Greene]

Gennadiy Rozental wrote:


1. merge the sequences.


That's easy.


2. Eliminate the duplicates (for example like Loki is doing)


That's hard to do efficiently.  My MC++D book is packed away
at the moment.  Can you refresh my memory as to the solution
there?  Is it better then O(n^2)?

  -Dave

--

"Some little people have music in them, but Fats, he was all music,
 and you know how big he was."  --  James P. Johnson

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Do we need a boost_exception class or idiom?

[David Bergman]

Fernando,

Just curious: do you mean "iff" ("if and only if") by your "IIF", or a
pure emphasized "if" (i.e. "IF")? Just in order for me to follow the
logic in the statements.

/David

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Fernando Cacciola
Sent: Wednesday, November 20, 2002 5:32 PM
To: Boost mailing list
Subject: Re: [boost] Do we need a boost_exception class or idiom?


- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 6:40 PM
Subject: Re: [boost] Do we need a boost_exception class or idiom?


> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > I'm not sure if a boost exception class is *needed*, but I see no
problem in
> > having one.
> > Anyway, IIF such an exception class is defined, I *strongly*
encourage
(as I
> > did in the past) that it provides:
> >
> >   virtual void raise() const
> >   {
> > #ifndef BOOST_NO_EXCEPTIONS
> >   throw *this ;
> > #endif
> >   }
> >
> > and that boost libraries throw such exceptions *only* by calling
.raise():
> > i.e. never with a throw expression directly in the user code.
>
> 1. Why should this be a virtual function? The dynamic type of an
>exception object is never used in a throw expression.
>
Just to avoid visivility issues with redefinitions in derived types (to
avoid the compiler telling that 'raise' hides definition on the base
class)

> 2. Why are we reinventing the wheel?  What's wrong with
>boost::throw_exception() from boost/throw_exception.hpp?
>
Nothing :-)
I like this approach... and I had forgot about it.
Anyway, I was just pointing out that IIF a boost exception class was
defined
it should throw itself.

Fernando Cacciola


___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Do we need a boost_exception class or idiom?

[David Bergman]

I do not know if I would necessary like to have such a hard coupling
between exceptions and logging/tracing...

First of all, the exception-carrying objects get kind of heavy.
Secondly; I think it is good to regard exceptions as something a bit
more than carriers of either (1) log information or (2) a last message
before aborting (which is sometimes implicit in arguments around
exceptions...). I am not saying that your brief sketch of your
home-brewed exception handling indicates that you do not appreciate the
non-logging facet of exceptions, just want the overall discussion of
exceptions not to diverge into pure logging issues. 

Thanks,

David

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: Wednesday, November 20, 2002 4:03 PM
To: [EMAIL PROTECTED]
Subject: RE: [boost] Do we need a boost_exception class or idiom?

> Has anyone run into a comprehensive attack on these and similar
exception 
> class problems? Is there a better way than each Boost developer just 
> hacking together individual exception classes? Could we do better with
a 
> Boost exception class or idiom?

I can only speak from my own personal experience, here...

In my own code, a base class has evolved over time, which I call simply
'error' (in my own namespace, of course).  It has the following
properies:
. Publicly derives from std::exception.
. Contains a std::string member containing the exception message (msg_).
msg_.c_str() is returned to satisfy std::exception::what().  A constant
reference to msg_ is returned from a member function message(); this is
provided as a convenience.
. Contains another std::string member containing an xml description of
the
exception.  A constant reference to this member is returned from the
member
function xml().
. The constructor is declared protected, and has the following
signature:
  error(const string & type, const string & message,
const string & funcname = string(), const string & code =
string())

Furthermore, I have evolved the following practices:
. The "exception message" is always of the form:
  [ErrorTypeName] error `[ErrorMessage]'
with an optional postfix:
  from `[FunctionName]'
. The "xml description" is of the form:
  
Though this is a loose definition; 'function' and 'code' are optional,
'error's may be nested arbitrarily, and additional attributes may be
added.
It is always guaranteed to be valid XML, however.
. The "[FunctionName]" is intended to be the name of the OS/library
function
that returned an error; but whenever possible additional runtime
information
should be included in parenthesis after the actual function name, e.g.,
"CreateFile ([AttemptedFileName])" or "WriteFile (async callback)".
. The "[ErrorMessage]" is a string error taken from an OS/library lookup
function, specific to a derived error class.  It should be trimmed
(i.e., no
trailing whitespace), but may contain whitespace (including newlines).
If
the error code is not known by the lookup function, either "Unknown
error
[ErrorCodeDec]" or "Unknown error 0x[ErrorCodeHex]" should be used.
. There is a one-to-one mapping between derived error classes and values
of
"[ErrorTypeName]".

The constructor for error() enforces the first two of the practices that
have evolved.

However, as I said in the beginning, this has evolved fully from my
personal
experience:
. I regularly have to store errors on disk or send them to other
programs,
and I find the xml member useful for this.
. These are designed for a hierarchy of error classes, each one
responsible
for a separate API.  For example, here's a partial listing:
  error
Win32_error
COM_error
  OLE_error
OLEDB_error
  DirectX_error
socket_error
. The need for nested errors and extendable error attributes (i.e., most
of
the complexity) came from my OLEDB_error derived class.
. In general, I want to capture as much information as reasonably
possible.

Conventions have also evolved for the design of derived classes, but I
don't
see any need to post those at this time.

For a Boost error base class or idiom, I would suggest at least the
following:
. A strict definition of the exception message
. Public derivation from std::exception for all exception classes
. Contains a member of type std::string for the exception message.  It
took
a while for this to evolve in my 'error' (due to performance and
resource
allocation concerns), but I am convinced this is the way to go.

Moving beyond that is more tenatious ground; one of the main questions
on my
mind is should an exception hierarchy be structured after API interfaces
(like mine), or after Boost libraries?  I just don't want to see a lot
of
rework where each Boost library would have their own Win32_error class
or
format_message function.  OTOH, structuring an exception hierarchy after
API
interfaces makes perfect sense for an end-user executable program (like
what
I write), but maybe not as much sense for a library?

Regardless

Re: FW: [boost] Serialization & XML (was Serialization Library Review)

[Beman Dawes]

At 10:01 PM 11/18/2002, Robert Ramey wrote:

>Is there a reason you sent this to me privately?
>> From: David Abrahams <[EMAIL PROTECTED]>
>
>>I believe your assessment that some
>>data structures can't be represented using XML is incorrect, and
>>that's easy to prove. A serialization library which makes generation
>>of XML output difficult is severely handicapped in the modern world.
>
>Well, I have conceded that it was preliminary.  All I know about XML
>is from a small book containing a concise description of XML.
>
>My skeptism is based on the following thought experiment:
>Suppose on is given a list of polymorphic pointers, some of which
>correspond to bottom node of a diamond in heritance structure
>and some of which are repeated in the list and serialized
>some where else as well.
>
>a) How would such a thing be represented in XML?
>b) Could be loaded back to create an equivalent structure?
>c) Would it be useful for anything other than this serialization system?
>
>If someone can assure me that the answers to all three of the above
>is yes then it should be possible - otherwise not.  Given that its
>"easy to prove" these questions should be easy to answer in
>a convincing way.

Robert,

I think you may be missing several points with your thought experiment:

* The serialization library doesn't have to figure out how all C++ data 
structures (such as in your thought experiment) would be represented in XML 
or any other format. Instead, all that serialization has to supply is a 
base class with the default hooks for prolog, epilog, separator, data, and 
similar functions. It is up to the user to customize for a particular 
format, beyond a few basic ones supplied by the implementation.

* Some approaches, including XML, allow a practically unlimited number of 
different ways to represent the same data. The user rather than the 
serialization library should choose the particular design.

* Some formats may not be able to support all C++ data structures, and that 
is okay. For example, the comma separated value (CSV) format used by many 
desktop tool programs won't extend much beyond arrays of simple structures. 
That doesn't mean the format is useless and or that it shouldn't be 
supported. It just means it isn't suitable for all tasks.

So what seems to me to be needed is a description of the concepts for input 
and output format classes.  As long at these are flexible, the users can 
then work out many of the details for particular formats.

--Beman


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[David Abrahams]

"William E. Kempf" <[EMAIL PROTECTED]> writes:

> David Abrahams said:
>> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>>
 There are workarounds for that problem. See
 http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254
>>>
>>> Thanks for the link.  Comments:
>>>
>>> * I personally don't agree with the rationale that not throwing
>>> bad_alloc when constructing from a string is not necessarily a bad
>>> thing.  As bad as exception specifications are, they are at least
>>> useful as documentation
>>
>> Not very. Don't forget that derived classes pass.
>
> *being dumb* What do you mean by that last sentence?

If an exception specification says throw(X), any class derived from X
may be thrown, and that class can add arbitrary semantic value to
X. So an exception-specification doesn't tell you much about what can
actually be thrown.

>>> and this automatically adds another exception type to the list that
>>> may not have otherwise been there.
>>
>> Not unless your compiler is broken. Exception specifications are
>> strictly enforced at runtime.
>
> I was referring to specification as documentation, not as an actual
> specification in the code.  For instance, the
> boost::thread_lock_error is specified to be thrown in the
> documentation of several Boost.Threads methods, but what's not
> documented (which means a bug either in the documentation or the
> implementation, but that answer is unsatisfying) is that this means
> std::bad_alloc may also be thrown.

Why? That just seems like a bad implementation of thread_lock_error.

> But, frankly, the using specification in the actual code would make
> this point even stronger, as this may mean a call to unexpected()
> instead.

I don't know what you're saying.

>>> At the very least, it would be nice if we had a boost::exception
>>> (derived from std::exception) as a base, which included the const
>>> char* constructor to eliminate the problem with the string
>>> constructor,
>>
>> There is no problem with the string constructor, because that
>> constructor doesn't exist in std::exception.
>
> No, but it does in the branches for logic_error and runtime_error.
> The logic is that if all of our exceptions are based of off
> boost::exception, we can avoid the issue found in those branches.
> (OK, this isn't an argument for having our own exceptions, exactly,
> but I wasn't trying to make that argument.)

What argument are you trying to make?

>>> and that ensured nothrow copies.
>>
>> You can't ensure that in a base class. A derived class can always
>> throw in its copy-ctor.
>
> Yeah, but that wasn't the point I was trying to make.  I simply
> meant that IIF we do have a Boost exception heirarchy, it shouldn't
> force the issue of dynamic allocation of strings on the user at any
> node of the tree.

Good, we agree on that.

>>> No, but it is desirable to provide language neutral strings
>>
>> What's a language-neutral string? "42"?
>
> A string that's based on the users locale.
>
>>> that describe what exception was thrown, and possibly why and/or
>>> from where, etc.  This isn't to say that what() is bad because
>>> it's not language neutral
>>
>> ?? It's as language-neutral as you make it. It's just a string.
>>
>>> only that there's (at least in some circumstances) a desire for a
>>> language neutral description of what went wrong.
>>
>> Localization should not the be the job of an exception class.
>
> This shows that you did understand what I was trying to convey,
> despite the numerous questions that do nothing but point out how
> badly I described the problem ;).

If I gave you just one coherent answer in all this mess, it doesn't
mean I understood what you were driving at all along. It only means we
managed to communicate without confusion at one point in the
conversation. I'm not trying to be anal about your description of "the
problem", whatever that may be. I really don't understand what you're
driving at.

And, BTW, I think that if there _is_ a problem, a good description
should precede any attempts to solve it.

> I don't expect the exception to provide localization, only that it
> provide the necessary hooks for localization to be easily
> implemented.

What do you think those should look like?

>> ?? Aren't we talking about whether a boost::exception is needed?
>> Wouldn't that just be derived from std::exception?  What's the
>> problem?
>
> If you leave it just at the root of the tree, nothing.  I just
> expected we'd have the logic_error and runtime_error branches as
> well... but that may have been a bad expectation.

I sure hope so. I would never use those exceptions if I cared about
behavior in low-memory situations.

> and possibly could be used to index into a catalog of language
> neutral strings for output.

 Existing what() does that.
>>>
>>> How so?  I can think of a few hacks, but none seem completely
>>> satisfying.
>>
>>   std::map?
>
> This assumes that the what() strings are all unique, 

Show me anoth

RE: [boost] Do we need a boost_exception class or idiom?

[johan_ericsson]

-Original Message-
From: David Abrahams [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, November 20, 2002 1:40 PM
To: Boost mailing list
Subject: Re: [boost] Do we need a boost_exception class or idiom?


>"Fernando Cacciola" <[EMAIL PROTECTED]> writes:

>> I'm not sure if a boost exception class is *needed*, but I see no problem in
>> having one.
>> Anyway, IIF such an exception class is defined, I *strongly* encourage (as I
>> did in the past) that it provides:
>>
>>   virtual void raise() const
>>   {
>> #ifndef BOOST_NO_EXCEPTIONS
>>   throw *this ;
>> #endif
>>  }
>>
>> and that boost libraries throw such exceptions *only* by calling .raise():
>> i.e. never with a throw expression directly in the user code.

>1. Why should this be a virtual function? The dynamic type of an
>   exception object is never used in a throw expression.

I can think of one reason; if you are going to add a clone() method call to
the exception hierarchy. Then you could save a copy of the exception object
and rethrow it using the virtual method call. This is useful when you want to
pass an exception across threads. It's also useful if you are wrapping a C
interface that includes callbacks.

Johan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Do we need a boost_exception class or idiom?

[Andrei Alexandrescu]

"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[snip]
> This seems like a very bad solution. It requires solving the
> forwarding constructor problem, for one thing. boost::throw_exception
> doesn't have that problem.

I don't know about boost::throw_exception, but a nonmenber should be
generally preferred to a member. Thus, I find the solution based on member
raise poor. An equivalent free function can be written:

template 
void raise(const T& exc)
{
#ifdef ...
throw exc;
#endif
}


Andrei




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[William E. Kempf]

David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>
>>> There are workarounds for that problem. See
>>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254
>>
>> Thanks for the link.  Comments:
>>
>> * I personally don't agree with the rationale that not throwing
>> bad_alloc when constructing from a string is not necessarily a bad
>> thing.  As bad as exception specifications are, they are at least
>> useful as documentation
>
> Not very. Don't forget that derived classes pass.

*being dumb* What do you mean by that last sentence?

>> and this automatically adds another exception type to the list that
>> may not have otherwise been there.
>
> Not unless your compiler is broken. Exception specifications are
> strictly enforced at runtime.

I was referring to specification as documentation, not as an actual
specification in the code.  For instance, the boost::thread_lock_error is
specified to be thrown in the documentation of several Boost.Threads
methods, but what's not documented (which means a bug either in the
documentation or the implementation, but that answer is unsatisfying) is
that this means std::bad_alloc may also be thrown.

But, frankly, the using specification in the actual code would make this
point even stronger, as this may mean a call to unexpected() instead.

>> * It's nice to know that the copy constructor is technically not
>> allowed to throw, but how many implementations get this wrong today?
>
> None, to my knowledge.

Surprising, but if true, reassuring.

>> At the very least, it would be nice if we had a boost::exception
>> (derived from std::exception) as a base, which included the const
>> char* constructor to eliminate the problem with the string
>> constructor,
>
> There is no problem with the string constructor, because that
> constructor doesn't exist in std::exception.

No, but it does in the branches for logic_error and runtime_error.  The
logic is that if all of our exceptions are based of off boost::exception,
we can avoid the issue found in those branches.  (OK, this isn't an
argument for having our own exceptions, exactly, but I wasn't trying to
make that argument.)

>> and that ensured nothrow copies.
>
> You can't ensure that in a base class. A derived class can always
> throw in its copy-ctor.

Yeah, but that wasn't the point I was trying to make.  I simply meant that
IIF we do have a Boost exception heirarchy, it shouldn't force the issue
of dynamic allocation of strings on the user at any node of the tree.

 and the string isn't language neutral.
>>>
>>> Neither is your source code. You don't need to use the string for
>>> language-neutral messages.
>>
>> No, but it is desirable to provide language neutral strings
>
> What's a language-neutral string? "42"?

A string that's based on the users locale.

>> that describe what exception was thrown, and possibly why and/or from
>> where, etc.  This isn't to say that what() is bad because it's not
>> language neutral
>
> ?? It's as language-neutral as you make it. It's just a string.
>
>> only that there's (at least in some circumstances) a desire for a
>> language neutral description of what went wrong.
>
> Localization should not the be the job of an exception class.

This shows that you did understand what I was trying to convey, despite
the numerous questions that do nothing but point out how badly I described
the problem ;).

I don't expect the exception to provide localization, only that it provide
the necessary hooks for localization to be easily implemented.

 I'd prefer a what() that returned a key which never had to be
 allocated
>>>
>>> It does; you can always return a string literal.
>>
>> Uhm... yes, so long as you can supply that key with out having to use
>> the string constructors from most of the standard exceptions.
>
> ?? Aren't we talking about whether a boost::exception is needed?
> Wouldn't that just be derived from std::exception?  What's the
> problem?

If you leave it just at the root of the tree, nothing.  I just expected
we'd have the logic_error and runtime_error branches as well... but that
may have been a bad expectation.

 and possibly could be used to index into a catalog of language
 neutral strings for output.
>>>
>>> Existing what() does that.
>>
>> How so?  I can think of a few hacks, but none seem completely
>> satisfying.
>
>   std::map?

This assumes that the what() strings are all unique, gives suboptimal
performance in lookups, and doesn't allow for specifying data to be
formatted into the string.  But at this point I think I can safely assume
you don't care about these points, which is a valid point of view.

>> std::exception is nearly the perfect design (it's the logic_error and
>> runtime_error branches in the heirarchy I have problems with, though
>> as you pointed out there are ways to fix those).  The only problem is
>> how you allow the strings to be made language neutral.  From what you
>> said above, I assume you think 

Re: [boost] Do we need a boost_exception class or idiom?

[David Abrahams]

"Fernando Cacciola" <[EMAIL PROTECTED]> writes:

>> 2. Why are we reinventing the wheel?  What's wrong with
>>boost::throw_exception() from boost/throw_exception.hpp?
>>
> Nothing :-)
> I like this approach... and I had forgot about it.
> Anyway, I was just pointing out that IIF a boost exception class was defined
> it should throw itself.

Why should it? That seems to imply that there /is/ something wrong
with the boost::throw_exception approach.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[David Abrahams]

"William E. Kempf" <[EMAIL PROTECTED]> writes:

>> There are workarounds for that problem. See
>> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254
>
> Thanks for the link.  Comments:
>
> * I personally don't agree with the rationale that not throwing
> bad_alloc when constructing from a string is not necessarily a bad
> thing.  As bad as exception specifications are, they are at least
> useful as documentation

Not very. Don't forget that derived classes pass.

> and this automatically adds another exception type to the list that
> may not have otherwise been there.

Not unless your compiler is broken. Exception specifications are
strictly enforced at runtime.

> * It's nice to know that the copy constructor is technically not allowed
> to throw, but how many implementations get this wrong today?

None, to my knowledge.

> At the very least, it would be nice if we had a boost::exception (derived
> from std::exception) as a base, which included the const char* constructor
> to eliminate the problem with the string constructor, 

There is no problem with the string constructor, because that
constructor doesn't exist in std::exception.

> and that ensured nothrow copies.

You can't ensure that in a base class. A derived class can always
throw in its copy-ctor.

>>> and the string isn't language neutral.
>>
>> Neither is your source code. You don't need to use the string for
>> language-neutral messages.
>
> No, but it is desirable to provide language neutral strings 

What's a language-neutral string? "42"?

> that describe what exception was thrown, and possibly why and/or
> from where, etc.  This isn't to say that what() is bad because it's
> not language neutral

?? It's as language-neutral as you make it. It's just a string.

> only that there's (at least in some circumstances) a desire for a
> language neutral description of what went wrong.

Localization should not the be the job of an exception class.

>>> I'd prefer a what() that returned a key which never had to be
>>> allocated
>>
>> It does; you can always return a string literal.
>
> Uhm... yes, so long as you can supply that key with out having to
> use the string constructors from most of the standard exceptions.

?? Aren't we talking about whether a boost::exception is needed?
Wouldn't that just be derived from std::exception?  What's the
problem?

>
>>> and possibly could be used to index into a catalog of language
>>> neutral strings for output.
>>
>> Existing what() does that.
>
> How so?  I can think of a few hacks, but none seem completely
> satisfying.

  std::map?

>> I don't think what() needs to be addressed. The kind of polymorphic key
>> that could carry arbitrary extra data surely *forces* dynamic
>> allocation, so it wouldn't be an improvment.
>
> I never claimed the key need be polymorphic, and thus dynamic allocation
> isn't necessarily forced.

OK, but I claim char const* does give us very nice polymorphism and
can even use static allocation.

> std::exception is nearly the perfect design (it's the logic_error and
> runtime_error branches in the heirarchy I have problems with, though as
> you pointed out there are ways to fix those).  The only problem is how you
> allow the strings to be made language neutral.  From what you said above,
> I assume you think there's a solution to that, but I don't see it.  Care
> to point out what I'm not seeing?

If there's an answer, it's in a different domain. I don't think that
belongs in an exception class.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 'function' idea

[Paul Mensonides]

- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 2:24 PM
Subject: Re: [boost] 'function' idea


> "Paul Mensonides" <[EMAIL PROTECTED]> writes:
>
> >> [This is getting way off-topic for Boost. We should take this off-line
or
> > over
> >> to clc++m)
> >
> > I'm done anyway.  I've already made my case.
>
> But you made it in a forum where it can't make much difference. If you
> don't post this to csc++ it's too bad, since your incisive thinking
> and argumentation will go to waste.

I already did make this case at comp.std.c++, and I'm not in a position to
make it directly to the committee--except to people that are on the
committee such as those at Boost and comp.std.c++.

Paul Mensonides

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[William E. Kempf]

David Abrahams said:
> "William E. Kempf" <[EMAIL PROTECTED]> writes:
>> Fernando Cacciola said:
>> template 
>> void raise(const P1& p1)
>> {
>> #ifndef BOOST_NO_EXCEPTIONS
>>throw T(p1);
>> #endif
>> }
>>
>> // other such overloads if needed
>>
>> void foo()
>> {
>>raise("my logic error");
>> }
>>
>> Is this not better?  It works even with the standard exception types,
>> no modification to the implementation.  Not a 100% solution for what
>> you want, since there's still exceptions that can be raised outside of
>> Boost code, but maybe it's enough.
>
> This seems like a very bad solution. It requires solving the
> forwarding constructor problem, for one thing. boost::throw_exception
> doesn't have that problem.

A better solution yet, though I wouldn't classify what I had as "very
bad". ;)

>> I dislike the standard exception what(), since (with most of the
>> exception types) this requires dynamic allocation of the string,
>
> It's not what() that imposes this constraint, but the constructor
> signature.

Yep.  That's why I said "with most of the exception types", though I have
to admit this was a bad description of the problem.

>> which may change the type of exception thrown
>
> There are workarounds for that problem. See
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254

Thanks for the link.  Comments:

* I personally don't agree with the rationale that not throwing bad_alloc
when constructing from a string is not necessarily a bad thing.  As bad as
exception specifications are, they are at least useful as documentation,
and this automatically adds another exception type to the list that may
not have otherwise been there.

* It's nice to know that the copy constructor is technically not allowed
to throw, but how many implementations get this wrong today?

At the very least, it would be nice if we had a boost::exception (derived
from std::exception) as a base, which included the const char* constructor
to eliminate the problem with the string constructor, and that ensured
nothrow copies.

>> and the string isn't language neutral.
>
> Neither is your source code. You don't need to use the string for
> language-neutral messages.

No, but it is desirable to provide language neutral strings that describe
what exception was thrown, and possibly why and/or from where, etc.  This
isn't to say that what() is bad because it's not language neutral, only
that there's (at least in some circumstances) a desire for a language
neutral description of what went wrong.

>> I'd prefer a what() that returned a key which never had to be
>> allocated
>
> It does; you can always return a string literal.

Uhm... yes, so long as you can supply that key with out having to use the
string constructors from most of the standard exceptions.

>> and possibly could be used to index into a catalog of language
>> neutral strings for output.
>
> Existing what() does that.

How so?  I can think of a few hacks, but none seem completely satisfying.

>> Maybe type_info::name() would be enough for a human readable string,
>> but there's two issues with this: it doesn't carry any extra data (for
>> example, an invalid_argument exception could indicate which argument
>> was invalid) and it's not easily used to index into
>> language neutral strings.  But if there's anything a boost_exception
>> base type should do, it's address the what() issues.
>
> I don't think what() needs to be addressed. The kind of polymorphic key
> that could carry arbitrary extra data surely *forces* dynamic
> allocation, so it wouldn't be an improvment.

I never claimed the key need be polymorphic, and thus dynamic allocation
isn't necessarily forced.

std::exception is nearly the perfect design (it's the logic_error and
runtime_error branches in the heirarchy I have problems with, though as
you pointed out there are ways to fix those).  The only problem is how you
allow the strings to be made language neutral.  From what you said above,
I assume you think there's a solution to that, but I don't see it.  Care
to point out what I'm not seeing?

William E. Kempf



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[Fernando Cacciola]

- Original Message -
From: "David Abrahams" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 6:40 PM
Subject: Re: [boost] Do we need a boost_exception class or idiom?


> "Fernando Cacciola" <[EMAIL PROTECTED]> writes:
>
> > I'm not sure if a boost exception class is *needed*, but I see no
problem in
> > having one.
> > Anyway, IIF such an exception class is defined, I *strongly* encourage
(as I
> > did in the past) that it provides:
> >
> >   virtual void raise() const
> >   {
> > #ifndef BOOST_NO_EXCEPTIONS
> >   throw *this ;
> > #endif
> >   }
> >
> > and that boost libraries throw such exceptions *only* by calling
.raise():
> > i.e. never with a throw expression directly in the user code.
>
> 1. Why should this be a virtual function? The dynamic type of an
>exception object is never used in a throw expression.
>
Just to avoid visivility issues with redefinitions in derived types (to
avoid the compiler telling that 'raise' hides definition on the base class)

> 2. Why are we reinventing the wheel?  What's wrong with
>boost::throw_exception() from boost/throw_exception.hpp?
>
Nothing :-)
I like this approach... and I had forgot about it.
Anyway, I was just pointing out that IIF a boost exception class was defined
it should throw itself.

Fernando Cacciola


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 'function' idea

[David Abrahams]

"Paul Mensonides" <[EMAIL PROTECTED]> writes:

>> [This is getting way off-topic for Boost. We should take this off-line or
> over
>> to clc++m)
>
> I'm done anyway.  I've already made my case.  

But you made it in a forum where it can't make much difference. If you
don't post this to csc++ it's too bad, since your incisive thinking
and argumentation will go to waste.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: BOOST_CHECK_EQUAL() dangers

[Tanton Gibbs]

> > 1. Just document it. Not so good, IMHO.
> >
> > 2. Document the special case and add a check for NULL pointers before
> > calling strcmp().
> >
> > 3. Remove the special case alltogether. After all, I might want to check
> > that the pointers are equal and not the string they point to. This might
> > be the best solution, but breaks backward compatibility.
> >
> > Markus
>
> In majority of the cases when user is comparing two character pointers he
> need namely "string comparison". Requiring to cast both sides to
std::string
> is a big burden IMO. So I would choose  solution 2.
>
> Gennadiy.

I agree with this.  I know people will occasionally want to check whether
two char* ptrs are pointing to the same value, but it doesn't seem to me to
be as common as checking whether two char* are "strcmp" equal.  To get ptr
equality, the users could just cast the char* to void*.

Tanton

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 'function' idea

[Paul Mensonides]

- Original Message -
From: "Douglas Gregor" <[EMAIL PROTECTED]>

> > This isn't what that section means however.  It is only a list a few
cases
> > of "trying to form any type that isn't a C++ type."
>
> ... but I've stated what was the intent of the committee (according to my
> recollection from talking with Daveed); that is, to fail when one tries to
> form a type that isn't a C++ type. Do you have any specific cases they
have
> missed? If so, then there is a defect and we should report it. Note that
> sizeof()-based cases (that rely on semantic checks) don't apply, because
they
> aren't based on forming new types and should cause a real error (not
template
> argument deduction failure).

Given the intent of the committee on this issue, then yes, it should cause a
real error rather than failure.  What I want to know is *why* that is
considered a good resolution.  I see no gain an any way for type deduction
failure to fail only in this regard.

> > I'm talking about the strict interpretation of the standard
(14.8.3)--not
> > what current compilers do.  Type deduction happens *before* overload
> > resolution--i.e. in the process or building a candidate set.  The
template
> > function just has to be visible.  So, in order for the function to
"never
> > make it into the overload set," it has to fail type deduction (i.e. not
> > pass and _not_ error).
>
> There's a _huge_ miscommunication here. I'm talking about your proposed
> resolution, and assuming that we adopt the rule "template argument
deduction
> fails if the result is a semantically invalid declaration". One can then
> write a function template whose declaration will _always_ be ill-formed,
so
> it will never succeed at template argument deduction.

I'm only talking about things that a dependant on template parameters.
Something like this would be a compile-time error just by passing the
declaration:

template void f(T&*);

That is not what I mean.  Type deduction can fail only if the declaration
was previously passed without error.  Otherwise, type deduction on the given
template function and overload resolution in general is moot.

Besides, you'd actually have to go out of your way to concoct a declaration
that would *always* be ill-formed when instantiated with template arguments.
And even if you did, so what?  You can write an overload that will never be
selected already:

class x {
private:
struct y { };
friend void f(y);
};

void f(x::y) { }

You can even write a template function declaration that will _never_ pass
type deduction already.

> How will the user get
> an error when trying to call this function? (Answer: use a C++98 compiler,
> which will emit an error on any attempt to instantiate the function
template
> declaration).

What kind of function declaration are you talking about here?  I'm only
talking about declarations that aren't ill-formed all by themselves--without
any instantiation whatsoever.

> The issue I have is that your resolution may make it easier to write code
that
> "compiles", but only because the definition is never actually
instantiated.
> And when it's easier to write bad code that the compiler won't catch, it's
> harder to learn the language.

If you're running into problems caused by type deduction failure, then you
already should be pretty solid on the language itself.  It wouldn't exactly
be surprising that a template function was not selected if it was invalid
with a given template argument.  Plus, I can just as easily make the case
that the reverse is true--that having a specific list of "failures" is more
complex for one learning the language.

> > This isn't a case of a "badly broken function template," nor is a case
of
> > it being "silently useless."  It can be a perfectly worthwhile function
> > template.
>
> Do you have a concrete example? This would help us greatly.

I already gave several.  In particular, how about
pointer-to-member-reference:

struct X { };

template void f(T X::*);
template void f(T x, T y);

f(0, 0); // error in type deduction of function
   // that never would be selected anyway

> > This change would do several things,
> > 1) cleanup that section of the standard,
>
> "Cleanup" is not a good word to use when we're talking about a change in
> semantics. Cleanup can refer to adding missing cases, introducing
rationale,
> or tighening up the wording in accordance with the intent of the section.

I'm specifically *not* talking about a change in semantics.  This whole idea
of a compile-time error during type deduction is not specified *anywhere* in
the standard.  In fact, this whole area is *way* underspecified.  Even if
you assume that is implied--which I'll grant is possible--all this would do
is make something legal that wasn't before.  That isn't "changing
semantics."

Why is the intent as limited as it is?  I've yet to hear anyone answer that
question.

> > 2) unify the rules with
> > declaration instantiation ala member functions,
>
> I'm not s

Re: [boost] Re: BOOST_CHECK_EQUAL() dangers

[David Abrahams]

"Gennadiy Rozental" <[EMAIL PROTECTED]> writes:

>> 1. Just document it. Not so good, IMHO.
>>
>> 2. Document the special case and add a check for NULL pointers before
>> calling strcmp().
>>
>> 3. Remove the special case alltogether. After all, I might want to check
>> that the pointers are equal and not the string they point to. This might
>> be the best solution, but breaks backward compatibility.
>>
>> Markus
>
> In majority of the cases when user is comparing two character pointers he
> need namely "string comparison". Requiring to cast both sides to std::string
> is a big burden IMO. 

Really?

BOOST_CHECK_EQUAL(std::string(x), std::string(y))

> So I would choose  solution 2.

:(

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: BOOST_CHECK_EQUAL() dangers

[Gennadiy Rozental]

> 1. Just document it. Not so good, IMHO.
>
> 2. Document the special case and add a check for NULL pointers before
> calling strcmp().
>
> 3. Remove the special case alltogether. After all, I might want to check
> that the pointers are equal and not the string they point to. This might
> be the best solution, but breaks backward compatibility.
>
> Markus

In majority of the cases when user is comparing two character pointers he
need namely "string comparison". Requiring to cast both sides to std::string
is a big burden IMO. So I would choose  solution 2.

Gennadiy.




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[David Abrahams]

Beman Dawes <[EMAIL PROTECTED]> writes:

> The bigger issue is whether or not Boost should have a usual way of
> defining error exceptions thrown by Boost libraries

Probably not; std::exception works well enough.

> with raise() being one of the issues to be dealt with.

Definitely not. That's not a Boost-exception-specific issue.

>  >and that boost libraries throw such exceptions *only* by calling
>  >.raise(): i.e. never with a throw expression directly in the user
>  >code.
>
> I'm not sure if what we need is a class, a concept, or just some
> documentation.
>
> But it does seem that individual Boosters have figured out
> (presumably better) ways to handle some aspects of reporting error
> exceptions. Would anyone be interested in trying to refine that
> vague feeling into something specific?

I don't know what the problem is yet.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[David Abrahams]

"William E. Kempf" <[EMAIL PROTECTED]> writes:

> Fernando Cacciola said:
>> I'm not sure if a boost exception class is *needed*, but I see no
>> problem in having one.
>> Anyway, IIF such an exception class is defined, I *strongly* encourage
>> (as I did in the past) that it provides:
>>
>>   virtual void raise() const
>>   {
>> #ifndef BOOST_NO_EXCEPTIONS
>>   throw *this ;
>> #endif
>>   }
>>
>> and that boost libraries throw such exceptions *only* by calling
>> .raise(): i.e. never with a throw expression directly in the user code.
>
> template 
> void raise()
> {
> #ifndef BOOST_NO_EXCEPTIONS
>throw T();
> #endif
> }
>
> template 
> void raise(const P1& p1)
> {
> #ifndef BOOST_NO_EXCEPTIONS
>throw T(p1);
> #endif
> }
>
> // other such overloads if needed
>
> void foo()
> {
>raise("my logic error");
> }
>
> Is this not better?  It works even with the standard exception types, no
> modification to the implementation.  Not a 100% solution for what you
> want, since there's still exceptions that can be raised outside of Boost
> code, but maybe it's enough.

This seems like a very bad solution. It requires solving the
forwarding constructor problem, for one thing. boost::throw_exception
doesn't have that problem.

> I dislike the standard exception what(), since (with most of the
> exception types) this requires dynamic allocation of the string,

It's not what() that imposes this constraint, but the constructor
signature.

> which may change the type of exception thrown

There are workarounds for that problem. See
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-closed.html#254

> and the string isn't language neutral.  

Neither is your source code. You don't need to use the string for
language-neutral messages.

> I'd prefer a what() that returned a key which never had to be
> allocated

It does; you can always return a string literal.

> and possibly could be used to index into a catalog of language
> neutral strings for output.  

Existing what() does that.

> Maybe type_info::name() would be enough for a human readable string,
> but there's two issues with this: it doesn't carry any extra data
> (for example, an invalid_argument exception could indicate which
> argument was invalid) and it's not easily used to index into
> language neutral strings.  But if there's anything a boost_exception
> base type should do, it's address the what() issues.

I don't think what() needs to be addressed. The kind of polymorphic
key that could carry arbitrary extra data surely *forces* dynamic
allocation, so it wouldn't be an improvment.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[David Abrahams]

"Fernando Cacciola" <[EMAIL PROTECTED]> writes:

> I'm not sure if a boost exception class is *needed*, but I see no problem in
> having one.
> Anyway, IIF such an exception class is defined, I *strongly* encourage (as I
> did in the past) that it provides:
>
>   virtual void raise() const
>   {
> #ifndef BOOST_NO_EXCEPTIONS
>   throw *this ;
> #endif
>   }
>
> and that boost libraries throw such exceptions *only* by calling .raise():
> i.e. never with a throw expression directly in the user code.

1. Why should this be a virtual function? The dynamic type of an
   exception object is never used in a throw expression.

2. Why are we reinventing the wheel?  What's wrong with
   boost::throw_exception() from boost/throw_exception.hpp?

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] [Jason Shirk ]boost\dynamic_bitset.hppneeds update for Everett

[David Abrahams]

--- Begin Message ---
I just checked CVS, and boost\dynamic_bitset.hpp needs a change to avoid a warning 
with Everett:

Here is the patch:

50c50
< #ifdef BOOST_MSVC
---
> #if (BOOST_MSVC <= 1300)

Jason

--- End Message ---


-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: [MPL] Several Questions

[Gennadiy Rozental]

> David A. Greene wrote:
> > I'm starting to explore mpl a bit and I ran into a roadblock.
> > If I have a template that takes an argument that can be
> > a sequence (e.g. mpl::vector) or a regular old type, is
> > there any way, short of specialization, to determine whether
> > the parameter is a sequence?
>
> "is_sequence::value", please expect it to appear in the CVS in a day or
> two :).

'That's exactly what I wanted in a thread "high order type traits and MPL".
Where you able to implement it without template template?

>
> > I'd like to avoid specializing the template based on mpl guts
> > that may change.  Alternatively, is there any way to manipulate
> > the parameter to guarantee that it is converted to a sequence (of
> > one element) if it is not a sequence?
>
> Given 'is_sequence', it will be as simple as this:
>
> template< typename T >
> struct as_sequence
> : if_< is_sequence, T, single_view >
> {
> };

single_view?

> implement something like this:
>
> struct my_sequence_tag;
>
> struct first {
> typedef my_sequence_tag;

> >
> > I thought about designing some kind of wrapper that could
> > be used in specialization:
> >
> > template
> > struct intrusive_list {
> >typedef Node::type type;
> > };
> >
> > Then I could partially specialize begin<>/end<> on
> > intrusive_list.  Is this a reasonable approach?
>
> It is, at least from the technical standpoint - 'begin/end' /
> 'begin_trait/end_trait' templates were intended to be specialized; I would
> need some user-level examples of intended usage for the whole thing to be
> able to judge if there is a better way here.
>
>
> >
> > Here's one final puzzle: I have two type vectors that
> > I'd like to merge into one.  The trick is that I want
> > to eliminate all duplicates.  Since types cannot be
> > ordered (how does one define a less-than operation?)

1. merge the sequences.
2. Eliminate the duplicates (for example like Loki is doing)

Gennadiy.




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Do we need a boost_exception class or idiom?

[scleary]

> Has anyone run into a comprehensive attack on these and similar exception 
> class problems? Is there a better way than each Boost developer just 
> hacking together individual exception classes? Could we do better with a 
> Boost exception class or idiom?

I can only speak from my own personal experience, here...

In my own code, a base class has evolved over time, which I call simply
'error' (in my own namespace, of course).  It has the following properies:
. Publicly derives from std::exception.
. Contains a std::string member containing the exception message (msg_).
msg_.c_str() is returned to satisfy std::exception::what().  A constant
reference to msg_ is returned from a member function message(); this is
provided as a convenience.
. Contains another std::string member containing an xml description of the
exception.  A constant reference to this member is returned from the member
function xml().
. The constructor is declared protected, and has the following signature:
  error(const string & type, const string & message,
const string & funcname = string(), const string & code = string())

Furthermore, I have evolved the following practices:
. The "exception message" is always of the form:
  [ErrorTypeName] error `[ErrorMessage]'
with an optional postfix:
  from `[FunctionName]'
. The "xml description" is of the form:
  
Though this is a loose definition; 'function' and 'code' are optional,
'error's may be nested arbitrarily, and additional attributes may be added.
It is always guaranteed to be valid XML, however.
. The "[FunctionName]" is intended to be the name of the OS/library function
that returned an error; but whenever possible additional runtime information
should be included in parenthesis after the actual function name, e.g.,
"CreateFile ([AttemptedFileName])" or "WriteFile (async callback)".
. The "[ErrorMessage]" is a string error taken from an OS/library lookup
function, specific to a derived error class.  It should be trimmed (i.e., no
trailing whitespace), but may contain whitespace (including newlines).  If
the error code is not known by the lookup function, either "Unknown error
[ErrorCodeDec]" or "Unknown error 0x[ErrorCodeHex]" should be used.
. There is a one-to-one mapping between derived error classes and values of
"[ErrorTypeName]".

The constructor for error() enforces the first two of the practices that
have evolved.

However, as I said in the beginning, this has evolved fully from my personal
experience:
. I regularly have to store errors on disk or send them to other programs,
and I find the xml member useful for this.
. These are designed for a hierarchy of error classes, each one responsible
for a separate API.  For example, here's a partial listing:
  error
Win32_error
COM_error
  OLE_error
OLEDB_error
  DirectX_error
socket_error
. The need for nested errors and extendable error attributes (i.e., most of
the complexity) came from my OLEDB_error derived class.
. In general, I want to capture as much information as reasonably possible.

Conventions have also evolved for the design of derived classes, but I don't
see any need to post those at this time.

For a Boost error base class or idiom, I would suggest at least the
following:
. A strict definition of the exception message
. Public derivation from std::exception for all exception classes
. Contains a member of type std::string for the exception message.  It took
a while for this to evolve in my 'error' (due to performance and resource
allocation concerns), but I am convinced this is the way to go.

Moving beyond that is more tenatious ground; one of the main questions on my
mind is should an exception hierarchy be structured after API interfaces
(like mine), or after Boost libraries?  I just don't want to see a lot of
rework where each Boost library would have their own Win32_error class or
format_message function.  OTOH, structuring an exception hierarchy after API
interfaces makes perfect sense for an end-user executable program (like what
I write), but maybe not as much sense for a library?

Regardless of what exactly we end up with, I am in favor both of exception
message guidelines, and of a common Boost error base class providing
reasonable functionality.

-Steve
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: Re:Re:reinterpret_cast&>[wasRe:const-correctnessas functionargument]

[Eric Woodruff]

"Rob Stewart" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> From: "Eric Woodruff" <[EMAIL PROTECTED]>
> >
> > Every reference I can find excludes pointer conversions from being
> > implementation defined. They all (even the standard) specifically treat
> > pointer conversions differently (clause 7) than
pointer->integer->pointer
> > conversions. This is because creating an integer requires mapping the
bits
> > to a temporary, converting pointers does not require this because
pointers
> > share the same underlying representation, and it is done in compile time
so
> > there is no possibility of translation occuring.
> >
> > "reinterpret_cast treats all pointers exactly as traditional
type-casting
> > operators do. "
[snip]

> So, 5.2.10/7 plainly states that there's only one thing you can
> do portably with reintrepret_cast on pointers: convert from one
> type to another and back again.  Everything else is unspecified,
> so you can't even count on finding the result documented on each
> platform of interest.  This means that your references and
> understanding are wrong if they lead you to conclude that one-way
> pointer conversions are anything other than unspecified.
>
[snip]

The context surrounding converting a pointer "back again" is kind of
subjective. In the context of this original discussion, it was in converting
a pointer of an object to a char const* const for use with serialization.
This data is eventually deserialized and, thus, converted "back again."

In that context, do you find it to be unspecified? In my opinion, as long as
the bit representation remains the same [as in, the character bits are not
fiddled with during the time they are archived], it falls under the category
of converting a pointer to another pointer and then to the original type.




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] ublas regression test problems

[Beman Dawes]

At 01:32 PM 11/20/2002, Toon Knapen wrote:

>On Wednesday 20 November 2002 06:35, Aleksey Gurtovoy wrote:
>> > P.S.: Why aren't there any regression tests for mpl?
>>
>> There are, they just not included into the batch. Probably they should
>be;
>> there are some issues, mainly with the number of tests (currently ~60 
and
>> more to come) - simply putting those into results table would render it
>> rather useless, IMO, and the corresponding increase in compile times
>might
>> also be a problem (for the tests runners). In any case, I almost never
>> checking in anything before the regressions passed.
>
>Some have mentioned multiple times that the regression-test batch should 
not
>
>take too long to compile. I don't share this opinion. The more tests, the 

>better and as long as the tests can be compiled in less then one night I
>don't see a problem. For the status pages we (should) just have a cronjob 

>that starts in the evening.
>
>As for reporting it's more difficult. Although Beman probably saw this 
one
>coming and thus provided functionality to make a status page that only
>reports the failed tests (as reported seperatly for windows 2K and vacpp)

I'm working on finishing the Filesystem library right now, as a 
prerequisite to upgrading the regression testing mechanisms, including 
figuring out how to handling every larger numbers of tests.

I'll ask for testing suggestions once the Filesystem work is done.

--Beman


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] ublas regression test problems

[Beman Dawes]

At 06:35 AM 11/20/2002, Aleksey Gurtovoy wrote:


>> because ublas doesn't depend from mpl. So I've to assume,
>> that somebody is changing either boost.config, boost.type_traits,
>> boost.smart_ptr or boost.timer.
>
>Hmm, compiles fine for me on the clean CVS get (ignoring "test31/32.cpp"
>errors, see the attached log). Are you sure you are in sync with the main
>trunk?

I've just cleared off all old Win32 test bin directories, in case testing 
artifacts are causing those failures.  Running the tests now, but they take 
several hours when starting from scratch, so it will be awhile before they 
are posted.

--Beman 


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] [MPL] Several Questions

[David A. Greene]

Aleksey Gurtovoy wrote:

there any way, short of specialization, to determine whether
the parameter is a sequence?  

"is_sequence::value", please expect it to appear in the CVS in a day or
two :).


Oh, fabulous!  Just what I ws looking for.


Given 'is_sequence', it will be as simple as this:

template< typename T >
struct as_sequence
: if_< is_sequence, T, single_view >
{
};


Yep, that's what I had in mind.  But what is single_view and
what advantage does it have over mpl::vector?


Actually, as the comments say, that is a default implementation. You can
override it in two ways - (partially) specialize the primary 'begin/end'
templates, or specialize 'begin_trait/end_trait' on a sequence tag to
implement something like this:

struct my_sequence_tag;

struct first {
typedef my_sequence_tag;
typedef second type;
};

struct second {
typedef my_sequence_tag;
typedef third type;
};

struct third {
typedef my_sequence_tag;
typedef boost::mpl::void_ type;
};


Ok, but what if I don't want to alter first, second and third?
That is, I have some set of classes that define types like this
but they were never originally intended to represent a sequence.
It just happens that I want to maipulate a set of these types
formed by the typedef members they define.  See what I'm getting
at?  Previously I used template recursion and specialization
to do this but I want to follow the MPL Way(tm). :)


template<>
struct begin_traits
{
template< typename Sequence > struct algorithm
{
typedef my_iterator type;
};
};

template< typename Tag >
struct end_traits
{
template< typename Sequence > struct algorithm
{
typedef my_iterator type;
};
};

Would it cover your needs?


Mostly, except as I said I don't want to alter the classes if I
don't have to.


I thought about designing some kind of wrapper that could
be used in specialization:

template
struct intrusive_list {
  typedef Node::type type;
};

Then I could partially specialize begin<>/end<> on
intrusive_list.  Is this a reasonable approach?  

It is, at least from the technical standpoint - 'begin/end' /
'begin_trait/end_trait' templates were intended to be specialized; I would
need some user-level examples of intended usage for the whole thing to be
able to judge if there is a better way here.


Let me try out some ideas and I'll see what I find.


Here's one final puzzle: I have two type vectors that
I'd like to merge into one.  The trick is that I want
to eliminate all duplicates.  Since types cannot be
ordered (how does one define a less-than operation?)


This one might be solvable (a challenge! :), but I don't have a solution
right now.


Well, to accomplish the task below, I really just need to group
identical types together.  Then I can just use mpl::unique
to remove the duplicates.  So I don't need a full sort, but that's
the obvious solution if it's available.


it seems that type vectors cannot be easily sorted.
Thus to do a concat/copy while eliminating duplicates
would seem to be a very expensive task (search for
each candidate in the built-up list before adding it).
Any ideas here?  I know I'm missing something important.


Well, it's not an easy one :). For now, I would suggest you to go with the
algorithm you've outlined above and see if the performance is a showstopper.
I am sure we'll figure something out, it just needs some amount of thought
that I am not able to dedicate to it at the moment. Thoughts are welcome!


The above algorithm is certainly fairly easy to write.  I'm just
concerned about compile time.  I'll do some investigating and
hard thinking about this puzzle.

Thanks for your help, Aleksey, it's very much appreciated.

-Dave

--

"Some little people have music in them, but Fats, he was all music,
 and you know how big he was."  --  James P. Johnson

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Re:Re:reinterpret_cast&>[wasRe:const-correctnessas functionargument]

[Rob Stewart]

From: "Eric Woodruff" <[EMAIL PROTECTED]>
> 
> Every reference I can find excludes pointer conversions from being
> implementation defined. They all (even the standard) specifically treat
> pointer conversions differently (clause 7) than pointer->integer->pointer
> conversions. This is because creating an integer requires mapping the bits
> to a temporary, converting pointers does not require this because pointers
> share the same underlying representation, and it is done in compile time so
> there is no possibility of translation occuring.
> 
> "reinterpret_cast treats all pointers exactly as traditional type-casting
> operators do. "

Let me outline what I see in the standard.  Perhaps I can clarify
the matter for you and others, late to the debate though I may be.

5.2.10/1 says only the conversions listed in the following
paragraphs are permissible with reinterpret_cast.  IOW, if it
isn't explicity stated, it isn't allowed.

Paragraph 2 states that you cannot cast away constness.

Paragraph 3 states unequivocally that the mappings are
implementation-defined.

Paragraph 7 states that you can use reinterpret_cast to cast from
one pointer type to another.  It also states that you can convert
from one pointer type to another and back again, yielding the
original pointer value.  Finally, it states that all other
pointer conversions, which includes the conversion from one type
to another (but not back again) is unspecified.  IOW, the only
thing you can do with reinterpret_cast on pointers that is
portable is cast from one pointer type to another and back again.

For reference, 1.3.5 states that "implementation-defined" means
that what you get is entirely up to the implementation and that
the only obligation on the implementor is to document what
happens.

Likewise, 1.3.13 states that "unspecified behavior" means that
what you get is entirely up to the implementation and the
implementor doesn't even need to document what happens.

So, 5.2.10/7 plainly states that there's only one thing you can
do portably with reintrepret_cast on pointers: convert from one
type to another and back again.  Everything else is unspecified,
so you can't even count on finding the result documented on each
platform of interest.  This means that your references and
understanding are wrong if they lead you to conclude that one-way
pointer conversions are anything other than unspecified.

now-removing-my-language-lawyer-interpreter's-hat-ly y'rs,

Rob

-- 
Rob Stewart   [EMAIL PROTECTED]
Software Engineer http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Check digits

[Paul A. Bristow]

Driven by an local requirement, I have recently coded a Verhoeff decimal check
digit program,

based on the Java calculator embedded in
http://www.augustana.ab.ca/~mohrj/algorithms/checkdigit.html
by Jonathon Mohr, [EMAIL PROTECTED]
Augustana University College, 4901 - 46 Ave., Camrose, AB T4V 2R3 Canada

For example, if you have a decimal number 1357, the Verhoeff check digit is 3
and if you enter the complete number 13573 incorrectly nearly all human errors,
like transposition, will be detected.

(But I note that this appears to give different results to the one in Numeric
Recipes in C++ - someone wrote about this on Boost recently - which references
the same sources, mainly Neal AR Wagner and Paul S Putter, Comm of the ACM,
32(1) 106 to 110, and the original but difficult to obtain paper by J M
Verhoeff).

This is by far the best human error detecting check digit scheme and would seem
to be a good candidate for a Boost library (though ISBN, credit card and US EFT
schemes could also be made available though they are not recommended for new
applications).

Two questions:

1  Is there any interest in these schemes?  Which?

2  It would be valuable to generalise this to other more compact number systems,
for example ones based on 16 (familiar Hexadecimal) and 32 (letters and
numbers).

(I have recently opened a bank account with a 13 decimal digit identifier! This
could be as little as 5 with a 32 character letters and numbers scheme.)

The Deutsche Bundesbank bank notes are numbered using letters as well as numbers
and use a extended Verhoeff check digit scheme.  Does anyone have any details,
especially programs, showing how this works?  Or does anyone know of other
extensions to other number & letter schemes?

Thanks

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
+44 1539 561830   Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]


Numerical Recipes in C++, p 904 - 905W H Press, S A Teukolsky, W T Vettering, B
P Flannery, ISBN 0 521 75033 4.

SNOMED® Clinical Terms (First Release Technical Reference Manual
First Release (January 2002), Annex B. Check-digit computation, p 30 to 34
http://www.snomed.org/Spanish%20Documents/SNOMEDCT_Core_Technical%20Reference%20
Manual_US.pdf
uses Jonathan Mohr Javascript checkdigit.htm (copy in checkdigit.txt)
based on code at http://www.augustana. ab.ca/~mohrj/algorithms/checkdigit.html

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 'function' idea

[Douglas Gregor]

On Wednesday 20 November 2002 01:38 pm, Paul Mensonides wrote:
> > I don't think it's quite so clear-cut, because we have to define what you
>
> mean
>
> > by "nonsense", and I'm not sure you'll find agreement. The committee
> > chose one view of nonsense: trying to form any type that isn't a C++ type
> > (e.g., typename int::foo) is nonsense, so deduction fails.
>
> This isn't what that section means however.  It is only a list a few cases
> of "trying to form any type that isn't a C++ type."

... but I've stated what was the intent of the committee (according to my 
recollection from talking with Daveed); that is, to fail when one tries to 
form a type that isn't a C++ type. Do you have any specific cases they have 
missed? If so, then there is a defect and we should report it. Note that 
sizeof()-based cases (that rely on semantic checks) don't apply, because they 
aren't based on forming new types and should cause a real error (not template 
argument deduction failure).

> I'm talking about the strict interpretation of the standard (14.8.3)--not
> what current compilers do.  Type deduction happens *before* overload
> resolution--i.e. in the process or building a candidate set.  The template
> function just has to be visible.  So, in order for the function to "never
> make it into the overload set," it has to fail type deduction (i.e. not
> pass and _not_ error).

There's a _huge_ miscommunication here. I'm talking about your proposed 
resolution, and assuming that we adopt the rule "template argument deduction 
fails if the result is a semantically invalid declaration". One can then 
write a function template whose declaration will _always_ be ill-formed, so 
it will never succeed at template argument deduction. How will the user get 
an error when trying to call this function? (Answer: use a C++98 compiler, 
which will emit an error on any attempt to instantiate the function template 
declaration).

The issue I have is that your resolution may make it easier to write code that 
"compiles", but only because the definition is never actually instantiated. 
And when it's easier to write bad code that the compiler won't catch, it's 
harder to learn the language. 

> > Also note that this change is a huge problem for backward compatibility.
>
> That
>
> > badly broken function template from above is silently useless on C++0x,
>
> but
>
> > step back to C++98/C++02 and its going to fail.
>
> This isn't a case of a "badly broken function template," nor is a case of
> it being "silently useless."  It can be a perfectly worthwhile function
> template. 

Do you have a concrete example? This would help us greatly.
 
> This change would do several things,
> 1) cleanup that section of the standard,

"Cleanup" is not a good word to use when we're talking about a change in 
semantics. Cleanup can refer to adding missing cases, introducing rationale, 
or tighening up the wording in accordance with the intent of the section.

> 2) unify the rules with
> declaration instantiation ala member functions,

I'm not sure what you mean by this.

> 3) give us a huge set of tools to work with for generic programming, and

If we're going to be changing semantics, why not introduce new tools that 
support our goals better? 

> 4) close a potentially
> serious hole in the C++ overload mechanism.  What this change *wouldn't* do
> is alter the results on overload resolution in any way, nor would it allow
> more functions into the candidate set.

I don't understand this at all. Where is the hole in the C++ overload 
mechanism? We're only talking about template argument deduction, which is not 
overloading.

> > ... but don't forget that once we get more language primitives, that will
> > enable new tricks as well.
>
> Yes.  My point is that whatever gets added to 0x is not going to solve all
> of our needs.  We should never throw away worthwhile tools--even if some of
> them make us bend over backward to accomplish something (i.e. the sizeof
> hack).
>
> Paul Mensonides

We don't have this tool now, so there is nothing to throw away. 

Doug

[This is getting way off-topic for Boost. We should take this off-line or over 
to clc++m)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Serialization Library Review (pointer serializationfacility)

[Alberto Barbati]

Matthias Troyer wrote:


On Monday, November 18, 2002, at 02:30 PM, Yitzhak Sapir wrote:


I think taking out the pointer facility into a separate class would be 
better design.  By this I mean, that register_type<> and the logic for 
identifying and maintaining pointers would be in a separate class from 
the archive.  The archive would hold an instance of this class (given 
in the constructor), and use member functions of this container class 
to determine what to do when it encounters a new pointer/alias.  But 
it seems to me this is not the case yet (again, correct me if I'm wrong).


I want to second that vote. I would prefer a separate facility for 
pointer serialization, as an add-on to a serialization library if that 
is possible. Robert, what do you think, could it be separated out?

I already proposed a similar facility (under the unfortunate name of 
"registry") in a few previous posts of mine. Yitzhak Sapir has expressed 
my idea with much better words, so you may count my vote for it, too.

Alberto Barbati



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[Fernando Cacciola]

- Original Message -
From: "Beman Dawes" <[EMAIL PROTECTED]>
To: "Boost mailing list" <[EMAIL PROTECTED]>; "Boost mailing list"
<[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 3:43 PM
Subject: Re: [boost] Do we need a boost_exception class or idiom?


> At 01:20 PM 11/20/2002, Fernando Cacciola wrote:
>
>  >I'm not sure if a boost exception class is *needed*, but I see no
problem
>
>  >in
>  >having one.
>  >Anyway, IIF such an exception class is defined, I *strongly* encourage
> (as
>  >I
>  >did in the past) that it provides:
>  >
>  >  virtual void raise() const
>  >  {
>  >#ifndef BOOST_NO_EXCEPTIONS
>  >  throw *this ;
>  >#endif
>
> My naive expectation would be to call abort() if not wishing to handle
> exceptions,
I agree... I just omitted the #else part :-)

> but that really is a side issue. The bigger issue is whether or
> not Boost should have a usual way of defining error exceptions thrown by
> Boost libraries, with raise() being one of the issues to be dealt with.
>
> [snipped]
>
>I'm not sure if what we need is a class, a concept, or just some
>documentation.

Me neither... And I agree we should explore the big picture first.


I can start with the rationale behind 'raise()', at least, which shows that
it is not about 'raise' itself, specifically, but about encapsulation.

The common idiom:

   if ( error )
 throw some_exception("");

is not sufficiently encapsulated for library-code.
The problems are:
  (1) is disseminated along tons of code.
  (2) a throw expression is typically complex in terms of machine code, so
it usually spoils inlining.
  (3) has no application-level control

Error handling is one of the most typical library aspects that applications
need to customize.
I've turned down otherwise excellent libraries just because they have fixed
(even if very good for a specific context) error handling.

So, my first conclusion is that as a minimum, users will benefit if we
encapsulate error handling in ways that users can hook into.

BOOST_ASSERT, is IMO, starting off in the right direction in this respect.

Perhaps some sort of BOOST_ERROR macro which encapsulates a concept in a way
similar to BOOST_ASSERT might also work.

Fernando Cacciola

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[William E. Kempf]

Fernando Cacciola said:
> I'm not sure if a boost exception class is *needed*, but I see no
> problem in having one.
> Anyway, IIF such an exception class is defined, I *strongly* encourage
> (as I did in the past) that it provides:
>
>   virtual void raise() const
>   {
> #ifndef BOOST_NO_EXCEPTIONS
>   throw *this ;
> #endif
>   }
>
> and that boost libraries throw such exceptions *only* by calling
> .raise(): i.e. never with a throw expression directly in the user code.

template 
void raise()
{
#ifndef BOOST_NO_EXCEPTIONS
   throw T();
#endif
}

template 
void raise(const P1& p1)
{
#ifndef BOOST_NO_EXCEPTIONS
   throw T(p1);
#endif
}

// other such overloads if needed

void foo()
{
   raise("my logic error");
}

Is this not better?  It works even with the standard exception types, no
modification to the implementation.  Not a 100% solution for what you
want, since there's still exceptions that can be raised outside of Boost
code, but maybe it's enough.

I dislike the standard exception what(), since (with most of the exception
types) this requires dynamic allocation of the string, which may change
the type of exception thrown, and the string isn't language neutral.  I'd
prefer a what() that returned a key which never had to be allocated, and
possibly could be used to index into a catalog of language neutral strings
for output.  Maybe type_info::name() would be enough for a human readable
string, but there's two issues with this: it doesn't carry any extra data
(for example, an invalid_argument exception could indicate which argument
was invalid) and it's not easily used to index into language neutral
strings.  But if there's anything a boost_exception base type should do,
it's address the what() issues.

William E. Kempf



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: Serialization to relational table

[Bohdan]

"Vladimir Prus" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Bohdan wrote:
> I'm not a database expert, so my knowledge may be just rusty. However, I never
> heard about composite types in relational tables, and never seen anything like
> that in MySQL. Looking at MySQL docs right now, I indeed see no mention of
> composite types. Could you clarify, preferably with concrete SQL syntax.

  You are right MySql isn't too feature-reach sql-server.
Mentioned features like nested-tables are rather extention than
norm for relational dabases. If you are interested in feature-reach sql-server
take a look at Oracle.

> Ah.. so here's example. The only problem with implementing this
> in the same way as for serialization, is that you'd need to
> define database structure before serializing. It's quite possible,
> if the 'reflection' layer is designed to support this use case.

i'n not sure if some general database structure is possible
in case of Robert serialization lib. User writes hes own
functions and he can write very cumbersome and unsymmetric
code (store/load). In my proposal serialization (or better ORM ) will be
completely symmetric and you can write something like descriptor object
responcible for particular class mapping. Most probably it will be limited
comared to boost::serialization library but clean and multipurpose.

Well ... there was no positive answer yet. Most probably "structured streams"
and ORM is poor idea or just wrong thing for boost.

regards,
bohdan







___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Do we need a boost_exception class or idiom?

[Gennaro Prota]

On Wed, 20 Nov 2002 08:53:21 -0500, Beman Dawes <[EMAIL PROTECTED]>
wrote:

>Boost libraries often define exception classes, usually derived from the 
>standard library exception hierarchy.  Users sometimes ask for further 
>refinement, so the library ends up with its own hierarchy.
>
>For example, the Filesystem library started out with 
>boost::filesystem::filesystem_error, but reviewers asked for more specific 
>exceptions at least for the most common errors (like "file not found".)

I'm surprised that the filesystem library uses exceptions for that. I
used to think the consensus among experts was to use a return value,
and complain about the Java library that does otherwise :-)

[...]
>Has anyone run into a comprehensive attack on these and similar exception 
>class problems? Is there a better way than each Boost developer just 
>hacking together individual exception classes? Could we do better with a 
>Boost exception class or idiom?

For what my opinion is worth, I'm a little unwilling to have a
boost_exception base class, for the simple reason that conceptually
speaking it is not a part of the exception hierarchy. In other words
the fact that, say, bad_year is defined in the boost library shouldn't
affect its base type; the class should be coded the same way
regardless of the library it belongs to. Anyhow, I would accept the
compromise if it brings other important advantages.

Genny.


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Re: Re: Re: STL applied to disk

[Bohdan]

"David Abrahams" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> "Bohdan" <[EMAIL PROTECTED]> writes:
>
> > Do you mean that *i returns proxy (not object or reference) ?
> > Can you give some link where i can find rationale for this ?
>
> A rationale? No, "them's the rules". The reasons why don't matter much
> do they?

I see, but i mean reationale for "why iterators dereferenced to proxy are
non-standart."

regards,
bohdan




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[Beman Dawes]

At 01:20 PM 11/20/2002, Fernando Cacciola wrote:

>I'm not sure if a boost exception class is *needed*, but I see no problem 

>in
>having one.
>Anyway, IIF such an exception class is defined, I *strongly* encourage 
(as
>I
>did in the past) that it provides:
>
>  virtual void raise() const
>  {
>#ifndef BOOST_NO_EXCEPTIONS
>  throw *this ;
>#endif

My naive expectation would be to call abort() if not wishing to handle 
exceptions, but that really is a side issue. The bigger issue is whether or 
not Boost should have a usual way of defining error exceptions thrown by 
Boost libraries, with raise() being one of the issues to be dealt with.

>  }
>
>and that boost libraries throw such exceptions *only* by calling 
.raise():
>i.e. never with a throw expression directly in the user code.

I'm not sure if what we need is a class, a concept, or just some 
documentation.

But it does seem that individual Boosters have figured out (presumably 
better) ways to handle some aspects of reporting error exceptions. Would 
anyone be interested in trying to refine that vague feeling into something 
specific?

--Beman


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 'function' idea

[Paul Mensonides]

- Original Message -
From: "Douglas Gregor" <[EMAIL PROTECTED]>


> On Tuesday 19 November 2002 04:44 pm, Paul Mensonides wrote:
> > Clever type traits are one thing, but they are a side-effect of the
> > solution to a more general problem.  Specifically, one template function
> > declaration can permanently break an overload set--even if it is not
> > selected.  The solution to this is obvious, if type deduction yields
> > nonsense, it should fail.  It just so happens that we could exploit that
> > solution in significant ways with traits and expression validity
checking.
>
> I don't think it's quite so clear-cut, because we have to define what you
mean
> by "nonsense", and I'm not sure you'll find agreement. The committee chose
> one view of nonsense: trying to form any type that isn't a C++ type (e.g.,
> typename int::foo) is nonsense, so deduction fails.

This isn't what that section means however.  It is only a list a few cases
of "trying to form any type that isn't a C++ type."

> But we're talking about a
> whole new dimension of nonsense, where we want it to say "anything that
can't
> compile is nonsense".

More or less, yes.  Anything that is not semantically valid causes type
deduction failure.

> I have to wonder if this makes the problem you
> cite---that one function template declaration can permanently break an
> overload set---even worse. We're not talking about one brilliantly-written
> function template declaration, we're talking about one that is poorly
written
> because it is too general. It's an error that should be corrected, but the
> user won't ever actually see this error because the function template will
> never make it into the overload set.

I'm talking about the strict interpretation of the standard (14.8.3)--not
what current compilers do.  Type deduction happens *before* overload
resolution--i.e. in the process or building a candidate set.  The template
function just has to be visible.  So, in order for the function to "never
make it into the overload set," it has to fail type deduction (i.e. not pass
and _not_ error).

template class x { };
template class y { };

template void f( x* );
template void f( y* x, y* y );

f(0, 0) // error

struct z { };

template void g( T z::*, int );
template void g( int ... );

g(0, 0) // error

> Also note that this change is a huge problem for backward compatibility.
That
> badly broken function template from above is silently useless on C++0x,
but
> step back to C++98/C++02 and its going to fail.

This isn't a case of a "badly broken function template," nor is a case of it
being "silently useless."  It can be a perfectly worthwhile function
template.  All that has to happen is its declaration cannot be instantiated
with a certain template arguments, where doing so does not match one of the
listed criteria for type deduction failure in 14.8.2.  Remember, this
happens *before* overload resolution, so it happens with every function
template that is in scope every time a call is made to a function with that
name.  A given template function can *not* be selected in only two ways--1)
it fails type deduction which causes it to be invisible to overload
resolution, or 2) it passes type deduction but is not selected by regular
overload resolution.

As far as compatibility goes, this is a non-issue.  What once was an error
would now be allowed (0x).  That is not the same thing as something that
*was* allowed and later was an error.  This change would do several things,
1) cleanup that section of the standard, 2) unify the rules with declaration
instantiation ala member functions, 3) give us a huge set of tools to work
with for generic programming, and 4) close a potentially serious hole in the
C++ overload mechanism.  What this change *wouldn't* do is alter the results
on overload resolution in any way, nor would it allow more functions into
the candidate set.  The *only* change would be that functions would be
removed automatically if declaration instantiation makes no sense.  This is
just professional-quality design here, folks.  As it is now, it is only
half-designed.

Furthermore, defining "nonsense" in the context which I use it is not
difficult.  If type deduction yields a function declaration that would be
invalid if directly used in the source, then type deduction fails.
Obviously, it can be worded better than that, but you get the idea.

> > *why* something is invalid in the general sense.  Also, the "sizeof"
trick
> > is open-ended.  Any possible future language primitives will only give
us a
> > few of the things we need, and we'll still have to do the rest anyway.
> >
> > Paul Mensonides
>
> ... but don't forget that once we get more language primitives, that will
> enable new tricks as well.

Yes.  My point is that whatever gets added to 0x is not going to solve all
of our needs.  We should never throw away worthwhile tools--even if some of
them make us bend over backward to accomplish something (i.e. the sizeof
hack).

Paul Menson

[boost] Re: Possible boost addition: sub string and const s tring.

[Alexei Novakov]

"Vincent Finn" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Forwarded to main Boost list - that's the more appropriate venue for
> discussions of possible additions.
>
> -- Jim Hyslop boost-users moderator.
>
>  > -Original Message-
>  > From: alexei_novakov [mailto:[EMAIL PROTECTED]]
>  > Sent: Monday, November 18, 2002 7:05 PM
>  > To: [EMAIL PROTECTED]
>  > Subject: [Boost-Users] Possible boost addition: sub string and const
>  > string.
>  >
>  >
>  > Hello everyone.
>  >
>  > I have two classes which I found pretty handy: sub_string (behaves as
>  > a mirror of the portion of master basic_string) and const_string (C-
>  > string wrapper). Nice thing about these two is they implemented as
>  > template specialization of basic_string which has advantages:
>  > a) familiar interface;
>  > b) possibility to reuse the code written for basic_string (like
>  > string streams, lexical casts, etc).
>  >
>  > Any interest?
>  >
>  > Regards.
>  >
>  > Alexei Novakov
>
> Sounds interesting, like slice on a valarray
>
> When I have to do a lot of manipulation of sub string and can't afford
> to copy back and forward I normally resort to using vector; this
> sounds a lot handier
>
> How does it work ?
>
> Vin
>

The idea is simple. Sub string is declared as basic_string template
specialization:

template 
class basic_string >

The interfase is the same as for basic_string (except constructors). Sub
string instances contain reference to master string and boundaries (start
and size). One can use it like this:

// Start
typedef basic_string
sub_string;

string str("1234567890");
sub_string ss(str, 2, 5); // master string, start position, size

assert(lexical_cast(ss) == 34567);

ss = "$$";

assert(str == "12$$890");
// End

All the basic_string operators (like +, ==, !=, <, >, <=, >=) are overloaded
to be used for both strings and sub strings.

Similar approach is used for const_string (C string wrapper), but only const
methods of basic_string are implemented.

Alexei.




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Do we need a boost_exception class or idiom?

[Fernando Cacciola]

I'm not sure if a boost exception class is *needed*, but I see no problem in
having one.
Anyway, IIF such an exception class is defined, I *strongly* encourage (as I
did in the past) that it provides:

  virtual void raise() const
  {
#ifndef BOOST_NO_EXCEPTIONS
  throw *this ;
#endif
  }

and that boost libraries throw such exceptions *only* by calling .raise():
i.e. never with a throw expression directly in the user code.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Do we need a boost_exception class or idiom?

[Beman Dawes]

Boost libraries often define exception classes, usually derived from the 
standard library exception hierarchy.  Users sometimes ask for further 
refinement, so the library ends up with its own hierarchy.

For example, the Filesystem library started out with 
boost::filesystem::filesystem_error, but reviewers asked for more specific 
exceptions at least for the most common errors (like "file not found".) The 
suggested plan was to add one or two derived error types now, and more as 
experience dictates.

That works well for callers who know exactly what exception types will be 
thrown, but also implies that libraries like Boost.Test which try to catch 
specific exception types (for better error reporting) have to be 
continually updated to reflect new boost exceptions being added. An 
exception class which was self-explanatory would be better for these uses. 
I try to cope with that need by a lengthy what() message.

In another thread, Peter Dimov has pointed out that providing a what() 
message that can be used as a key is helpful in internationalizing 
messages.

Has anyone run into a comprehensive attack on these and similar exception 
class problems? Is there a better way than each Boost developer just 
hacking together individual exception classes? Could we do better with a 
Boost exception class or idiom?

--Beman


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Serialization Library: review

[Robert Ramey]

From: "Gennadiy Rozental" <[EMAIL PROTECTED]>

Its clear you spend a lot of time on this.  Your attention to end perception of
detail is extraordinary.  Also your critisms are phrased in a way that
proposes and contrasts the alternative - a very useful feature.

So many of these I have no problem with - except maybe with the time
do actually do work.  Things like breaking up the stl.hpp, etc are
non-controversial.  A few of the bugs have already been fixed and
some are reported here for the first time.  These posts have long
convinced me that the documentation needs to be corrected and amplified in
certain aspects.

One thing interests me right away.  Is there anyway that void_cast.*
would be interesting as a separate boost object.  I don't have
much emotional capitol invested in this and would be happy
to split it off right away and/or replace with your own
implementation somewhere else in boost.  I have no idea
whether it has any utility outside of this context.

Generally I like this post very much. There are several things I will
disagree with but I will require more time to respond with attention
it deserves.

Robert Ramey


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] soureforge

[David Abrahams]

"Matt Hurd" <[EMAIL PROTECTED]> writes:

> 1.27 is the latest on sourcefourge.  Would pay to either remove it or put
> 1.29 up.

How much?  ;-) 

I removed 1.27



-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Boost License Issues

[Joel Young]

From: Andrew Koenig <[EMAIL PROTECTED]>
> an issue here--that all FSF wanted was to be able to put the work
> under GPL (which would also be impossible for a public-domain work).

The exact public domain work can't be copyrighted, however for all
practical purposes that is meaningless.  It can be derived from and that
derivation can be copyrighted.  That derived work can be rearranged with
no requirement to distinguish the new parts from the old parts.  Yes, if
someone is confident they can extract the original public domain code
from the derived work, they could, but without the original public
domain code to baseline against, how can they ever know they did it
right?  If they can't know they did it right, then they can't afford the
legal risk of doing it.

Joel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: String algorithm library

[Pavol Droba]

On Wed, Nov 20, 2002 at 04:34:21PM +0100, Gennaro Prota wrote:
> On Tue, 19 Nov 2002 19:37:51 +0100, Pavol Droba <[EMAIL PROTECTED]>
> wrote:
> 
> > isclassified was suggested by Genny Prota
> 
> My name in the file is a theft though. That's just a classic. My only
> contribution was the error of using the type ctype_base::mask for a
> template parameter :-)
> 

well for me you are the first one who showed it to me:) I can remove the remark,
if you don't like it. But I will definitely put you in the acknowledgements :)

Cheers,

Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] BOOST_CHECK_EQUAL() dangers

[David Abrahams]

Markus Schöpflin <[EMAIL PROTECTED]> writes:

> 1. Just document it. Not so good, IMHO.
>
> 2. Document the special case and add a check for NULL pointers before calling 
>strcmp().
>
> 3. Remove the special case alltogether. After all, I might want to
> check that the pointers are equal and not the string they point
> to. This might be the best solution, but breaks backward
> compatibility.

I vote for #3, strongly. It's too capricious and inconsistent
otherwise, and might make the check useless in generic code. The user
can always convert to std::string if he wants the other check.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: String algorithm library

[Gennaro Prota]

On Tue, 19 Nov 2002 19:37:51 +0100, Pavol Droba <[EMAIL PROTECTED]>
wrote:

> isclassified was suggested by Genny Prota

My name in the file is a theft though. That's just a classic. My only
contribution was the error of using the type ctype_base::mask for a
template parameter :-)

Genny.


___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Boost License Issues

[Andrew Koenig]

>> Keith Gorlen,
>> the author of the NIH (National Institutes of Health) class library,
>> told me once that his work, being a ``US Government work'' is in the
>> public domain and *cannot* be copyrighted or licensed.  That is,
>> *nothing* that anyone does with his work can legally prevent anyone
>> from copying it, so there is no meaningful way of licensing it.

Beman> If I understand correctly, what was being requested was that it
Beman> be possible to clearly associate each file with its legal
Beman> status. So in the case you mention, I guess they would want to
Beman> see a notice to the effect it was a "US Government work" and
Beman> that it was in the public domain.

No -- what the FSF wanted was for the author to assign the copyright
to the FSF, and Keith could not do that because once a work is in the
public domain, it is no longer possible for the FSF or anyone else
to copyright it.

I expect that someone may say that actual ownership by the FSF is not
an issue here--that all FSF wanted was to be able to put the work
under GPL (which would also be impossible for a public-domain work).
However, I'm quite sure that ownership is the issue, because the same
issue rears its head in

http://www.xemacs.org/About/XEmacsVsGNUemacs.html
-- 
Andrew Koenig, [EMAIL PROTECTED], http://www.research.att.com/info/ark
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Copy Constructible Concept

[Douglas Gregor]

On Saturday 16 November 2002 12:24 pm, Gennaro Prota wrote:
> Sorry for the late reply (it's just my timezone).
>
> You wrote:
> >I don't see the contradiction here. 5.2.10/7 says that you can cast from a
> > T pointer to a U pointer and back to a T pointer and get the original
> > pointer back.
>
> Unfortunately the standard is a great piece of work but fails
> miserably to support you when you want to "deduce" things that are not
> written explicitly there in plain English, especially when generic
> expressions like "it's the same as", "is equivalent to", etc. are
> used.

I would generally agree that such an informal style doesn't allow any 
deduction, but I think we have to be realistic. We don't have a formal 
specification for C++, and it's unlikely that we will ever have one. We won't 
get anywhere if we require formal methods with an informal specification.

> First of all the quotes:
>
>5.2.10/7: "A pointer to an object can be explicitly converted
>to a pointer to an object of different type.65) Except that
>converting an rvalue of type "pointer to T1" to the type
>"pointer to T2" (where T1 and T2 are object types and where
>the alignment requirements of T2 are no stricter than those
>of T1) and back to its original type yields the original pointer
>value, the result of such a pointer conversion is unspecified."
>
>
> Incidentally, what does "converting back" means? However that's not
> the main point.

Given T* tp, reinterpret_cast(reinterpret_cast(tp)) is semantically 
equivalent to tp.

>
>5.2.10/10: An lvalue expression of type T1 can be cast to the type
>"reference to T2" if an expression of type "pointer to T1" can be
>explicitly converted to the type "pointer to T2" using a
>reinterpret_cast. That is, a reference cast reinterpret_cast(x)
>has the same effect as the conversion *reinterpret_cast(&x)
>with the built-in & and * operators.
>
>
> What does it mean "has the same effect of"?

Would you prefer "is semantically equivalent to?" You can rewrite one 
expression as the other. (Not in actual C++ code, because you can't say "I 
want the built-in operator&", but it's fine for exploring the properties of 
an expression).

> 5.2.10/7 says that the
> result of reinterpret_cast(&x) is unspecified. What is the effect
> of dereferencing it?
>
> *reinterpret_cast(&x)

The effect is the same as dereferencing any pointer. You get the lvalue 
associated with the address stored in the pointer.

Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] [PATCH] Boost.Format: making it work without exceptions

[Bjorn . Karlsson]

> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> This patch makes the Boost.Format library work when exceptions is not
> present. It is done the same way as with the smart pointers.
> 

Applied, thanks!
Bjorn 
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] BOOST_CHECK_EQUAL() dangers

[Markus Schöpflin]

Hi,

the (really useful!) boost test library provides the test tool macro 
BOOST_CHECK_EQUAL() which checks two values for equality. I just learned 
the hard way that the following does not do what one would expect.

char const *p = 0;
BOOST_CHECK_EQUAL(p, p);

On my system, this results in a test program crash. The reason is, for 
this parameter type strcmp() is called which (of course) doesn't like 
NULL pointers as it's arguments.

This isn't documented anywhere in the test library documentation 
(neither the special treatment of char * nor the requirement that those 
must not be NULL) and I think it needs to be fixed. There are several 
possible ways.

1. Just document it. Not so good, IMHO.

2. Document the special case and add a check for NULL pointers before 
calling strcmp().

3. Remove the special case alltogether. After all, I might want to check 
that the pointers are equal and not the string they point to. This might 
be the best solution, but breaks backward compatibility.

Markus





___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Serialization Library: review

[Matthias Troyer]

On Wednesday, November 20, 2002, at 01:42 PM, Gennadiy Rozental wrote:


[Issue 3] Library seems to hardcode important part of functionality 
that
users may want to overwrite. Here I refer in most part to 
archive/object
preamble.


Major [Issue 3]: Submitted library is somewhat limited in a means to 
modify
what is written in archive header (I can change it but I will need to 
supply
full fledged specific archive cause currently this logic is in 
constructor).
And even more limited in a means to modify object header together with 
logic
bound to it. Let me give couple examples.

1. Serialization signature is 22 bytes. Let say I am serializing 
messages
into binary format for sending them through network. Size of my 
serialized
code is 10 bytes. I do not believe I could accept 22 bytes of 
"signature
information". The same about the version. I may or may not be 
interested in
versioning of serialization system.
2. Binary archive constructor save some "guard" information. I may or 
may
not want to do this. Or I may want to be even more careful.
3. Object save/load function contains pretty expensive logic for 
making sure
that object is stored/loaded only once. If for any reason 
(performance) I
could not afford constant searching but have external knowledge that 
all
objects are different I may want to skip lookup phase.
4. Let say I am sending data by contract.  It could be fixed contract 
in
external file loaded during initialization or dynamic one sent before
sending real data. The purpose id to save the bandwidth and eliminate 
all
object/class ids from serialized stream. What should I do?

After playing some more and trying to read my old "legacy" 
serialization files which do not contain any such preamble I want to 
support Gennadiy's point. I would like for my archive classes (e.g. to 
read legacy archive formats) to override these preambles.

Matthias

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] 'function' idea

[Douglas Gregor]

On Tuesday 19 November 2002 04:44 pm, Paul Mensonides wrote:
> Clever type traits are one thing, but they are a side-effect of the
> solution to a more general problem.  Specifically, one template function
> declaration can permanently break an overload set--even if it is not
> selected.  The solution to this is obvious, if type deduction yields
> nonsense, it should fail.  It just so happens that we could exploit that
> solution in significant ways with traits and expression validity checking.

I don't think it's quite so clear-cut, because we have to define what you mean 
by "nonsense", and I'm not sure you'll find agreement. The committee chose 
one view of nonsense: trying to form any type that isn't a C++ type (e.g., 
typename int::foo) is nonsense, so deduction fails. But we're talking about a 
whole new dimension of nonsense, where we want it to say "anything that can't 
compile is nonsense". I have to wonder if this makes the problem you 
cite---that one function template declaration can permanently break an 
overload set---even worse. We're not talking about one brilliantly-written 
function template declaration, we're talking about one that is poorly written 
because it is too general. It's an error that should be corrected, but the 
user won't ever actually see this error because the function template will 
never make it into the overload set. 

Also note that this change is a huge problem for backward compatibility. That 
badly broken function template from above is silently useless on C++0x, but 
step back to C++98/C++02 and its going to fail.

> *why* something is invalid in the general sense.  Also, the "sizeof" trick
> is open-ended.  Any possible future language primitives will only give us a
> few of the things we need, and we'll still have to do the rest anyway.
>
> Paul Mensonides

... but don't forget that once we get more language primitives, that will 
enable new tricks as well. 

Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] [PATCH] Boost.Format: making it work without exceptions

[Lars Gullik Bjønnes]

This patch makes the Boost.Format library work when exceptions is not
present. It is done the same way as with the smart pointers.

Please apply.


Index: boost/format/feed_args.hpp
===
RCS file: /cvsroot/boost/boost/boost/format/feed_args.hpp,v
retrieving revision 1.4
diff -u -p -r1.4 feed_args.hpp
--- boost/format/feed_args.hpp	10 Oct 2002 11:17:18 -	1.4
+++ boost/format/feed_args.hpp	20 Nov 2002 13:22:45 -
@@ -25,6 +25,7 @@
 #include "boost/format/group.hpp"
 
 #include "boost/format/msvc_disambiguater.hpp"
+#include "boost/throw_exception.hpp"
 
 namespace boost {
 namespace io {
@@ -221,7 +222,7 @@ void distribute(basic_format& sel
 if(self.cur_arg_ >= self.num_args_)
   {
 if( self.exceptions() & too_many_args_bit )
-  throw too_many_args(); // too many variables have been supplied !
+  boost::throw_exception(too_many_args()); // too many variables have been supplied !
 else return;
   }
 for(unsigned long i=0; i < self.items_.size(); ++i)
Index: boost/format/format_implementation.hpp
===
RCS file: /cvsroot/boost/boost/boost/format/format_implementation.hpp,v
retrieving revision 1.3
diff -u -p -r1.3 format_implementation.hpp
--- boost/format/format_implementation.hpp	10 Oct 2002 11:17:18 -	1.3
+++ boost/format/format_implementation.hpp	20 Nov 2002 13:22:46 -
@@ -23,6 +23,7 @@
 #include 
 
 #include "boost/format/format_class.hpp"
+#include "boost/throw_exception.hpp"
 
 namespace boost {
 
@@ -151,7 +152,7 @@ basic_format& basic_format
 if(argN<1 || argN > num_args_ || bound_.size()==0 || !bound_[argN-1] ) 
   {
 if( exceptions() & out_of_range_bit )
-  throw out_of_range(); // arg not in range.
+  boost::throw_exception(out_of_range()); // arg not in range.
 else return *this;
   }
 bound_[argN-1]=false;
@@ -169,7 +170,7 @@ std::basic_string basic_format&  bind_arg_body( ba
 if(argN<1 || argN > self.num_args_) 
   {
 if( self.exceptions() & out_of_range_bit )
-  throw out_of_range(); // arg not in range.
+  boost::throw_exception(out_of_range()); // arg not in range.
 else return self;
   }
 if(self.bound_.size()==0) 
@@ -246,7 +247,7 @@ basic_format&  modify_item_body(
   if(itemN<1 || itemN >= static_cast(self.items_.size() )) 
 {
   if( self.exceptions() & out_of_range_bit ) 
-throw out_of_range(); // item not in range.
+boost::throw_exception(out_of_range()); // item not in range.
   else return self;
 }
   self.items_[itemN-1].ref_state_.apply_manip( manipulator );
Index: boost/format/free_funcs.hpp
===
RCS file: /cvsroot/boost/boost/boost/format/free_funcs.hpp,v
retrieving revision 1.3
diff -u -p -r1.3 free_funcs.hpp
--- boost/format/free_funcs.hpp	10 Oct 2002 11:17:18 -	1.3
+++ boost/format/free_funcs.hpp	20 Nov 2002 13:22:46 -
@@ -20,6 +20,7 @@
 #define BOOST_FORMAT_FUNCS_HPP
 
 #include "boost/format/format_class.hpp"
+#include "boost/throw_exception.hpp"
 
 namespace boost {
 
@@ -44,7 +45,7 @@ operator<<( BOOST_IO_STD basic_ostream ::parse(co
 {
   if( i1+1 >= buf.size() ) {
 if(exceptions() & io::bad_format_string_bit)
-  throw io::bad_format_string(); // must not end in "bla bla %"
+  boost::throw_exception(io::bad_format_string()); // must not end in "bla bla %"
 else break; // stop there, ignore last '%'
   }
   if(buf[i1+1] == buf[i1] ) { i1+=2; continue; } // escaped "%%" / "##"
@@ -421,7 +422,7 @@ void basic_format ::parse(co
   if(max_argN >= 0 )  // dont mix positional with non-positionnal directives
 {
   if(exceptions() & io::bad_format_string_bit)
-throw io::bad_format_string();
+boost::throw_exception(io::bad_format_string());
   // else do nothing. => positionnal arguments are processed as non-positionnal
 }
   // set things like it would have been with positional directives :


-- 
Lgb

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: lexical_cast and bool

[Vincent Finn]

Neal D. Becker wrote:

"Roland" == Roland Richter <[EMAIL PROTECTED]> writes:




Roland> Dear all,
Roland> just a minor issue for the upcoming(?) lexical_cast in 1.30.0:

Roland> lexical_cast( "true" ) returns false,
Roland> since std::ios::boolalpha is not set by default.

Roland> How about changing this?

I believe we need a mechanism to set all the flags, not just this one.


true
I have altered my copy of the file with boolalpha
but I always have to go back to the stream if I want to do hex
being able to set fill, precision etc... would be nice too

No simple generic way to do it that I could think of though :-(

	Vin





___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] shared_ptr deleter introspection?

[David Abrahams]

"Peter Dimov" <[EMAIL PROTECTED]> writes:

> From: "David Abrahams" <[EMAIL PROTECTED]>
>
> [get_deleter]
>
>> I think that considering the alternatives require:
>>
>>1. Periodic map sweeps (we might as well be doing GC ;->), or
>>
>>2. Solving the constructor forwarding problem for tacking on
>>   additional data to the pointed-to class
>>
>> IMO it's worth giving serious consideration to deleter
>> introspection.
>
> Looks like I have to apply my mad "diligent reader" skills to the above.
>
  
>
> Correct?

Yep, you got mad skills.

> Now the interface questions.
>
> Q: Why a free function? A: a member would require the p.template
> get_deleter() syntax when p is dependent on a template parameter.

That's one answer.  There's also p.get_deleter(type). Either one is
slightly ugly. But mostly I suggested a free function because it was
what came to mind.

> Q: Why use a generic 'get_deleter' name for the free function? A: ???

Heh. I suggest that it /not/ be intended for invocation via Koenig
Lookup, so the name would be OK.

There is another option, of course: make it a class template, like
boost::python::extract. Since introspection is a two-phase process
anyway, maybe that's better.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] [MPL] Several Questions

[Aleksey Gurtovoy]

David A. Greene wrote:
> I'm starting to explore mpl a bit and I ran into a roadblock.
> If I have a template that takes an argument that can be
> a sequence (e.g. mpl::vector) or a regular old type, is
> there any way, short of specialization, to determine whether
> the parameter is a sequence?  

"is_sequence::value", please expect it to appear in the CVS in a day or
two :).

> I'd like to avoid specializing the template based on mpl guts 
> that may change.  Alternatively, is there any way to manipulate 
> the parameter to guarantee that it is converted to a sequence (of 
> one element) if it is not a sequence?

Given 'is_sequence', it will be as simple as this:

template< typename T >
struct as_sequence
: if_< is_sequence, T, single_view >
{
};

> 
> Here's a second question.  Suppose I have a "chain" of types
> such that each type contains as a member the next type in the
> chain.  For example:
> 
> struct third;
> struct second;
> struct first;
> 
> struct first {
>typedef second type;
> };
> 
> struct second {
>typedef third type;
> };
> 
> struct third {
>typedef boost::mpl::void_ type;
> };
> 
> If I want to use this kind of intrusive sequence with mpl,
> how would I go about defining begin<> and end<>?  The headers
> use something called begin_traits and end_traits but they
> assume that the type passed is an mpl-style sequence that
> has begin and end members defined.

Actually, as the comments say, that is a default implementation. You can
override it in two ways - (partially) specialize the primary 'begin/end'
templates, or specialize 'begin_trait/end_trait' on a sequence tag to
implement something like this:

struct my_sequence_tag;

struct first {
typedef my_sequence_tag;
typedef second type;
};

struct second {
typedef my_sequence_tag;
typedef third type;
};

struct third {
typedef my_sequence_tag;
typedef boost::mpl::void_ type;
};


template<>
struct begin_traits
{
template< typename Sequence > struct algorithm
{
typedef my_iterator type;
};
};

template< typename Tag >
struct end_traits
{
template< typename Sequence > struct algorithm
{
typedef my_iterator type;
};
};

Would it cover your needs?

> 
> I thought about designing some kind of wrapper that could
> be used in specialization:
> 
> template
> struct intrusive_list {
>typedef Node::type type;
> };
> 
> Then I could partially specialize begin<>/end<> on
> intrusive_list.  Is this a reasonable approach?  

It is, at least from the technical standpoint - 'begin/end' /
'begin_trait/end_trait' templates were intended to be specialized; I would
need some user-level examples of intended usage for the whole thing to be
able to judge if there is a better way here.


> 
> Here's one final puzzle: I have two type vectors that
> I'd like to merge into one.  The trick is that I want
> to eliminate all duplicates.  Since types cannot be
> ordered (how does one define a less-than operation?)

This one might be solvable (a challenge! :), but I don't have a solution
right now.

> it seems that type vectors cannot be easily sorted.
> Thus to do a concat/copy while eliminating duplicates
> would seem to be a very expensive task (search for
> each candidate in the built-up list before adding it).
> Any ideas here?  I know I'm missing something important.

Well, it's not an easy one :). For now, I would suggest you to go with the
algorithm you've outlined above and see if the performance is a showstopper.
I am sure we'll figure something out, it just needs some amount of thought
that I am not able to dedicate to it at the moment. Thoughts are welcome!

> Great work by all on mpl -- I'm enjoying the exploration!

Thank you!

HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] lexical_cast and bool

[Neal D. Becker]

> "Roland" == Roland Richter <[EMAIL PROTECTED]> writes:

Roland> Dear all,
Roland> just a minor issue for the upcoming(?) lexical_cast in 1.30.0:

Roland> lexical_cast( "true" ) returns false,
Roland> since std::ios::boolalpha is not set by default.

Roland> How about changing this?

I believe we need a mechanism to set all the flags, not just this one.

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] RE: [Boost-Users] Possible boost addition: sub string and const string.

[Jim.Hyslop]

Forwarded to main Boost list - that's the more appropriate venue for
discussions of possible additions.

-- 
Jim Hyslop
boost-users moderator.

> -Original Message-
> From: alexei_novakov [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 18, 2002 7:05 PM
> To: [EMAIL PROTECTED]
> Subject: [Boost-Users] Possible boost addition: sub string and const
> string.
> 
> 
> Hello everyone.
> 
> I have two classes which I found pretty handy: sub_string (behaves as 
> a mirror of the portion of master basic_string) and const_string (C-
> string wrapper). Nice thing about these two is they implemented as 
> template specialization of basic_string which has advantages:
> a) familiar interface;
> b) possibility to reuse the code written for basic_string (like 
> string streams, lexical casts, etc).
> 
> Any interest?
> 
> Regards.
> 
> Alexei Novakov
> 
> 
> Info: 
> Wiki: 
> Unsubscribe: 
>  
> 
> Your use of Yahoo! Groups is subject to 
> http://docs.yahoo.com/info/terms/ 
> 
> 
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] installing Boost on HP-UX 10.20

[David Abrahams]

Toon Knapen <[EMAIL PROTECTED]> writes:

> (John, I would like to continue the discussion on the boost-ml since there 
> are some people with experience with boost on HPUX that will be able to 
> provide some more info, I'm not crosposting to jamboost since all jamboosters 
> are also boosters)

Check the man pages carefully. aCC has standards-conformance options
which are OFF by default.

-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: Object Factory

[David Abrahams]

Anthony Liguori <[EMAIL PROTECTED]> writes:

> David Abrahams wrote:
>
>>Now can we rename "factory" to "metaclass"? I just want to see smoke
>>come out of peoples' ears!
>>
> You know, this might be possible...  If we can find a way to map
> members to function objects somewhat automatically, 

Why does that matter?

> this might be realistic. After that, it's a simple sed script ;-)

sed...


-- 
   David Abrahams
   [EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] singlton library?

[Pavol Droba]

On Wed, Nov 20, 2002 at 01:42:47PM +0200, Yakov Bachmutsky wrote:
> Hi,
> 
> I've posted a proposal of a singleton library (among others) maybe a month
> ago and as far as I remember it was ignored so I post it again with its name
> as the subject, hoping this will help, and some explanations:
> 
> 1. I use singleton to have a singleton instance of a class in my
> apps.
> The obvious advantage in developement of large apps is that u don't have to
> remember the name of the 1 instance u create like g_myObj but only the
> class's name and thus always use it like this:
>   singleton p->method();
> 
> 2. In addition I use a singleton manager to have all singleton objects
> started at app start:
>   singleton_manager::startup()
> 
> 3. to use that I "register" classes to use the singleton class and manager
> class using a macro:
>   REGISTER_SINGLETON(myclass)
> 
> 4. classes can inherit the singleton class to get more specific behaviour
> like two stage construction.
> Every such inhariting class must have its own registration macro.
> 
> 5. In addition to all the above I suggest few more little thingies to
> support other singleton patterns, mostly in the form of macroes. There's
> also an article on this topic:
> http://www.beginthread.com/Article/yakov/Singleton Techniques/

I have done singleton stuff in a way many times. Could you please post some
code examples. I'd like to have a look.

Regards,

Pavol
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] shared_ptr deleter introspection?

[Peter Dimov]

From: "David Abrahams" <[EMAIL PROTECTED]>

[get_deleter]

> I think that considering the alternatives require:
>
>1. Periodic map sweeps (we might as well be doing GC ;->), or
>
>2. Solving the constructor forwarding problem for tacking on
>   additional data to the pointed-to class
>
> IMO it's worth giving serious consideration to deleter
> introspection.

Looks like I have to apply my mad "diligent reader" skills to the above.

Problem statement:

A library lib1 contains the following functions:

shared_ptr lib1::f();
lib1::g(shared_ptr p);

The library needs to communicate a piece of private data from f to g, i.e.
lib1::g needs to determine whether p has been created by lib1::f, and if so,
what is the private data associated with p.

Solution #1: put the private data in X.

lib1::f can return a shared_ptr that stores an instance of a class Ximpl,
derived from X, that contains the private data. lib1::g can use
dynamic_cast to detect the presence of private data.

Problem: if X is not defined by lib1, transparently wrapping it in a Ximpl
requires forwarding constructor arguments from Ximpl's constructors to X's
constructors (X may be noncopyable.)

Solution #2: use a map, Data>.

lib1::f can use the generated shared_ptr as a key to a global map,
storing the private data there. lib1::g can use p to find the associated
data in the map.

This solution is more general since it doesn't require lib1 to create the
shared_ptr itself. Even external shared_ptr instances can have associated
private data.

Problem: the map needs to be periodically swept to eliminate expired
weak_ptr keys.

Solution #3: use the two-argument shared_ptr constructor and put the private
data in the deleter.

Problem: given a shared_ptr, there is currently no way to obtain a reference
to the deleter, if there is one.

Correct?

Now the interface questions.

Q: Why a free function? A: a member would require the p.template
get_deleter() syntax when p is dependent on a template parameter.

Q: Why use a generic 'get_deleter' name for the free function? A: ???

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Serialization Library: review

[Gennadiy Rozental]

And here promised attachments
 
Gennadiy.
 


serialization.rar
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Serialization Library: review

[Gennadiy Rozental]

Hi,

After spending some time with library, looking through docs and code,
compiling it and comparing with my expectations I see following 5 major
issues with submitted library:

[Issue 1] Registration/reflection facility should be completely separated
from serialization implementation and became registration policy template
parameter

[Issue 2] Library should be subdivided into 2 *independent* library serving
purpose of serialization and deserialization.

[Issue 3] Library seems to hardcode important part of functionality that
users may want to overwrite. Here I refer in most part to archive/object
preamble.

[Issue 4] Presented solution for serialization of STL collections is
seriously flawed.

[Issue 5] Quality of code/implementation. I believe Boost should demonstrate
examples of solidly written code; requirement submitted library not always
comply to.

I was able to compile library and tests with MSVC6.5. test.cpp produce
couple runtime failures. See attached.

Now let take a look in more details:

Documentation
---

As it what mentioned by some other reviewers documentation is incomplete and
sometimes incorrect and most importantly missing very important topics.

Tutorial:
page 2: after // close archive you are closing ifs - should be ofs
page 3: in function load incorrect type of the second argument: int
file_version

Reference:
Section that is definitely missing is one describing in details (including
contract) how to write custom archives.

Operators for Pointers:
  const * T should be const T * (or T const* but this comment later)
  Why are you using "backward" logic while describing issues addressed
to properly save and restore pointers. Reader will read the document from
top to bottom and all these "must" "need" "have to be" are confusing.

Operators for Templates:
Operators you are describing in this section does not exist in  reality
and STL containers serialization is implemented using different means (even
for compiler that support [partial specialization it would not look like
what you described). IMO you confusing readers and simple incorrect.

Serialization of Classes:
code snippet at the end and one before using array "a" that never declared.

Serialization of templates:

Passage about "not working as expected" simply incorrect. It does world if
partial specialization is supported. Following example successfully compiled
and with both gcc and bcc32 I have access to:

#include 

template 
struct A{};

template
struct B {enum { value = 0 }; };

template 
struct B > { enum { value = 1 }; };

int main() {
   typedef A a_int;
   std::cout << B::value;
   std::cout << B::value;
}

In reality what should be discussed here is that library supports several
ways to specialize the serialization logic and user may choose any way he
prefer depends on it's preferences and used compiler. And BTW it's not
specific to the templates this 3-layer logic is used for *all" classes. What
I mean here (and it should be clear from docs that currently library is
using following 3 layer logic for overwriting serialization algorithm:

Layer 3: one could use partial ordering for specializing serialization for
type T by overloading function
void boost::serialization::sterilization_save( basic_oachive& ar, T&,
long );
by default it referee to the serialization::save(...)

Note that I moved it out of details into serialization namespace.
(BTW it was one of the reviewer requested - it's already in)

Layer 2: one could provide partial/full specialization of traits class
specialization
by default if refer to the T::save(...)

Layer 1: one could provide the function save(...) as member of type T
accessible for serialization

Moreover I think that it should be clearly specified that Layer 3 is
"temporary" and may be eliminated in a future so it is recommended to use
one of the layers 2 or 1.

Very large numbers of Small Objects:
In function serialization::save_ptr extra "(" near BOOST_STATIC
_ASSERT.
vector data? doesn't vector need any template parameters?
When you serializing the struct line it's unclear how you save/load vector
size

Exception safety:
First paragraph: "this problem" What problem? It should be clearly stated or
rephrased.
Each scenario you are describing should be accompanied by the simple but
clear example code.

"Other cases" refer to the altered shared_count.hpp which permits the
serialization of shared_ptr. Does this means that the things will stay as it
is users won't be able to serialize instances of shared_ptr? Whose fault is
it?

Serialization Implementation included in the library:
"This header is automatically included in any program..."
This is incorrect decision and docs will need to be fixed together with
code. See below.

Advice:
Should be called "Advises"

Working around ...
"... compiler will attempt to declare an instance of an abstract base class
as part of type traits package". Why? Where? could not you provide a
workaround yourself.

Rationale:

quiet - 

[boost] lexical_cast and bool

[Roland Richter]

Dear all,

just a minor issue for the upcoming(?) lexical_cast in 1.30.0:

lexical_cast( "true" ) returns false,
since std::ios::boolalpha is not set by default.

How about changing this?


- Roland



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] ublas regression test problems

[Toon Knapen]

On Wednesday 20 November 2002 06:35, Aleksey Gurtovoy wrote:
> > P.S.: Why aren't there any regression tests for mpl?
>
> There are, they just not included into the batch. Probably they should be;
> there are some issues, mainly with the number of tests (currently ~60 and
> more to come) - simply putting those into results table would render it
> rather useless, IMO, and the corresponding increase in compile times might
> also be a problem (for the tests runners). In any case, I almost never
> checking in anything before the regressions passed.

Some have mentioned multiple times that the regression-test batch should not 
take too long to compile. I don't share this opinion. The more tests, the 
better and as long as the tests can be compiled in less then one night I 
don't see a problem. For the status pages we (should) just have a cronjob 
that starts in the evening.

As for reporting it's more difficult. Although Beman probably saw this one 
coming and thus provided functionality to make a status page that only 
reports the failed tests (as reported seperatly for windows 2K and vacpp)

toon
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] ublas regression test problems

[jhr . walter]

Aleksey Gurtovoy wrote:
> Joerg Walter wrote:
> > I've recently committed a couple of bugfixes,
> extensions and 
> > compatibility hacks. The last regression tests seem to
> be OK 
> > for Linux, but some tests under Windows fail to
> compile. I'm 
> > especially concerned about VC7 failures with the
> diagnostic
> > 
> > concepts.cpp
> > C:\boost\site\boost\mpl\if.hpp(158) : error C2976: 
> > 'boost::mpl::if_' : too
> > few template arguments
> > C:\boost\site\boost\mpl\if.hpp(102) : see
> declaration of
> > 'boost::mpl::if_'
> > C:\boost\site\boost\mpl\if.hpp(158) : error C2504: 
> > '' : base class
> > undefined
> > 
> > because ublas doesn't depend from mpl. So I've to
> assume, 
> > that somebody is changing either boost.config,
> boost.type_traits, 
> > boost.smart_ptr or boost.timer.
> 
> Hmm, compiles fine for me on the clean CVS get (ignoring
> "test31/32.cpp"
> errors, see the attached log). Are you sure you are in
> sync with the main
> trunk?

Sorry for being unclear, I referred to the tests at
http://boost.sourceforge.net/regression-logs/cs-win32-full.html

I don't have MSVC 7.0 available.

[snip]

Thanks

Joerg
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: new initialization lib, any interest?

[Thorsten Ottosen]

- Original Message -
From: "Rob Stewart" <[EMAIL PROTECTED]>

> From: Thorsten Ottosen <[EMAIL PROTECTED]>
> > From: "Yitzhak Sapir" <[EMAIL PROTECTED]>
> > > On Wed, 9 Oct 2002, Thorsten Ottosen wrote:
> > >
> > > > The problem of missing a value in the assignment to
> > > > the map is hypothetical. If I wan't to map int to int, I can make
the
>
> No, it isn't hypothetical.  It is a reasonable situation to map
> from one numeric type to another, and to use integers for the
> initial values even when assigning to a floating point type.

It was hypothetical that the missing value should be a problem, not that
maps from 'int' to 'int' are.
If you fordot a value, an assertion will be triggered.

>
> > > > mapping just as clear by using newline or tabs:
> > > >
> > > > set_map( m ) += 1,22,33,45,6;
> > > > set_map( m ) += 1,2
> > > >2,3
> > > >   3,4;
>
> As you can see, tabs can be a problem.  At least in mailing
> lists! ;-)
>
> > > Given that you yourself did not do well in giving an example of
> > > separation with whitespace, I think this speaks strongly for a
pair-wise
> > > syntax.
>
> I agree.
[snip]
  Your point, if I understand you
> correctly, is that the compiler would have complained had you
> been able to actually attempt to compile the above with a more
> compliant compiler.

no, if I had compiled it at all. No compiler accepts white spaces in
identifiers.

>
> > > The parenthesis form is not that hard.  Add a space between the values
and
> > > the parenthesis, and the value isn't buried:
> > >
> > > init(m)( 1, 2 )( 2, 3 )( 3, 4 );
>
> I don't put spaces within parenthetical expressions, so I'm
> accustomed to code like this:
>
>init(m)(1, 2)(2, 3)(3, 4);
>
> I find that perfectly readable.

You could then also quickly be accustomed to code like m+= 1,2,  3,4; I
don't think
we're discussing anything that has to do with ambiguity, simple people's
personal preferences
for a certain syntax.  I think I mentioned in a mail that one could choose
to support
both syntaxes, but I'm not sure that is a good idea.

> > > In this case white space does enhance readability, but the syntax
> > > guarantees the user won't make a mistake.
>
> I find the spaces distracting, but since they are not required,
> but merely possible should your own sense of taste dictate them,
> I have no problem either way.

good. :-)

> > neither will he in the other case. ¨The concern is hypothetical and the
> > interface for map and eg vector will be different which is much worse
than
> > having both operator= and operator+=.
>
> The concern is not hypothetical.  If you have a
> std::map, you could easily initialize it with only
> "pairs" of integers, and the compiler will be happy to convert
> integers to doubles for you.  How can you find an error if the
> compiler doesn't flag it?  How will you learn that you transposed
> a 2 and a 3 in such a case?  It depends upon how that
> transposition affects the rest of your code.  It may be invisible
> in most circumstances.
My imagination is just not good enough, please show an example with both
syntaxes and pinpoint
where the error appears.

> Couldn't you use map-like notation:
>
>init(m)["ssdsd"] = Class(2, Cow(3)), ["dfedfe"] = Class(2, Cow(3));
>
> The idea is that init(m) would create an object that provides the
> subscript operator which takes the map's key type as a parameter
> and returns an object with an assignment operator which takes the
> map's value type as a parameter.  The assignment operator
> would return the original "init" object.  The "init" class
> provides the comma operator to allow chaining as shown.
>
> (Add whitespace to taste:
>
>init(m)
>   ["ssdsd"]  = Class(2, Cow(3)),
>   ["dfedfe"] = Class(2, Cow(3));
> )
>
> What could be more intuitive?
init(m)
   ["sdsds"] -> Class( 2, Cow(3));

>(Efficiency may be another matter,
> but it's intuitive, right?)

yes. might not be such a bad idea.

>
> > >In your case, whitespace might
> > > add something, but the user can still make a mistake.  Even something
> > > like:
> > >
> > > set_map(m) += 1,2,   2,3,   3,4,   5,6,   7,8,  | 9,
> > >   9,10,  11,12, 13,14, 15,16  17,18
> > >   19,20;
> > >
> > > With the user screen margin occuring where the | passes is possible.
In
> > > this case, white space doesn't save him from this mistake.  And it
could
> > > be hard to find.
> >
> > no. as I said earlier, a missing value  will be caught at "bug-time"
(~the
> > first time the user runs the code).
>
> You're assuming the code path containing that initialization code
> will always run.  What if the situation leading to that code path
> wasn't tested?  That may not bode well for the testing
> methodology, but the point is that a compile time error is
> better.
I cannot imagine a situation where constant data in a program has not been
tested. I agree compile errors are better, but if it means you
ruin the int

Re: [boost] is_polymorphic question

[John Maddock]

> It has been reported to me that is_polymorphic gives 
> compile time error when T is const type and the compiler is g++.
> 
> Is there a fix for this?

It will be fixed in cvs shortly.

Thanks for the report,

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] ublas regression test problems

[Aleksey Gurtovoy]

Joerg Walter wrote:
> I've recently committed a couple of bugfixes, extensions and 
> compatibility hacks. The last regression tests seem to be OK 
> for Linux, but some tests under Windows fail to compile. I'm 
> especially concerned about VC7 failures with the diagnostic
> 
> concepts.cpp
> C:\boost\site\boost\mpl\if.hpp(158) : error C2976: 
> 'boost::mpl::if_' : too
> few template arguments
> C:\boost\site\boost\mpl\if.hpp(102) : see declaration of
> 'boost::mpl::if_'
> C:\boost\site\boost\mpl\if.hpp(158) : error C2504: 
> '' : base class
> undefined
> 
> because ublas doesn't depend from mpl. So I've to assume, 
> that somebody is changing either boost.config, boost.type_traits, 
> boost.smart_ptr or boost.timer.

Hmm, compiles fine for me on the clean CVS get (ignoring "test31/32.cpp"
errors, see the attached log). Are you sure you are in sync with the main
trunk?

> P.S.: Why aren't there any regression tests for mpl?

There are, they just not included into the batch. Probably they should be;
there are some issues, mainly with the number of tests (currently ~60 and
more to come) - simply putting those into results table would render it
rather useless, IMO, and the corresponding increase in compile times might
also be a problem (for the tests runners). In any case, I almost never
checking in anything before the regressions passed.

Aleksey




log.zip
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] singlton library?

[Yakov Bachmutsky]

Hi,I've 
posted a proposal of a singleton library (among others) maybe a monthago and 
as far as I remember it was ignored so I post it again with its nameas the 
subject, hoping this will help, and some explanations:1. I use 
singleton to have a singleton instance of a class in 
myapps.The obvious advantage in developement of large apps is that u 
don't have toremember the name of the 1 instance u create like g_myObj but 
only theclass's name and thus always use it like this:  
singleton p->method();2. In addition I use a singleton 
manager to have all singleton objectsstarted at app start:  
singleton_manager::startup()3. to use that I "register" classes to use 
the singleton class and managerclass using a macro:  
REGISTER_SINGLETON(myclass)4. classes can inherit the singleton class to 
get more specific behaviourlike two stage construction.Every such 
inhariting class must have its own registration macro.5. In addition to 
all the above I suggest few more little thingies tosupport other singleton 
patterns, mostly in the form of macroes. There'salso an article on this 
topic:http://www.beginthread.com/Article/yakov/Singleton Techniques/Any interest 
?Yakov

[boost] Re: Serialization to relational table

[Arkadiy Vertleyb]

> With run-time relational libray you also can do joins, projections ..
> but without compile-time type safety.

So, you have to use some kind of "variant"?  I think this solution still
limits which types can be used.  Am I wrong?

> I was thinking about some simple variant of rtl::table with predefined
> run-time tuple. In this case you can define structure of this tuple
> during run-time -> define schema of whole table. But i'm still not
> expert in rtl so i can be wrong.

I really don't see any way we can do any runtime schema definition in RTL.
All the interface is tailored for compile-time calculations and
verifications.

> Dynamic variant of rtl theoretically can avoid only in-memory limitations.
> You can inherit from base class (table,index,database,record, nested_table
...)
> and supply factory for your platform. Than you can have same interface
> for in_memory relational tables and for serious relational database table.

RTL is not limited with in-memory tables only.  Different table
implementations can be defined and used together.  Some of them can be
memory-based, others -- disk-based.  It is just that all we have "in-stock"
right now, is in-memory, sorted std::vector-based table implementation.

And, of course, in-memory tables are serializable.

Regards,
Arkadiy




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Possible boost addition: sub string and const s tring.

[Vincent Finn]

Forwarded to main Boost list - that's the more appropriate venue for
discussions of possible additions.

-- Jim Hyslop boost-users moderator.

> -Original Message-
> From: alexei_novakov [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 18, 2002 7:05 PM
> To: [EMAIL PROTECTED]
> Subject: [Boost-Users] Possible boost addition: sub string and const
> string.
>
>
> Hello everyone.
>
> I have two classes which I found pretty handy: sub_string (behaves as
> a mirror of the portion of master basic_string) and const_string (C-
> string wrapper). Nice thing about these two is they implemented as
> template specialization of basic_string which has advantages:
> a) familiar interface;
> b) possibility to reuse the code written for basic_string (like
> string streams, lexical casts, etc).
>
> Any interest?
>
> Regards.
>
> Alexei Novakov

Sounds interesting, like slice on a valarray

When I have to do a lot of manipulation of sub string and can't afford 
to copy back and forward I normally resort to using vector; this 
sounds a lot handier

How does it work ?

	Vin



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Boost License Issues

[Paul A. Bristow]

I am sure legal views on this would be useful, but I fear that if you ask
n lawyers for their opinion, you will end up with more than n+1 opinions!

Can't we tap some of these firms that are worrying about this for
their legal views, for what they are worth?

Paul

Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB  UK
+44 1539 561830   Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]


> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Beman Dawes
> Sent: Wednesday, November 20, 2002 1:15 AM
> To: Boost mailing list; Boost mailing list
> Subject: Re: [boost] Boost License Issues
>
>
> At 09:38 AM 11/19/2002, Andrew Koenig wrote:
>
>  >Beman> Even something in the public domain should have a copyright, and a
>  >Beman> license that says it is in the public domain.
>  >
>  >I think you should check this statement with a lawyer.
>
> I'd really like a knowledgeable intellectual property lawyer to review all
> Boost related license issues. But finding one willing to help has been a
> problem. Suggestions would be welcome.
>
>  >  Keith Gorlen,
>  >the author of the NIH (National Institutes of Health) class library,
>  >told me once that his work, being a ``US Government work'' is in the
>  >public domain and *cannot* be copyrighted or licensed.  That is,
>  >*nothing* that anyone does with his work can legally prevent anyone
>  >from copying it, so there is no meaningful way of licensing it.
>
> If I understand correctly, what was being requested was that it be possible
> to clearly associate each file with its legal status. So in the case you
> mention, I guess they would want to see a notice to the effect it was
> a  "US Government work" and that it was in the public domain.
>
> We know some potential Boost users are delaying use of the libraries
> because of uncertainty about legal issues. We would like to address those
> issues, but really need help from a knowledgeable lawyer to do so.
>
> --Beman
>
>
> ___
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>

___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] ublas regression test problems

[Joerg Walter]

Hi all,

I've recently committed a couple of bugfixes, extensions and compatibility
hacks. The last regression tests seem to be OK for Linux, but some tests
under Windows fail to compile. I'm especially concerned about VC7 failures
with the diagnostic

concepts.cpp
C:\boost\site\boost\mpl\if.hpp(158) : error C2976: 'boost::mpl::if_' : too
few template arguments
C:\boost\site\boost\mpl\if.hpp(102) : see declaration of
'boost::mpl::if_'
C:\boost\site\boost\mpl\if.hpp(158) : error C2504: '' : base class
undefined

because ublas doesn't depend from mpl. So I've to assume, that somebody is
changing either boost.config, boost.type_traits, boost.smart_ptr or
boost.timer.

Thanks in advance

Joerg

P.S.: Why aren't there any regression tests for mpl?

P.P.S.: Thanks very much for the regular regression tests! These are an
invaluable tool, especially if one isn't able to test on all supported
platforms.



___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Boost License Issues

[Bjorn . Karlsson]

> From: Rene Rivera [mailto:[EMAIL PROTECTED]]
> I think you did a limited search... only in the headers. 
> There are many more
> files without (C). For example most "Jamfile"s don't have one.
> 
> Could you post how you did the search... perhaps this is 
> something for Beman
> to add to the list of checks for releases.

Yep, the search was limited (recursion started from the #include root); also
grepping Jamfiles, make files, html files, etceteras yields quite different
results. I'm not exactly sure where the "copyright line" should be drawn;
for instance, must every style sheet that's part of the distribution also
contain a copyright statement? When I ran some Boost library licenses
through our legal department, they were mainly interested in the copyright
in the source files, not the documentation. Ah well.

My search was simple and far from foolproof:

grep -i -L -r "copyright" * | grep -E -v
"(\.gif|\.jpe?g|\.png|\.scc|\.dat|\.obj|\.fig)|\.expected|\.dot|\.lib|\.cmd|
\.dll|\.mak|\.dsp" > missing_copyrights.dat

[for 1.29.0, the result is >1600 hits]
[On a clean distribution, some exclude patterns could be, well, excluded.]

Of course, using this grep, any file containing "copyright" will pass.

Bjorn
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Re: Serialization to relational table

[Bohdan]

"Arkadiy Vertleyb" <[EMAIL PROTECTED]> wrote in message
ared23$aod$[EMAIL PROTECTED]">news:ared23$aod$[EMAIL PROTECTED]...
> > Note! My knowledges about RTL are far from good. Just first glance.
> > I failed to compile rtl with my compiler. Will try once again.
>
> Which compiler are you using?  So far we only support VC6 and g++.
>
> Arkadiy
>

bcc32 5.5.1 ( borland ) commonly with stlport
I'll try to fix sources for it.

regards,
bohdan




___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost