Wednesday, April 11, 2018

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

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.
 
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 10 11:26PM -0700

On 4/10/2018 3:22 PM, Ben Bacarisse wrote:
 
> short buffer[100], *bp = buffer;
 
> precisely because it seems to me clearer to link them. I don't know if
> this is "mixing concepts" or if it's doing it "too tightly".
 
Interesting. I prefer them on two separate lines. However, I think the
linking aspect is pretty nice.
 
Lets see how many errors I can make here:
_____________________________
short buffer[100] = { 0 };
short* bp = buffer;
_____________________________
 
;^)
 
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 11 08:43AM +0200

On 11.04.2018 00:22, Ben Bacarisse wrote:
> [snip]
 
> What do you with a pointer to an array? Do you write
 
> int(* x)[10];
 
That one's easy.
 
using Size = ptrdiff_t;
template< class T > using ptr_ = T*;
template< Size n, class T > using raw_array_ = T[n];
 
ptr_<raw_array_<10,int>> x;
 
Cheers & hth.,
 
- Alf
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
David Brown <david.brown@hesbynett.no>: Apr 11 09:40AM +0200

On 10/04/18 23:48, Rick C. Hodgin wrote:
 
>>> I don't have a goal to "get it out there."
 
>> Why do you continually mention it here?
 
> I have wanted the ideas I have to be incorporated into C and C++.
 
That will /never/ happen.
 
Some of your ideas are interesting for a new programming language
(though as you know, I disagree completely on many of them). Like
Bart's ideas of programming languages, you have different ways of doing
things that are perfectly legitimate in their own right. But these
proposals are not C or C++, and simply do not fit with these existing
languages. You cannot make the kinds of changes you want and still have
basically the same language - it would be something totally different
from C or C++.
 
The other issue is the way the C and C++ evolve. They do so very
differently from each other, but they are both very different from the
way you want to go with your language.
 
Very little changes in C - the whole point of the language is its
stability. The standards are changed only when there is a very clear
advantage to the change, when the change makes very little impact on
existing code, when the change has been tested out for a long time in at
least one /major/ compiler, when it is realistic to implement in
compilers, when someone has done all the work in making the proposal and
suggested standards changes, when it is been discussed amongst the
committee, when feedback has been collected from major compiler vendors,
and final decisions have been made.
 
Making your own personal tools or making Usenet posts does /nothing/ in
that process.
 
C++ moves forward a lot more rapidly than C, and the change process is
more open, but it is similarly far, far more involved than just coming
up with an idea.
 
 
Personally, I think it can be interesting to discuss ideas of other
languages, or compare them to C or C++. Sometimes these ideas can make
sense for a /new/ programming language, but not for C or C++.
 
> from everybody, much as I am doing here with you, and it was clear
> I was getting nowhere with anybody else, so I decided to move in
> 2015.
 
Of course you met nothing but resistance to trying to add classes or
exceptions to C. No one who understands C would expect anything else.
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 11 01:05AM -0700

On 4/9/2018 5:51 PM, Rick C. Hodgin wrote:
 
> When the product is
> released you'll be able to download it, source code and all, and
> examine it fully.
 
 
Well, that is nice. Btw, would you consider being able to download it a
form of "get it out there."?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 11 01:06AM -0700

On 4/11/2018 1:05 AM, Chris M. Thomasson wrote:
>> examine it fully.
 
> Well, that is nice. Btw, would you consider being able to download it a
> form of "get it out there."?
 
Or would it be encrypted?
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 11 01:06AM -0700

On 4/10/2018 3:01 PM, Rick C. Hodgin wrote:
> a hello.ca program.
 
> You are so very wrong about limited me, Chris. How wrong are you
> even more so about God?
 
I want to try out some programs in CAlive.
David Brown <david.brown@hesbynett.no>: Apr 11 10:29AM +0200

On 11/04/18 00:22, Ben Bacarisse wrote:
 
> short buffer[100], *bp = buffer;
 
> precisely because it seems to me clearer to link them. I don't know if
> this is "mixing concepts" or if it's doing it "too tightly".
 
I would always write that on two declarations. But I appreciate the
point - you are keeping the two tightly related variables in the same
declaration. There is no fixed definition of when things should be kept
together, or when they are similar "concepts" - you can match them up in
many different ways. (Being the same type is one kind of similarity, as
is being used in the same part of the code, or forming part of a bigger
interface, or being used in similar ways even in different parts of the
code.) The important thing is whatever makes the code clearer, easier
to understand, easier to maintain, and harder to get wrong.
 
So to /me/, that would be putting these two on separate lines. But
other programmers can view it differently while still keeping the
principles of code clarity - you are putting these two on the same line
for good, well-considered reasons, not just to save a bit of space.
 
 
> pointer-to-char. Pointers are declared with a * in the declarator and I
> see a plain, naked x. Now I /can/ parse char* x; but I have to spot the
> * placed as far away as possible from the declarator.
 
I actually write "char * x;" in my code. But again, preferences differ.
 
 
> What do you with a pointer to an array? Do you write
 
> int(* x)[10];
 
No, it would have to be "int (*x)[10];". I can't say it is something I
would write often - I would have had typedefs involved here:
 
enum { bufferSize = 10 };
typedef int buffer_t[bufferSize];
 
buffer_t incomingData;
buffer_t * pWorkingBuffer = &incomingData;
 
 
 
>> Those two would really annoy me too.
 
> Why? They annoy me because the spacing is "fighting" the syntax. Are
> you saying that that carries less weight for you in declarations?
 
No - I just disagree a little on what is "fighting the syntax" in
declarations.
David Brown <david.brown@hesbynett.no>: Apr 11 10:30AM +0200

On 11/04/18 08:43, Alf P. Steinbach wrote:
> template< class T > using ptr_ = T*;
> template< Size n, class T > using raw_array_ = T[n];
 
> ptr_<raw_array_<10,int>> x;
 
Surely you mean:
 
ptr_<raw_array_<10, int>> x;
 
:-)
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 11 02:07AM -0700

On 4/11/2018 1:06 AM, Chris M. Thomasson wrote:
 
>> You are so very wrong about limited me, Chris.  How wrong are you
>> even more so about God?
 
> I want to try out some programs in CAlive.
 
Does it support C11 threading? So far, I can only find a single compiler
that does this.
scott@slp53.sl.home (Scott Lurndal): Apr 10 05:21PM

>> language.
 
>The type syntax created in C and inherited by C++ is /not/ a good way of
>doing it as evidenced by the numerous ways you can be tripped up
 
The type syntax created in C and inherited by C++ _is_ a good way
of doing it as evidenced by the billions of lines of C and C++ code
in existence.
 
The fact that you refuse to understand the rules, doesn't invalidate them.
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."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 06:22PM +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?
 
So you can refer to an object without using pointer semantics.
 
/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."
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 10 04:57PM

> What is the C++ reasoning for having both & and * types? Why not just
> have * types?
Because of C legacy/>
 
 
--
press any key to continue or any other to quit...
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 .
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 10 01:20PM +0100

On 10/04/2018 00:58, Rick C. Hodgin wrote:
 
> It's that Christians see the traps Satan lays for people. Satan
> tries to trap people into caged boxes where the response they give
> in that case would serve to lead to Satan's desired end.
 
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.
 
/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."
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."
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."
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."
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Apr 11 12:40AM -0700

On 4/10/2018 1:47 PM, Chris M. Thomasson wrote:
 
>> Ever see "A Fish Called Wanda?"
 
> Yes Mr Thomason. They are missing an s.
 
> [...]
 
Btw, I can put some of stuff online:
 
https://groups.google.com/d/topic/sci.physics/1diSd7hZf-o/discussion
 
http://funwithfractals.atspace.cc/ct_fdla_pa_t0
 
 
https://groups.google.com/d/topic/sci.physics/x1U38KWmNHU/discussion
 
http://funwithfractals.atspace.cc/ct_fdla_anime_dynamic_test/
(point and click attractors!)
 
Read all, if you are not too afraid! ;^o
 
 
some of my simple glsl shaders, please do not try to view the following
links on a phone! Too much for them.
 
https://www.shadertoy.com/user/Chris_M_Thomasson
 
;^)
woodbrian77@gmail.com: Apr 10 07:05PM -0700

I've been thinking about serializing bools.
 
The following code is from this file:
https://github.com/Ebenezer-group/onwards/blob/master/Buffer.hh
 
static_assert(::std::numeric_limits<unsigned char>::digits==8,"");
 
Serializing:
inline void Receive (SendBuffer&b,bool bl){b.Receive(static_cast<unsigned char>(bl));}
 
Deserializing:
template<class R>
bool GiveBool (ReceiveBuffer<R>& buf){
switch(buf.GiveOne()){
case 0:return false;
case 1:return true;
default:throw failure("GiveBool");
}
}
 
GiveOne() returns a byte and is in the file I linked to.
 
Any comments on that much? The second thing is I'm
wondering if I should add a value, say 100, to the
bool values (0 and 1) to get away from the common
values of 0 and 1. False would be serialized as 100
and true as 101. Thanks in advance.
 
 
Brian
Ebenezer Enterprises - If you're happy and you know it,
clap your hands.
 
http://webEbenezer.net
Daniel <danielaparker@gmail.com>: Apr 10 09:45PM -0700


> The following code is from this file:
> https://github.com/Ebenezer-group/onwards/blob/master/Buffer.hh
 
Had a quick look, does your binary serialization take into account endianess? It wasn't obvious to me that it did.
> bool values (0 and 1) to get away from the common
> values of 0 and 1. False would be serialized as 100
> and true as 101.
 
No
 
Daniel
David Brown <david.brown@hesbynett.no>: Apr 11 09:20AM +0200

> bool values (0 and 1) to get away from the common
> values of 0 and 1. False would be serialized as 100
> and true as 101. Thanks in advance.
 
No, that would be pointless complication and confusing for anyone
looking at your protocol or code. If you have got out of
synchronisation with your serialisation, or the input data is corrupt,
your output data is wrong and a bias of 100 will not help. If there is
a risk of problems, then you need to look harder at your checksumming,
encoding mechanisms, error checking and correcting, etc., in code below
the "GiveOne()" level. Storing the boolean value as anything other than
0 or 1 is trying to fix something at the wrong level.
 
I would even question whether it is worth the effort checking for 0 and
1 and throwing an error here. When is it feasible for this error to
occur? (The answer should be never, if the lower levels are good.) How
is the user code likely to handle it? Are you testing this path in your
code? (Experience shows that error detecting, throwing and catching
code is often very poorly tested, and a source of bugs.)
 
template<class R>
bool GiveBool (ReceiveBuffer<R>& buf){
return buf.GiveOne();
}
 
Simpler, clearer, easier to test. If you get wrong data in, you get
wrong data out - but that is always the case.
"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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)