🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2226

New Functionality.... Was (Re: Is the STL too authentic... ?)

#2226
From: jgreen
Date: Tue, 17 Oct 1995 08:53
175 lines
6163 bytes
[ I do not have a news feed out right now, if this is interesting to some
  of you please forward it to de.comp.lang.c++ for review in the standard ]

    Here are some additions I would like to see in the C++ standard.
This is based on John Nagle's request below to pass code blocks in C++.
I have used languages with this feature and created a object oriented
language with this feature. I would find this feature invaluable but it does
have one major draw back. The language I wrote for this keeps the scope of
the local variables around as long as there is a reference to them, the
language is a front end to scheme and the scheme interpreter takes care of
this ( this is one of the major differences between lisp and scheme ).
In John's example below the code block would be passed as a function pointer
which could in theory be assigned to a variable, this variable could then
execute the function block after the activation record with the calling
functions local variables has been release. A way around this would be to
create a new key word such as "block" which would declare a parameter as
a function block. The keyword block can only be used in parameter lists
thus removing the ability to do an assignment to a scope outside the stack
frame. Here is an example (based on my personal language):
NOTE: an alternative syntax is given that does not create a need new a
      new key word.

// Example of passing code blocks....
class OrdInt
{
    int size;
    foo *elem;
public:
    .
    .
    .
    void do( block( foo el ) );
    // alternative syntax : void do ( { ( foo el ) } );
};

void OrdInt::do( block fun( foo el ) )
// alternative syntax : void OrdInt::do( { fun ( foo el ) } )
{
    for ( int i = 0; i < size; i++ )
    {
        fun( elem[ i ] );
    }
}

main( )
{
    OrdInt t;
    .
    .
    .
    t.do( { ( foo el ) el.print( ); } );
}

It would also be nice to do something like this....


Other features I would like to see:
-----------------------------------

1: Nested functions.

    int foo ( int i )
    {
        int sum = 0;
        int foo_rec( int i )
        {
            int j = foo_rec( i + sum ); // foo_rec can only be accessed from
                                        // within foo( int i ); Assinging or
                                        // returning the address of foo_rec
                                        // should give a compiler warning or
                                        // error.
            sum += j;
            return j;
        }
        return foo_rec( i );
    }

2: A variant key word which does the following:

2a: A non default contructor declaration declared with the variant keyword
    is enherited by base classes.

    class a
    {
        variant a( int );
    };

    class b: public a
    {
        b( );
    }

    class c: public b
    {
        b( int ); // Will implicitly call b( ) and a( int ). 
    }

2b: An series of overloaded virtual functions with the same name delared with
    the variant key word will not be hidden when one or more of the overload
    definitions is redeclared.

    class a
    {
        virtual variant foo ( int );
        virtual variant foo ( long );
        virtual variant foo ( double );
    };

    class b : public a
    {
        virtual foo( long );
        // virtual foo( int ) and foo( double ) are not hidden.
    }

alternate syntax:

    class a
    {
        virtual foo ( int );
        virtual foo ( long );
        virtual foo ( double );
    };

    class b : public variant a
    {
        virtual foo( long );
        // virtual foo( int ) and foo( double ) are not hidden.
    }

---------------------------------------------------
Here is the posting that this article is based on:

In article <nagleDFuGI9.9Ar@netcom.com> you write:
>wsog@site71.ping.at (Walter Sommergruber) writes:
>>Alexander Ehrler  (ukci@rzstud1.rz.uni-karlsruhe.de) wrote on 02.10.95
>>about "Re: Is the STL too authentic... ?":
>
>>> Andrew Koenig (ark@research.att.com) wrote:
>>> : In article <44kgjg$cuv@nz12.rz.uni-karlsruhe.de>
>>> ukci@rzstud1.rz.uni-karlsruhe.de (Alexander Ehrler) writes:
>>>
>>> : It is possible to implement safe containers on top of unsafe ones.
>>> : I don't know how to implement fast containers on top of slow ones.
>>> : There is also nothing stopping implementations from providing
>>> : bounds-checked versions of STL if they so desire.
>>The old hype about speed :-(
>
>      Yes.
>
>      Part of the problem is that C++ doesn't support local functions,
>let alone anonymous functions.  So you can't really use "do this to
>all that stuff" style iterators, like Smalltalk's.
>
>      I'd like to be able to write
>
>	float total = 0.0;
>	forall(tab,{(int i) { total += tab[i]; }});
>	outf << "Total is " << total;
>
>The code between the outer { and } is an inline declaration and definition 
>of a function with no name.  This style is both safe and fast.  
>But it's not C++.
>
>					John Nagle


-- 
Jon Greenblatt   (602) 504-2373     jgreenb@amex-trs.com
    
The opinions expressed in this message are those of the author only,
and do not necessarily reflect the opinions of American Express.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID: <9510170050.AA42882@cs90slave.csv-tgsc.amex-trs.com>
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!in2.uu.net!bounce-back
Date: 17 Oct 95 08:53:20 GMT
Approved: fjh@cs.mu.oz.au
Organization: American Express Travel Related Services
Newsgroups: comp.std.c++
From: jgreen@amex-trs.com
X-Original-Date: Mon, 16 Oct 1995 17:50:12 -0700
Message-ID: <9510170050.AA42882@cs90slave.csv-tgsc.amex-trs.com>
Subject: New Functionality.... Was (Re: Is the STL too authentic... ?)
Cc: jgreen@amexphx.amex-trs.com, wrober@amexphx.amex-trs.com
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMINvZuEDnX0m9pzZAQHeRwGAhTeiAqzjJyz6mIxOlou3SKbxHMDd/byF
 yTvJpQDmiCQWqhitNZ8HlBp5h82Fj2uN
 =22VR