Monday, October 2, 2017

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

"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 02 08:50AM -0400

On 9/29/2017 9:44 AM, Rick C. Hodgin wrote:
>         //     i = 5
>     }
 
> Please advise any notes or comments.  Thank you in advance.
 
??
 
Does anybody have any thoughts on this feature, positive or negative?
 
--
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/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
bartc <bc@freeuk.com>: Oct 02 02:09PM +0100

On 29/09/2017 14:44, Rick C. Hodgin wrote:
>         //     i = 5
>     }
 
> Please advise any notes or comments.  Thank you in advance.
 
I've read it, and can't understand it. And you have two versions of
my_function(), but both apparently do the same thing.
 
What problem does this solve: how would the equivalent be done in C now,
and how would this new feature transform that?
 
And in the above, how many parameters does my_function() actually take,
is it 3, 4 or 5? Ie. how many values does the caller put on the stack
before passing control, or is there some magic that happens at the
call-site too?
 
--
bartc
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 02 09:19AM -0400

On 10/2/2017 9:09 AM, bartc wrote:
 
>> Please advise any notes or comments.  Thank you in advance.
 
> I've read it, and can't understand it. And you have two versions of
> my_function(), but both apparently do the same thing.
 
The first my_function() stores the incoming 3rd parameter to the
types indicated by max and total.
 
The second my_function() declares the incoming 3rd parameter as
two int variables, with the 3rd parameter being automatically
copied into both.
 
> What problem does this solve: how would the equivalent be done in C now,
> and how would this new feature transform that?
 
In C today:
 
my_function(1, 2, 3, 4);
 
void my_function(int a, int b, int p3, int c)
{
int max = p3;
int total = p3;
int i = 5;
}
 
The p3 value is received as a single parameter, and it is manually
copied to max and total.
 
> is it 3, 4 or 5? Ie. how many values does the caller put on the stack
> before passing control, or is there some magic that happens at the
> call-site too?
 
You pass in four parameters, but this parameter redirect ability kind
of reinterprets the parameters as incoming slots. Those slots then
align with their parameter definition in the target function, but can
also have logic applied by the compiler to automatically re-direct an
incoming parameter to multiple targets, or to multiple types, allowing
for the compiler to inject that code for you without multiple lines of
source code, or explicit casting (where required).
 
It's a way to save some code lines, document that the incoming params
are used in multiple local variables, or is the default value for the
return value (if it's redirected there), so that only those things
which actually alter the value (in the code within the function) are
seen in that code.
 
It de-clutters code, and performs the same kind of compiler-injected
initialization that creating a new class with default member values
does, in that they are assigned automatically before the first line
of function code is run.
 
--
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/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
David Brown <david.brown@hesbynett.no>: Oct 02 03:53PM +0200

On 02/10/17 14:50, Rick C. Hodgin wrote:
 
> Does anybody have any thoughts on this feature, positive or negative?
 
It strikes me as a complicated solution to a non-existent problem. I
cannot see any benefit over:
 
void my_function(int a, int b, int max_total, int c)
{
int i = 5;
int max = max_total;
int total = max_total;
...
}
 
At best, you are introducing a new syntax to save a line of code, or a
few characters of typing. That is a very poor tradeoff in my book.
 
Or have I misunderstood something here?
bartc <bc@freeuk.com>: Oct 02 03:32PM +0100

On 02/10/2017 14:19, Rick C. Hodgin wrote:
>> my_function(), but both apparently do the same thing.
 
> The first my_function() stores the incoming 3rd parameter to the
> types indicated by max and total.
 
Max and total are types (which types?) or variables?
 
> The second my_function() declares the incoming 3rd parameter as
> two int variables, with the 3rd parameter being automatically
> copied into both.
 
So what's the difference here, or isn't there any?
 
>     }
 
 
> The p3 value is received as a single parameter, and it is manually
> copied to max and total.
 
OK, everyone can understand this.
 
> incoming parameter to multiple targets, or to multiple types, allowing
> for the compiler to inject that code for you without multiple lines of
> source code, or explicit casting (where required).
 
Sorry, I can't parse that! But if all it does is copy a parameter to
multiple values, then it is easy enough to do now.
 
Using one (IMO more useful) extension to avoid re-stating a parameter
type, the above can be written like this:
 
void my_function(int a, b, max, c) {
int total = max;
int i = 5;
 
This assumes you don't need p3 as well (so three copies of the parameter
are needed). If so then it's what you have in C apart from writing the
params as 'int a, b, p3, c)'.
 
> It de-clutters code,
 
I've not convinced that this would be very useful. It happens sometimes
that you need to take a copy of an incoming parameter, leaving the
original unchanged. But that can be done most easily, AND WITHOUT ADDING
A NEW FEATURE, just by writing:
 
int total = p3;
 
--
bartc
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 02 11:26AM -0400

On 10/2/2017 10:32 AM, bartc wrote:
 
>> The first my_function() stores the incoming 3rd parameter to the
>> types indicated by max and total.
 
> Max and total are types (which types?) or variables?
 
In the original post they were identified as local variables
within the function:
 
void my_function(int a, int b, to max, total, int c)
{
int i = 5;
int max, total;
}
 
>> two int variables, with the 3rd parameter being automatically
>> copied into both.
 
> So what's the difference here, or isn't there any?
 
One of them declares max and total on the function declaration
line, the other uses the variables declared internally as local
variables.
 
>> source code, or explicit casting (where required).
 
> Sorry, I can't parse that! But if all it does is copy a parameter to
> multiple values, then it is easy enough to do now.
 
It is. But, it requires lines of code to do it, and those can be
scattered about.
 
 
> This assumes you don't need p3 as well (so three copies of the parameter
> are needed). If so then it's what you have in C apart from writing the
> params as 'int a, b, p3, c)'.
 
I don't see that saving as beneficial, and largely for the same
reason I don't see using tabs instead of spaces as beneficial.
If I use tabs, then I can make minor tweaks and adjustments to
my code and it will only occasionally move other things that are
aligned nearby. If I use spaces, I have to make adjustments to
aligned code every time I change the width of anything.
 
Similarly, in your example, if I suddenly wanted to convert one of
the parameters after int a to another type, I'd have to make more
than one change to the line. It also has me scanning left on each
parameter to see how it's defined.
 
With parameter re-directs, you can have an incoming parameter be
an int, and have it auto-redirected/copied into other types, like
a float or larger / smaller / unsigned integer type.
 
The biggest benefit I can see is assigning a pass-thru value to
a return variable (something CAlive allows, but C/C++ do not),
by name, so that the only code that will change that value is
something processed in the function.
 
> original unchanged. But that can be done most easily, AND WITHOUT ADDING
>  A NEW FEATURE, just by writing:
 
>      int total = p3;
 
It has more utility than that. You could assign to a global variable,
for example, which then brings the reference to the global variable as
being tied explicitly to that function's input, for documentation
purposes. It has the ability to assign things before any local function
code is run. In C++ or CAlive, if it was a class that's being copied,
it will call the constructors before-hand, etc.
 
It won't have utility in most programming circumstances, but I can see
some where it will help with code clarity, documentation, and it helps
to re-define the input parameters to a function as something other than
mechanical things. They become logical things, and logical things can
be altered into other things.
 
We'll see how it goes. I appreciate your feedback, Bart.
 
--
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/C, Debi, RDC, CAlive, ES/2, VJr, VFrP, Logician, C90/99
Hardware:
Aroxda Desktop CPU -- 40-bit multi-core 80386 with many extensions
Arxita Embedded CPU -- Low power, low pin count 80386 w/128 registers
Arlina Compute FPGA -- Scalable compute cores, large GPIO pin count
"Öö Tiib" <ootiib@hot.ee>: Oct 02 09:36AM -0700

On Monday, 2 October 2017 16:53:34 UTC+3, David Brown wrote:
> On 02/10/17 14:50, Rick C. Hodgin wrote:
 
> > Does anybody have any thoughts on this feature, positive or negative?
 
> It strikes me as a complicated solution to a non-existent problem.
 
For feature being worth it there should be several motivating examples.
Motivating example is like that:
1) actual code how it is currently.
2) explanation what in that code misleads, is inconvenient and/or is
error prone.
3) equivalent code that uses proposed improvement.
4) explanation of how it is better.
 
All code in this thread seems absurd, unused parameters or parameters
assigned to unused function-local variables. Feels like author of
feature was incapable of imagining motivating examples.
asetofsymbols@gmail.com: Oct 01 11:04PM -0700

How many errors I had done in that code?
David Brown <david.brown@hesbynett.no>: Oct 02 08:30AM +0200

> How many errors I had done in that code?
 
I counted 8 errors, starting with "#define u32" and ending with "#define
ooo".
 
Actually, make that 10 errors - the mention of "malloc" and "free" in
C++ code is another two errors.
 
After that, there is no point continuing.
asetofsymbols@gmail.com: Oct 01 11:41PM -0700

One other error it is i not include <stdlib.h>, it appear C++ compiler and linker know where are malloc / free without warning...
(always if they are right malloc/free)
 
In C that would be ok with a warning missing prototype
David Brown <david.brown@hesbynett.no>: Oct 02 09:35AM +0200

> compiler and linker know where are malloc / free without warning...
> (always if they are right malloc/free)
 
> In C that would be ok with a warning missing prototype
 
No, in C that would /not/ be okay. Implicit function declarations were
removed in C99.
Barry Schwarz <schwarzb@dqel.com>: Oct 02 02:42AM -0700

On Sun, 1 Oct 2017 14:33:58 -0700 (PDT), asetofsymbols@gmail.com
wrote:
 
>I don't know if this is right or even compile, now I see list as this:
 
Then why didn't you try to compile it?
 
 
>#define u32 unsigned
>#define i32 int
>#define S sizeof
 
The use of these types of macros is so annoying to many contributors
that it almost guarantees you will not get a serious discussion about
the "real" code.
 
As for me, I just stop reading when I see these abominations.
 
--
Remove del for email
asetofsymbols@gmail.com: Oct 02 02:59AM -0700

Barry Schwarz wrote
On Sun, 1 Oct 2017 14:33:58 -0700 (PDT), asetof...@gmail.com
wrote:
 
 
>I don't know if this is right or even compile, now I see list as this:
 
 
Then why didn't you try to compile it?
--------
I compiled it 2 times
 
the first with my home made malloc/free/cout input output function library C and C++ (but not all) etc environment (I wrote only a dedicated #include file, one main() that control main() and the command line for compile for using one file library .dll)
 
The second time using the C and C++ library of the compiler... Both no error or warning compile and run as aspect
Jerry Stuckle <jstucklex@attglobal.net>: Oct 02 11:16AM -0400

> How many errors I had done in that code?
 
If a programmer on one of my projects presented this code, it would
immediately be relegated to the bit bucket. I wouldn't even waste time
with a code review of it.
 
Besides the comments on the #define statements, your code is almost
impossible to decipher due to the lack of meaningful variable names and
poor structure, i.e.
 
if(s){ooo<<"\nArgomenti del costruttore non buoni\n"; R;}
else R;
 
This is a little better:
 
{if( (v=(rNode<T>*)MM(S(rNode<T>)))==0 )
{ooo<<"\nErrore memoria non sufficiente\n";
(*this).remove(0);R;
}
 
At least the then clause is in separate lines. But although I've seen
your brace usage before, in my experience it's rather unusual. Most
people I've seen use
 
if (...) {
then clause
}
 
Or
 
if (...)
{
then clause
}
 
Either way is much easier to read than what you are using.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
asetofsymbols@gmail.com: Oct 02 09:02AM -0700

On put statements and operations in a line:
This is my experience:
 
Indentation is one art very good
Align code redundancies is good
Multiple instruction for line can be very good too
 
If operations are correlate
or we are habituated (I don't remember the right word, used) to read/write these operations
As in
for(pa=a.pnd,pb=b.pnd;pa&&pb;pa=pa->next,pb=pb->next)
r+=(pa->nd)*(pb->nd);
one line it is the best indentation
The best layout on the page
 
For example the just above code can not be seen by me better than in that way without spaces without indentation it is as one single operation for me, clear in what it can do.
If someone say the same in plan English it not will be so clear
asetofsymbols@gmail.com: Oct 01 10:33PM -0700

In my opinion obj oriented languages are not complete until it is know one error element for each type.
 
Each operation or function or operator elaborate error element obj return error elements obj
 
For example for T=u8 (unsigned char 8 bit ) it could be FF
T=i8 (signed char 8 bit, it could be 128)
T=double it could be one NaN double
if I have type list<T> than its error
element could be one list of element of type T of one element, and that element is the error element of T.
"Öö Tiib" <ootiib@hot.ee>: Oct 01 11:36PM -0700

> one error element for each type.
 
> Each operation or function or operator elaborate error element obj
> return error elements obj
 
In C++ we usually signal about unrecoverable errors with exceptions.
We may still quite often need "missing" state ("unknown", "unavailable",
"not yet retrieved", "nil") by program logic.
 
> if I have type list<T> than its error
> element could be one list of element of type T of one element, and
> that element is the error element of T.
 
Reserving one of valid states to represent missing state may be
OK but you have to keep track of it yourself manually, language does
not understand it. For safe handling of potentially missing value would
be to use std::optional<T>.
asetofsymbols@gmail.com: Oct 01 11:54PM -0700

Error is not a state of the program
 
It is one set of error objects
 
In practice one operation or function fail and produce one error object I call it e in the time t0
 
Than the set S_t={objects build apply operations on e}
in the time t>=t0 is the set error one can not safe use
 
All the remain sys or objects are ok
Jerry Stuckle <jstucklex@attglobal.net>: Oct 02 11:07AM -0400


> Than the set S_t={objects build apply operations on e}
> in the time t>=t0 is the set error one can not safe use
 
> All the remain sys or objects are ok
 
Incorrect. Error is a program state - for instance attempting to open a
read-only file for output. You can handle the error there, or in C++,
throw an exception to allow the error to be handled in a higher routine.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
asetofsymbols@gmail.com: Oct 02 08:48AM -0700

Open a read only file for writing...
in a obj oriented language
 
fstream j("file name", "w");
 
j object is the error obj for filestream class
because can not open one read only file for write
 
So I would check if open is ok in this way
 
if(j.e) error();
 
if some function use j obj will fail or produce error objects
 
writefile(j, "123") will fail etc
v=readfile(j)
produce error obj for v variable type etc
David Brown <david.brown@hesbynett.no>: Oct 02 09:29AM +0200

> I don't use new() because I have my home made memory allocator
> function that inform me for leaks and write out heap memory in some
> places where it should be not written
 
One of the key features of C++ compared to C is better resource
management with more automation. It does not make sense to use a C
malloc that helps you see where your leaks are, when you could use C++
"new" and avoid the leaks in the first place.
 
C++ lets you use your own allocator with "new", and thus get the best of
both worlds.
Barry Schwarz <schwarzb@dqel.com>: Oct 02 02:44AM -0700

On Sun, 1 Oct 2017 15:02:17 -0700 (PDT), asetofsymbols@gmail.com
wrote:
 
>I don't use new() because I have my home made memory allocator function
 
This I understand.
 
>that inform me for leaks and write out heap memory in some places where it should be not written
 
I am curious how an allocator can report a leaks.
 
I have no idea what the phrase after the "and" is supposed to mean.
 
--
Remove del for email
asetofsymbols@gmail.com: Oct 02 03:09AM -0700

Easy at end of the program is open a window that show if there are leaks the max memory usage from the program, the remain heap, as linked list (if I remember with address) the first address one has to pass to free() function for eliminate the first leak if I remember well or something as this. If the program find one write out the space in the heap, it stop the program and the address to last functon called first the write out the space is found too.
asetofsymbols@gmail.com: Oct 02 03:23AM -0700

Barry Schwarz
 
On Sun, 1 Oct 2017 15:02:17 -0700 (PDT), asetof...@gmail.com
wrote:
 
 
>I don't use new() because I have my home made memory allocator function
 
 
This I understand.
 
 
>that inform me for leaks and write out heap memory in some places where it should be not written
 
 
I am curious how an allocator can report a leaks.
 
I have no idea what the phrase after the "and" is supposed to mean.
----
"and" would mean
if I have a space returned from malloc
it has 2 sentinels one in the start of that space and one in the end
that has no be written from program
 
If the data in one of these 2 sentinel space it is changed
when free has to free that memory
check if the data of the 2 borders sentinel is changed too
If it is changed free() call for end the program
A window is open show (with other things) the address array is written out the space, the value written, the side in the beginning or in the ending, the address last function called etc
David Brown <david.brown@hesbynett.no>: Oct 02 02:23PM +0200

On 02/10/17 12:23, asetofsymbols@gmail.com wrote:
<scrambled mess of quotations>
 
Please - if you want people to help you, then follow Usenet conventions
and quote properly. Posts without context do not help, nor do mixed
quotations from different posts at different times.
 
The best solution is to get a real newsreader and a real newserver,
instead of the disaster that Google provides. But if you have to use
google groups, learn to use it correctly and make the effort to format
your posts correctly.
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)