Re: [boost] container algorithms almost complete

"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 *

[boost] Re: container algorithms almost complete

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 -- Ali

[boost] postponed<> proposal

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 que

[boost] Proposal: strings as template parameters?

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

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

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 paramet

[boost] Re: container algorithms almost complete

"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 h

[boost] Re: container algorithms almost complete

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

[boost] Re: container algorithms almost complete

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 mo

[boost] Re: postponed<> proposal

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 w

[boost] Re: container algorithms almost complete

"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

Re: [boost] Re: container algorithms almost complete

"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 contain

Re: [boost] postponed<> proposal

"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.b

[boost] Re: postponed<> proposal

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

[boost] Re: Re: container algorithms almost complete

"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

[boost] Re: container algorithms almost complete

"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

[boost] Unused template parameters

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 re

[boost] SourceForge computer farm

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

[boost] static_assert.hpp queries

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_ASS

[boost] Re: postponed<> proposal

"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 underst

[boost] Re: postponed<> proposal

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

[boost] Borland problems with dynamic RTL

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 th

[boost] Re: postponed<> proposal

"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: > >>