Sunday, January 6, 2019

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

"I set my girlfriend's panythose on fire" <cdalten@gmail.com>: Jan 06 06:10AM -0800

On Saturday, January 5, 2019 at 3:19:20 PM UTC-8, TYSC++ wrote:
> ISBN-10: 0789757745
> ISBN-13: 978-0789757746
> Product Dimensions: 17.8 x 5 x 23.2 cm
 
Should I cite a former VP at google that says reading this book is a bad idea?
Daniel <danielaparker@gmail.com>: Jan 06 08:08AM -0800

On Sunday, January 6, 2019 at 9:10:19 AM UTC-5, I set my girlfriend's panythose on fire wrote:
 
> > C++ in One Hour a Day, Sams Teach Yourself Paperback – 23 Dec 2016
 
> Should I cite a former VP at google that says reading this book is a bad
> idea?
 
No, that would be the "appeal to authority" fallacy.
 
Daniel
Siri Cruise <chine.bleu@yahoo.com>: Jan 06 09:38AM -0800

With Pascal?
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
sten.unto@gmail.com (Unto Sten): Jan 06 07:00PM


>> Should I cite a former VP at google that says reading this book is a bad
>> idea?
 
> No, that would be the "appeal to authority" fallacy.
 
I guess he could cite him or her, as long as it is not
a mere citation, but a coherent text containing the
*reasons* why the proposed book could be harmful.
 
(By the way, sorry for mispelling "Bjarne" as "Bjärne")
 
Best regards,
Unto Sten
cdalten@gmail.com: Jan 06 11:18AM -0800

On Sunday, January 6, 2019 at 11:00:38 AM UTC-8, Unto Sten wrote:
> a mere citation, but a coherent text containing the
> *reasons* why the proposed book could be harmful.
 
> (By the way, sorry for mispelling "Bjarne" as "Bjärne")
 
Well, okay, the guy doesn't cite this book. But he does criticize something that he feels falls within the same category.
 
Taken from his site at..
 
http://norvig.com/21-days.html
 
And I quote..
 
"
Walk into any bookstore, and you'll see how to Teach Yourself Java in 24 Hours alongside endless variations offering to teach C, SQL, Ruby, Algorithms, and so on in a few days or hours. The Amazon advanced search for [title: teach, yourself, hours, since: 2000 and found 512 such books. Of the top ten, nine are programming books (the other is about bookkeeping). Similar results come from replacing "teach yourself" with "learn" or "hours" with "days."
The conclusion is that either people are in a big rush to learn about programming, or that programming is somehow fabulously easier to learn than anything else. Felleisen et al. give a nod to this trend in their book How to Design Programs, when they say "Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies." The Abtruse Goose comic also had their take.
"
 
And then he goes on to say..
 
"
Let's analyze what a title like Teach Yourself C++ in 24 Hours could mean:
Teach Yourself: In 24 hours you won't have time to write several significant programs, and learn from your successes and failures with them. You won't have time to work with an experienced programmer and understand what it is like to live in a C++ environment. In short, you won't have time to learn much. So the book can only be talking about a superficial familiarity, not a deep understanding. As Alexander Pope said, a little learning is a dangerous thing.
 
C++: In 24 hours you might be able to learn some of the syntax of C++ (if you already know another language), but you couldn't learn much about how to use the language. In short, if you were, say, a Basic programmer, you could learn to write programs in the style of Basic using C++ syntax, but you couldn't learn what C++ is actually good (and bad) for. So what's the point? Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". One possible point is that you have to learn a tiny bit of C++ (or more likely, something like JavaScript or Processing) because you need to interface with an existing tool to accomplish a specific task. But then you're not learning how to program; you're learning to accomplish that task.
 
in 24 Hours: Unfortunately, this is not enough, as the next section shows.
"
ram@zedat.fu-berlin.de (Stefan Ram): Jan 06 09:47AM

>It might be, but it might be solvable by choice of the right command
>line options (I have not figured out which ones).
 
Compiles here with g++ 9 if »-std=c++2a« is used.
Does not compile here if g++ 9 is used with no options.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 06 01:32PM

>>Does not compile here if g++ 9 is used with no options.
>Hmm. It still fails with "g++ -std=c++2a", using g++ compiled from
>source a few weeks ago (revision 5c93472397c, 2018-12-20).
 
The implementation used here has:
 
math.h
|/**
| * This file has no copyright assigned and is placed in the Public Domain.
| * This file is part of the mingw-w64 runtime package.
| * No warranty is given; refer to the file DISCLAIMER.PD within this package.
| */
..
|#if !defined(__STRICT_ANSI__) || defined(_POSIX_C_SOURCE) || defined(_POSIX_SOURCE) || defined(_XOPEN_SOURCE) || defined(_GNU_SOURCE) || defined(_BSD_SOURCE) || defined(_USE_MATH_DEFINES)
..
|#define M_PI 3.14159265358979323846
 
. And we can find in the documentation:
 
|__STRICT_ANSI__
|
|GCC defines this macro if and only if the '-ansi' switch, or
|a '-std' switch specifying strict conformance to some version
|of ISO C or ISO C++, was specified when GCC was invoked.
The C Preprocessor
For gcc version 9.0.0 (pre-release)
Copyright (c) 1987-2019 Free Software Foundation, Inc.
as created 2019-01-06T00:51:30 (no time zone specified)
 
.
Keith Thompson <kst-u@mib.org>: Jan 05 05:12PM -0800

Consider the following program:
 
#include <iostream>
#include <cmath>
int main() {
const int M_PI = 22/7;
std::cout << M_PI << '\n';
}
 
(Yes, I know that the value of 22/7 is 3, not a good approximation of pi.)
 
Both g++ 8.2.0 and clang++ 7.0.0 fail to compile this, because M_PI is
defined as a macro in <cmath>:
 
$ g++ -std=c++17 -pedantic-errors -c c.cpp
In file included from /o/apps/gcc-8.2.0/include/c++/8.2.0/cmath:45,
from c.cpp:2:
c.cpp: In function 'int main()':
c.cpp:4:15: error: expected unqualified-id before numeric constant
const int M_PI = 22/7;
^~~~
 
The library implementation is libc6-dev:amd64 2.27-3ubuntu1.
 
M_PI is defined by POSIX, not by either ISO C or ISO C++. It's not
a reserved identifier in either language, so it should be available
as a user-defined identifier in conforming C++ code.
 
Am I correct in thinking that this is a bug in the implementation,
or is there some C++ rule that allows conforming implementations
to reject it?
 
(For a similar C program, using "-std=c11" causes it to compiler
correctly.)
 
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 05 05:18PM -0800

On 1/5/2019 5:12 PM, Keith Thompson wrote:
 
> M_PI is defined by POSIX, not by either ISO C or ISO C++. It's not
> a reserved identifier in either language, so it should be available
> as a user-defined identifier in conforming C++ code.
 
Just a thought, is _USE_MATH_DEFINES defied?
 
Keith Thompson <kst-u@mib.org>: Jan 05 05:32PM -0800

> On 1/5/2019 5:12 PM, Keith Thompson wrote:
[...]
>> a reserved identifier in either language, so it should be available
>> as a user-defined identifier in conforming C++ code.
 
> Just a thought, is _USE_MATH_DEFINES defied?
 
I didn't define it (I showed the entire source program and the
command I used to compile it). Adding an #ifdef (and renaming M_PI)
indicates that _USE_MATH_DEFINES is not defined.
 
The only occurrence of that identifier I found on my system is in
/usr/include/mysql/my_global.h, which seems to assume that defining
it will make M_PI et all visible. That assumption does not appear
to be correct.
 
Another data point: including <math.h> rather than <cmath> doesn't
change the behavior.
 
[...]
 
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson <kst-u@mib.org>: Jan 05 05:34PM -0800

> /usr/include/mysql/my_global.h, which seems to assume that defining
> it will make M_PI et all visible. That assumption does not appear
> to be correct.
 
I think _USE_MATH_DEFINES is specific to Microsoft's implementation.
 
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 05 05:35PM -0800

On 1/5/2019 5:32 PM, Keith Thompson wrote:
> to be correct.
 
> Another data point: including <math.h> rather than <cmath> doesn't
> change the behavior.
 
Afaict, M_PI should not be available on non-posix systems.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jan 05 05:37PM -0800

On 1/5/2019 5:35 PM, Chris M. Thomasson wrote:
 
>> Another data point: including <math.h> rather than <cmath> doesn't
>> change the behavior.
 
> Afaict, M_PI should not be available on non-posix systems.
 
Fwiw, this kind of reminds me of avoiding the use of the _t postfix when
writing POSIX code in C. It clashes with POSIX's use of _t, like
pthread_mutex_t.
Keith Thompson <kst-u@mib.org>: Jan 05 06:35PM -0800

"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> writes:
[...]
> Afaict, M_PI should not be available on non-posix systems.
 
Yes, but that wasn't the question. I'm using a POSIX system (Ubuntu
18.04), but I'm invoking the C++ compiler in a mode that should
conform to ISO C++. (I expect M_PI to be available if I invoke the
compiler in a way that makes POSIX-specific features available.)
I believe that means that the name M_PI should be available for
my use. I'm reasonably certain this is true for C (and gcc and
clang behave that way), but I'm slightly less sure for C++.
 
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 05 11:13PM -0500

On 1/5/19 20:12, Keith Thompson wrote:
> a reserved identifier in either language, so it should be available
> as a user-defined identifier in conforming C++ code.
 
> Am I correct in thinking that this is a bug in the implementation,
 
It might be, but it might be solvable by choice of the right command
line options (I have not figured out which ones). If so, it's not
conforming without use of those options.
 
I used -E and -dD to dump #definitions. Providing a #definition for M_PI
is controlled by __USE_XOPEN, which in turn is controlled by
_XOPEN_SOURCE, which in turn is controlled by _GNU_SOURCE, which is
supposedly set by the command line (I'm not sure which command line
option sets it). Explicitly unsetting it using -U_GNU_SOURCE causes the
#definition of M_PI to be removed, but it causes a lot of other
problems, so that's not the right solution.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 06 10:56AM +0100

On 06.01.2019 02:12, Keith Thompson wrote:
> a reserved identifier in either language, so it should be available
> as a user-defined identifier in conforming C++ code.
 
> Am I correct in thinking that this is a bug in the implementation,
 
Assuming that you haven't defined `_USE_MATH_DEFINED`, then yes, it
should not be defined by default.
 
 
> to reject it?
 
> (For a similar C program, using "-std=c11" causes it to compiler
> correctly.)
 
The best course of action is IMO to /not/ all use uppercase names that
clash with Posix macros.
 
Alternatively you can try defining `__STRICT_ANSI__`.
 
 
Cheers & hth.,
 
- Alf
Keith Thompson <kst-u@mib.org>: Jan 06 04:00AM -0800

>>line options (I have not figured out which ones).
 
> Compiles here with g++ 9 if »-std=c++2a« is used.
> Does not compile here if g++ 9 is used with no options.
 
Hmm. It still fails with "g++ -std=c++2a", using g++ compiled from
source a few weeks ago (revision 5c93472397c, 2018-12-20).
 
With no options, g++ is non-conforming, so I'm not surprised that it
fails. What about "-std=c++11" or "-std=c++17"? Or it might be a
difference in the library implementation rather than in the compiler.
 
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson <kst-u@mib.org>: Jan 06 04:15AM -0800

>> correctly.)
 
> The best course of action is IMO to /not/ all use uppercase names that
> clash with Posix macros.
 
The best course of action is not to try to use names that are defined
by POSIX. This wasn't something I ran into in real-world code.
But it can be difficult to keep track of which identifiers are
defined by POSIX (or by any number of other secondary standards).
 
> Alternatively you can try defining `__STRICT_ANSI__`.
 
That has no effect.
 
I think the problem is in GNU libc, or in its interaction with g++.
Under Cygwin, which uses a different library implementation, the
problem doesn't occur with g++ (though it does occur with clang++).
 
I'll submit a bug report.
 
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
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)