Re: STL::glice vs cstdio
On 1 Jul., 17:03, n...@cam.ac.uk wrote:
In article <b17b6daf-48e2-464d-bcb5-f1e0c71d2...@b35g2000yqi.googlegroups.com>,
=?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.krueg...@googlemail.com> wrote:
Let me first ask a question: According to which
standard (C++98, C++03, C++0x) did you compile your
code? (See below, why)?
C++0x, I am afraid :-( But I checked against examples, tutorials etc.
on the Web and a couple of books to avoid using too much new stuff. Not
ideal, I know, and I really should get hold of a copy of C++03.
Hmmh, this must be a buggy implementation then, because
within C++0x std::gslice_array is a copyable type (see
below).
using namespace std;
I'm not kidding, but did you really write this using-
directive *in front* of the std headers and w/o any
previous namespace std definition? If so, your
compiler must be very tolerant (it should not even
be allowed in C++98 to use a using-directive w/o
a previous namespace definition) and I strongly suggest
to move this directive after the include's.
Thanks for the advice. I can't find that restriction at all in C++0x,
and I can think of no reason that it's necessary, but it costs
nothing to change.
This restriction does still exist in C++0x, because
it violates the grammar:
using-directive:
attribute-specifieropt using namespace ::opt nested-name-
specifieropt namespace-name;
and
namespace-name:
original-namespace-name
namespace-alias
This means that namespace-name must refer to a previously
defined namespace.
As of C++98/03 this code should be ill-formed, because
std::gslice_array is not copyable. You should look
carefully at this, because if the compiler accepts
this, it might just work or - with some bad luck - it
might produce something nasty. This restriction has
been removed as of C++0x, though.
That is almost certainly the problem, then. It's thoroughly shoddy to
generate code that doesn't work with no comment, of a nature that can
be detected statically.
None of the gslice tutorials and descriptions I saw mentioned that
gslice_array is not copyable, which isn't good of them, either.
There is some problem with the old specification and you
could argue that in C++03 there must be a defect because
of this. In fact it was recognized as a library defect, see:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#253
But I know of libraries which *really* (still) declare the
copy-constructor private - as specified in the C++03 standard.
The standard says in all three versions that you meet
undefined behaviour, if the non-const overload of
valarray's operator[](const gslice&) sees degenerate
indices. I did calculate your indices by hand, but
I didn't find a violation of this restriction.
I also checked for normal boundary violations but I
didn't find any. This doesn't mean that there aren't any,
but I want just to give you the best information at
your hands that are available to me.
That is very kind - thanks very much. The reason that there aren't
any is that my base code contains checking against both of those;
I removed it for the example I posted.
Understandable, because you already explained that
you simplified the program to a minimum that still
demonstrated the defect.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]