Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: copying an aggregate (array)
209 views
Skip to first unread message
Richard Damon
Nov 26, 2017, 7:21:53 AM11/26/17
to
On 11/26/17 12:35 AM, Stefan Ram wrote:
> I compile with gcc, but then also ask clang to have a look
> at my source code. Today, I saw this:
>
> main.cpp
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> using namespace ::std::literals;
>
> int main()
> { ::std::string const b[ 3 ]{ "a"s, "b"s, "c"s };
> ::std::string const a[ 3 ]= b;
>
> ::std::cout << R"(")" <<
> a[ 0 ]<< R"(", ")" <<
> a[ 1 ]<< R"(", ")" <<
> a[ 2 ]<< "\".\n"s; }
>
> transcript
>
> "a", "b", "c".
> main.cpp:9:23: error: array initializer must be an initializer list [clang-diagnostic-error]
> ::std::string const a[ 3 ]= b;
> ^
>
> What is this? gcc compiled and executed the program without
> a diagnostic message, and then clang says there is an error?
>
a is a raw array of string.
By the standard, you can initialize an array, but not with another array
value, only with a list of values (like you did with b);
gcc has an extension that allows array assignment, which also covers
this case.
It you had run gcc with the appropriate options, it would have warned
you that you were using an extension (gcc does not default to being a
conforming compiler).
> I compile with gcc, but then also ask clang to have a look
> at my source code. Today, I saw this:
>
> main.cpp
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> using namespace ::std::literals;
>
> int main()
> { ::std::string const b[ 3 ]{ "a"s, "b"s, "c"s };
> ::std::string const a[ 3 ]= b;
>
> ::std::cout << R"(")" <<
> a[ 0 ]<< R"(", ")" <<
> a[ 1 ]<< R"(", ")" <<
> a[ 2 ]<< "\".\n"s; }
>
> transcript
>
> "a", "b", "c".
> main.cpp:9:23: error: array initializer must be an initializer list [clang-diagnostic-error]
> ::std::string const a[ 3 ]= b;
> ^
>
> What is this? gcc compiled and executed the program without
> a diagnostic message, and then clang says there is an error?
>
a is a raw array of string.
By the standard, you can initialize an array, but not with another array
value, only with a list of values (like you did with b);
gcc has an extension that allows array assignment, which also covers
this case.
It you had run gcc with the appropriate options, it would have warned
you that you were using an extension (gcc does not default to being a
conforming compiler).
Alf P. Steinbach
Nov 27, 2017, 3:09:58 AM11/27/17
to
On 11/26/2017 6:35 AM, Stefan Ram wrote:
> I compile with gcc, but then also ask clang to have a look
> at my source code. Today, I saw this:
>
> main.cpp
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> using namespace ::std::literals;
>
> int main()
> { ::std::string const b[ 3 ]{ "a"s, "b"s, "c"s };
> ::std::string const a[ 3 ]= b;
>
> ::std::cout << R"(")" <<
> a[ 0 ]<< R"(", ")" <<
> a[ 1 ]<< R"(", ")" <<
> a[ 2 ]<< "\".\n"s; }
>
> transcript
>
> "a", "b", "c".
> main.cpp:9:23: error: array initializer must be an initializer list [clang-diagnostic-error]
> ::std::string const a[ 3 ]= b;
> ^
>
> What is this?
No such thing as direct raw array copying in standard C++.
> I compile with gcc, but then also ask clang to have a look
> at my source code. Today, I saw this:
>
> main.cpp
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> using namespace ::std::literals;
>
> int main()
> { ::std::string const b[ 3 ]{ "a"s, "b"s, "c"s };
> ::std::string const a[ 3 ]= b;
>
> ::std::cout << R"(")" <<
> a[ 0 ]<< R"(", ")" <<
> a[ 1 ]<< R"(", ")" <<
> a[ 2 ]<< "\".\n"s; }
>
> transcript
>
> "a", "b", "c".
> main.cpp:9:23: error: array initializer must be an initializer list [clang-diagnostic-error]
> ::std::string const a[ 3 ]= b;
> ^
>
> What is this?
> gcc compiled and executed the program without
> a diagnostic message,
> and then clang says there is an error?
Raw array copying is supported for raw arrays as data members, e.g. as
in `std::array`.
#include <array>
#include <iostream>
#include <string>
using namespace std;
auto main()
-> int
{
const array<string, 3> b{ "a", "b", "c" };
const array<string, 3> a = b;
cout
<< "\""
<< a[0] << ", "
<< a[1] << ", "
<< a[2]
<< "\"." << endl;
}
In this rewrite:
• Including <ostream> is not formally necessary with C++11 and later, so
that's not done here.
• Explicitly converting the initializer items to `string` is also
unnecessary, so that's not done here.
• Using raw string literals is unnecessary, so that's not done here.
And of course, prefixing all standard library items with `::std::` is
unnecessary.
Cheers & hth.,
- ALf
leigh.v....@googlemail.com
Nov 27, 2017, 7:33:02 AM11/27/17
to
"::std::" prefix is unnecessary but "std::" isn't as "using namespace std;" is egregious.
/Leigh
/Leigh
James Kuyper
Nov 27, 2017, 10:53:43 PM11/27/17
to
On 11/27/2017 07:32 AM, leigh.v....@googlemail.com wrote:
> "::std::" prefix is unnecessary but "std::" isn't as "using namespace std;" is egregious.
I've heard that claim before, but I admit to being confused by it. The
> "::std::" prefix is unnecessary but "std::" isn't as "using namespace std;" is egregious.
following code compiles without warning or error messages and produces
exactly the result that I expect, based upon the assumption that ::std::
IS necessary, at least in some circumstances. Have I misunderstood
something?
#include <cstdio>
namespace kuyper {
namespace std {
void printf(const char *) { return;}
}
void func(void)
{
std::printf("Fake printf\n");
::std::printf("Real printf\n");
}
}
int main(void)
{
kuyper::func();
return 0;
}
Alf P. Steinbach
Nov 28, 2017, 12:40:48 AM11/28/17
to
But that doesn't mean that Leigh is right about `using namespace std;`
always being ungood. That's like thinking pointers are always ungood,
say. To build a skyscraper in the same way as a small toy dollhouse,
just to be able to follow a simple set of mechanical rules for tool usage.
The way I look at code is more like overall structure first, and then
the details attach into slots of that structure here and there, for
whatever I look closer at. Some programmers say that verbosity with
everything qualified everywhere brings clarity, but that doesn't work
for me: it's just distracting redundancy. I guess they're focused on one
very tiny piece of code at a time, and then find it problematic to deal
with an unqualified `distance`, say, which, with a sufficiently narrowed
view just could be `std::distance`, or something else.
Cheers!,
- Alf
Juha Nieminen
Nov 28, 2017, 2:19:58 AM11/28/17
to
James Kuyper <james...@verizon.net> wrote:
> I've heard that claim before, but I admit to being confused by it. The
> following code compiles without warning or error messages and produces
> exactly the result that I expect, based upon the assumption that ::std::
> IS necessary, at least in some circumstances. Have I misunderstood
> something?
Does the standard allow using the name 'std' for a namespace other
> I've heard that claim before, but I admit to being confused by it. The
> following code compiles without warning or error messages and produces
> exactly the result that I expect, based upon the assumption that ::std::
> IS necessary, at least in some circumstances. Have I misunderstood
> something?
than the standard one? (I honestly don't know.)
Juha Nieminen
Nov 28, 2017, 2:25:17 AM11/28/17
to
Stefan Ram <r...@zedat.fu-berlin.de> wrote:
> using namespace ::std;
>
> : even Bjarne Stroustrup uses it in his books. So it should
> be accepted for tutorial examples or small or short-lived
> programs. (I still do not use it in my own tutorial.)
The irony is that with very small snippets of code, using that
line often makes the code *longer*, not shorter.
Also, it doesn't increase readability. It only decreases it.
For some reason I can't really comprehend, many people have this
obstinate notion that using the "std::" previx somehow makes the
code harder to read. I have yet to see any of them giving a good
argument why. They just don't like it... because they don't like
it, period. No good reason.
In actuality the "std::" prefix works as a visual hint that
"a standard library name is being used here". It's a bit like
code coloring. It helps recognize standard library names with
a quick visual scan. Also, with names you don't recognize it
immediately tells you that it's a name from the standard library,
not some user-declared name somewhere else.
One some guy tried to prove that the "std::" prefix makes the
code unreadable and ugly by concocting a short piece of code
with something like ten uses of a standard library name.
Ironically, the version with the "std::" prefixes was actually
easier to understand than the one without them.
> using namespace ::std;
>
> : even Bjarne Stroustrup uses it in his books. So it should
> be accepted for tutorial examples or small or short-lived
> programs. (I still do not use it in my own tutorial.)
The irony is that with very small snippets of code, using that
line often makes the code *longer*, not shorter.
Also, it doesn't increase readability. It only decreases it.
For some reason I can't really comprehend, many people have this
obstinate notion that using the "std::" previx somehow makes the
code harder to read. I have yet to see any of them giving a good
argument why. They just don't like it... because they don't like
it, period. No good reason.
In actuality the "std::" prefix works as a visual hint that
"a standard library name is being used here". It's a bit like
code coloring. It helps recognize standard library names with
a quick visual scan. Also, with names you don't recognize it
immediately tells you that it's a name from the standard library,
not some user-declared name somewhere else.
One some guy tried to prove that the "std::" prefix makes the
code unreadable and ugly by concocting a short piece of code
with something like ten uses of a standard library name.
Ironically, the version with the "std::" prefixes was actually
easier to understand than the one without them.
Ian Collins
Nov 28, 2017, 3:00:16 AM11/28/17
to
On 11/28/2017 07:03 PM, Stefan Ram wrote:
>
> ::std::xyz
>
> means:
>
> "The name »xyz« from /the/ famous global std namespace."
>
> , while
>
> std::xyz
>
> means:
>
> "The name "xyz" from /any/ namespace "std" that happens
> to in the scope of the usage of this expression".
>
> Maybe the second possibility is a good thing sometimes,
> when one wants to assign custom meanings to std::-names?
As Alf says, no one names a namespace `std`.
--
Ian.
> James Kuyper <james...@verizon.net> writes:
>> exactly the result that I expect, based upon the assumption that ::std::
>> IS necessary, at least in some circumstances. Have I misunderstood
>
> There is a conceptual difference:
>> exactly the result that I expect, based upon the assumption that ::std::
>> IS necessary, at least in some circumstances. Have I misunderstood
>
>
> ::std::xyz
>
> means:
>
> "The name »xyz« from /the/ famous global std namespace."
>
> , while
>
> std::xyz
>
> means:
>
> "The name "xyz" from /any/ namespace "std" that happens
> to in the scope of the usage of this expression".
>
> Maybe the second possibility is a good thing sometimes,
> when one wants to assign custom meanings to std::-names?
As Alf says, no one names a namespace `std`.
--
Ian.
David Brown
Nov 28, 2017, 3:39:46 AM11/28/17
to
>> exactly the result that I expect, based upon the assumption that ::std::
>> IS necessary, at least in some circumstances. Have I misunderstood
>
>> IS necessary, at least in some circumstances. Have I misunderstood
>
> There is a conceptual difference:
>
> ::std::xyz
>
> means:
>
> "The name »xyz« from /the/ famous global std namespace."
>
> , while
>
> std::xyz
>
> means:
>
> "The name "xyz" from /any/ namespace "std" that happens
> to in the scope of the usage of this expression".
Surely every C++ programmer knows not to make their own namespaces
>
> ::std::xyz
>
> means:
>
> "The name »xyz« from /the/ famous global std namespace."
>
> , while
>
> std::xyz
>
> means:
>
> "The name "xyz" from /any/ namespace "std" that happens
> to in the scope of the usage of this expression".
called "std" ? There is no value in uglifying all your code to help
with a problem that does not exist.
>
> Maybe the second possibility is a good thing sometimes,
> when one wants to assign custom meanings to std::-names?
>
std::swap. And then you want to be sure that you get that overload
/every/ time.
> ~~
>
> WRT
>
> using namespace ::std;
>
> : even Bjarne Stroustrup uses it in his books. So it should
> be accepted for tutorial examples or small or short-lived
> programs. (I still do not use it in my own tutorial.)
>
Code snippets in books are not examples of good real-world code. They
> using namespace ::std;
>
> : even Bjarne Stroustrup uses it in his books. So it should
> be accepted for tutorial examples or small or short-lived
> programs. (I still do not use it in my own tutorial.)
>
are to show a particular feature under discussion at the time.
> ~~
>
> Pastability
>
> A snippet like
>
> ::std::cout << 22 << '\n';
>
> can be copied to every place:
>
> - No need to verify that there is a
> »using namespace ::std;« at the beginning
Yes, and "std::cout" can be pasted without verifying that "using
namespace std;" is in action.
No one argues against having the "std::" namespace prefix (sometimes you
want it, sometimes you want a "using"). But almost everyone disagrees
with your use of "::std::" instead of the normal "std::".
>
> - No need to verify that there is no
> (and will never be) another namespace
> "std" in the vicinity.
Have you ever seen any code that has its own "std" namespace with its
own identifiers, making "::std::" necessary?
>
> A snippet like »cout << 22 << '\n'« would be more "fragile".
>
David Brown
Nov 28, 2017, 3:47:48 AM11/28/17
to
17.6.4.2.1
1
Overview
[constraints]
Namespace std
[namespace.std]
C++
The behavior of a
program is undefined if it adds declarations or definitions to namespace
std or to a
namespace within namespace std unless otherwise specified. A program may
add a template specialization
for any standard library template to namespace std only if the
declaration depends on a user-defined type
and the specialization meets the standard library requirements for the
original template and is not explicitly
prohibited.
I also had a quick look at some C++ standard library headers (from a gcc
installation). They are full of "std::", with the occasional
function-local using clause like "using std::swap;". Only once, in the
whole directory of include files, did I find "::std::" - it occurs in
"functional" and does not appear to be used intentionally.
So on at least one major C++ compiler, the whole standard library could
break if someone has been messing with "std" namespaces in such a way
that "::std::" will work but "std::" will not.
James R. Kuyper
Nov 28, 2017, 11:37:01 AM11/28/17
to
On 11/28/2017 12:40 AM, Alf P. Steinbach wrote:
> On 11/28/2017 4:53 AM, James Kuyper wrote:
>> On 11/27/2017 07:32 AM, leigh.v....@googlemail.com wrote:
>>> "::std::" prefix is unnecessary but "std::" isn't as "using namespace std;" is egregious.
>>
>> I've heard that claim before, but I admit to being confused by it. The
>> following code compiles without warning or error messages and produces
>> exactly the result that I expect, based upon the assumption that ::std::
>> IS necessary, at least in some circumstances. Have I misunderstood
>> something?
>>
>>
>> #include <cstdio>
>> namespace kuyper {
>> namespace std {
>> void printf(const char *) { return;}
>>
>> }
>> void func(void)
>> {
>> std::printf("Fake printf\n");
>> ::std::printf("Real printf\n");
>> }
>> }
>>
>> int main(void)
>> {
>> kuyper::func();
>> return 0;
>> }
>>
>
> No-one names a namespace `std`.
I'm not interested in common practice. Does the standard say anything to
> On 11/28/2017 4:53 AM, James Kuyper wrote:
>> On 11/27/2017 07:32 AM, leigh.v....@googlemail.com wrote:
>>> "::std::" prefix is unnecessary but "std::" isn't as "using namespace std;" is egregious.
>>
>> I've heard that claim before, but I admit to being confused by it. The
>> following code compiles without warning or error messages and produces
>> exactly the result that I expect, based upon the assumption that ::std::
>> IS necessary, at least in some circumstances. Have I misunderstood
>> something?
>>
>>
>> #include <cstdio>
>> namespace kuyper {
>> namespace std {
>> void printf(const char *) { return;}
>>
>> }
>> void func(void)
>> {
>> std::printf("Fake printf\n");
>> ::std::printf("Real printf\n");
>> }
>> }
>>
>> int main(void)
>> {
>> kuyper::func();
>> return 0;
>> }
>>
>
> No-one names a namespace `std`.
prohibit a user-defined namespace named "std" anywhere other than the
global namespace? I looked, and couldn't find any such prohibition - but
it's a big, complex standard, and I might not have looked in the right
location.
James R. Kuyper
Nov 28, 2017, 11:39:50 AM11/28/17
to
On 11/28/2017 03:47 AM, David Brown wrote:
> On 28/11/17 08:19, Juha Nieminen wrote:
>> James Kuyper <james...@verizon.net> wrote:
>>> I've heard that claim before, but I admit to being confused by it. The
>>> following code compiles without warning or error messages and produces
>>> exactly the result that I expect, based upon the assumption that ::std::
>>> IS necessary, at least in some circumstances. Have I misunderstood
>>> something?
>>
>> Does the standard allow using the name 'std' for a namespace other
>> than the standard one? (I honestly don't know.)
>>
>
> I found this in the C++14 standard:
>
> 17.6.4.2.1
> 1
> Overview
> [constraints]
> Namespace std
> [namespace.std]
> C++
> The behavior of a
> program is undefined if it adds declarations or definitions to namespace
> std or to a
> namespace within namespace std unless otherwise specified.
That does not cover the case of a user-defined namespace named std
> On 28/11/17 08:19, Juha Nieminen wrote:
>> James Kuyper <james...@verizon.net> wrote:
>>> I've heard that claim before, but I admit to being confused by it. The
>>> following code compiles without warning or error messages and produces
>>> exactly the result that I expect, based upon the assumption that ::std::
>>> IS necessary, at least in some circumstances. Have I misunderstood
>>> something?
>>
>> Does the standard allow using the name 'std' for a namespace other
>> than the standard one? (I honestly don't know.)
>>
>
> I found this in the C++14 standard:
>
> 17.6.4.2.1
> 1
> Overview
> [constraints]
> Namespace std
> [namespace.std]
> C++
> The behavior of a
> program is undefined if it adds declarations or definitions to namespace
> std or to a
> namespace within namespace std unless otherwise specified.
within a user-defined namespace.
Bo Persson
Nov 28, 2017, 12:32:24 PM11/28/17
to
jump off a cliff. Still bad ideas.
The standard practice IS that if you do this, and your co-workers find
that out after days of debugging - they are likely to bring their
baseball bats when they come visit you.
So just don't do this!
Bo Persson
James R. Kuyper
Nov 28, 2017, 12:49:53 PM11/28/17
to
to the point I'm asking about.
Richard
Nov 28, 2017, 1:29:24 PM11/28/17
to
[Please do not mail me a copy of your followup]
"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<ovissa$6t3$1...@dont-email.me> thusly:
>But that doesn't mean that Leigh is right about `using namespace std;`
>always being ungood. [...]
There's one case where I thought it was mandatory: allowing ADL to
select between your custom implementation of swap and std::swap.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<ovissa$6t3$1...@dont-email.me> thusly:
>But that doesn't mean that Leigh is right about `using namespace std;`
There's one case where I thought it was mandatory: allowing ADL to
select between your custom implementation of swap and std::swap.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Öö Tiib
Nov 28, 2017, 1:34:45 PM11/28/17
to
fully qualified name of any name x of standard library is ::std::x unless explicitly described otherwise.
Usage of the name std for anything can in practice still get ones work
contract ended as deliberately confusing others and hampering team-work.
Öö Tiib
Nov 28, 2017, 1:48:15 PM11/28/17
to
On Tuesday, 28 November 2017 20:29:24 UTC+2, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
> <ovissa$6t3$1...@dont-email.me> thusly:
>
> >But that doesn't mean that Leigh is right about `using namespace std;`
> >always being ungood. [...]
>
> There's one case where I thought it was mandatory: allowing ADL to
> select between your custom implementation of swap and std::swap.
The examples in standard about swappability seem all to use
> [Please do not mail me a copy of your followup]
>
> "Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
> <ovissa$6t3$1...@dont-email.me> thusly:
>
> >But that doesn't mean that Leigh is right about `using namespace std;`
> >always being ungood. [...]
>
> There's one case where I thought it was mandatory: allowing ADL to
> select between your custom implementation of swap and std::swap.
"using std::swap;" for that purpose (instead of "using namespace std;"
or "using ::std::swap;")
Christian Gollwitzer
Nov 29, 2017, 1:41:14 AM11/29/17
to
Am 28.11.17 um 08:25 schrieb Juha Nieminen:
is confusing. Compare:
(std::sin(q*r) + q*r*std::cos(q*r)) / std::exp(-q*std::pow(r,2))
(sin(q*r) + q*r*cos(qr)) / exp(-q*pow(r,2))
The second one is not only shorter, but closer to the formula as you
read it in textbooks and papers. And if you want to substitute the type,
e.g. for automatic differentiation, you need to drop th std:: because
the functions are overloaded outside of std::.
What is the correct way to do that? Include "math.h" instead of cmath?
using std::sin; using std::cos; ... ?
Actually, I'd love to have
using std::mathfunctions;
which import the basic trigonometric functions.
Christian
> For some reason I can't really comprehend, many people have this
> obstinate notion that using the "std::" previx somehow makes the
> code harder to read. I have yet to see any of them giving a good
> argument why. They just don't like it... because they don't like
> it, period. No good reason.
It's partly a matter of taste, but for math functions I'd say that std::
> obstinate notion that using the "std::" previx somehow makes the
> code harder to read. I have yet to see any of them giving a good
> argument why. They just don't like it... because they don't like
> it, period. No good reason.
is confusing. Compare:
(std::sin(q*r) + q*r*std::cos(q*r)) / std::exp(-q*std::pow(r,2))
(sin(q*r) + q*r*cos(qr)) / exp(-q*pow(r,2))
The second one is not only shorter, but closer to the formula as you
read it in textbooks and papers. And if you want to substitute the type,
e.g. for automatic differentiation, you need to drop th std:: because
the functions are overloaded outside of std::.
What is the correct way to do that? Include "math.h" instead of cmath?
using std::sin; using std::cos; ... ?
Actually, I'd love to have
using std::mathfunctions;
which import the basic trigonometric functions.
Christian
David Brown
Nov 29, 2017, 3:19:34 AM11/29/17
to
namespace "std" (or "::std") and namespaces nested within it, but not on
namespaces called "std" that are nested within other namespaces. The
(global) namespace "posix" is also reserved from use by user code.
Gareth Owen
Nov 29, 2017, 2:30:46 PM11/29/17
to
Well, I've been commissioned to write an app for a clap clinic
Öö Tiib
Nov 29, 2017, 3:16:49 PM11/29/17
to
transmitted infections" as STD and wants separate namespace
for those ... then perhaps write your app in Java. :p
Richard
Nov 29, 2017, 5:48:33 PM11/29/17
to
[Please do not mail me a copy of your followup]
(Richard) legaliz...@mail.xmission.com spake the secret code
<ovk9td$u12$1...@news.xmission.com> thusly:
>"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
><ovissa$6t3$1...@dont-email.me> thusly:
>
>>But that doesn't mean that Leigh is right about `using namespace std;`
>>always being ungood. [...]
>
>There's one case where I thought it was mandatory: allowing ADL to
>select between your custom implementation of swap and std::swap.
and not 'using namespace std;'.
woodb...@gmail.com
Nov 29, 2017, 11:28:38 PM11/29/17
to
ready to have some of his code reviewed, if he hasn't already
figured it out from reading the code base, he should be told
to add the :: prefix. I see it as defensive programming.
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
David Brown
Nov 30, 2017, 2:49:29 AM11/30/17
to
in a style is higher priority than any particular decision about style
(unless that decision is truly idiotic).
But Öö said that using the identifier "std" for anything other than the
standard global namespace should be a firing offence - he did not say
that using "::std" should get you fired.
> I see it as defensive programming.
>
that putting copper bands over all the trees in your garden is
"defending against lightening strikes".
There are some kinds of coding where that level of "make sure everything
works, no matter what other people do" is justified. You can look in
some implementation library headers and see pervasive use of identifiers
like "__x" rather than "x". This is because it is legal in C and C++ to
have "#define x int" (or whatever) before including the header - and the
header should work no matter what the user does, as long as the
standards allow it. But that sort of thing makes the code messier and
harder to follow - it comes at a price, and it is only appropriate in
very specific circumstances.
Similarly, the use of "::std" might be justified within the standard
headers. In normal coding, it serves only to cause confusion (by being
different from almost all other C++ programmers) and make code messier.
I have only looked at the C++ headers for one compiler - gcc - but they
use "std" almost exclusively. There is only one use of "::std" that I
can see, and that looks like a mistake.
Öö Tiib
Nov 30, 2017, 3:05:42 AM11/30/17
to
If you defend against name "std" really misused then you defend against
mythological thing. Who had real clown in their team who really named
something as "std" in their production C++ code-base? Why? When? Where?
What problems it caused? How it was resolved? I haven't seen or heard
about that during the very decades, no urban legends nor fiction, nothing.
If you defend against sabotage in general then you defend against
what sometimes happens and against that there are no defenses.
If programmer wants to disrupt C++ project or turn it into hard to
debug and maintain then they can do it in countless less palpable ways.
Risk of such enemy in your ranks can not be mitigated by "defensive
programming".
What are the most hard and annoying debugging problems? These are
when program only rarely does something incorrect. Gives wrong
results for unknown reasons. Nothing actually neither crashes nor
hangs because of that just results are wrong. Bonus points for being
disguised as typo in reasonable-looking code and being not reproducible
with same input data. Resulting program is untrustworthy and so useless.
That is what good antagonist would implement in your software and not
other namespace named "std".
I would buy if you said that "::std" is beautiful for your eyes
but as "defense" it is clearly pointless erosion of colon key.
Öö Tiib
Nov 30, 2017, 4:49:35 AM11/30/17
to
On Thursday, 30 November 2017 09:49:29 UTC+2, David Brown wrote:
> On 30/11/17 05:28, woodb...@gmail.com wrote:
> >
> > If the team uses the :: prefix, then when a new person is
> > ready to have some of his code reviewed, if he hasn't already
> > figured it out from reading the code base, he should be told
> > to add the :: prefix.
>
> Clearly the standard used by an existing team is important - consistency
> in a style is higher priority than any particular decision about style
> (unless that decision is truly idiotic).
>
> But Öö said that using the identifier "std" for anything other than the
> standard global namespace should be a firing offence - he did not say
> that using "::std" should get you fired.
Exactly. I see "::std" pointless. I still would write it if that was coding
> On 30/11/17 05:28, woodb...@gmail.com wrote:
> >
> > If the team uses the :: prefix, then when a new person is
> > ready to have some of his code reviewed, if he hasn't already
> > figured it out from reading the code base, he should be told
> > to add the :: prefix.
>
> Clearly the standard used by an existing team is important - consistency
> in a style is higher priority than any particular decision about style
> (unless that decision is truly idiotic).
>
> But Öö said that using the identifier "std" for anything other than the
> standard global namespace should be a firing offence - he did not say
> that using "::std" should get you fired.
standard. Consistency and "because we do it that way" are strong
reasons for me. Doing something slightly pointless is fine for
consistency and unity.
I argue against people who say that the "::std" helps against
actual, real problem. That is disinformation. They never provide
evidence. They even NEVER compose any fiction. How that
"problem" really did sting their or someone else's fanny? How
it took weeks to cure the swollen buttocks? Nada. Nil. Nothing.
So not worth to follow.
asetof...@gmail.com
Nov 30, 2017, 5:56:02 AM11/30/17
to
I find that hide(nascondere) it is the main problem C++ has
Juha Nieminen
Dec 1, 2017, 1:40:54 AM12/1/17
to
James R. Kuyper <james...@verizon.net> wrote:
> That does not cover the case of a user-defined namespace named std
> within a user-defined namespace.
Maybe this is an omission in the standard. I think that it should be
> That does not cover the case of a user-defined namespace named std
> within a user-defined namespace.
specific about this (ie. either forbidding it, or specifically
allowing it).
Anybody has any contacts in the standardization committee, so they could
send a comment about this?
James R. Kuyper
Dec 1, 2017, 10:37:02 AM12/1/17
to
On 12/01/2017 01:40 AM, Juha Nieminen wrote:
> James R. Kuyper <james...@verizon.net> wrote:
>> That does not cover the case of a user-defined namespace named std
>> within a user-defined namespace.
>
> Maybe this is an omission in the standard. I think that it should be
> specific about this (ie. either forbidding it, or specifically
> allowing it).
If the intent were to allow it, it would be contrary to the way the
> James R. Kuyper <james...@verizon.net> wrote:
>> That does not cover the case of a user-defined namespace named std
>> within a user-defined namespace.
>
> Maybe this is an omission in the standard. I think that it should be
> specific about this (ie. either forbidding it, or specifically
> allowing it).
standard is normally written to specifically say so. There's a general
rule that allows creation of user-named name spaces, and as far as I can
see, there's no exception to that rule for one that is named "std". The
namespace ::std is already defined by the standard, and there are
explicit rules governing what a program can do in that namespace, but I
believe it says nothing about, for example, ::kuyper::std. if I'm right
about that, that's sufficient to allow such a namespace.
woodb...@gmail.com
Dec 1, 2017, 12:51:20 PM12/1/17
to
On Friday, December 1, 2017 at 12:40:54 AM UTC-6, Juha Nieminen wrote:
>
> Maybe this is an omission in the standard. I think that it should be
> specific about this (ie. either forbidding it, or specifically
> allowing it).
>
> Anybody has any contacts in the standardization committee, so they could
> send a comment about this?
I haven't found it difficult to find email addresses for
>
> Maybe this is an omission in the standard. I think that it should be
> specific about this (ie. either forbidding it, or specifically
> allowing it).
>
> Anybody has any contacts in the standardization committee, so they could
> send a comment about this?
people on the committee. For the most part, they have
replied to my emails.
With a lot of things slipping through the cracks for C++
2017, I think the committee is under pressure to not blow it
again for C++ 2020. So I'm not sure how interested they
would be in this matter.
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
James Kuyper
Dec 2, 2017, 3:19:07 PM12/2/17
to
On 12/01/2017 10:45 PM, Stefan Ram wrote:
> (in this group?) and the common wisdom was then that one may
> not put names into »::std«, but into any other namespace »std«.
>
> I took this for granted for a long time and am surprised that
> you now ask about this. I can't put my finger on a place in
> the C++ specification where this is allowed, but I also think
> that the general idea is that there is a general license to
> put names into namespaces and a restriction regarding »::std«.
I too take it for granted, I ask only because it has been repeatedly
asserted that ::std is pointless and unnecessary, an assertion which
would only make sense to me if std were a reserved identifier for use as
an namespace name. Basically, the response that I've gotten is that std
is, for practical purposes, a reserved identifier - not because code
which violates such a reservation is a constraint violation, but because
delivering such code is likely to get you fired. While I can appreciate
that argument, it's not directly relevant to my point. If it is indeed
such a bad idea to do that, I think it should be identified as a
constraint violation.
So long as it isn't a constraint violation, fully conforming
implementations must accept and correctly translate code which defines
such a namespace, and I get the impression from some of the things that
have been said, that many implementation of the C++ standard library
might malfunction if used with code that defined such a namespace.
> "James R. Kuyper" <james...@verizon.net> writes:
>> believe it says nothing about, for example, ::kuyper::std. if I'm right
>> about that, that's sufficient to allow such a namespace.
>
> I believe that this has been discussed in the Usenet before
>> believe it says nothing about, for example, ::kuyper::std. if I'm right
>> about that, that's sufficient to allow such a namespace.
>
> (in this group?) and the common wisdom was then that one may
> not put names into »::std«, but into any other namespace »std«.
>
> I took this for granted for a long time and am surprised that
> you now ask about this. I can't put my finger on a place in
> the C++ specification where this is allowed, but I also think
> that the general idea is that there is a general license to
> put names into namespaces and a restriction regarding »::std«.
I too take it for granted, I ask only because it has been repeatedly
asserted that ::std is pointless and unnecessary, an assertion which
would only make sense to me if std were a reserved identifier for use as
an namespace name. Basically, the response that I've gotten is that std
is, for practical purposes, a reserved identifier - not because code
which violates such a reservation is a constraint violation, but because
delivering such code is likely to get you fired. While I can appreciate
that argument, it's not directly relevant to my point. If it is indeed
such a bad idea to do that, I think it should be identified as a
constraint violation.
So long as it isn't a constraint violation, fully conforming
implementations must accept and correctly translate code which defines
such a namespace, and I get the impression from some of the things that
have been said, that many implementation of the C++ standard library
might malfunction if used with code that defined such a namespace.
Chris Vine
Dec 2, 2017, 4:56:45 PM12/2/17
to
programming practice, nor for that matter every possible case of
malicious coding by a psychopathic programmer, if that is what you mean
by "constraint violation". How long do you want the standard to be?
Only an incompetent or malicious programmer would place a 'std'
namespace within another namespace given current coding practices,
which treat 'std' as being at the top level. If a project is so
concerned about this it could put that in its coding standard for the
project, but the idea of using 'std' in this way is so outlandish that
I would view it as unnecessary.
Writing code in any language requires programmers to behave reasonably
and in accordance with coding standards for the project in question.
If they try to sabotage the project you fire them. That seems
perfectly reasonable to me.
Chris
James Kuyper
Dec 2, 2017, 6:15:35 PM12/2/17
to
On 12/02/2017 04:56 PM, Chris Vine wrote:
> On Sat, 2 Dec 2017 15:18:47 -0500
> James Kuyper <james...@verizon.net> wrote:
>> On 12/01/2017 10:45 PM, Stefan Ram wrote:
>>> "James R. Kuyper" <james...@verizon.net> writes:
>>>> believe it says nothing about, for example, ::kuyper::std. if I'm
>>>> right about that, that's sufficient to allow such a namespace.
...
> On Sat, 2 Dec 2017 15:18:47 -0500
> James Kuyper <james...@verizon.net> wrote:
>> On 12/01/2017 10:45 PM, Stefan Ram wrote:
>>> "James R. Kuyper" <james...@verizon.net> writes:
>>>> believe it says nothing about, for example, ::kuyper::std. if I'm
>>>> right about that, that's sufficient to allow such a namespace.
>> I too take it for granted, I ask only because it has been repeatedly
>> asserted that ::std is pointless and unnecessary, an assertion which
>> would only make sense to me if std were a reserved identifier for use
>> as an namespace name. Basically, the response that I've gotten is
>> that std is, for practical purposes, a reserved identifier - not
>> because code which violates such a reservation is a constraint
>> violation, but because delivering such code is likely to get you
>> fired. While I can appreciate that argument, it's not directly
>> relevant to my point. If it is indeed such a bad idea to do that, I
>> think it should be identified as a constraint violation.
>> So long as it isn't a constraint violation, fully conforming
>> implementations must accept and correctly translate code which defines
>> such a namespace, and I get the impression from some of the things
>> that have been said, that many implementation of the C++ standard
>> library might malfunction if used with code that defined such a
>> namespace.
>
> The C++ standard cannot explicitly rule out every case of bad
> programming practice, nor for that matter every possible case of
> malicious coding by a psychopathic programmer, if that is what you mean
> by "constraint violation".
I tend to spend most of my time on the C newsgroups; I forgot that
>> asserted that ::std is pointless and unnecessary, an assertion which
>> would only make sense to me if std were a reserved identifier for use
>> as an namespace name. Basically, the response that I've gotten is
>> that std is, for practical purposes, a reserved identifier - not
>> because code which violates such a reservation is a constraint
>> violation, but because delivering such code is likely to get you
>> fired. While I can appreciate that argument, it's not directly
>> relevant to my point. If it is indeed such a bad idea to do that, I
>> think it should be identified as a constraint violation.
>> So long as it isn't a constraint violation, fully conforming
>> implementations must accept and correctly translate code which defines
>> such a namespace, and I get the impression from some of the things
>> that have been said, that many implementation of the C++ standard
>> library might malfunction if used with code that defined such a
>> namespace.
>
> The C++ standard cannot explicitly rule out every case of bad
> programming practice, nor for that matter every possible case of
> malicious coding by a psychopathic programmer, if that is what you mean
> by "constraint violation".
"constraint violation" is a C-specific term. The key feature of a
constraint that matters in this context is that at least one diagnostic
must be issued for any program that contains any syntax errors or
constraint violations, and that either of those features means that is
an implementation is no longer required to accept the program. The C++
standard imposes the same requirements for any violation of any
diagnosable rule (1.4p2). The C standard distinguishes constraints from
other kinds of rules; the C++ standard makes the same distinction by
specifying, for a large number of different rules, that "no diagnostic
is required" - which seems to me to be a clumsier way of making the same
distinction.
Creation of such a namespace is trivially diagnosable, so I'm just
suggesting that a rule be created prohibiting it - if such a rule
accurately represents what the committee believes the standard should say.
> How long do you want the standard to be?
implementation is required to do. If you believe that a conforming
implementation of the C++ standard library is allowed to use std::
rather than ::std::, even in contexts where such code could break if I
defined a ::kuyper::std namespace, then the standard should explicitly
state, in some fashion, that there's a problem with me defining such a
namespace.
If an implementation of the C++ standard library should be required to
use ::std:: whenever my creation of such a namespace might otherwise
cause something to break, the current wording is sufficient.
> Only an incompetent or malicious programmer would place a 'std'
standard makes about the behavior of my program will still hold, even if
I choose to define ::kuyper::std. If my own code doesn't contain any
constructs for which definition of such a namespace is problematic, that
should be sufficient to have a well-formed program, regardless of how
poorly you might think of me for writing it. This implies that any part
of the C++ standard library that I choose to use in my program must also
avoid any use of constructs that would be broken by my definition of
::kuyper::std.
> namespace within another namespace given current coding practices,
> which treat 'std' as being at the top level. If a project is so
> concerned about this it could put that in its coding standard for the
> project, but the idea of using 'std' in this way is so outlandish that
> I would view it as unnecessary.
code, and I almost certainly wouldn't write such code. But I still
believe that the standard should be clear about whether or not the C++
standard library is required to be written in such a way that it would
not be broken by such code.
> Writing code in any language requires programmers to behave reasonably
> and in accordance with coding standards for the project in question.
project with non-trivial coding standards. All that is actually required
is that the code be, in C++ terms, well-formed, in order to ensure that
it must have the behavior that the relevant standard specifies for such
code. I don't have to be reasonable, and I don't have to conform to
anyone else's coding standards, in order for that requirement to apply.
Alf P. Steinbach
Dec 2, 2017, 9:27:04 PM12/2/17
to
On 12/3/2017 12:15 AM, James Kuyper wrote:
>
> The standard as currently written implies that every guarantee the
> standard makes about the behavior of my program will still hold, even if
> I choose to define ::kuyper::std. If my own code doesn't contain any
> constructs for which definition of such a namespace is problematic, that
> should be sufficient to have a well-formed program, regardless of how
> poorly you might think of me for writing it. This implies that any part
> of the C++ standard library that I choose to use in my program must also
> avoid any use of constructs that would be broken by my definition of
> ::kuyper::std.
I think you need to demonstrate the ability to break the code of some
>
> The standard as currently written implies that every guarantee the
> standard makes about the behavior of my program will still hold, even if
> I choose to define ::kuyper::std. If my own code doesn't contain any
> constructs for which definition of such a namespace is problematic, that
> should be sufficient to have a well-formed program, regardless of how
> poorly you might think of me for writing it. This implies that any part
> of the C++ standard library that I choose to use in my program must also
> avoid any use of constructs that would be broken by my definition of
> ::kuyper::std.
standard library implementation, in order to make this argument plausible.
Cheers!,
- Alf
James Kuyper
Dec 2, 2017, 10:55:48 PM12/2/17
to
got a lot of knowledge about C++, I've relatively little experience
writing it. The way in which such breakage could happen seems quite
obvious to me, but I'm afraid that if I tried to write example code, I'd
mess up one of the subtle details, which would end up being the focus of
the ensuing discussion, ignoring the fact that the subtle detail could
easily be fixed.
The key thing is that C++ standard library templates (whether template
classes or template functions) can be instantiated using user-defined
types. When one of those types appears as the argument of a function,
argument-dependent name lookup (3.4.2) can occur that searches the
namespace that type is defined in. If there's an identifier in
::kuyper::std that is the same as one in ::std, use of std:: will not
resolve the ambiguity as to which one is to be used. Such identifiers
are reserved only in ::std and in the global namespace (17.6.4.3.3p1),
so use of such identifiers in ::kuyper::std should not be problematic,
but it would be if some of the standard C++ library code for such
functions uses std:: instead of ::std::.
Juha Nieminen
Dec 4, 2017, 3:02:02 AM12/4/17
to
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> The C++ standard cannot explicitly rule out every case of bad
> programming practice, nor for that matter every possible case of
> malicious coding by a psychopathic programmer
The standard already states that names beginning with an underscore are
> The C++ standard cannot explicitly rule out every case of bad
> programming practice, nor for that matter every possible case of
> malicious coding by a psychopathic programmer
reserved for the compiler, even tough there's absolutely nothing in the
language preventing the user from breaking that convention. Because it's
just that: A convention established by the standard.
In the same way the standard could say that the namespace 'std', no matter
where it appears (even if inside other namespaces) is reserved for the
standard libraries.
Chris Vine
Dec 4, 2017, 3:28:23 PM12/4/17
to
On Mon, 4 Dec 2017 08:01:42 -0000 (UTC)
Juha Nieminen <nos...@thanks.invalid> wrote
promulgates The Law.
Your summary is not quite right though. The standard prohibits global
names beginning with an underscore, and locals beginning with an
underscore followed by a capital letter or another underscore (or at
least it used to if C++17 has changed that).
> In the same way the standard could say that the namespace 'std', no
> matter where it appears (even if inside other namespaces) is reserved
> for the standard libraries.
It could. But the cases are not equivalent. The rule about
underscores is to enable compilers to be written. Any new rule about
'std' would be to try to prevent assholes from being assholes,
something which is likely to fail.
Chris
Juha Nieminen <nos...@thanks.invalid> wrote
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> > The C++ standard cannot explicitly rule out every case of bad
> > programming practice, nor for that matter every possible case of
> > malicious coding by a psychopathic programmer
>
> The standard already states that names beginning with an underscore
> are reserved for the compiler, even tough there's absolutely nothing
> in the language preventing the user from breaking that convention.
> Because it's just that: A convention established by the standard.
It is coding standards which promulgate conventions. The standard
> > The C++ standard cannot explicitly rule out every case of bad
> > programming practice, nor for that matter every possible case of
> > malicious coding by a psychopathic programmer
>
> The standard already states that names beginning with an underscore
> are reserved for the compiler, even tough there's absolutely nothing
> in the language preventing the user from breaking that convention.
> Because it's just that: A convention established by the standard.
promulgates The Law.
Your summary is not quite right though. The standard prohibits global
names beginning with an underscore, and locals beginning with an
underscore followed by a capital letter or another underscore (or at
least it used to if C++17 has changed that).
> In the same way the standard could say that the namespace 'std', no
> matter where it appears (even if inside other namespaces) is reserved
> for the standard libraries.
underscores is to enable compilers to be written. Any new rule about
'std' would be to try to prevent assholes from being assholes,
something which is likely to fail.
Chris
Mr Flibble
Jan 26, 2018, 4:27:40 PM1/26/18
to
/Flibble
--
"Suppose it’s all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I’d say, bone cancer in children? What’s that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It’s not right, it’s utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That’s what I would say."
Cholo Lennon
Jan 29, 2018, 9:01:31 AM1/29/18
to
On 28/11/17 03:03, Stefan Ram wrote:
>
> ::std::xyz
>
> means:
>
> "The name »xyz« from /the/ famous global std namespace."
>
> , while
>
> std::xyz
>
> means:
>
> "The name "xyz" from /any/ namespace "std" that happens
> to in the scope of the usage of this expression".
>
> Maybe the second possibility is a good thing sometimes,
> when one wants to assign custom meanings to std::-names?
>
> ~~
I suppose here we all know the difference between ::std and std. IMHO
the usage of ::std it has no sense (with only a very few exceptions).
I've been programming in C++ since 1990. Also at my current work I have
to deal with a huge code base with million lines of C++ code and I've
never seen a namespace "std" other than the standard. To summ up: I've
never needed to use ::std! but C'mon Stefan, let's face it, in
'comp.lang.java.programmer' you use "java.lang.String" when "String" is
enough. Of course, in real code there are situations when full type name
is used (security reasons/classloaders for example), but for snippets...
no way.
>
> WRT
>
> using namespace ::std;
>
> : even Bjarne Stroustrup uses it in his books. So it should
> be accepted for tutorial examples or small or short-lived
> programs. (I still do not use it in my own tutorial.)
>
> ~~
>
> Pastability
>
> A snippet like
>
> ::std::cout << 22 << '\n';
>
> can be copied to every place:
>
> - No need to verify that there is a
> »using namespace ::std;« at the beginning
>
> - No need to verify that there is no
> (and will never be) another namespace
> "std" in the vicinity.
>
> A snippet like »cout << 22 << '\n'« would be more "fragile".
>
--
Cholo Lennon
Bs.As.
ARG
> James Kuyper <james...@verizon.net> writes:
>> exactly the result that I expect, based upon the assumption that ::std::
>> IS necessary, at least in some circumstances. Have I misunderstood
>
> There is a conceptual difference:
>> exactly the result that I expect, based upon the assumption that ::std::
>> IS necessary, at least in some circumstances. Have I misunderstood
>
>
> ::std::xyz
>
> means:
>
> "The name »xyz« from /the/ famous global std namespace."
>
> , while
>
> std::xyz
>
> means:
>
> "The name "xyz" from /any/ namespace "std" that happens
> to in the scope of the usage of this expression".
>
> Maybe the second possibility is a good thing sometimes,
> when one wants to assign custom meanings to std::-names?
>
> ~~
I suppose here we all know the difference between ::std and std. IMHO
the usage of ::std it has no sense (with only a very few exceptions).
I've been programming in C++ since 1990. Also at my current work I have
to deal with a huge code base with million lines of C++ code and I've
never seen a namespace "std" other than the standard. To summ up: I've
never needed to use ::std! but C'mon Stefan, let's face it, in
'comp.lang.java.programmer' you use "java.lang.String" when "String" is
enough. Of course, in real code there are situations when full type name
is used (security reasons/classloaders for example), but for snippets...
no way.
>
> WRT
>
> using namespace ::std;
>
> : even Bjarne Stroustrup uses it in his books. So it should
> be accepted for tutorial examples or small or short-lived
> programs. (I still do not use it in my own tutorial.)
>
> ~~
>
> Pastability
>
> A snippet like
>
> ::std::cout << 22 << '\n';
>
> can be copied to every place:
>
> - No need to verify that there is a
> »using namespace ::std;« at the beginning
>
> - No need to verify that there is no
> (and will never be) another namespace
> "std" in the vicinity.
>
> A snippet like »cout << 22 << '\n'« would be more "fragile".
>
--
Cholo Lennon
Bs.As.
ARG
Cholo Lennon
Jan 30, 2018, 7:52:21 AM1/30/18
to
Totally agree.
0 new messages