Saturday, May 7, 2016

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

Rosario19 <Ros@invalid.invalid>: May 07 06:18AM +0200

On Tue, 3 May 2016 11:44:53 -0700 (PDT), "Rick C. Hodgin" wrote:
 
>use in the target function, which is desirable while still carrying out
>remote data assignment. There's just no way to know if something is a
>reference or not without additional interrogation of the source code.
 
and if the pointer is NULL? [the sys has not memory for the obj]
i like all these NULL checks
Rosario19 <Ros@invalid.invalid>: May 07 06:22AM +0200

On Tue, 3 May 2016 20:36:30 +0200, Melzzzzz wrote:
 
>Operator overloading. Having c = a + b; is more convenient then
>c = &a + &b;
 
c = a + b
 
if the types of c, a, b are objects and not basic types
should mean already "&c = &a + &b"
Rosario19 <Ros@invalid.invalid>: May 07 06:24AM +0200

On Sat, 07 May 2016 06:22:38 +0200, Rosario19 wrote:
 
 
>c = a + b
 
>if the types of c, a, b are objects and not basic types
>should mean already "&c = &a + &b"
 
and reference has not objius use...
so reference is one error in the story of informatic...
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 07 05:00AM

On Tue, 2016-05-03, K. Frank wrote:
...
> those arguments. (This is what I generally do. I either
> "forbid" the use of null -- and other invalid -- pointers,
> or test for them.)
 
That's what I used to do too, but after a discussion with someone here
I more or less stopped doing that, and embraced non-const reference
parameters.
 
In practice it works well. These cases are rare (especially if you
don't use them often as a possibly-faster substitute for return
values) and it's usually pretty clear from context what happens: you
tend to see at the call site that the function intends to modify
what's passed in.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 07:21AM -0700

On Saturday, May 7, 2016 at 12:24:59 AM UTC-4, Rosario19 wrote:
 
> >c = a + b
 
> >if the types of c, a, b are objects and not basic types
> >should mean already "&c = &a + &b"
 
This kind of syntax is silly. :-) My only interest in highlighting
the use of reference values in syntax is when they're passed as input
into functions, either directly or indirectly. I'd like to see that
they are entering a function as a non-const reference parameter (meaning
they might be updated).
 
> and reference has not objius use...
> so reference is one error in the story of informatic...
 
They remove the need to check for NULL because all reference params
come in guaranteed by the compiler to be non-NULL. The only way they
can be non-NULL is if some illegal and sneaky or tricky happens.
 
The syntax in the function which uses the reference is greatly
simplified while allowing remote data (data at the other end of a
pointer) to be updated as though it were local data.
 
My only issue is that these two look identical (except for the function
name), yet they are capable of doing completely different things:
 
func1(int a, int b, int c) { ... }
func2(int& a, int& b, int& c) { ... }
 
int a, b, c = 0;
 
func1(a, b, c);
func2(a, b, c);
 
There's no way to know without changing the syntax. It should be like
this:
 
func1(a, b, c);
func2(@a, @b, @c);
 
In this way it's obvious that a, b, and c in func2() are reference
parameters that may be updated. And the additional syntax of the
@a! would indicate it's a const reference that won't be updated,
and @a' means it could. I would also be open to @a# as an alternate
syntax (to indicate it is non-const, and then to use @a' or some
other form to indicate it's not const, but should not be updated
by convention rather than enforcement).
 
Best regards,
Rick C. Hodgin
Rosario19 <Ros@invalid.invalid>: May 07 07:14PM +0200

On Sat, 7 May 2016 07:21:04 -0700 (PDT), "Rick C. Hodgin" wrote:
 
>They remove the need to check for NULL because all reference params
>come in guaranteed by the compiler to be non-NULL. The only way they
>can be non-NULL is if some illegal and sneaky or tricky happens.
 
i not see as you...
i see malloc or stack give the memory for create the obj
and *no one* can garantee that memory exist....
 
so the way of resolve the problem is see if &obj==NULL
and not the compiler that know that the memory for the obj exist..
 
because objects are created in run time too
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 11:58AM -0700

On Saturday, May 7, 2016 at 1:14:25 PM UTC-4, Rosario19 wrote:
 
> so the way of resolve the problem is see if &obj==NULL
> and not the compiler that know that the memory for the obj exist..
 
> because objects are created in run time too
 
The compiler guarantees that a pointer is not NULL when you use a
reference. It will not allow something by reference that is NULL.
 
int a, b, c;
 
These are not allocated at runtime by a runtime function, but rather
they exist by the mechanics of the machine (the stack). As such, you
will be guaranteed that you are able to use them when you try to use
them because the stack error would've already occurred before you got
to the place in your program where you were trying to use them.
 
The only way you can have a NULL is by someone doing something that
is not legal code, such as by passing a NULL input to a function that
is receives a reference parameter in that slot. In that case, the
language protocol has been violated and the error condition is the
result.
 
By using this secure feature, the only way that the function could
be fooled is if the virus had intimate knowledge of the runtime state
of the program because it would not be able to read the source code
to find out what value to use with the call.
 
And something SuperCat brought up has made me consider something
along the lines of what another user pointed out in comp.lang.c,
which is that there should be true security with regards to the
actual API entry points the application uses, so that they cannot
even be called unless they pass security scrutiny. And I am
considering how I could implement that feature in my CPU as I
think it's a truly brilliant suggestion.
 
But as for by-reference parameters, they have great utility because
they have simplified syntax, and there is then no need to consider
them ever being NULL in a compliant system. I view them as an
essential component of software development.
 
Best regards,
Rick C. Hodgin
Rosario19 <Ros@invalid.invalid>: May 07 09:50PM +0200

On Sat, 7 May 2016 11:58:19 -0700 (PDT), "Rick C. Hodgin" wrote:
 
> int a, b, c;
 
>These are not allocated at runtime by a runtime function, but rather
>they exist by the mechanics of the machine (the stack).
 
i know if "int a,b,c;" are global than there is the "garantee" the
memory where they are exist
 
but if "int a,b,c;" is in the stack
[as local variables for one function] there is not such garantee...
 
>As such, you
>will be guaranteed that you are able to use them
 
there is for little size variable some "garantee" but enven in that
case if
int f(void){int a,b,c; a=1; f(); }
this should seg fault because "a" has no memory...
 
if you think that f() is one error, than exist function recursive have
need big memory on stack for calculate their finaly result...
 
>considering how I could implement that feature in my CPU as I
>think it's a truly brilliant suggestion.
 
>But as for by-reference parameters,
 
i find "by-reference" as const
errors streets for informatic...
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 12:57PM -0700

On Saturday, May 7, 2016 at 3:51:05 PM UTC-4, Rosario19 wrote:
> memory where they are exist
 
> but if "int a,b,c;" is in the stack
> [as local variables for one function] there is not such garantee...
 
If they are local variables, it is guaranteed they will exist. If
they are pointers to those types, then it is possible they will not
exist, even though it is guaranteed the pointer itself WILL exist,
as it can always be tested for NULL, for example.
 
int a;
int* b = (int*)malloc(sizeof(int));
// a and b always exist
// But, it's possible *b doesn't because it was allocated at runtime
 
> case if
> int f(void){int a,b,c; a=1; f(); }
> this should seg fault because "a" has no memory...
 
Yes, but the segfault occurs before you are able to use a. If, however,
you are able to use a (because you are on that line of source code),
then you know it exists.
 
That's my point, the error would've occurred BEFORE you were able to
use a.
 
> if you think that f() is one error, than exist function recursive have
> need big memory on stack for calculate their finaly result...
 
If you have a recursive function that could exceed the stack, then it
is a requirement that you guard against that by monitoring your depth.
If it gets too high, then you implement a protocol which fails further
recursion.
 
 
> >But as for by-reference parameters,
 
> i find "by-reference" as const
> errors streets for informatic...
 
I may be misunderstanding what you mean, but by-reference doesn't have
to be const. The two are separate, and much of their utility comes in
the non-const form.
 
> >they have simplified syntax, and there is then no need to consider
> >them ever being NULL in a compliant system. I view them as an
> >essential component of software development.
 
Best regards,
Rick C. Hodgin
Rosario19 <Ros@invalid.invalid>: May 07 10:03PM +0200

On Sat, 7 May 2016 12:57:37 -0700 (PDT), "Rick C. Hodgin" wrote:
 
>I may be misunderstanding what you mean, but by-reference doesn't have
>to be const. The two are separate, and much of their utility comes in
>the non-const form.
 
references and consts
are two words not good for the informatic
are wrong ways in how i see them
Rosario19 <Ros@invalid.invalid>: May 07 10:04PM +0200

On Sat, 7 May 2016 12:57:37 -0700 (PDT), "Rick C. Hodgin" wrote:
 
>I may be misunderstanding what you mean, but by-reference doesn't have
>to be const. The two are separate, and much of their utility comes in
>the non-const form.
 
"reference" and "const"
are two words not good for the informatic
are wrong ways in how i see them
"Öö Tiib" <ootiib@hot.ee>: May 07 01:32PM -0700

On Saturday, 7 May 2016 17:21:20 UTC+3, Rick C. Hodgin wrote:
> this:
 
> func1(a, b, c);
> func2(@a, @b, @c);
 
We understood that, we just are unsure if it is improvement. Can you for
a variety bring some motivating examples? Where you really need functions
with 3 or more "in-out" parameters? What are those functions doing?
 
C++ has some mechanics to make function calls more expressive. For example
when there is a function with one "in" parameter, one "in-out" parameter
and one "out" parameter then I expect the designer of interface to arrange
the call like that in C++:
 
out_parameter = in_out_parameter.function( in_parameter );
 
If there are two "in-out" parameters then one of those has to be
passed as reference or pointer to non-const however that situation
is typically obvious from function's name. Situation with three or
more in-out parameters however feels complicated regardless if
there are some special indication of those or not. IOW it tends to
work fine like it is in practice.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 01:48PM -0700

On Saturday, May 7, 2016 at 4:32:20 PM UTC-4, Öö Tiib wrote:
> more in-out parameters however feels complicated regardless if
> there are some special indication of those or not. IOW it tends to
> work fine like it is in practice.
 
The place where it occurred to me was in source code like this (a
greatly simplified example):
 
// Parse the string
void some_function(char* data, int length)
{
int offset;
 
for (offset = 0; offset < length; )
{
// Skip any leading whitespaces
skip_whitepsaces(data, offset, length);
 
// Parse something else
// Skip past the parsed data
}
}
 
At first glance, I was wondering why offset was being used, and why data
wasn't being updated. It took me a couple seconds to realize that offset
must be being passed by reference, and is being updated.
 
Had it been written like this, I would've known without even thinking
about it:
 
skip_whitepsaces(data, @offset, length);
 
I would've recognized that character there and said silently to myself,
"Ah ha!"
 
It was after I read that source code line I had the thought, because
after the brief few seconds where I was puzzled, and then when I came
to the realization, I remembered other times in my past where I had
encountered similar things, each time winding up doing one of these
things:
 
http://www.omsmedia.com/wordpress/wp-content/uploads/2013/05/kid-head-slap.jpg
 
It got me to thinking about why do we have "int& a" rather than
something else? We use & for address-of, which is associated with a
pointer, but we also use it for a reference? Really? It seemed
backwards.
 
And, I remembered how I had decided to fix this issue in my CAlive
language I'm working on:
 
https://groups.google.com/forum/#!topic/caliveprogramminglanguage/mFVHvtDTmo8
 
I introduce @, and allow @ or & to be used for a reference or pointer
form, allowing a new relaxation, and one which I hope will spawn a
switch to where pointers being to use @var for the equivalent of what
today is &var, and that we will begin using &var for the equivalent
of what today is a pass-by-reference syntax, that which I have here
been proposing should use the new @var form in C/C++.
 
In CAlive I want them to be reversed because I think they make more
sense the other way around, but I am not prepared to break backward
compatibility, so I would allow either at both and resolve the ambiguity
by the declaration type, or the type of the body definition if the
declaration is not present (as CAlive also has plans to remove the
need for forward declarations).
 
And, to be clear, CAlive is a somewhat object-oriented version of C.
It is much less than C++, but brings to C many of the essential elements
of C++ (as I see them, and there's room for expansion or contraction as
other people provide input).
 
Best regards,
Rick C. Hodgin
Rosario19 <Ros@invalid.invalid>: May 07 07:33PM +0200

basic types should be as now
 
signed
int32_t
int8_t
int16_t
etc
unsigned
types for 32 8 16 bit etc
 
and should be values
so
int32_t a;
and a is a value as now
 
 
but structs and classes have to be address for example
 
clasA w;
 
than w is a pointer to the obj defined from the clasA
 
[if that obj has not memory for to be create from the system
than this if print no mem for w
if(w==0) print("No Mem for w");
]
 
this can be ok in using of operators as in
 
a=b+c;
 
so there is no reason for the reference....
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 12:23PM -0700

On Saturday, May 7, 2016 at 1:33:23 PM UTC-4, Rosario19 wrote:
> than this if print no mem for w
> if(w==0) print("No Mem for w");
> ]
 
That's the difference between using pointers and native objects. With
a pointer there is an allocation step, and it does introduce the potential
for a failed allocation. When you use a native object, it is already
allocated by the time you are able to use it in your program.
 
By reference variables give you the same ability. By the time you're
able to use them, you know they are valid because the error would've
already occurred before you were able to use them in your line of source
code.
 
> this can be ok in using of operators as in
 
> a=b+c;
 
> so there is no reason for the reference....
 
What does this mean (a=b+c) when a, b, or c are something other than
a fundamental data type? In that case their use requires the class
definition to make it have contextual sense. And as such, the needs of
that mechanism at runtime require that a reference to the object be
available for the context, otherwise they'd be converted to pointers
which does introduce the possibility of a NULL and does then require
the extra protection against NULL pointers, which is one of the things
the use of references was created to avoid.
 
-----
There are cases where you know you have valid data. There's no reason
to then use it as a pointer because it makes the syntax more complex,
and it requires that you consistently guard against NULL values in the
pointer. With references, all of that disappears and your code is both
cleaner, and faster, because you can remove the requisite NULL checks.
 
Best regards,
Rick C. Hodgin
Rosario19 <Ros@invalid.invalid>: May 07 09:59PM +0200

On Sat, 7 May 2016 12:23:30 -0700 (PDT), "Rick C. Hodgin" wrote:
>> ]
 
>That's the difference between using pointers and native objects. With
>a pointer there is an allocation step,
 
allocation step is done from C++ constructor
basically the constructor has one arg &w
and fill it with the address right [if memory exist for that] or 0 in
the other case.
 
>and it does introduce the potential
>for a failed allocation.
 
memory infinite not exist but with this the program can see if obj is
0 [memory error]
if it is 0 the program can run and report the error without segfault
 
 
>> so there is no reason for the reference....
 
>What does this mean (a=b+c) when a, b, or c are something other than
>a fundamental data type?
 
b is address where b is
c is address where c is
doing b+c assign the result to t
copy t to a
free t
 
Rosario19 <Ros@invalid.invalid>: May 07 10:10PM +0200

On Sat, 7 May 2016 12:23:30 -0700 (PDT), "Rick C. Hodgin" wrote:
 
>There are cases where you know you have valid data.
 
0,1%
 
>There's no reason
>to then use it as a pointer because it makes the syntax more complex,
 
if it would be for me all would be a pointer
 
>and it requires that you consistently guard against NULL values in the
>pointer.
 
only in the start of the function or operator
 
>With references, all of that disappears
 
but the finite memory problem remain
 
>and your code is both
>cleaner, and faster,
 
i prefer the checks
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 01:15PM -0700

On Saturday, May 7, 2016 at 3:59:49 PM UTC-4, Rosario19 wrote:
> basically the constructor has one arg &w
> and fill it with the address right [if memory exist for that] or 0 in
> the other case.
 
That's true of pointers to class objects, but not of objects which are
on the stack. They occupy local stack space and physically exist.
There is no allocation step, however their constructors are called,
and their destructors also upon exit.
 
 
> memory infinite not exist but with this the program can see if obj is
> 0 [memory error]
> if it is 0 the program can run and report the error without segfault
 
That's the point, with references you do don't need to. IF you are
on the line of source code where you are using it, it _already_ exists
and _is not_ NULL.
 
That's one of their features.
 
> doing b+c assign the result to t
> copy t to a
> free t
 
Not necessarily. Operator overrides change the meaning to custom
applications, and it doesn't have to mean anything like that, though
it typically might.
 
References are then used here for one or both sides of each operator.
Internally, the compiler will issue steps to handle certain things
based on operations, but it doesn't have to be that way. It depends
on what code exists and is in use.
 
> >and it requires that you consistently guard against NULL values in the
> >pointer. With references, all of that disappears and your code is both
> >cleaner, and faster, because you can remove the requisite NULL checks.
 
Best regards,
Rick C. Hodgin
Paavo Helde <myfirstname@osa.pri.ee>: May 07 11:17PM +0300

On 7.05.2016 22:23, Rick C. Hodgin wrote:
> a pointer there is an allocation step, and it does introduce the potential
> for a failed allocation. When you use a native object, it is already
> allocated by the time you are able to use it in your program.
 
Rosario19 did not have any pointers or allocations, so talking about
NULL pointers or failed allocations was not appropriate.
 
BTW, pointers are native data types in C/C++. What you are talking about
is the difference between dynamically and automatically allocated
storage. This is orthogonal to the "native types" concept, you can
easily have
 
int* p = new int(42);
 
for example, where you have an object of native type (int) allocated
dynamically.
 
Best regards
Paavo
 
(PS. I never reply to Rosario19 directly because he (or she or it) is
apparently not capable to keep up a coherent conversation.)
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 01:24PM -0700

On Saturday, May 7, 2016 at 4:17:48 PM UTC-4, Paavo Helde wrote:
> > allocated by the time you are able to use it in your program.
 
> Rosario19 did not have any pointers or allocations, so talking about
> NULL pointers or failed allocations was not appropriate.
 
Look at Rosario19's code. It's why I mentioned it.
 
> is the difference between dynamically and automatically allocated
> storage. This is orthogonal to the "native types" concept, you can
> easily have
 
No. I mention that pointers are native types, but that the things
they point to are not always guaranteed to exist, however, the pointer
itself will always exist and can be tested for NULL, for example.
 
> int* p = new int(42);
 
> for example, where you have an object of native type (int) allocated
> dynamically.
 
I stated something similar in previous post.
 
> Paavo
 
> (PS. I never reply to Rosario19 directly because he (or she or it) is
> apparently not capable to keep up a coherent conversation.)
 
Best regards,
Rick C. Hodgin
Rosario19 <Ros@invalid.invalid>: May 07 10:27PM +0200

On Sat, 7 May 2016 13:15:22 -0700 (PDT), "Rick C. Hodgin" wrote:
>on the stack. They occupy local stack space and physically exist.
>There is no allocation step, however their constructors are called,
>and their destructors also upon exit.
 
i speak the impossible case (for C++ because they define in one other
way)
ClassName a;
a is a pointer to the object so one
sizeof(void*) or one size of pointer
 
the obj "a" is in the memory returned from malloc() [or one stack
allocator]
 
 
for example in
ClassName a;
 
a==0xFF00FF and from
 
0xFF00FF to 0xFF00FF+sizeof(obj)
there is the "a" obj
 
so ((u8*)a)[0..sizeof(obj)] is where the obj is...
 
 
>That's the point, with references you do don't need to. IF you are
>on the line of source code where you are using it, it _already_ exists
>and _is not_ NULL.
 
and if it is NULL the sys what do? it is the programmer that says to
the sys what to do?
 
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 07 01:35PM -0700

On Saturday, May 7, 2016 at 4:27:57 PM UTC-4, Rosario19 wrote:
> ClassName a;
> a is a pointer to the object so one
> sizeof(void*) or one size of pointer
 
No. The syntax "ClassName a;" is a real object that exists on the
stack. You would have to use "ClassName* a = new ClassName();" to
have a pointer which may or may not exist.
 
> the obj "a" is in the memory returned from malloc() [or one stack
> allocator]
 
Only in the case of pointers. When you do not use the "ClassName*"
declarator, it is just like if you had used "int a" in that it always
exists because it uses local stack space memory, but unlike "int a;"
the use of "ClassName a;" will cause the constructor to be called
before any code in the method/function, and the destructor will be
called when it exits.
 
 
> 0xFF00FF to 0xFF00FF+sizeof(obj)
> there is the "a" obj
 
> so ((u8*)a)[0..sizeof(obj)] is where the obj is...
 
Only in "ClassName* a = new ClassName();" does that happen. In the
case of just "ClassName a;" then it exists from &a to for sizeof(a)
bytes, which will be somewhere on the stack on most systems.
 
> >and _is not_ NULL.
 
> and if it is NULL the sys what do? it is the programmer that says to
> the sys what to do?
 
That my point: it won't ever be NULL if you don't use a pointer, or if
you pass a properly allocated value by its value by reference.
 
That's why references are so nice. Also because they simplify usage
syntax in called functions, while still maintaining the basic mechanics
of that which you would see were you using a pointer instead.
 
> >That's one of their features.
 
Best regards,
Rick C. Hodgin
Rosario19 <Ros@invalid.invalid>: May 07 10:35PM +0200

On Sat, 07 May 2016 23:17:31 +0300, Paavo Helde wrote:
 
>int* p = new int(42);
 
>for example, where you have an object of native type (int) allocated
>dynamically.
 
and if the system has no memory what return "new"?
i think return 0 to p...
bleachbot <bleachbot@httrack.com>: May 07 08:37PM +0200

Ramine <ramine@1.1>: May 07 02:40PM -0700

Hello...
 
 
C++ synchronization objects library was updated..
 
I have set the IsMultithread variable to true, to be sure of
thread safety. Now i think that you can be more confident
because i have tested it thoroughly.
 
 
You can download my new C++ synchronization objects library:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
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)