Tuesday, April 10, 2018

Digest for comp.lang.c++@googlegroups.com - 25 updates in 6 topics

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 10:26AM -0400

What is the C++ reasoning for having both & and * types? Why not just
have * types?
 
--
Thank you! | Indianapolis, Indiana | God is love -- 1 John 4:7-9
Rick C. Hodgin | http://www.libsf.org/ | http://tinyurl.com/yaogvqhj
-------------------------------------------------------------------------
Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 03:33PM +0100

On 10/04/2018 15:26, Rick C. Hodgin wrote:
> What is the C++ reasoning for having both & and * types?  Why not just
> have * types?
 
Because epistemological sausages travel at the speed of light in a
vacuum. How is this possible? They have no mass and always face the
Flying Spaghetti Monster (the one true God).
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
jameskuyper@verizon.net: Apr 10 08:39AM -0700

On Tuesday, April 10, 2018 at 10:27:03 AM UTC-4, Rick C. Hodgin wrote:
> -------------------------------------------------------------------------
> Software: LSA, LSC, Debi, RDC/CAlive, ES/1, ES/2, VJr, VFrP, Logician
> Hardware: Arxoda Desktop CPU, Arxita Embedded CPU, Arlina Compute FPGA
 
C++ references are semantically closely related to const pointers.
Internally, code using a reference will often be implemented identically
to equivalent code using a const pointer. However, references are
syntactically more convenient than const pointers. C++ retains pointers
both for backwards compatibility with C, and because it's possible for a
pointer to be null, which is a convenient way of conveying the
information that "there is nothing to be pointed at"; there's no simple
way to use C++ references to convey the information that "there is
nothing to be referred to".
That's a matter of deliberate design, not an oversight. The C++ rules
governing references were designed to justify the assumption that a
reference always refers to an actual object of the specified type,
which makes it easier to write safe code.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 10 03:22PM

On Mon, 2018-04-09, Chris M. Thomasson wrote:
> to have less traffic:
 
> https://groups.google.com/forum/#!forum/lock-free
 
> Argh!
 
Surely there's /some/ place where this is discussed openly? Although
if the forum is C-oriented, I imagine mentioning C++ can be difficult.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
David Brown <david.brown@hesbynett.no>: Apr 10 03:16PM +0200

On 10/04/18 14:09, bartc wrote:
>> standards forbid to declare more than one thing per declaration.
 
> Why don't more people who write coding standards design language syntax?
> They seem to have more sense.
 
Language designers are aiming for flexibility - let programmers use the
language the way they want, for the tasks they want. Coding standards
authors are aiming to restrict those freedoms, often in a manner that
depends on the task in hand. A coding standard suitable for
small-systems embedded design would be useless for general purpose "big
computer" programming, and vice versa. And of course people have wildly
different ideas of what is good coding practice and clear presentation.
 
C was designed with a "trust the programmer" philosophy. That has let
the language be used in far more areas than were originally envisioned
by the designers. But it also means the programmer has to be more
responsible, because the language won't stop them writing a mess.
David Brown <david.brown@hesbynett.no>: Apr 10 03:18PM +0200

On 10/04/18 15:04, Scott Lurndal wrote:
>> standards forbid to declare more than one thing per declaration.
 
> What's a "real C++ code base"? We've several million lines of
> actively developed C++ code that uses raw arrays and raw pointers.
 
I can't tell you what Öö thinks is "real C++", but I'd guess that in
your "real C++ code base" you don't declare variables of type T and T*
in the same line.
David Brown <david.brown@hesbynett.no>: Apr 10 03:36PM +0200

On 10/04/18 14:11, Rick C. Hodgin wrote:
> of that type. It would remove the need for the existing pointer declar-
> ation syntax which can be prickly, and it would not break existing code
> because the new form would have to be enabled to be used.
 
I think it is fine to say that the type (including the pointer bit) has
to be on the left, separated by a space. I merely think you should
avoid there being ambiguity here - the declarations should be clearly
one thing, clearly the other thing, or an error. (C compatible mode
excluded, of course.)
 
> the dot form because CAlive makes . and -> synonymous, and also allows
> instances of --> or ---> to be the same as -> for alignment):
 
> CWhatever [p], [[pp]]; // Same as CWhatever* p; CWhatever** pp;
 
This is all getting back to the same confusion - and then making it worse.
 
Pick /one/ method for declaring pointers. It does not really matter if
that is "CWhatever* p", "CWhatever [p]", "CWhatever^ p", "pointer to
CWhatever p". But the key thing is to have a single clear and
unambiguous syntax.
 
What you don't want is for some people to be writing "CWhatever* p",
others to be writing "CWhatever [p]", and neither being able to
understand the other's code because they never use that syntax themselves.
 
And don't allow mixing different levels of pointedness in the same
declaration. It is not needed, and just makes code harder to follow.
 
 
One thing you should also try to decide upon is how you view pointer and
types. For "int * p;", the usual C philosophy is "*p is an int -
therefore you write int *p", while the usual C++ philosophy is "p is of
type pointer-to-int - therefore you write int* p". Both C and C++
conflate these concepts but they have a bias towards one of them. In
designing a new language, I would aim to view it from one side.
Personally, I'd chose the "p is of type pointer-to-int", but a syntax
like "int [p]" matches the C idea better. It is up to you to choose one.
 
 
You should also think about initialisation syntaxes. A strange thing
about C is that when you write:
 
int x;
int *p = &x;
 
you are assigning to /p/, not to "*p". If you wrote "*p = &x" later, it
would be an error.
 
I can't see any neat way to have initialisation with declarations of the
form "int [p]".
 
 
So I would prefer to have the pointer as part of the type, and choose a
syntax that does not match C in order to avoid misunderstanding - such as:
 
int^ p = &x;
 
 
> [pp].member; // Same as (*pp)->member, again using .
 
> It's a nod to assembly language, which uses [reg] for indirection,
> and an extension of that syntax to [[pp]] for double-indirection.
 
Different assembly languages use different syntaxes. There is nothing
wrong with using [p] for indirection, taking inspiration from Intel
format x86 assembly, but don't imagine it is universal in assembly.
 
Just don't give multiple optional syntaxes.
 
And be careful about automatically dereferencing pointers to structs or
objects - it can be confusing. In Delphi (which is based on Object
Pascal), objects are mostly pointers that are automatically
dereferenced, but not always - it can be difficult to track which is
which. Consider copying C++'s concepts of references and pointers.
Consider also the possibility of disbanding pointers altogether, and
working /only/ with references.
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:51AM -0700

On Tuesday, April 10, 2018 at 9:36:55 AM UTC-4, David Brown wrote:
> This is all getting back to the same confusion - and then making it
> worse.
 
I disagree wholeheartedly, though I'm certain I'm in the minority
here in the C++ group.
 
--
Rick C. Hodgin
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:53AM -0700

On Tuesday, April 10, 2018 at 9:51:17 AM UTC-4, Rick C. Hodgin wrote:
> > worse.
 
> I disagree wholeheartedly, though I'm certain I'm in the minority
> here in the C++ group.
 
One other thing: CAlive supports traditional C/C++ syntax. Nobody
has to use any of these new features I am adding. They exist as one
more tool in the toolbox, able to be used for those who see value in
that tool.
 
--
Rick C. Hodgin
scott@slp53.sl.home (Scott Lurndal): Apr 10 02:10PM


>I can't tell you what Öö thinks is "real C++", but I'd guess that in
>your "real C++ code base" you don't declare variables of type T and T*
>in the same line.
 
As a general rule, you're correct, variables are declared one per line.
scott@slp53.sl.home (Scott Lurndal): Apr 10 02:17PM

>that is "CWhatever* p", "CWhatever [p]", "CWhatever^ p", "pointer to
>CWhatever p". But the key thing is to have a single clear and
>unambiguous syntax.
 
Or you can be more verbose:
 
08050000 ssp_initialize
08054000PROC;
08055000SHARES
08056000 CONST loader_storage,
08057000 CONST mcp_identification,
08058000 CONST pointer_reference_table,
08059000 VAR queue_storage,
08060000 CONST shared_systems_data;
08061000
08062000VAR
08063000 base_ptr DAT_POINTER := ioat_ptrs.first_element,
08064000 ch_ptr PTR TO CHANNEL_TABLE_ENTRY := nil,
08065000 search_done BOOLEAN := false,
08066000 status_buffer SSP_STATUS,
08067000 status_ptr PTR TO SSP_STATUS := ptr( status_buffer );
08068000
08069000
08070000
08071000 DO
08072000 FIND ioat_ptr OVER base_ptr..ioat_ptrs.last_element
08073000 INTO ioat_ptrs.base @
08074000 WHERE ioat_ptr@.primary_hardware_type = shared_system_processor
08075000 THEN
08076000 ch_ptr := ptr( channel_table_ptrs.base @
08077000 [ioat_ptr @.primary_channel_number] );
08078000 ch_ptr @.flags.good_firmware_file := false;
...
 
Declarations are obvious "PTR TO <type>" and
dereferences are visible (@).
bartc <bc@freeuk.com>: Apr 10 03:20PM +0100

On 10/04/2018 14:36, David Brown wrote:
 
> So I would prefer to have the pointer as part of the type, and choose a
> syntax that does not match C in order to avoid misunderstanding - such as:
 
> int^ p = &x;
 
That's getting on the right lines, depending on dereference syntax. If
it's now ^p, then you have the same problem.
 
(Elsewhere I write types strictly left-to-right, with a variable name
following if this is a declaration:
 
ref int p := &a
ref int p; p := &a
 
The difference between assignment and declaration/initialisation of one
variable, is simply that type spec stuck on the left. And the
left-to-right form allows building of complex types more naturally in a
way that exactly follows the English:
 
ref[]ref int p # pointer to array of pointer to int
 
The only quibble might be whether you stick the variable before or after
the type, and with what extra syntax.
 
What you wouldn't do is stick the variable name IN THE MIDDLE of the
type, and even end up splitting the type into THREE PARTS like the
variable 'c' here:
 
int a,b, *c[10];
 
So you have the 'int', '*', and '[10]' all in different places with
respect to the variable name. If someone were to invent this syntax now,
you'd think they were having a laugh.
 
And if that wasn't enough, if the parts are numbered 1, 2 and 3, you
have to rearrange them as 3, 2, 1 to read off the type, or as 2, 3, 1 if
it was (*c)[10].)
 
 
 
> Different assembly languages use different syntaxes. There is nothing
> wrong with using [p] for indirection, taking inspiration from Intel
> format x86 assembly, but don't imagine it is universal in assembly.
 
This is recycling the C (and now also C++) idea of declaration syntax
having to mirror expression syntax, which leads to the situation I
mentioned above.
 
How about, just keeping it simple:
 
TYPE NAME
 
or, declaring several names with exactly the same type wouldn't be
objectionable:
 
TYPE NAME, NAME, NAME
 
And not STILL having part of the type syntax that wraps itself around name.
 
--
bartc
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 10 03:29PM +0100


> You can get a lot worse than that (you can throw in some function
> declarations, typedefs, etc.), but such mixes are fortunately rare in
> real code - even in C code without coding standards.
 
There is a function declaration in there! (You probably meant a pointer
to function, since those start to get more complex.)
 
I think part of the trouble is that so many people learn C "by
example". And when coding standards say you should put only one
declaration on a line there's no incentive to learn.
 
Because I know that the * is part of little expression-like syntax that
revolves around the name being declared, I can't stand seeing
 
char* x;
 
It really grates. It looks like
 
return! x;
or
return x +1;
 
to me.
 
Given that this is comp.lang.c++ it's worth noting that such derived
types are rare in programs that use the standard library so it's often
much less of an issue.
 
>> In real C++ code bases it is getting irrelevant because raw arrays
>> are rarely used and raw pointers are rarely used...
 
Oh, snap!
 
--
Ben.
David Brown <david.brown@hesbynett.no>: Apr 10 04:53PM +0200

On 10/04/18 16:29, Ben Bacarisse wrote:
>> real code - even in C code without coding standards.
 
> There is a function declaration in there! (You probably meant a pointer
> to function, since those start to get more complex.)
 
Let's assume that's what I meant, rather than simply failing to read
properly :-)
 
 
> I think part of the trouble is that so many people learn C "by
> example". And when coding standards say you should put only one
> declaration on a line there's no incentive to learn.
 
I don't think it is a matter of not learning - I know fine how things
work when you have multiple declarations in one line. But mixing
concepts together too tightly is never a good idea for clarity.
 
I also think your declarations mostly either have expressive (and
therefore somewhat longer) names, a useful comment, an initialiser, or
are so local that they are part of a loop (like "for (int i ..."). The
lines are long enough, and contain enough information, that one
declaration at a time is a good size.
 
There are exceptions, of course.
 
> Because I know that the * is part of little expression-like syntax that
> revolves around the name being declared, I can't stand seeing
 
> char* x;
 
To me, that is putting the emphasis on x being a pointer-to-char. I
tend to write "char * x;" myself, as I would usually want an initialisation:
 
char * x = &b;
 
I dislike seeing :
 
char *x = &b;
 
because "*x = &b;" would be wrong after the declaration and initialisation.
 
> or
> return x +1;
 
> to me.
 
Those two would really annoy me too.
 
David Brown <david.brown@hesbynett.no>: Apr 10 05:05PM +0200

On 10/04/18 16:20, bartc wrote:
> left-to-right form allows building of complex types more naturally in a
> way that exactly follows the English:
 
> ref[]ref int p # pointer to array of pointer to int
 
I'd be inclined to use either keywords or punctuation, rather than a
mixture, but that's just preference. I'd also use more spaces.
 
> The only quibble might be whether you stick the variable before or after
> the type, and with what extra syntax.
 
You might also want keywords to say that this is a variable declaration
(or a block of variable declarations) rather than a statement (or block
of statements). Some programming languages require an extra keyword to
declare the identifier as a non-constant variable, which I think is a
good idea - if I were designing a new language, "variables" would be
immutable by default.
 
> type, and even end up splitting the type into THREE PARTS like the
> variable 'c' here:
 
> int a,b, *c[10];
 
Well, /you/ wouldn't do it! Clearly some other people are quite happy
with that. In C, the declaration syntax is designed to match the way
the variable is used, rather than to emphasis its type. Since the
language has postfix and prefix operators, both can occur in the
declarations.
 
If I were making a language, I would probably be using much stronger
typing than in C and with a bigger emphasis on types - thus having the
type entirely before or entirely after the variable name would be natural.
 
> So you have the 'int', '*', and '[10]' all in different places with
> respect to the variable name. If someone were to invent this syntax now,
> you'd think they were having a laugh.
 
No, you would not - at least, you would not laugh if you understood
about language design - as distinct from having designed a couple of
simple languages and thinking that they are the only good ways to make a
language.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:21AM -0700

On Tuesday, April 10, 2018 at 8:21:08 AM UTC-4, Mr Flibble wrote:
 
> No. You use Satan as an excuse to not answer any question that might
> conflict with your worldview so Kenny is correct when he says that
> religious people can't answer such questions.
 
No, Leigh. Satan really is real. Demons are real. The spirit
nature is real. Our flesh cannot see it, but only the effects
of it, because we are spiritually dead due to sin.
 
I explain these things to you so you can know the truth, but you
reject it. It's why you don't understand or believe the things
I say as being true, nor trust the contents of the Bible as being
true.
 
You refuse to acknowledge the possibility that something beyond
this tangible, physical, flesh-knowing world we live in actually
exists. If you ever step away from that place you will then be
able to pursue the truth. Until that time, it will totally elude
you.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 02:30PM +0100

On 10/04/2018 14:21, Rick C. Hodgin wrote:
> exists. If you ever step away from that place you will then be
> able to pursue the truth. Until that time, it will totally elude
> you.
 
Evolution mate. Speed of light in a vacuum mate.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 06:48AM -0700

On Tuesday, April 10, 2018 at 9:30:50 AM UTC-4, Mr Flibble wrote:
> Evolution mate. Speed of light in a vacuum mate.
 
Ever see "A Fish Called Wanda?" Remember this scene with Otto and
Wendy?
 
Wendy: My father was in the Secret Service, Mr. Manfredjinsinjin,
and I know perfectly well that you don't keep the general
public informed when you are "debriefing KGB defectors in
a safe house."
 
Ever see Star Trek Voyager and the episode with the female Q (Q's wife)?
 
FEMALE Q: Try to wrap your minuscule mind around this. These
supernovas are actually caused by spatial disruptions
within the Continuum, the result of the war. Now,
each time a star implodes, a negative density false
vacuum is created which actually sucks the surrounding
matter into the Continuum.
 
-----
Now, in that same tone picture me saying this to you (as you stand
there looking like Otto):
 
Rick: Try to wrap your brain around this, Leigh. Everything you
think exists ... it's not the limit of what exists. There's
a whole spiritual universe out there beyond this one, here
right now at the same time, invisible to your natural eyes
but more real than all of this. It's from within that
spirit nature that God exists, which is why your miniscule
mind cannot fathom God's existence today. But if you'll
take even one conscious step away from that permanent magnet
you seem affixed to, then you'll be taking your first step
to true enlightenment, real understanding, and eternal life.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 03:23PM +0100

On 10/04/2018 14:48, Rick C. Hodgin wrote:
> take even one conscious step away from that permanent magnet
> you seem affixed to, then you'll be taking your first step
> to true enlightenment, real understanding, and eternal life.
 
Quod gratis asseritur, gratis negatur.
What can be asserted without evidence can be dismissed without evidence.
 
https://en.wikipedia.org/wiki/Hitchens%27s_razor
 
Evolution mate. Speed of light in a vacuum mate.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 07:34AM -0700

On Tuesday, April 10, 2018 at 10:23:58 AM UTC-4, Mr Flibble wrote:
> > to true enlightenment, real understanding, and eternal life.
 
> Quod gratis asseritur, gratis negatur.
> What can be asserted without evidence can be dismissed without evidence.
 
The evidence exists, Leigh. It exists spiritually, not physically.
It's what I've been trying to teach you. I used to also believe as
you do. So sure I was right. When I came to seek the truth, God
gave it to me, and it completely blew everything I previously held
out of the water.
 
That's what I'm teaching you. There's more than your flesh knows
today.
 
> https://en.wikipedia.org/wiki/Hitchens%27s_razor
 
> Evolution mate. Speed of light in a vacuum mate.
 
God created the entire universe by His word. He could've assembled
everything as we see it today, Leigh, just as our video games would
load the entire world in as a single scene before game play begins.
 
You understand these concepts fully. You refuse to acknowledge the
possibility that God exists and created more than a mere video game
using His ability to instantiate everything, and you do so solely
because of sin and your love of sin ahead of truth.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 03:36PM +0100

On 10/04/2018 15:34, Rick C. Hodgin wrote:
> you do. So sure I was right. When I came to seek the truth, God
> gave it to me, and it completely blew everything I previously held
> out of the water.
 
Quod gratis asseritur, gratis negatur.
 
 
> That's what I'm teaching you. There's more than your flesh knows
> today.
 
Quod gratis asseritur, gratis negatur.
 
 
> God created the entire universe by His word. He could've assembled
> everything as we see it today, Leigh, just as our video games would
> load the entire world in as a single scene before game play begins.
 
Quod gratis asseritur, gratis negatur.
 
> possibility that God exists and created more than a mere video game
> using His ability to instantiate everything, and you do so solely
> because of sin and your love of sin ahead of truth.
 
Quod gratis asseritur, gratis negatur.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 07:40AM -0700

On Tuesday, April 10, 2018 at 10:36:50 AM UTC-4, Mr Flibble wrote:
> > gave it to me, and it completely blew everything I previously held
> > out of the water.
 
> Quod gratis asseritur, gratis negatur.
 
Oro te, ut veritas revelata sunt a Domino.
 
 
> > That's what I'm teaching you. There's more than your flesh knows
> > today.
 
> Quod gratis asseritur, gratis negatur.
 
Oro te, ut veritas revelata sunt a Domino.
 
> > everything as we see it today, Leigh, just as our video games would
> > load the entire world in as a single scene before game play begins.
 
> Quod gratis asseritur, gratis negatur.
 
Oro te, ut veritas revelata sunt a Domino.
 
> > using His ability to instantiate everything, and you do so solely
> > because of sin and your love of sin ahead of truth.
 
> Quod gratis asseritur, gratis negatur.
 
Oro te, ut veritas revelata sunt a Domino.
 
--
Rick C. Hodgin
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 04:04PM +0100

On 10/04/2018 15:40, Rick C. Hodgin wrote:
> Oro te, ut veritas revelata sunt a Domino.
 
Nemo curat.
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Apr 10 07:46AM -0700

On Saturday, March 31, 2018 at 2:51:08 PM UTC-4, Andrey Karpov wrote:
> A new version of the PVS-Studio analyzer 6.23 is working under macOS, which allows you to check the projects written in C and C++. Our team decided to perform a XNU Kernel check to coincide it with this event. https://www.viva64.com/en/b/0566/
 
I continued to use this tool for a few more days and remain thoroughly
and completely impressed. All told it found about 300 things in my
35K line app. About 6 of them were legitimate bugs. The rest were
cases where I was double-testing a variable, using memcmp() without
comparing an entire buffer, copying more data to a structure than did
exist in the structure definition (when the structure pointed to a 512-
byte block, but only had a few bytes which are the start of the fixed
portion of the structure, and the remaining 400+ bytes were always
variable).
 
It actually helped solidify one of my projects. It's made it more
stable by finding a case where I did this:
 
memset(ptr, 0, sizeof(ptr));
 
Rather than:
 
memset(ptr, 0, sizeof(*ptr));
 
And a few others like that.
 
-----
Bottom line: I recommend this tool to everyone who does C/C++ code.
It integrated seamlessly with Visual Studio, and was very easy to use.
 
--
Rick C. Hodgin
"James R. Kuyper" <jameskuyper@verizon.net>: Apr 10 10:07AM -0400

On 04/10/2018 03:11 AM, Barry Schwarz wrote:
 
>> This compiles just fine on Visual C++ 2015.
 
> Because there is an implicit conversion from the integer 0 to the
> character '0x00'.
 
You're thinking about the implicit conversion from a null pointer
constant (which 0 qualifies as) to a null pointer of any particular
type. std::string doesn't have a constructor from a single integer type
of any size, not even "char", but it does have a constructor from a
char* value.
 
However, the description for that constructor has says:"Requires: s
points to an array of at least traits::length(s) + 1 elements of charT."
(24.3.2.2p10).
 
Note: this description is for std::basic_string<charT, traits,
Allocator>. In the context of std::string, "traits" refers to
std::char_traits<char>.
 
As a null pointer, (char*)0 is prohibited from pointing at any object,
so it cannot meet that requirement.
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.

No comments: