Prev: Is this ambiguous ? Templates parameter deduction.
Next: member iterator - request for comment
From: Daniel Krügler on 2 Jul 2010 06:15
On 1 Jul., 17:03, n...(a)cam.ac.uk wrote:
> In article <b17b6daf-48e2-464d-bcb5-f1e0c71d2...(a)b35g2000yqi.googlegroups.com>,
>
> =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.krueg...(a)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! ]

From: CornedBee on 2 Jul 2010 09:05
On Jul 1, 5:03 pm, n...(a)cam.ac.uk wrote:
> In article <b17b6daf-48e2-464d-bcb5-f1e0c71d2...(a)b35g2000yqi.googlegroups.com>,
>
>
>
> =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.krueg...(a)googlemail.com> wrote:
>
> >> 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.

Namespace std isn't that special; in particular, it is not implicitly
known to the compiler. As such, like any other namespace name, it must
declared in order to be known to the compiler, and it must be known to
the compiler in order to be usable in a using-directive. The
specification for this is C++'s usual ugly semantic grammar
restriction. The definition of the using directive is

using-directive:
attribute-specifier[opt] 'using' 'namespace' '::'[opt] nested-named-
specifier[opt] namespace-name ';'

And a namespace-name is only a namespace-name if the compiler can
identify it as such. Otherwise it's just an identifier, and therefore
invalid in this grammar.

Sebastian


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on 3 Jul 2010 17:41
CornedBee wrote:
> On Jul 1, 5:03 pm, n...(a)cam.ac.uk wrote:
>> In article <b17b6daf-48e2-464d-bcb5-f1e0c71d2...(a)b35g2000yqi.googlegroups.com>,
>>
>> =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.krueg...(a)googlemail.com> wrote:
>>
>>>> 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.
>
> Namespace std isn't that special; in particular, it is not implicitly
> known to the compiler. As such, like any other namespace name, it must
> declared in order to be known to the compiler, and it must be known to
> the compiler in order to be usable in a using-directive.

Actually that is not strictly true. An implementation is permitted to
have knowledge of all public names in the Standard Library. Indeed the
standard headers need not be files, their contents can be directly known
to the compiler (and the #include only unlocks this knowledge). Does
that matter? Yes because that is why names are reserved to the
implementation. If you use a namespace std that is not the standard one
then all bets are off as regards the behaviour of your program.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Jeffrey Schwab on 4 Jul 2010 05:58
On 7/4/10 4:41 AM, Francis Glassborow wrote:

> If you use a namespace std that is not the standard one
> then all bets are off as regards the behaviour of your program.

Is that true only for ::std, or for any namespace std?

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Francis Glassborow on 5 Jul 2010 04:05
Jeffrey Schwab wrote:
> On 7/4/10 4:41 AM, Francis Glassborow wrote:
>
>> If you use a namespace std that is not the standard one
>> then all bets are off as regards the behaviour of your program.
>
> Is that true only for ::std, or for any namespace std?
>

I think it is just for ::std

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

First  |  Prev  | 
Pages: 1 2
Prev: Is this ambiguous ? Templates parameter deduction.
Next: member iterator - request for comment