Monday, September 3, 2018

Digest for comp.lang.c++@googlegroups.com - 21 updates in 4 topics

Juha Nieminen <nospam@thanks.invalid>: Sep 03 05:22AM

> Common wisdom is that we can use "using namespace" in .cpp files
 
The only situation where "using namespace" ought to be used is to bring the
contents of one namespace into another (and basically never to the global
namespace). And these situations ought to be quite rare.
 
"using namespace std;" should never be used, anywhere. In the extremely few
cases where there might be an argument for bringing a standard library name
into the current scope, only that one name should be done so, not the
entirety of the std namespace. (One example situation where you might want
to bring a standard library name into the current scope is if you are
writing a templated function that, for example, swaps two templated
elements, and you want to support for a custom swap function implementation,
for instance. Thus you would write "using std::swap;" inside that function
and then just "swap(a, b);" But even these situations ought to be rare.)
Juha Nieminen <nospam@thanks.invalid>: Sep 03 05:23AM

> The reason is simple: we can avoid to write "std::" in cpp files with "using namespace std;".
 
Why would you want to avoid that?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 03 09:46AM +0200

On 02.09.2018 23:55, Paavo Helde wrote:
> [snip]
> Well, we can avoid writing std::, but why should we? Losing a lot of
> clarity for ... what? Saving 5 keystrokes?
 
No, it's about reducing visual clutter and verbosity. Reducing that
improves local readability. And improved readability improves global
clarity, the ability to understand the main things at-a-glance.
 
Consider
 
auto d = std::distance(a, b)
 
The `std::` prefix tells you that you can look up the specification of
this function, which will tell you what it computes and the exact type
of `d`.
 
That /possibility of later clarity/ might, to some, associate with
direct clarity, compared to
 
auto d = distance(a, b)
 
... which involves a possibly user-defined function that you possibly
can't look up, e.g. possibly you don't even have the source code.
 
But there are just two main cases:
 
* You are unclear on what `distance` does or produces.
For clarity you will have to look up the function spec. In the case
where `distance` is the standard library's function neither style
helps you do that more easily. E.g. in Visual Studio, place the text
cursor on `distance` and hit F1, that's it, regardless of which style.
 
* You are clear on what `distance` does and produces.
Well.
 
So with the in-your-face clarity of what each individual statement
means, out of the picture, it boils down to: do the namespace prefixes
that introduce more text to read and visually distracting `::` symbols
all over, help readability?
 
For me the `::` symbols and namespace names just reduce readability,
greatly, and thereby reduce global clarity.
 
Some others, maybe that includes you, maintain that for them they do
help readability. I tend to not believe that claim but I don't entirely
dismiss it, because it /can/ conceivably be like a suitable amount of
the right kind of background music can help one focus on a task. I guess
the mechanism is by keeping the otherwise too active parts of the mind
occupied with the music, maybe.
 
So it seems possible that to some degree it's a subjective thing, but I
would be very surprised if Mother Nature has evolved people so that a
majority are helped in their thought processes by having `::` and
redundant namespace names peppered all over the text, as background.
 
 
Cheers!,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Sep 03 04:47PM +0300

On 3.09.2018 10:46, Alf P. Steinbach wrote:
 
> auto d = distance(a, b)
 
> ... which involves a possibly user-defined function that you possibly
> can't look up, e.g. possibly you don't even have the source code.
 
Yes, that's the point. I greatly prefer std::distance(), especially in
case of short lines and single usage like in your example. Especially if
it's in template code and some other 'distance' could be involved,
depending on the types.
 
> where `distance` is the standard library's function neither style
> helps you do that more easily. E.g. in Visual Studio, place the text
> cursor on `distance` and hit F1, that's it, regardless of which style.
 
So I need to perform a special operation in order to clarify something
which could have easily been written clearly in the first place.
 
And yes, if I'm looking at some foreign code or code written by myself
more than 3 months ago, I am always in doubt what it actually does. The
mere fact that I'm looking on it already means it is probably doing
something wrong. Anything which helps me to understand more clearly what
the code exactly does is greatly appreciated at that point.
 
And no, VS does not work nearly as reliably as you suggest (though it
has become better over years). And I don't always have the luxury to
work with an IDE, not to speak about one which can reliably look up symbols.
 
> the right kind of background music can help one focus on a task. I guess
> the mechanism is by keeping the otherwise too active parts of the mind
> occupied with the music, maybe.
 
Your beliefs do not change the reality ;-)
 
Anyway, I suspect that using or not using the std:: prefix usage has
mostly to do with habits. If I see std::max() and std::uint32_t all the
time in the code I get used to them and would feel lost without std::.
It looks like for you it is the opposite.
 
> would be very surprised if Mother Nature has evolved people so that a
> majority are helped in their thought processes by having `::` and
> redundant namespace names peppered all over the text, as background.
 
There is also the issue of namespace length. "std::" is short enough to
write out, some other namespaces not so, especially when used often.
 
There is also the issue of the codebase size and homogeneity. For
example I made a quick search of 'distance' in our codebase and
immediately found a 'double distance(double a, double b);' in a
third-party header.
Vir Campestris <vir.campestris@invalid.invalid>: Sep 03 11:04PM +0100

On 03/09/2018 08:46, Alf P. Steinbach wrote:
 
<snip>
 
> The `std::` prefix tells you that you can look up the specification of
> this function, which will tell you what it computes and the exact type
> of `d`.
 
</snip>
 
And this need to look up is where I differ from some of the eminences of
C++; I use auto only where I have to (type of a lambda, for instance).
 
Looking up the return type of std::distance I can see why you want to
avoid all that typing. But you type it once, and maintain the code for
years.
 
Andy
Juha Nieminen <nospam@thanks.invalid>: Sep 03 05:14AM

>> anymore. (Even if they are, they are definitely not recommended.)
 
> They are and they are still recommended in more than a few coding
> standards (including ours).
 
Does the same coding standard recommend using "using namespace std;"?
 
Doesn't sound like a very good coding standard to me...
 
> If you are going to use C standard library
> functions, you may as will use the C headers.
 
They are C++ standard library functions because they are defined in the
C++ standard. If you are writing C++, use C++ headers.
Ian Collins <ian-news@hotmail.com>: Sep 03 05:34PM +1200

On 03/09/18 17:14, Juha Nieminen wrote:
 
>> They are and they are still recommended in more than a few coding
>> standards (including ours).
 
> Does the same coding standard recommend using "using namespace std;"?
 
No, it forbids it.
 
> Doesn't sound like a very good coding standard to me...
 
It's quite good at a mere page and a bit.
 
>> functions, you may as will use the C headers.
 
> They are C++ standard library functions because they are defined in the
> C++ standard. If you are writing C++, use C++ headers.
 
std::size_t? No thanks!
 
--
Ian.
Juha Nieminen <nospam@thanks.invalid>: Sep 03 06:26AM

>> They are C++ standard library functions because they are defined in the
>> C++ standard. If you are writing C++, use C++ headers.
 
> std::size_t? No thanks!
 
What problem do you find with that? I use it all the time. I have had
no problems with it.
peter koch <peter.koch.larsen@gmail.com>: Sep 03 03:05AM -0700

mandag den 3. september 2018 kl. 07.14.46 UTC+2 skrev Juha Nieminen:
> > standards (including ours).
 
> Does the same coding standard recommend using "using namespace std;"?
 
> Doesn't sound like a very good coding standard to me...
 
Including the CPP versions of C headers does not guarantee that the global namespace is not polluted. I believe that this is a strong argument for preferring the C-headers. How else would you guard yourself against stuff breaking up when e.g. changing between compilers?
 
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 03 11:33AM +0100

On Sun, 2 Sep 2018 20:12:51 +1200
> standards (including ours). If you are going to use C standard library
> functions, you may as will use the C headers. I for one consider the
> C++ wrappers a mistake.
 
It can also be necessary to use the C headers in C++ where the code is
governed by more than one standard. Say you are using the POSIX
function strdup() in your C++ code[1]. That is in the C/POSIX header
string.h.
 
Can you reliably (in a cross-implementation way) call strdup() by
including the cstring header, and if so is strdup() placed in namespace
std? Dunno, strdup() is not incorporated by the C++ standard at any
rate. If you have to include string.h to capture strdup(), are you
really going to include cstring to capture also, say, strcpy() in the
same code?
 
This is not wholly rhetorical. What do other people do?
 
Chris
 
[1] Yes there are other ways of duplicating strings in C++ - you might
just copy std::string objects. But strdup() can often be useful when
interfacing with C libraries.
Paavo Helde <myfirstname@osa.pri.ee>: Sep 03 01:53PM +0300

On 3.09.2018 13:33, Chris Vine wrote:
 
> Say you are using the POSIX function strdup() in your C++ code[1].
> That is in the C/POSIX headerstring.h.
[...]
> This is not wholly rhetorical. What do other people do?
 
Why, perform code cleanup and replace strdup() with a C++ std::string
creation, of course.
 
BTW, I'm in the camp of including <header.h>, if I'm using C functions
in C++ code then I should be brave enough to admit it and not trying to
masquerade them with std::. Strdup() is just probably the most useless
example.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 03 03:36PM +0100

On Mon, 03 Sep 2018 13:53:54 +0300
> in C++ code then I should be brave enough to admit it and not trying to
> masquerade them with std::. Strdup() is just probably the most useless
> example.
 
"Yes there are other ways of duplicating strings in C++ - you might
just copy std::string objects. But strdup() can often be useful when
interfacing with C libraries".
Paavo Helde <myfirstname@osa.pri.ee>: Sep 03 07:12PM +0300

On 3.09.2018 17:36, Chris Vine wrote:
 
> "Yes there are other ways of duplicating strings in C++ - you might
> just copy std::string objects. But strdup() can often be useful when
> interfacing with C libraries".
 
I'm curious where it can be "often useful"?
 
I can see using strdup might be useful if a C library function has a
string input parameter which is assumed to be released inside the
library, or at least is assumed to be not released by the caller. There
are some C interfaces like that, e.g. POSIX putenv() (which basically
mandates memory leaks and should be replaced by setenv() anyway), and
rl_completion_matches in the readline library interface. However, I
would not use the word "often" here.
 
Not to speak about that strdup() is more verbose to use than std::string
as its return value needs to be explicitly checked for errors.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 03 06:49PM +0100

On Mon, 03 Sep 2018 19:12:39 +0300
> > just copy std::string objects. But strdup() can often be useful when
> > interfacing with C libraries".
 
> I'm curious where it can be "often useful"?
 
For example, when passing a non-literal string datum to a callback in a
C library. (Callbacks often have to take ownership of their data,
because they control lifetime and not you.)
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 02 06:38PM +0100

On Sun, 2 Sep 2018 12:28:01 -0400
> features to confirm whether there would be any problems with, for
> instance, using _Static_assert in C and static_assert in C++ with the
> same arguments.
 
I think you are perhaps missing the point I was making. I was not
commenting on the extent to which C++ has equivalents to _Bool,
_Complex, _Imaginery, _Alignas, _Alignof, _Atomic, _Noreturn,
_Static_assert and _Thread_local (it does have equivalents, albeit
bool is a macro in C stdbool.h, and a type in C++ stdbool.h and
cstdbool); it was that the fact that C++ doesn't support these names
(and doesn't have compound literals, designated initializers and the
restrict qualifier and is incompatible in other ways) means that VLAs
are not "pretty much the only real issue preventing C++ being a proper
superset of C". Given what you say about _Pragma I will have to look
that one up (I can't do that right now).
 
If you were suggesting C++ stdbool.h has to provide _Bool, that is
wrong. g++ provides it in C++ as an extension. But perhaps you meant
something else.
Sam <sam@email-scan.com>: Sep 03 09:15AM -0400

> is an idiot and simply wastes everyone elses bandwidth. If you want to post
> binaries to usenet then take a time machine back to 1990 and head to one
> of the alt.binaries groups.
 
I must've missed the memo that announced your appointment to the post of
Commissar of Usenet Idiots. When did it happen?
 
> >That would be more than 20 years ago, according to my math.
 
> Well done. Whats your next trick, telling us what the month is?
 
Sure, it was October. October of 1996. For some reason I thought it was
September though, not sure why.
 
What is really confusing, actually, is why you were unable to look it up
yourself. The document in question is publicly available, of course. Anyone
can simply pull it up. And, look, it even has the author and a date on it!

You must've been too busy with your exhaustive search for Usenet idiots; but
I'm HTH nevertheless.
 
> analyser
> instead of being able to doing it yourself doesn't exactly paint you as a
> master coder.
 
Oh, you must be using your own computer you've constructed yourself, by
mining lead, copper, and other minerals; fabricating your own
semiconductors, and finally assembling the Univac that you're using just to
write this message. I'm impressed.
 
> I've written at least 15 parsers of various languages both
> common and internal company ones and never had to resort to lex, yacc or
> bison once.
 
You have my condolensces.
boltar@cylonHQ.com: Sep 03 04:19PM

On Sun, 2 Sep 2018 12:53:46 -0700 (PDT)
 
>Admitting to use tools like shovel to dig that hole you are in instead
>of being able to doing it yourself does not exactly paint you as master
>mole. Keep digging!
 
I'm sure that made sense to someone.
boltar@cylonHQ.com: Sep 03 04:24PM

On Mon, 03 Sep 2018 09:15:41 -0400
>> of the alt.binaries groups.
 
>I must've missed the memo that announced your appointment to the post of
>Commissar of Usenet Idiots. When did it happen?
 
Usenet is a text based service and pretty much always has been. Since you
only post text anyway why exactly do you need to send MIME encoded posts?
You honestly think anyone is going to use your PGP public key to email you
an encrypted reply to some post you made? You think you're that important?
Or maybe you're just an arrogant ass.
 
>Sure, it was October. October of 1996. For some reason I thought it was
>September though, not sure why.
 
No, you'd have to go back further than that for you to fit in.
 
[rest of "I can't think of a response" ad hominen BS snipped]
 
>mining lead, copper, and other minerals; fabricating your own
>semiconductors, and finally assembling the Univac that you're using just to
>write this message. I'm impressed.
 
That would be hard work. Writing ones own parser isn't. So long as you know
what you're doing. Apparently that rules you out.
 
>> common and internal company ones and never had to resort to lex, yacc or
>> bison once.
 
>You have my condolensces.
 
Its called working for a living, maybe try it one day when you're out of
short trousers.
 
 
>-----BEGIN PGP SIGNATURE-----
 
>iQIcBAABAgAGBQJbjTP9AAoJEGs6Yr4nnb8ldMMQANgOO1D33a6VSMd/3AJCBO5o
>8mDjcb85naJMr4AHIw6vrNOwCvHRY/ahRkny477pg8Z7NMTTOC60+xsxoAY+wFs9
 
"Look how important I am! I've got PGP! Please send me an email!"
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 03 06:54PM +0200

On 03.09.2018 15:15, Sam wrote:
> You have my condolensces.
 
Hey, shouldn't that be «condolences»?
 
Cheers!, 🍻
 
- Alf
ram@zedat.fu-berlin.de (Stefan Ram): Sep 03 12:11AM

The following table was converted to an ASCII table by me,
but I took it from slide by Howard Hinnant. All errors must
have been introduced by me when creating the ASCII version.
 
It kind of answers what I asked for some months ago when
I wanted an algorithm about what constructors are defaulted
under which circumstances.
 
It uses long lines with more than 72 characters (104?).
 
.------------------------ compiler implicitly declares ------------------------.

.- User default destructor copy copy move move
| declares: constructor constructor assignment constructor assignment
|
|
|
| Nothing defaulted defaulted defaulted defaulted defaulted defaulted
|
| Any not defaulted defaulted defaulted defaulted defaulted
| constructor declared
|
| default user defaulted defaulted defaulted defaulted defaulted
| constructor declared
|
| destructor defaulted user defaulted* defaulted* not not
| declared declared declared
|
| copy not defaulted user defaulted* not not
| constructor declared declared declared declared
|
| copy defaulted defaulted defaulted* user not not
| assignment declared declared declared
|
| move not defaulted deleted deleted user not
| constructor declared declared declared
|
| move defaulted defaulted deleted deleted not user
| assignment declared declared
'-
* = deprecated
 
This table does not yet explains what you get when you
declare two or more of the above (e.g., a copy constructor
/and/ a move assignment). Maybe there is some way the two
rows are merged by some operation in this case.
 
 
.:*~*:._.:*~*:._.:*~*:._.:.
 
This message was written to be viewed with a fixed-width
(monospaced) font and verbatim rendition of spaces and line
breaks. The two "T" in the following two lines should be
at the same horizontal position.
 
IIIIIII...........|||||||||||||||"T"
WWWWWWWWWWWWWWWWWWWWWWWWMMMMMMMMMMMMMMMMMMMMMMM"T"
 
Lines with up to 110 characters should not be wrapped
automatically, so there should be exactly two adjacent lines
following this paragraph, where each line ends with an "I",
and the two "I" are directly on top of each other:
 
WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WWWW WW WI
WI
 
The following lines are indented, one exactly one space
more than the preceding line. When this message is viewed
or quoted, this property should be retained. The uppercase
I should be aligned directly on top of each other.
 
not indented I
indented by 1 space I
indented by 2 spaces I
indented by 3 spaces I
0123 I
 
not indented I
 
indented by 1 space I
 
indented by 2 spaces I
 
indented by 3 spaces I
 
0123 I
ram@zedat.fu-berlin.de (Stefan Ram): Sep 03 04:46AM

>declare two or more of the above (e.g., a copy constructor
>/and/ a move assignment). Maybe there is some way the two
>rows are merged by some operation in this case.
 
When the user declares one thing, this usually deletes or
undeclares something else.
 
So, I assume, when he declares /two/ things, if anything is
deleted by one of them, it will be deleted; else, if
anything is undeclared by one of them, it will be undeclared.
 
defaulted not declared deleted
 
defaulted defaulted not declared deleted
not declared not declared not declared deleted
deleted deleted deleted deleted
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)