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 2 of 2 — ← Prev page 1 [2]

#87485

On Sunday, 20 November 2022 at 05:56:28 UTC+2, Chris M. Thomasson wrote:
> 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.

I mean the int pointed at must be present but may be uninitialized so it is
lot more logical to have it as return value.

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

#87486

On Sunday, November 20, 2022 at 1:47:53 PM UTC+2, Öö Tiib wrote:
> On Sunday, 20 November 2022 at 05:56:28 UTC+2, Chris M. Thomasson wrote: 
> > 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.
> I mean the int pointed at must be present but may be uninitialized so it is 
> lot more logical to have it as return value.

This was an example intended to illustrate *one* point.
It was not an attempt to justify a passing of parameters by pointer/reference
vs other methods, but illustration of absence of material difference between 
pointer and reference in this case and of weakness of your argument about need
to check for null by caller.
Normally, you are well capable of critical thinking, but in this particular
case it seems like you copied argument from bad beginner's book without giving
it your own thought.

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

#87491

On Sunday, 20 November 2022 at 14:24:38 UTC+2, Michael S wrote:
> On Sunday, November 20, 2022 at 1:47:53 PM UTC+2, Öö Tiib wrote: 
> > On Sunday, 20 November 2022 at 05:56:28 UTC+2, Chris M. Thomasson wrote: 
> > > 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. 
> > I mean the int pointed at must be present but may be uninitialized so it is 
> > lot more logical to have it as return value.
> 
> This was an example intended to illustrate *one* point. 

It did not do that very well as it looked like badly designed interface.

> It was not an attempt to justify a passing of parameters by pointer/reference 
> vs other methods, but illustration of absence of material difference between 
> pointer and reference in this case and of weakness of your argument about need 
> to check for null by caller.

Where did I claim that there do not exist such circumstances where we know 
that some pointer can't be null? Reference communicates that situation better
and with less stars to type. Library whose documentation tells that lot of its
usages are undefined behavior is low quality library. 

The whole reason of languages like Rust winning is that in real application
every C++ module has to be maximally paranoid with explicit and very
repetitive code about shit feed to it. Otherwise app crashes in their module,
bug will be reported to them, and they have to analyze and explain to yet
another set of confused newbies that it was documented that the argument
should not be null. 

> Normally, you are well capable of critical thinking, but in this particular 
> case it seems like you copied argument from bad beginner's book without giving 
> it your own thought.

There are no point in your argument. I have not used any raw pointers in
C++ code for more than 15 years. There was no need to write code for
that as smart pointers, optional, variant and array were in boost already
at 2005. After C++11 there are even less theoretical corner cases where
there might be need for pointers. So my library interface just does not
have any raw pointer arguments and you have aired zero reason why it
has to change.

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

#87505

On 11/20/2022 6:32 AM, Öö Tiib wrote:
> On Sunday, 20 November 2022 at 14:24:38 UTC+2, Michael S wrote:
>> On Sunday, November 20, 2022 at 1:47:53 PM UTC+2, Öö Tiib wrote:
>>> On Sunday, 20 November 2022 at 05:56:28 UTC+2, Chris M. Thomasson wrote:
>>>> 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.
>>> I mean the int pointed at must be present but may be uninitialized so it is
>>> lot more logical to have it as return value.
>>
>> This was an example intended to illustrate *one* point.
> 
> It did not do that very well as it looked like badly designed interface.

A C API that requires a non-null pointer is not badly designed, right?


>> It was not an attempt to justify a passing of parameters by pointer/reference
>> vs other methods, but illustration of absence of material difference between
>> pointer and reference in this case and of weakness of your argument about need
>> to check for null by caller.
> 
> Where did I claim that there do not exist such circumstances where we know
> that some pointer can't be null? Reference communicates that situation better
> and with less stars to type.
^^^^^^^^^^^^^^^^^^^^^^^^^
[...]

Hard to disagree with this.

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

#87516

On Tuesday, 22 November 2022 at 02:32:25 UTC+2, Chris M. Thomasson wrote:
> On 11/20/2022 6:32 AM, Öö Tiib wrote: 
> > On Sunday, 20 November 2022 at 14:24:38 UTC+2, Michael S wrote: 
> >> On Sunday, November 20, 2022 at 1:47:53 PM UTC+2, Öö Tiib wrote: 
> >>> On Sunday, 20 November 2022 at 05:56:28 UTC+2, Chris M. Thomasson wrote: 
> >>>> 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. 
> >>> I mean the int pointed at must be present but may be uninitialized so it is 
> >>> lot more logical to have it as return value. 
> >> 
> >> This was an example intended to illustrate *one* point. 
> > 
> > It did not do that very well as it looked like badly designed interface.
> 
> A C API that requires a non-null pointer is not badly designed, right?

C API that requires non-null pointer arguments is perfectly fine. There are no
references in C. Passing things around by value is expensive but passing
nothing can be out of question. So the only solution is to have pointer
that may not be null. Also usages of void pointers or otherwise opaque
pointers and function pointers can be rather useful in C but are relatively
rare in C++.

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

#87469

On Sunday, November 20, 2022 at 1:13:37 AM UTC+2, Öö 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.

If you specified in the docs for your function that it can't take null
then you don't have to check for null.

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

#87470

20.11.2022 01:27 Michael S kirjutas:
> On Sunday, November 20, 2022 at 1:13:37 AM UTC+2, Öö Tiib wrote:
>> 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.
> 
> If you specified in the docs for your function that it can't take null
> then you don't have to check for null.

That's what a reference is for. It's self documenting.

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

#87446

18.11.2022 11:40 Juha Nieminen kirjutas:

> 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. 

It seems other people have agreed with this idea, resulting in things like:

while (*(bord+*(*contur-1)-upp)==ncus &&
   (*(*contur-1)-tper2<0 || *(*contur-1)-tper2>(ntpertper-1) ||
   *(bord+*(*contur-1)-tper2)!=ncus) &&
   *temporal!=*(*contur-1))
{
   *(*contur)=*(*contur-1)-upp;
   (*contur)++;
}

Unfortunately, these is a copy-paste from real code :-((

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

#87449

On 18/11/2022 14:51, Paavo Helde wrote:
> 18.11.2022 11:40 Juha Nieminen kirjutas:
> 
>> 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. 
> 
> It seems other people have agreed with this idea, resulting in things like:
> 
> while (*(bord+*(*contur-1)-upp)==ncus &&
>    (*(*contur-1)-tper2<0 || *(*contur-1)-tper2>(ntpertper-1) ||
>    *(bord+*(*contur-1)-tper2)!=ncus) &&
>    *temporal!=*(*contur-1))
> {
>    *(*contur)=*(*contur-1)-upp;
>    (*contur)++;
> }
> 
> Unfortunately, these is a copy-paste from real code :-((
> 
> 

  A lot of stars :)

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

#87501

Paavo Helde <eesnimi@osa.pri.ee> wrote:
> 18.11.2022 11:40 Juha Nieminen kirjutas:
> 
>> 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. 
> 
> It seems other people have agreed with this idea, resulting in things like:
> 
> while (*(bord+*(*contur-1)-upp)==ncus &&
>   (*(*contur-1)-tper2<0 || *(*contur-1)-tper2>(ntpertper-1) ||
>   *(bord+*(*contur-1)-tper2)!=ncus) &&
>   *temporal!=*(*contur-1))
> {
>   *(*contur)=*(*contur-1)-upp;
>   (*contur)++;
> }
> 
> Unfortunately, these is a copy-paste from real code :-((

I also like the lack of clarifying spaces, making the code even more
condensed and harder to read than it already is.

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

#87436

References are so simple that I don't understand why to write
such a long text about them.

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

#87462

On Thu, 2022-11-17, 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.

Especially since the beginners you're explaining things to should
learn about references long before they learn about pointers.  And
they don't always have a C background nowadays.

> A reference should be thought of as an "alias" for the original variable
> it's referencing.

s/variable/object/.  (Happily you use "object" in the rest of the text.)

[snip]

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#87502

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> A reference should be thought of as an "alias" for the original variable
>> it's referencing.
> 
> s/variable/object/.  (Happily you use "object" in the rest of the text.)

I was thinking of it more like "the name of the object is 'foo', and a
reference 'bar' would be an alias for that 'foo' object".

(But yes, references can also refer to unnamed temporary objects...)

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web