From Newsgroup: comp.lang.c

in separate theread i noticed that references are same as pointers but
with swapped syntax and changed symbol

NORMAL

int*x;
x //pointer value
*x //value

SWAPPED SYNTAX: (fictional)
int* x;
*x //pointer value
x ; //value


i talk about this reversed syntax becouse this
syntax has more sense becouse you more often acces value than
use pointer value


REFERENCE:

int& x;
&x; //pointer value (kinda)(there is subtle difference as in
reversed pointer syntax you would be able to change it)
x; //value


SO IN SHORT

if you swap syntax of pointers on more sane where xis value and *x is
aeress (not like today *x is value and x is adress) you will get the c++ reference except that in c++ afaik (i not used it really in my life as
i distaste c++) you cannot change it


IN FACT there are two options

if you have this reversed pointer as a language mechanism

int& x;

you could decide to allow (&x)++ or disallow it


1) if you ALLOW it you can do as far as it seems do all pointer mechanics/codes on this

2) if you DISALLOW this you probably help the compiler to cover
cases when in real life MANY POINTERS are NOT REAT POINTERS becouse
if you only use it to read or write alues but not change pointer
values itself there in fact are not real pointers - and
use pointers to it is kinda FLAW

SUMMARY in short

1) c++ references are surprisingly a good idea (unlike to c++)
2) many pointers in C are not real and write code with pointers tonot
real pointers is a flaw
3) decision if to allow (&x)++ on references at the moment i cant take
- teh fact is you need both , you need real pointers and you need those
not real pointers (some could ask if pointer is not real why to need it anyway- ths is probably as with const the pointer is not real locally
like const is constant locally but cant be reassigned previousl (though
thus this name is not proper in respect to real consts)
in c many pointers seem to be not real

SO you need 2 syntaxex for real and not real pointers (references) or
you could use something like int& for both allowing compiler to find
where you do not change the pointer value at all

PROBABLY better is to have those 2 separate syntaxex to explicitely note
this is real pointer or not real pointer BUT as its almost the same the
syntax could be more close one to another

like i dont know

real int& x; //you can (&x)++
int& x; //you cant change &x

i think my thoughts are sorta conclusive, so it shows in fact pointers
in c are flawed (though there are sorta nice showing hov low lewel
programming is and all things are adresses etc - FLAW is that many
pointers in c are not real so its kinda mistypisation like you would
write float when you use them for ints (write float for floats int for
ints) SECOND FLAW is that they have reversed syntax (you need more
common to use value then pointer vvalue so more handy is to hae x for
value *x or &x for pointer alue

maybe it showed for c creators that *x is explicite show that x is a
pointer not static compile time number, but i doubt if this is needed or valuable (im not sure but it is at least doubtfull - in some previous commentary i said to bartc that given identifier in c says what it is ,
pure x xan be function can be float can be structure of strctures - so generally you need to know what pure identifier is, same way you would
need to know if its a pointer or static adress same way not to carry *x
to show it in every place usage like yoy would write struct x or int x
or function x in every usage place int x= iny y + int z; its not how its
goin in c








--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

yet practical conclusion : maybe to start using this a bit (?) for ma s
c programmer but having c++ compiler and at least to see how it looks
like and if it has no some flaws prcatically

fact is if someone is avare of two flaws of pointers i noted
(mainly many pointers in c are not real and that thos *x *x *x *x *x
codes are non proper) then it could be annoying to see that flaws and
mabe it would be natural to not use it

esp as i checked and this c++ work as it should i mean it can be
counted in runtime as a non real pointer and only then not changed
as it shouldnt

char text[] = "zzbazzcf";
char& ch = text[3];
ch = 'X';

char&ch is cooputed in runtime
if ch is not real pointer than writing

char* ch = &text[3];
*ch = 'X';

is a flaw as uts hole in typesystem
(more to say probbaly its proper to use const references in many places
though im not sure if thsi onst place is not flawed

as for example

int const& const y could mean use int& reference that is not chengable
(this is not pointer) to const y (so it is read only)
so it means

not real int* read olny y

this const word is obviously wrong as im real const as i said
should be probably program life consts

so here above more proper words would be

"not changeble* to read only int" y


in c++ chat gpt says

foo(const int& x) means its not changable reference to readonly x

where

foo(int& const x) whoch would be moreproper imo not compiles

this is also not proper imo
foo(const int& x)

becouse if say references as pointers would have its types/sizes like
int char long (which is sorta fact on assembly level afaik)

then int& would mean pointer of int size

so it should be more

& int x //reference to int named x

const& int //const reference to x

const& read int //const reference to read x

in c++ all references are const so

&read int //would be proper imo

(yawn)






)




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

const int* p;
int const* p;

is afaik the same and its messed

imo those wordls should adhere to things right to them so
logically

*int p //pointer to int p

const* int p //coinst pointer to int


const* const int p// const pointer to const int


const char* const int x //constt char-size pointer to const int


long const* const int x //long size const pointer to const int


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

const int* p;
int const* p;

is afaik the same and its messed

imo those wordls should adhere to things right to them so
logically

*int p //pointer to int p

const* int p //coinst pointer to int

const* const int p// const pointer to const int

const char* const int x //constt char-size pointer to const int

long const* const int x //long size const pointer to const int

note for moral uses it would be

*int //pointer/reference to int LETS SAY name a constant pointers a
references maybe for sipmplicity, this here if its pointer or reference depends if it is by defaulf const or not so if it is by default
reference or pointer)


const* int // reference to int


*const int //pointer or reference to read int

const*const int //reference to read int

(as i said thos word const ale flaw but for illustration)


im not sure if pointer or reference should be default, also some may use
two signs

*int p //pointer

&int p // reference (const pointer)

THIUGH probably maybe its better tu use one




--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

const int* p;
int const* p;

is afaik the same and its messed

imo those wordls should adhere to things right to them so
logically

*int p //pointer to int p

const* int p //coinst pointer to int


const* const int p// const pointer to const int


const char* const int x //constt char-size pointer to const int


long const* const int x //long size const pointer to const int

note for moral uses it would be

*int //pointer/reference to int LETS SAY name a constant pointers a references maybe for sipmplicity, this here if its pointer or reference depends if it is by defaulf const or not so if it is by default
reference or pointer)

const* int // reference to int

*const int //pointer or reference to read int

const*const int //reference to read int

(as i said thos word const ale flaw but for illustration)

im not sure if pointer or reference should be default, also some may use
two signs

*int p //pointer

&int p // reference (const pointer)

THIUGH probably maybe its better tu use one

note as opinter and reference has different names maybe int and const
int also could have different names like int and rint ;/ (rint would men
read only int)

also logically (technically) there is an option of wint (write only int,
not for read)

cn someone in c typedef const int on rint? (checked it says its possible)

im nota big fan of const though in practice but in some places it
probably has some sense


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

On 20/05/2026 04:13, fir wrote:

in separate theread i noticed that references are same as pointers but
with swapped syntax and changed symbol

NORMAL

int*x;
  x //pointer value
 *x //value

SWAPPED SYNTAX: (fictional)
int* x;
  *x //pointer value
   x ; //value

i talk about this reversed syntax  becouse this
syntax has more sense becouse you more often acces value than
use pointer value

REFERENCE:

  int& x;
    &x; //pointer value (kinda)(there is subtle difference as in reversed pointer syntax you would be able to change it)
     x; //value

SO IN SHORT

if you swap syntax of pointers on more sane where xis value and *x is
aeress (not like today *x is value and x is adress) you will get the c++ reference  except that in c++ afaik (i not used it really in my life as
i distaste c++) you cannot change it

This is where a HLL varies from Assembly; take this variable A (in C,
'int A;'):

A: dd 0

mov rax, A # A by itself is its address
mov eax, [A] # Use [A] to dereference get its value

If that was the same in a HLL, then you'd write this:

int a, b, c;

a; // address of a (&a now)
*a; // value of a
*a = *b + *c;

That would be inconvenient however, so most HLLs will automatically dereference variables names so that you get the value. You need &a to
get their address (some languages can figure out what you're trying to do).


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

Bart pisze:

On 20/05/2026 04:13, fir wrote:

in separate theread i noticed that references are same as pointers but
with swapped syntax and changed symbol

NORMAL

int*x;
   x //pointer value
  *x //value

SWAPPED SYNTAX: (fictional)
int* x;
   *x //pointer value
    x ; //value


i talk about this reversed syntax  becouse this
syntax has more sense becouse you more often acces value than
use pointer value


REFERENCE:

   int& x;
     &x; //pointer value (kinda)(there is subtle difference as in
reversed pointer syntax you would be able to change it)
      x; //value


SO IN SHORT

if you swap syntax of pointers on more sane where xis value and *x is
aeress (not like today *x is value and x is adress) you will get the
c++ reference  except that in c++ afaik (i not used it really in my
life as
i distaste c++) you cannot change it

This is where a HLL varies from Assembly; take this variable A (in C,
'int A;'):

    A: dd 0

    mov rax, A           # A by itself is its address
    mov eax, [A]         # Use [A] to dereference get its value

If that was the same in a HLL, then you'd write this:

    int a, b, c;

    a;                   // address of a (&a now)
    *a;                  // value of a
    *a = *b + *c;

That would be inconvenient however, so most HLLs will automatically dereference variables names so that you get the value. You need &a to
get their address (some languages can figure out what you're trying to do).

you mean this *a is to remember this dereference like

[0x9879879] -> 0x33373873

its kinda nonsense in practice imo as it you use few *a *a *a *a
but you not change a in a row the first time only compiler dereferences [0x9879879] then it uses 0x33373873 if it is sane compiler not
[0x9879879] every time so this *a is not illustrating but is misleading

in fact if a is reference to rint not to int (rint i mean this typedef
conts int rint;) then when you writa a it could in fact not to use
0x33373873 but immediate value, say 3

so here are 3 levels

int* - [0x09879879]
int/int& - 0x33373873
rint/rint& - 3

it imo says you should use int/int& instead of int* when appropriate and rint/rint& instead of int/int& when appropriate

(though it would need to be tested in practice

i only now concluded that int& are better and rints are better, never
used it massively









--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

Bart pisze:

On 20/05/2026 04:13, fir wrote:

in separate theread i noticed that references are same as pointers
but with swapped syntax and changed symbol

NORMAL

int*x;
   x //pointer value
  *x //value

SWAPPED SYNTAX: (fictional)
int* x;
   *x //pointer value
    x ; //value


i talk about this reversed syntax  becouse this
syntax has more sense becouse you more often acces value than
use pointer value


REFERENCE:

   int& x;
     &x; //pointer value (kinda)(there is subtle difference as in
reversed pointer syntax you would be able to change it)
      x; //value


SO IN SHORT

if you swap syntax of pointers on more sane where xis value and *x is
aeress (not like today *x is value and x is adress) you will get the
c++ reference  except that in c++ afaik (i not used it really in my
life as
i distaste c++) you cannot change it

This is where a HLL varies from Assembly; take this variable A (in C,
'int A;'):

     A: dd 0

     mov rax, A           # A by itself is its address
     mov eax, [A]         # Use [A] to dereference get its value >>
If that was the same in a HLL, then you'd write this:

     int a, b, c;

     a;                   // address of a (&a now)
     *a;                  // value of a
     *a = *b + *c;

That would be inconvenient however, so most HLLs will automatically
dereference variables names so that you get the value. You need &a to
get their address (some languages can figure out what you're trying to
do).

you mean this *a is to remember this dereference like

[0x9879879] -> 0x33373873

its kinda nonsense in practice imo as it you use few *a *a *a *a
but you not change a in a row the first time only compiler dereferences [0x9879879]  then it uses 0x33373873 if it is sane compiler not
[0x9879879] every time so this *a is not illustrating but is misleading

in fact if a is reference to rint not to int (rint i mean this typedef
conts int rint;) then when you writa a it could in fact not to use 0x33373873 but immediate value, say 3

so here are 3 levels

int*  - [0x09879879]
int/int&   -  0x33373873
rint/rint&    - 3

it imo says you should use int/int& instead of int* when appropriate and rint/rint& instead of int/int& when appropriate

(though it would need to be tested in practice

i only now concluded that int& are better and rints are better, never
used it massively

note this damn flow in function arguments


foo(char* txt, unsigned color)
{
//...
}
//here it should be

foo(rchar* txt, runsigned color)

becouse in most cases youre interested in value of color not its
real adress..sometimes you may use the adrees of color like using it
like local variable (color=color&0xff00 etc) buts its kinda side
effect - normally youre interested in values not having local copies
so it shows most cases if not all argument should be const/read only


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.c

fir pisze:

fir pisze:

Bart pisze:

On 20/05/2026 04:13, fir wrote:

in separate theread i noticed that references are same as pointers
but with swapped syntax and changed symbol

NORMAL

int*x;
   x //pointer value
  *x //value

SWAPPED SYNTAX: (fictional)
int* x;
   *x //pointer value
    x ; //value


i talk about this reversed syntax  becouse this
syntax has more sense becouse you more often acces value than
use pointer value


REFERENCE:

   int& x;
     &x; //pointer value (kinda)(there is subtle difference as in >>>> reversed pointer syntax you would be able to change it)
      x; //value


SO IN SHORT

if you swap syntax of pointers on more sane where xis value and *x
is aeress (not like today *x is value and x is adress) you will get
the c++ reference  except that in c++ afaik (i not used it really in >>>> my life as
i distaste c++) you cannot change it

This is where a HLL varies from Assembly; take this variable A (in C,
'int A;'):

     A: dd 0

     mov rax, A           # A by itself is its address
     mov eax, [A]         # Use [A] to dereference get its value

If that was the same in a HLL, then you'd write this:

     int a, b, c;

     a;                   // address of a (&a now) >>>      *a;                  // value of a
     *a = *b + *c;

That would be inconvenient however, so most HLLs will automatically
dereference variables names so that you get the value. You need &a to
get their address (some languages can figure out what you're trying
to do).

you mean this *a is to remember this dereference like

[0x9879879] -> 0x33373873

its kinda nonsense in practice imo as it you use few *a *a *a *a
but you not change a in a row the first time only compiler dereferences
[0x9879879]  then it uses 0x33373873 if it is sane compiler not
[0x9879879] every time so this *a is not illustrating but is misleading

in fact if a is reference to rint not to int (rint i mean this typedef
conts int rint;) then when you writa a it could in fact not to use
0x33373873 but immediate value, say 3

so here are 3 levels

int*  - [0x09879879]
int/int&   -  0x33373873
rint/rint&    - 3

it imo says you should use int/int& instead of int* when appropriate and
rint/rint& instead of int/int& when appropriate

(though it would need to be tested in practice

i only now concluded that int& are better and rints are better, never
used it massively

note this damn flow in function arguments

foo(char* txt, unsigned color)
{
 //...
}
  //here it should be

foo(rchar* txt, runsigned color)

small mistake here obviously it should be

foo(rchar& txt, runsigned color)

(const pointer to array of const char)

becouse in most cases youre interested in value of color not its
real adress..sometimes you may use the adrees of color like using it
like local variable (color=color&0xff00 etc) buts its kinda side
effect - normally youre interested in values not having local copies
so it shows most cases if not all argument should be const/read only

--- Synchronet 3.22a-Linux NewsLink 1.2