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

Groups > comp.lang.c > #74216 > unrolled thread

CAlive special use instance class, called an angel

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

Contents

  CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 18:18 -0700
    Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 18:23 -0700
    Re: CAlive special use instance class, called an angel Ian Collins <ian-news@hotmail.com> - 2015-10-30 14:27 +1300
      Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-29 19:18 -0700
        Re: CAlive special use instance class, called an angel Philip Lantz <prl@canterey.us> - 2015-10-29 22:29 -0700
          Re: CAlive special use instance class, called an angel Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-29 22:53 -0700
            Re: CAlive special use instance class, called an angel gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-30 08:40 +0000
              Re: CAlive special use instance class, called an angel Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-30 01:49 -0700
                Re: CAlive special use instance class, called an angel Richard Heathfield <rjh@cpax.org.uk> - 2015-10-30 09:15 +0000
                Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 05:37 -0700
                  Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-10-30 14:25 +0100
                    Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 06:35 -0700
                      Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-10-30 16:34 +0100
                        Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 08:44 -0700
                  Re: CAlive special use instance class, called an angel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 13:32 +0000
            Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 05:34 -0700
              Re: CAlive special use instance class, called an angel gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-30 13:13 +0000
                Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 06:25 -0700
              Re: CAlive special use instance class, called an angel Ian Collins <ian-news@hotmail.com> - 2015-10-31 11:03 +1300
                Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 15:17 -0700
                  Re: CAlive special use instance class, called an angel Ian Collins <ian-news@hotmail.com> - 2015-10-31 16:55 +1300
                    Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 21:13 -0700
                      Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 21:36 -0700
                        Re: CAlive special use instance class, called an angel Ian Collins <ian-news@hotmail.com> - 2015-10-31 17:44 +1300
                          Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 21:53 -0700
                            Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 21:57 -0700
                            Re: CAlive special use instance class, called an angel Ian Collins <ian-news@hotmail.com> - 2015-10-31 22:16 +1300
                              Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 09:50 -0700
                      Re: CAlive special use instance class, called an angel Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 01:52 -0700
                Re: CAlive special use instance class, called an angel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 22:44 +0000
                  Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 16:14 -0700
                    Re: CAlive special use instance class, called an angel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 01:03 +0000
                      Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 19:14 -0700
                        Re: CAlive special use instance class, called an angel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 11:56 +0000
                          Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 09:55 -0700
                            Re: CAlive special use instance class, called an angel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 20:17 +0000
                              Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 14:27 -0700
                                Re: CAlive special use instance class, called an angel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 22:38 +0000
                        Re: CAlive special use instance class, called an angel Richard Damon <Richard@Damon-Family.org> - 2015-10-31 10:44 -0400
                          Re: CAlive special use instance class, called an angel Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 12:16 -0700
                  Re: CAlive special use instance class, called an angel Ian Collins <ian-news@hotmail.com> - 2015-10-31 13:13 +1300
                  Re: CAlive special use instance class, called an angel James Kuyper <jameskuyper@verizon.net> - 2015-10-30 22:17 -0400
                    Re: CAlive special use instance class, called an angel James Kuyper <jameskuyper@verizon.net> - 2015-10-30 22:31 -0400
          Re: CAlive special use instance class, called an angel Philip Lantz <prl@canterey.us> - 2015-10-30 01:42 -0700
        Re: CAlive special use instance class, called an angel Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-30 09:38 +0000
          Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 04:35 -0700
            Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-10-30 14:10 +0100
              Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 06:21 -0700
                Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-10-30 16:43 +0100
                  Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 08:55 -0700
                    Re: CAlive special use instance class, called an angel Ian Collins <ian-news@hotmail.com> - 2015-10-31 11:09 +1300
                      Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 15:19 -0700
                    Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-11-01 00:47 +0100
                      Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-31 17:24 -0700
                        Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-11-01 23:39 +0100
                          Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 16:50 -0800
                            Re: CAlive special use instance class, called an angel Philip Lantz <prl@canterey.us> - 2015-11-01 23:22 -0800
                            Re: CAlive special use instance class, called an angel Bartc <bc@freeuk.com> - 2015-11-02 13:54 +0000
                              Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-02 06:23 -0800
                          Re: CAlive special use instance class, called an angel supercat@casperkitty.com - 2015-11-01 18:46 -0800
              Re: CAlive special use instance class, called an angel Bartc <bc@freeuk.com> - 2015-10-30 13:55 +0000
    Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-10-30 10:16 +0100
      Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 05:39 -0700
        Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-10-30 14:38 +0100
          Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 06:59 -0700
            Re: CAlive special use instance class, called an angel Bartc <bc@freeuk.com> - 2015-10-30 14:41 +0000
              Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 08:31 -0700
              Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 08:38 -0700
              Re: CAlive special use instance class, called an angel asetofsymbols@gmail.com - 2015-10-30 08:39 -0700
                Re: CAlive special use instance class, called an angel supercat@casperkitty.com - 2015-10-30 15:20 -0700
            Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-10-30 16:48 +0100
              Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-30 09:07 -0700
                Re: CAlive special use instance class, called an angel David Brown <david.brown@hesbynett.no> - 2015-11-01 14:53 +0100
                  Re: CAlive special use instance class, called an angel Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-01 06:12 -0800
                    Re: CAlive special use instance class, called an angel Bartc <bc@freeuk.com> - 2015-11-02 14:16 +0000
                  Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 06:25 -0800
                    CLC as a dating site (Was: CAlive special use instance class, called an angel) gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-01 14:33 +0000
                      Re: CLC as a dating site (Was: CAlive special use instance class, called an angel) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 06:45 -0800
                  Re: CAlive special use instance class, called an angel "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-01 07:53 -0800
                    Using CLC for crowdsourcing (Was: CAlive special use instance class, called an angel) gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-01 15:56 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#74396

Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 6:03:33 PM UTC-4, Ian Collins wrote:
>> Rick C. Hodgin wrote:
>>> On Friday, October 30, 2015 at 1:53:55 AM UTC-4, Malcolm McLean wrote:
>>
>>>
>>> I am in no way a C++ expert.  I could be wrong in my understanding
>>> of how things operate in C++.  I probably am wrong.
>>>
>>> In my use of angels, I am creating a specific thing which can be
>>> encapsulated behind its instance use name, giving it readable context
>>> and meaning in source code.
>>>
>>> The same angel could be used for different contexts.  If you created
>>> an angel to assemble a message to be passed, for example, then it
>>> might have a meaning when adding a warning to a computed value, or
>>> an error, or maybe it's just a note attached for the user to read
>>> indicating the size of the thing that was loaded, or how many seconds
>>> it took to process, etc.
>>>
>>> In each of these cases the angel instance names could be given as
>>> warning, error, note, time, etc., and then when used it would convey
>>> in code what the purpose of the instance use was.
>>
>> Which as others have shown can be done in C with a typedef and in in C++
>> with a typedef or "using".
>
> While C and C++ allow for alternatives, I don't want to use a typedef
> or a using.  It's unnecessary clutter.

Then you had better make sure that your syntax is unambiguous or you 
will end up with yet more confusion.

>>> -----
>>> With regards to C++:
>>>
>>> In my testing using MSVC and g++, when this is used the created
>>> instances of CWhatever in the calling function never have their
>>> destructor called unless they are explicitly deleted, which means
>>> variable name management.
>>
>> Off topic I know, but it is the weekend...
>>
>> In C++ the destructor is called when the object goes out of scope, which
>> appears to be what you wanted.
>
> The angels go out of scope after the expression they're used in.  I
> see that Malcom's C++ const example does that:
>
>      void something(CWhatever const &w1, CWhatever const &w2, CWhatever const &w3)
>
> ...but in my testing, it required changes to the way the accessor had
> to be written.  That may be a weakness in my understanding C++ syntax,
> however, though I currently believe it to be because they are declared
> const.

That's correct.  As I've said elsewhere it makes limited sense to pass a 
mutable copy of something that is about to be destroyed.

>>> The only cases I tested which do explicitly call their destructor
>>> are here:
>>>
>>>       CWhatever c1("c1"), c2("c2"), c3("c3");
>>>       whatever(&c1, &c2, &c3);
>>>
>>> But those destructors were not called until the function exited, and
>>> remained in scope from the point of their creation until the function
>>> exited.
>>>
>>>> Buy would wouldn't normally write a C++, as opposed to C, function
>>>> like that. If "something" doesn't modify the arguments, which,
>>>> since we're ignoring them after the call, is a reasonable guess,
>>>> normally it would be written,
>>>>
>>>> void something(CWhatever const &w1, CWhatever const &w2, CWhatever const &w3).
>>>>
>>>> We can now create the arguments as we call, but not using a name,
>>>> it needs to be
>>>>
>>>> something( CWhatever("1"), CWhatever("2"), CWhatever("3"))
>>>
>>> In my testing, this creates const instances of CWhatever which also
>>> required changes to the definition of some class member functions
>>> to make them suitable for const access.  This changes the nature of
>>> what can be done within the class.
>>
>> That is correct.  The temporary parameter objects scope is the function
>> call. They will not exist after the call son there is no point in trying
>> to modify them.
>
> That is the behavior of angels, but without const or & requirements, as
> all angels are passed as pointers.

So what happens if a function assigned one of these pointers to a global 
variable?

>>> And if you alter the behavior into something like this:
>>>
>>>       something( &CWhatever("1"), &CWhatever("2"), &CWhatever("3"));
>>>
>>> You need to use -fpermissive in g++ to access the address of the
>>> "temporary" variable it creates, and you actually need to use
>>> this form because the "1", "2", and "3" are interpreted as const
>>> char* by default:
>>
>> They (as string literals) are const char* by the language definition.
>>
>>>       something( &CWhatever((char*)"1"),
>>>                  &CWhatever((char*)"2"),
>>>                  &CWhatever((char*)"3")  );
>>>
>>> You could wrap it in this:
>>>
>>>       #define w(a) &CWhatever((char*)a)
>>>       something(w("1"), w("2"), w("3"));
>>>
>>> Now you have the same functionality as an angel.
>>
>> The same broken functionality.  It might help you to understand the rule
>> by considering a change in parameter type:
>>
>> void something( int const &w1 );
>>
>> something( 42 );
>>
>> Now would it make sense to be able to modify w1?
>
> That's my point... why would you want to use const &?

For the same reasons you would use const *: that you do not want to or 
are unable to modify the referenced object.

> It makes no
> sense.  The purpose of angels is to do real things classes can do,
> but to only have their limited lifespan, and to provide name reuse
> without separate instances being manually accounted for.

Which is what has been demonstrated with basic C++ classes.

> In my testing, I could not find a form like Malcom's const & form
> that also called the destructor immediately after creation while
> using a pointer.  If there is one, angels add no value there.  If
> there isn't one, then that's one of two things angels add for value.

That's correct because to do so would be unsafe.

-- 
Ian Collins

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

#74399

On Friday, October 30, 2015 at 11:55:17 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Friday, October 30, 2015 at 6:03:33 PM UTC-4, Ian Collins wrote:
> >> Rick C. Hodgin wrote:
> >>> On Friday, October 30, 2015 at 1:53:55 AM UTC-4, Malcolm McLean wrote:
> >>
> >>>
> >>> I am in no way a C++ expert.  I could be wrong in my understanding
> >>> of how things operate in C++.  I probably am wrong.
> >>>
> >>> In my use of angels, I am creating a specific thing which can be
> >>> encapsulated behind its instance use name, giving it readable context
> >>> and meaning in source code.
> >>>
> >>> The same angel could be used for different contexts.  If you created
> >>> an angel to assemble a message to be passed, for example, then it
> >>> might have a meaning when adding a warning to a computed value, or
> >>> an error, or maybe it's just a note attached for the user to read
> >>> indicating the size of the thing that was loaded, or how many seconds
> >>> it took to process, etc.
> >>>
> >>> In each of these cases the angel instance names could be given as
> >>> warning, error, note, time, etc., and then when used it would convey
> >>> in code what the purpose of the instance use was.
> >>
> >> Which as others have shown can be done in C with a typedef and in in C++
> >> with a typedef or "using".
> >
> > While C and C++ allow for alternatives, I don't want to use a typedef
> > or a using.  It's unnecessary clutter.
> 
> Then you had better make sure that your syntax is unambiguous or you 
> will end up with yet more confusion.
>
> >>> -----
> >>> With regards to C++:
> >>>
> >>> In my testing using MSVC and g++, when this is used the created
> >>> instances of CWhatever in the calling function never have their
> >>> destructor called unless they are explicitly deleted, which means
> >>> variable name management.
> >>
> >> Off topic I know, but it is the weekend...
> >>
> >> In C++ the destructor is called when the object goes out of scope, which
> >> appears to be what you wanted.
> >
> > The angels go out of scope after the expression they're used in.  I
> > see that Malcom's C++ const example does that:
> >
> >      void something(CWhatever const &w1, CWhatever const &w2, CWhatever const &w3)
> >
> > ...but in my testing, it required changes to the way the accessor had
> > to be written.  That may be a weakness in my understanding C++ syntax,
> > however, though I currently believe it to be because they are declared
> > const.
> 
> That's correct.  As I've said elsewhere it makes limited sense to pass a 
> mutable copy of something that is about to be destroyed.
> 
> >>> The only cases I tested which do explicitly call their destructor
> >>> are here:
> >>>
> >>>       CWhatever c1("c1"), c2("c2"), c3("c3");
> >>>       whatever(&c1, &c2, &c3);
> >>>
> >>> But those destructors were not called until the function exited, and
> >>> remained in scope from the point of their creation until the function
> >>> exited.
> >>>
> >>>> Buy would wouldn't normally write a C++, as opposed to C, function
> >>>> like that. If "something" doesn't modify the arguments, which,
> >>>> since we're ignoring them after the call, is a reasonable guess,
> >>>> normally it would be written,
> >>>>
> >>>> void something(CWhatever const &w1, CWhatever const &w2, CWhatever const &w3).
> >>>>
> >>>> We can now create the arguments as we call, but not using a name,
> >>>> it needs to be
> >>>>
> >>>> something( CWhatever("1"), CWhatever("2"), CWhatever("3"))
> >>>
> >>> In my testing, this creates const instances of CWhatever which also
> >>> required changes to the definition of some class member functions
> >>> to make them suitable for const access.  This changes the nature of
> >>> what can be done within the class.
> >>
> >> That is correct.  The temporary parameter objects scope is the function
> >> call. They will not exist after the call son there is no point in trying
> >> to modify them.
> >
> > That is the behavior of angels, but without const or & requirements, as
> > all angels are passed as pointers.
> 
> So what happens if a function assigned one of these pointers to a global 
> variable?

The global variable would be pointing to the angel, able to act on
it, but because angels go immediately out of scope once the expression
they were instantiated in is complete, the global variable would only
be pointing to live data so long as it's being accessed from called
code.  Upon returning to the original thing, the global variable would
be pointing to an instance of the angel class, but it would no longer
be valid, as by protocol, because its destructor would've been called.
However, it could still be used as an angel* and accessed ... it would
just be based on whatever the angel does in processing data to
determine if anything it would return would be valid or not.  If the
angel included a member function which takes a float, and returns the
float multiplied by 2.0f, and doesn't actually use any of its data,
then it would work properly.  But if you tried to access something
that's only live between the constructor and destructor, it would
signal an inquiry (a type of fault).

> >>> And if you alter the behavior into something like this:
> >>>
> >>>       something( &CWhatever("1"), &CWhatever("2"), &CWhatever("3"));
> >>>
> >>> You need to use -fpermissive in g++ to access the address of the
> >>> "temporary" variable it creates, and you actually need to use
> >>> this form because the "1", "2", and "3" are interpreted as const
> >>> char* by default:
> >>
> >> They (as string literals) are const char* by the language definition.
> >>
> >>>       something( &CWhatever((char*)"1"),
> >>>                  &CWhatever((char*)"2"),
> >>>                  &CWhatever((char*)"3")  );
> >>>
> >>> You could wrap it in this:
> >>>
> >>>       #define w(a) &CWhatever((char*)a)
> >>>       something(w("1"), w("2"), w("3"));
> >>>
> >>> Now you have the same functionality as an angel.
> >>
> >> The same broken functionality.  It might help you to understand the rule
> >> by considering a change in parameter type:
> >>
> >> void something( int const &w1 );
> >>
> >> something( 42 );
> >>
> >> Now would it make sense to be able to modify w1?
> >
> > That's my point... why would you want to use const &?
> 
> For the same reasons you would use const *: that you do not want to or 
> are unable to modify the referenced object.

I might want to alter the angel.  Perhaps I'm passing it to something
which will augment it with additional information, to pass it on to
another thing which does the same, and so on, until finally it goes
to its ultimate destination with the full call stack, for example.

> > It makes no
> > sense.  The purpose of angels is to do real things classes can do,
> > but to only have their limited lifespan, and to provide name reuse
> > without separate instances being manually accounted for.
> 
> Which is what has been demonstrated with basic C++ classes.

Through obtuse syntax and const constraints, yes.

> > In my testing, I could not find a form like Malcom's const & form
> > that also called the destructor immediately after creation while
> > using a pointer.  If there is one, angels add no value there.  If
> > there isn't one, then that's one of two things angels add for value.
> 
> That's correct because to do so would be unsafe.

Unsafe is a peculiar thing because it's legal to create a new, and
then delete after a one-line use, and because I, the developer,
explicitly carried out the delete ... then all is good.  That's
great, but it is implied with angels that they do the same thing
but without the mechanical requirement of physically doing it.  It's
all handled for you (which is why it's desirable).

Best regards,
Rick C. Hodgin

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

#74400

On Saturday, October 31, 2015 at 12:14:13 AM UTC-4, Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 11:55:17 PM UTC-4, Ian Collins wrote:
> > Rick C. Hodgin wrote:
> > > On Friday, October 30, 2015 at 6:03:33 PM UTC-4, Ian Collins wrote:
> > >> Rick C. Hodgin wrote:
> > >>> On Friday, October 30, 2015 at 1:53:55 AM UTC-4, Malcolm McLean wrote:
> > >>
> > >>>
> > >>> I am in no way a C++ expert.  I could be wrong in my understanding
> > >>> of how things operate in C++.  I probably am wrong.
> > >>>
> > >>> In my use of angels, I am creating a specific thing which can be
> > >>> encapsulated behind its instance use name, giving it readable context
> > >>> and meaning in source code.
> > >>>
> > >>> The same angel could be used for different contexts.  If you created
> > >>> an angel to assemble a message to be passed, for example, then it
> > >>> might have a meaning when adding a warning to a computed value, or
> > >>> an error, or maybe it's just a note attached for the user to read
> > >>> indicating the size of the thing that was loaded, or how many seconds
> > >>> it took to process, etc.
> > >>>
> > >>> In each of these cases the angel instance names could be given as
> > >>> warning, error, note, time, etc., and then when used it would convey
> > >>> in code what the purpose of the instance use was.
> > >>
> > >> Which as others have shown can be done in C with a typedef and in in C++
> > >> with a typedef or "using".
> > >
> > > While C and C++ allow for alternatives, I don't want to use a typedef
> > > or a using.  It's unnecessary clutter.
> > 
> > Then you had better make sure that your syntax is unambiguous or you 
> > will end up with yet more confusion.
> >
> > >>> -----
> > >>> With regards to C++:
> > >>>
> > >>> In my testing using MSVC and g++, when this is used the created
> > >>> instances of CWhatever in the calling function never have their
> > >>> destructor called unless they are explicitly deleted, which means
> > >>> variable name management.
> > >>
> > >> Off topic I know, but it is the weekend...
> > >>
> > >> In C++ the destructor is called when the object goes out of scope, which
> > >> appears to be what you wanted.
> > >
> > > The angels go out of scope after the expression they're used in.  I
> > > see that Malcom's C++ const example does that:
> > >
> > >      void something(CWhatever const &w1, CWhatever const &w2, CWhatever const &w3)
> > >
> > > ...but in my testing, it required changes to the way the accessor had
> > > to be written.  That may be a weakness in my understanding C++ syntax,
> > > however, though I currently believe it to be because they are declared
> > > const.
> > 
> > That's correct.  As I've said elsewhere it makes limited sense to pass a 
> > mutable copy of something that is about to be destroyed.
> > 
> > >>> The only cases I tested which do explicitly call their destructor
> > >>> are here:
> > >>>
> > >>>       CWhatever c1("c1"), c2("c2"), c3("c3");
> > >>>       whatever(&c1, &c2, &c3);
> > >>>
> > >>> But those destructors were not called until the function exited, and
> > >>> remained in scope from the point of their creation until the function
> > >>> exited.
> > >>>
> > >>>> Buy would wouldn't normally write a C++, as opposed to C, function
> > >>>> like that. If "something" doesn't modify the arguments, which,
> > >>>> since we're ignoring them after the call, is a reasonable guess,
> > >>>> normally it would be written,
> > >>>>
> > >>>> void something(CWhatever const &w1, CWhatever const &w2, CWhatever const &w3).
> > >>>>
> > >>>> We can now create the arguments as we call, but not using a name,
> > >>>> it needs to be
> > >>>>
> > >>>> something( CWhatever("1"), CWhatever("2"), CWhatever("3"))
> > >>>
> > >>> In my testing, this creates const instances of CWhatever which also
> > >>> required changes to the definition of some class member functions
> > >>> to make them suitable for const access.  This changes the nature of
> > >>> what can be done within the class.
> > >>
> > >> That is correct.  The temporary parameter objects scope is the function
> > >> call. They will not exist after the call son there is no point in trying
> > >> to modify them.
> > >
> > > That is the behavior of angels, but without const or & requirements, as
> > > all angels are passed as pointers.
> > 
> > So what happens if a function assigned one of these pointers to a global 
> > variable?
> 
> The global variable would be pointing to the angel, able to act on
> it, but because angels go immediately out of scope once the expression
> they were instantiated in is complete, the global variable would only
> be pointing to live data so long as it's being accessed from called
> code.  Upon returning to the original thing, the global variable would
> be pointing to an instance of the angel class, but it would no longer
> be valid, as by protocol, because its destructor would've been called.
> However, it could still be used as an angel* and accessed ... it would
> just be based on whatever the angel does in processing data to
> determine if anything it would return would be valid or not.  If the
> angel included a member function which takes a float, and returns the
> float multiplied by 2.0f, and doesn't actually use any of its data,
> then it would work properly.  But if you tried to access something
> that's only live between the constructor and destructor, it would
> signal an inquiry (a type of fault).

I just tested this in GCC using this simple class, and it behaved
the same way I describe here.  A member function on the deleted class
name which did not access member data worked properly, but access
to its member data signaled a fault.

    #include <stdio.h>

    class CAbc
    {
    public:
        CAbc(const char* p)     { m_p = p; }
        ~CAbc()                 {  }
        const char* g()         { return(m_p); }
        int         mul(int i)  { return(i*2); }

    private:
        const char* m_p;
    };

    CAbc* abc;

    int main(int argc, char **argv)
    {
        abc = new CAbc("test");
        delete abc;
    
        printf("%d\n", abc->mul(2));
FAULT=> printf("%s\n", abc->g());
    
        return 0;
    }

Best regards,
Rick C. Hodgin

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

#74401

Rick C. Hodgin wrote:
>
> I just tested this in GCC using this simple class, and it behaved
> the same way I describe here.  A member function on the deleted class
> name which did not access member data worked properly, but access
> to its member data signaled a fault.

Undefined behaviour can do that, or anything else....

-- 
Ian Collins

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

#74403

On Saturday, October 31, 2015 at 12:44:48 AM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> >
> > I just tested this in GCC using this simple class, and it behaved
> > the same way I describe here.  A member function on the deleted class
> > name which did not access member data worked properly, but access
> > to its member data signaled a fault.
> 
> Undefined behaviour can do that, or anything else....

Would it be worth adding a flag to the class, angel, or struct, which
pads a byte to the data block which indicates if it's operating between
constructor and destructor?  And when in use, accesses can check that
byte explicitly to see if the thing's still in scope (by protocol) or
not.

Best regards,
Rick C. Hodgin

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

#74404

On Saturday, October 31, 2015 at 12:53:46 AM UTC-4, Rick C. Hodgin wrote:
> On Saturday, October 31, 2015 at 12:44:48 AM UTC-4, Ian Collins wrote:
> > Rick C. Hodgin wrote:
> > >
> > > I just tested this in GCC using this simple class, and it behaved
> > > the same way I describe here.  A member function on the deleted class
> > > name which did not access member data worked properly, but access
> > > to its member data signaled a fault.
> > 
> > Undefined behaviour can do that, or anything else....
> 
> Would it be worth adding a flag to the class, angel, or struct, which
> pads a byte to the data block which indicates if it's operating between
> constructor and destructor?  And when in use, accesses can check that
> byte explicitly to see if the thing's still in scope (by protocol) or
> not.

I've actually wanted to add managed data to CAlive.  I think such a
feature would be better applied in that context, and not in general.

Best regards,
Rick C. Hodgin

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

#74414

Rick C. Hodgin wrote:
> On Saturday, October 31, 2015 at 12:44:48 AM UTC-4, Ian Collins wrote:
>> Rick C. Hodgin wrote:
>>>
>>> I just tested this in GCC using this simple class, and it behaved
>>> the same way I describe here.  A member function on the deleted class
>>> name which did not access member data worked properly, but access
>>> to its member data signaled a fault.
>>
>> Undefined behaviour can do that, or anything else....
>
> Would it be worth adding a flag to the class, angel, or struct, which
> pads a byte to the data block which indicates if it's operating between
> constructor and destructor?

No because once it has been freed, anything can be written over the 
memory it once occupied.

-- 
Ian Collins

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

#74447

On Saturday, October 31, 2015 at 5:16:52 AM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Saturday, October 31, 2015 at 12:44:48 AM UTC-4, Ian Collins wrote:
> >> Rick C. Hodgin wrote:
> >>>
> >>> I just tested this in GCC using this simple class, and it behaved
> >>> the same way I describe here.  A member function on the deleted class
> >>> name which did not access member data worked properly, but access
> >>> to its member data signaled a fault.
> >>
> >> Undefined behaviour can do that, or anything else....
> >
> > Would it be worth adding a flag to the class, angel, or struct, which
> > pads a byte to the data block which indicates if it's operating between
> > constructor and destructor?
> 
> No because once it has been freed, anything can be written over the 
> memory it once occupied.

That's why I want to implement it in managed memory, because in such
a framework, the implementation of the thing can and must take on
decoration beyond mere definition.

Best regards,
Rick C. Hodgin

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

#74413

On Saturday, October 31, 2015 at 4:14:13 AM UTC, Rick C. Hodgin wrote:
>
> The global variable would be pointing to the angel, able to act on
> it, but because angels go immediately out of scope once the expression
> they were instantiated in is complete, the global variable would only
> be pointing to live data so long as it's being accessed from called
> code.  Upon returning to the original thing, the global variable would
> be pointing to an instance of the angel class, but it would no longer
> be valid, as by protocol, because its destructor would've been called.
> However, it could still be used as an angel* and accessed ... it would
> just be based on whatever the angel does in processing data to
> determine if anything it would return would be valid or not.  If the
> angel included a member function which takes a float, and returns the
> float multiplied by 2.0f, and doesn't actually use any of its data,
> then it would work properly.  But if you tried to access something
> that's only live between the constructor and destructor, it would
> signal an inquiry (a type of fault).
> 
[why angels are not const &s]
> I might want to alter the angel.  Perhaps I'm passing it to something
> which will augment it with additional information, to pass it on to
> another thing which does the same, and so on, until finally it goes
> to its ultimate destination with the full call stack, for example.
> 
> Unsafe is a peculiar thing because it's legal to create a new, and
> then delete after a one-line use, and because I, the developer,
> explicitly carried out the delete ... then all is good.  That's
> great, but it is implied with angels that they do the same thing
> but without the mechanical requirement of physically doing it.  It's
> all handled for you (which is why it's desirable).
> 
So there are some differences. An angel can be global, and still
have it destructor called. In fact the destructor is guaranteed to 
be called after execution from the line on which it is instantiated,
unlike C++, where the destructor will be called when the compiler
feel like it. it's also slightly easier to pass a non-const object
created at call time. So we can do 

// Workspace for low level functions call by foo 
Angel_Workspace  workspace
foo(workspace);
// workspace now destroyed


Rather than

Cpp_Workspace *wk_ptr = new Cpp_Workspace();
foo(wk_ptr);
delete wk_ptr;
wk_ptr = 0;

which is disapproved C++ - new and delete are almost deprecated now,
except for container implementations themselves.
 
I don't really see that the advantage is large enough to justify
a new syntactical feature, however.

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

#74378

Ian Collins <ian-news@hotmail.com> writes:
<snip>
> Off topic I know, but it is the weekend...
>
> In C++ the destructor is called when the object goes out of scope,

That's not really true.  It's a common shorthand (I've probably said it
myself) but it's wrong in two ways.  First objects don't have scope --
only names have scope.  There are objects that come and go without
names, and there are names with scope that don't name objects.  Second,
a named object's destructor is called when control passes the end of the
scope.  Names (of objects) go out of scope all the time without the
destructor firing -- when a function is called, for example.

Even this is a bit of a simplification because of gotos and exceptions
(in C++) but there's probably not much to gain by going further.

I am sure you know all this, and I am also sure that pointing it out
will not really help, but "objects going out of scope" is, to me, like
"I regularly go to the pub" and "there's a finite chance it will happen"
-- something I find it almost impossible to avoid remarking on!

<snip>
-- 
Ben.

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

#74381

On Friday, October 30, 2015 at 6:45:05 PM UTC-4, Ben Bacarisse wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> <snip>
> > Off topic I know, but it is the weekend...
> >
> > In C++ the destructor is called when the object goes out of scope,
> 
> That's not really true.  It's a common shorthand (I've probably said it
> myself) but it's wrong in two ways.  First objects don't have scope --
> only names have scope.

In CAlive, objects have scope.  And the names used to access them are
just references to their existence.  Names may come and go, but the
object will be instantiated, and later de-instantiated, causing it
to then go out of scope, even if the names remain, or come and go as
well.

Best regards,
Rick C. Hodgin

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

#74385

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Friday, October 30, 2015 at 6:45:05 PM UTC-4, Ben Bacarisse wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>> <snip>
>> > Off topic I know, but it is the weekend...
>> >
>> > In C++ the destructor is called when the object goes out of scope,
>> 
>> That's not really true.  It's a common shorthand (I've probably said it
>> myself) but it's wrong in two ways.  First objects don't have scope --
>> only names have scope.
>
> In CAlive, objects have scope.

That's your prerogative.  But CAlive's names also have a normal-sense
scope, and it's objects also have a normal-sense lifetime.  Giving
objects are Rick-sense scope is just make-work for you when you come to
explain the language.

<snip>
-- 
Ben.

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

#74387

On Friday, October 30, 2015 at 9:03:41 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Friday, October 30, 2015 at 6:45:05 PM UTC-4, Ben Bacarisse wrote:
> >> Ian Collins <ian-news@hotmail.com> writes:
> >> <snip>
> >> > Off topic I know, but it is the weekend...
> >> >
> >> > In C++ the destructor is called when the object goes out of scope,
> >> 
> >> That's not really true.  It's a common shorthand (I've probably said it
> >> myself) but it's wrong in two ways.  First objects don't have scope --
> >> only names have scope.
> >
> > In CAlive, objects have scope.
> 
> That's your prerogative.  But CAlive's names also have a normal-sense
> scope, and it's objects also have a normal-sense lifetime.

What's the difference between scope and lifetime?  Names have a
scope, which is also their lifetime.  Objects have a scope, which
is also their lifetime.  And names applied to objects do not always
have the same scope, and therefore, don't always have the same
lifetime.

Fundamentally, I don't see how there is any difference between scope
and lifetime.  And object's lifetime is its scope.  A name's lifetime
is its scope.  But the two are not directly connected, unless they are
connected by protocol, and that protocol also has a scope, which is
its lifetime.

> Giving
> objects are Rick-sense scope is just make-work for you when you come to
> explain the language.

I would explain it in the way I've tried to explain to you in the past
about what data is fundamentally, and not just how it is to C.

When I have this:

    union {
        float*  f;
        int*    i;
        double* d;
    };

And I assign a vlaue to f, i, or d, what I'm doing is putting an
address in the shared pointer, which points to some location in
memory.  That location is then accessed through the protocol of
the thing I'm using to examine it.  It is a lens to view the data
in that way.  Switching to another member means looking at the
same location in memory, the same exact bits, with the new lens.

It is the same for access to data in objects or angels (and also
arguably structs).  They each have a protocol which sits atop
their data for manipulation.  That protocol is an enforcement of
certain rules which must be carried out to alter the data, so
that it is altered in an expected way.  But fundamentally, there
is a block of data in memory of a certain size which is the most
fundamental thing involved.  And were a pointer to that block of
data passed to some other form, the data that's there could
simply be updated by that other protocol, regardless of whether
or not it's valid for its original protocol.

Data is just that:  data.  It is not some magical thing.  It is
a finite and discrete quantity capable of being acted upon by
whatever compute resources are available, and in the context of
a CAlive compiler, that will mean at least x86, ARM, and prayerfully
eventually my own LibSF 386-x40 CPU, and each of those have some
fundamental abilities which are to be relied upon ... not the least
of which is data can be acted on fairly universally, and it is only
the constraints of the language, and the protocols conveyed through
program instructions, which prevent it from being acted upon
differently.

But still at the heart of it all ... it's just data.  And that data
will be instantiated at some point, and then later de-instantiated
by whatever protocol/means is applied to de-instantiate it, which
will then take it out of scope, and end its lifetime.  And atop
that fundamental nature of data's manipulation, the peculiarities
of the language feed into the computer program which instructs the
CPU how to process it... and those protocol are whatever they are,
but they are ultimately removed completely from the data because
even if all of them were to go away in mid-processing, the data
will still reside as it was setup up until that point.  And even if
those protocols never come back (because the program was shutdown
in some way), the data would still persist there until the machine
state alters it in some way (OS wipes that memory, assigns it to
another process, the power is lost, whatever).

-----
Data is what we're manipulating.  The language describes the way
in which we manipulate it.  The peculiarities of a language give
it its protocol for access, and its forward-facing form to the
developer.

My goals with CAlive are to give the developer a better coding
experience, and to recognize that under the hood, data is the name
of the game:  how to access it and alter it.  The rest is just the
mechanics of needs of the ways and means which make it happen, and
whereas that part is very important, none of it would matter one
iota without the underlying thing being acted upon:  data.

Data rules the computing world.  And the things we design need to
be able to access that data in fundamental ways.  And the tools we
design need to view things in fundamental ways which are limited
only by the protocols we the developers enforce and establish
through the tools we use, and those tools should not artificially
apply limits against us, the developers, by the mechanics of the
language, not toward expressions of thought, or of machine-legal
operations on data.

CAlive seeks to look at things fundamentally, and grow everything
up from there.  Some of it will undoubtedly be altered over time.
But for the first crack at it, it's look to have a fairly solid
base, albeit perhaps a non-standard one when compared to existing
languages.  But, I'd argue that, barring something catastrophic
happening, it won't be too many years from now until CAlive has
become the dominant language world-wide, and then people will be
comparing the way languages like C and C++ operate when compared
to CAlive, noting their unusual quirks as oddities, rather than
the other way around.  What?  What's that?  Oh, sorry, mom.  I'm
getting up.  I'll be ready for school in just a few minutes.

You see... I was dreaming a little bit there at the end.

Best regards,
Rick C. Hodgin

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

#74424

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Friday, October 30, 2015 at 9:03:41 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Friday, October 30, 2015 at 6:45:05 PM UTC-4, Ben Bacarisse wrote:
>> >> Ian Collins <ian-news@hotmail.com> writes:
>> >> <snip>
>> >> > Off topic I know, but it is the weekend...
>> >> >
>> >> > In C++ the destructor is called when the object goes out of scope,
>> >> 
>> >> That's not really true.  It's a common shorthand (I've probably said it
>> >> myself) but it's wrong in two ways.  First objects don't have scope --
>> >> only names have scope.
>> >
>> > In CAlive, objects have scope.
>> 
>> That's your prerogative.  But CAlive's names also have a normal-sense
>> scope, and it's objects also have a normal-sense lifetime.
>
> What's the difference between scope and lifetime?

Why are you asking me?  It's very easy to find out from the web and you
are much more likely to believe what you read there than anything I
might write.

> Names have a
> scope, which is also their lifetime.  Objects have a scope, which
> is also their lifetime.

That's Humpty Dumpty language -- you're making words mean what you want
them to mean rather than accepting that they already mean something else
to other people.  It's very likely that CAlive can be explained using
the usual meanings of scope and lifetime, so there isn't any need to
re-purpose the terms.

<snip>
-- 
Ben.

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

#74448

On Saturday, October 31, 2015 at 7:56:56 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Friday, October 30, 2015 at 9:03:41 PM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> 
> >> > On Friday, October 30, 2015 at 6:45:05 PM UTC-4, Ben Bacarisse wrote:
> >> >> Ian Collins <ian-news@hotmail.com> writes:
> >> >> <snip>
> >> >> > Off topic I know, but it is the weekend...
> >> >> >
> >> >> > In C++ the destructor is called when the object goes out of scope,
> >> >> 
> >> >> That's not really true.  It's a common shorthand (I've probably said it
> >> >> myself) but it's wrong in two ways.  First objects don't have scope --
> >> >> only names have scope.
> >> >
> >> > In CAlive, objects have scope.
> >> 
> >> That's your prerogative.  But CAlive's names also have a normal-sense
> >> scope, and it's objects also have a normal-sense lifetime.
> >
> > What's the difference between scope and lifetime?
> 
> Why are you asking me?  It's very easy to find out from the web and you
> are much more likely to believe what you read there than anything I
> might write.

I looked it up before I asked.  And whereas I recognize what the formal
definitions are, I don't think they're truly fundamentally isolated or
connected, except as by established protocol.  I think fundamentally
they are different than is commonly applied.

> > Names have a
> > scope, which is also their lifetime.  Objects have a scope, which
> > is also their lifetime.
> 
> That's Humpty Dumpty language -- you're making words mean what you want
> them to mean rather than accepting that they already mean something else
> to other people.  It's very likely that CAlive can be explained using
> the usual meanings of scope and lifetime, so there isn't any need to
> re-purpose the terms.

You're now a member in a club:

    http://gimpforums.com/thread-another-term-for-anti-alias-floan

...of people who have accused me of making up words, or forcing them
to mean whatever I say, instead of what is already standard.

I look at things from fundamentals.  I design and build everything
from there.  In the area of CAlive, I give a nod to my existing code
base written in C/C++, so I can continue on.  But, eventually, I
will migrate everything to CAlive (Lord willing), and when I do, it
will no longer be backward compatible with C/C++, except through
a hard translation mechanism, which I'll probably incorporate anyway
at some point as I desire to have a C-source code back-end to my RDC
framework as well, one which generates compatible and compileable C
code from its intermediate language.

Best regards,
Rick C. Hodgin

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

#74484

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Saturday, October 31, 2015 at 7:56:56 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Friday, October 30, 2015 at 9:03:41 PM UTC-4, Ben Bacarisse wrote:
>> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >> 
>> >> > On Friday, October 30, 2015 at 6:45:05 PM UTC-4, Ben Bacarisse wrote:
>> >> >> Ian Collins <ian-news@hotmail.com> writes:
>> >> >> <snip>
>> >> >> > Off topic I know, but it is the weekend...
>> >> >> >
>> >> >> > In C++ the destructor is called when the object goes out of scope,
>> >> >> 
>> >> >> That's not really true.  It's a common shorthand (I've probably said it
>> >> >> myself) but it's wrong in two ways.  First objects don't have scope --
>> >> >> only names have scope.
>> >> >
>> >> > In CAlive, objects have scope.
>> >> 
>> >> That's your prerogative.  But CAlive's names also have a normal-sense
>> >> scope, and it's objects also have a normal-sense lifetime.
>> >
>> > What's the difference between scope and lifetime?
>> 
>> Why are you asking me?  It's very easy to find out from the web and you
>> are much more likely to believe what you read there than anything I
>> might write.
>
> I looked it up before I asked.  And whereas I recognize what the formal
> definitions are, I don't think they're truly fundamentally isolated or
> connected, except as by established protocol.  I think fundamentally
> they are different than is commonly applied.

I'm having trouble understanding that.  I think it means that you have
understood these terms in a fundamental way that has eluded the rest of
us.  Let's take that as a working assumption...  You can't educate me to
the true nature of scope and lifetime simply by using the words in a way
that looks incorrect to people who have not had your insight.

(However, please don't try.)

<snip>
-- 
Ben.

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

#74499

On Saturday, October 31, 2015 at 4:18:06 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Saturday, October 31, 2015 at 7:56:56 AM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> 
> >> > On Friday, October 30, 2015 at 9:03:41 PM UTC-4, Ben Bacarisse wrote:
> >> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >> >> 
> >> >> > On Friday, October 30, 2015 at 6:45:05 PM UTC-4, Ben Bacarisse wrote:
> >> >> >> Ian Collins <ian-news@hotmail.com> writes:
> >> >> >> <snip>
> >> >> >> > Off topic I know, but it is the weekend...
> >> >> >> >
> >> >> >> > In C++ the destructor is called when the object goes out of scope,
> >> >> >> 
> >> >> >> That's not really true.  It's a common shorthand (I've probably said it
> >> >> >> myself) but it's wrong in two ways.  First objects don't have scope --
> >> >> >> only names have scope.
> >> >> >
> >> >> > In CAlive, objects have scope.
> >> >> 
> >> >> That's your prerogative.  But CAlive's names also have a normal-sense
> >> >> scope, and it's objects also have a normal-sense lifetime.
> >> >
> >> > What's the difference between scope and lifetime?
> >> 
> >> Why are you asking me?  It's very easy to find out from the web and you
> >> are much more likely to believe what you read there than anything I
> >> might write.
> >
> > I looked it up before I asked.  And whereas I recognize what the formal
> > definitions are, I don't think they're truly fundamentally isolated or
> > connected, except as by established protocol.  I think fundamentally
> > they are different than is commonly applied.
> 
> I'm having trouble understanding that.

Hmmm....

> I think it means that you have
> understood these terms in a fundamental way that has eluded the rest of
> us.

Well... I recognize what a scope is.  I recognize what a lifetime is.
And to my thinking, they are the same.  Here's why:

The only thing that makes a name scope and an object scope have anything
in common is the protocol with which they interact, and that protocol is
governed by the peculiarities of the programming language in our case,
and that protocol also has a scope/lifetime of its own.

In short:  There's a three-way triangle at work, and a three-way
           relationship involved:  name, object, protocol.  Each of
           these triangle corners are truly their own independent
           entity, and only occasionally do they interact in a common
           way, which is what's introducing the confusion that exists
           today as to why a scope and a lifetime can be different.

Consider:

Only when the three are viewed together can there some common scope and
lifetime which is then derived from the overlap of those of the individual
and fundamental components (the corners).  Yet in all ways that view is
not a truly fundamental way to look at what's happening there.  It's a
combined way, a language way, one that doesn't reflect the important
component:  the state of the underlying data, which truly is fundamental.

-----
It is fundamental to look at the name as having a scope all its own, which
is also its lifetime.  It is fundamental to look at the object having a
scope all its own, which is its lifetime.  And it's fundamental to look at
the protocol involved which connects the other two together (the time
inside a function, for example, where the two CAN (but don't always)
relate) as having a scope all its own.

It is not fundamental to use the correlation of the three to arrive at any
kind of varying definition as to what a scope and lifetime is because each
of those fundamental components is wholly resolved on its own.  What's
being attempted in viewing the three simultaneously in a non-fundamental
correlation, an application of an algorithm or mechanism, one applied atop
the fundamental components, and one which yields something which is not
truly fundamental, but results in the confusion we see in the two having
separate definitions.

> Let's take that as a working assumption...  You can't educate me to
> the true nature of scope and lifetime simply by using the words in a way
> that looks incorrect to people who have not had your insight.
> 
> (However, please don't try.)

Here's my view on the matter:  If you don't want a reply, then don't post
something for people to reply to.  Not all of the replies you'll receive
to your posts are written for you.  Some of them are designed to clear the
matter up for those who might truly be interested in reaching a resolution.

Best regards,
Rick C. Hodgin

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

#74503

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> Well... I recognize what a scope is.  I recognize what a lifetime is.
> And to my thinking, they are the same.  Here's why:

And here's why they are different: scope is a spacial property of a
name.  It simply determines where a name may be used.  Lifetime is a
temporal property of an object (at least in C) -- an object's lifetime
has a start time and an end time.  A name's scope is a portion of the
program text.  You can use a highlighter to mark up the scope of a name
in a point out of the program text.  You can mark up the lifetime of an
object on a time-line.  They are entirely different categories of thing.

You can confuse matters by co-mingling the ideas (since they are
connected in many cases) but it won't add clarity of talk about the
scope of an object or the lifetime of a name.

<snip>
-- 
Ben.

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

#74433

On 10/30/15 10:14 PM, Rick C. Hodgin wrote:
> What's the difference between scope and lifetime?  Names have a
> scope, which is also their lifetime.  Objects have a scope, which
> is also their lifetime.  And names applied to objects do not always
> have the same scope, and therefore, don't always have the same
> lifetime.
>

Fundamentally, Scope is 'positional' and Lifetime it 'Temporal'.

Scope is a 'Source Code' property, it applies to 'Names', while Lifetime 
is an 'Execution Time' property, it applies to 'objects'.

> Fundamentally, I don't see how there is any difference between scope
> and lifetime.  And object's lifetime is its scope.  A name's lifetime
> is its scope.  But the two are not directly connected, unless they are
> connected by protocol, and that protocol also has a scope, which is
> its lifetime.
>
> Best regards,
> Rick C. Hodgin
>

Here is an example that perhaps you can understand. Let us take the 
Bible, You (and others here) believe it is a Historical Document 
describing things that have (and will) be (others will disagree, but 
that really isn't the point here).

In Genesis, there is the name 'Adam', referring to the 'First Man'. If 
we are in the scope of a Biblical discussion, we can use 'Adam' to refer 
to this object, and talk a lot about it. The NAME 'Adam' can still be in 
scope. The NAME 'Adam' doesn't have a 'lifetime' as there is no point in 
time when this will cease to be true (unless you count end of time type 
events). The object/man 'Adam' had a lifetime that is now over. We can't 
use the name 'Adam' to access the actual being Adam. In the time of 
Genesis 2 (if we presume it happened), the name 'Adam' could be used to 
access the being Adam, and we have record of this happening (rather than 
him just being addresses as Hey You).

In other scopes, 'Adam' might refer to different things, for example in 
the scope of the TV Program MythBusters, Adam is one of the hosts (Adam 
Savage), who is still within his lifetime. Just because we 'leave' the 
scope of the show, the name 'Adam' doesn't end its lifetime.

In an interpretive environment (which it sounds like RDC has some 
aspects off), scope and lifetime can get a bit more muddled as there is 
during execution a 'scope' that is special, the scope where the point of 
execution is currently happening, but that doesn't mean that it is the 
only scope that actually exists, and it is still important to understand 
the difference.

This whole topic gives me flashbacks to decades ago when I was first 
learning programming, and the history of programming, and reminds me so 
much of what the 'industry' went through as it learned. Your decision to 
do it alone, without taking a bit of time to learn from the experience 
of those who have gone before, is leading you to many of the traps that 
many of us see coming.

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

#74474

On Saturday, October 31, 2015 at 2:44:50 PM UTC, Richard Damon wrote:
>
> Scope is a 'Source Code' property, it applies to 'Names', while Lifetime 
> is an 'Execution Time' property, it applies to 'objects'.
> 
The main practical difference is that, in most languages, an object
(or an identifier if you insist on correctness) goes out of scope
when a subroutine is called, but it still exists, and pops back into
scope when the subroutine returns.
>
>
> Here is an example that perhaps you can understand. Let us take the 
> Bible, You (and others here) believe it is a Historical Document 
> describing things that have (and will) be (others will disagree, but 
> that really isn't the point here).
> 
> In Genesis, there is the name 'Adam', referring to the 'First Man'. If 
> we are in the scope of a Biblical discussion, we can use 'Adam' to refer 
> to this object, and talk a lot about it. The NAME 'Adam' can still be in 
> scope. 
>
As it happens, my novel is called "Adam and Abagail go to St Tom's".
Adam is schoolboy, and he has a twin sister called Abagail. So 
anywhere Adam appears in that text, it means him.
Except that the name was chosen deliberately, not just as something
that alliterates with Abagail. That's where than analogy breaks
down. 

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web