Tuesday, August 20, 2019

Digest for comp.lang.c++@googlegroups.com - 12 updates in 5 topics

Keith Thompson <kst-u@mib.org>: Aug 20 03:50PM -0700

Bart <bc@freeuk.com> writes:
[...]
> ++a;
> }
> }
 
"gcc -v" or "g++ -v" is easier.
 
[...]
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson <kst-u@mib.org>: Aug 20 03:58PM -0700


> gcc -c *.c
> g++ -c *.o
> ld -o prog *.o
[...]
 
If you're doing this as a learning exercise, it's perfectly reasonable
(and others have already suggested "g++ -v"). If you're trying to do
something useful, I don't think this is a good approach.
 
g++ is a driver program that invokes other programs, including ld, as
needed. It knows what linker options are required to link a C++
program. That's its job. Why reinvent the wheel?
 
You also run the risk that the required options could change with
new releases, or with different versions of installed tools, or
with the phase of the moon. Knowing how g++ invokes ld doesn't
necessarily tell you how g++ figured out how to invoke ld, or how
that might change.
 
(On the other hand, if you need to link together code in different
languages, say C++ and Ada, you might need to dive a bit more deeply
into the innards.)
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
David Brown <david.brown@hesbynett.no>: Aug 20 04:18PM +0200

On 20/08/2019 15:03, Juha Nieminen wrote:
> these architectures telling the compilar that eg. a pointer to that memory
> location is pointing to a volatile value may be important, as it (usually)
> prevents the compiler from optimizing away reads and writes to it.
 
That was the original motivation for "volatile", and it is still a major
use-case. (Usually the hardware will have features for treating the
memory locations of these hardware registers in special ways, such as
skipping caches and disallowing re-ordering in buffers or speculative
accesses - this gives you some of the effects of C++11 atomic accesses
on these addresses even when you just have a simple "volatile".)
 
"volatile" also finds use in single core systems - it has long been
essential in microcontroller programming for handling data between
interrupt functions and other code, and on most microcontrollers it is
still sufficient (while C++11 atomics would be overkill and slower).
 
Sometimes it is also used to force particular effects. For example, if
you have a pure calculation function "foo" (i.e., it has no side effects
and does not access non-const global data), and you want to know how
long it takes to run, you might try:
 
const int x = 123;
auto start_time = get_time();
for (int i = 0; i < 1000000; i++) {
int y = foo(x);
}
auto end_time = get_time();
std::cout << "Time for 1000000 runs is " <<
(end_time - start_time) << "\n";
 
Enable optimisation, and the compiler may happily remove the entire loop.
 
But if you use:
 
volatile const int x = 123;
 
and
 
volatile int y = foo(x);
 
you get the timing you want.
 
 
> to that variable in memory every single time it's done in the code.
> (For example, declaring a loop counter variable volatile for no good
> reason would be rather silly.)
 
Yes.
Vir Campestris <vir.campestris@invalid.invalid>: Aug 20 09:58PM +0100

On 20/08/2019 00:37, Chris M. Thomasson wrote:
> some things do some don't, it was never meant for threading. Use
> std::atomic with _relaxed_ membars to read and write volatiles for a
> device or something.
 
In this case I have a damn great lump of C code (not C++) which has been
jammed into the C++ compiler as C++.
 
But I don't need it to be portable. It only needs to run on medium sized
ARMs with maybe 4 processors.
 
I know what the code ought to be. It ought to be re-written in C++ using
atomics (and in several cases other library features - I noticed a
spin-lock)
 
But it's big. It isn't going to be rewritten unless it's proved to be a
problem. And proving this would be hard - it'll be a race condition
somewhere.
 
I was only hoping someone here had experience of the actual behaviour of
volatile - but it looks like not.
 
Thanks anyway
Andy
scott@slp53.sl.home (Scott Lurndal): Aug 20 10:18PM

>somewhere.
 
>I was only hoping someone here had experience of the actual behaviour of
>volatile - but it looks like not.
 
On ARM, the behavior will depend on the memory type. It should work fine
when accessing device memory (e.g. device command/status registers, PCIe
ECAM space, etc).
 
For Normal, Sharable, Cacheable memory the weak (relative to x86) memory
model will cause problems even if you qualify your accesses with the volatile
qualifier (in a highly out-of-order pipeline, other accesses may pass the
volatile access or vice versa, so you need a load/store with ordering
semantics).
Keith Thompson <kst-u@mib.org>: Aug 20 02:21PM -0700

> On 20/08/2019 21:18, Keith Thompson wrote:
[...]
> 2 warnings generated.
> $ clang++ --version
> clang version 8.0.1-svn363027-1~exp1~20190611211629.77 (branches/release_80)
 
Yes, I had already tried clang. It allows '$' in identifiers, but warns
about them in conforming mode, which agrees with my interpretation of
what the C++17 standard requires.
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Keith Thompson <kst-u@mib.org>: Aug 20 02:59PM -0700


> int a$ = 1;
 
> "--std=c++03 -Wpedantic" gives a warning (testing with gcc trunk).
> --std=c++11 and --std=c++17 do not. (C++98 also warns.)
 
All editions of the C++ standard allow universal-character-names in
identifiers, and all restrict them to ranges listed in a table (the
table does not include the code for '$').
 
C++11 (and apparently C++14) add the "other implementation-defined
characters" wording, which means that a compiler *may* permit '$' in
identifiers (and needn't warn about it). C++17 dropped it according to
the drafts I have.
 
As far as I can tell, no version of g++ warns about '$' in an identifier
with "-Wpedantic -std=c++17". My reading of the C++17 standard is that
such a warning is required, making g++ non-conforming.
 
It appears that gcc warns about '$' in identifiers with -std=c++98 and
-std=c++03, and does not warn with -std=c++11 or higher. It looks like
the gcc maintainers responded to the addition of "other
implementation-defined character" in C++11, but did not respond to its
removal in C++17.
 
clang supports '$' in identifiers as an extension, but always warns
about them with "-std=c++... -Wpedantic", which is conforming behavior
for all versions of the standard.
 
[...]
 
> undefined behaviour (since it is not defined in the standard), and
> therefore a compiler can support it, or would it constitute a syntax
> error (requiring a diagnostic for conformity) ?
 
It would be a violation of a *diagnosable rule*, requiring at least a
warning. I don't think it's a syntax error, but there's no required
distinction between syntax errors and other kinds of diagnosable errors.
 
The rule it violates is in N4700 5.10 [lex.name] paragraph 1:
 
Each universal-character-name in an identifier shall designate a
character whose encoding in ISO 10646 falls into one of the ranges
specified in Table 2.
 
('$' is not in Table 2.) That wording in the C standard would imply
that the behavior is undefined (or that it's a "constraint violation",
if it's in an explicitly marked constraint) but C++ [intro.compliance]
says:
 
The set of diagnosable rules consists of all syntactic and
semantic rules in this document except for those rules containing
an explicit notation that "no diagnostic is required" or
which are described as resulting in "undefined behavior".
 
The effect is the same: a diagnostic is required. (If the
implementation chooses to produce an executable after printing the
required diagnostic, I suppose the behavior is undefined by omission.)
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Lynn McGuire <lynnmcguire5@gmail.com>: Aug 20 02:38PM -0500

On 8/20/2019 1:21 AM, David Brown wrote:
 
> Lynn, I added the marks to your URL when I made the reply.  By now, it
> will have wrapped to two lines - you can test it and see if it still
> works as a link for your client.
 
It does. I use Thunderbird on Windows 7 x64 as both my email and news
client.
 
Thanks,
Lynn
Szyk Cech <szykcech@spoko.pl>: Aug 20 05:21PM +0200

> void qux(void);
 
> private:
> const QString name;
 
This:
 
> QSettings * const settings;
 
Should be:
const QSettings* settings;
 
 
Paavo Helde <myfirstname@osa.pri.ee>: Aug 20 06:58PM +0300

On 20.08.2019 18:21, Szyk Cech wrote:
 
>> QSettings * const settings;
 
> Should be:
> const QSettings* settings;
 
This he already had earlier. Maybe he wants
 
const QSettings* const settings;
stdcerr <ron.eggler@gmail.com>: Aug 20 10:44AM -0700

On Tuesday, August 20, 2019 at 8:58:50 AM UTC-7, Paavo Helde wrote:
 
> > Should be:
> > const QSettings* settings;
 
> This he already had earlier.
 
yes, Thanks!
 
> Maybe he wants
 
> const QSettings* const settings;
 
I want a cost pointer to QSettings. Originally, I thought const QSettings* settings would give me that until Sam told me that this is not right but why notI'm not exactly sure.
Paavo Helde <myfirstname@osa.pri.ee>: Aug 20 09:19PM +0300

On 20.08.2019 20:44, stdcerr wrote:
 
>> Maybe he wants
 
>> const QSettings* const settings;
 
> I want a cost pointer to QSettings. Originally, I thought const QSettings* settings would give me that until Sam told me that this is not right but why notI'm not exactly sure.
 
A const pointer to mutable QSettings is 'QSettings * const'. If you want
this, you need to use the same type also in the constructor, not 'const
QSettings *' you have above.
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)