Article View: comp.std.c++
Article #2226New Functionality.... Was (Re: Is the STL too authentic... ?)
From: jgreen
Date: Tue, 17 Oct 1995 08:53
Date: Tue, 17 Oct 1995 08:53
175 lines
6163 bytes
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-backShow 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