Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #87429 > unrolled thread

What a reference actually is

Back to article view | Back to comp.lang.c++

Contents

  What a reference actually is Juha Nieminen <nospam@thanks.invalid> - 2022-11-17 09:01 +0000
    Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-17 06:09 -0800
      Re: What a reference actually is Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-18 00:36 +0200
        Re: What a reference actually is JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-11-18 07:49 +0200
        Re: What a reference actually is Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-20 05:48 -0800
      Re: What a reference actually is Juha Nieminen <nospam@thanks.invalid> - 2022-11-18 09:40 +0000
        Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-18 03:23 -0800
          Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-18 05:11 -0800
          Re: What a reference actually is James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-11-19 02:34 -0500
            Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-19 08:20 -0800
              Re: What a reference actually is Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-20 00:37 +0200
                Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-19 15:35 -0800
              Re: What a reference actually is Öö Tiib <ootiib@hot.ee> - 2022-11-19 15:13 -0800
                Re: What a reference actually is "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 15:18 -0800
                  Re: What a reference actually is Öö Tiib <ootiib@hot.ee> - 2022-11-19 15:33 -0800
                    Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-19 15:36 -0800
                      Re: What a reference actually is Öö Tiib <ootiib@hot.ee> - 2022-11-19 15:43 -0800
                        Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-19 15:51 -0800
                          Re: What a reference actually is Öö Tiib <ootiib@hot.ee> - 2022-11-19 17:57 -0800
                            Re: What a reference actually is "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-19 19:56 -0800
                              Re: What a reference actually is Öö Tiib <ootiib@hot.ee> - 2022-11-20 03:47 -0800
                                Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-20 04:24 -0800
                                  Re: What a reference actually is Öö Tiib <ootiib@hot.ee> - 2022-11-20 06:32 -0800
                                    Re: What a reference actually is "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-11-21 16:32 -0800
                                      Re: What a reference actually is Öö Tiib <ootiib@hot.ee> - 2022-11-22 08:30 -0800
                Re: What a reference actually is Michael S <already5chosen@yahoo.com> - 2022-11-19 15:27 -0800
                  Re: What a reference actually is Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-20 01:28 +0200
        Re: What a reference actually is Paavo Helde <eesnimi@osa.pri.ee> - 2022-11-18 14:51 +0200
          Re: What a reference actually is JiiPee <kerrttuPoistaTama11@gmail.com> - 2022-11-18 18:32 +0200
          Re: What a reference actually is Juha Nieminen <nospam@thanks.invalid> - 2022-11-21 11:56 +0000
    Re: What a reference actually is Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-17 19:27 +0100
    Re: What a reference actually is Jorgen Grahn <grahn+nntp@snipabacken.se> - 2022-11-19 17:10 +0000
      Re: What a reference actually is Juha Nieminen <nospam@thanks.invalid> - 2022-11-21 11:59 +0000

Page 1 of 2  [1] 2  Next page →

#87429 — What a reference actually is

I have noticed that a lot of C++ programmers have an... well, perhaps the
word "incorrect" is too strong, but at least slightly incorrect concept
of what a "reference" in C++ is. Not in terms of how the compiler
implements it internally, but at the language level. Thus, they tend to
explain it to beginners in a way that might not be the best. (They tend to
go too much into the internal implementation details that the compiler uses,
even if they do this inadvertently, instead of talking at the *language*
level, about the semantics.)

What I mean with this is that many (perhaps most?) C++ programmers seem to
think of C++ references, for all intents and purposes, as "an alternative
syntax for pointers". A more limited version of a pointer. Perhaps "a safer
alternative syntax for a pointer."

While a reference might in practice be internally implemented by the
compiler pretty much as if it were a pointer, it shouldn't really be
thought as such at the language level.

A reference should be thought of as an "alias" for the original variable
it's referencing. In almost all situations the reference behaves in the
exact same way as the original object it's referencing. Whatever you do
to the reference is in practice as if you were doing it directly to the
original object. In fact, the syntax for doing things to the original
object via the reference is in almost all cases identical to the syntax
if you were using the original object directly.

The reason why a reference is not a pointer is because of that. For example,
you can not use the 'variable[integer]' syntax on a reference if the original
object does not support that syntax (and, conversely, you *can* use that
syntax if the original object supports it). This shouldn't be thought of as
"it's because this is a more limited alternative syntax for pointers", but
as "it's because this is an 'alias' for the original object, and behaves the
same as that original object does". It's as if you were using the original
object directly, and thus all the same syntax support applies.

This form of thinking also explains why you can't change a reference to
later refer to a different object. It would be like you were trying to
make the original object somehow become the other object. Not a *copy*
of the other object, but literally the other object. From a semantical
perspective that makes no sense. It just doesn't compute.

(One could argue that there should be a way to make a reference change
what it's an "alias" of, but this is how it was originally designed, so
this is how it works.)

The advantage of using such an 'alias' reference is that the 'alias' is
not a *copy* of the original object. It's just an alias of the original
object (which still resides where it originally was created). Thus the
reference is usually much more lightweight than taking the original
object by copy.

While that makes it *similar* to a pointer (and it may internally be
implemented as such), it shouldn't really be thought of as one.

[toc] | [next] | [standalone]

#87432

On Thursday, November 17, 2022 at 11:01:30 AM UTC+2, Juha Nieminen wrote:
> I have noticed that a lot of C++ programmers have an... well, perhaps the 
> word "incorrect" is too strong, but at least slightly incorrect concept 
> of what a "reference" in C++ is. Not in terms of how the compiler 
> implements it internally, but at the language level. Thus, they tend to 
> explain it to beginners in a way that might not be the best. (They tend to 
> go too much into the internal implementation details that the compiler uses, 
> even if they do this inadvertently, instead of talking at the *language* 
> level, about the semantics.) 
> 
> What I mean with this is that many (perhaps most?) C++ programmers seem to 
> think of C++ references, for all intents and purposes, as "an alternative 
> syntax for pointers". A more limited version of a pointer. Perhaps "a safer 
> alternative syntax for a pointer." 
> 
> While a reference might in practice be internally implemented by the 
> compiler pretty much as if it were a pointer, it shouldn't really be 
> thought as such at the language level. 
> 
> A reference should be thought of as an "alias" for the original variable 
> it's referencing. In almost all situations the reference behaves in the 
> exact same way as the original object it's referencing. Whatever you do 
> to the reference is in practice as if you were doing it directly to the 
> original object. In fact, the syntax for doing things to the original 
> object via the reference is in almost all cases identical to the syntax 
> if you were using the original object directly. 
> 
> The reason why a reference is not a pointer is because of that. For example, 
> you can not use the 'variable[integer]' syntax on a reference if the original 
> object does not support that syntax (and, conversely, you *can* use that 
> syntax if the original object supports it). This shouldn't be thought of as 
> "it's because this is a more limited alternative syntax for pointers", but 
> as "it's because this is an 'alias' for the original object, and behaves the 
> same as that original object does". It's as if you were using the original 
> object directly, and thus all the same syntax support applies. 
> 
> This form of thinking also explains why you can't change a reference to 
> later refer to a different object. It would be like you were trying to 
> make the original object somehow become the other object. Not a *copy* 
> of the other object, but literally the other object. From a semantical 
> perspective that makes no sense. It just doesn't compute. 
> 
> (One could argue that there should be a way to make a reference change 
> what it's an "alias" of, but this is how it was originally designed, so 
> this is how it works.) 
> 
> The advantage of using such an 'alias' reference is that the 'alias' is 
> not a *copy* of the original object. It's just an alias of the original 
> object (which still resides where it originally was created). Thus the 
> reference is usually much more lightweight than taking the original 
> object by copy. 
> 
> While that makes it *similar* to a pointer (and it may internally be 
> implemented as such), it shouldn't really be thought of as one.

For language that is so similar (nearly identical) to C at the level of
"virtual machine", as is C++, the concept of reference is just unnecessary.
Don't use references in your code except when forced by interfaces that
are out of your control! Then people that are going to read and comprehend
your code will be thankful.

[toc] | [prev] | [next] | [standalone]

#87438

17.11.2022 16:09 Michael S kirjutas:
> 
> For language that is so similar (nearly identical) to C at the level of
> "virtual machine", as is C++, the concept of reference is just unnecessary.
> Don't use references in your code except when forced by interfaces that
> are out of your control! Then people that are going to read and comprehend
> your code will be thankful.

Aren't most languages similar to C at the level of virtual machine? And 
isn't it so that a major point of having higher level languages is to 
provide better abstractions than the virtual machine?

With C++, my advise is to not use raw pointers in your code except when 
forced by interfaces that are out of your control. Prefer references 
instead, especially const lvalue and non-const rvalue references.

[toc] | [prev] | [next] | [standalone]

#87441

On 18/11/2022 00:36, Paavo Helde wrote:
> With C++, my advise is to not use raw pointers in your code except when 
> forced by interfaces that are out of your control. Prefer references 
> instead,

I have done C++ since 1997 and I agree.

[toc] | [prev] | [next] | [standalone]

#87487

Paavo Helde <eesnimi@osa.pri.ee> writes:

> 17.11.2022 16:09 Michael S kirjutas:
>
>> For language that is so similar (nearly identical) to C at the level of
>> "virtual machine", as is C++, the concept of reference is just unnecessary.
>> Don't use references in your code except when forced by interfaces that
>> are out of your control!  Then people that are going to read and comprehend
>> your code will be thankful.
>
> Aren't most languages similar to C at the level of virtual machine?

No.  Many are.  Many are not.

[toc] | [prev] | [next] | [standalone]

#87443

Michael S <already5chosen@yahoo.com> wrote:
> For language that is so similar (nearly identical) to C at the level of
> "virtual machine", as is C++, the concept of reference is just unnecessary.

If we start dismissing everything that one could deem "unnecessary" then we
could start dropping off quite many features even from C itself.

After all, for example the syntax 'a[b]' is just syntactic sugar for
'*(a+b)', and thus the former is "unnecessary" and could just be dropped
off. A 'for()' statement is unnecessary because you can write the same
thing using a 'while()' statement. And obviously the 'do' keyword is
completely unnecessary. As well as the 'switch' keyword. And why do we
even need a 'const' keyword at all? That could be easily dropped off.

We could easily drop half of C syntax as "unnecessary" and still be able
to write the same programs as before. Not to talk about C++!

> Don't use references in your code except when forced by interfaces that
> are out of your control! Then people that are going to read and comprehend
> your code will be thankful.

Actually references add useful abstraction to interfaces. For example,
when you write 'foobar(abc)', is that 'foobar' function taking the
parameter by value or by reference? It can decide! Whatever is best in
that particular function, it can choose. The calling code doesn't need to
tie its hands and force one or the other.

Moreover, if later it turns out that the function would need to change
how it takes the parameter (for example it originally took it by value,
but the type got a lot larger after a refactor, so now it would be more
efficient to take it by reference), it can do so without breaking any
code that's calling the function. (And no, "just fix all the places
where the function is called, by following the compiler errors" is not
a good solution because this may be a library used somewhere, and you
will be breaking the API, causing it to become incompatible with the
previous version, forcing every project that uses the library to fix
all the calls.)

Also, how do you suggest implementing copy constructors and operator
overloading without references?

[toc] | [prev] | [next] | [standalone]

#87444

On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote:
> Michael S <already...@yahoo.com> wrote: 
> > For language that is so similar (nearly identical) to C at the level of 
> > "virtual machine", as is C++, the concept of reference is just unnecessary.
> If we start dismissing everything that one could deem "unnecessary" then we 
> could start dropping off quite many features even from C itself. 
> 
> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> '*(a+b)', and thus the former is "unnecessary" and could just be dropped 
> off. 

The [] variant is shorter by 2 characters. In DRM view, shortness of most 
frequently used language features was of high priority.
Also, in slightly more complex expressions, in case of *(a+b) variant reader 
has to look for more information in order to figure out which of two homonyms
of * is actually used. I would speculate that DRM was not really pleased with
using asterisk for dereference, but had no better choice in available
character set.

A 'for()' statement is unnecessary because you can write the same 
> thing using a 'while()' statement. 

Except that 'continue' behave differently.
The better argument is that 'while' loops are unnecessary and that is
absolutely correct. A mistake on part of DRM.

> And obviously the 'do' keyword is completely unnecessary.

I don't see it. Please elaborate.

>  As well as the 'switch' keyword. 

What alternative do have in mind? if-else-if chains?
Both more typing and intentions of using the same selection variable
for all choices is not pronounced clearly.

> And why do we 
> even need a 'const' keyword at all? That could be easily dropped off. 

People argue for that. IIRC, 'const' is relatively late addition to C, so
likely DRM was not very sure about it.
Personally, I find it useful, primarily for documenting of intent. 
The claim that it often helps to catch bugs is hard to prove.
As to C++ [mis]use for peeking one of polymorphic methods... well,
it's pretty bad, but not the worst thing caused by polymorphic methods.

> 
> We could easily drop half of C syntax as "unnecessary" and still be able 
> to write the same programs as before. Not to talk about C++!

So, you don't think that  C++ will become a better language if 2/3rd of it
is dropped? I was under impression that just about everybody agree about
that. Of course, they rarely agree about what third to retain.

> > Don't use references in your code except when forced by interfaces that 
> > are out of your control! Then people that are going to read and comprehend 
> > your code will be thankful.
> Actually references add useful abstraction to interfaces. For example, 
> when you write 'foobar(abc)', is that 'foobar' function taking the 
> parameter by value or by reference? It can decide! Whatever is best in 
> that particular function, it can choose. The calling code doesn't need to 
> tie its hands and force one or the other. 
> 
> Moreover, if later it turns out that the function would need to change 
> how it takes the parameter (for example it originally took it by value, 
> but the type got a lot larger after a refactor, so now it would be more 
> efficient to take it by reference), it can do so without breaking any 
> code that's calling the function. (And no, "just fix all the places 
> where the function is called, by following the compiler errors" is not 
> a good solution because this may be a library used somewhere, and you 
> will be breaking the API, causing it to become incompatible with the 
> previous version, forcing every project that uses the library to fix 
> all the calls.) 
> 

If only const references were allowed as function arguments I'd
wholeheartedly agree with majority of above paragraph. 
Unfortunately, mutable references are as legal as const ones
and the reader of the code has no hint about which variant was
used by looking at function call.

> Also, how do you suggest implementing copy constructors and operator 
> overloading without references?

How said that I suggest implementing copy constructors and operator
overloading?
In my view, non-trivial constructor is original sin of C++ language.
It begot exceptions and the rest of the mess followed.

[toc] | [prev] | [next] | [standalone]

#87447

On Friday, November 18, 2022 at 1:23:10 PM UTC+2, Michael S wrote:
> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: 
> > Michael S <already...@yahoo.com> wrote: 
> > > For language that is so similar (nearly identical) to C at the level of 
> > > "virtual machine", as is C++, the concept of reference is just unnecessary. 
> > If we start dismissing everything that one could deem "unnecessary" then we 
> > could start dropping off quite many features even from C itself. 
> > 
> > After all, for example the syntax 'a[b]' is just syntactic sugar for 
> > '*(a+b)', and thus the former is "unnecessary" and could just be dropped 
> > off.
> The [] variant is shorter by 2 characters. In DRM view, shortness of most 
> frequently used language features was of high priority. 
> Also, in slightly more complex expressions, in case of *(a+b) variant reader 
> has to look for more information in order to figure out which of two homonyms 
> of * is actually used. I would speculate that DRM was not really pleased with 
> using asterisk for dereference, but had no better choice in available 
> character set.
> A 'for()' statement is unnecessary because you can write the same 
> > thing using a 'while()' statement.
> Except that 'continue' behave differently. 
> The better argument is that 'while' loops are unnecessary and that is 
> absolutely correct. A mistake on part of DRM.
> > And obviously the 'do' keyword is completely unnecessary.
> I don't see it. Please elaborate.
> > As well as the 'switch' keyword.
> What alternative do have in mind? if-else-if chains? 
> Both more typing and intentions of using the same selection variable 
> for all choices is not pronounced clearly.
> > And why do we 
> > even need a 'const' keyword at all? That could be easily dropped off.
> People argue for that. IIRC, 'const' is relatively late addition to C, so 
> likely DRM was not very sure about it. 
> Personally, I find it useful, primarily for documenting of intent. 
> The claim that it often helps to catch bugs is hard to prove. 
> As to C++ [mis]use for peeking one of polymorphic methods... well, 
> it's pretty bad, but not the worst thing caused by polymorphic methods.
> > 
> > We could easily drop half of C syntax as "unnecessary" and still be able 
> > to write the same programs as before. Not to talk about C++!
> So, you don't think that C++ will become a better language if 2/3rd of it 
> is dropped? I was under impression that just about everybody agree about 
> that. Of course, they rarely agree about what third to retain.
> > > Don't use references in your code except when forced by interfaces that 
> > > are out of your control! Then people that are going to read and comprehend 
> > > your code will be thankful. 
> > Actually references add useful abstraction to interfaces. For example, 
> > when you write 'foobar(abc)', is that 'foobar' function taking the 
> > parameter by value or by reference? It can decide! Whatever is best in 
> > that particular function, it can choose. The calling code doesn't need to 
> > tie its hands and force one or the other. 
> > 
> > Moreover, if later it turns out that the function would need to change 
> > how it takes the parameter (for example it originally took it by value, 
> > but the type got a lot larger after a refactor, so now it would be more 
> > efficient to take it by reference), it can do so without breaking any 
> > code that's calling the function. (And no, "just fix all the places 
> > where the function is called, by following the compiler errors" is not 
> > a good solution because this may be a library used somewhere, and you 
> > will be breaking the API, causing it to become incompatible with the 
> > previous version, forcing every project that uses the library to fix 
> > all the calls.) 
> >
> If only const references were allowed as function arguments I'd 
> wholeheartedly agree with majority of above paragraph. 
> Unfortunately, mutable references are as legal as const ones 
> and the reader of the code has no hint about which variant was 
> used by looking at function call.
> > Also, how do you suggest implementing copy constructors and operator 
> > overloading without references?
> How said that I suggest implementing copy constructors and operator 
> overloading? 
> In my view, non-trivial constructor is original sin of C++ language. 
> It begot exceptions and the rest of the mess followed.

In post above, please mentally replace DRM with DMR.

[toc] | [prev] | [next] | [standalone]

#87457

On 11/18/22 06:23, Michael S wrote:
> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote:
...
>> If we start dismissing everything that one could deem "unnecessary"
>> then we could start dropping off quite many features even from C itself.
>> After all, for example the syntax 'a[b]' is just syntactic sugar for
>> '*(a+b)', and thus the former is "unnecessary" and could just be
>> dropped off. 
>
> The [] variant is shorter by 2 characters. In DRM view, shortness of
> most frequently used language features was of high priority.
> Also, in slightly more complex expressions, in case of *(a+b) variant
> reader has to look for more information in order to figure out which
> of two homonyms
> of * is actually used. I would speculate that DRM was not really
> pleased with
> using asterisk for dereference, but had no better choice in available
> character set.
>
> A 'for()' statement is unnecessary because you can write the same
>> thing using a 'while()' statement. 
>
> Except that 'continue' behave differently.
> The better argument is that 'while' loops are unnecessary and that is
> absolutely correct. A mistake on part of DRM.
>
>> And obviously the 'do' keyword is completely unnecessary.
>
> I don't see it. Please elaborate.
>
>> As well as the 'switch' keyword. 
>
> What alternative do have in mind? if-else-if chains?
> Both more typing and intentions of using the same selection variable
> for all choices is not pronounced clearly.

I get the impression that you've missed his point. He's not arguing that
C would be made better by dropping all of those things. He's pointing
out that just because something is not necessary, is not a reason for
dropping it from the language. It is precisely his point that the
language would be less easy to use if these features were removed for no
better reason than the fact that they are unnecessary.

[toc] | [prev] | [next] | [standalone]

#87461

On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote:
> On 11/18/22 06:23, Michael S wrote: 
> > On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote:
> ...
> >> If we start dismissing everything that one could deem "unnecessary" 
> >> then we could start dropping off quite many features even from C itself. 
> >> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> >> '*(a+b)', and thus the former is "unnecessary" and could just be 
> >> dropped off. 
> > 
> > The [] variant is shorter by 2 characters. In DRM view, shortness of 
> > most frequently used language features was of high priority. 
> > Also, in slightly more complex expressions, in case of *(a+b) variant 
> > reader has to look for more information in order to figure out which 
> > of two homonyms 
> > of * is actually used. I would speculate that DRM was not really 
> > pleased with 
> > using asterisk for dereference, but had no better choice in available 
> > character set. 
> > 
> > A 'for()' statement is unnecessary because you can write the same 
> >> thing using a 'while()' statement. 
> > 
> > Except that 'continue' behave differently. 
> > The better argument is that 'while' loops are unnecessary and that is 
> > absolutely correct. A mistake on part of DRM. 
> > 
> >> And obviously the 'do' keyword is completely unnecessary. 
> > 
> > I don't see it. Please elaborate. 
> > 
> >> As well as the 'switch' keyword. 
> > 
> > What alternative do have in mind? if-else-if chains? 
> > Both more typing and intentions of using the same selection variable 
> > for all choices is not pronounced clearly.
> I get the impression that you've missed his point. He's not arguing that 
> C would be made better by dropping all of those things. He's pointing 
> out that just because something is not necessary, is not a reason for 
> dropping it from the language. It is precisely his point that the 
> language would be less easy to use if these features were removed for no 
> better reason than the fact that they are unnecessary.

I don't know about your or Juha, but I personally draw a line at DRY.
Features that help to DRY can be controversial, can be even harmful,
(as many preprocessor macros) but they are not nutrient-free syntactic
 sugar.
Of all features of 'C' listed by Juha, only 'while' and 'const' do not help
DRY at all and only [] help it minimally, but [] obviously help other aspects
of readability.
C++ references do not help DRY at all, except if you consider  & here
or * there as repeating yourself. And, IMHO, presence of references 
in the language makes understanding somebody else's code
significantly harder.

[toc] | [prev] | [next] | [standalone]

#87464

19.11.2022 18:20 Michael S kirjutas:
> I don't know about your or Juha, but I personally draw a line at DRY.
> Features that help to DRY can be controversial, can be even harmful,
> (as many preprocessor macros) but they are not nutrient-free syntactic
>   sugar.
[...]
> C++ references do not help DRY at all, except if you consider  & here
> or * there as repeating yourself. And, IMHO, presence of references
> in the language makes understanding somebody else's code
> significantly harder.

That's strange, are you sure you mean the same DRY ("Don't repeat 
yourself")? Because with pointers you need to consider and repeat the 
fact that you are calling via a pointer at each call site, with 
references this is not so.

I agree the code might be hard to understand if references or pointers 
are abused for implementing "output parameters". But thankfully, C++ has 
perfectly fine ways to return multiple values from the function, so 
there is no need to abuse pointers or references for that purpose. And 
for normal input parameters references (const or rvalue) are just fine 
and often a much better choice than pointers.

Also, if you say presence of references is what makes C++ hard to 
understand, I start to suspect you haven't seen half of C++ yet. Look up 
any template code posts from Bonita, for starters ;-)

[toc] | [prev] | [next] | [standalone]

#87472

On Sunday, November 20, 2022 at 12:38:14 AM UTC+2, Paavo Helde wrote:
> 19.11.2022 18:20 Michael S kirjutas: 
> > I don't know about your or Juha, but I personally draw a line at DRY. 
> > Features that help to DRY can be controversial, can be even harmful, 
> > (as many preprocessor macros) but they are not nutrient-free syntactic 
> > sugar.
> [...]
> > C++ references do not help DRY at all, except if you consider & here 
> > or * there as repeating yourself. And, IMHO, presence of references 
> > in the language makes understanding somebody else's code 
> > significantly harder.
> That's strange, are you sure you mean the same DRY ("Don't repeat 
> yourself")? Because with pointers you need to consider and repeat the 
> fact that you are calling via a pointer at each call site, with 
> references this is not so. 
> 

As I said, "except if you consider & here or * there as repeating yourself."
I don't. Also, even those who considered it repeating would agree that
it is non dangerous sort of repeating, because each time you did it wrong
compiler will catch you.

> I agree the code might be hard to understand if references or pointers 
> are abused for implementing "output parameters".

You mean tuples?
May be, they should be used more, but syntax is rather ugly.
Even pairs look ugly.

>  But thankfully, C++ has 
> perfectly fine ways to return multiple values from the function, so 
> there is no need to abuse pointers or references for that purpose.
>  And 
> for normal input parameters references (const or rvalue) are just fine 
> and often a much better choice than pointers. 
> 
> Also, if you say presence of references is what makes C++ hard to 
> understand, I start to suspect you haven't seen half of C++ yet. Look up 
> any template code posts from Bonita, for starters ;-)

Of course, I recognize that references are a small nuisance relatively
to 100 other features in C++, including 75 features  that considered
god-send by "modern C++" enthusiasts.

[toc] | [prev] | [next] | [standalone]

#87467

On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote:
> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote: 
> > On 11/18/22 06:23, Michael S wrote: 
> > > On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: 
> > ... 
> > >> If we start dismissing everything that one could deem "unnecessary" 
> > >> then we could start dropping off quite many features even from C itself. 
> > >> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> > >> '*(a+b)', and thus the former is "unnecessary" and could just be 
> > >> dropped off. 
> > > 
> > > The [] variant is shorter by 2 characters. In DRM view, shortness of 
> > > most frequently used language features was of high priority. 
> > > Also, in slightly more complex expressions, in case of *(a+b) variant 
> > > reader has to look for more information in order to figure out which 
> > > of two homonyms 
> > > of * is actually used. I would speculate that DRM was not really 
> > > pleased with 
> > > using asterisk for dereference, but had no better choice in available 
> > > character set. 
> > > 
> > > A 'for()' statement is unnecessary because you can write the same 
> > >> thing using a 'while()' statement. 
> > > 
> > > Except that 'continue' behave differently. 
> > > The better argument is that 'while' loops are unnecessary and that is 
> > > absolutely correct. A mistake on part of DRM. 
> > > 
> > >> And obviously the 'do' keyword is completely unnecessary. 
> > > 
> > > I don't see it. Please elaborate. 
> > > 
> > >> As well as the 'switch' keyword. 
> > > 
> > > What alternative do have in mind? if-else-if chains? 
> > > Both more typing and intentions of using the same selection variable 
> > > for all choices is not pronounced clearly. 
> > I get the impression that you've missed his point. He's not arguing that 
> > C would be made better by dropping all of those things. He's pointing 
> > out that just because something is not necessary, is not a reason for 
> > dropping it from the language. It is precisely his point that the 
> > language would be less easy to use if these features were removed for no 
> > better reason than the fact that they are unnecessary.
> I don't know about your or Juha, but I personally draw a line at DRY. 
> Features that help to DRY can be controversial, can be even harmful, 
> (as many preprocessor macros) but they are not nutrient-free syntactic 
> sugar. 
> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help 
> DRY at all and only [] help it minimally, but [] obviously help other aspects 
> of readability. 
> C++ references do not help DRY at all, except if you consider & here 
> or * there as repeating yourself. And, IMHO, presence of references 
> in the language makes understanding somebody else's code 
> significantly harder.

Pointer can be null, so everywhere it is passed has to check that it is
not null and that gets quite repetitive to do after a while.

[toc] | [prev] | [next] | [standalone]

#87468

On 11/19/2022 3:13 PM, Öö Tiib wrote:
> On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote:
>> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote:
>>> On 11/18/22 06:23, Michael S wrote:
>>>> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote:
>>> ...
>>>>> If we start dismissing everything that one could deem "unnecessary"
>>>>> then we could start dropping off quite many features even from C itself.
>>>>> After all, for example the syntax 'a[b]' is just syntactic sugar for
>>>>> '*(a+b)', and thus the former is "unnecessary" and could just be
>>>>> dropped off.
>>>>
>>>> The [] variant is shorter by 2 characters. In DRM view, shortness of
>>>> most frequently used language features was of high priority.
>>>> Also, in slightly more complex expressions, in case of *(a+b) variant
>>>> reader has to look for more information in order to figure out which
>>>> of two homonyms
>>>> of * is actually used. I would speculate that DRM was not really
>>>> pleased with
>>>> using asterisk for dereference, but had no better choice in available
>>>> character set.
>>>>
>>>> A 'for()' statement is unnecessary because you can write the same
>>>>> thing using a 'while()' statement.
>>>>
>>>> Except that 'continue' behave differently.
>>>> The better argument is that 'while' loops are unnecessary and that is
>>>> absolutely correct. A mistake on part of DRM.
>>>>
>>>>> And obviously the 'do' keyword is completely unnecessary.
>>>>
>>>> I don't see it. Please elaborate.
>>>>
>>>>> As well as the 'switch' keyword.
>>>>
>>>> What alternative do have in mind? if-else-if chains?
>>>> Both more typing and intentions of using the same selection variable
>>>> for all choices is not pronounced clearly.
>>> I get the impression that you've missed his point. He's not arguing that
>>> C would be made better by dropping all of those things. He's pointing
>>> out that just because something is not necessary, is not a reason for
>>> dropping it from the language. It is precisely his point that the
>>> language would be less easy to use if these features were removed for no
>>> better reason than the fact that they are unnecessary.
>> I don't know about your or Juha, but I personally draw a line at DRY.
>> Features that help to DRY can be controversial, can be even harmful,
>> (as many preprocessor macros) but they are not nutrient-free syntactic
>> sugar.
>> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help
>> DRY at all and only [] help it minimally, but [] obviously help other aspects
>> of readability.
>> C++ references do not help DRY at all, except if you consider & here
>> or * there as repeating yourself. And, IMHO, presence of references
>> in the language makes understanding somebody else's code
>> significantly harder.
> 
> Pointer can be null, so everywhere it is passed has to check that it is
> not null and that gets quite repetitive to do after a while.

Or, a lib writer can say passing a null pointer into function void* 
foo(void*) will result in undefined behavior.

[toc] | [prev] | [next] | [standalone]

#87471

On Sunday, 20 November 2022 at 01:18:59 UTC+2, Chris M. Thomasson wrote:
> On 11/19/2022 3:13 PM, Öö Tiib wrote: 
> > On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote: 
> >> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote: 
> >>> On 11/18/22 06:23, Michael S wrote: 
> >>>> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: 
> >>> ... 
> >>>>> If we start dismissing everything that one could deem "unnecessary" 
> >>>>> then we could start dropping off quite many features even from C itself. 
> >>>>> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> >>>>> '*(a+b)', and thus the former is "unnecessary" and could just be 
> >>>>> dropped off. 
> >>>> 
> >>>> The [] variant is shorter by 2 characters. In DRM view, shortness of 
> >>>> most frequently used language features was of high priority. 
> >>>> Also, in slightly more complex expressions, in case of *(a+b) variant 
> >>>> reader has to look for more information in order to figure out which 
> >>>> of two homonyms 
> >>>> of * is actually used. I would speculate that DRM was not really 
> >>>> pleased with 
> >>>> using asterisk for dereference, but had no better choice in available 
> >>>> character set. 
> >>>> 
> >>>> A 'for()' statement is unnecessary because you can write the same 
> >>>>> thing using a 'while()' statement. 
> >>>> 
> >>>> Except that 'continue' behave differently. 
> >>>> The better argument is that 'while' loops are unnecessary and that is 
> >>>> absolutely correct. A mistake on part of DRM. 
> >>>> 
> >>>>> And obviously the 'do' keyword is completely unnecessary. 
> >>>> 
> >>>> I don't see it. Please elaborate. 
> >>>> 
> >>>>> As well as the 'switch' keyword. 
> >>>> 
> >>>> What alternative do have in mind? if-else-if chains? 
> >>>> Both more typing and intentions of using the same selection variable 
> >>>> for all choices is not pronounced clearly. 
> >>> I get the impression that you've missed his point. He's not arguing that 
> >>> C would be made better by dropping all of those things. He's pointing 
> >>> out that just because something is not necessary, is not a reason for 
> >>> dropping it from the language. It is precisely his point that the 
> >>> language would be less easy to use if these features were removed for no 
> >>> better reason than the fact that they are unnecessary. 
> >> I don't know about your or Juha, but I personally draw a line at DRY. 
> >> Features that help to DRY can be controversial, can be even harmful, 
> >> (as many preprocessor macros) but they are not nutrient-free syntactic 
> >> sugar. 
> >> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help 
> >> DRY at all and only [] help it minimally, but [] obviously help other aspects 
> >> of readability. 
> >> C++ references do not help DRY at all, except if you consider & here 
> >> or * there as repeating yourself. And, IMHO, presence of references 
> >> in the language makes understanding somebody else's code 
> >> significantly harder. 
> > 
> > Pointer can be null, so everywhere it is passed has to check that it is 
> > not null and that gets quite repetitive to do after a while.
> 
> Or, a lib writer can say passing a null pointer into function void* 
> foo(void*) will result in undefined behavior.

So caller has to check, that is even worse violation of DRY as a function is
usually called from multiple places. Meanwhile lib writer can accept a
reference and then the check is needed on neither side.

[toc] | [prev] | [next] | [standalone]

#87473

On Sunday, November 20, 2022 at 1:33:16 AM UTC+2, Öö Tiib wrote:
> On Sunday, 20 November 2022 at 01:18:59 UTC+2, Chris M. Thomasson wrote: 
> > On 11/19/2022 3:13 PM, Öö Tiib wrote: 
> > > On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote: 
> > >> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote: 
> > >>> On 11/18/22 06:23, Michael S wrote: 
> > >>>> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: 
> > >>> ... 
> > >>>>> If we start dismissing everything that one could deem "unnecessary" 
> > >>>>> then we could start dropping off quite many features even from C itself. 
> > >>>>> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> > >>>>> '*(a+b)', and thus the former is "unnecessary" and could just be 
> > >>>>> dropped off. 
> > >>>> 
> > >>>> The [] variant is shorter by 2 characters. In DRM view, shortness of 
> > >>>> most frequently used language features was of high priority. 
> > >>>> Also, in slightly more complex expressions, in case of *(a+b) variant 
> > >>>> reader has to look for more information in order to figure out which 
> > >>>> of two homonyms 
> > >>>> of * is actually used. I would speculate that DRM was not really 
> > >>>> pleased with 
> > >>>> using asterisk for dereference, but had no better choice in available 
> > >>>> character set. 
> > >>>> 
> > >>>> A 'for()' statement is unnecessary because you can write the same 
> > >>>>> thing using a 'while()' statement. 
> > >>>> 
> > >>>> Except that 'continue' behave differently. 
> > >>>> The better argument is that 'while' loops are unnecessary and that is 
> > >>>> absolutely correct. A mistake on part of DRM. 
> > >>>> 
> > >>>>> And obviously the 'do' keyword is completely unnecessary. 
> > >>>> 
> > >>>> I don't see it. Please elaborate. 
> > >>>> 
> > >>>>> As well as the 'switch' keyword. 
> > >>>> 
> > >>>> What alternative do have in mind? if-else-if chains? 
> > >>>> Both more typing and intentions of using the same selection variable 
> > >>>> for all choices is not pronounced clearly. 
> > >>> I get the impression that you've missed his point. He's not arguing that 
> > >>> C would be made better by dropping all of those things. He's pointing 
> > >>> out that just because something is not necessary, is not a reason for 
> > >>> dropping it from the language. It is precisely his point that the 
> > >>> language would be less easy to use if these features were removed for no 
> > >>> better reason than the fact that they are unnecessary. 
> > >> I don't know about your or Juha, but I personally draw a line at DRY. 
> > >> Features that help to DRY can be controversial, can be even harmful, 
> > >> (as many preprocessor macros) but they are not nutrient-free syntactic 
> > >> sugar. 
> > >> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help 
> > >> DRY at all and only [] help it minimally, but [] obviously help other aspects 
> > >> of readability. 
> > >> C++ references do not help DRY at all, except if you consider & here 
> > >> or * there as repeating yourself. And, IMHO, presence of references 
> > >> in the language makes understanding somebody else's code 
> > >> significantly harder. 
> > > 
> > > Pointer can be null, so everywhere it is passed has to check that it is 
> > > not null and that gets quite repetitive to do after a while. 
> > 
> > Or, a lib writer can say passing a null pointer into function void* 
> > foo(void*) will result in undefined behavior.
> So caller has to check, that is even worse violation of DRY as a function is 
> usually called from multiple places. Meanwhile lib writer can accept a 
> reference and then the check is needed on neither side.

No, caller does not have to check, because caller knows that he passes non-null.

[toc] | [prev] | [next] | [standalone]

#87474

On Sunday, 20 November 2022 at 01:36:50 UTC+2, Michael S wrote:
> On Sunday, November 20, 2022 at 1:33:16 AM UTC+2, Öö Tiib wrote: 
> > On Sunday, 20 November 2022 at 01:18:59 UTC+2, Chris M. Thomasson wrote: 
> > > On 11/19/2022 3:13 PM, Öö Tiib wrote: 
> > > > On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote: 
> > > >> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote: 
> > > >>> On 11/18/22 06:23, Michael S wrote: 
> > > >>>> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: 
> > > >>> ... 
> > > >>>>> If we start dismissing everything that one could deem "unnecessary" 
> > > >>>>> then we could start dropping off quite many features even from C itself. 
> > > >>>>> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> > > >>>>> '*(a+b)', and thus the former is "unnecessary" and could just be 
> > > >>>>> dropped off. 
> > > >>>> 
> > > >>>> The [] variant is shorter by 2 characters. In DRM view, shortness of 
> > > >>>> most frequently used language features was of high priority. 
> > > >>>> Also, in slightly more complex expressions, in case of *(a+b) variant 
> > > >>>> reader has to look for more information in order to figure out which 
> > > >>>> of two homonyms 
> > > >>>> of * is actually used. I would speculate that DRM was not really 
> > > >>>> pleased with 
> > > >>>> using asterisk for dereference, but had no better choice in available 
> > > >>>> character set. 
> > > >>>> 
> > > >>>> A 'for()' statement is unnecessary because you can write the same 
> > > >>>>> thing using a 'while()' statement. 
> > > >>>> 
> > > >>>> Except that 'continue' behave differently. 
> > > >>>> The better argument is that 'while' loops are unnecessary and that is 
> > > >>>> absolutely correct. A mistake on part of DRM. 
> > > >>>> 
> > > >>>>> And obviously the 'do' keyword is completely unnecessary. 
> > > >>>> 
> > > >>>> I don't see it. Please elaborate. 
> > > >>>> 
> > > >>>>> As well as the 'switch' keyword. 
> > > >>>> 
> > > >>>> What alternative do have in mind? if-else-if chains? 
> > > >>>> Both more typing and intentions of using the same selection variable 
> > > >>>> for all choices is not pronounced clearly. 
> > > >>> I get the impression that you've missed his point. He's not arguing that 
> > > >>> C would be made better by dropping all of those things. He's pointing 
> > > >>> out that just because something is not necessary, is not a reason for 
> > > >>> dropping it from the language. It is precisely his point that the 
> > > >>> language would be less easy to use if these features were removed for no 
> > > >>> better reason than the fact that they are unnecessary. 
> > > >> I don't know about your or Juha, but I personally draw a line at DRY. 
> > > >> Features that help to DRY can be controversial, can be even harmful, 
> > > >> (as many preprocessor macros) but they are not nutrient-free syntactic 
> > > >> sugar. 
> > > >> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help 
> > > >> DRY at all and only [] help it minimally, but [] obviously help other aspects 
> > > >> of readability. 
> > > >> C++ references do not help DRY at all, except if you consider & here 
> > > >> or * there as repeating yourself. And, IMHO, presence of references 
> > > >> in the language makes understanding somebody else's code 
> > > >> significantly harder. 
> > > > 
> > > > Pointer can be null, so everywhere it is passed has to check that it is 
> > > > not null and that gets quite repetitive to do after a while. 
> > > 
> > > Or, a lib writer can say passing a null pointer into function void* 
> > > foo(void*) will result in undefined behavior. 
> > So caller has to check, that is even worse violation of DRY as a function is 
> > usually called from multiple places. Meanwhile lib writer can accept a 
> > reference and then the check is needed on neither side.
> No, caller does not have to check, because caller knows that he passes non-null.

About reference it is known that it is not null but about pointer it is known only
after checking  ... like if the caller is he or she takes checking.
 

[toc] | [prev] | [next] | [standalone]

#87475

On Sunday, November 20, 2022 at 1:43:28 AM UTC+2, Öö Tiib wrote:
> On Sunday, 20 November 2022 at 01:36:50 UTC+2, Michael S wrote: 
> > On Sunday, November 20, 2022 at 1:33:16 AM UTC+2, Öö Tiib wrote: 
> > > On Sunday, 20 November 2022 at 01:18:59 UTC+2, Chris M. Thomasson wrote: 
> > > > On 11/19/2022 3:13 PM, Öö Tiib wrote: 
> > > > > On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote: 
> > > > >> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote: 
> > > > >>> On 11/18/22 06:23, Michael S wrote: 
> > > > >>>> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: 
> > > > >>> ... 
> > > > >>>>> If we start dismissing everything that one could deem "unnecessary" 
> > > > >>>>> then we could start dropping off quite many features even from C itself. 
> > > > >>>>> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> > > > >>>>> '*(a+b)', and thus the former is "unnecessary" and could just be 
> > > > >>>>> dropped off. 
> > > > >>>> 
> > > > >>>> The [] variant is shorter by 2 characters. In DRM view, shortness of 
> > > > >>>> most frequently used language features was of high priority. 
> > > > >>>> Also, in slightly more complex expressions, in case of *(a+b) variant 
> > > > >>>> reader has to look for more information in order to figure out which 
> > > > >>>> of two homonyms 
> > > > >>>> of * is actually used. I would speculate that DRM was not really 
> > > > >>>> pleased with 
> > > > >>>> using asterisk for dereference, but had no better choice in available 
> > > > >>>> character set. 
> > > > >>>> 
> > > > >>>> A 'for()' statement is unnecessary because you can write the same 
> > > > >>>>> thing using a 'while()' statement. 
> > > > >>>> 
> > > > >>>> Except that 'continue' behave differently. 
> > > > >>>> The better argument is that 'while' loops are unnecessary and that is 
> > > > >>>> absolutely correct. A mistake on part of DRM. 
> > > > >>>> 
> > > > >>>>> And obviously the 'do' keyword is completely unnecessary. 
> > > > >>>> 
> > > > >>>> I don't see it. Please elaborate. 
> > > > >>>> 
> > > > >>>>> As well as the 'switch' keyword. 
> > > > >>>> 
> > > > >>>> What alternative do have in mind? if-else-if chains? 
> > > > >>>> Both more typing and intentions of using the same selection variable 
> > > > >>>> for all choices is not pronounced clearly. 
> > > > >>> I get the impression that you've missed his point. He's not arguing that 
> > > > >>> C would be made better by dropping all of those things. He's pointing 
> > > > >>> out that just because something is not necessary, is not a reason for 
> > > > >>> dropping it from the language. It is precisely his point that the 
> > > > >>> language would be less easy to use if these features were removed for no 
> > > > >>> better reason than the fact that they are unnecessary. 
> > > > >> I don't know about your or Juha, but I personally draw a line at DRY. 
> > > > >> Features that help to DRY can be controversial, can be even harmful, 
> > > > >> (as many preprocessor macros) but they are not nutrient-free syntactic 
> > > > >> sugar. 
> > > > >> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help 
> > > > >> DRY at all and only [] help it minimally, but [] obviously help other aspects 
> > > > >> of readability. 
> > > > >> C++ references do not help DRY at all, except if you consider & here 
> > > > >> or * there as repeating yourself. And, IMHO, presence of references 
> > > > >> in the language makes understanding somebody else's code 
> > > > >> significantly harder. 
> > > > > 
> > > > > Pointer can be null, so everywhere it is passed has to check that it is 
> > > > > not null and that gets quite repetitive to do after a while. 
> > > > 
> > > > Or, a lib writer can say passing a null pointer into function void* 
> > > > foo(void*) will result in undefined behavior. 
> > > So caller has to check, that is even worse violation of DRY as a function is 
> > > usually called from multiple places. Meanwhile lib writer can accept a 
> > > reference and then the check is needed on neither side. 
> > No, caller does not have to check, because caller knows that he passes non-null.
> About reference it is known that it is not null but about pointer it is known only 
> after checking ... like if the caller is he or she takes checking.

No. in code below caller does non need to check anything.
int bar;
foo(&bar);

[toc] | [prev] | [next] | [standalone]

#87477

On Sunday, 20 November 2022 at 01:51:19 UTC+2, Michael S wrote:
> On Sunday, November 20, 2022 at 1:43:28 AM UTC+2, Öö Tiib wrote: 
> > On Sunday, 20 November 2022 at 01:36:50 UTC+2, Michael S wrote: 
> > > On Sunday, November 20, 2022 at 1:33:16 AM UTC+2, Öö Tiib wrote: 
> > > > On Sunday, 20 November 2022 at 01:18:59 UTC+2, Chris M. Thomasson wrote: 
> > > > > On 11/19/2022 3:13 PM, Öö Tiib wrote: 
> > > > > > On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote: 
> > > > > >> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote: 
> > > > > >>> On 11/18/22 06:23, Michael S wrote: 
> > > > > >>>> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote: 
> > > > > >>> ... 
> > > > > >>>>> If we start dismissing everything that one could deem "unnecessary" 
> > > > > >>>>> then we could start dropping off quite many features even from C itself. 
> > > > > >>>>> After all, for example the syntax 'a[b]' is just syntactic sugar for 
> > > > > >>>>> '*(a+b)', and thus the former is "unnecessary" and could just be 
> > > > > >>>>> dropped off. 
> > > > > >>>> 
> > > > > >>>> The [] variant is shorter by 2 characters. In DRM view, shortness of 
> > > > > >>>> most frequently used language features was of high priority. 
> > > > > >>>> Also, in slightly more complex expressions, in case of *(a+b) variant 
> > > > > >>>> reader has to look for more information in order to figure out which 
> > > > > >>>> of two homonyms 
> > > > > >>>> of * is actually used. I would speculate that DRM was not really 
> > > > > >>>> pleased with 
> > > > > >>>> using asterisk for dereference, but had no better choice in available 
> > > > > >>>> character set. 
> > > > > >>>> 
> > > > > >>>> A 'for()' statement is unnecessary because you can write the same 
> > > > > >>>>> thing using a 'while()' statement. 
> > > > > >>>> 
> > > > > >>>> Except that 'continue' behave differently. 
> > > > > >>>> The better argument is that 'while' loops are unnecessary and that is 
> > > > > >>>> absolutely correct. A mistake on part of DRM. 
> > > > > >>>> 
> > > > > >>>>> And obviously the 'do' keyword is completely unnecessary. 
> > > > > >>>> 
> > > > > >>>> I don't see it. Please elaborate. 
> > > > > >>>> 
> > > > > >>>>> As well as the 'switch' keyword. 
> > > > > >>>> 
> > > > > >>>> What alternative do have in mind? if-else-if chains? 
> > > > > >>>> Both more typing and intentions of using the same selection variable 
> > > > > >>>> for all choices is not pronounced clearly. 
> > > > > >>> I get the impression that you've missed his point. He's not arguing that 
> > > > > >>> C would be made better by dropping all of those things. He's pointing 
> > > > > >>> out that just because something is not necessary, is not a reason for 
> > > > > >>> dropping it from the language. It is precisely his point that the 
> > > > > >>> language would be less easy to use if these features were removed for no 
> > > > > >>> better reason than the fact that they are unnecessary. 
> > > > > >> I don't know about your or Juha, but I personally draw a line at DRY. 
> > > > > >> Features that help to DRY can be controversial, can be even harmful, 
> > > > > >> (as many preprocessor macros) but they are not nutrient-free syntactic 
> > > > > >> sugar. 
> > > > > >> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help 
> > > > > >> DRY at all and only [] help it minimally, but [] obviously help other aspects 
> > > > > >> of readability. 
> > > > > >> C++ references do not help DRY at all, except if you consider & here 
> > > > > >> or * there as repeating yourself. And, IMHO, presence of references 
> > > > > >> in the language makes understanding somebody else's code 
> > > > > >> significantly harder. 
> > > > > > 
> > > > > > Pointer can be null, so everywhere it is passed has to check that it is 
> > > > > > not null and that gets quite repetitive to do after a while. 
> > > > > 
> > > > > Or, a lib writer can say passing a null pointer into function void* 
> > > > > foo(void*) will result in undefined behavior. 
> > > > So caller has to check, that is even worse violation of DRY as a function is 
> > > > usually called from multiple places. Meanwhile lib writer can accept a 
> > > > reference and then the check is needed on neither side. 
> > > No, caller does not have to check, because caller knows that he passes non-null. 
> > About reference it is known that it is not null but about pointer it is known only 
> > after checking ... like if the caller is he or she takes checking.
>
> No. in code below caller does non need to check anything. 
> int bar; 
> foo(&bar);

That function foo there is done weirdly. Why it wasn't done without using neither
pointer nor reference? Like:

int bar = foo(); 

[toc] | [prev] | [next] | [standalone]

#87480

On 11/19/2022 5:57 PM, Öö Tiib wrote:
> On Sunday, 20 November 2022 at 01:51:19 UTC+2, Michael S wrote:
>> On Sunday, November 20, 2022 at 1:43:28 AM UTC+2, Öö Tiib wrote:
>>> On Sunday, 20 November 2022 at 01:36:50 UTC+2, Michael S wrote:
>>>> On Sunday, November 20, 2022 at 1:33:16 AM UTC+2, Öö Tiib wrote:
>>>>> On Sunday, 20 November 2022 at 01:18:59 UTC+2, Chris M. Thomasson wrote:
>>>>>> On 11/19/2022 3:13 PM, Öö Tiib wrote:
>>>>>>> On Saturday, 19 November 2022 at 18:21:05 UTC+2, Michael S wrote:
>>>>>>>> On Saturday, November 19, 2022 at 9:34:32 AM UTC+2, james...@alumni.caltech.edu wrote:
>>>>>>>>> On 11/18/22 06:23, Michael S wrote:
>>>>>>>>>> On Friday, November 18, 2022 at 11:40:43 AM UTC+2, Juha Nieminen wrote:
>>>>>>>>> ...
>>>>>>>>>>> If we start dismissing everything that one could deem "unnecessary"
>>>>>>>>>>> then we could start dropping off quite many features even from C itself.
>>>>>>>>>>> After all, for example the syntax 'a[b]' is just syntactic sugar for
>>>>>>>>>>> '*(a+b)', and thus the former is "unnecessary" and could just be
>>>>>>>>>>> dropped off.
>>>>>>>>>>
>>>>>>>>>> The [] variant is shorter by 2 characters. In DRM view, shortness of
>>>>>>>>>> most frequently used language features was of high priority.
>>>>>>>>>> Also, in slightly more complex expressions, in case of *(a+b) variant
>>>>>>>>>> reader has to look for more information in order to figure out which
>>>>>>>>>> of two homonyms
>>>>>>>>>> of * is actually used. I would speculate that DRM was not really
>>>>>>>>>> pleased with
>>>>>>>>>> using asterisk for dereference, but had no better choice in available
>>>>>>>>>> character set.
>>>>>>>>>>
>>>>>>>>>> A 'for()' statement is unnecessary because you can write the same
>>>>>>>>>>> thing using a 'while()' statement.
>>>>>>>>>>
>>>>>>>>>> Except that 'continue' behave differently.
>>>>>>>>>> The better argument is that 'while' loops are unnecessary and that is
>>>>>>>>>> absolutely correct. A mistake on part of DRM.
>>>>>>>>>>
>>>>>>>>>>> And obviously the 'do' keyword is completely unnecessary.
>>>>>>>>>>
>>>>>>>>>> I don't see it. Please elaborate.
>>>>>>>>>>
>>>>>>>>>>> As well as the 'switch' keyword.
>>>>>>>>>>
>>>>>>>>>> What alternative do have in mind? if-else-if chains?
>>>>>>>>>> Both more typing and intentions of using the same selection variable
>>>>>>>>>> for all choices is not pronounced clearly.
>>>>>>>>> I get the impression that you've missed his point. He's not arguing that
>>>>>>>>> C would be made better by dropping all of those things. He's pointing
>>>>>>>>> out that just because something is not necessary, is not a reason for
>>>>>>>>> dropping it from the language. It is precisely his point that the
>>>>>>>>> language would be less easy to use if these features were removed for no
>>>>>>>>> better reason than the fact that they are unnecessary.
>>>>>>>> I don't know about your or Juha, but I personally draw a line at DRY.
>>>>>>>> Features that help to DRY can be controversial, can be even harmful,
>>>>>>>> (as many preprocessor macros) but they are not nutrient-free syntactic
>>>>>>>> sugar.
>>>>>>>> Of all features of 'C' listed by Juha, only 'while' and 'const' do not help
>>>>>>>> DRY at all and only [] help it minimally, but [] obviously help other aspects
>>>>>>>> of readability.
>>>>>>>> C++ references do not help DRY at all, except if you consider & here
>>>>>>>> or * there as repeating yourself. And, IMHO, presence of references
>>>>>>>> in the language makes understanding somebody else's code
>>>>>>>> significantly harder.
>>>>>>>
>>>>>>> Pointer can be null, so everywhere it is passed has to check that it is
>>>>>>> not null and that gets quite repetitive to do after a while.
>>>>>>
>>>>>> Or, a lib writer can say passing a null pointer into function void*
>>>>>> foo(void*) will result in undefined behavior.
>>>>> So caller has to check, that is even worse violation of DRY as a function is
>>>>> usually called from multiple places. Meanwhile lib writer can accept a
>>>>> reference and then the check is needed on neither side.
>>>> No, caller does not have to check, because caller knows that he passes non-null.
>>> About reference it is known that it is not null but about pointer it is known only
>>> after checking ... like if the caller is he or she takes checking.
>>
>> No. in code below caller does non need to check anything.
>> int bar;
>> foo(&bar);
> 
> That function foo there is done weirdly. Why it wasn't done without using neither
> pointer nor reference? Like:
> 
> int bar = foo();
> 
> 

Because foo takes a pointer to an int that _shall_ not be a nullptr.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web