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

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

References in C

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

Contents

  References in C jacob navia <jacob@spamsink.net> - 2011-06-24 10:42 +0200
    Re: References in C BGB <cr88192@hotmail.com> - 2011-06-24 02:53 -0700
      Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-24 22:10 +1200
    Re: References in C "BartC" <bc@freeuk.com> - 2011-06-24 11:14 +0100
      Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 16:59 +0200
    Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 09:26 -0400
      Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 20:08 +0200
        Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-24 11:40 -0700
        Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 14:53 -0400
        Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-24 20:44 +0000
          Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 23:09 +0200
            Re: References in C Joe Wright <joewwright@comcast.net> - 2011-06-24 17:38 -0400
              Re: References in C "BartC" <bc@freeuk.com> - 2011-06-24 22:58 +0100
              Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-25 10:11 +1200
                Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 17:00 -0500
                  Re: References in C "BartC" <bc@freeuk.com> - 2011-06-26 22:55 +0100
                    Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 18:25 -0500
                      Re: References in C "BartC" <bc@freeuk.com> - 2011-06-26 23:38 +0100
                        Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 19:19 -0500
                          Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 01:27 +0200
                            Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-26 19:13 -0700
                              Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 16:50 +1200
                                Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 06:55 +0200
                                  Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 17:10 +1200
                                Re: References in C lawrence.jones@siemens.com - 2011-06-27 10:04 -0400
                      Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-26 22:54 +0000
                        Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 01:29 +0200
                        Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 19:39 -0500
                          Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 07:16 +0000
                            Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 09:46 +0200
                              Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 12:03 -0400
                              Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-27 12:09 -0500
                              Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 22:16 +0000
                            Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 11:57 -0400
                              Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 22:21 +0000
                                Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-28 13:59 +1200
                        Re: References in C Ike Naar <ike@iceland.freeshell.org> - 2011-06-27 07:05 +0000
                          Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-27 20:10 +0000
                        Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-27 16:39 -0500
                  Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-26 15:23 -0700
                    Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 18:57 -0500
                      Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-26 19:21 -0700
                        Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 09:40 -0400
                          Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-27 09:00 -0700
                          Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-27 23:15 +0000
                            Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-28 22:50 -0700
                              Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-29 17:46 +0000
                                Re: References in C Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-29 20:23 +0100
                              Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-06-29 22:35 +0000
                                Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-29 16:52 -0700
                                  Re: References in C Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-03 01:31 +0300
                                    Re: References in C Chad <cdalten@gmail.com> - 2011-07-02 17:20 -0700
                                Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-29 18:54 -0500
                                Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-30 10:32 -0700
                                  Re: References in C "io_x" <a@b.c.invalid> - 2011-07-01 10:19 +0200
                                  Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-07-01 19:21 +0000
                                    Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-01 12:31 -0700
                                      Re: References in C pacman@kosh.dhis.org (Alan Curry) - 2011-07-01 19:32 +0000
                                        Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-01 13:05 -0700
                                          Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-07-01 23:58 +0000
                                            Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-01 20:13 -0500
                                    Re: References in C Michael Press <rubrum@pacbell.net> - 2011-07-01 12:44 -0700
                                    Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-01 15:57 -0500
                                  Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-03 14:54 -0700
                                    Re: References in C Michael Press <rubrum@pacbell.net> - 2011-07-03 20:29 -0700
                                      Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-04 16:05 -0700
                                        Re: References in C Michael Press <rubrum@pacbell.net> - 2011-07-05 08:32 -0700
                                          Re: References in C Lowell Gilbert <lgusenet@be-well.ilk.org> - 2011-07-05 15:34 -0400
                                          Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-06 15:30 -0700
                  Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 13:27 +1200
                    Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-27 09:02 -0400
                Re: References in C "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-06-26 18:35 -0400
                  Re: References in C James Kuyper <jameskuyper@verizon.net> - 2011-06-26 19:11 -0400
                    Re: References in C "Joel C. Salomon" <joelcsalomon@gmail.com> - 2011-06-28 00:52 -0400
                      Re: References in C James Kuyper <jameskuyper@verizon.net> - 2011-06-28 07:56 -0400
            Re: References in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-06-24 22:52 +0100
            Re: References in C jt@toerring.de (Jens Thoms Toerring) - 2011-06-24 23:58 +0000
    Re: References in C Tom St Denis <tom@iahu.ca> - 2011-06-24 06:48 -0700
      Re: References in C David Resnick <lndresnick@gmail.com> - 2011-06-24 07:14 -0700
        Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 16:58 +0200
          Re: References in C Tom St Denis <tom@iahu.ca> - 2011-06-24 09:08 -0700
            Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-24 11:33 -0500
            Re: References in C gazelle@shell.xmission.com (Kenny McCormack) - 2011-06-24 17:47 +0000
              Re: References in C JG <jgrove24@hotmail.com> - 2011-07-01 14:24 -0700
            Re: References in C Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-06-25 04:39 -0700
              Re: References in C BGB <cr88192@hotmail.com> - 2011-06-25 16:15 -0700
                Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-26 11:27 +1200
                  Re: References in C BGB <cr88192@hotmail.com> - 2011-06-25 19:13 -0700
                  Re: References in C cri@tiac.net (Richard Harter) - 2011-06-26 04:22 +0000
                    Re: References in C Robert Wessel <robertwessel2@yahoo.com> - 2011-06-26 01:31 -0500
                      Re: References in C BGB <cr88192@hotmail.com> - 2011-06-26 00:03 -0700
                  Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-26 13:54 -0500
                  Re: References in C luser- -droog <mijoryx@yahoo.com> - 2011-07-07 11:19 -0700
              Re: References in C Dr Nick <3-nospam@temporary-address.org.uk> - 2011-06-26 08:15 +0100
      Re: References in C Ike Naar <ike@sverige.freeshell.org> - 2011-06-24 16:08 +0000
        Re: References in C Tom St Denis <tom@iahu.ca> - 2011-06-24 11:12 -0700
          Re: References in C Ike Naar <ike@iceland.freeshell.org> - 2011-06-24 21:42 +0000
    Re: References in C Stephen Sprunk <stephen@sprunk.org> - 2011-06-24 11:49 -0500
    Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-24 13:17 -0700
      Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 16:46 -0400
        Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-24 14:32 -0700
          Re: References in C Gareth Owen <gwowen@gmail.com> - 2011-06-25 09:39 +0100
            Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-04 17:38 -0400
    Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-06-24 16:33 -0400
      Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-24 23:04 +0200
    Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-26 17:53 -0700
      Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-27 17:04 +1200
        Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-27 14:28 -0700
          Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-28 14:11 +1200
            Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-28 16:27 -0700
            Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-29 13:41 -0700
              Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-29 21:15 +0000
                Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-30 09:26 -0700
                  Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-30 20:55 +0000
                    Re: References in C Michael Press <rubrum@pacbell.net> - 2011-06-30 16:20 -0700
                      Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-30 23:45 +0000
                  Re: References in C James Kuyper <jameskuyper@verizon.net> - 2011-07-01 07:58 -0400
      Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-27 10:43 +0200
        Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-27 08:32 -0700
        Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-28 11:01 -0700
          Re: References in C jacob navia <jacob@spamsink.net> - 2011-06-28 22:17 +0200
            Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-29 09:05 +1200
            Re: References in C Keith Thompson <kst-u@mib.org> - 2011-06-28 22:24 -0700
            Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-29 01:07 -0700
              Re: References in C Ian Collins <ian-news@hotmail.com> - 2011-06-29 21:16 +1200
                Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-06-29 17:46 +0000
                Re: References in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-29 12:19 -0700
            Re: References in C sandeep <nospam@nospam.com> - 2011-07-03 20:53 +0000
              Re: References in C Chad <cdalten@gmail.com> - 2011-07-03 14:02 -0700
              Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-03 14:33 -0700
                Re: References in C jacob navia <jacob@spamsink.net> - 2011-07-04 00:22 +0200
                  Re: References in C Keith Thompson <kst-u@mib.org> - 2011-07-04 13:41 -0700
                Re: References in C gazelle@shell.xmission.com (Kenny McCormack) - 2011-07-04 00:00 +0000
                Re: References in C Seebs <usenet-nospam@seebs.net> - 2011-07-04 00:20 +0000
        Re: References in C Shao Miller <sha0.miller@gmail.com> - 2011-07-04 17:43 -0400

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

#6842

On Jun 24, 10:58 am, jacob navia <ja...@spamsink.net> wrote:
> Le 24/06/11 16:14, David Resnick a écrit :
>
>
>
> > While I'm not sold on having references in C (not clear the it is THAT
> > big a win), this macro crud isn't the same thing as having a ref.
> > Main virtue of references is self-documentation and automated function
> > argument semantics enforcement IMHO...
>
> > i.e. in C you might have:
>
> > /* Note: ledata absolutely CAN NOT and MUST NOT be NULL here */
> > int func(int *ledata)
> > {
> >       if ( ledata == NULL )
> >       {
> >            /* do something drastic */
> >       }
> > }
>
> > You can express all that extra material without the comments, checks,
> > whatever, with the one little '&' in the
>
> > int func( int&ledata )
>
> > Earth shattering?  No, but it is sometimes nice.
>
> > -David
>
> Precisely. It is not the best thing since baked bread but it is an
> improvement that implies a small change in the language.

I can't see a reason to not have it, but just the same I can't say
that my programming career has been taking back by it.  What I would
love is Turbo Pascals "with" stmt.  e.g.

struct { int foo, bar, whatever; } baz;

with (baz) {
   foo = 4;
   bar = 3 * foo;
   whatever = bar - 5;
}

Which makes all the elements of "baz" local scope.  That would beat
crap like

baz.foo      = 4;
baz.bar      = 3 * baz.foo;
baz.whatever = baz.bar - 5;

Of course then you have

int foo;
with (baz) {
   foo = 4; // which foo?
}

But that's something specifications are for...

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

#6844

On 24-Jun-11 11:08, Tom St Denis wrote:
> ... What I would love is Turbo Pascals "with" stmt.  e.g.
> 
> struct { int foo, bar, whatever; } baz;
> 
> with (baz) {
>    foo = 4;
>    bar = 3 * foo;
>    whatever = bar - 5;
> }
> 
> Which makes all the elements of "baz" local scope.  That would beat
> crap like
> 
> baz.foo      = 4;
> baz.bar      = 3 * baz.foo;
> baz.whatever = baz.bar - 5;
> 
> Of course then you have
> 
> int foo;
> with (baz) {
>    foo = 4; // which foo?
> }
> 
> But that's something specifications are for...

Presumably it would be baz.foo, using the same sort of logic as if the
same identifier is used at block scope and file scope; you've just added
a new level.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#6851

In article <45c7b44e-150a-48cb-9bff-f68109add972@u7g2000yqc.googlegroups.com>,
Tom St Denis  <tom@iahu.ca> wrote:
...
>Of course then you have
>
>int foo;
>with (baz) {
>   foo = 4; // which foo?
>}
>
>But that's something specifications are for...

What does Pascal do?

(But I agree with the other poster that it should be baz.foo, although I
could easily imagine that it would be frequently desirable to be able to
access the "uplevel" foo - something that ordinary "variable shadowing"
prevents [unless extreme measures are taken...])

-- 
One of the best lines I've heard lately:

    Obama could cure cancer tomorrow, and the Republicans would be
    complaining that he had ruined the pharmaceutical business.

(Heard on Stephanie Miller = but the sad thing is that there is an awful lot
of direct truth in it.  We've constructed an economy in which eliminating
cancer would be a horrible disaster.  There are many other such examples.)

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

#7392

On Jun 24, 12:47 pm, gaze...@shell.xmission.com (Kenny McCormack)
wrote:
> In article <45c7b44e-150a-48cb-9bff-f68109add...@u7g2000yqc.googlegroups.com>,
> Tom St Denis  <t...@iahu.ca> wrote:
> ...
>
> >Of course then you have
>
> >int foo;
> >with (baz) {
> >   foo = 4; // which foo?
> >}
>
> >But that's something specifications are for...
>
> What does Pascal do?
>
> (But I agree with the other poster that it should be baz.foo, although I
> could easily imagine that it would be frequently desirable to be able to
> access the "uplevel" foo - something that ordinary "variable shadowing"
> prevents [unless extreme measures are taken...])
>
> --
> One of the best lines I've heard lately:
>
>     Obama could cure cancer tomorrow, and the Republicans would be
>     complaining that he had ruined the pharmaceutical business.
>
> (Heard on Stephanie Miller=

Whats all this talk about a Shiksa Library Tour ?? What library
charges for entry tickets ??
I'm a regular listener but Steph hardly mentions which libraries she
will be touring. Why keep the cities a secret, Steph ??

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

#6925

On Jun 24, 5:08 pm, Tom St Denis <t...@iahu.ca> wrote:
> On Jun 24, 10:58 am, jacob navia <ja...@spamsink.net> wrote:
>
>
>
>
>
> > Le 24/06/11 16:14, David Resnick a écrit :
>
> > > While I'm not sold on having references in C (not clear the it is THAT
> > > big a win), this macro crud isn't the same thing as having a ref.
> > > Main virtue of references is self-documentation and automated function
> > > argument semantics enforcement IMHO...
>
> > > i.e. in C you might have:
>
> > > /* Note: ledata absolutely CAN NOT and MUST NOT be NULL here */
> > > int func(int *ledata)
> > > {
> > >       if ( ledata == NULL )
> > >       {
> > >            /* do something drastic */
> > >       }
> > > }
>
> > > You can express all that extra material without the comments, checks,
> > > whatever, with the one little '&' in the
>
> > > int func( int&ledata )
>
> > > Earth shattering?  No, but it is sometimes nice.
>
> > > -David
>
> > Precisely. It is not the best thing since baked bread but it is an
> > improvement that implies a small change in the language.
>
> I can't see a reason to not have it, but just the same I can't say
> that my programming career has been taking back by it.  What I would
> love is Turbo Pascals "with" stmt.  e.g.

eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
invent pascal. 'with' is actually a standard pascal feature

I understand 'with' presents problems and this is one reason it hasnt
been widely adopted



> struct { int foo, bar, whatever; } baz;
>
> with (baz) {
>    foo = 4;
>    bar = 3 * foo;
>    whatever = bar - 5;
>
> }
>
> Which makes all the elements of "baz" local scope.  That would beat
> crap like
>
> baz.foo      = 4;
> baz.bar      = 3 * baz.foo;
> baz.whatever = baz.bar - 5;
>
> Of course then you have
>
> int foo;
> with (baz) {
>    foo = 4; // which foo?
>
> }
>
> But that's something specifications are for...

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

#6945

On 6/25/2011 4:39 AM, Nick Keighley wrote:
> On Jun 24, 5:08 pm, Tom St Denis<t...@iahu.ca>  wrote:
>> On Jun 24, 10:58 am, jacob navia<ja...@spamsink.net>  wrote:
>>
>>

<snip>

>>
>>> Precisely. It is not the best thing since baked bread but it is an
>>> improvement that implies a small change in the language.
>>
>> I can't see a reason to not have it, but just the same I can't say
>> that my programming career has been taking back by it.  What I would
>> love is Turbo Pascals "with" stmt.  e.g.
>
> eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
> invent pascal. 'with' is actually a standard pascal feature
>
> I understand 'with' presents problems and this is one reason it hasnt
> been widely adopted
>

in my own language, I have "with", but IIRC it was inherited from the 
languages it was based on (JavaScript and ActionScript).

however, as-implemented, using with will currently temporarily redirect 
"this", meaning that bindings located in the real "this" are temporarily 
inaccessible.

there is no ideal solution, apart from temporarily creating a new 
temporary binding to hold the old "this", and internally redirecting any 
field accesses to it (but, this itself has issues, for example, the old 
'this' would then have tighter binding than the newly-added "this", 
which has a binding precedence weaker than that for locals and 
arguments). exiting the "with" then restores the original "this".

but, yeah, there are other issues as well...


also, a lot of these sorts of constructions will mix poorly with the use 
of goto (using goto in some places may risk causing some very strange 
behaviors, although later the compiler may check for an raise an error 
regarding use of goto into/out of some constructions, such as 
"with"/"package"/"class"/try-catch blocks/...).

granted, yes, these are not likely to be an issue in sanely-written code...

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

#6946

On 06/26/11 11:15 AM, BGB wrote:
> On 6/25/2011 4:39 AM, Nick Keighley wrote:
>> On Jun 24, 5:08 pm, Tom St Denis<t...@iahu.ca>   wrote:
>>>
>>> I can't see a reason to not have it, but just the same I can't say
>>> that my programming career has been taking back by it.  What I would
>>> love is Turbo Pascals "with" stmt.  e.g.
>>
>> eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
>> invent pascal. 'with' is actually a standard pascal feature
>>
>> I understand 'with' presents problems and this is one reason it hasnt
>> been widely adopted
>>
>
> in my own language, I have "with", but IIRC it was inherited from the
> languages it was based on (JavaScript and ActionScript).
>
> however, as-implemented, using with will currently temporarily redirect
> "this", meaning that bindings located in the real "this" are temporarily
> inaccessible.
>
> there is no ideal solution, apart from temporarily creating a new
> temporary binding to hold the old "this", and internally redirecting any
> field accesses to it (but, this itself has issues, for example, the old
> 'this' would then have tighter binding than the newly-added "this",
> which has a binding precedence weaker than that for locals and
> arguments). exiting the "with" then restores the original "this".
>
> but, yeah, there are other issues as well...
>
> also, a lot of these sorts of constructions will mix poorly with the use
> of goto (using goto in some places may risk causing some very strange
> behaviors, although later the compiler may check for an raise an error
> regarding use of goto into/out of some constructions, such as
> "with"/"package"/"class"/try-catch blocks/...).
>
> granted, yes, these are not likely to be an issue in sanely-written code...

Any sanely designed language wouldn't have goto!

-- 
Ian Collins

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

#6948

On 6/25/2011 4:27 PM, Ian Collins wrote:
> On 06/26/11 11:15 AM, BGB wrote:
>> On 6/25/2011 4:39 AM, Nick Keighley wrote:
>>> On Jun 24, 5:08 pm, Tom St Denis<t...@iahu.ca> wrote:
>>>>
>>>> I can't see a reason to not have it, but just the same I can't say
>>>> that my programming career has been taking back by it. What I would
>>>> love is Turbo Pascals "with" stmt. e.g.
>>>
>>> eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
>>> invent pascal. 'with' is actually a standard pascal feature
>>>
>>> I understand 'with' presents problems and this is one reason it hasnt
>>> been widely adopted
>>>
>>
>> in my own language, I have "with", but IIRC it was inherited from the
>> languages it was based on (JavaScript and ActionScript).
>>
>> however, as-implemented, using with will currently temporarily redirect
>> "this", meaning that bindings located in the real "this" are temporarily
>> inaccessible.
>>
>> there is no ideal solution, apart from temporarily creating a new
>> temporary binding to hold the old "this", and internally redirecting any
>> field accesses to it (but, this itself has issues, for example, the old
>> 'this' would then have tighter binding than the newly-added "this",
>> which has a binding precedence weaker than that for locals and
>> arguments). exiting the "with" then restores the original "this".
>>
>> but, yeah, there are other issues as well...
>>
>> also, a lot of these sorts of constructions will mix poorly with the use
>> of goto (using goto in some places may risk causing some very strange
>> behaviors, although later the compiler may check for an raise an error
>> regarding use of goto into/out of some constructions, such as
>> "with"/"package"/"class"/try-catch blocks/...).
>>
>> granted, yes, these are not likely to be an issue in sanely-written
>> code...
>
> Any sanely designed language wouldn't have goto!
>

C and C++ have goto, and goto sometimes has additional uses, such as for 
computed goto...

my language simply retains goto...

if also has the '&' and '*' unary operators, ability to use arithmetic 
to walk/offset strings and arrays, ...


or such...

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

#6953

On Sun, 26 Jun 2011 11:27:27 +1200, Ian Collins <ian-news@hotmail.com>
wrote:

>On 06/26/11 11:15 AM, BGB wrote:
>> On 6/25/2011 4:39 AM, Nick Keighley wrote:
>>> On Jun 24, 5:08 pm, Tom St Denis<t...@iahu.ca>   wrote:
>>>>
>>>> I can't see a reason to not have it, but just the same I can't say
>>>> that my programming career has been taking back by it.  What I would
>>>> love is Turbo Pascals "with" stmt.  e.g.
>>>
>>> eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
>>> invent pascal. 'with' is actually a standard pascal feature
>>>
>>> I understand 'with' presents problems and this is one reason it hasnt
>>> been widely adopted
>>>
>>
>> in my own language, I have "with", but IIRC it was inherited from the
>> languages it was based on (JavaScript and ActionScript).
>>
>> however, as-implemented, using with will currently temporarily redirect
>> "this", meaning that bindings located in the real "this" are temporarily
>> inaccessible.
>>
>> there is no ideal solution, apart from temporarily creating a new
>> temporary binding to hold the old "this", and internally redirecting any
>> field accesses to it (but, this itself has issues, for example, the old
>> 'this' would then have tighter binding than the newly-added "this",
>> which has a binding precedence weaker than that for locals and
>> arguments). exiting the "with" then restores the original "this".
>>
>> but, yeah, there are other issues as well...
>>
>> also, a lot of these sorts of constructions will mix poorly with the use
>> of goto (using goto in some places may risk causing some very strange
>> behaviors, although later the compiler may check for an raise an error
>> regarding use of goto into/out of some constructions, such as
>> "with"/"package"/"class"/try-catch blocks/...).
>>
>> granted, yes, these are not likely to be an issue in sanely-written code...
>
>Any sanely designed language wouldn't have goto!

Fair enough.  Still, a sanely designed language wouldn't have gaps
where goto is the obvious solution.  The two that occur to me are
function epilogs (goto wrapup) and state machines (goto state
with_current_continuation).  Any others?

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

#6959

On Sun, 26 Jun 2011 04:22:27 GMT, cri@tiac.net (Richard Harter) wrote:

>On Sun, 26 Jun 2011 11:27:27 +1200, Ian Collins <ian-news@hotmail.com>
>wrote:
>
>>On 06/26/11 11:15 AM, BGB wrote:
>>> On 6/25/2011 4:39 AM, Nick Keighley wrote:
>>>> On Jun 24, 5:08 pm, Tom St Denis<t...@iahu.ca>   wrote:
>>>>>
>>>>> I can't see a reason to not have it, but just the same I can't say
>>>>> that my programming career has been taking back by it.  What I would
>>>>> love is Turbo Pascals "with" stmt.  e.g.
>>>>
>>>> eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
>>>> invent pascal. 'with' is actually a standard pascal feature
>>>>
>>>> I understand 'with' presents problems and this is one reason it hasnt
>>>> been widely adopted
>>>>
>>>
>>> in my own language, I have "with", but IIRC it was inherited from the
>>> languages it was based on (JavaScript and ActionScript).
>>>
>>> however, as-implemented, using with will currently temporarily redirect
>>> "this", meaning that bindings located in the real "this" are temporarily
>>> inaccessible.
>>>
>>> there is no ideal solution, apart from temporarily creating a new
>>> temporary binding to hold the old "this", and internally redirecting any
>>> field accesses to it (but, this itself has issues, for example, the old
>>> 'this' would then have tighter binding than the newly-added "this",
>>> which has a binding precedence weaker than that for locals and
>>> arguments). exiting the "with" then restores the original "this".
>>>
>>> but, yeah, there are other issues as well...
>>>
>>> also, a lot of these sorts of constructions will mix poorly with the use
>>> of goto (using goto in some places may risk causing some very strange
>>> behaviors, although later the compiler may check for an raise an error
>>> regarding use of goto into/out of some constructions, such as
>>> "with"/"package"/"class"/try-catch blocks/...).
>>>
>>> granted, yes, these are not likely to be an issue in sanely-written code...
>>
>>Any sanely designed language wouldn't have goto!
>
>Fair enough.  Still, a sanely designed language wouldn't have gaps
>where goto is the obvious solution.  The two that occur to me are
>function epilogs (goto wrapup) and state machines (goto state
>with_current_continuation).  Any others?


Multi-level loop break/continues.

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

#6961

On 6/25/2011 11:31 PM, Robert Wessel wrote:
> On Sun, 26 Jun 2011 04:22:27 GMT, cri@tiac.net (Richard Harter) wrote:
>
>> On Sun, 26 Jun 2011 11:27:27 +1200, Ian Collins<ian-news@hotmail.com>
>> wrote:
>>
>>> On 06/26/11 11:15 AM, BGB wrote:
>>>> On 6/25/2011 4:39 AM, Nick Keighley wrote:
>>>>> On Jun 24, 5:08 pm, Tom St Denis<t...@iahu.ca>    wrote:
>>>>>>
>>>>>> I can't see a reason to not have it, but just the same I can't say
>>>>>> that my programming career has been taking back by it.  What I would
>>>>>> love is Turbo Pascals "with" stmt.  e.g.
>>>>>
>>>>> eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
>>>>> invent pascal. 'with' is actually a standard pascal feature
>>>>>
>>>>> I understand 'with' presents problems and this is one reason it hasnt
>>>>> been widely adopted
>>>>>
>>>>
>>>> in my own language, I have "with", but IIRC it was inherited from the
>>>> languages it was based on (JavaScript and ActionScript).
>>>>
>>>> however, as-implemented, using with will currently temporarily redirect
>>>> "this", meaning that bindings located in the real "this" are temporarily
>>>> inaccessible.
>>>>
>>>> there is no ideal solution, apart from temporarily creating a new
>>>> temporary binding to hold the old "this", and internally redirecting any
>>>> field accesses to it (but, this itself has issues, for example, the old
>>>> 'this' would then have tighter binding than the newly-added "this",
>>>> which has a binding precedence weaker than that for locals and
>>>> arguments). exiting the "with" then restores the original "this".
>>>>
>>>> but, yeah, there are other issues as well...
>>>>
>>>> also, a lot of these sorts of constructions will mix poorly with the use
>>>> of goto (using goto in some places may risk causing some very strange
>>>> behaviors, although later the compiler may check for an raise an error
>>>> regarding use of goto into/out of some constructions, such as
>>>> "with"/"package"/"class"/try-catch blocks/...).
>>>>
>>>> granted, yes, these are not likely to be an issue in sanely-written code...
>>>
>>> Any sanely designed language wouldn't have goto!
>>
>> Fair enough.  Still, a sanely designed language wouldn't have gaps
>> where goto is the obvious solution.  The two that occur to me are
>> function epilogs (goto wrapup) and state machines (goto state
>> with_current_continuation).  Any others?
>
>
> Multi-level loop break/continues.

yeah. JavaScript and ActionScript also have "break label;" and "continue 
label;", which as I see it are mostly just glorified gotos (or glorigied 
multi-level break/continue, either way, as break/continue are themselves 
internally implemented as gotos...).

my language includes these as well...

so:
break 2; //break 2 levels
break FOO;
goto FOO;

are all technically valid.

I personally see little wrong with including goto, as it may have uses 
in some cases, although it is very rarely used in my own code.


also planned is, possibly say:
x=&&FOO;
goto *x;
for a computed goto.

but, I have not yet implemented this (not a high priority).


or such...

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

#6978

On 6/25/2011 6:27 PM, Ian Collins wrote:
>
> Any sanely designed language wouldn't have goto!
>

I must respectfully disagree. :)  I usually employ it for clean-up purposes.

Having said that...

/* "So you don't like goto, eh?" */

#include <stdlib.h>
#include <stdio.h>

int main(void) {
     enum {
         DONE,
         FREE_MEM,
         FREE_MORE,
         START
       } state = START;
     char * foo, * bar;

     do switch (state) {
         default:
           puts("Invalid state!");
           state = DONE;
           continue;
         case START: state = DONE;

         /* Allocate foo. */
         foo = malloc(12);
         if (!foo) {
             puts("No foo!");
             continue;
             case FREE_MEM:
             free(foo);
             puts("Freed foo.");
             state--;
             continue;
           }
         puts("Allocated foo.");
         state++;

         /* Allocate bar. */
         bar = malloc(12);
         if (!bar) {
             puts("No bar!");
             continue;
             case FREE_MORE:
             free(bar);
             puts("Freed bar.");
             state--;
             continue;
           }
         puts("Allocated bar.");
         state++;

         /* All done.  Free resources or return, as you wish. */
         puts("Done.");
       } while (state);
     return EXIT_SUCCESS;
   }

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

#7863

On Jun 25, 6:27 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 06/26/11 11:15 AM, BGB wrote:
>
>
>
> > On 6/25/2011 4:39 AM, Nick Keighley wrote:
> >> On Jun 24, 5:08 pm, Tom St Denis<t...@iahu.ca>   wrote:
>
> >>> I can't see a reason to not have it, but just the same I can't say
> >>> that my programming career has been taking back by it.  What I would
> >>> love is Turbo Pascals "with" stmt.  e.g.
>
> >> eek!!!!!!!! just as microsoft didnt invent basic so borland didnt
> >> invent pascal. 'with' is actually a standard pascal feature
>
> >> I understand 'with' presents problems and this is one reason it hasnt
> >> been widely adopted
>
> > in my own language, I have "with", but IIRC it was inherited from the
> > languages it was based on (JavaScript and ActionScript).
>
> > however, as-implemented, using with will currently temporarily redirect
> > "this", meaning that bindings located in the real "this" are temporarily
> > inaccessible.
>
> > there is no ideal solution, apart from temporarily creating a new
> > temporary binding to hold the old "this", and internally redirecting any
> > field accesses to it (but, this itself has issues, for example, the old
> > 'this' would then have tighter binding than the newly-added "this",
> > which has a binding precedence weaker than that for locals and
> > arguments). exiting the "with" then restores the original "this".
>
> > but, yeah, there are other issues as well...
>
> > also, a lot of these sorts of constructions will mix poorly with the use
> > of goto (using goto in some places may risk causing some very strange
> > behaviors, although later the compiler may check for an raise an error
> > regarding use of goto into/out of some constructions, such as
> > "with"/"package"/"class"/try-catch blocks/...).
>
> > granted, yes, these are not likely to be an issue in sanely-written code...
>
> Any sanely designed language wouldn't have goto!
>
> --
> Ian Collins

That seems extreme. Since the structured control constructs are
implemented with explicit jumps underneath, any "sanely designed
language" would be implemented in a language *not* "sanely designed".

--
You can't get on the people train... 'cause you're cows!

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

#6962

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> I understand 'with' presents problems and this is one reason it hasnt
> been widely adopted

It exists in the templating language ClearSilver.  I haven't used it
much, but on the odd occasions I have it's served to remove huge piles
of repeated this[that].other[perhaps].something in a block of code.

ClearSilver is carefully designed to prevent you doing too much of the
programming in it and to prevent endless loops.  I don't know if that
helps to work around the problems you allude to.
-- 
Online waterways route planner            | http://canalplan.eu
Plan trips, see photos, check facilities  | http://canalplan.org.uk

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

#6843

On 2011-06-24, Tom St Denis <tom@iahu.ca> wrote:
> Simipler...
>
> int func(int *ledata)
> {
> #define reflefdata (*ledata)

Error prone; see below.

>    int a;
>
>    a = (refledata *= 4);

See above.

>    return a;
> }

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

#6853

On Jun 24, 12:08 pm, Ike Naar <i...@sverige.freeshell.org> wrote:
> On 2011-06-24, Tom St Denis <t...@iahu.ca> wrote:
>
> > Simipler...
>
> > int func(int *ledata)
> > {
> > #define reflefdata (*ledata)
>
> Error prone; see below.
>
> >    int a;
>
> >    a = (refledata *= 4);
>
> See above.

Error prone how?  Aside from the typo which was easy enough to fix.
If I have a complicated function in which I want to work on it by
reference this is how I would do it.  of course I'd switch the names
around so the frequently used one was shorter...

My error was akin to

int foo(int &bar)
{
   return (baz *= 3);
}

It's a friggin typo, not a design error.

Tom

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

#6894

On 2011-06-24, Tom St Denis <tom@iahu.ca> wrote:
> On Jun 24, 12:08?pm, Ike Naar <i...@sverige.freeshell.org> wrote:
>> On 2011-06-24, Tom St Denis <t...@iahu.ca> wrote:
>>
>> > Simipler...
>>
>> > int func(int *ledata)
>> > {
>> > #define reflefdata (*ledata)
>>
>> Error prone; see below.
>>
>> > ? ?int a;
>>
>> > ? ?a = (refledata *= 4);
>>
>> See above.
>
> Error prone how?  Aside from the typo which was easy enough to fix.
> If I have a complicated function in which I want to work on it by
> reference this is how I would do it.  of course I'd switch the names
> around so the frequently used one was shorter...
>
> My error was akin to
>
> int foo(int &bar)
> {
>    return (baz *= 3);
> }
>
> It's a friggin typo, not a design error.

The problem with macro tricks is they always frig.
They are, so, to say, error prone. See below:

  void increment(int *x) /* uses the call-by-reference macro trick */
  {
    #define refx (*x)
    ++refx;
  }

  void use_increment(void) /* using above function */
  {
    int i = 42;
    increment(&i);
    if (i == 43)
    {
      /* got here */
    }
  }

  /* so far so good */

  /* ... 99999 more lines of code ... */

  /* The author of ``is_null'' is unaware of the
     fact that the name ``refx'' was #defined 100017 lines earlier.
  */
  int is_null(char *refx)  /* looks like an ordinary parameter */
  {
    return refx == NULL;
  }

  void surprise(void)
  {
    if (is_null(NULL))
    {
      /* Expected to get here, but got a segfault instead */
    }
  }

In isolation, the functions ``increment'' and ``is_null'' are both
harmless and unsurprising; but the macro definition in ``increment''
has an unexpected and devastating effect on the working of ``is_null''.

Of course the code is a bit contrived, but I hope you get the point:
macro tricks are best avoided, or at least one should be careful.
For instance, adding ``#undef refx'' at the end of ``increment'' would
have made a difference.

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

#6846

On 24-Jun-11 03:42, jacob navia wrote:
> In fact, a reference is just a pointer. It is different from plain
> pointers in two ways:
> 
> (1) It is always assigned to a concrete object when it is defined.
> (2) Once defined, it will always point to that same object. It can't
>    be changed to point into another object.
> (3) It is used with the '.' notation, as if it weren't a pointer.
> (4) Instead of "*' the symbol "&" is used:
>     int i = 23;
>     int &IntReference = i;

More plainly, a reference is an implicitly dereferenced pointer.  The
compiler can substitute "(*ref)" wherever it sees "ref" and "ref"
wherever it sees "&ref".  Also, the address of the initializer is used
rather than the initializer itself.

> The problem is when defining a reference but when you pass a reference
> to a function:
>     int fn(void &ref);
> In this case there is no initialization (that would explode immediately)
> but just a definition without any initialization. The compiler must
> check, then, that the reference is not to a void pointer.

Conceptually, when a function is called, its arguments are implicitly
initialized with the corresponding parameters.

> The advantages of using references are that they are never NULL,

Well, there are circumstances where a reference could be null, but
creating them requires invoking UB, so there's no point in specifying
what happens after that point.

> and that they always point to the same object, two important
> things less to test.

I'm not so sure about that.  What is so wrong with being able to change
the referent, e.g. by assigning to &ref?

> The only (orthodox) way of declaring a non-NULL pointer in an argument
> list is now:
> 
>     int fn(int arg[static 1]);
> 
> This declares that the "arg" argument will have at least one integer
> Few people know this, and it wasn't much explained when C99 introduced
> it.

News to me.  Did we really need _yet another_ use for the "static" keyword?

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#6868

jacob navia <jacob@spamsink.net> writes:
> The lcc-win compiler is an experimental compiler to promote the
> development of C as a language. Contrary to the main trends of
> language design this days, lcc-win considers C not a dead language but
> a language that can evolve and propose new features.
>
> In this context, one of the extensions that lcc-win supports is
> references, where the design is largely inspired from the C++ design.
>
>
> What are references?
>
> In fact, a reference is just a pointer. It is different from plain
> pointers in two ways:
>
> (1) It is always assigned to a concrete object when it is defined.
> (2) Once defined, it will always point to that same object. It can't
>    be changed to point into another object.
> (3) It is used with the '.' notation, as if it weren't a pointer.
> (4) Instead of "*' the symbol "&" is used:
>     int i = 23;
>     int &IntReference = i;
[...]

For what it's worth, an initialized const pointer gives you 2 and
*partly* gives you 1, but not 3 or 4.

The "partly" refers to the fact that an initialized local const
pointer object, as long as the initialization isn't a null pointer,
will always point to the same thing, but no such guarantees can be
made for a pointer parameter unless you use the C99 "static" kludge.

(This is an observation, not an argument for or against the
proposal.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#6875

On 6/24/2011 16:17, Keith Thompson wrote:
>
> The "partly" refers to the fact that an initialized local const
> pointer object, as long as the initialization isn't a null pointer,
> will always point to the same thing, but no such guarantees can be
> made for a pointer parameter unless you use the C99 "static" kludge.
>

I don't understand why:

   void foo(int * const ip);

couldn't give the same guarantee, assuming the point is that 'ip' within 
the function definition for 'foo' mustn't be modified; "point to the 
same thing," even if "no thing," which is a different point.

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

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

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

csiph-web