Eric Niebler <neric@qwest.net> wrote in message news:<pan.2002.06.05.07.59.40.553619.4629@qwest.net>...
> It sure would be nice if all STL implementations were required to provide
> a compile-time constant which indicated whether stateful allocators were
> supported or not.  That way, I could write portable code that used
> stateful allocators when the implementation supported it, and fall back to
> good, ol' stateless allocators if it didn't.
>
> Something like:
>
> namespace std
> {
>     bool const stateful_allocators = true; // woo-hoo!
> }
>

I would like to comment on the general style of this solution (and
some others that use the same philosophy), without discussing the
problem itself (allocators and stuff).

Would requiring this flag in the standard make your code more
portable? Well, the flag saves you of the effort of writing these 4
lines (plus ifdefs) yourself for each implementation you work with. I
mean is that a real portability issue?

The portability issue that I see is having to write two
implementations of your code - one for stateful allocators and one for
stateless allocators. It's double work. I think portability is about
the effort it takes to do stuff over the platforms. In this case,
allowing implementations to have either stateful or stateless
allocators causes double effort on your part.

I would favor solutions that require the implementations to provide
both versions or provide a single specific one.

As an example, different STL implementations have different
performance characteristics for list::size() (linear vs.
constant-time). Both implementations are standard and therefore if you
write standard-compliant code, you are portable. But this is a fake
portability - I have to rewrite code from scratch to adapt to
different performances of size().

So, to summarize, I'm for increasing the burden on the
implementations, instead of allowing a range of possible
implementation strategies to make sure more implementations become
automatically compliant.

Regards,
-Vahan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 10 Jun 2002 15:47:53 -0700, Vahan Margaryan wrote:

> Would requiring this flag in the standard make your code more portable?
> Well, the flag saves you of the effort of writing these 4 lines (plus
> ifdefs) yourself for each implementation you work with. I mean is that a
> real portability issue?

Yes, it's a real portability issue. I'm writing a template library, and it
want it to work with any std-compliant library implementation. #ifdef's
are not a viable solution -- I don't know ahead of time what standard
library implementation my users will pick.

> The portability issue that I see is having to write two implementations
> of your code - one for stateful allocators and one for stateless
> allocators. It's double work.

No, I only need to write one (stateful) allocator. I can fall back on
std::allocator.  All I would need is a typedef to pick the allocator based
on the std::stateful_allocators compile-time constant.

> I would favor solutions that require the implementations to provide both
> versions or provide a single specific one.

And I'd like it to rain beer.  :-)  But it seems unlikely that C++0x would
require all standard library implementations to support stateful
allocators.  At least, I'm not aware of any such proposal.

Providing a compile-time constant is easy, backwards compatible, and makes
it possible for library developers to write portable (portable!) code that
takes advantage of stateful allocators.

Cheers!
Eric

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The standard containers are allowed to treat all allocator instances of
the same type as equivalent.  But the standard also encourages library
implementers to not make this assumption, and some don't and allow the use
of "stateful allocators."  Trouble is, there is no way to make code that
uses stateful allocators portable across different STL implementations.

It sure would be nice if all STL implementations were required to provide
a compile-time constant which indicated whether stateful allocators were
supported or not.  That way, I could write portable code that used
stateful allocators when the implementation supported it, and fall back to
good, ol' stateless allocators if it didn't.

Something like:

namespace std
{
    bool const stateful_allocators = true; // woo-hoo!
}

It wouldn't be very hard to implement.  :-)

Eric

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]