"Greg Comeau" <comeau@panix.com> wrote:
> Anyway, considering that some vendors have been (at best ridiculously)
> claiming full compilance to ISO C++ for years, at times this
> seems like a good idea.  There are of course C++ test suites
> as one step, but that's not exactly the same.

Is there a recognized, non-commercial "compliance" suite for C++? I know
there exist web site that list some conformance issues for various
compilers, but these sites are usually behind the times.

Would it not behoove the C++ community to develop a free/open Standard
compliance suite? Or is this (as I suspect) more work than most of us can
afford?

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com



---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3B04B044.2689A521@eznet.net>,
David A. Frantz <wizard@eznet.net> wrote:
>Bjarne Stroustrup wrote:
>> >  Which brings up another of my pet peeves: Companies who participate
>> > in a standards group (like the one for C++) should be obligated to support
>> > said standard when it is released! The biggest offender in this regard is
>> > Microsoft... (he goes back into his corner, growling about supporting
>> > Microsoft's annoying compiler...)
>>
>> Even Microsoft will get there, but yes, it would be a nice thing if
>> programming language standards had "real teeth" - say, like the way
>> standards for electrical equipment or automobiles have. However, most
>> people in the computer industry would strongly object to the degree of
>> formality and government intervention that would imply.
>
>Just a thought from left field.   If someone wants that sort of
>formality they can always consider a validated ADA compiler.
>
>I bring this up only due to the slow implementation of the entire C++
>standard.    Yes its nice that everyone is working on conforming compilers,
>but I often question how we would really know when they got there.
>Its not like we can put much trust into any marketing department.
>Its to bad this industry doesn't have an "UL" like organization
>to validate conformance.

I'm not convinced such an entity in and of itself would
necessarily mean that implementors would be working _faster_.

Anyway, considering that some vendors have been (at best ridiculously)
claiming full compilance to ISO C++ for years, at times this
seems like a good idea.  There are of course C++ test suites
as one step, but that's not exactly the same.
--
Greg Comeau                 Comeau C/C++ 4.2.45.2
ONLINE COMPILER ==>         http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo!       NEW: Try out our C99 mode!
comeau@comeaucomputing.com  http://www.comeaucomputing.com

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Bjarne Stroustrup wrote:

>>>>>snip

>
> >  Which brings up another of my pet peeves: Companies who participate
> > in a standards group (like the one for C++) should be obligated to support
> > said standard when it is released! The biggest offender in this regard is
> > Microsoft... (he goes back into his corner, growling about supporting
> > Microsoft's annoying compiler...)
>
> Even Microsoft will get there, but yes, it would be a nice thing if
> programming language standards had "real teeth" - say, like the way
> standards for electrical equipment or automobiles have. However, most
> people in the computer industry would strongly object to the degree of
> formality and government intervention that would imply.

Just a thought from left field.   If someone wants that sort of formality they
can always consider a validated ADA compiler.

I bring this up only due to the slow implementation of the entire C++
standard.    Yes its nice that everyone is working on conforming compilers, but I
often question how we would really know when they got there.   Its not like we
can put much trust into any marketing department.    Its to bad this industry
doesn't have an "UL" like organization to validate conformance.

Thanks
Dave


>
>
>         - Bjarne
> Bjarne Stroustrup - http://www.research.att.com/~bs
>
> ---
> [ 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.research.att.com/~austern/csc/faq.html                ]

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi,
Al Grant (tnarga@arm.REVERSE-NAME.com) wrote:
: "Howard Hinnant" <hinnant@antispam.metrowerks.com> wrote in message
: news:140520011313028184%hinnant@antispam.metrowerks.com...
: > While your point about an O(1) size() is well taken, I just wanted to
: > point out that I'm not aware of any std::list that is implemented with
: > just a single pointer of overhead.  I am aware of implementations that
: > have sizeof(list<int>) == sizeof(int*).  But as far as I know, on those
: > implementations there is typically at least 3 more words of overhead
: > that are put on the heap.

: If this is not done until the list first becomes non-empty,
: that could be a significant saving, if the programmer
: expected that an empty list was as cheap as a null pointer.

It really depends on what the implementer of 'std::list<T>' expects
from the list: That it is normally empty and should save memory in this
case or that there are elements and it should perform at maximum
performance.  I would almost certainly optimize for the second option,
at least as the default case! And I would try to avoid the heap
allocation. That is, I would expect that 'sizeof(std::list<T>)' is two
words and that 'size()' takes O(n) but I'm not really sure what that is
legal under the rules of the standard (I think it is under the rules of
the TC).
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Bjarne Stroustrup wrote:
>
> So do I, and such compilers are on their way. The implementers work slower
> than we'd like (of course we do, we want all the neat features yesterday
> - unless it features of a system for which we are the implementers :-),
> but they do work hard. They are professionals, and eventually they'll get
> there.
>

Yup. It takes time to figure out what it means and how to do it. export
is not a simple notion, and it's not at all surprising that it's taken
this long for compiler writers to get to the point where they have it
barely working internally.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9dqpr7$bo8$1@cam-news1.cambridge.arm.com>, Al Grant
<tnarga@arm.REVERSE-NAME.com> wrote:

| "Howard Hinnant" <hinnant@antispam.metrowerks.com> wrote in message
| news:140520011313028184%hinnant@antispam.metrowerks.com...
| > While your point about an O(1) size() is well taken, I just wanted to
| > point out that I'm not aware of any std::list that is implemented with
| > just a single pointer of overhead.  I am aware of implementations that
| > have sizeof(list<int>) == sizeof(int*).  But as far as I know, on those
| > implementations there is typically at least 3 more words of overhead
| > that are put on the heap.
|
| If this is not done until the list first becomes non-empty,
| that could be a significant saving, if the programmer
| expected that an empty list was as cheap as a null pointer.

If find myself wondering if the nothrow guarantee can be upheld for
members like splice (or swap) under such a design:

void splice(iterator position, list& x, iterator i);

If *this is empty (and has not allocated its overhead), and this != &x,
and x.size() > 1 (so that it can not donate its overhead), then *this
would have to allocate a new overhead during this operation.  But this
operation has a nothrow guarantee and shouldn't be allocating.  Seems
you're forced into a design of either always preallocating your
overhead (either on the stack or on the heap), or of maintaining a
non-empty free list of overheads.  Maybe you see something I don't.

--
Howard Hinnant
Metrowerks

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:Jc3X7GBlB$$6Ew58@ntlworld.com...
> In article <heRL6.241084$o9.35381041@typhoon.tampabay.rr.com>, Scott
> Robert Ladd <scott@coyotegulch.com> writes
> >As it stands, the Standard Library violates the most important C++ tenet:
> >You don't pay for it if you don't use it. Heavy containers and heavy
strings
> >make programs pay for unnecessary functionality.
>
> Yes and No. As these items are templates, a conforming compiler should
> (is only allowed to) ONLY instantiate those functions that you actually
> use. So where does the fat come in?

Default construction, for one thing.  That also makes
it impossible to use a container in a union.

> The problems I have with the Standard Library are rather different.
> Defaulted extra parameters should not be allowed, that is a serious
> design error that should be removed (if implementors want extras they
> should have a licence to add overloads to functions and function
> templates. The second thing that should be yanked out ASAP are
> allocators.

Yes, it's ridiculous that when some STLs can implement
list<int> as a single pointer, others bloat it to 5 times
that by adding allocator, cached length etc. while still
being conforming.  And why cache the length?  Either you
want an O(1) length function or you don't, and if you don't,
you don't want the overhead every time you use such a
basic container.  That is not a decision that should be
made by the STL author.  The Standard should forbid
a container implementation from consuming any resources
other than those necessary to fulfil its contract.



---
[ 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.research.att.com/~austern/csc/faq.html                ]

FG> Yes and No. As these items are templates, a conforming compiler
FG> should (is only allowed to) ONLY instantiate those functions that
FG> you actually use. So where does the fat come in?

Compile times, for starters. I don't know about you, but heavily
template-based code brings some compilers to their knees. Too many people
throw code into template-headers, and then expect the compiler to optimize
it for them...

Part of the problem stems from precompiled headers. One of my projects
generated a 50MB pre-compiled header, due to our use of various template
libraries! The sheer physical I/O on such a file is amazing.

I'll grant that most of my complaint is based on poor and incomplete C++
implementations. However, I just don't see the point to "one size fits all"
classes or templates; it seems to me that a better design is to build a
hierarchy of functionality, so programmers can choose their level of
complexity. As it stands now, I get all of vector<>, even if I only use a
small part of its feature set.

BTW, I know about export. Lordy, do I wish more compilers implemented
export. Which brings up another of my pet peeves: Companies who participate
in a standards group (like the one for C++) should be obligated to support
said standard when it is released! The biggest offender in this regard is
Microsoft... (he goes back into his corner, growling about supporting
Microsoft's annoying compiler...)

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com



---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <zAUL6.242154$o9.35525674@typhoon.tampabay.rr.com>, Scott
Robert Ladd <scott@coyotegulch.com> writes
>BTW, I know about export. Lordy, do I wish more compilers implemented
>export. Which brings up another of my pet peeves: Companies who participate
>in a standards group (like the one for C++) should be obligated to support
>said standard when it is released! The biggest offender in this regard is
>Microsoft... (he goes back into his corner, growling about supporting
>Microsoft's annoying compiler...)

However, note that Microsoft actually lost there voting rights in the
years just prior to the completion of the C++ Standard, so I guess it
would have made no difference to them. I would still like to see
language names trademarked by ISO or the NBs.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <9dp0v1$n2q$1@cam-news1.cambridge.arm.com>, Al Grant
<tnarga@arm.REVERSE-NAME.com> wrote:

| Yes, it's ridiculous that when some STLs can implement
| list<int> as a single pointer, others bloat it to 5 times
| that by adding allocator, cached length etc. while still
| being conforming.  And why cache the length?  Either you
| want an O(1) length function or you don't, and if you don't,
| you don't want the overhead every time you use such a
| basic container.  That is not a decision that should be
| made by the STL author.  The Standard should forbid
| a container implementation from consuming any resources
| other than those necessary to fulfil its contract.

While your point about an O(1) size() is well taken, I just wanted to
point out that I'm not aware of any std::list that is implemented with
just a single pointer of overhead.  I am aware of implementations that
have sizeof(list<int>) == sizeof(int*).  But as far as I know, on those
implementations there is typically at least 3 more words of overhead
that are put on the heap.

An interesting exercise is to create a std::list<int, AuditAlloc<int>
>, where AuditAlloc keeps track of the amount of memory allocated and
provides an interface to report that amount.

--
Howard Hinnant
Metrowerks

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Howard Hinnant" <hinnant@antispam.metrowerks.com> wrote in message
news:140520011313028184%hinnant@antispam.metrowerks.com...
> While your point about an O(1) size() is well taken, I just wanted to
> point out that I'm not aware of any std::list that is implemented with
> just a single pointer of overhead.  I am aware of implementations that
> have sizeof(list<int>) == sizeof(int*).  But as far as I know, on those
> implementations there is typically at least 3 more words of overhead
> that are put on the heap.

If this is not done until the list first becomes non-empty,
that could be a significant saving, if the programmer
expected that an empty list was as cheap as a null pointer.



---
[ 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.research.att.com/~austern/csc/faq.html                ]

1. list should have stable_sort() as well as sort().
2. All of the other std containers should have
   sort() and stable_sort() member functions that
   sort the entire container.

Optional:

3. All std containers should also have member functions
   sort( Container::iterator begin, Container::iterator end )
   stable_sort( Container::iterator begin, Container::iterator end )
   which sort the specified range.

Why?
So templates have a convenient way to sort containers without
knowing if they are lists or not.
And because they are all trivial to implement for those
who are allowed to edit the standard headers.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi,
Dennis Yelle (dennis51@jps.net) wrote:
: 1. list should have stable_sort() as well as sort().

Probably list should have neither of those! Due to the current presence
of 'sort()' in 'std::list' we are probably stuck with that one but it
should be deprecated... To support his approach, the algorithms should
be mandated to use something like 'std::iter_swap()' allowing the
swapping algorithms being implemented in terms of pointer
manipulations. Likewise for other operations changing the order of
elements.

: 2. All of the other std containers should have
:    sort() and stable_sort() member functions that
:    sort the entire container.

Nope! Algorithms are not the business of the containers. The business
of containers is to contain elements. Their business is not to
replicate algorithms.

: 3. All std containers should also have member functions
:    sort( Container::iterator begin, Container::iterator end )
:    stable_sort( Container::iterator begin, Container::iterator end )
:    which sort the specified range.

It depends: Currently, 'std::sort()' is supposed to be a fast sorting
implementation, ie. a variation of Quicksort, probably something like
Introsort (I think this was the name: it is, as far as I understood
basically a Quicksort with the additional property that it turns into
some other sorting algorithm for degenerate cases; that is, it is an
O(n log n) algorithm which happens to be as fast as Quicksort if not
faster). I think that this should not be changed which basically mean
that 'std::sort()' will not be applicable to non-random access
iterators like eg. list iterators.

I think 'std::stable_sort()' is basically merge-sort and thus
applicable to all bidirectional (or even forward) iterators. This
should thus be applicable to all containers.

Now, this would punish the uses random access iterators in algorithms
which just want to accomodate non-random access iterators, too. Thus,
there should probably also be something like 'std::best_sort()' which
is basically 'std::sort()' where applicable and 'std::stable_sort()'
otherwise. The reason to distinguish between 'std::stable_sort() and
'std::best_sort()' is to avoid unexpected performance behavior when
switching between types: A subtle change in the container might
suddenly switch to a considerably inferior algorithm. With
'std::best_sort()' this is what is to be expected and should be clearly
documented.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Ah... I missed this thread when I posted my "Laundry List" article last
night...

"Dietmar Kuehl" <kuehl@ramsen.informatik.uni-konstanz.de> wrote:

> Nope! Algorithms are not the business of the containers. The business
> of containers is to contain elements. Their business is not to
> replicate algorithms.

Yes, yes, and another resounding YES! My point exactly! The existing library
is inconsistent and binds algorithms tightly to specific structures.
Algorithms should be *general* tools that *act* on *data structures*.

This same principle holds for the string<> classes, which are very heavy. A
simple string<> template would be excellent, with string *algorithms* as
independent, generic components.

As it stands, the Standard Library violates the most important C++ tenet:
You don't pay for it if you don't use it. Heavy containers and heavy strings
make programs pay for unnecessary functionality.

--
Scott Robert Ladd
Master of Complexity, Destroyer of Order and Chaos
http://www.coyotegulch.com



---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <heRL6.241084$o9.35381041@typhoon.tampabay.rr.com>, Scott
Robert Ladd <scott@coyotegulch.com> writes
>As it stands, the Standard Library violates the most important C++ tenet:
>You don't pay for it if you don't use it. Heavy containers and heavy strings
>make programs pay for unnecessary functionality.

Yes and No. As these items are templates, a conforming compiler should
(is only allowed to) ONLY instantiate those functions that you actually
use. So where does the fat come in?

It is different for non-template classes.

Now, where the problem is, is that actually writing these overly bloated
template classes (for strings and iostreams) is difficult to get right
because there is too much to do.

The problems I have with the Standard Library are rather different.
Defaulted extra parameters should not be allowed, that is a serious
design error that should be removed (if implementors want extras they
should have a licence to add overloads to functions and function
templates. The second thing that should be yanked out ASAP are
allocators. At the very least, partial specialisations should be
provided that provide optimised containers using what is currently a
default template parameter. I think that partial specialisations can
take advantage of knowing that the allocation policy is the standard
one.

I think the Standard Library suffers from that common characteristic of
engineering that devices get more and more overtly complicated until one
day someone sits down and redoes the design from scratch. Part of that
redesign is to throw away all the 'good ideas' that are not actually
used, or that are only used in special cases.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]