in history of c there are some syayemants like goto is evil, global variable accesses (some of them i mean more linke non -streamlined writes toi small global variables) are evil, and more

i was already writin on that somewhat but sometimes i just notice some
somewhat new 'take' on things (like seing some previos statements a bit more generally etc) and its maybe worth mentioning

pointers inded i find evil

in c when you got things like that

int a = 3;
int foo() {}
int tab[100];

a,foo,tab are adresses and its fully okay.. each of this thing lays somewhere in ram takes place and has its adress - and this is good thing

if you then make

int& tab_p = tab;

then its something like writing to local variable or abusing gotos,
it is asking yourself for trouble

and thats mostly it, what i want to say at the moment on this ..
people should rather avoid breaking 1-1 correspondence (of adres and ram) - its maybe not such bat do have n-1 correspondence but making those adresses pointers and make them probe to change its containing values making space for 'desynchronisation'

poniedziałek, 20 lutego 2023 o 01:13:05 UTC+1 fir napisał(a):
>
> if you then make
>
> int& tab_p = tab;
>
i menat ofc int* tab_p = tab;

> then its something like writing to local variable or abusing gotos,
> it is asking yourself for trouble
>
> and thats mostly it, what i want to say at the moment on this ..

On Sunday, February 19, 2023 at 7:13:05 PM UTC-5, fir wrote:
> in history of c there are some syayemants like goto is evil,

No, it is the unrestricted use of GOTO is EVIL.

> global variable accesses (some of them i mean more linke non -streamlined writes toi small global variables) are evil, and more
>
> i was already writin on that somewhat but sometimes i just notice some
> somewhat new 'take' on things (like seing some previos statements a bit more generally etc)
> and its maybe worth mentioning
>
> pointers inded i find evil

I suspect you me the unrestricted use of pointers.
>
> in c when you got things like that
>
> int a = 3;
> int foo() {}
> int tab[100];
>
> a,foo,tab are adresses and its fully okay.. each of this thing lays somewhere in ram takes place and has its adress - and this is good thing
>
> if you then make
>
> int& tab_p = tab;
>
> then its something like writing to local variable or abusing gotos,
> it is asking yourself for trouble

No, it isn't.
And I see you corrected the statement later to

int *tab_p = tab;

>
> and thats mostly it, what i want to say at the moment on this ..
> people should rather avoid breaking 1-1 correspondence (of adres and ram)

Dropping pointers means dropping linked lists, trees and other data structures.

> - its maybe not such bat do have n-1 correspondence but making those adresses
> pointers and make them probe to change its containing values making space for 'desynchronisation'

But this is necessary in some cases. C is a language designed for systems level programs.
Writing a device driver may require addressing fixed memory locations (absolute address)
and there are situations where that address may change! This is an extreme but real example.

C programming does place great power in the programmer's hands.

You may want to to review the principles of structured programming.

Any programming language has features that can be abused.
C is no standout in this regard. IOW it is neither worse or better than other languages,
though the obfuscated C contest elevates the abuse to an art form.

Enjoy,
Ed

środa, 22 lutego 2023 o 17:54:44 UTC+1 Ed Prochak napisał(a):
> On Sunday, February 19, 2023 at 7:13:05 PM UTC-5, fir wrote:
> > in history of c there are some syayemants like goto is evil,
> No, it is the unrestricted use of GOTO is EVIL.
> > global variable accesses (some of them i mean more linke non -streamlined writes toi small global variables) are evil, and more
> >
> > i was already writin on that somewhat but sometimes i just notice some
> > somewhat new 'take' on things (like seing some previos statements a bit more generally etc)
> > and its maybe worth mentioning
> >
> > pointers inded i find evil
> I suspect you me the unrestricted use of pointers.
> >
> > in c when you got things like that
> >
> > int a = 3;
> > int foo() {}
> > int tab[100];
> >
> > a,foo,tab are adresses and its fully okay.. each of this thing lays somewhere in ram takes place and has its adress - and this is good thing
> >
> > if you then make
> >
> > int& tab_p = tab;
> >
> > then its something like writing to local variable or abusing gotos,
> > it is asking yourself for trouble
> No, it isn't.
> And I see you corrected the statement later to
>
> int *tab_p = tab;
> >
> > and thats mostly it, what i want to say at the moment on this ..
> > people should rather avoid breaking 1-1 correspondence (of adres and ram)
> Dropping pointers means dropping linked lists, trees and other data structures.
> > - its maybe not such bat do have n-1 correspondence but making those adresses
> > pointers and make them probe to change its containing values making space for 'desynchronisation'
> But this is necessary in some cases. C is a language designed for systems level programs.
> Writing a device driver may require addressing fixed memory locations (absolute address)
> and there are situations where that address may change! This is an extreme but real example.
>
> C programming does place great power in the programmer's hands.
>
> You may want to to review the principles of structured programming.
>
> Any programming language has features that can be abused.
> C is no standout in this regard. IOW it is neither worse or better than other languages,
> though the obfuscated C contest elevates the abuse to an art form.
>

well pointers are evin in some extent and about this it was this post...
its somewhat like with goto or global variables pointers are like goto or global variables

On Wednesday, February 22, 2023 at 12:57:42 PM UTC-5, fir wrote:
> środa, 22 lutego 2023 o 17:54:44 UTC+1 Ed Prochak napisał(a):
> > On Sunday, February 19, 2023 at 7:13:05 PM UTC-5, fir wrote:
> > > in history of c there are some syayemants like goto is evil,
> > No, it is the unrestricted use of GOTO is EVIL.
> > > global variable accesses (some of them i mean more linke non -streamlined writes toi small global variables) are evil, and more
> > >
> > > i was already writin on that somewhat but sometimes i just notice some
> > > somewhat new 'take' on things (like seing some previos statements a bit more generally etc)
> > > and its maybe worth mentioning
> > >
> > > pointers inded i find evil
> > I suspect you me the unrestricted use of pointers.
Ed correction: I suspect you mean the unrestricted use of pointers.
[]
> > > int& tab_p = tab;
> > >
> > > then its something like writing to local variable or abusing gotos,
> > > it is asking yourself for trouble
[]
> > >
> > > and thats mostly it, what i want to say at the moment on this ..
> > > people should rather avoid breaking 1-1 correspondence (of adres and ram)

new comment on this original point:
With current major processors, there is no 1-1 correspondence (of address and ram).
Programs run from execution cache memory and data is read and written to data cache.

[]
> > > - its maybe not such bat do have n-1 correspondence but making those adresses
> > > pointers and make them probe to change its containing values making space for 'desynchronisation'

Now this is a good point but the root cause of memory synchronization problems
is not necessarily pointer variables. I suggest it is related to multi-threading,
different threads of execution in a shared address space. Programmers unaware
of synchronization algorithms and tools my have this issue.

> > But this is necessary in some cases. C is a language designed for systems level programs.
> > Writing a device driver may require addressing fixed memory locations (absolute address)
> > and there are situations where that address may change! This is an extreme but real example.
> >
> > C programming does place great power in the programmer's hands.
> >
> > You may want to to review the principles of structured programming.
> >
> > Any programming language has features that can be abused.
> > C is no standout in this regard. IOW it is neither worse or better than other languages,
> > though the obfuscated C contest elevates the abuse to an art form.
> >
> well pointers are evin in some extent and about this it was this post...
> its somewhat like with goto or global variables pointers are like goto or global variables

Again I suggest you review the principles of structured programming.
Or consider the saying: A bad workman that blames his tools.

Pointers, GOTO statements, and global variables are tools in the C language toolbox.

If you think those tools are dangerous, go use another language.
Try PERL 8^) or maybe APL!
Or are you a JAVA programmer trying to get attention?

Enjoy,
Ed

On 2/22/23 23:37, Ed Prochak wrote:
....
> Or consider the saying: A bad workman that blames his tools.

I hate that saying, or more accurately, it's misuse to justify ignoring
all complaints about badly designed tools. Good workmen also blame their
tools, if they are in fact blameworthy - or do you claim that tools are
never worthy of blame?

On 2/22/23 11:54, Ed Prochak wrote:
....
> Dropping pointers means dropping linked lists, trees and other data structures.

No, it doesn't. Each of those structures can be implemented by saving
indices into arrays, rather than pointers. Instead of *next_ptr, you end
up writing node_list[next_idx]. I've experience with that kind of thing
in old Fortran programs. Pointers are a [great!] convenience, not a
necessity.

On 2023-02-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 2/22/23 11:54, Ed Prochak wrote:
> ...
>> Dropping pointers means dropping linked lists, trees and other data structures.
>
> No, it doesn't. Each of those structures can be implemented by saving
> indices into arrays, rather than pointers.

Not only that, but also using aggregate values that have reference
semantics. These are kind of pointers, but they can be managed (e.g.
garbage collection) and prevented from misuse (no casting to another
type, or arithmetic).

> Instead of *next_ptr, you end
> up writing node_list[next_idx]. I've experience with that kind of thing
> in old Fortran programs. Pointers are a [great!] convenience, not a
> necessity.

I wrote a balanced binary search tree that way in John E. Davis's S-lang,
back around 1996. A team at Nortel had integrated S-lang into production
use, and in that project I had to solve a problem that needed the S-lang
code to have halfway efficient dictionary structure.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 23/02/2023 05:51, James Kuyper wrote:
> On 2/22/23 11:54, Ed Prochak wrote:
> ...
>> Dropping pointers means dropping linked lists, trees and other data structures.
>
> No, it doesn't. Each of those structures can be implemented by saving
> indices into arrays, rather than pointers. Instead of *next_ptr, you end
> up writing node_list[next_idx]. I've experience with that kind of thing
> in old Fortran programs. Pointers are a [great!] convenience, not a
> necessity.
>

Such indices are pointers too, in a more general sense. In C, the term
"pointer" almost always refers to a simple "memory address" pointer.
But in other contexts, including C++, "pointer" can be refer to other
types of indirect references (including "smart pointers").

But it is also possible to implement data structures without any
explicit pointers or pointer equivalent, where the details are hidden by
the language. You don't see pointers at all in Python or Haskell, but
can quite happily have lists, trees, and other structures.

Ed Prochak <edprochak@gmail.com> writes:
>On Wednesday, February 22, 2023 at 12:57:42 PM UTC-5, fir wrote:

>> > > and thats mostly it, what i want to say at the moment on this ..=20
>> > > people should rather avoid breaking 1-1 correspondence (of adres and =
>ram)=20
>
>new comment on this original point:
>With current major processors, there is no 1-1 correspondence (of address a=
>nd ram).
>Programs run from execution cache memory and data is read and written to da=
>ta cache.

That's not a particularly accurate or useful description of how the
memory subsystem works on a modern processor. Caches use the same
physical addresses as RAM (leaving aside the rare virtually indexed
cache, which even then is still physically tagged) and aside from
some transient data, cached data will flushed to RAM as necessary.

All modern processors allow the caches to be disabled for some or
all of the physical address space (MTRR, MAIR, etc).

Aside from bare-metal code, C program pointers are virtual
addresses anyway.

On 2/23/23 03:37, David Brown wrote:
> On 23/02/2023 05:51, James Kuyper wrote:
>> On 2/22/23 11:54, Ed Prochak wrote:
>> ...
>>> Dropping pointers means dropping linked lists, trees and other data
>>> structures.
>>
>> No, it doesn't. Each of those structures can be implemented by saving
>> indices into arrays, rather than pointers. Instead of *next_ptr, you end
>> up writing node_list[next_idx]. I've experience with that kind of thing
>> in old Fortran programs. Pointers are a [great!] convenience, not a
>> necessity.
>>
>
> Such indices are pointers too, in a more general sense. In C, the term
> "pointer" almost always refers to a simple "memory address" pointer.
> But in other contexts, including C++, "pointer" can be refer to other
> types of indirect references (including "smart pointers").

Perhaps, but they don't need to have the features that make pointers
dangerous. I've used languages where accessing an array outside of it's
range had well-defined behavior (in some of them, array[i] refers to the
first element of the array if i is too small, and it refers to the last
element of the array if i is too big - and I've even seen a program
targeting one such implementation that relied upon that feature to
simplify the logic),

On 2/23/23 14:26, Mr Flibble wrote:
> On Thu, 23 Feb 2023 11:13:23 -0500, James Kuyper wrote:
....
>> Perhaps, but they don't need to have the features that make pointers
>> dangerous. I've used languages where accessing an array outside of it's
>> range had well-defined behavior (in some of them, array[i] refers to the
>> first element of the array if i is too small, and it refers to the last
>> element of the array if i is too big - and I've even seen a program
>> targeting one such implementation that relied upon that feature to
>> simplify the logic),
>
> Bullshit.
>
> /Flibble

Are you denying the existence of such languages? IDL is one of them. I
can't remember the others - they must be ones I didn't make much use of,
I just remember this one way in which they were significantly different
from any other language I've ever learned.

czwartek, 23 lutego 2023 o 05:51:21 UTC+1 James Kuyper napisał(a):
> On 2/22/23 23:37, Ed Prochak wrote:
> ...
> > Or consider the saying: A bad workman that blames his tools.
> I hate that saying, or more accurately, it's misuse to justify ignoring
> all complaints about badly designed tools. Good workmen also blame their
> tools, if they are in fact blameworthy - or do you claim that tools are
> never worthy of blame?

i dont blame tools.. what i say is rather that there are many people who sees a thing in c like pointer and they could have idea to use a lot of it...what i say that even aberage use of pointers is imo bad they should be sorta minimalised imo (roughly speaking, becous there is a neeed to judge it in cases)..also the overal reutation of pointers in c (as a language syub) is too high imo

On Wednesday, February 22, 2023 at 11:51:21 PM UTC-5, James Kuyper wrote:
> On 2/22/23 23:37, Ed Prochak wrote:
> ...
> > Or consider the saying: A bad workman that blames his tools.
> I hate that saying, or more accurately, it's misuse to justify ignoring
> all complaints about badly designed tools. Good workmen also blame their
> tools, if they are in fact blameworthy - or do you claim that tools are
> never worthy of blame?

I have complained many times about bad tools over the span of my career.

In this context, decent software engineering workmen have correctly built
an enormous amount of correctly functioning software using C with its
"evil" pointers. And especially the amount of embedded and operating system
software for which the C language was designed demonstrates the usefulness
of this tool. So, it seems clear that C is a tool appropriate for the tasks for which
it was designed.

To continue the analogy, C is a power tool, and there have also been many less skilled
software engineers that have used it improperly and had poor results as a consequence.

I did not bring up that saying as a cheap shot or to call out anyone as a poor workman.
I was trying to jog fir out of the very limiting views that pointers, GOTO statements, and
global variables are inherently and always "evil".
Ed

On Wednesday, February 22, 2023 at 11:52:11 PM UTC-5, James Kuyper wrote:
> On 2/22/23 11:54, Ed Prochak wrote:
> ...
> > Dropping pointers means dropping linked lists, trees and other data structures.
> No, it doesn't. Each of those structures can be implemented by saving
> indices into arrays, rather than pointers. Instead of *next_ptr, you end
> up writing node_list[next_idx]. I've experience with that kind of thing
> in old Fortran programs. Pointers are a [great!] convenience, not a
> necessity.

You are correct I did overstate the case.
But your solution merely replaced absolute addresses with relative ones.

If you want to program in FORTRAN, go ahead. (I did it for some years early
in my career.)

Try programming hardware device drivers, operating system, or just the
basic memory management needed to allocate your arrays without pointers.

Ed

On Thursday, February 23, 2023 at 11:09:06 AM UTC-5, Scott Lurndal wrote:
> Ed Prochak <edpr...@gmail.com> writes:
> >On Wednesday, February 22, 2023 at 12:57:42 PM UTC-5, fir wrote:
> >> > > and thats mostly it, what i want to say at the moment on this ..=20
> >> > > people should rather avoid breaking 1-1 correspondence (of adres and =
> >ram)=20
> >
> >new comment on this original point:
> >With current major processors, there is no 1-1 correspondence (of address a=
> >nd ram).
> >Programs run from execution cache memory and data is read and written to da=
> >ta cache.
>
> That's not a particularly accurate or useful description of how the
> memory subsystem works on a modern processor. Caches use the same
> physical addresses as RAM (leaving aside the rare virtually indexed
> cache, which even then is still physically tagged) and aside from
> some transient data, cached data will flushed to RAM as necessary.
>
> All modern processors allow the caches to be disabled for some or
> all of the physical address space (MTRR, MAIR, etc).
>
> Aside from bare-metal code, C program pointers are virtual
> addresses anyway.

Quite true.

But I thought the original complaint implied the old (ancient in internet time :^)
more direct modes of addressing without cache support hardware. I often think
of these discussions in an embedded software environment where I sometimes
need to point to a real hardware physical address.

Ed

On Friday, February 24, 2023 at 7:58:31 PM UTC-5, fir wrote:
> czwartek, 23 lutego 2023 o 05:51:21 UTC+1 James Kuyper napisał(a):
> > On 2/22/23 23:37, Ed Prochak wrote:
> > ...
> > > Or consider the saying: A bad workman that blames his tools.
> > I hate that saying, or more accurately, it's misuse to justify ignoring
> > all complaints about badly designed tools. Good workmen also blame their
> > tools, if they are in fact blameworthy - or do you claim that tools are
> > never worthy of blame?
> i dont blame tools.. what i say is rather that there are many people
> who sees a thing in c like pointer and they could have idea to use a lot of it.
> ..what i say that even aberage use of pointers is imo bad they should be sorta
> minimalised imo (roughly speaking, becous there is a neeed to judge it in cases)
> ..also the overal reutation of pointers in c (as a language syub) is too high imo

You are entitled to your opinion. You have a choice in what language to use to avoid
the "evil" you see in C programming. Go ahead any use JAVA.

But you have not made a strong case for eliminating pointers, GOTOs, or global variables
in the C programming language

Just because you have seen a feature abused is not justification to remove it from the language.
I have seen pointers abused in C. I have also seen other features of C abused. For example,
I've had to deal with an extended compound conditional expression in a while loop, specifically
a while() statement that was 7 lines long!

A better solution IMHO is conducting code reviews. More experienced senior engineers can
tell when an apparent abuse of a pointer might just be a clever optimization requiring just
a detailed explanation in the comments. Or when a seemingly simple use of a pointer might
truly be an abuse of the feature.

Ed

poniedziałek, 27 lutego 2023 o 05:34:07 UTC+1 Ed Prochak napisał(a):
> On Friday, February 24, 2023 at 7:58:31 PM UTC-5, fir wrote:
> > czwartek, 23 lutego 2023 o 05:51:21 UTC+1 James Kuyper napisał(a):
> > > On 2/22/23 23:37, Ed Prochak wrote:
> > > ...
> > > > Or consider the saying: A bad workman that blames his tools.
> > > I hate that saying, or more accurately, it's misuse to justify ignoring
> > > all complaints about badly designed tools. Good workmen also blame their
> > > tools, if they are in fact blameworthy - or do you claim that tools are
> > > never worthy of blame?
> > i dont blame tools.. what i say is rather that there are many people
> > who sees a thing in c like pointer and they could have idea to use a lot of it.
> > ..what i say that even aberage use of pointers is imo bad they should be sorta
> > minimalised imo (roughly speaking, becous there is a neeed to judge it in cases)
> > ..also the overal reutation of pointers in c (as a language syub) is too high imo
> You are entitled to your opinion. You have a choice in what language to use to avoid
> the "evil" you see in C programming. Go ahead any use JAVA.
>
> But you have not made a strong case for eliminating pointers, GOTOs, or global variables
> in the C programming language
>
> Just because you have seen a feature abused is not justification to remove it from the language.
> I have seen pointers abused in C. I have also seen other features of C abused. For example,
> I've had to deal with an extended compound conditional expression in a while loop, specifically
> a while() statement that was 7 lines long!
>
> A better solution IMHO is conducting code reviews. More experienced senior engineers can
> tell when an apparent abuse of a pointer might just be a clever optimization requiring just
> a detailed explanation in the comments. Or when a seemingly simple use of a pointer might
> truly be an abuse of the feature.
>
> Ed

well i dint see pointers abused (mostly becouse i very rarely read others people code, also i guess its hard to abuse pointers)

what i say is something other, its not quiote on usage of pointers by people but understanding its nature (and how it should be treated)

what i say that adresses are ok but pointers not quite

maybe some example for example allocating memory by mallooc
creates pointer and this is bad becouse pointer is evil, it would be better to create not a pointer but a name containing adress

wtorek, 28 lutego 2023 o 04:12:08 UTC+1 fir napisał(a):
> poniedziałek, 27 lutego 2023 o 05:34:07 UTC+1 Ed Prochak napisał(a):
> > On Friday, February 24, 2023 at 7:58:31 PM UTC-5, fir wrote:
> > > czwartek, 23 lutego 2023 o 05:51:21 UTC+1 James Kuyper napisał(a):
> > > > On 2/22/23 23:37, Ed Prochak wrote:
> > > > ...
> > > > > Or consider the saying: A bad workman that blames his tools.
> > > > I hate that saying, or more accurately, it's misuse to justify ignoring
> > > > all complaints about badly designed tools. Good workmen also blame their
> > > > tools, if they are in fact blameworthy - or do you claim that tools are
> > > > never worthy of blame?
> > > i dont blame tools.. what i say is rather that there are many people
> > > who sees a thing in c like pointer and they could have idea to use a lot of it.
> > > ..what i say that even aberage use of pointers is imo bad they should be sorta
> > > minimalised imo (roughly speaking, becous there is a neeed to judge it in cases)
> > > ..also the overal reutation of pointers in c (as a language syub) is too high imo
> > You are entitled to your opinion. You have a choice in what language to use to avoid
> > the "evil" you see in C programming. Go ahead any use JAVA.
> >
> > But you have not made a strong case for eliminating pointers, GOTOs, or global variables
> > in the C programming language
> >
> > Just because you have seen a feature abused is not justification to remove it from the language.
> > I have seen pointers abused in C. I have also seen other features of C abused. For example,
> > I've had to deal with an extended compound conditional expression in a while loop, specifically
> > a while() statement that was 7 lines long!
> >
> > A better solution IMHO is conducting code reviews. More experienced senior engineers can
> > tell when an apparent abuse of a pointer might just be a clever optimization requiring just
> > a detailed explanation in the comments. Or when a seemingly simple use of a pointer might
> > truly be an abuse of the feature.
> >
> > Ed
> well i dint see pointers abused (mostly becouse i very rarely read others people code, also i guess its hard to abuse pointers)
>
> what i say is something other, its not quiote on usage of pointers by people but understanding its nature (and how it should be treated)
>
> what i say that adresses are ok but pointers not quite
>
> maybe some example for example allocating memory by mallooc
> creates pointer and this is bad becouse pointer is evil, it would be better to create not a pointer but a name containing adress

so what iu was saying is more like highly theoretical, but has some practocal outcome in understanding/treating the languege

as to what i say here

int* buf = malloc(1000);

is evil becouse pointer is evil as i said
by coincidence you dont need buff to be a pointer you need it to be
an label (adress + name pair)

you dont need to change the pointer value etc

sou you would rather need

int buf[] = malloc(1000);

and here buf is not a pointer, note, it shouldnt be

wtorek, 28 lutego 2023 o 04:19:23 UTC+1 fir napisał(a):
> wtorek, 28 lutego 2023 o 04:12:08 UTC+1 fir napisał(a):
> > poniedziałek, 27 lutego 2023 o 05:34:07 UTC+1 Ed Prochak napisał(a):
> > > On Friday, February 24, 2023 at 7:58:31 PM UTC-5, fir wrote:
> > > > czwartek, 23 lutego 2023 o 05:51:21 UTC+1 James Kuyper napisał(a):
> > > > > On 2/22/23 23:37, Ed Prochak wrote:
> > > > > ...
> > > > > > Or consider the saying: A bad workman that blames his tools.
> > > > > I hate that saying, or more accurately, it's misuse to justify ignoring
> > > > > all complaints about badly designed tools. Good workmen also blame their
> > > > > tools, if they are in fact blameworthy - or do you claim that tools are
> > > > > never worthy of blame?
> > > > i dont blame tools.. what i say is rather that there are many people
> > > > who sees a thing in c like pointer and they could have idea to use a lot of it.
> > > > ..what i say that even aberage use of pointers is imo bad they should be sorta
> > > > minimalised imo (roughly speaking, becous there is a neeed to judge it in cases)
> > > > ..also the overal reutation of pointers in c (as a language syub) is too high imo
> > > You are entitled to your opinion. You have a choice in what language to use to avoid
> > > the "evil" you see in C programming. Go ahead any use JAVA.
> > >
> > > But you have not made a strong case for eliminating pointers, GOTOs, or global variables
> > > in the C programming language
> > >
> > > Just because you have seen a feature abused is not justification to remove it from the language.
> > > I have seen pointers abused in C. I have also seen other features of C abused. For example,
> > > I've had to deal with an extended compound conditional expression in a while loop, specifically
> > > a while() statement that was 7 lines long!
> > >
> > > A better solution IMHO is conducting code reviews. More experienced senior engineers can
> > > tell when an apparent abuse of a pointer might just be a clever optimization requiring just
> > > a detailed explanation in the comments. Or when a seemingly simple use of a pointer might
> > > truly be an abuse of the feature.
> > >
> > > Ed
> > well i dint see pointers abused (mostly becouse i very rarely read others people code, also i guess its hard to abuse pointers)
> >
> > what i say is something other, its not quiote on usage of pointers by people but understanding its nature (and how it should be treated)
> >
> > what i say that adresses are ok but pointers not quite
> >
> > maybe some example for example allocating memory by mallooc
> > creates pointer and this is bad becouse pointer is evil, it would be better to create not a pointer but a name containing adress
> so what iu was saying is more like highly theoretical, but has some practocal outcome in understanding/treating the languege
>
> as to what i say here
>
> int* buf = malloc(1000);
>
> is evil becouse pointer is evil as i said
> by coincidence you dont need buff to be a pointer you need it to be
> an label (adress + name pair)
>
> you dont need to change the pointer value etc
>
> sou you would rather need
>
> int buf[] = malloc(1000);
>
> and here buf is not a pointer, note, it shouldnt be

c also abuses that not only in mallock but in function
arguments

int print2(char* txt)
{ //you dont need here a pointer txt placet in its ram, to be able to change it etc, you only need and adress to read freoim it or eventually write under itt
}

in c nomenclature as i said i would rather write it
int print2(char txt[])
{ }

here txt is adres not a pointer (in my provate nomenclature
here txt is two adresses)

some also my see it as c++ reference
int print2(char& txt)
{ }

though i dilike c++ and there is no need to name it as reference
but notatiuon is ok in showing difference between char& (which is adress) and chat* wgich is pointer that is logical abuse

Am 20.02.2023 um 01:12 schrieb fir:
> in history of c there are some syayemants like goto is evil, global variable accesses (some of them i mean more linke non -streamlined writes toi small global variables) are evil, and more
>
> i was already writin on that somewhat but sometimes i just notice some
> somewhat new 'take' on things (like seing some previos statements a bit more generally etc) and its maybe worth mentioning
>
> pointers inded i find evil
>
> in c when you got things like that
>
> int a = 3;
> int foo() {}
> int tab[100];
>
> a,foo,tab are adresses and its fully okay.. each of this thing lays somewhere in ram takes place and has its adress - and this is good thing
>
> if you then make
>
> int& tab_p = tab;
>
> then its something like writing to local variable or abusing gotos,
> it is asking yourself for trouble
>
> and thats mostly it, what i want to say at the moment on this ..
> people should rather avoid breaking 1-1 correspondence (of adres and ram) - its maybe not such bat do have n-1 correspondence but making those adresses pointers and make them probe to change its containing values making space for 'desynchronisation'

Use a different language if you like.

fir,

I'm not ignoring you, just busy.

Ed

On Tuesday, February 28, 2023 at 8:21:45 PM UTC-5, fir wrote:
> wtorek, 28 lutego 2023 o 04:19:23 UTC+1 fir napisał(a):
> > wtorek, 28 lutego 2023 o 04:12:08 UTC+1 fir napisał(a):
> > > poniedziałek, 27 lutego 2023 o 05:34:07 UTC+1 Ed Prochak napisał(a):
[]
> > > > A better solution IMHO is conducting code reviews. More experienced senior engineers can
> > > > tell when an apparent abuse of a pointer might just be a clever optimization requiring just
> > > > a detailed explanation in the comments. Or when a seemingly simple use of a pointer might
> > > > truly be an abuse of the feature.
> > > >
> > > > Ed
> > > well i dint see pointers abused (mostly becouse i very rarely read others people code,

Well, perhaps you should read some others code. It is a good way to learn many things
like
coding styles (indentation, placement of braces, variable and function naming),
cases where pointers make much cleaner and more maintainable code (linked lists, trees)
proper use of functions from standard and optional libraries,
efficient algorithms and application of standard algorithms,
reliable code techniques (error checking and recovery)
Multitasking and multi-threading
and other programming skills.

I'm a little curious. Are you programming for your work or for yourself?
What kinds of software do you write?
User applications? Business applications? Scientific processing?
Communications? Operating systems or libraries? Embedded systems?

> > > also i guess its hard to abuse pointers)

Wait. you say pointers are evil, but hard to abuse? confusing.
I think you meant something else here.

> > >
> > > what i say is something other, its not quiote on usage of pointers by people
> > > but understanding its nature (and how it should be treated)

Exactly. It does take some time to really understand when a pointer is the best tool.
Ways to improve your understanding include
reading code produced by more senior software developers at work,
reading books on the C language and programming in general,
learning other languages and when they are better for the task at hand.

> > >
> > > what i say that adresses are ok but pointers not quite
> > >
> > > maybe some example for example allocating memory by mallooc
> > > creates pointer and this is bad becouse pointer is evil, it would be better to create not a pointer but a name containing adress
> > so what iu was saying is more like highly theoretical, but has some practocal outcome in understanding/treating the languege
> >
> > as to what i say here
> >
> > int* buf = malloc(1000);
> >
> > is evil becouse pointer is evil as i said

"i said" presents your opinion. you have yet to show any evidence of why you think it is "evil"

> > by coincidence you dont need buff to be a pointer you need it to be
> > an label (adress + name pair)
You are starting to define the syntax for another language here.
This is still just your opinion.
> >
> > you dont need to change the pointer value etc

WHAT?! How do you know what my programming needs are?

> >
> > sou you would rather need
> >
> > int buf[] = malloc(1000);
> >
> > and here buf is not a pointer, note, it shouldnt be

And here, you should note that
int buf[] = malloc(1000);
is invalid. Essentially this confirms that you are asking to a change in the C language.

> c also abuses that not only in mallock

C programmers may abuse malloc() and pointers, but the language C cannot.
(This may be a problem of language. I see you are Polski. I have Polish ancestors.)

> but in function
> arguments
>
> int print2(char* txt)
> {
> //you dont need here a pointer txt placet in its ram, to be able to change it etc,
> // you only need and adress to read freoim it or eventually write under itt
> }
You claim this is an abuse of pointers, but this is standard C syntax and style.
All C programmers should be comfortable with this.

The abuse, if any, of the pointer txt would happen in the body of the function.
You did not show that abuse.

>
> in c nomenclature as i said i would rather write it
> int print2(char txt[])
> {
> }
>
> here txt is adres not a pointer (in my provate nomenclature
> here txt is two adresses)

Again you are merely repeating a proposed change to the C language.

>
> some also my see it as c++ reference
> int print2(char& txt)
> {
> }
>
> though i dilike c++ and there is no need to name it as reference
> but notatiuon is ok in showing difference between char& (which is adress) and chat* wgich is pointer that is logical abuse

If you want, then program in C++. The C language exists for a different purpose and
includes the pointer features for very valid reasons.

And in the full context of programming, you still have
not given a reason why you think pointers are "evil".

Have a good day,
Ed

Ed Prochak:

> cases where pointers make much cleaner and more
> maintainable code (linked lists, trees)

The simplest approach to such lists or trees involves
allocating each element with a separate malloc() call. Does
it provide sufficient performance is the majority of
production code?

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 3/9/2023 3:07 AM, Anton Shepelev wrote:
> Ed Prochak:
>
>> cases where pointers make much cleaner and more
>> maintainable code (linked lists, trees)
>
> The simplest approach to such lists or trees involves
> allocating each element with a separate malloc() call. Does
> it provide sufficient performance is the majority of
> production code?
>

The memory leak errors made possible by pointers can be easily
eliminated by compiling the code as C++ and using the standard template
library for all memory allocation.

--
Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer