[boost] Re: postponed<> proposal

[Fernando Cacciola]

"Philippe A. Bouchard" <[EMAIL PROTECTED]> escribió en el mensaje
news:[EMAIL PROTECTED]
> David B. Held wrote:
>
> > "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >> David Abrahams wrote:
> >>
> >> > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> >> >
> >> >> I would like some feedback about the logic behind it.
> >> >
> >> > Do you have a use-case for this?
> >>
> >> Sorry, I do not understand; you mean someone that would want to
> >> use it this way?  I am not sure, but it would be better for continous
> >> optional<>s this way?
> >
> > Dave is asking you if you are solving a problem that doesn't exist. ;)
> > Your answer seems to indicate as much. ;)
>
> I do not have any use-case.  Thanks anyways.
>
> Maybe it would be better to simply disable EH overhead with some BOOST
> macro.  _That_ would be really really great then...
>
>
Which EH overhead?

Anyway, the problem with your proposal is that as I said before the
boolean flag is initialized before the object is really constructed.

Fernando Cacciola






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

[boost] Borland problems with dynamic RTL

[Alisdair Meredith]

It appears the current borland compiler has several problems when
linking with the dyanmic version of the RTL, most noticably (in boost
regressions) wrt std::numeric limits.  These problems go away when
linking statically to the RTL.  Would it be viable to change the
regression builds to support this?

I have tried #define BOOST_NO_LIMITS in the borland config as a
workaround, but it seems the STL implementation itself will use 
leading to duplicate definitions, causing more problems than it solves
(mainly fixes some issues for the interval library.)

Is there a better way to tackle this problem?

-- 
AlisdairM

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

[boost] Re: postponed<> proposal

[Philippe A. Bouchard]

David B. Held wrote:

> "Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> David Abrahams wrote:
>>
>> > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
>> >
>> >> I would like some feedback about the logic behind it.
>> >
>> > Do you have a use-case for this?
>>
>> Sorry, I do not understand; you mean someone that would want to
>> use it this way?  I am not sure, but it would be better for continous
>> optional<>s this way?
> 
> Dave is asking you if you are solving a problem that doesn't exist. ;)
> Your answer seems to indicate as much. ;)

I do not have any use-case.  Thanks anyways.

Maybe it would be better to simply disable EH overhead with some BOOST 
macro.  _That_ would be really really great then...


-- 
Philippe A. Bouchard


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

[boost] Re: postponed<> proposal

[David B. Held]

"Philippe A. Bouchard" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> David Abrahams wrote:
>
> > "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> >
> >> I would like some feedback about the logic behind it.
> >
> > Do you have a use-case for this?
>
> Sorry, I do not understand; you mean someone that would want to
> use it this way?  I am not sure, but it would be better for continous
> optional<>s this way?

Dave is asking you if you are solving a problem that doesn't exist. ;)
Your answer seems to indicate as much. ;)

Dave




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

[boost] static_assert.hpp queries

[Alisdair Meredith]

Picking off more borland errors, I have a couple of questions on this
test case:

1/ should char be Char in the following snippet [case-error]
[Extract of static_assert.hpp starting line 53]

template 
struct Bill
{
  private:  // can be in private, to avoid namespace pollution
BOOST_STATIC_ASSERT(sizeof(Int) > sizeof(char)); // <-- error?
  public:
...

2/ This same line line is the source of the borland error.  A quick test
shows it cannot cope with the simple

BOOST_STATIC_ASSERT( 5 > 3 );

however

BOOST_STATIC_ASSERT( 5 >= 3 );

passes fine.  I guess the > is fooling the template parser.

This leads to the obvious workaround of:

#if defined( __BORLANDC__ )  //  Borland cannot handle > comparison
BOOST_STATIC_ASSERT( 
   ( sizeof(Int) >= sizeof(Char) ) 
&& ( sizeof(Int) != sizeof(Char) ) 
);
#else
BOOST_STATIC_ASSERT(sizeof(Int) > sizeof(Char));
#endif

However, I am not happy patching test-cases rather than libraries.  On
the other hand, having diagnosed the problem with a viable workaround, I
don't see where else to record the information.  Do we have a way of
documenting known workarounds for a library?

--
AlisdairM

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

[boost] SourceForge computer farm

[Daryle Walker]

When I read a web page for a project (in this case, HTML-Tidy at 
), I noticed that they built/tested their 
library every day automatically with computers SourceForge leaves for 
automation.  Maybe we should use those computer for our regression 
testing?

Daryle

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

[boost] Unused template parameters

[Daryle Walker]

On Thursday, February 13, 2003, at 6:11 AM, Daniel Frey wrote:

Markus Schöpflin wrote:
Daniel Frey wrote:

Markus Schöpflin wrote:

This was the original source:

template struct enable_if;
---^
Visual Age doesn't like this, it needs a name here.
  ^^

Ah, that's the reason. But given my recent discomfort about
unmaintainable code, look at it again:
  #  if BOOST_WORKAROUND(__HP_aCC, <= 33900)
  template struct enable_if;
  #  else
  template struct enable_if;
  #  endif
Does this really makes sense? Shouldn't we just keep one version 
with names for template parameters? AFAICS this should work for all 
compilers and it could be a general boost coding guideline to always 
provide names for template parameters. Comments?
Agreed, if it works for all compilers, let's just keep the version 
with the names. (And add a comment that it should stay like it is!)
No, don't add a comment. Let's make it a boost coding guideline,
otherwise we will clutter the code again with comments instead of
workarounds. Remember that this is only one example of a line with
template parameters. Would you like to add a comment for every line 
all over boost?
Should the template parameter names be something like Unused (if 
there's exactly one) or Unused1, Unused2, etc.?

Later, on February 16, 2003, at 9:29 PM, Dave Gomboc wrote:

So you would prefer

#if BOOST_WORKAROUND(__HP_aCC, <= 33900)
template struct enable_if;
#elif BOOST_WORKAROUND(__VisualAge, <= 12345) // Dummy values
template struct enable_if;
#else
template struct enable_if;
#endif
over

template struct enable_if;

If that is the case, then we disagree. Do you have any reason to 
prefer the first version?
No, I would prefer

#if BOOST_WORKAROUND(__HP_aCC, <=33900) || 
BOOST_WORKAROUND(__VisualAge,
<=12345)
template  struct enable_if;
#else
template  struct enable_if;
#endif

I already explained the reason: C++ compiler vendors use Boost with
BOOST_NO_CONFIG for conformance testing.  I'd rather see broken 
compilers get fixed than developers forever spending time finding 
workarounds.
If vendors want to do this check, then they could #define Unused, 
Unused1, Unused2, etc. to be nothing.  (Make sure to check all the 
files to see if my suggestion is the only use of these words.)

Daryle

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

[boost] Re: container algorithms almost complete

[Thorsten Ottosen]

"Thorsten Ottosen" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Alisdair Meredith" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Thorsten Ottosen wrote:
> >
> > > 2. many standard algorithms take a single output iterator as an
> argument.
> > > Currently the argument for output must be a container. Should
> > > it be posible to specify an iterator here too?
> >
> > Absolutely!  Not all iterators belong to containers eg ostream_iterator
>
> I see your point. Does anyone have a nice idea of how to detect when the
> template argument is an iterator? It's easy with pairs and arrays and the
> default case is containers.

The "easy" workaround is maybe to change the template argument to expect an
output iterator and not a container:


template< typename Container1, typename Container2 >
inline typename container_traits::iterator
copy( const Container1& c1, Container2& c2 )
{
return std::copy( begin( c1 ), end( c1 ), begin( c2 ) );
}

becomes

template< typename Container1, typename Output_iterator >
inline typename container_traits::iterator
copy( const Container1& c1, Output_iterator c2 )
{
return std::copy( begin( c1 ), end( c1 ), c2 );
}

and usage change accordingly from

copy( vector1, vector2 );

to

copy( vector1, vector2.begin() );

I see a potential benefit of the former because we can assert that the size
of the container is big enough
to hold the input. I guess debug iterators would catch the same, if you have
them.

Still, we need to detect iterators anyway if this should work:

istream_iterator< string >is( in_file ), eof;
typedef vector< string >  vec_t;
vec_t  text;
copy( is, back_inserter( text ) ); // same as std::copy( is, eof,
back_inserter( text ) );

We could keep the former syntax and allow inserters like this:

template< typename C >
std::back_insert_iterator&
make_back_inserter( C& c )
{
static std::back_insert_iterator bii( c );
bii = back_inserter( c );
return bii;
}
...
copy( is, make_back_inserter( text ) );

Let me now what you think.

regards

Thorsten



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

[boost] Re: Re: container algorithms almost complete

[Thorsten Ottosen]

"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Thorsten Ottosen" <[EMAIL PROTECTED]> writes:

> > I see your point. Does anyone have a nice idea of how to detect when the
> > template argument is an iterator?
>
> Sadly, there is no reliable way.  The closest thing I can imagine is
> to use SFINAE to check that iterator_traits has valid types, and
> that the types are consistent with the iterator requirements.

I imagine that will be rather non-portable (Comeau and ?). This seems to
work for como, gcc3.2, vc7:


 template< typename C, typename T, typename D,
typename P, typename R >
  true_t  is_iterator( const std::iterator& );
 template< typename C >
 true_t  is_iterator( const std::back_insert_iterator& );
 template< typename C >
 true_t  is_iterator( const std::front_insert_iterator& );
 template< typename C >
 true_t  is_iterator( const std::insert_iterator& );
 template< typename T, typename C, typename Tr >
 true_t  is_iterator( const std::istream_iterator& );
 template< typename T, typename C, typename Tr >
 true_t  is_iterator( const std::ostream_iterator& );
 template< typename C, typename Tr >
 true_t  is_iterator( const std::istreambuf_iterator& );
 template< typename C, typename Tr >
 true_t  is_iterator( const std::ostreambuf_iterator& );
 false_t is_iterator( ... );

but I'm wondering if that is enough. Can anybody come up with some cases
which will fail here and which is important?

regards


Thorsten



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

[boost] Re: postponed<> proposal

[Philippe A. Bouchard]

David Abrahams wrote:

> "Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:
> 
>> I would like some feedback about the logic behind it.
> 
> Do you have a use-case for this?

Sorry, I do not understand; you mean someone that would want to use it this 
way?  I am not sure, but it would be better for continous optional<>s this 
way?

-- 
Philippe A. Bouchard


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

Re: [boost] postponed<> proposal

[David Abrahams]

"Philippe A. Bouchard" <[EMAIL PROTECTED]> writes:

> I would like some feedback about the logic behind it.

Do you have a use-case for this?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

Re: [boost] Re: container algorithms almost complete

[David Abrahams]

"Thorsten Ottosen" <[EMAIL PROTECTED]> writes:

> "Alisdair Meredith" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> Thorsten Ottosen wrote:
>>
>> > 2. many standard algorithms take a single output iterator as an
> argument.
>> > Currently the argument for output must be a container. Should
>> > it be posible to specify an iterator here too?
>>
>> Absolutely!  Not all iterators belong to containers eg ostream_iterator
>
> I see your point. Does anyone have a nice idea of how to detect when the
> template argument is an iterator? 

Sadly, there is no reliable way.  The closest thing I can imagine is
to use SFINAE to check that iterator_traits has valid types, and
that the types are consistent with the iterator requirements.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

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

[boost] Re: container algorithms almost complete

[Thorsten Ottosen]

"Dirk Gerrits" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Dirk Gerrits wrote:
> > Thorsten Ottosen wrote:
> >
> >> I see your point. Does anyone have a nice idea of how to detect when
the
> >> template argument is an iterator? It's easy with pairs and arrays and
the
> >> default case is containers.
> >
> >
> > Perhaps you can use Boost's concept check to see if the template
> > argument models the Input Iterator concept? That's the first thing that
> > came to mind, I haven't tried it out or anything.
>
> On second thought, that won't work. Concept check causes a compilation
> error when the argument does not conform to the concept.
>
> Perhaps you can do it the other way around? Check for a T::begin member
> function to see if the type is a container, and assume the type is an
> iterator in the default case? I'm not sure what that check would look
> like though.

I can't come up with any reason that it should be easier to detect a
container. Here's my initial attempt for iterators based on the assumption
that
all important iterators have derived from std::iterator:


 template< typename C, typename T, typename D,
typename P, typename R >
  true_t  is_iterator( const std::iterator& );
 false_t is_iterator( ... );


template< typename C >
struct container_traits
{
private:
 static C& c;
 BOOST_STATIC_CONSTANT( bool, is_iterator =
  sizeof( detail::container::is_iterator( c ) )
  == sizeof( detail::container::true_t ) );
};

but it doesn't seem to work for eg. an ostream iterator. Does anyone know if
the binding in is_iterator is possible with all these templates involved?

regards

Thorsten



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

[boost] Re: postponed<> proposal

[Philippe A. Bouchard]

Philippe A. Bouchard wrote:

[...]

> typelists but I guess some derivative of tuple<> will be better
> eventually. The member function postponed<>::set<>() properly initialized
> the boolean to true:
> 
> struct A : postponed< typelist typelist > > > >
> {
> };

[...]

The tuple<> like interface will look like, but I think the number of 
template parameters cannot be infinite this way:

struct A : postponed
{
};

struct A : postponed
{
};

-- 
Philippe A. Bouchard


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

[boost] Re: container algorithms almost complete

[Dirk Gerrits]

Dirk Gerrits wrote:
Thorsten Ottosen wrote:

I see your point. Does anyone have a nice idea of how to detect when the
template argument is an iterator? It's easy with pairs and arrays and the
default case is containers.


Perhaps you can use Boost's concept check to see if the template 
argument models the Input Iterator concept? That's the first thing that 
came to mind, I haven't tried it out or anything.
On second thought, that won't work. Concept check causes a compilation 
error when the argument does not conform to the concept.

Perhaps you can do it the other way around? Check for a T::begin member 
function to see if the type is a container, and assume the type is an 
iterator in the default case? I'm not sure what that check would look 
like though.

Dirk Gerrits

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

[boost] Re: container algorithms almost complete

[Dirk Gerrits]

Thorsten Ottosen wrote:
I see your point. Does anyone have a nice idea of how to detect when the
template argument is an iterator? It's easy with pairs and arrays and the
default case is containers.
Perhaps you can use Boost's concept check to see if the template 
argument models the Input Iterator concept? That's the first thing that 
came to mind, I haven't tried it out or anything.

Regards,

Dirk Gerrits

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

[boost] Re: container algorithms almost complete

[Thorsten Ottosen]

"Alisdair Meredith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Thorsten Ottosen wrote:
>
> > 2. many standard algorithms take a single output iterator as an
argument.
> > Currently the argument for output must be a container. Should
> > it be posible to specify an iterator here too?
>
> Absolutely!  Not all iterators belong to containers eg ostream_iterator

I see your point. Does anyone have a nice idea of how to detect when the
template argument is an iterator? It's easy with pairs and arrays and the
default case is containers.

regards

Thorsten



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

[boost] Re: Proposal: strings as template parameters?

[Dirk Gerrits]

Jason House wrote:
I'm thinking that it would be nice to be able to us define distinct
types based on strings (the fundamental type const char * and not
std::string).  The intended use is in templates.
Well I'm just curious how you would like to accomplish this. String 
literals as template parameters don't really work all that well, if I 
recall correctly. Then again, I might be wrong.

Dirk Gerrits

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

[boost] Proposal: strings as template parameters?

[Jason House]

I believe I've seen traffic earlier about some kind of upcoming deadline
for proposals for becoming part of the C++ standard.

I'm thinking that it would be nice to be able to us define distinct
types based on strings (the fundamental type const char * and not
std::string).  The intended use is in templates.

Here's one motivating example:
http://groups.yahoo.com/group/boost/files/associative_list/
by Emily Winch

Inside there is a line:
struct a{}; struct b{}; struct c{}; struct d{};

Which is then followed up by calls such as
get(...)
get(...)
...

a,b,c,d are all empty structures, with the only goal of getting distinct
types (this easily could have human readable forms, like an address book
example: struct FirstName{}; struct PhoneNumber{}; etc...)

I guess what I want to know is:
  Does anyone know of other motivating examples, especially within other
parts of boost?
  Any arguments as to why this is the worst idea ever?  
  How about the best? ;)

It seems like such functionality would be a convenience to the
programmer.  It would also make conversion of the type to a string
format very easy ;)  While that seems like a side topic, I'm sure that
there are interesting ways to tie that in.

For the moment, I'm just curious to see the reactions to the idea.

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

[boost] postponed<> proposal

[Philippe A. Bouchard]

Greetings,

I have just made a class which is able to correctly handle alignments of
the types resembling to boost::optional<>.  The booleans which are
responsible to flag if the object is initialized or not are gathered
together so that they will not disturb the alignment of the objects in
question.

The following example demonstrates how it looks like for now; I am using
typelists but I guess some derivative of tuple<> will be better eventually.
The member function postponed<>::set<>() properly initialized the boolean to
true:

struct A : postponed< typelist > > > >
{
};

int main()
{
A a;

new (a.set<0>()) char('M');
new (a.set<1>()) short(50);
new (a.set<2>()) long(10);
new (a.set<3>()) double(3.1416);

cout << a.get<0>() << endl;
cout << a.get<1>() << endl;
cout << a.get<2>() << endl;
cout << a.get<3>() << endl;
}


Maybe the following will be better...:
new (a.set<0>) char('M');

I would like some feedback about the logic behind it.



Regards,

Philippe A. Bouchard




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

[boost] Re: container algorithms almost complete

[Alisdair Meredith]

Thorsten Ottosen wrote:

> 2. many standard algorithms take a single output iterator as an argument.
> Currently the argument for output must be a container. Should
> it be posible to specify an iterator here too?

Absolutely!  Not all iterators belong to containers eg ostream_iterator

-- 
AlisdairM
Team Thai Kingdom

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

Re: [boost] container algorithms almost complete

[Gabriel Dos Reis]

"Thorsten Ottosen" <[EMAIL PROTECTED]> writes:

| 4. The code implement poor mans partial specialization to enable the
| container_traits to work with buggy compilers; so far so good; however,
| many compilers cannot even do partial ordering of function templates
| which is a real pain in the . I know the workaround might be
| to  say
| 
| template< typename C >
| inline typename
| container_traits::iterator
| begin( C c )
| {
| return container_traits::function_t::begin( c );
| }
| 
| instead of
| 
| template< typename C >
| inline typename
| container_traits::iterator
| begin( C& c )
| {
| return container_traits::function_t::begin( c );
| }
| 
| template< typename C >
| inline typename
| container_traits::const_iterator
| begin( const C& c )
| {
| return container_traits::function_t::begin( c );
| }
| 
| but C can be a huge STL container. Can we assume compilers will inline code
| and not copy anything?

I don't think that assumption may be valid for major compilers out there.
 

Irrespective of pessimization issues, there is a definitve semantics
avantage of the latter over the former:  It works with native "C"
arrays while the former does not.  That is a decisive argument to have
begin/end non-member functions.

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