Wednesday, August 21, 2019

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

Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 21 08:26PM

On Wed, 2019-08-07, Jorgen Grahn wrote:
> On Wed, 2019-08-07, Scott Lurndal wrote:
...
> provoke an unaligned access by writing broken code. Also, the huge
> body of Unix software is already free from such code (or it wouldn't
> have worked on e.g. SPARC or PPC).
 
Or maybe that should be "/used to/ be free from such code", since I
came across this on debian-devel-announce today:
 
Aurelien Jarno recently proposed[3] the mips architecture
(supporting 32-bit big-endian MIPS CPUs) for removal and then got
it removed[4] [...] The removal was due to the limited 2GB
virtual address space and because the architecture is one of the
last big-endian architecture Debian supports, the porting effort
became increasingly difficult.
 
So we may be entering another "all the world's a VAX" period. Oh
well, I'm going to keep writing portable code unless paid not to.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 21 08:39PM +0100

On Wed, 21 Aug 2019 08:34:56 +0200
> can only program in a way to make them impossible. And you can't be
> sure of finding them by testing. It is very easy to have code that
> worked when you tested it in the lab, and fails in the field.
 
Reference to a "race condition" in C++ is apt to cause confusion.
According to the C++ standard, a "data race" arises if the program
"contains two potentially concurrent conflicting actions, at least one
of which is not atomic, and neither happens before the other ...", and
two concurrent actions conflict "if one of them modifies a memory
location and the other one accesses or modifies the same memory
location".
 
This is different from what an ordinary programmer would call a "race
condition" or "data race", which in general usage is a reference to
something improperly synchronized. An improperly synchronized program
which uses atomic variables with relaxed memory ordering does not
according to the standard suffer from a data race, even if it is
(because of the relaxed ordering) completely unsynchronized and
generates randomly incorrect results and gives rise to a race condition
in common parlance.
 
It is important to be clear which case you are in fact referring to.
 
In any machine I have ever come across, using a volatile scalar which
is atomic at the hardware level, such as an int, has identical effect
to using the equivalent atomic variable with relaxed memory ordering.
The code emitted by the compiler is identical.
 
If you need lock-free synchronization for your volatile ints, you can
use fences just as you can use fences with atomic ints with relaxed
memory ordering. (If you are using locks to synchronize, volatile
or atomic variables are unnecessary and a pessimization - hence the
"happens before" in the text I have quoted.) So Bonita's use may be
fine.
 
The question is: now that we have C and C++ standards which provide
atomic scalars with relaxed memory ordering, why are you using a
volatile int at all? The answer "because I don't want to rewrite my
code unnecessarily" seems to me to be a reasonable answer, provided the
program is indeed adequately synchronized by some other means such as
fences, so that it does not contain a race condition in common parlance.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 21 09:02PM +0100

On Wed, 21 Aug 2019 20:39:59 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]
> code unnecessarily" seems to me to be a reasonable answer, provided the
> program is indeed adequately synchronized by some other means such as
> fences, so that it does not contain a race condition in common parlance.
 
The "why are you using a volatile int" was a reference to using volatile
ints with threads. Volatile ints (such as sig_atomic_t) can of course
be required in other cases such as with signals, mapping hardware
addresses and mmaping.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Aug 21 07:34PM

On Wed, 2019-08-21, JiiPee wrote:
> {
> public:
> int getAge() { return age;}
 
There's a const missing.
 
> {
> int age;
> };
 
Or one which is not invalidated by time itself:
 
struct Person {
explicit Person(const Date& birthday);
const Date birthday;
};
 
(Ignoring intricacies of hours, minutes and time zones, and people of
unknown age.)
 
It depends on what you're modeling and how you want to model it.
Saying one is better than the other is like saying a spoon is better
than a fork.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Bo Persson <bo@bo-persson.se>: Aug 21 09:40PM +0200

On 2019-08-21 at 21:22, JiiPee wrote:
 
> I do currently 1) but wondering which way to go.
 
> Like now I have a "Settings" class. Simple data members. I started
> adding getters and setters....
 
There probably isn't a general answer, except that it depends.
 
If you model a real person, the age doesn't change except by +1 on each
birthday. So what is the use for setAge?
 
 
In the Core Guidelines you have a Point(x, y) where it is unclear what
the use for set_x is. So you could just skip it.
 
If the class were to have some kind of behavior, perhaps a
Point.move_to(somewhere) would be more useful?
 
 
So, it depends. :-)
 
 
Bo Persson
"Öö Tiib" <ootiib@hot.ee>: Aug 21 12:52PM -0700

On Wednesday, 21 August 2019 22:23:08 UTC+3, JiiPee wrote:
 
> {
 
> int age;
 
> };
 
Age is rapidly changing property of a person so it is usually made as
getter function that calculates it based on date of birth of person
and current date. Date of birth is usually const set in constructor
since that can't change during life-time (or even after) of a person.
 
Snipping possible misrepresentation of Herb Sutter and
CppCoreGuidelines of isocpp.
 
> I do currently 1) but wondering which way to go.
 
I think you should do in usual way (that I desribed).
Keith Thompson <kst-u@mib.org>: Aug 21 12:41PM -0700

>> language."
 
>> So no, for gcc/g++ not blinking the caps lock is not a diagnostic.
 
> I'm sorry, that's a simple fallacy.
 
No, that's what the documentation says.
 
> That g++ doesn't do that now, has no bearing on what it /can/ do.
 
How is that relevant?
 
The language standard requires each implementation to document what a
"diagnostic" is. The gcc/g++ documentation clearly documents what a
"diagnostic" is, in a way that clearly excludes "non-blinking caps
lock".
 
A future version could change that, but I'd be willing to bet that it
won't.
 
By accepting identifiers with "$" without a diagnostic in what is
intended to be a conforming mode, g++ is violating the requirements of
the C++ standard. If you disagree, what exactly is your argument?
 
> As far as the formal is concerned g++ can use the non-blinking caps lock
> as a diagnostic.
 
The "formal" what?
 
Yes, the standard permits an implementation to use a non-blinking caps
lock as a diagnostic -- if and only if its documentation defines
"diagnostic" in a way that's consistent with that. No implementation
does so or is likely to do so in the future.
 
I thought your argument was based on "common sense".
 
Here's an idea. I'll just assume that, at some point in the future, you
might change your argument and agree with me. Problem solved.
 
[...]
 
> That's long ago, 1980s, but presumably use of `$` in system API function
> names was part of the reasons why compilers supported it. And continue
> to support it.
 
OpenVMS uses $ in identifiers (and C and C++ compilers for OpenVMS have
to allow for that). Which is why, in my opinion, the standard *should*
allow compilers to accept $ in identifiers.
 
[...]
 
--
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 */
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)