Thursday, August 22, 2019

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

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 22 07:50PM +0200

On 22.08.2019 19:28, Tim Rentsch wrote:
> very much swimming upstream here: do you really want to say you are
> smarter than all the people who have participated in the C and C++
> working groups to standardize these languages?
 
There are 3 main things wrong with that statement:
 
* The idea that I'm arguing a view at odds with the standard. I'm not.
Check how many in this group agree with your view of UB: that's 0.
 
* The idea that /if/ one believes the standard is sub-optimal or wrong,
one must believe that one is smarter than all the people blah blah. If
that were the case then all those non-committee members who have filed
Defect Reports against the standard, must be megalomaniacs who think
they're very very smart. That's just not so.
 
* It's a purely social argument.
 
 
> I hope you will
> understand if I view these last remarks with a fair amount of
> skepticism.
 
[Hark.]
 
I may address the rest of your posting later, trying to give the
examples etc. you ask for, because I feel you mean this seriously.
 
And I don't think you think you're smarter than everybody else in this
group just for holding an opinion on UB that nobody else here shares.
 
I think you're simply convinced that you're right, that your
distinctions are meaningful, and somehow my and others' arguments have
failed to move your conviction. Which I think means we're not good
enough at presenting our view. Not, that we're wrong. ;-)
 
 
Cheers!,
 
- Alf (fairly intelligent but at least now not at Mensa level :) )
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 22 11:45PM +0100

"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes:
<cut>
> And I don't think you think you're smarter than everybody else in this
> group just for holding an opinion on UB that nobody else here shares.
 
Why do you think no one else shares Tim's opinion? Tim has not said
anything here about UB that I disagree with. You have, but I've found
my life to be more pleasant if I don't reply to your posts, and anyway,
Tim has it covered.
 
--
Ben.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 22 06:17PM

>What is easiest to use static C++ code analyser?
 
Every static code analyzer is easy to use
(unless you want to use it under Windows).
ram@zedat.fu-berlin.de (Stefan Ram): Aug 22 10:22PM

>int age;
 
A class needs to protect its invariants.
 
Therefore, a member can be public only if it has no
invariant.
 
An accessor, however, is just appropriate for data
classes where object effectively are used to represent
records as in non-OOP programming. In OOP they violate
"Tell, Don't Ask!".
 
Instead of asking the object for data and the processing
to data outside of the object (as when using accessors),
you should tell the object to do the processing itself.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 22 10:33PM

Supersedes: <accessor-20190822232107@ram.dialup.fu-berlin.de>
[Typos and clarifications]
 
>int age;
 
A class needs to protect its invariants.
 
Therefore, a member can be public only if it is not
mentioned in an invariant of the class.
 
An accessor, however, is just appropriate for data
classes where objects effectively are used to represent
records as in non-OOP programming. In OOP they violate
"Tell, Don't Ask!".
 
Instead of asking the object for data and then processing
the data outside of the object (as when using accessors),
you should just /tell the object/ to do the processing.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 22 03:09PM -0700

JiiPee <no@notvalid.com> writes:
 
[some white space reformatting done]
 
 
> 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....
 
I agree with Herb Sutter's recommendation that (assuming the
class or struct has some member functions) data members should
never be public. There are cases where for data members might
plausibly be made protected rather than private, but never
public. (Incidentally I am ignoring the "age/birthday" matter
that some other people have commented on, and assuming your
question is meant as generic, with 'age' being merely an
unfortunate choice of example.)
 
I suggest however a slightly different pattern than (1), along
these lines (disclaimer: not compiled):
 
class Person {
unsigned siblings_;
// ... other data members ...
 
public:
// ... other member functions
 
unsigned &siblings() { return siblings_; }
const unsigned &siblings() const { return siblings_; }
};
 
Now our accessor functions look more like data member access, but
they remain functions:
 
if( fred.siblings() > 0 ) ...
 
fred.siblings() += 1; // a new birth in fred's family
 
To me this pattern reads nicer on the client side than set/get
functions.
David Brown <david.brown@hesbynett.no>: Aug 22 08:04PM +0200

On 22/08/2019 18:18, Szyk Cech wrote:
 
> What is easiest to use static C++ code analyser?
 
> Thak you in advance and best regards!
> Szyk Cech
 
This will depend on your needs, and your budget.
 
Tools like Coverity, Klocwork and PVS-Studio are all powerful and well
regarded, but can cost quite a lot of money. This kind of tool will
often run on a server and produce detailed reports.
 
At the other end of the scale, there are lots of free and open source
analysers. You can come a long way with the warnings found in good
compilers like gcc, clang and MSVC, and can make good use of static
assertions in your code. (gcc and clang also have a selection of
run-time checking sanitizers.) Lightweight but helpful analysers like
cppcheck can be integrated with an IDE - they don't spot as many errors,
but what they do find, they identify as early as possible.
 
There are also lots of specialised tools for particular purposes, such
as "Sparse" for spotting certain faults in the Linux kernel.
 
If you decide to use a tool beyond your compiler's warnings, there are a
couple of things to watch out for. One is that static analysers are
often behind compilers in support for newer features and standards, and
certainly for any compiler-specific extensions. That may limit your
coding styles. The other is that they often need additional information
in order to do more analysis - for many, this is done using comments in
particular formats. It is quite possible to end up with code where
these special comments make it difficult to find and read the real code
- if they distract from the readability of the code, they are
counter-productive.
 
My recommendation is to start with the features provided in the compiler
you are using - read the manual page for the warnings, and try them (not
all will suit your programming style). And use a good IDE with cppcheck
or similar built in. Only move on when you have outgrown these and are
willing to spent some time and/or money on the matter.
Ian Collins <ian-news@hotmail.com>: Aug 23 08:42AM +1200

On 23/08/2019 04:18, Szyk Cech wrote:
> So maybe you have some experience with those tools if so:
> Please answer me to question:
 
> What is easiest to use static C++ code analyser?
 
We use two, Cppcheck and clang-tidy.
 
Cppcheck is reasonably fast, so we run it on every build. It spots a
good number of problems, it categories issues as Error, Warning, Style,
Performance, Portability and Information. You can filter based on
category or specific warning.
 
clang-tidy is much slower (we run it as a separate job) because it digs
much deeper into the code and can follow control flow paths. It has an
extensive list of warnings, many of which can be automatically repaired.
See <http://clang.llvm.org/extra/clang-tidy/index.html#using-clang-tidy>
 
Both can be run in parallel, which speed things along if you have the
hardware.
 
HTH,
 
--
Ian.
Vir Campestris <vir.campestris@invalid.invalid>: Aug 22 09:39PM +0100

On 20/08/2019 23:18, Scott Lurndal wrote:
> 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).
 
I've already checked and passed a bunch of those.
 
> 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).
 
This is the kind of thing I need. Looks like I should worry about the
code - it's a 3rd party lump, and it was written in C without atomics.
 
I'll speak to the people who pulled it in next time I'm in their country.
 
Thanks Paavo, Chris & David.
 
Andy
--
BTW the first machine I ever worked on professionally didn't do cache
snooping. Cache coherency was a manual process. Which meant that 2
processors were more than twice as fast as one on some workloads!
Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 22 12:57PM -0700

>> clang accept the -x c and -x c++ options.
 
> I didn't even think you needed the -x option, as long as your
> files have recognized extensions. [...]
 
For things like C and C++, which have widely recognized ISO
standards, I don't mind taking the established rules as being
authoritative, and acting accordingly.
 
For tools like gcc or g++ or clang, which depend on the whims of
whichever developers happen to be contributing, and which easily
may change from one version to another, my usual practice is to
spell things out more explicitly. Here I think it helps convey
the point if the -x c and -x c++ options are made explicit rather
than being left as implied.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Aug 22 12:37PM -0700


> There is no good complete resolution, but there is the /observation/
> that since the standard is out of tune with reality in this respect,
> it can't very well be viewed as authoritative. [...]
 
It's Microsoft that is out of tune. And getting moreso as time
goes on.
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)