Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #74216 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-10-29 18:18 -0700 |
| Last post | 2015-11-01 15:56 +0000 |
| Articles | 20 on this page of 80 — 13 participants |
Back to article view | Back to comp.lang.c
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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-31 13:13 +1300 |
| Message-ID | <d9ifdmF2lrhU9@mid.individual.net> |
| In reply to | #74378 |
Ben Bacarisse wrote: > > 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! Some of us do regularly go to the pub.... Problems go out of scope on the way in, but unfortunately they come back on the way out. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-30 22:17 -0400 |
| Message-ID | <n1187t$9le$1@dont-email.me> |
| In reply to | #74378 |
On 10/30/2015 06:44 PM, 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. 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! Implicit execution of an object's destructor is governed by 12.4p4, and the word "scope" doesn't appear anywhere in that section. The idea that it's the scope that matters comes from the fact that objects with automatic storage duration have a lifetime that ends when the block containing them exits, which is the same location where the scope of the names of the objects ends (3.3.3p1). However, their lifetime can also end when an exception is thrown. For objects that don't have automatic storage duration, there's no particular connection between the scope of the object's name and the execution of of its destructor. Objects with static storage duration have their destructors called at the end of the program. Objects with thread storage duration have them called when the thread exits. The destructors for temporary objects are called when their lifetime ends. In fact, "lifetime ends" is an accurate description for all of those categories. Destructors of objects with dynamic storage duration never have their destructors called implicitly. Objects created by the new operator have the destructor called when the delete operator is used on them (5.3.5p6). If something meets the standard's requirements for an allocator (17.6.3.5), then the destructor can also be invoked by calling allocator.destroy(object) BEFORE calling allocator.deallocate(object). For objects explicitly constructed in memory that is allocated using calloc(), malloc(), realloc() or get_temporary_buffer(), destructors have to be called equally explicitly. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-10-30 22:31 -0400 |
| Message-ID | <n1191e$b33$1@dont-email.me> |
| In reply to | #74388 |
On 10/30/2015 10:17 PM, James Kuyper wrote: ... > Implicit execution of an object's destructor is governed by 12.4p4, and Correction: 12.4p11. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-10-30 01:42 -0700 |
| Message-ID | <MPG.309ccd6c4d3f9fb05c@news.eternal-september.org> |
| In reply to | #74230 |
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.
Oh, I should have read that more carefully. In C++, it would be:
something(AWhatever("1"), AWhatever("2"), AWhatever("3"));
or simply
something("1", "2", "3");
(where the conversions are implicit). It does the same thing, which was
my point, but I overlooked that the code is different.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-30 09:38 +0000 |
| Message-ID | <87twp8g0gl.fsf@bsb.me.uk> |
| In reply to | #74223 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
<snip>
> So, with angels you use:
>
> AWhatever w;
> something(w("1"), w("2"), w("3"));
> // At this point, no instance of w remains in scope
Somewhat topical: you are confusing scope and lifetime: scope is a
spacial property of a name; lifetime is a temporal property of an
object. Obviously they are connected but "no instance of w remains in
scope" is, at best, confusing.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-30 04:35 -0700 |
| Message-ID | <7f773e2a-fb37-49f8-bb83-97dded468fba@googlegroups.com> |
| In reply to | #74258 |
On Friday, October 30, 2015 at 5:39:07 AM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>
> > On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
> <snip>
> > So, with angels you use:
> >
> > AWhatever w;
> > something(w("1"), w("2"), w("3"));
> > // At this point, no instance of w remains in scope
>
> Somewhat topical: you are confusing scope and lifetime: scope is a
> spacial property of a name; lifetime is a temporal property of an
> object. Obviously they are connected but "no instance of w remains in
> scope" is, at best, confusing.
I have stopped responding to you because I see in my case and others,
you're often having trouble understanding the things people write. I
think you actually do understand in all cases, so it makes the response
pointless.
However, it is very likely I'm using the terms improperly compared to
however they're defined in C or C++ because I don't know how they're
technically defined in C or C++. So... here goes:
Internally, CAlive does this:
// AWhatever w;
// something(w("1"), w("2"), w("3"));
||||||||||
||| Equivalent of:
||
|| AWhatever* tw1 = new AWhatever("1");
|| AWhatever* tw2 = new AWhatever("2");
|| AWhatever* tw3 = new AWhatever("3"):
||
|| something(tw1, tw2, tw3);
||
|| delete tw1;
|| delete tw2;
|| delete tw3;
||
||||||
// The names tw1, tw2, tw3 do not exist, and their instances do not
// exist. The tw1, tw2, and tw3 "slots" on the stack still exist,
// but they are out of scope (which, to me, means they are not longer
// viable entities, as whatever their destructors did is now done,
// only the allocated space for their static data members exist.
// If later code reused additional w("..") instances, those twN slots
// would be re-used, and the maximum number of twN slots allocated
// relates to the maximum number of concurrent instance uses found in
// source code.
-----
Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
allowing for visual groupings like the above example.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-30 14:10 +0100 |
| Message-ID | <n0vq4r$t74$1@dont-email.me> |
| In reply to | #74272 |
On 30/10/15 12:35, Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 5:39:07 AM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>
>>> On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
>> <snip>
>>> So, with angels you use:
>>>
>>> AWhatever w;
>>> something(w("1"), w("2"), w("3"));
>>> // At this point, no instance of w remains in scope
>>
>> Somewhat topical: you are confusing scope and lifetime: scope is a
>> spacial property of a name; lifetime is a temporal property of an
>> object. Obviously they are connected but "no instance of w remains in
>> scope" is, at best, confusing.
>
> I have stopped responding to you because I see in my case and others,
> you're often having trouble understanding the things people write. I
> think you actually do understand in all cases, so it makes the response
> pointless.
I have found Ben's comments almost always to be accurate, considered,
informed and to the point. He rates very highly on my list of people to
listen to in this group. (But please don't reply to this point - I'd
rather not have a discussion about people here.)
>
> However, it is very likely I'm using the terms improperly compared to
> however they're defined in C or C++ because I don't know how they're
> technically defined in C or C++.
"scope" and "lifetime" are rather critical terms in most programming
languages, and you must learn to understand them properly to use a
language. It is certainly not possible to create a consistent and
workable programming language without understanding the concepts, and
you might as well get the terms right too.
"scope" concerns names and identifiers - something is "in scope" if you
can refer to the name, and "out of scope" if you cannot. "lifetime"
concerns objects - their lifetime begins logically when they are created
or initialised (and in C++, a constructor is called), and logically ends
when they are destroyed (and in C++, a destructor may be called). I
write "logically" here, because compilers are free to re-arrange the
actual generated code as long as the logical effect is correct.
Scope and lifetime often go hand-in-hand - this is true for automatic
(stack) variables and temporaries. But they can be different. For
example, file-level variables have program lifetimes and global scope.
File-level statics have program lifetimes and file-level scope.
Function local statics have program lifetimes and function-local scope
(or block scope within a function). Objects created on a heap and
returned outside the block in which they were allocated, have longer
lifetimes than scope.
In the case of your equivalent code, the temporaries tw1, tw2 and tw3
are pointers whose scope and lifetimes are the same. The AWhatever
objects have lifetimes stretching from when they are created by "new",
until they are destroyed by "delete". But these objects have no scope -
they have no names. Only the pointers to the objects have scope.
> So... here goes:
>
> Internally, CAlive does this:
>
> // AWhatever w;
> // something(w("1"), w("2"), w("3"));
>
> ||||||||||
> ||| Equivalent of:
> ||
> || AWhatever* tw1 = new AWhatever("1");
> || AWhatever* tw2 = new AWhatever("2");
> || AWhatever* tw3 = new AWhatever("3"):
> ||
> || something(tw1, tw2, tw3);
> ||
> || delete tw1;
> || delete tw2;
> || delete tw3;
> ||
> ||||||
>
> // The names tw1, tw2, tw3 do not exist, and their instances do not
> // exist. The tw1, tw2, and tw3 "slots" on the stack still exist,
> // but they are out of scope (which, to me, means they are not longer
> // viable entities, as whatever their destructors did is now done,
> // only the allocated space for their static data members exist.
> // If later code reused additional w("..") instances, those twN slots
> // would be re-used, and the maximum number of twN slots allocated
> // relates to the maximum number of concurrent instance uses found in
> // source code.
In C++, if you write:
something(AWhatever("1"), AWhatever("2"), AWhatever("3"));
it is roughly equivalent to:
{
// The order of these is not specified
AWhatever tw1("1");
AWhatever tw2("2");
AWhatever tw3("3");
something(tw1, tw2, tw3);
// The tw1, tw2, tw3 go out of scope and are destructed
// in reverse creation order
}
In other words, you already get the temporary nature of the objects in C++.
Are you /sure/ that in CAlive, the temporary objects are constructed on
the heap (with new/delete) rather than the stack, as they are in C++?
Certainly stack allocation is a better choice in most cases, as it is
far more efficient.
And in C++, the destruction order is guaranteed to be the reverse of the
construction order. Is that not also the case in CAlive?
>
> -----
> Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
> allowing for visual groupings like the above example.
>
Now I /know/ you are joking. What is wrong with using spaces for white
space? And what insanity possessed you to make long lists of bar
characters, where even numbers means white space and odd numbers mean
comments?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-30 06:21 -0700 |
| Message-ID | <e8f30178-64cd-41ed-9c71-078b9d7f61bb@googlegroups.com> |
| In reply to | #74284 |
On Friday, October 30, 2015 at 9:11:05 AM UTC-4, David Brown wrote:
> On 30/10/15 12:35, Rick C. Hodgin wrote:
> > On Friday, October 30, 2015 at 5:39:07 AM UTC-4, Ben Bacarisse wrote:
> >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>
> >>> On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
> >> <snip>
> >>> So, with angels you use:
> >>>
> >>> AWhatever w;
> >>> something(w("1"), w("2"), w("3"));
> >>> // At this point, no instance of w remains in scope
> >>
> >> Somewhat topical: you are confusing scope and lifetime: scope is a
> >> spacial property of a name; lifetime is a temporal property of an
> >> object. Obviously they are connected but "no instance of w remains in
> >> scope" is, at best, confusing.
> >
> > I have stopped responding to you because I see in my case and others,
> > you're often having trouble understanding the things people write. I
> > think you actually do understand in all cases, so it makes the response
> > pointless.
>
> I have found Ben's comments almost always to be accurate, considered,
> informed and to the point. He rates very highly on my list of people to
> listen to in this group. (But please don't reply to this point - I'd
> rather not have a discussion about people here.)
>
> >
> > However, it is very likely I'm using the terms improperly compared to
> > however they're defined in C or C++ because I don't know how they're
> > technically defined in C or C++.
>
> "scope" and "lifetime" are rather critical terms in most programming
> languages, and you must learn to understand them properly to use a
> language. It is certainly not possible to create a consistent and
> workable programming language without understanding the concepts, and
> you might as well get the terms right too.
>
> "scope" concerns names and identifiers - something is "in scope" if you
> can refer to the name, and "out of scope" if you cannot. "lifetime"
> concerns objects - their lifetime begins logically when they are created
> or initialised (and in C++, a constructor is called), and logically ends
> when they are destroyed (and in C++, a destructor may be called). I
> write "logically" here, because compilers are free to re-arrange the
> actual generated code as long as the logical effect is correct.
>
> Scope and lifetime often go hand-in-hand - this is true for automatic
> (stack) variables and temporaries. But they can be different. For
> example, file-level variables have program lifetimes and global scope.
> File-level statics have program lifetimes and file-level scope.
> Function local statics have program lifetimes and function-local scope
> (or block scope within a function). Objects created on a heap and
> returned outside the block in which they were allocated, have longer
> lifetimes than scope.
>
> In the case of your equivalent code, the temporaries tw1, tw2 and tw3
> are pointers whose scope and lifetimes are the same. The AWhatever
> objects have lifetimes stretching from when they are created by "new",
> until they are destroyed by "delete". But these objects have no scope -
> they have no names. Only the pointers to the objects have scope.
>
>
> > So... here goes:
> >
> > Internally, CAlive does this:
> >
> > // AWhatever w;
> > // something(w("1"), w("2"), w("3"));
> >
> > ||||||||||
> > ||| Equivalent of:
> > ||
> > || AWhatever* tw1 = new AWhatever("1");
> > || AWhatever* tw2 = new AWhatever("2");
> > || AWhatever* tw3 = new AWhatever("3"):
> > ||
> > || something(tw1, tw2, tw3);
> > ||
> > || delete tw1;
> > || delete tw2;
> > || delete tw3;
> > ||
> > ||||||
> >
> > // The names tw1, tw2, tw3 do not exist, and their instances do not
> > // exist. The tw1, tw2, and tw3 "slots" on the stack still exist,
> > // but they are out of scope (which, to me, means they are not longer
> > // viable entities, as whatever their destructors did is now done,
> > // only the allocated space for their static data members exist.
> > // If later code reused additional w("..") instances, those twN slots
> > // would be re-used, and the maximum number of twN slots allocated
> > // relates to the maximum number of concurrent instance uses found in
> > // source code.
>
>
> In C++, if you write:
>
> something(AWhatever("1"), AWhatever("2"), AWhatever("3"));
>
> it is roughly equivalent to:
>
> {
> // The order of these is not specified
> AWhatever tw1("1");
> AWhatever tw2("2");
> AWhatever tw3("3");
>
> something(tw1, tw2, tw3);
>
> // The tw1, tw2, tw3 go out of scope and are destructed
> // in reverse creation order
> }
>
> In other words, you already get the temporary nature of the objects in C++.
>
> Are you /sure/ that in CAlive, the temporary objects are constructed on
> the heap (with new/delete) rather than the stack, as they are in C++?
> Certainly stack allocation is a better choice in most cases, as it is
> far more efficient.
They are on the stack. I use lnew and new to determine where runtime-
allocated classes, structs, and angels are allocated.
> And in C++, the destruction order is guaranteed to be the reverse of the
> construction order. Is that not also the case in CAlive?
Not today. If that's a requirement in C++ then I can make it be that
way. I had planned on them being released in the order they were
allocated. As such, I'll probably make that a compiler option.
> > -----
> > Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
> > allowing for visual groupings like the above example.
> >
>
> Now I /know/ you are joking. What is wrong with using spaces for white
> space? And what insanity possessed you to make long lists of bar
> characters, where even numbers means white space and odd numbers mean
> comments?
The grouped appearance of text above answers your question. It is
obvious to the eye at a glance that that block of code is related.
In addition, within the debugger, it allows you to do a special kind
of single-step debugging, called a single-group-step, allowing you
to step over concepts in your code, and not just mechanical lines.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-30 16:43 +0100 |
| Message-ID | <n1032k$3la$1@dont-email.me> |
| In reply to | #74289 |
On 30/10/15 14:21, Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 9:11:05 AM UTC-4, David Brown wrote:
>> On 30/10/15 12:35, Rick C. Hodgin wrote:
>>> On Friday, October 30, 2015 at 5:39:07 AM UTC-4, Ben Bacarisse wrote:
>>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>>>
>>>>> On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
>>>> <snip>
>>>>> So, with angels you use:
>>>>>
>>>>> AWhatever w;
>>>>> something(w("1"), w("2"), w("3"));
>>>>> // At this point, no instance of w remains in scope
>>>>
>>>> Somewhat topical: you are confusing scope and lifetime: scope is a
>>>> spacial property of a name; lifetime is a temporal property of an
>>>> object. Obviously they are connected but "no instance of w remains in
>>>> scope" is, at best, confusing.
>>>
>>> I have stopped responding to you because I see in my case and others,
>>> you're often having trouble understanding the things people write. I
>>> think you actually do understand in all cases, so it makes the response
>>> pointless.
>>
>> I have found Ben's comments almost always to be accurate, considered,
>> informed and to the point. He rates very highly on my list of people to
>> listen to in this group. (But please don't reply to this point - I'd
>> rather not have a discussion about people here.)
>>
>>>
>>> However, it is very likely I'm using the terms improperly compared to
>>> however they're defined in C or C++ because I don't know how they're
>>> technically defined in C or C++.
>>
>> "scope" and "lifetime" are rather critical terms in most programming
>> languages, and you must learn to understand them properly to use a
>> language. It is certainly not possible to create a consistent and
>> workable programming language without understanding the concepts, and
>> you might as well get the terms right too.
>>
>> "scope" concerns names and identifiers - something is "in scope" if you
>> can refer to the name, and "out of scope" if you cannot. "lifetime"
>> concerns objects - their lifetime begins logically when they are created
>> or initialised (and in C++, a constructor is called), and logically ends
>> when they are destroyed (and in C++, a destructor may be called). I
>> write "logically" here, because compilers are free to re-arrange the
>> actual generated code as long as the logical effect is correct.
>>
>> Scope and lifetime often go hand-in-hand - this is true for automatic
>> (stack) variables and temporaries. But they can be different. For
>> example, file-level variables have program lifetimes and global scope.
>> File-level statics have program lifetimes and file-level scope.
>> Function local statics have program lifetimes and function-local scope
>> (or block scope within a function). Objects created on a heap and
>> returned outside the block in which they were allocated, have longer
>> lifetimes than scope.
>>
>> In the case of your equivalent code, the temporaries tw1, tw2 and tw3
>> are pointers whose scope and lifetimes are the same. The AWhatever
>> objects have lifetimes stretching from when they are created by "new",
>> until they are destroyed by "delete". But these objects have no scope -
>> they have no names. Only the pointers to the objects have scope.
>>
>>
>>> So... here goes:
>>>
>>> Internally, CAlive does this:
>>>
>>> // AWhatever w;
>>> // something(w("1"), w("2"), w("3"));
>>>
>>> ||||||||||
>>> ||| Equivalent of:
>>> ||
>>> || AWhatever* tw1 = new AWhatever("1");
>>> || AWhatever* tw2 = new AWhatever("2");
>>> || AWhatever* tw3 = new AWhatever("3"):
>>> ||
>>> || something(tw1, tw2, tw3);
>>> ||
>>> || delete tw1;
>>> || delete tw2;
>>> || delete tw3;
>>> ||
>>> ||||||
>>>
>>> // The names tw1, tw2, tw3 do not exist, and their instances do not
>>> // exist. The tw1, tw2, and tw3 "slots" on the stack still exist,
>>> // but they are out of scope (which, to me, means they are not longer
>>> // viable entities, as whatever their destructors did is now done,
>>> // only the allocated space for their static data members exist.
>>> // If later code reused additional w("..") instances, those twN slots
>>> // would be re-used, and the maximum number of twN slots allocated
>>> // relates to the maximum number of concurrent instance uses found in
>>> // source code.
>>
>>
>> In C++, if you write:
>>
>> something(AWhatever("1"), AWhatever("2"), AWhatever("3"));
>>
>> it is roughly equivalent to:
>>
>> {
>> // The order of these is not specified
>> AWhatever tw1("1");
>> AWhatever tw2("2");
>> AWhatever tw3("3");
>>
>> something(tw1, tw2, tw3);
>>
>> // The tw1, tw2, tw3 go out of scope and are destructed
>> // in reverse creation order
>> }
>>
>> In other words, you already get the temporary nature of the objects in C++.
>>
>> Are you /sure/ that in CAlive, the temporary objects are constructed on
>> the heap (with new/delete) rather than the stack, as they are in C++?
>> Certainly stack allocation is a better choice in most cases, as it is
>> far more efficient.
>
> They are on the stack. I use lnew and new to determine where runtime-
> allocated classes, structs, and angels are allocated.
Then why bother with all the extra pointers?
>
>> And in C++, the destruction order is guaranteed to be the reverse of the
>> construction order. Is that not also the case in CAlive?
>
> Not today. If that's a requirement in C++ then I can make it be that
> way. I had planned on them being released in the order they were
> allocated. As such, I'll probably make that a compiler option.
Controlled, guaranteed reverse construction order for destructors is
absolutely crucial to RAII, which is a cornerstone of C++. It means you
can wrap your resource acquisition in class constructors, and their
release in class destructors, and know /exactly/ how and when they are
acquired and released in code.
(Of course, a compiler can re-arrange destructors if there is no logical
difference, just like for any other code.)
>
>>> -----
>>> Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
>>> allowing for visual groupings like the above example.
>>>
>>
>> Now I /know/ you are joking. What is wrong with using spaces for white
>> space? And what insanity possessed you to make long lists of bar
>> characters, where even numbers means white space and odd numbers mean
>> comments?
>
> The grouped appearance of text above answers your question. It is
> obvious to the eye at a glance that that block of code is related.
White space does that fine too. And a bit of syntax highlighting, such
as italics or a different colour for comments, makes it even easier.
> In addition, within the debugger, it allows you to do a special kind
> of single-step debugging, called a single-group-step, allowing you
> to step over concepts in your code, and not just mechanical lines.
>
Other debuggers do that fine today - the grouping is called "functions".
Another option is "run to line", or putting breakpoints at steps in the
code.
You might like to introduce a kind of breakpoint and stepping so that a
step-breakpoint is only enabled for breaking if you are doing
group-stepping - then the user can easily add or remove such
step-breakpoints as needed, without changing the source code. That
would be a useful debugging feature, I think.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-30 08:55 -0700 |
| Message-ID | <e1ef9768-79c4-4aef-806d-d6c2a84495b5@googlegroups.com> |
| In reply to | #74324 |
On Friday, October 30, 2015 at 11:43:29 AM UTC-4, David Brown wrote:
> On 30/10/15 14:21, Rick C. Hodgin wrote:
> > On Friday, October 30, 2015 at 9:11:05 AM UTC-4, David Brown wrote:
> >> On 30/10/15 12:35, Rick C. Hodgin wrote:
> >>> On Friday, October 30, 2015 at 5:39:07 AM UTC-4, Ben Bacarisse wrote:
> >>>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >>>>
> >>>>> On Thursday, October 29, 2015 at 9:27:29 PM UTC-4, Ian Collins wrote:
> >>>> <snip>
> >>>>> So, with angels you use:
> >>>>>
> >>>>> AWhatever w;
> >>>>> something(w("1"), w("2"), w("3"));
> >>>>> // At this point, no instance of w remains in scope
> >>>>
> >>>> Somewhat topical: you are confusing scope and lifetime: scope is a
> >>>> spacial property of a name; lifetime is a temporal property of an
> >>>> object. Obviously they are connected but "no instance of w remains in
> >>>> scope" is, at best, confusing.
> >>>
> >>> I have stopped responding to you because I see in my case and others,
> >>> you're often having trouble understanding the things people write. I
> >>> think you actually do understand in all cases, so it makes the response
> >>> pointless.
> >>
> >> I have found Ben's comments almost always to be accurate, considered,
> >> informed and to the point. He rates very highly on my list of people to
> >> listen to in this group. (But please don't reply to this point - I'd
> >> rather not have a discussion about people here.)
> >>
> >>>
> >>> However, it is very likely I'm using the terms improperly compared to
> >>> however they're defined in C or C++ because I don't know how they're
> >>> technically defined in C or C++.
> >>
> >> "scope" and "lifetime" are rather critical terms in most programming
> >> languages, and you must learn to understand them properly to use a
> >> language. It is certainly not possible to create a consistent and
> >> workable programming language without understanding the concepts, and
> >> you might as well get the terms right too.
> >>
> >> "scope" concerns names and identifiers - something is "in scope" if you
> >> can refer to the name, and "out of scope" if you cannot. "lifetime"
> >> concerns objects - their lifetime begins logically when they are created
> >> or initialised (and in C++, a constructor is called), and logically ends
> >> when they are destroyed (and in C++, a destructor may be called). I
> >> write "logically" here, because compilers are free to re-arrange the
> >> actual generated code as long as the logical effect is correct.
> >>
> >> Scope and lifetime often go hand-in-hand - this is true for automatic
> >> (stack) variables and temporaries. But they can be different. For
> >> example, file-level variables have program lifetimes and global scope.
> >> File-level statics have program lifetimes and file-level scope.
> >> Function local statics have program lifetimes and function-local scope
> >> (or block scope within a function). Objects created on a heap and
> >> returned outside the block in which they were allocated, have longer
> >> lifetimes than scope.
> >>
> >> In the case of your equivalent code, the temporaries tw1, tw2 and tw3
> >> are pointers whose scope and lifetimes are the same. The AWhatever
> >> objects have lifetimes stretching from when they are created by "new",
> >> until they are destroyed by "delete". But these objects have no scope -
> >> they have no names. Only the pointers to the objects have scope.
> >>
> >>
> >>> So... here goes:
> >>>
> >>> Internally, CAlive does this:
> >>>
> >>> // AWhatever w;
> >>> // something(w("1"), w("2"), w("3"));
> >>>
> >>> ||||||||||
> >>> ||| Equivalent of:
> >>> ||
> >>> || AWhatever* tw1 = new AWhatever("1");
> >>> || AWhatever* tw2 = new AWhatever("2");
> >>> || AWhatever* tw3 = new AWhatever("3"):
> >>> ||
> >>> || something(tw1, tw2, tw3);
> >>> ||
> >>> || delete tw1;
> >>> || delete tw2;
> >>> || delete tw3;
> >>> ||
> >>> ||||||
> >>>
> >>> // The names tw1, tw2, tw3 do not exist, and their instances do not
> >>> // exist. The tw1, tw2, and tw3 "slots" on the stack still exist,
> >>> // but they are out of scope (which, to me, means they are not longer
> >>> // viable entities, as whatever their destructors did is now done,
> >>> // only the allocated space for their static data members exist.
> >>> // If later code reused additional w("..") instances, those twN slots
> >>> // would be re-used, and the maximum number of twN slots allocated
> >>> // relates to the maximum number of concurrent instance uses found in
> >>> // source code.
> >>
> >>
> >> In C++, if you write:
> >>
> >> something(AWhatever("1"), AWhatever("2"), AWhatever("3"));
> >>
> >> it is roughly equivalent to:
> >>
> >> {
> >> // The order of these is not specified
> >> AWhatever tw1("1");
> >> AWhatever tw2("2");
> >> AWhatever tw3("3");
> >>
> >> something(tw1, tw2, tw3);
> >>
> >> // The tw1, tw2, tw3 go out of scope and are destructed
> >> // in reverse creation order
> >> }
> >>
> >> In other words, you already get the temporary nature of the objects in C++.
> >>
> >> Are you /sure/ that in CAlive, the temporary objects are constructed on
> >> the heap (with new/delete) rather than the stack, as they are in C++?
> >> Certainly stack allocation is a better choice in most cases, as it is
> >> far more efficient.
> >
> > They are on the stack. I use lnew and new to determine where runtime-
> > allocated classes, structs, and angels are allocated.
>
> Then why bother with all the extra pointers?
I don't understand the context of your question.
> >> And in C++, the destruction order is guaranteed to be the reverse of the
> >> construction order. Is that not also the case in CAlive?
> >
> > Not today. If that's a requirement in C++ then I can make it be that
> > way. I had planned on them being released in the order they were
> > allocated. As such, I'll probably make that a compiler option.
>
> Controlled, guaranteed reverse construction order for destructors is
> absolutely crucial to RAII, which is a cornerstone of C++. It means you
> can wrap your resource acquisition in class constructors, and their
> release in class destructors, and know /exactly/ how and when they are
> acquired and released in code.
I'm not writing C++. And what I'm writing in CAlive are those features
which are desirable for C developers to also have access to (as per my
opinion, and any strong arguments made by others).
> (Of course, a compiler can re-arrange destructors if there is no logical
> difference, just like for any other code.)
How could it determine that it is a non-issue to re-arrange them? If
the rule applies, it should always apply.
> >>> -----
> >>> Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
> >>> allowing for visual groupings like the above example.
> >>>
> >>
> >> Now I /know/ you are joking. What is wrong with using spaces for white
> >> space? And what insanity possessed you to make long lists of bar
> >> characters, where even numbers means white space and odd numbers mean
> >> comments?
> >
> > The grouped appearance of text above answers your question. It is
> > obvious to the eye at a glance that that block of code is related.
>
> White space does that fine too. And a bit of syntax highlighting, such
> as italics or a different colour for comments, makes it even easier.
Sorry, Charlie. You'll never convince me and my dyslexic eyes. If you
look through my source code you'll see frequent use of extra vertical
spacing, and even large block markers, like this:
//////////
// Initialize
//////
if ((func = iFunction_allocate()))
{
memset(func, 0, sizeof(func));
} else {
iError_report_byNumber(_ERROR_CODE, ...);
}
//////////
// Populate
//////
func->member1 = value1;
func->member2 = value2;
Which then with the use of pipe-signs can be ever more clear:
||||||||||
||| Initialize
||
|| if ((func = iFunction_allocate()))
|| {
|| memset(func, 0, sizeof(func));
||
|| } else {
|| iError_report_byNumber(_ERROR_CODE, ...);
|| }
||
||||||
||||||||||
||| Populate
||
|| func->member1 = value1;
|| func->member2 = value2;
||
||||||
And, with GUI features of the editor, the pipe signs do not need to
be displayed, but instead each block can be wrapped into its own cask,
allowing the re-arranging of source code groupings as easily as a drag-
and-drop operation.
> > In addition, within the debugger, it allows you to do a special kind
> > of single-step debugging, called a single-group-step, allowing you
> > to step over concepts in your code, and not just mechanical lines.
> >
>
> Other debuggers do that fine today - the grouping is called "functions".
> Another option is "run to line", or putting breakpoints at steps in the
> code.
It's not the same, and you know it.
> You might like to introduce a kind of breakpoint and stepping so that a
> step-breakpoint is only enabled for breaking if you are doing
> group-stepping - then the user can easily add or remove such
> step-breakpoints as needed, without changing the source code. That
> would be a useful debugging feature, I think.
Yes.
I have also introduced something called a codepoint. It's like a
breakpoint in that it will trigger under the same conditions as a
breakpoint, but instead of breaking at that location and halting
execution, it instead executes the code you've given it.
Codepoints can be created at development time, or at run-time while
debugging. And they inherit the full environment from where they
are inserted, so you could add fixups, tests, dump-to-files, etc.
I have many more ideas. I'm working on them as fast as I can with
a job, family, church activities, and then using all of my spare
time evenings, weekends, and holidays.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-31 11:09 +1300 |
| Message-ID | <d9i85jF2lrhU8@mid.individual.net> |
| In reply to | #74329 |
Rick C. Hodgin wrote: > On Friday, October 30, 2015 at 11:43:29 AM UTC-4, David Brown wrote: >> >> Controlled, guaranteed reverse construction order for destructors is >> absolutely crucial to RAII, which is a cornerstone of C++. It means you >> can wrap your resource acquisition in class constructors, and their >> release in class destructors, and know /exactly/ how and when they are >> acquired and released in code. > > I'm not writing C++. And what I'm writing in CAlive are those features > which are desirable for C developers to also have access to (as per my > opinion, and any strong arguments made by others). Consistent, deterministic behaviour should be desirable features. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-30 15:19 -0700 |
| Message-ID | <52ea4d53-d3e2-4b89-a841-d6bc297c98a5@googlegroups.com> |
| In reply to | #74374 |
On Friday, October 30, 2015 at 6:10:07 PM UTC-4, Ian Collins wrote: > Rick C. Hodgin wrote: > > On Friday, October 30, 2015 at 11:43:29 AM UTC-4, David Brown wrote: > >> > >> Controlled, guaranteed reverse construction order for destructors is > >> absolutely crucial to RAII, which is a cornerstone of C++. It means you > >> can wrap your resource acquisition in class constructors, and their > >> release in class destructors, and know /exactly/ how and when they are > >> acquired and released in code. > > > > I'm not writing C++. And what I'm writing in CAlive are those features > > which are desirable for C developers to also have access to (as per my > > opinion, and any strong arguments made by others). > > Consistent, deterministic behaviour should be desirable features. Of course. And within CAlive, it will be. Comparing CAlive to C++ is not valid though, except in most ways that CAlive supports. There will be differences. And, since the source code base will be open, anyone can add options to remove this differences as desired. I don't expect many C or C++ developers to ever even try CAlive, let alone use it (should it be released and working like it should on real production code). I expect it will be new developers from other languages coming to a C-like language who will use it, and for the syntax reasons I'm establishing. We'll see though. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-01 00:47 +0100 |
| Message-ID | <n13jqu$dpa$1@dont-email.me> |
| In reply to | #74329 |
On 30/10/15 16:55, Rick C. Hodgin wrote:
> On Friday, October 30, 2015 at 11:43:29 AM UTC-4, David Brown wrote:
>> On 30/10/15 14:21, Rick C. Hodgin wrote:
>>> On Friday, October 30, 2015 at 9:11:05 AM UTC-4, David Brown wrote:
>>>> On 30/10/15 12:35, Rick C. Hodgin wrote:
>>>>> On Friday, October 30, 2015 at 5:39:07 AM UTC-4, Ben Bacarisse wrote:
<snip>
>>>> Are you /sure/ that in CAlive, the temporary objects are constructed on
>>>> the heap (with new/delete) rather than the stack, as they are in C++?
>>>> Certainly stack allocation is a better choice in most cases, as it is
>>>> far more efficient.
>>>
>>> They are on the stack. I use lnew and new to determine where runtime-
>>> allocated classes, structs, and angels are allocated.
>>
>> Then why bother with all the extra pointers?
>
> I don't understand the context of your question.
You said that the angel objects are allocated on the stack, rather than
the heap. But in your equivalent code, you allocated pointers
(presumably also on the stack) whose purpose is to point to the angel
objects on the stack. That looks to me like an extra level of pointers
for no purpose. But perhaps it is just an artefact of trying to write
equivalent code in C++. If so, then don't worry about it.
>
>>>> And in C++, the destruction order is guaranteed to be the reverse of the
>>>> construction order. Is that not also the case in CAlive?
>>>
>>> Not today. If that's a requirement in C++ then I can make it be that
>>> way. I had planned on them being released in the order they were
>>> allocated. As such, I'll probably make that a compiler option.
>>
>> Controlled, guaranteed reverse construction order for destructors is
>> absolutely crucial to RAII, which is a cornerstone of C++. It means you
>> can wrap your resource acquisition in class constructors, and their
>> release in class destructors, and know /exactly/ how and when they are
>> acquired and released in code.
>
> I'm not writing C++. And what I'm writing in CAlive are those features
> which are desirable for C developers to also have access to (as per my
> opinion, and any strong arguments made by others).
If objects are a feature of your language, and they have clear lifetime
rules, then predictable destructor call position and order is extremely
desirable - it allows all sorts of useful techniques, including RAII.
Some languages have other object models that don't have predictable
"deaths" - usually because the language uses garbage collection to tidy
them up some time after they are no longer in use. For languages such
as Python, you can't use RAII - that's one of the prices you pay for the
convenience of garbage collection. A language which does not have
garbage collection, and does not have a clear destructor place and
order, is the worst of both worlds. But from how I understand your
language so far, calling destructors in the reverse creation order
should not be a difficult improvement.
>
>> (Of course, a compiler can re-arrange destructors if there is no logical
>> difference, just like for any other code.)
>
> How could it determine that it is a non-issue to re-arrange them? If
> the rule applies, it should always apply.
Compilers can optimise following the "as if" rule - they can re-arrange
generated code as they like, as long as all effects applied "as if"
there were no re-arrangement. This is key to optimisation. It is
likely that you don't want to get too involved in optimisation at this
stage in your development of CAlive, but it is worth keeping in mind for
the future. The more you are able to get the compiler to automatically
optimise code, the less your users have to think about it.
>
>>>>> -----
>>>>> Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
>>>>> allowing for visual groupings like the above example.
>>>>>
>>>>
>>>> Now I /know/ you are joking. What is wrong with using spaces for white
>>>> space? And what insanity possessed you to make long lists of bar
>>>> characters, where even numbers means white space and odd numbers mean
>>>> comments?
>>>
>>> The grouped appearance of text above answers your question. It is
>>> obvious to the eye at a glance that that block of code is related.
>>
>> White space does that fine too. And a bit of syntax highlighting, such
>> as italics or a different colour for comments, makes it even easier.
>
> Sorry, Charlie. You'll never convince me and my dyslexic eyes. If you
> look through my source code you'll see frequent use of extra vertical
> spacing, and even large block markers, like this:
>
> //////////
> // Initialize
> //////
> if ((func = iFunction_allocate()))
> {
> memset(func, 0, sizeof(func));
>
> } else {
> iError_report_byNumber(_ERROR_CODE, ...);
> }
>
>
> //////////
> // Populate
> //////
> func->member1 = value1;
> func->member2 = value2;
>
I don't think that looks clearer or easier to read, but fair enough -
these things are somewhat a matter of preference.
> Which then with the use of pipe-signs can be ever more clear:
>
> ||||||||||
> ||| Initialize
> ||
> || if ((func = iFunction_allocate()))
> || {
> || memset(func, 0, sizeof(func));
> ||
> || } else {
> || iError_report_byNumber(_ERROR_CODE, ...);
> || }
> ||
> ||||||
>
>
>
> ||||||||||
> ||| Populate
> ||
> || func->member1 = value1;
> || func->member2 = value2;
> ||
> ||||||
>
Here I disagree entirely - I fail to see any reason why pipe symbols
should be so dramatically clearer than slashes. And I fail to see why a
vertical band on the left helps. Instead of clear white space
surrounding the code, you've got visual noise reducing the contrast and
making it harder to view.
> And, with GUI features of the editor, the pipe signs do not need to
> be displayed, but instead each block can be wrapped into its own cask,
> allowing the re-arranging of source code groupings as easily as a drag-
> and-drop operation.
Then why bother putting the pipe signs in the source at all? Just make
the lines, colours, folds, groups, etc., part of the gui display.
>
>>> In addition, within the debugger, it allows you to do a special kind
>>> of single-step debugging, called a single-group-step, allowing you
>>> to step over concepts in your code, and not just mechanical lines.
>>>
>>
>> Other debuggers do that fine today - the grouping is called "functions".
>> Another option is "run to line", or putting breakpoints at steps in the
>> code.
>
> It's not the same, and you know it.
It is good enough. I think if you regularly need a level of stepping
size somewhere between line and function, you probably should write
shorter functions.
>
>> You might like to introduce a kind of breakpoint and stepping so that a
>> step-breakpoint is only enabled for breaking if you are doing
>> group-stepping - then the user can easily add or remove such
>> step-breakpoints as needed, without changing the source code. That
>> would be a useful debugging feature, I think.
>
> Yes.
>
> I have also introduced something called a codepoint. It's like a
> breakpoint in that it will trigger under the same conditions as a
> breakpoint, but instead of breaking at that location and halting
> execution, it instead executes the code you've given it.
Such "codepoints" are not a new invention - many other debuggers have
them. But I agree that they can be a useful feature.
<https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html>
>
> Codepoints can be created at development time, or at run-time while
> debugging. And they inherit the full environment from where they
> are inserted, so you could add fixups, tests, dump-to-files, etc.
>
> I have many more ideas. I'm working on them as fast as I can with
> a job, family, church activities, and then using all of my spare
> time evenings, weekends, and holidays.
>
> Best regards,
> Rick C. Hodgin
>
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-31 17:24 -0700 |
| Message-ID | <eaf45765-1ca2-494c-9ac7-50fea508e4c8@googlegroups.com> |
| In reply to | #74507 |
On Saturday, October 31, 2015 at 7:47:58 PM UTC-4, David Brown wrote:
> On 30/10/15 16:55, Rick C. Hodgin wrote:
> > On Friday, October 30, 2015 at 11:43:29 AM UTC-4, David Brown wrote:
> >> On 30/10/15 14:21, Rick C. Hodgin wrote:
> >>> On Friday, October 30, 2015 at 9:11:05 AM UTC-4, David Brown wrote:
> >>>> On 30/10/15 12:35, Rick C. Hodgin wrote:
> >>>>> On Friday, October 30, 2015 at 5:39:07 AM UTC-4, Ben Bacarisse wrote:
> <snip>
> >>>> Are you /sure/ that in CAlive, the temporary objects are constructed on
> >>>> the heap (with new/delete) rather than the stack, as they are in C++?
> >>>> Certainly stack allocation is a better choice in most cases, as it is
> >>>> far more efficient.
> >>>
> >>> They are on the stack. I use lnew and new to determine where runtime-
> >>> allocated classes, structs, and angels are allocated.
> >>
> >> Then why bother with all the extra pointers?
> >
> > I don't understand the context of your question.
>
> You said that the angel objects are allocated on the stack, rather than
> the heap. But in your equivalent code, you allocated pointers
> (presumably also on the stack) whose purpose is to point to the angel
> objects on the stack. That looks to me like an extra level of pointers
> for no purpose. But perhaps it is just an artefact of trying to write
> equivalent code in C++. If so, then don't worry about it.
>
> >
> >>>> And in C++, the destruction order is guaranteed to be the reverse of the
> >>>> construction order. Is that not also the case in CAlive?
> >>>
> >>> Not today. If that's a requirement in C++ then I can make it be that
> >>> way. I had planned on them being released in the order they were
> >>> allocated. As such, I'll probably make that a compiler option.
> >>
> >> Controlled, guaranteed reverse construction order for destructors is
> >> absolutely crucial to RAII, which is a cornerstone of C++. It means you
> >> can wrap your resource acquisition in class constructors, and their
> >> release in class destructors, and know /exactly/ how and when they are
> >> acquired and released in code.
> >
> > I'm not writing C++. And what I'm writing in CAlive are those features
> > which are desirable for C developers to also have access to (as per my
> > opinion, and any strong arguments made by others).
>
> If objects are a feature of your language, and they have clear lifetime
> rules, then predictable destructor call position and order is extremely
> desirable - it allows all sorts of useful techniques, including RAII.
This was always my intention. However, I was going to have them
destructed in the same order allocated, and not in reverse order.
And as indicated, I will probably make that an option now.
> Some languages have other object models that don't have predictable
> "deaths" - usually because the language uses garbage collection to tidy
> them up some time after they are no longer in use.
I plan on implementing that in my managed data support. Anything that's
allocated using managed data will operate differently than machine data.
> For languages such
> as Python, you can't use RAII - that's one of the prices you pay for the
> convenience of garbage collection. A language which does not have
> garbage collection, and does not have a clear destructor place and
> order, is the worst of both worlds. But from how I understand your
> language so far, calling destructors in the reverse creation order
> should not be a difficult improvement.
It will be an "option," and not necessarily an improvement. :-)
> >> (Of course, a compiler can re-arrange destructors if there is no logical
> >> difference, just like for any other code.)
> >
> > How could it determine that it is a non-issue to re-arrange them? If
> > the rule applies, it should always apply.
>
> Compilers can optimise following the "as if" rule - they can re-arrange
> generated code as they like, as long as all effects applied "as if"
> there were no re-arrangement. This is key to optimisation. It is
> likely that you don't want to get too involved in optimisation at this
> stage in your development of CAlive, but it is worth keeping in mind for
> the future. The more you are able to get the compiler to automatically
> optimise code, the less your users have to think about it.
I don't think I will ever support optimizations which change things
from the developer's definition, except where the developer goes in
to source code explicitly and signs off on optimizations being
applied.
I'd like to see something like this before an optimization is applied:
struct SWhatever
{
#optimizations on
char member1;
int member2;
double member3;
char* member4;
};
Or to use specific ones:
#optimizations pack, padd, reorder, etc...
Through the GUI editor I'll probably eventually provide a way to note
the impact of each of those as the LiveCode compiler will provide near
real-time feedback on all changes.
> >>>>> Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
> >>>>> allowing for visual groupings like the above example.
> >>>>>
> >>>>
> >>>> Now I /know/ you are joking. What is wrong with using spaces for white
> >>>> space? And what insanity possessed you to make long lists of bar
> >>>> characters, where even numbers means white space and odd numbers mean
> >>>> comments?
> >>>
> >>> The grouped appearance of text above answers your question. It is
> >>> obvious to the eye at a glance that that block of code is related.
> >>
> >> White space does that fine too. And a bit of syntax highlighting, such
> >> as italics or a different colour for comments, makes it even easier.
> >
> > Sorry, Charlie. You'll never convince me and my dyslexic eyes. If you
> > look through my source code you'll see frequent use of extra vertical
> > spacing, and even large block markers, like this:
> >
> > //////////
> > // Initialize
> > //////
> > if ((func = iFunction_allocate()))
> > {
> > memset(func, 0, sizeof(func));
> >
> > } else {
> > iError_report_byNumber(_ERROR_CODE, ...);
> > }
> >
> >
> > //////////
> > // Populate
> > //////
> > func->member1 = value1;
> > func->member2 = value2;
> >
>
> I don't think that looks clearer or easier to read, but fair enough -
> these things are somewhat a matter of preference.
My eyes don't read words well. It's actually very difficult for me
to read. So, by putting things into groups where my eyes can see
them not from reading, it makes it fantastically easier for me to
see.
> > Which then with the use of pipe-signs can be ever more clear:
> >
> > ||||||||||
> > ||| Initialize
> > ||
> > || if ((func = iFunction_allocate()))
> > || {
> > || memset(func, 0, sizeof(func));
> > ||
> > || } else {
> > || iError_report_byNumber(_ERROR_CODE, ...);
> > || }
> > ||
> > ||||||
> >
> >
> >
> > ||||||||||
> > ||| Populate
> > ||
> > || func->member1 = value1;
> > || func->member2 = value2;
> > ||
> > ||||||
> >
>
> Here I disagree entirely - I fail to see any reason why pipe symbols
> should be so dramatically clearer than slashes.
It's not that they're dramatically clearer than slashes, but since the
purpose of the (now) ||| whitespace symbol is to correlate vertical
lines together, having then a // comment at the top seemed odd... so
I just also introduced the (now) |||| comment so it goes together.
> And I fail to see why a
> vertical band on the left helps. Instead of clear white space
> surrounding the code, you've got visual noise reducing the contrast and
> making it harder to view.
For my eyes, it is amazingly grouping. I can see at a glance that all
of that interspaced code within (that normally to me looks like a mass
quagmire of visual confusion) is related.
> > And, with GUI features of the editor, the pipe signs do not need to
> > be displayed, but instead each block can be wrapped into its own cask,
> > allowing the re-arranging of source code groupings as easily as a drag-
> > and-drop operation.
>
> Then why bother putting the pipe signs in the source at all? Just make
> the lines, colours, folds, groups, etc., part of the gui display.
So it shows up in text as well as within the GUI editor. It will also
pass through the multiple iterations of compilation and optimization
on its way down to machine code, and that will aid in group-step
debugging.
> >>> In addition, within the debugger, it allows you to do a special kind
> >>> of single-step debugging, called a single-group-step, allowing you
> >>> to step over concepts in your code, and not just mechanical lines.
> >>>
> >>
> >> Other debuggers do that fine today - the grouping is called "functions".
> >> Another option is "run to line", or putting breakpoints at steps in the
> >> code.
> >
> > It's not the same, and you know it.
>
> It is good enough. I think if you regularly need a level of stepping
> size somewhere between line and function, you probably should write
> shorter functions.
My debugger supports the standard forms as well. This is a new form
which allows you to step over concepts in code, rather than mechanical
details. It has utility.
> >> You might like to introduce a kind of breakpoint and stepping so that a
> >> step-breakpoint is only enabled for breaking if you are doing
> >> group-stepping - then the user can easily add or remove such
> >> step-breakpoints as needed, without changing the source code. That
> >> would be a useful debugging feature, I think.
> >
> > Yes.
> >
> > I have also introduced something called a codepoint. It's like a
> > breakpoint in that it will trigger under the same conditions as a
> > breakpoint, but instead of breaking at that location and halting
> > execution, it instead executes the code you've given it.
>
> Such "codepoints" are not a new invention - many other debuggers have
> them. But I agree that they can be a useful feature.
>
> <https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html>
Not quite the same, but similar. Codepoints are actually compiled
into the binary and do not trigger breaks to the debugger. It's
one of the features of the LiveCode ABI.
> > Codepoints can be created at development time, or at run-time while
> > debugging. And they inherit the full environment from where they
> > are inserted, so you could add fixups, tests, dump-to-files, etc.
> >
> > I have many more ideas. I'm working on them as fast as I can with
> > a job, family, church activities, and then using all of my spare
> > time evenings, weekends, and holidays.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-01 23:39 +0100 |
| Message-ID | <n1647g$85g$1@dont-email.me> |
| In reply to | #74511 |
On 01/11/15 01:24, Rick C. Hodgin wrote:
> On Saturday, October 31, 2015 at 7:47:58 PM UTC-4, David Brown wrote:
>> On 30/10/15 16:55, Rick C. Hodgin wrote:
>>> On Friday, October 30, 2015 at 11:43:29 AM UTC-4, David Brown wrote:
>>>> On 30/10/15 14:21, Rick C. Hodgin wrote:
>>>>> On Friday, October 30, 2015 at 9:11:05 AM UTC-4, David Brown wrote:
>>>>>> On 30/10/15 12:35, Rick C. Hodgin wrote:
<snip>
>> If objects are a feature of your language, and they have clear lifetime
>> rules, then predictable destructor call position and order is extremely
>> desirable - it allows all sorts of useful techniques, including RAII.
>
> This was always my intention. However, I was going to have them
> destructed in the same order allocated, and not in reverse order.
> And as indicated, I will probably make that an option now.
>
As always in such cases, I would recommend you to think through the
implications of each option, then pick /one/ method and make it the only
one. Too many options is confusing, complicated, and greatly increases
the chances of people making subtle mistakes. If you agree with me that
reverse construction order is the best choice for destructor orders,
then make it that way. If you have good reason for picking constructor
order, then make it /that/ way. It is much clearer to the user that
there is /one/ order, and that if they have code that would work best
with the other order, then they will have to find a different solution
to their problem.
Too much choice is a bad thing - just as bad as too little choice.
>> Some languages have other object models that don't have predictable
>> "deaths" - usually because the language uses garbage collection to tidy
>> them up some time after they are no longer in use.
>
> I plan on implementing that in my managed data support. Anything that's
> allocated using managed data will operate differently than machine data.
>
>> For languages such
>> as Python, you can't use RAII - that's one of the prices you pay for the
>> convenience of garbage collection. A language which does not have
>> garbage collection, and does not have a clear destructor place and
>> order, is the worst of both worlds. But from how I understand your
>> language so far, calling destructors in the reverse creation order
>> should not be a difficult improvement.
>
> It will be an "option," and not necessarily an improvement. :-)
>
>>>> (Of course, a compiler can re-arrange destructors if there is no logical
>>>> difference, just like for any other code.)
>>>
>>> How could it determine that it is a non-issue to re-arrange them? If
>>> the rule applies, it should always apply.
>>
>> Compilers can optimise following the "as if" rule - they can re-arrange
>> generated code as they like, as long as all effects applied "as if"
>> there were no re-arrangement. This is key to optimisation. It is
>> likely that you don't want to get too involved in optimisation at this
>> stage in your development of CAlive, but it is worth keeping in mind for
>> the future. The more you are able to get the compiler to automatically
>> optimise code, the less your users have to think about it.
>
> I don't think I will ever support optimizations which change things
> from the developer's definition, except where the developer goes in
> to source code explicitly and signs off on optimizations being
> applied.
>
> I'd like to see something like this before an optimization is applied:
>
> struct SWhatever
> {
> #optimizations on
> char member1;
> int member2;
> double member3;
> char* member4;
> };
>
> Or to use specific ones:
>
> #optimizations pack, padd, reorder, etc...
>
> Through the GUI editor I'll probably eventually provide a way to note
> the impact of each of those as the LiveCode compiler will provide near
> real-time feedback on all changes.
The idea is that optimisations do not affect the way the code runs, as
seen by the programmer or by visible effects. These should not be
something the user has to control explicitly - if the compiler can
handle optimisation better, then the programmer can be free to write
clearer and simpler code.
However, I understand you have a greater emphasis on debugging than is
usual in compiled languages, and that can easily limit the possibilities
for optimisation (in particular, you can't re-arrange code, and you
can't eliminate unneeded code or calculations).
>
>>>>>>> Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
>>>>>>> allowing for visual groupings like the above example.
>>>>>>>
>>>>>>
>>>>>> Now I /know/ you are joking. What is wrong with using spaces for white
>>>>>> space? And what insanity possessed you to make long lists of bar
>>>>>> characters, where even numbers means white space and odd numbers mean
>>>>>> comments?
>>>>>
>>>>> The grouped appearance of text above answers your question. It is
>>>>> obvious to the eye at a glance that that block of code is related.
>>>>
>>>> White space does that fine too. And a bit of syntax highlighting, such
>>>> as italics or a different colour for comments, makes it even easier.
>>>
>>> Sorry, Charlie. You'll never convince me and my dyslexic eyes. If you
>>> look through my source code you'll see frequent use of extra vertical
>>> spacing, and even large block markers, like this:
>>>
>>> //////////
>>> // Initialize
>>> //////
>>> if ((func = iFunction_allocate()))
>>> {
>>> memset(func, 0, sizeof(func));
>>>
>>> } else {
>>> iError_report_byNumber(_ERROR_CODE, ...);
>>> }
>>>
>>>
>>> //////////
>>> // Populate
>>> //////
>>> func->member1 = value1;
>>> func->member2 = value2;
>>>
>>
>> I don't think that looks clearer or easier to read, but fair enough -
>> these things are somewhat a matter of preference.
>
> My eyes don't read words well. It's actually very difficult for me
> to read. So, by putting things into groups where my eyes can see
> them not from reading, it makes it fantastically easier for me to
> see.
Grouping is good - I understand that. But I would want to minimise the
visual noise of extra symbols, precisely to make code clearer and easier
to read. But okay, enough said about that.
>
>>> Which then with the use of pipe-signs can be ever more clear:
>>>
>>> ||||||||||
>>> ||| Initialize
>>> ||
>>> || if ((func = iFunction_allocate()))
>>> || {
>>> || memset(func, 0, sizeof(func));
>>> ||
>>> || } else {
>>> || iError_report_byNumber(_ERROR_CODE, ...);
>>> || }
>>> ||
>>> ||||||
>>>
>>>
>>>
>>> ||||||||||
>>> ||| Populate
>>> ||
>>> || func->member1 = value1;
>>> || func->member2 = value2;
>>> ||
>>> ||||||
>>>
>>
>> Here I disagree entirely - I fail to see any reason why pipe symbols
>> should be so dramatically clearer than slashes.
>
> It's not that they're dramatically clearer than slashes, but since the
> purpose of the (now) ||| whitespace symbol is to correlate vertical
> lines together, having then a // comment at the top seemed odd... so
> I just also introduced the (now) |||| comment so it goes together.
>
>> And I fail to see why a
>> vertical band on the left helps. Instead of clear white space
>> surrounding the code, you've got visual noise reducing the contrast and
>> making it harder to view.
>
> For my eyes, it is amazingly grouping. I can see at a glance that all
> of that interspaced code within (that normally to me looks like a mass
> quagmire of visual confusion) is related.
>
>>> And, with GUI features of the editor, the pipe signs do not need to
>>> be displayed, but instead each block can be wrapped into its own cask,
>>> allowing the re-arranging of source code groupings as easily as a drag-
>>> and-drop operation.
>>
>> Then why bother putting the pipe signs in the source at all? Just make
>> the lines, colours, folds, groups, etc., part of the gui display.
>
> So it shows up in text as well as within the GUI editor. It will also
> pass through the multiple iterations of compilation and optimization
> on its way down to machine code, and that will aid in group-step
> debugging.
>
>>>>> In addition, within the debugger, it allows you to do a special kind
>>>>> of single-step debugging, called a single-group-step, allowing you
>>>>> to step over concepts in your code, and not just mechanical lines.
>>>>>
>>>>
>>>> Other debuggers do that fine today - the grouping is called "functions".
>>>> Another option is "run to line", or putting breakpoints at steps in the
>>>> code.
>>>
>>> It's not the same, and you know it.
>>
>> It is good enough. I think if you regularly need a level of stepping
>> size somewhere between line and function, you probably should write
>> shorter functions.
>
> My debugger supports the standard forms as well. This is a new form
> which allows you to step over concepts in code, rather than mechanical
> details. It has utility.
I struggle to see how much utility it would have for the way /I/ use a
debugger - but viewed from /your/ point of view, with the heavy emphasis
on running things within the debugger (and even changing code while
debugging), I can see the use of it for your CAlive system. I don't
like the way you are expressing it in code with hoards of pipe systems,
but I /do/ like the idea of group or concept steps.
>
>>>> You might like to introduce a kind of breakpoint and stepping so that a
>>>> step-breakpoint is only enabled for breaking if you are doing
>>>> group-stepping - then the user can easily add or remove such
>>>> step-breakpoints as needed, without changing the source code. That
>>>> would be a useful debugging feature, I think.
>>>
>>> Yes.
>>>
>>> I have also introduced something called a codepoint. It's like a
>>> breakpoint in that it will trigger under the same conditions as a
>>> breakpoint, but instead of breaking at that location and halting
>>> execution, it instead executes the code you've given it.
>>
>> Such "codepoints" are not a new invention - many other debuggers have
>> them. But I agree that they can be a useful feature.
>>
>> <https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html>
>
> Not quite the same, but similar. Codepoints are actually compiled
> into the binary and do not trigger breaks to the debugger. It's
> one of the features of the LiveCode ABI.
OK, that is somewhat different. I am sceptical to its benefits, but
only because I am sceptical to your whole program-while-debugging
concept. But I can see why it fits with the philosophy you have, and it
given that philosophy, it is a genuinely interesting and potentially
useful idea.
>
>>> Codepoints can be created at development time, or at run-time while
>>> debugging. And they inherit the full environment from where they
>>> are inserted, so you could add fixups, tests, dump-to-files, etc.
>>>
>>> I have many more ideas. I'm working on them as fast as I can with
>>> a job, family, church activities, and then using all of my spare
>>> time evenings, weekends, and holidays.
>
> Best regards,
> Rick C. Hodgin
>
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-01 16:50 -0800 |
| Message-ID | <a7e92afe-2a75-4779-ad8b-1d4785876c62@googlegroups.com> |
| In reply to | #74591 |
On Sunday, November 1, 2015 at 5:40:03 PM UTC-5, David Brown wrote:
> On 01/11/15 01:24, Rick C. Hodgin wrote:
> > On Saturday, October 31, 2015 at 7:47:58 PM UTC-4, David Brown wrote:
> >> On 30/10/15 16:55, Rick C. Hodgin wrote:
> >>> On Friday, October 30, 2015 at 11:43:29 AM UTC-4, David Brown wrote:
> >>>> On 30/10/15 14:21, Rick C. Hodgin wrote:
> >>>>> On Friday, October 30, 2015 at 9:11:05 AM UTC-4, David Brown wrote:
> >>>>>> On 30/10/15 12:35, Rick C. Hodgin wrote:
> <snip>
> >> If objects are a feature of your language, and they have clear lifetime
> >> rules, then predictable destructor call position and order is extremely
> >> desirable - it allows all sorts of useful techniques, including RAII.
> >
> > This was always my intention. However, I was going to have them
> > destructed in the same order allocated, and not in reverse order.
> > And as indicated, I will probably make that an option now.
>
> As always in such cases, I would recommend you to think through the
> implications of each option, then pick /one/ method and make it the only
> one. Too many options is confusing, complicated, and greatly increases
> the chances of people making subtle mistakes. If you agree with me that
> reverse construction order is the best choice for destructor orders,
> then make it that way. If you have good reason for picking constructor
> order, then make it /that/ way. It is much clearer to the user that
> there is /one/ order, and that if they have code that would work best
> with the other order, then they will have to find a different solution
> to their problem.
>
> Too much choice is a bad thing - just as bad as too little choice.
I think having a choice is a good thing. I'll also provide a #pragma
per function which lets the function possess an override which sets
it explicitly there. And with all #pragmas, CAlive allows the "force"
keyword to be used, which will override command line choices.
> >> Some languages have other object models that don't have predictable
> >> "deaths" - usually because the language uses garbage collection to tidy
> >> them up some time after they are no longer in use.
> >
> > I plan on implementing that in my managed data support. Anything that's
> > allocated using managed data will operate differently than machine data.
> >
> >> For languages such
> >> as Python, you can't use RAII - that's one of the prices you pay for the
> >> convenience of garbage collection. A language which does not have
> >> garbage collection, and does not have a clear destructor place and
> >> order, is the worst of both worlds. But from how I understand your
> >> language so far, calling destructors in the reverse creation order
> >> should not be a difficult improvement.
> >
> > It will be an "option," and not necessarily an improvement. :-)
> >
> >>>> (Of course, a compiler can re-arrange destructors if there is no logical
> >>>> difference, just like for any other code.)
> >>>
> >>> How could it determine that it is a non-issue to re-arrange them? If
> >>> the rule applies, it should always apply.
> >>
> >> Compilers can optimise following the "as if" rule - they can re-arrange
> >> generated code as they like, as long as all effects applied "as if"
> >> there were no re-arrangement. This is key to optimisation. It is
> >> likely that you don't want to get too involved in optimisation at this
> >> stage in your development of CAlive, but it is worth keeping in mind for
> >> the future. The more you are able to get the compiler to automatically
> >> optimise code, the less your users have to think about it.
> >
> > I don't think I will ever support optimizations which change things
> > from the developer's definition, except where the developer goes in
> > to source code explicitly and signs off on optimizations being
> > applied.
> >
> > I'd like to see something like this before an optimization is applied:
> >
> > struct SWhatever
> > {
> > #optimizations on
> > char member1;
> > int member2;
> > double member3;
> > char* member4;
> > };
> >
> > Or to use specific ones:
> >
> > #optimizations pack, padd, reorder, etc...
> >
> > Through the GUI editor I'll probably eventually provide a way to note
> > the impact of each of those as the LiveCode compiler will provide near
> > real-time feedback on all changes.
>
> The idea is that optimisations do not affect the way the code runs, as
> seen by the programmer or by visible effects. These should not be
> something the user has to control explicitly - if the compiler can
> handle optimisation better, then the programmer can be free to write
> clearer and simpler code.
I cannot make that choice for a developer. I do not know what
optimizations do not affect the way the code runs, because from
CAlive's point of view, writing printf("Hi, mom!"); is the process
of passing a char[] string to the printf() function, and not the
C-like process of putting some output out.
CAlive is a mechanical translator, doing what the author instructs
in code. And where they allow optimizations to take place, they
will (eventually). And where they do not, they will not.
> However, I understand you have a greater emphasis on debugging than is
> usual in compiled languages, and that can easily limit the possibilities
> for optimisation (in particular, you can't re-arrange code, and you
> can't eliminate unneeded code or calculations).
Remember, it's "Rapid DEVELOPMENT Compiler." The goals are in the
developer writing code. Optimization comes later, and with the RDC
framework, it will definitely be about the last thing I target in
any regard beyond superficial optimizations that yield themselves
to be totally and completely obvious.
> >>>>>>> Oh, and CAlive also introduces the || whitespace, and the ||| line comment,
> >>>>>>> allowing for visual groupings like the above example.
> >>>>>>>
> >>>>>>
> >>>>>> Now I /know/ you are joking. What is wrong with using spaces for white
> >>>>>> space? And what insanity possessed you to make long lists of bar
> >>>>>> characters, where even numbers means white space and odd numbers mean
> >>>>>> comments?
> >>>>>
> >>>>> The grouped appearance of text above answers your question. It is
> >>>>> obvious to the eye at a glance that that block of code is related.
> >>>>
> >>>> White space does that fine too. And a bit of syntax highlighting, such
> >>>> as italics or a different colour for comments, makes it even easier.
> >>>
> >>> Sorry, Charlie. You'll never convince me and my dyslexic eyes. If you
> >>> look through my source code you'll see frequent use of extra vertical
> >>> spacing, and even large block markers, like this:
> >>>
> >>> //////////
> >>> // Initialize
> >>> //////
> >>> if ((func = iFunction_allocate()))
> >>> {
> >>> memset(func, 0, sizeof(func));
> >>>
> >>> } else {
> >>> iError_report_byNumber(_ERROR_CODE, ...);
> >>> }
> >>>
> >>>
> >>> //////////
> >>> // Populate
> >>> //////
> >>> func->member1 = value1;
> >>> func->member2 = value2;
> >>>
> >>
> >> I don't think that looks clearer or easier to read, but fair enough -
> >> these things are somewhat a matter of preference.
> >
> > My eyes don't read words well. It's actually very difficult for me
> > to read. So, by putting things into groups where my eyes can see
> > them not from reading, it makes it fantastically easier for me to
> > see.
>
> Grouping is good - I understand that. But I would want to minimise the
> visual noise of extra symbols, precisely to make code clearer and easier
> to read. But okay, enough said about that.
That's why I introduced Side Coding. I was listening to your and
Bart's comments about the embedded nature of the ||| and ||||
actually being in source code for grouping, and I thought: What
else could I do to achieve the same thing? Someone had suggested
using something like html markup tags, but I don't like that idea.
So, I introduced the \|code|/ cask. I think it's a great solution
and I'm running with it. I've already also introduced it into my
XBASE language, called VXB.
> >>> Which then with the use of pipe-signs can be ever more clear:
> >>>
> >>> ||||||||||
> >>> ||| Initialize
> >>> ||
> >>> || if ((func = iFunction_allocate()))
> >>> || {
> >>> || memset(func, 0, sizeof(func));
> >>> ||
> >>> || } else {
> >>> || iError_report_byNumber(_ERROR_CODE, ...);
> >>> || }
> >>> ||
> >>> ||||||
> >>>
> >>>
> >>>
> >>> ||||||||||
> >>> ||| Populate
> >>> ||
> >>> || func->member1 = value1;
> >>> || func->member2 = value2;
> >>> ||
> >>> ||||||
> >>>
> >>
> >> Here I disagree entirely - I fail to see any reason why pipe symbols
> >> should be so dramatically clearer than slashes.
> >
> > It's not that they're dramatically clearer than slashes, but since the
> > purpose of the (now) ||| whitespace symbol is to correlate vertical
> > lines together, having then a // comment at the top seemed odd... so
> > I just also introduced the (now) |||| comment so it goes together.
> >
> >> And I fail to see why a
> >> vertical band on the left helps. Instead of clear white space
> >> surrounding the code, you've got visual noise reducing the contrast and
> >> making it harder to view.
> >
> > For my eyes, it is amazingly grouping. I can see at a glance that all
> > of that interspaced code within (that normally to me looks like a mass
> > quagmire of visual confusion) is related.
> >
> >>> And, with GUI features of the editor, the pipe signs do not need to
> >>> be displayed, but instead each block can be wrapped into its own cask,
> >>> allowing the re-arranging of source code groupings as easily as a drag-
> >>> and-drop operation.
> >>
> >> Then why bother putting the pipe signs in the source at all? Just make
> >> the lines, colours, folds, groups, etc., part of the gui display.
> >
> > So it shows up in text as well as within the GUI editor. It will also
> > pass through the multiple iterations of compilation and optimization
> > on its way down to machine code, and that will aid in group-step
> > debugging.
> >
> >>>>> In addition, within the debugger, it allows you to do a special kind
> >>>>> of single-step debugging, called a single-group-step, allowing you
> >>>>> to step over concepts in your code, and not just mechanical lines.
> >>>>>
> >>>>
> >>>> Other debuggers do that fine today - the grouping is called "functions".
> >>>> Another option is "run to line", or putting breakpoints at steps in the
> >>>> code.
> >>>
> >>> It's not the same, and you know it.
> >>
> >> It is good enough. I think if you regularly need a level of stepping
> >> size somewhere between line and function, you probably should write
> >> shorter functions.
> >
> > My debugger supports the standard forms as well. This is a new form
> > which allows you to step over concepts in code, rather than mechanical
> > details. It has utility.
>
> I struggle to see how much utility it would have for the way /I/ use a
> debugger - but viewed from /your/ point of view, with the heavy emphasis
> on running things within the debugger (and even changing code while
> debugging), I can see the use of it for your CAlive system. I don't
> like the way you are expressing it in code with hoards of pipe systems,
> but I /do/ like the idea of group or concept steps.
When CAlive is ready to use, you'll be able to code in CAlive like you
always have, using the C-style function declarations, everything. You
don't have to use any of the new features, and it will provide enough
compatibility with C/C++ that most all code will work properly with
zero changes. And eventually I'll add -c90 and -c99 support and then
I'll force as much compatibility as I can squeeze into it, so as to
give people a clear migration path from C to CAlive, and also from
limited C++ to CAlive.
> >>>> You might like to introduce a kind of breakpoint and stepping so that a
> >>>> step-breakpoint is only enabled for breaking if you are doing
> >>>> group-stepping - then the user can easily add or remove such
> >>>> step-breakpoints as needed, without changing the source code. That
> >>>> would be a useful debugging feature, I think.
> >>>
> >>> Yes.
> >>>
> >>> I have also introduced something called a codepoint. It's like a
> >>> breakpoint in that it will trigger under the same conditions as a
> >>> breakpoint, but instead of breaking at that location and halting
> >>> execution, it instead executes the code you've given it.
> >>
> >> Such "codepoints" are not a new invention - many other debuggers have
> >> them. But I agree that they can be a useful feature.
> >>
> >> <https://sourceware.org/gdb/onlinedocs/gdb/Break-Commands.html>
> >
> > Not quite the same, but similar. Codepoints are actually compiled
> > into the binary and do not trigger breaks to the debugger. It's
> > one of the features of the LiveCode ABI.
>
> OK, that is somewhat different. I am sceptical to its benefits, but
> only because I am sceptical to your whole program-while-debugging
> concept. But I can see why it fits with the philosophy you have, and it
> given that philosophy, it is a genuinely interesting and potentially
> useful idea.
[Rick faints. He's carried off to a couch where smelling salts are
administered....] :-)
> >>> Codepoints can be created at development time, or at run-time while
> >>> debugging. And they inherit the full environment from where they
> >>> are inserted, so you could add fixups, tests, dump-to-files, etc.
> >>>
> >>> I have many more ideas. I'm working on them as fast as I can with
> >>> a job, family, church activities, and then using all of my spare
> >>> time evenings, weekends, and holidays.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2015-11-01 23:22 -0800 |
| Message-ID | <MPG.30a0af0aa00205f25d@news.eternal-september.org> |
| In reply to | #74611 |
Rick C. Hodgin wrote: > David Brown wrote: > > OK, that is somewhat different. I am sceptical to its benefits, but > > only because I am sceptical to your whole program-while-debugging > > concept. But I can see why it fits with the philosophy you have, and it > > given that philosophy, it is a genuinely interesting and potentially > > useful idea. > > [Rick faints. He's carried off to a couch where smelling salts are > administered....] :-) :-)
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-11-02 13:54 +0000 |
| Message-ID | <n17pqn$4v1$1@dont-email.me> |
| In reply to | #74611 |
On 02/11/2015 00:50, Rick C. Hodgin wrote:
> Remember, it's "Rapid DEVELOPMENT Compiler." The goals are in the
> developer writing code.
Have you factored in the number of years before the thing is ready?
That might have big effect on development time!
> That's why I introduced Side Coding. I was listening to your and
> Bart's comments about the embedded nature of the ||| and ||||
> actually being in source code for grouping, and I thought: What
> else could I do to achieve the same thing?
I think this might be where you're going wrong (IMO).
You're having trouble separating the written form of the language, from
what you see on your screen.
Once you make that distinction, then I think things will get much
easier. A lot of it could be done now with an existing language - you
just add markups that your IDE will recognise, but that the compiler
will just see as comments.
(And I think it is really the job of the IDE/editor to display things in
'Side Coding' mode.)
>>>>> ||| Initialize
>>>>> ||
>>>>> || if ((func = iFunction_allocate()))
>>>>> || {
>>>>> || memset(func, 0, sizeof(func));
This is a case in point. It would be quite straightforward to load
source text that looks like this:
// Initialize
if ((func = iFunction_allocate()))
{
memset(func, 0, sizeof(func));
and display it like this:
||| Initialize
||
|| if ((func = iFunction_allocate()))
|| {
|| memset(func, 0, sizeof(func));
if people want. (But most won't!) It keeps the actual source on disk
looking conventional, and it doesn't demand a new compiler just for that
feature.
(One example in my own designs: I used to have various schemes for
multi-line comments, but now I don't have any, because I think it is
best left as an editor function.
It's easy enough for an editor to insert comment-to-end-line symbols for
a block of text, and remove them later. They are also nestable. And if
examining lines 73016 to 73035 of a source file, you don't need to have
scanning the previoys 73000 lines to establish whether these are are
part of a multi-line comment starting at line 10921. It also frees up a
bit of syntax for other purposes.
In an emergency, I can surround a block with the equivalent of #if
0...#endif.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-02 06:23 -0800 |
| Message-ID | <2e683622-e39b-492a-9c3a-bf0e8a8941ce@googlegroups.com> |
| In reply to | #74641 |
On Monday, November 2, 2015 at 8:54:45 AM UTC-5, Bart wrote:
> On 02/11/2015 00:50, Rick C. Hodgin wrote:
>
> > Remember, it's "Rapid DEVELOPMENT Compiler." The goals are in the
> > developer writing code.
>
> Have you factored in the number of years before the thing is ready?
>
> That might have big effect on development time!
>
> > That's why I introduced Side Coding. I was listening to your and
> > Bart's comments about the embedded nature of the ||| and ||||
> > actually being in source code for grouping, and I thought: What
> > else could I do to achieve the same thing?
>
> I think this might be where you're going wrong (IMO).
>
> You're having trouble separating the written form of the language, from
> what you see on your screen.
I understand the point you're making, but I disagree with your conclusion
that the two should not be connected.
> Once you make that distinction, then I think things will get much
> easier. A lot of it could be done now with an existing language - you
> just add markups that your IDE will recognise, but that the compiler
> will just see as comments.
>
> (And I think it is really the job of the IDE/editor to display things in
> 'Side Coding' mode.)
>
> >>>>> ||| Initialize
> >>>>> ||
> >>>>> || if ((func = iFunction_allocate()))
> >>>>> || {
> >>>>> || memset(func, 0, sizeof(func));
>
> This is a case in point. It would be quite straightforward to load
> source text that looks like this:
>
> // Initialize
>
> if ((func = iFunction_allocate()))
> {
> memset(func, 0, sizeof(func));
>
> and display it like this:
>
> ||| Initialize
> ||
> || if ((func = iFunction_allocate()))
> || {
> || memset(func, 0, sizeof(func));
>
> if people want. (But most won't!) It keeps the actual source on disk
> looking conventional, and it doesn't demand a new compiler just for that
> feature.
That would be possible. I may add it. I don't want that. I want to
embed blocks, and also the blocks within blocks, as I require. And
again, nobody has to use any of them. They're simply there to make
your visual life easier.
I also have a long-term plan of translating vertical code into a
horizontal form, which these blocks will correlate to. I'll then
use some kind of \|code|/ cask for meta data about where they appear
on the screen relative to some anchor point.
My goals exceed CAlive, and look to a vision I've had since the late
90s on how to write code. The closest thing I've ever seen that
comes to what I have envisioned is the movie Minority Report where
Tom Cruise's character was wielding data. But, it's not quite like
that.
> (One example in my own designs: I used to have various schemes for
> multi-line comments, but now I don't have any, because I think it is
> best left as an editor function.
>
> It's easy enough for an editor to insert comment-to-end-line symbols for
> a block of text, and remove them later. They are also nestable. And if
> examining lines 73016 to 73035 of a source file, you don't need to have
> scanning the previoys 73000 lines to establish whether these are are
> part of a multi-line comment starting at line 10921. It also frees up a
> bit of syntax for other purposes.
>
> In an emergency, I can surround a block with the equivalent of #if
> 0...#endif.)
>
> --
> Bartc
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-01 18:46 -0800 |
| Message-ID | <8b9080b4-572f-4ee3-ba2b-25f13273bfea@googlegroups.com> |
| In reply to | #74591 |
On Sunday, November 1, 2015 at 4:40:03 PM UTC-6, David Brown wrote:
> Too much choice is a bad thing - just as bad as too little choice.
> The idea is that optimisations do not affect the way the code runs, as
> seen by the programmer or by visible effects. These should not be
> something the user has to control explicitly - if the compiler can
> handle optimisation better, then the programmer can be free to write
> clearer and simpler code.
What is necessary is to be able to choose *when* wants to make a choice with
regard to some matter. There are some things programmers know better than
optimizers, and there are some things optimizers know better than programmers.
If a language does not provide a practical means for a programmer to describe
an application's requirements in various corner cases, there is no way an
optimizer can possibly know.
Suppose one needs to have a function which computes the same value as
int difcmp(int a, int b, int c)
{ return a-b > c; }
in all cases where the behavior of that function is defined by the C
Standard, but is subject to the additional requirement that it must never
do anything other than return zero or one, no matter what values of a, b,
and c are passed in, but it is free to arbitrarily return 0 or 1 in the
cases where the C Standard wouldn't specify a behavior.
On platforms where "unsigned int" and "long long" both have at least one
more value bit than "int", and where unsigned-to-signed casts behave in
two's-complement fashion, the code would satisfy the objective if it was
written as either:
int difcmp(int a, int b, int c)
{ return (long)a-b > c; }
or
int difcmp(int a, int b, int c)
{ return (int)((unsigned)a-b) > c; }
On many platforms, one of the above may be faster than the other--possibly
a lot faster if the function gets expanded inline within a tight loop. An
optimizer given the choice between them could easily pick the faster one
for a given platform, but unfortunately there's no way for a programmer to
give the optimizer that choice while constraining it from doing anything
other than returning zero or returning one.
Adding a way of writing the code which would tell the optimizer to use any
means of making its decision that it sees fit, provided it abides by the
appropriate constraint, would be "another" choice for the programmer to
choose among, but it would actually reduce the programmer's required level
of decision-making since punting the harder decision to the optimizer would
avoid the programmer having to make it.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web