Tuesday, September 4, 2018

Digest for comp.lang.c++@googlegroups.com - 15 updates in 3 topics

Juha Nieminen <nospam@thanks.invalid>: Sep 04 05:43AM

> argument for preferring the C-headers. How else would you guard
> yourself against stuff breaking up when e.g. changing between
> compilers?
 
Does including the .h files guarantee that the names will also be in the
std namespace? If not, what if you *want* to use the std:: prefix?
David Brown <david.brown@hesbynett.no>: Sep 04 08:15AM +0200

On 04/09/18 07:43, Juha Nieminen wrote:
>> compilers?
 
> Does including the .h files guarantee that the names will also be in the
> std namespace? If not, what if you *want* to use the std:: prefix?
 
The C++ standard (quoting from N3797, C++14, since that's what I have
handy) says:
 
 
17.6.1.2 Headers
Each element of the C ++ standard library is declared or defined (as
appropriate) in a header.
The C ++ standard library provides 55 C ++ library headers, as shown in
Table 14.
The facilities of the C standard Library are provided in 26 additional
headers, as shown in Table 15.
Except as noted in Clauses 18 through 30 and Annex D, the contents of
each header cname shall be the same
as that of the corresponding header name.h, as specified in the C
standard library (1.2) or the C Unicode TR, as appropriate, as if by
inclusion. In the C ++ standard library, however, the declarations
(except for
names which are defined as macros in C) are within namespace scope
(3.3.6) of the namespace std. It is
unspecified whether these names are first declared within the global
namespace scope and are then injected
into namespace std by explicit using-declarations.
 
 
To me, that says that <cstdint> guarantees to have the names in std::
while <stdint.h> guarantees to have the names in the global namespace.
<cstdint> may also have them in the global namespace, but does not have
to, while <stdint.h> could also have them in std:: but does not have to.
 
In fact, I don't think a C++ implementation has to have <stdint.h> at
all - only the <cstdint> style headers. But I'd be surprised to find a
C++ implementation that is not also a C implementation.
Ian Collins <ian-news@hotmail.com>: Sep 04 07:32PM +1200

On 03/09/18 18:26, Juha Nieminen wrote:
 
>> 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.
 
I just find it odd, probably because I also work with C and POSIX code.
 
--
Ian.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 04 10:14AM +0200

On 04.09.2018 07:43, Juha Nieminen wrote:
>> compilers?
 
> Does including the .h files guarantee that the names will also be in the
> std namespace?
 
No.
 
 
> If not, what if you *want* to use the std:: prefix?
 
Include both, or better, include a wrapper that includes both.
 
Oh look!
 
<url:
https://github.com/alf-p-steinbach/Wrapped-stdlib/tree/master/source/c>
 
However, that code includes an overly optimistic attempt to foil
Microsoft's attempt at steering people over to their vendor lock-in
traps via spurious and misleading sillywarnings. I now regret attempting
it. It didn't work: the solutions to avoid that diagnostics noise must
be adjusted at roughly every new Visual C++ compiler update, so it's
best done via the build system and not attempted in code.
 
Sorry 'bout that.
 
 
Cheers & hth.,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 04 06:12PM +0100

On Tue, 4 Sep 2018 08:15:53 +0200
David Brown <david.brown@hesbynett.no> wrote:
[snip]
> In fact, I don't think a C++ implementation has to have <stdint.h> at
> all - only the <cstdint> style headers. But I'd be surprised to find a
> C++ implementation that is not also a C implementation.
 
My reading of Annex D5 of C++14 is that stdint.h must be supplied by a
conforming implementation (along with the other 26 C headers in
'name.h' form), and that the things declared or defined there must be in
the global namespace.
jameskuyper@alumni.caltech.edu: Sep 04 10:48AM -0700

On Tuesday, September 4, 2018 at 2:16:04 AM UTC-4, David Brown wrote:
...
> In fact, I don't think a C++ implementation has to have <stdint.h> at
> all - only the <cstdint> style headers. But I'd be surprised to find a
> C++ implementation that is not also a C implementation.
 
From n4762.pdf:
"The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to ensure static type safety." (15.1p1)
"For compatibility with the C standard library, the C++ standard library provides the C headers shown in Table 136." (D.6p1)
 
Table 136 include <stdint.h>. This is not new in this draft version - it's been around for a while, though I'm not sure which was the first version to mandate provision of <stdint.h>.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Sep 04 10:08PM +0200

On 04.09.2018 08:15, David Brown wrote:
> while <stdint.h> guarantees to have the names in the global namespace.
> <cstdint> may also have them in the global namespace, but does not have
> to, while <stdint.h> could also have them in std:: but does not have to.
 
Yes.
 
 
> In fact, I don't think a C++ implementation has to have <stdint.h> at
> all - only the <cstdint> style headers.  But I'd be surprised to find a
> C++ implementation that is not also a C implementation.
 
The C++ ".h" headers are not part of the C implementation, except to the
degree that each vendor finds it possible to reuse code (in particular,
by just letting the C++ ".h" header include the C ".h" header and add
whatever additional stuff that's required in C++, such as overloads).
 
The C++ ".h" headers define a lot of stuff that wouldn't compile as C,
including function overloads.
 
They're required headers, and the language being built on the idea of
reusing C libraries, means that one needs to use C language headers that
in turn include ".h" headers, from C++, which means they'll not go away.
 
One might wonder what the deprecation in 1998 then was all about. I
think it's simple, that some committee members /envisioned/ the
possibility of clean C++ code with all standard library names in
namespace `std`. The compiler vendors' total unwillingness to provide
clean conforming "c..." headers shattered that dream.
 
Since C++11, where practical reality ("c..." headers polluting the
global namespace) was allowed by the standard, so that the "c..."
headers no longer have any purpose, and especially so that refraining
from using the ".h" headers no longer has any purpose, one might wonder
what the continued deprecation is all about. I think that may be
political. Or it may be, and writing this now it seems probable, simply
that nobody's willing to front and argue the case; after all, things
work now, there's no technical problem to be solved, just a perception.
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Sep 04 02:38PM -0700

On Tuesday, 4 September 2018 23:08:26 UTC+3, Alf P. Steinbach wrote:
> political. Or it may be, and writing this now it seems probable, simply
> that nobody's willing to front and argue the case; after all, things
> work now, there's no technical problem to be solved, just a perception.
 
Several people have already expressed the purpose of <cheaders>. They
want to write "std::" and <cheaders> provide that opportunity. It
makes code easier to read for them. This is matter of taste
and about taste it is easy to fight but impossible to argue.
 
Most of C library names are utter Klingon recognizable from afar
without any "std::" needed. But ... about dozen or so names in it are
common words. You know ... "time", "clock", "abort", "exit", "free",
"system", "floor", "round" &c. Such can clash and I've seen
intermediate maintainers confusing themselves for a hour or couple
because of hiding those with a more local name. So at least "::"
prefix should be used and then it is only "std" that remains.
woodbrian77@gmail.com: Sep 03 09:32PM -0700

On Sunday, September 2, 2018 at 2:47:29 PM UTC-5, Öö Tiib wrote:
> > to the standard?
 
> I think that you need to start from reasons. Why most senior and expert level specialists dislike "using namespace std;" in header files? Why lot of
> them dislike it even in cpp files?
 
Not everyone uses cpp files. I use cc files.
 
 
Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards
 
woodbrian77@gmail.com: Sep 03 09:34PM -0700

On Monday, September 3, 2018 at 2:46:19 AM UTC-5, Alf P. Steinbach wrote:
> all over, help readability?
 
> For me the `::` symbols and namespace names just reduce readability,
> greatly, and thereby reduce global clarity.
 
I don't know about the greatly part, but I tend to
agree. In my code I write:
using namespace ::cmw;
 
in source files in order to get a little bit of that.
I only permit that though for my namespaces.
 
 
> 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
 
Has anyone watched this?
https://duckduckgo.com/?q=%22edward+Feser%22+shapiro&t=ffab&ia=videos&iax=videos&iai=9FvYwpyFbIQ
 
 
> redundant namespace names peppered all over the text, as background.
 
> Cheers!,
 
> - Alf
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
Jorgen Grahn <grahn+nntp@snipabacken.se>: Sep 04 05:49AM

On Mon, 2018-09-03, Alf P. Steinbach wrote:
...
> 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.
 
You're either joking, or you greatly underestimate how differently
people read and think about code.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Juha Nieminen <nospam@thanks.invalid>: Sep 04 06:01AM

> 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.
 
Once, in another forum, I made the argument that using the std:: prefix
increases readability, rather than reduce it. Someone tried to prove me
wrong by posting a piece of code with half a dozen lines, and about a
dozen uses of standard library names.
 
Quite ironically, at least personally, I found the version *with* the
std:: prefixes to be easier to understand and read than the version
where they were removed.
 
For some reason which I can't really understand, some people seem to
think that if "std::" appears many times in the code, that somehow
makes it "cluttered" and "less readable". For reasons unknown.
 
To me that's as silly as saying that using capital letters at the
beginning of sentences makes the text "cluttered" and "less readable".
"Fred.Zwarts" <F.Zwarts@KVI.nl>: Sep 04 09:45AM +0200

"Paavo Helde" schreef in bericht news:pmje0m$ot7$1@dont-email.me...
>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.
 
I understand your point. But it is not to only one to be considered. When I
look at code, I sometimes wonder why a particular header is included. When
the use of std:: is scattered al over the source file and I do not know all
symbols that are defined in the header, it is often difficult to find the
reason. Therefore, at the top of my code after the list of #includes, I
always have another list (often in a namespace) where I mention all symbols
imported from these headers, in a way that it easy to see which symbol is
from which header. That makes it easy to see why a certain header is
included and where a certain name comes from.
 
E.g.,
 
If I see that <iterator> is included, I need to know that distance is
defined there in order to understand why it is included in your example.
I find it much clearer if "#include <iterator>" is followed by "using
std::distance;".
 
Of course the imported symbols can also be named in a comment, but when the
code changes and other symbols are added, with the first method the compiler
will help me to update the list of imported symbols, but with these names in
a comment, the compiler cannot help.
 
Which of the two points is the most important is a personal taste, I think.
Sam <sam@email-scan.com>: Sep 03 09:08PM -0400

> >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.
 
It sure did.
Sam <sam@email-scan.com>: Sep 03 09:27PM -0400

> >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?
 
Because MIME is used for text content? For example, if I wished to tell you
that "vous êtes un crétin", without MIME it wouldn't be possible.
 
And that would be a darn shame.
 
> 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?
 
I think I'm very important, yes.
 
> Or maybe you're just an arrogant ass.
 
I'm that too.
 
> >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.
 
Can you translate that into English? You're not making sense. The
publication date is pretty clear. Are you suggesting a grand conspiracy, of
some kind, which attempts for unknown reason to misrepresent the publication
date of the formal specification for PGP-signed MIME content? Why would
someone want to misrepresent the publication date? Enlighten us, please.
 
> >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.
 
Who said it was hard?
 
> So long as you know
> what you're doing. Apparently that rules you out.
 
You are forced to qualify and hedge your bets by using the "apparently"
qualifier. Well, when you figure it out conclusively, be sure to let me
know. I'm always anxious to know what I'm doing, at any particular moment,
and I'm so glad I finally found someone to tell me that. You're like a
personal Google Assistant. I never found it useful, or much source of
entertainment. But you seem to do a much better job, at it.
 
And I feel obligated to return the favor, and I tell you that I have no
doubts at all, not any, whatsoever, as to whether you know or don't know
what you're doing. Not much of a mystery, there.
 
 
> >You have my condolensces.
 
> Its called working for a living, maybe try it one day when you're out of
> short trousers.
 
I'll keep your very profound advice in mind, thank you very much.
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)