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 1 of 4  [1] 2 3 4  Next page →

#74216 — CAlive special use instance class, called an angel

CAlive introduces a special type of class called an angel.  Angels are
instance-use classes which are created as/when they are used, with the
ability to also reuse a single named variable multiple times with each
instance being maintained separately internally.

When passed as parameters they operate as standard classes, but upon
returning to the place where they were instantiated they immediately
fall out of scope and their destructor is called.

For example:

    angel ANote
    {
        ANote(s8* note)            { m_note = datum(note, -1); }
        ~ANote()                   { datumfree(m_note); m_note = NULL; }

        accessor datum* getNote()  { return(m_note); }

    private:
        datum  m_note;
    }


    int main(int argc, char* argv[])
    {
        ANote note;

        my_func(note("Example 1"), note("Example 2"));
    }


    void my_func(ANote* note1, ANote* note2)
    {
        printf("%_sd\n%_sd", note1.getNote, note2.getNote);
    }

-----
Their utility is provided for short-lived objects that are needed in
context, but have no long-term need beyond their immediate instance
use, so they can then be discarded, and without having to manually
discard them, or keep track of them even by name.

Their ability to spawn multiple instances by name as needed is also
a time saver for the developer.  Less variables to track manually,
and clean-up.

Best regards,
Rick C. Hodgin

[toc] | [next] | [standalone]

#74217

On Thursday, October 29, 2015 at 9:18:40 PM UTC-4, Rick C. Hodgin wrote:
>         datum  m_note;

Should be datum* not datum.

Best regards,
Rick C. Hodgin

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

#74219

Rick C. Hodgin wrote:
> CAlive introduces a special type of class called an angel.  Angels are
> instance-use classes which are created as/when they are used, with the
> ability to also reuse a single named variable multiple times with each
> instance being maintained separately internally.
>
> When passed as parameters they operate as standard classes, but upon
> returning to the place where they were instantiated they immediately
> fall out of scope and their destructor is called.

This differs from a C++ class how?


-- 
Ian Collins

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

#74223

On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > CAlive introduces a special type of class called an angel.  Angels are
> > instance-use classes which are created as/when they are used, with the
> > ability to also reuse a single named variable multiple times with each
> > instance being maintained separately internally.
> >
> > When passed as parameters they operate as standard classes, but upon
> > returning to the place where they were instantiated they immediately
> > fall out of scope and their destructor is called.
> 
> This differs from a C++ class how?

As I understand it, in two ways:

    (1) when declared as a named variable, that named variable can be
        reused multiple times with the same name, with each name reuse
        creating its own separate instance.

    (2) angels fall out of scope immediately after use, calling their
        destructor, which in C++ as I understand it, would be the
        equivalent of this operation:

            CWhatever* w1 = new CWhatever("1");
            CWhatever* w2 = new CWhatever("2");
            CWhatever* w3 = new CWhatever("3");
            something(w1, w2, w3);
            delete w1, w2, w3;

        So, with angels you use:

            AWhatever w;
            something(w("1"), w("2"), w("3"));
            // At this point, no instance of w remains in scope

Best regards,
Rick C. Hodgin

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

#74230

Rick C. Hodgin wrote:
> 
> On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
> > Rick C. Hodgin wrote:
> > > CAlive introduces a special type of class called an angel.  Angels are
> > > instance-use classes which are created as/when they are used, with the
> > > ability to also reuse a single named variable multiple times with each
> > > instance being maintained separately internally.
> > >
> > > When passed as parameters they operate as standard classes, but upon
> > > returning to the place where they were instantiated they immediately
> > > fall out of scope and their destructor is called.
> > 
> > This differs from a C++ class how?
> 
> As I understand it, in two ways:
> 
>     (1) when declared as a named variable, that named variable can be
>         reused multiple times with the same name, with each name reuse
>         creating its own separate instance.

Yes, that is different. I'm not sure I see the value, though--why give 
it a name, if you don't want to refer to it more than once.

>     (2) angels fall out of scope immediately after use, calling their
>         destructor, which in C++ as I understand it, would be the
>         equivalent of this operation:
> 
>             CWhatever* w1 = new CWhatever("1");
>             CWhatever* w2 = new CWhatever("2");
>             CWhatever* w3 = new CWhatever("3");
>             something(w1, w2, w3);
>             delete w1, w2, w3;
> 
>         So, with angels you use:
> 
>             AWhatever w;
>             something(w("1"), w("2"), w("3"));
>             // At this point, no instance of w remains in scope

Nope, C++ works exactly like this.

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

#74231

On Friday, October 30, 2015 at 5:29:21 AM UTC, Philip Lantz wrote:
> Rick C. Hodgin wrote:
>
> >     (2) angels fall out of scope immediately after use, calling their
> >         destructor, which in C++ as I understand it, would be the
> >         equivalent of this operation:
> > 
> >             CWhatever* w1 = new CWhatever("1");
> >             CWhatever* w2 = new CWhatever("2");
> >             CWhatever* w3 = new CWhatever("3");
> >             something(w1, w2, w3);
> >             delete w1, w2, w3;
> > 
> >         So, with angels you use:
> > 
> >             AWhatever w;
> >             something(w("1"), w("2"), w("3"));
> >             // At this point, no instance of w remains in scope
> 
> Nope, C++ works exactly like this.
>
There's a difference, but I don't really see the importance.
in C++, "something" would be declared as

void something(CWhatever *w1, CWhatever *w2, CWhatever *w3);

it follows that we have to create the three arguments, take their
addresses, and pass them to the function.
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"))

this is also comparatively unusual, because normally "something"
would just take "1", "2", "3", that's all the actual information 
we're passing it, but it's a snippet example.

I don't really see what programming issue angels solve, however.
If "something" is polymorphic we can presumably set the type
where the angel is defined, rather than where it is instantiated.
But I can't really think of a use case for that.

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

#74245

In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
...
>> Nope, C++ works exactly like this.
>>
>There's a difference, but I don't really see the importance.
>in C++, "something" would be declared as

I don't get this.  Why are you people pushing C++ ideas/solutions at Ricky?

Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?

-- 
"Although written many years ago, Lady Chatterley's Lover has just
been reissued by the Grove Press, and this fictional account of the
day-to-day life of an English gamekeeper is still of considerable
interest to outdoor minded readers, as it contains many passages on
pheasant raising, the apprehending of poachers, ways to control vermin,
and other chores and duties of the professional gamekeeper.

"Unfortunately, one is obliged to wade through many pages of extraneous
material in order to discover and savor these sidelights on the
management of a Midlands shooting estate, and in this reviewer's opinion
this book cannot take the place of J.R. Miller's Practical Gamekeeping"
(Ed Zern, Field and Stream, November 1959, p. 142).

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

#74248

On Friday, October 30, 2015 at 8:40:43 AM UTC, Kenny McCormack wrote:
> In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
> ...
> >> Nope, C++ works exactly like this.
> >>
> >There's a difference, but I don't really see the importance.
> >in C++, "something" would be declared as
> 
> I don't get this.  Why are you people pushing C++ ideas/solutions
> at Ricky?
> 
> Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?
> 
People are always taking C as a base from which to make a new language.
Proposals are topical to a point. We wouldn't want the newsgroup swamped 
by them, but you can maybe usefully modify a C compiler.

However if a proposed extension has already been implemented by C++,
it's worth pointing it out. In this case, the claim that "C++
works exactly like this" isn't quite true, but I don't see an
application for the differences. But maybe I'm missing something,
it's a invitation to Rick to explain.

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

#74254

On 30/10/15 08:49, Malcolm McLean wrote:
> On Friday, October 30, 2015 at 8:40:43 AM UTC, Kenny McCormack wrote:
>> In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
>> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>> ...
>>>> Nope, C++ works exactly like this.
>>>>
>>> There's a difference, but I don't really see the importance.
>>> in C++, "something" would be declared as
>>
>> I don't get this.  Why are you people pushing C++ ideas/solutions
>> at Ricky?
>>
>> Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?
>>
> People are always taking C as a base from which to make a new language.

That doesn't make such languages topical here.

> Proposals are topical to a point.

No, they aren't. This newsgroup is about C, not languages based on C.

> We wouldn't want the newsgroup swamped
> by them, but you can maybe usefully modify a C compiler.
>
> However if a proposed extension has already been implemented by C++,
> it's worth pointing it out. In this case, the claim that "C++
> works exactly like this" isn't quite true, but I don't see an
> application for the differences. But maybe I'm missing something,
> it's a invitation to Rick to explain.

Perhaps he could respond to that invitation in a newsgroup where the 
discussion is topical. This isn't that newsgroup.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#74280

On Friday, October 30, 2015 at 4:49:31 AM UTC-4, Malcolm McLean wrote:
> On Friday, October 30, 2015 at 8:40:43 AM UTC, Kenny McCormack wrote:
> > In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
> > Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
> > ...
> > >> Nope, C++ works exactly like this.
> > >>
> > >There's a difference, but I don't really see the importance.
> > >in C++, "something" would be declared as
> > 
> > I don't get this.  Why are you people pushing C++ ideas/solutions
> > at Ricky?
> > 
> > Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?
> > 
> People are always taking C as a base from which to make a new language.
> Proposals are topical to a point. We wouldn't want the newsgroup swamped 
> by them, but you can maybe usefully modify a C compiler.
> 
> However if a proposed extension has already been implemented by C++,
> it's worth pointing it out. In this case, the claim that "C++
> works exactly like this" isn't quite true, but I don't see an
> application for the differences. But maybe I'm missing something,
> it's a invitation to Rick to explain.

The reason why I allow name reuse, rather than just angel/class name
reuse, is because I want things to take on a meaning in source code.
I don't want to create a generic class like:

    angel ALogNote
    {
        // Code for maintaining a log of notes and pertinent note data
    };

And then use just:

    something(ALogNote("The meeting was cancelled."));

I want it to have some meaning in code:

    ALogNote warning;
    something(warning("The meeting was cancelled."));

So, angels exist. :-)

Best regards,
Rick C. Hodgin

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

#74292

On 30/10/15 13:37, Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 4:49:31 AM UTC-4, Malcolm McLean wrote:
>> On Friday, October 30, 2015 at 8:40:43 AM UTC, Kenny McCormack wrote:
>>> In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
>>> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>>> ...
>>>>> Nope, C++ works exactly like this.
>>>>>
>>>> There's a difference, but I don't really see the importance.
>>>> in C++, "something" would be declared as
>>>
>>> I don't get this.  Why are you people pushing C++ ideas/solutions
>>> at Ricky?
>>>
>>> Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?
>>>
>> People are always taking C as a base from which to make a new language.
>> Proposals are topical to a point. We wouldn't want the newsgroup swamped 
>> by them, but you can maybe usefully modify a C compiler.
>>
>> However if a proposed extension has already been implemented by C++,
>> it's worth pointing it out. In this case, the claim that "C++
>> works exactly like this" isn't quite true, but I don't see an
>> application for the differences. But maybe I'm missing something,
>> it's a invitation to Rick to explain.
> 
> The reason why I allow name reuse, rather than just angel/class name
> reuse, is because I want things to take on a meaning in source code.
> I don't want to create a generic class like:
> 
>     angel ALogNote
>     {
>         // Code for maintaining a log of notes and pertinent note data
>     };
> 
> And then use just:
> 
>     something(ALogNote("The meeting was cancelled."));
> 
> I want it to have some meaning in code:
> 
>     ALogNote warning;
>     something(warning("The meeting was cancelled."));
> 
> So, angels exist. :-)
> 

Then why not write:

	typedef ALogNote warning;
	something(warning("The meeting was cancelled."));

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

#74296

On Friday, October 30, 2015 at 9:25:31 AM UTC-4, David Brown wrote:
> On 30/10/15 13:37, Rick C. Hodgin wrote:
> > On Friday, October 30, 2015 at 4:49:31 AM UTC-4, Malcolm McLean wrote:
> >> On Friday, October 30, 2015 at 8:40:43 AM UTC, Kenny McCormack wrote:
> >>> In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
> >>> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
> >>> ...
> >>>>> Nope, C++ works exactly like this.
> >>>>>
> >>>> There's a difference, but I don't really see the importance.
> >>>> in C++, "something" would be declared as
> >>>
> >>> I don't get this.  Why are you people pushing C++ ideas/solutions
> >>> at Ricky?
> >>>
> >>> Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?
> >>>
> >> People are always taking C as a base from which to make a new language.
> >> Proposals are topical to a point. We wouldn't want the newsgroup swamped 
> >> by them, but you can maybe usefully modify a C compiler.
> >>
> >> However if a proposed extension has already been implemented by C++,
> >> it's worth pointing it out. In this case, the claim that "C++
> >> works exactly like this" isn't quite true, but I don't see an
> >> application for the differences. But maybe I'm missing something,
> >> it's a invitation to Rick to explain.
> > 
> > The reason why I allow name reuse, rather than just angel/class name
> > reuse, is because I want things to take on a meaning in source code.
> > I don't want to create a generic class like:
> > 
> >     angel ALogNote
> >     {
> >         // Code for maintaining a log of notes and pertinent note data
> >     };
> > 
> > And then use just:
> > 
> >     something(ALogNote("The meeting was cancelled."));
> > 
> > I want it to have some meaning in code:
> > 
> >     ALogNote warning;
> >     something(warning("The meeting was cancelled."));
> > 
> > So, angels exist. :-)
> > 
> 
> Then why not write:
> 
> 	typedef ALogNote warning;
> 	something(warning("The meeting was cancelled."));

(1) I didn't know local typedefs were legal.

(2) I think typedefing something is inappropriate in nearly all
    cases.  I prefer to use the thing, and then with reference
    to its * or **.

(3) Typedefing still doesn't remove the other syntax changes and
    requirements.

The use of angels doesn't require worrying about pointers or non-
pointers, they are always defined dynamically, and they are always
passed as pointers.  You simply use them.  It gives the developer
the ability to operate more in the realms of ideas and concepts
than down in the murky details of the mechanical implementation.

Best regards,
Rick C. Hodgin

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

#74318

On 30/10/15 14:35, Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 9:25:31 AM UTC-4, David Brown wrote:
>> On 30/10/15 13:37, Rick C. Hodgin wrote:
>>> On Friday, October 30, 2015 at 4:49:31 AM UTC-4, Malcolm McLean wrote:
>>>> On Friday, October 30, 2015 at 8:40:43 AM UTC, Kenny McCormack wrote:
>>>>> In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
>>>>> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
>>>>> ...
>>>>>>> Nope, C++ works exactly like this.
>>>>>>>
>>>>>> There's a difference, but I don't really see the importance.
>>>>>> in C++, "something" would be declared as
>>>>>
>>>>> I don't get this.  Why are you people pushing C++ ideas/solutions
>>>>> at Ricky?
>>>>>
>>>>> Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?
>>>>>
>>>> People are always taking C as a base from which to make a new language.
>>>> Proposals are topical to a point. We wouldn't want the newsgroup swamped 
>>>> by them, but you can maybe usefully modify a C compiler.
>>>>
>>>> However if a proposed extension has already been implemented by C++,
>>>> it's worth pointing it out. In this case, the claim that "C++
>>>> works exactly like this" isn't quite true, but I don't see an
>>>> application for the differences. But maybe I'm missing something,
>>>> it's a invitation to Rick to explain.
>>>
>>> The reason why I allow name reuse, rather than just angel/class name
>>> reuse, is because I want things to take on a meaning in source code.
>>> I don't want to create a generic class like:
>>>
>>>     angel ALogNote
>>>     {
>>>         // Code for maintaining a log of notes and pertinent note data
>>>     };
>>>
>>> And then use just:
>>>
>>>     something(ALogNote("The meeting was cancelled."));
>>>
>>> I want it to have some meaning in code:
>>>
>>>     ALogNote warning;
>>>     something(warning("The meeting was cancelled."));
>>>
>>> So, angels exist. :-)
>>>
>>
>> Then why not write:
>>
>> 	typedef ALogNote warning;
>> 	something(warning("The meeting was cancelled."));
> 
> (1) I didn't know local typedefs were legal.

It's /your/ language.  /Make/ them legal, regardless of whether or not
they are legal in C.

C++11 also has "type alias", which is a little more flexible than
typedef, especially when using templates.  It is particularly useful for
making shortcuts for long type names.

	using warning = ALogNote;

> 
> (2) I think typedefing something is inappropriate in nearly all
>     cases.  I prefer to use the thing, and then with reference
>     to its * or **.

What you are doing in the code above is effectively a typedef, even if
you don't like it.  Your use of "ALogNote warning" is making a sort of
object-generator rather than an instance of a class, and you use that
object-generator to make new /real/ instances when it is used.  Such
"object-generators" are simply types.

(If you want to make types into first-class objects in your language,
with functions being able to create and manipulate types, then that
would be very interesting.)

Personally, I use typedefs extensively - it is important in trying to
get as much compile-time information and checking as possible in order
to write clearer and safer code.  But I would not want to use one in
this case (or an "angel" either).

> 
> (3) Typedefing still doesn't remove the other syntax changes and
>     requirements.

It works fine in the examples you have shown so far.

> 
> The use of angels doesn't require worrying about pointers or non-
> pointers, they are always defined dynamically, and they are always
> passed as pointers.  You simply use them.  It gives the developer
> the ability to operate more in the realms of ideas and concepts
> than down in the murky details of the mechanical implementation.
> 

I don't see anything here that you don't already have in C++ using
simple classes, a typedef or two, and using reference parameters.
Putting things on the stack rather than with extra pointers makes it
much less likely that things will leak, and the results are more efficient.

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

#74325

On Friday, October 30, 2015 at 11:34:13 AM UTC-4, David Brown wrote:
> On 30/10/15 14:35, Rick C. Hodgin wrote:
> > On Friday, October 30, 2015 at 9:25:31 AM UTC-4, David Brown wrote:
> >> On 30/10/15 13:37, Rick C. Hodgin wrote:
> >>> On Friday, October 30, 2015 at 4:49:31 AM UTC-4, Malcolm McLean wrote:
> >>>> On Friday, October 30, 2015 at 8:40:43 AM UTC, Kenny McCormack wrote:
> >>>>> In article <77be262f-6ad6-4b73-bad7-e28d42fbc12a@googlegroups.com>,
> >>>>> Malcolm McLean  <malcolm.mclean5@btinternet.com> wrote:
> >>>>> ...
> >>>>>>> Nope, C++ works exactly like this.
> >>>>>>>
> >>>>>> There's a difference, but I don't really see the importance.
> >>>>>> in C++, "something" would be declared as
> >>>>>
> >>>>> I don't get this.  Why are you people pushing C++ ideas/solutions
> >>>>> at Ricky?
> >>>>>
> >>>>> Isn't C++ every bit as irrelevant (aka, "OT") here as is CAlive?
> >>>>>
> >>>> People are always taking C as a base from which to make a new language.
> >>>> Proposals are topical to a point. We wouldn't want the newsgroup swamped 
> >>>> by them, but you can maybe usefully modify a C compiler.
> >>>>
> >>>> However if a proposed extension has already been implemented by C++,
> >>>> it's worth pointing it out. In this case, the claim that "C++
> >>>> works exactly like this" isn't quite true, but I don't see an
> >>>> application for the differences. But maybe I'm missing something,
> >>>> it's a invitation to Rick to explain.
> >>>
> >>> The reason why I allow name reuse, rather than just angel/class name
> >>> reuse, is because I want things to take on a meaning in source code.
> >>> I don't want to create a generic class like:
> >>>
> >>>     angel ALogNote
> >>>     {
> >>>         // Code for maintaining a log of notes and pertinent note data
> >>>     };
> >>>
> >>> And then use just:
> >>>
> >>>     something(ALogNote("The meeting was cancelled."));
> >>>
> >>> I want it to have some meaning in code:
> >>>
> >>>     ALogNote warning;
> >>>     something(warning("The meeting was cancelled."));
> >>>
> >>> So, angels exist. :-)
> >>>
> >>
> >> Then why not write:
> >>
> >> 	typedef ALogNote warning;
> >> 	something(warning("The meeting was cancelled."));
> > 
> > (1) I didn't know local typedefs were legal.
> 
> It's /your/ language.  /Make/ them legal, regardless of whether or not
> they are legal in C.
> 
> C++11 also has "type alias", which is a little more flexible than
> typedef, especially when using templates.  It is particularly useful for
> making shortcuts for long type names.
> 
> 	using warning = ALogNote;
> 
> > 
> > (2) I think typedefing something is inappropriate in nearly all
> >     cases.  I prefer to use the thing, and then with reference
> >     to its * or **.
> 
> What you are doing in the code above is effectively a typedef, even if
> you don't like it.  Your use of "ALogNote warning" is making a sort of
> object-generator rather than an instance of a class, and you use that
> object-generator to make new /real/ instances when it is used.  Such
> "object-generators" are simply types.

As with much of what I do with CAlive, I tweak the syntax.  I make
it easier to use.  I don't need to say typedef ALogNote warning, I
simply say ALogNote warning.

It makes a difference.

> (If you want to make types into first-class objects in your language,
> with functions being able to create and manipulate types, then that
> would be very interesting.)
> 
> Personally, I use typedefs extensively - it is important in trying to
> get as much compile-time information and checking as possible in order
> to write clearer and safer code.  But I would not want to use one in
> this case (or an "angel" either).

I also make heavy use of typedefs in C/C++.  I have to because the
only other choice I have is to use char, int, long, and so on.

> > (3) Typedefing still doesn't remove the other syntax changes and
> >     requirements.
> 
> It works fine in the examples you have shown so far.

I demonstrated in my reply that it doesn't.  There are syntax variations
which, again, are part of the problem.  Using angels is easy.  Using
the constructs demonstrated thus far require changes to the class
definition, and that's part of what I'm trying to avoid.

> > The use of angels doesn't require worrying about pointers or non-
> > pointers, they are always defined dynamically, and they are always
> > passed as pointers.  You simply use them.  It gives the developer
> > the ability to operate more in the realms of ideas and concepts
> > than down in the murky details of the mechanical implementation.
> 
> I don't see anything here that you don't already have in C++ using
> simple classes, a typedef or two, and using reference parameters.
> Putting things on the stack rather than with extra pointers makes it
> much less likely that things will leak, and the results are more
> efficient.

Well, implement a simple solution using classes only.  And then
implement one using Malcom's CWhatever const &abc1 solution, and
see how the code needs to change.

Maybe it doesn't need to change.  I couldn't figure out a syntax
without making the accessor also const in that case, because the
instances that were created seemed to be created as singletons,
where each instance had its own location in memory.  With angels,
the slots in local variable space are re-used time and again.

Best regards,
Rick C. Hodgin

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

#74294

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> The reason why I allow name reuse, rather than just angel/class name
> reuse, is because I want things to take on a meaning in source code.
> I don't want to create a generic class like:
>
>     angel ALogNote
>     {
>         // Code for maintaining a log of notes and pertinent note data
>     };
>
> And then use just:
>
>     something(ALogNote("The meeting was cancelled."));
>
> I want it to have some meaning in code:
>
>     ALogNote warning;
>     something(warning("The meeting was cancelled."));

You can do that with existing notation:

  typedef ALogNote warning;

-- 
Ben.

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

#74278

On Friday, October 30, 2015 at 1:53:55 AM UTC-4, Malcolm McLean wrote:
> On Friday, October 30, 2015 at 5:29:21 AM UTC, Philip Lantz wrote:
> > Rick C. Hodgin wrote:
> >
> > >     (2) angels fall out of scope immediately after use, calling their
> > >         destructor, which in C++ as I understand it, would be the
> > >         equivalent of this operation:
> > > 
> > >             CWhatever* w1 = new CWhatever("1");
> > >             CWhatever* w2 = new CWhatever("2");
> > >             CWhatever* w3 = new CWhatever("3");
> > >             something(w1, w2, w3);
> > >             delete w1, w2, w3;
> > > 
> > >         So, with angels you use:
> > > 
> > >             AWhatever w;
> > >             something(w("1"), w("2"), w("3"));
> > >             // At this point, no instance of w remains in scope
> > 
> > Nope, C++ works exactly like this.
> >
> There's a difference, but I don't really see the importance.
> in C++, "something" would be declared as
> 
> void something(CWhatever *w1, CWhatever *w2, CWhatever *w3);
> 
> it follows that we have to create the three arguments, take their
> addresses, and pass them to the function.

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.

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

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.

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:

    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.

But perhaps that is my own misunderstanding of C++ and there is
another way to get the functionality using const.

> this is also comparatively unusual, because normally "something"
> would just take "1", "2", "3", that's all the actual information 
> we're passing it, but it's a snippet example.
> 
> I don't really see what programming issue angels solve, however.
> If "something" is polymorphic we can presumably set the type
> where the angel is defined, rather than where it is instantiated.
> But I can't really think of a use case for that.

Everything about CAlive ties back to RDC (Rapid Development Compiler).

In all of the cases I have shown, the conveyance of everything in
source code is to make the code clearer, easier to understand, to
self-document and connect things which are naturally connected
logically by their innate form, and all in a syntax which seems
much clearer and easier (once you get past the learning curve and
understand it and become familiar with it, and remember that it
will be shown in a GUI editor) than the equivalent code in C++
(when there is equivalent C++ code).

I call my ad hoc functions adhocs, rather than lambdas or nested
functions.  They convey their meaning in code.  And, you can #define
the term adhoc to be something else and make it suitable for your
use.

I place the word "adhoc" and "function" in front of my function
names so they convey that syntax.

I call my new helper class an angel, because it is there to serve
the instance needs, and also to spawn itself into more helpers as
much as is needed for the task at hand.

I also have other concepts I haven't introduced to comp.lang.c yet
which follow this same form of self-documenting code.

-----
I think they are nice features.  I desire to have these features in
my source code and programs to make the code easier to read and
understand.

CAlive is still a work in progress, but these definitions are becoming
more and more solid as I approach the final coding phases.  As such,
I am presenting them publicly for introduction and consumption.

-----
If you'd all like me to stop posting about CAlive, I'll be glad to.
I am writing this software for God, using the talents and abilities
He first gave me.  I do not have a background in computer theory or
I haven't learned what I've learned from books and classes.  I am
thinking things through, and generating those things which, to me,
make sense.  I am doing this to employ the best of what the Lord first
gave me, and then also whoever else would want to use it.

I do appreciate the feedback though.  Thank you.

Best regards,
Rick C. Hodgin

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

#74285

In article <06012d90-75a1-49ae-80da-fb3959d5a842@googlegroups.com>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
...
>If you'd all like me to stop posting about CAlive, I'll be glad to.
>I am writing this software for God, using the talents and abilities
>He first gave me.

Imaginary software for an imaginary being.  Makes sense to me.

And please don't stop.  This newsgroup needs you.  It'd be so boring
without you.

-- 
Watching ConservaLoons playing with statistics and facts is like watching a
newborn play with a computer.  Endlessly amusing, but totally unproductive.

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

#74293

On Friday, October 30, 2015 at 9:14:02 AM UTC-4, Kenny McCormack wrote:
> In article <06012d90-75a1-49ae-80da-fb3959d5a842@googlegroups.com>,
> Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
> ...
> >If you'd all like me to stop posting about CAlive, I'll be glad to.
> >I am writing this software for God, using the talents and abilities
> >He first gave me.
> 
> Imaginary software for an imaginary being.  Makes sense to me.

The "imaginary being" will only "be" imaginary to those people who
deny insurmountable evidence, and only then until the day of their
death... at which point the falseness of this world is stripped from
them and they then, apart from sin, stand in full realization of
truth, and the full weight of truth, standing naked, alone, and
weeping, before a Holy, Holy, Holy God who is there as their judge
at this point, and not their savior, without any hope or recourse
because up until that point they had never believed in the existence
of that which is so obvious all around them.  And, having denied His
existence, they were not saved.

It is that end I would save you from by witnessing to you about
the true nature of this universe, our world, who we are, who Jesus
is, why we need Him, so that you would go to Him, repent of your
sin, ask forgiveness, and be saved.

I would like to see you in Heaven, Kenny.

> And please don't stop.  This newsgroup needs you.  It'd be so boring
> without you.

Why thank you, Kenny.

Best regards,
Rick C. Hodgin

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

#74373

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

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

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

> But perhaps that is my own misunderstanding of C++ and there is
> another way to get the functionality using const.
>
>> this is also comparatively unusual, because normally "something"
>> would just take "1", "2", "3", that's all the actual information
>> we're passing it, but it's a snippet example.
>>
>> I don't really see what programming issue angels solve, however.
>> If "something" is polymorphic we can presumably set the type
>> where the angel is defined, rather than where it is instantiated.
>> But I can't really think of a use case for that.
>
> Everything about CAlive ties back to RDC (Rapid Development Compiler).
>
> In all of the cases I have shown, the conveyance of everything in
> source code is to make the code clearer, easier to understand, to
> self-document and connect things which are naturally connected
> logically by their innate form, and all in a syntax which seems
> much clearer and easier (once you get past the learning curve and
> understand it and become familiar with it, and remember that it
> will be shown in a GUI editor) than the equivalent code in C++
> (when there is equivalent C++ code).
>

That's all well and good, but don't loose sight of the common sense 
rules other languages impose.  Most are there for a reason which you may 
not spot until you try and go in a different direction.

I guess what I'm saying is learn from those who have trodden the same 
path before you.

-- 
Ian Collins

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

#74375

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.

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

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

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

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.

> > But perhaps that is my own misunderstanding of C++ and there is
> > another way to get the functionality using const.
> >
> >> this is also comparatively unusual, because normally "something"
> >> would just take "1", "2", "3", that's all the actual information
> >> we're passing it, but it's a snippet example.
> >>
> >> I don't really see what programming issue angels solve, however.
> >> If "something" is polymorphic we can presumably set the type
> >> where the angel is defined, rather than where it is instantiated.
> >> But I can't really think of a use case for that.
> >
> > Everything about CAlive ties back to RDC (Rapid Development Compiler).
> >
> > In all of the cases I have shown, the conveyance of everything in
> > source code is to make the code clearer, easier to understand, to
> > self-document and connect things which are naturally connected
> > logically by their innate form, and all in a syntax which seems
> > much clearer and easier (once you get past the learning curve and
> > understand it and become familiar with it, and remember that it
> > will be shown in a GUI editor) than the equivalent code in C++
> > (when there is equivalent C++ code).
> 
> That's all well and good, but don't loose sight of the common sense 
> rules other languages impose.  Most are there for a reason which you may 
> not spot until you try and go in a different direction.
> 
> I guess what I'm saying is learn from those who have trodden the same 
> path before you.

I appreciate the advice.

Best regards,
Rick C. Hodgin

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web