🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

2 total messages Started by jgreen Tue, 17 Oct 1995 08:53
New Functionality.... Was (Re: Is the STL too authentic... ?)
#2226
Author: 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. ]
Re: New Functionality.... Was (Re: Is the STL too authentic...
#2236
Author: Sean A Corfield
Date: Wed, 18 Oct 1995 13:38
54 lines
2210 bytes
In article <9510170050.AA42882@cs90slave.csv-tgsc.amex-trs.com>,
jgreen@amex-trs.com wrote:

[anonymous functions]
Yes, I would like these too -- the issue was raised in one of the
Extensions WG sessions but really got no support.

|> Other features I would like to see:
|> -----------------------------------
|> 
|> 1: Nested functions.

This has been discussed several times by the Extensions WG and the decision
was taken not to pursue this. I argued in favour of the extension because I
like nested functions but you can't win 'em all.

The closest you'll get is member functions of local classes, I think:

 struct interface
 {
   virtual void function() const = 0;
 };
 void f(const interface& i)
 {
 // do stuff with i.function()
 }
 void g()
 {
   struct local : public interface
   {
     void function() const { ... }
   };
   f(local());
 }

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

Something similar can be achieved with the using declaration:

|>     class b : public a
|>     {
|>         virtual foo( long );
           using a::foo; // brings in all base class variants
                         // to overload foo(long)
|>         // virtual foo( int ) and foo( double ) are not hidden.
|>     }
---
[ 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. ]
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads