Francis Glassborow wrote:

> You manage to completely miss the point. For excellent design reasons=20
> the language guarantees that it will never use operator new (and new[])=
=20
> nor operator delete (and delete[]) to acquire/release memory other than=
=20
> through the new and delete expressions.

Could you please be more specific, of give me a link to a rationale of=20
this "feature".

Thanks,

--=20
Lo=EFc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote
(abridged):
> > I would be more interested in a good proposal for local functions,
> > especially if they could capture local variables somehow and have
> > external linkage.
>
> That's very simple, just add the function declaration statement to the
> list of permitted statements in statement blocks (in the language syntax
> definition).

This stuff has been discussed before. It gets complicated when you think
it through. Try searching in this group or comp.lang.c++.moderated for
"anonymous functions" or "block closures".

For example, many people want the local function to be anonymous, defined
at the point of use, to make using std algorithms easier. There are issues
of memory management, especially if the local function can call itself
recursively, or if a pointer to it can be returned from the enclosing
function. The requirement to capture local variables makes it a kind of
object with mutable state, so we probably want to be able to use the rest
of the C++ object model: inheritance, virtual functions. And we have to
find a good concrete syntax for all this.

An attraction of "Valof" is its relative simplicity compared to full block
closures. On the other hand, full block closures may make it redundant.
For example, if (MyTree *)() {...} defines a local function, then valof
can be achieved by adding () at the end to call it.

    void func( void ) {
        MyTree* bigTree = (MyTree *)() {
            MyString s( userSelectFile() );
            MyFile f; f.Load( s );
            return loadTree( f );
        } ();

        bigTree->optimize();
    }


> I estimate about 5-10 extra lines of compiler source for that.
> Now that's a major task that needs to move planets, right?

Yes. You forgot about all the testing that comes after, and all the
politics that comes before, and the possible impact on future proposals.
Getting /anything/ added to C++ is very hard.

-- Dave Harris, Nottingham, UK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bq36l2$inh$1@news-reader4.wanadoo.fr>, Lo=EFc Joly=20
<loic.actarus.joly@wanadoo.fr> writes
>Francis Glassborow wrote:
>
>> You manage to completely miss the point. For excellent design reasons=20
>>the language guarantees that it will never use operator new (and=20
>>new[])  nor operator delete (and delete[]) to acquire/release memory=20
>>other than  through the new and delete expressions.
>
>Could you please be more specific, of give me a link to a rationale of=20
>this "feature".


Well to start with because C++ allows user replacement of the allocators=20
and deallocators (replacement, not just overloading). If the user=20
replaces the allocators with her own versions, for example to do GC, how=20
will that work if the core language tries to use the basic allocators?


--=20
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be readin=
g
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 01 Dec 2003 01:11:49 +0000, Francis Glassborow wrote:

> Well to start with because C++ allows user replacement of the allocators
> and deallocators (replacement, not just overloading). If the user
> replaces the allocators with her own versions, for example to do GC, how
> will that work if the core language tries to use the basic allocators?

The core language should use the replaced versions in this case.
I don't see a conceptual problem.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Ekkehard Morgenstern"" <ekkehard.morgenstern@onlinehome.de> wrote in
message news:bpptoo$mm6$1@online.de...
>
>
> Now let's go back to the valof{} blocks:
>
>     void func( void ) {        // class member
>
>             MyTree* bigTree = valof  MyTree* {
>                     MyString s( userSelectFile() );
>                     MyFile f; f.Load( s );
>                     return loadTree( f );
>             }
>
>             bigTree->optimize();
>     }
>

You could rewrite the valof block above as a single expression, thus:

MyTree *bigTree = loadTree(MyFile().Load(MyString(userSelectFile())));

In fact, with the use of the sequence operator (a comma) and the ?:
operator, you could rewrite practically anything as a single expression, so
occasions for use of a valof feature would be very few even if you wanted to
code in that style. If you did, then Lisp programmers might love you, but
many C++ programmers would probably be inclined to hate you.

> In this case, the valof{} clearly improves the clarity of the code. If
you'd
> put every such little code fragment into a new little class member, you
> generate members that are used only once and for one purpose, which is bad
> style, IMO, especially when the code would be intertwined with the logics
of
> one specific function.

I think your ideas about good C++ style are topsy-turvy. If you break things
up into small functions or methods, you will generally find that your code
is easier to modify, reuse, and adapt to new situations. If you squeeze it
all into big functions that perform multiple tasks, you make your code more
inflexible.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> > 1. The addition of the BCPL valof (value of) expression syntax.
> >         valof-expr := 'valof' type '{' statement-block '}' .
> >         It would be notated like " int c = valof int { return 3+5; } "
>
> There's no need to add a keyword for something like this - just use a
named
> function.

Sometimes you don't want to use a named function, especially if you need it
only once, and/or if the code is to be private to the function it's in, or
if it's to be moved out later.

valof{} blocks also permit to group code in the case you don't want to
create an extra function but a subroutine within a function.

> > 3. The addition of optional range checking for standard array types.
> >            array-dim-def := '[' expr [ 'range' [ expr '..' expr ]
> > 'checked' ] ']' .
> >            this could look like "int a[3 range checked 0..2]" or
> >           "int a[3 range checked]" for example.
>
> Use std::vector and at().
>
> > 4. The addition of dynamic arrays.
> >             array-dim-def := '[' expr | 'dynamic' ']'
> >             this could look like "int a[dynamic];"
>
> std::vector.
>

Using "vector" requires that you have a C++ compiler that is shipped with
the STL, and it might generate extra code for every module if the compiler /
linker pair does not support template instance optimizations.

A built-in dynamic array type would relieve the programmer from such
worries. Explicit range check declarations would also contribute to the
overall readability of the code. Plus, it would be possible then to modify
code that used to work with regular arrays to be dynamic and/or range
checked.

> > 5. The addition of optionally checked pointer types.
> >             pointer-def := 'checked' type '*';  // or similar
> >             this could look like "checked int* p;"
> >             a pointer like this would be checked during runtime before
> >             usage (like, at the first use in every block scope or
> something,
> >             or during every operation).
>
> I'm not sure what you want to "check", but here's one way:

It's not just about null pointer checking. It would be possible then to
perform an implementation-defined pointer check (like checking if the
pointer is (still) addressing the memory it was allocated for, or if it
points to specific allocated memory pages of the process). You could also
use the term "validated".

By using classes, you possibly cannot achieve this, since it's a feature
that is implementation-specific but should be made transparent to the
programmer.

> Also the syntax "checked int * p" is horrible.  For consistency with C
type
> declarations this would mean the int is checked, not the pointer.  "int *
> checked p" would be better, although still unnecessary.

You're right, technically it belongs to the group "volatile / const /
mutable" .

So one could add another, "checked" or "validated".

> > 6. The addition of value range checking for integral or floating-point
> >     base types.
> >             range-checked-base-type :=
> >                 [ 'range' [ expr '..' expr ] 'checked' ] base-type .
> >             This could look like "range 0..2 checked int a;"
> >             A check would be performed before every assignment to such
> >             a variable.
> >             A default range-checked variable, like "range checked int
a;"
> >             would be checked for overflows in arithmetic operations
also.

> Some compilers support floating-point types as template parameters - I
think
> this is an extension.  So for those you may need members representing max
> and min, or stick to integral and rational bounds.

The approach you suggested to this would be nonstandard and with excess
typing overhead for using.

The reason why I'd like to see it as a standard feature in C++ is because
I'd like to encourage the use of range checks to make software more readable
and less error prone.

Also, if the range checking was a standard feature, it would also generate
less code than with user-supplied classes.

> > 7. The addition of an optional byte ordering syntax for integral or
> >     floating-point base types.
> >             ordered-base-type := [ ( 'msblsb' | 'lsbmsb' ) 'ordered' ]
> >                     base-type .
> >            This would look like 'msblsb ordered int a = 0x12345678;'.
> >            This would permit setting the byte ordering for structure
> >             members, for example. The compiler would generate code
> >             to read and write such variables properly, for example.
> >             This way, reading and writing such fields from and to
> >             permanent storage or streams would be a piece of cake
> >             without any programming overhead.
>
> This is more complex than the above examples, but can still be
accomplished
> with a user-defined class.  The nice thing about user-defined types is the
> language does not have to have built-in ways to define every conceivable
> datatype.
>

That's true, but if it's not a standard feature, people won't use it and
still store or transmit data in a platform-dependent manner.

If it'd be a standard feature to specify the byte ordering, it'd be possible
to encourage writing code platform-independently.

It'd also be easier for the compiler to do these things, than for the
programmer coding it manually, because many processors have already
instructions for those things.

Like, on the IA-32 architecture, a "msblsb ordered int a; int b; ... ; a =
b;" sequence could be translated to "mov eax,ebx; bswap eax;" for example,
that'd be just one extra instruction overhead.

> > 8. The definition of anonymous classes.
> >             class-decl := ( 'anonymous' 'class' | 'class' identifier )
> >                       class-decl-body .
> >             this would look like
> >             "A* a = new anonymous class : public A { ... }"
> >             Constructors and destructors could use "anonymous()"
> >             then.
>
> Again, I think there's no need to add new syntax for this when it is
rarely
> needed and a class in an anonymous namespace works as well.

Anonymous classes would be good for creating temporary classes that are
needed only for a specific purpose.

If you don't have such a feature, you have to create a class for every
single case of such use.

> From what you've said, it sounds like you'd be better off just
implementing
> the types you need in C++ then trying to create a new language to handle
> these things.  Languages get too convoluted when they try to create new
> syntax for everything - the power of object-oriented programming is that a
> language can provide the minimum necessary types and users can create all
> the aggregate types they need.

So you think C++ is a minimal and lightweight programming language? ;-)

As I said, some of the features just belong into the language because the
compiler would be able to generate shorter and more efficient code, and the
users would actually feel encouraged to use them.  They wouldn't add much
extra complexity to the language, in fact most of them would be simple to
integrate into an existing compiler.

As for my own programming language developments, I will still try to think
of simpler and easier to use programming languages.  :-)



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bpfts2$46i$1@online.de>...
> "James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
> news:8b42afac.0311161239.1e75f3f4@posting.google.com...
> > > 1. The addition of the BCPL valof (value of) expression syntax.
> > >         valof-expr := 'valof' type '{' statement-block '}' .
> > >         It would be notated like " int c = valof int { return 3+5; } "
> >
> > What is the use of this? How is this better than:
> >
> >     int c = 3+5;
>
> It allows grouping of expressions in an extra scope.
>
> Like, you'd sometimes create an isolated code block within a code block, as
> in:
>
>     {
>             ...
>             {
>                 ...
>             }
>     }
>
> to distinguish code blocks from one another. A valof{} expression does the
> same, but permits to return a result.

I'm afraid that still leaves me unclear about the advantages of this
feature. Perhaps a more specific example would make the usefullness
clearer?

...
> > I think you mean something similar to C99's variable length arrays. If
...
> With 'dynamic array' I mean an array that changes size dynamically during
> runtime.

OK, so that's not quite the same as a VLA. VLAs have a potentially
different size each time they are initialized, but do not change size
during their own lifetimes.

...
> > It's also less useful in C++, since C++ already has a way to declare
> > dynamically sized arrays (with somewhat different semantics):
> >
> >      vector<int> a(initial_size);
>
> This has the disadvantage that the template class "vector" has to be
> available and properly implemented in the implementation.
>
> Also, if the compiler replicates the template instance's code over every
> module, it can lead to code bloat.

Well, that's also true it the compiler replicates the code needed to
implement the dynamic array in every module. That's purely a QoI
issue.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bpfts2$46i$1@online.de>...
> "James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
> news:8b42afac.0311161239.1e75f3f4@posting.google.com...
> > It's also less useful in C++, since C++ already has a way to declare
> > dynamically sized arrays (with somewhat different semantics):
> >
> >      vector<int> a(initial_size);
>
> This has the disadvantage that the template class "vector" has to be
> available and properly implemented in the implementation.

How much of a problem is that? Where is std::vector not available or
implemented so poorly as to make this an issue?

> Also, if the compiler replicates the template instance's code over every
> module, it can lead to code bloat.

So we need to introduce VLAs for compilers that don't compile
templates very well, which by the time the next standard is finalized
won't be very many compilers.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ekkehard Morgenstern wrote:
> Using "vector" requires that you have a C++ compiler that is shipped with
> the STL,

Doesn't the Standard already require that every C++ compiler be shipped with
std::vector?

> and it might generate extra code for every module if the compiler /
> linker pair does not support template instance optimizations.

It might.  How many people use compilers that don't support template instance
optimizations?  How much extra code do those compilers add to an actual project?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bpfvqu$9nl$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>Using "vector" requires that you have a C++ compiler that is shipped with
>the STL, and it might generate extra code for every module if the compiler /
>linker pair does not support template instance optimizations.
>
>A built-in dynamic array type would relieve the programmer from such
>worries. Explicit range check declarations would also contribute to the
>overall readability of the code. Plus, it would be possible then to modify
>code that used to work with regular arrays to be dynamic and/or range
>checked.

And where is the array going to expand (The core language by design
never uses new/delete)? I cannot think of a single feature of a
'built-in' dynamic array that is not already provided by std::vector. In
addition it is completely contrary to the design philosophy of C++ to
introduce a built-in type that could be provided as a library type.

It seems to me that many of your proposals are concerned with QoI issues
and are, perhaps, motivated by exposure to a very poor C++
implementation. Legislation will not change that problem.



--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Matt Seitz wrote:

> > and it might generate extra code for every module if the compiler /
> > linker pair does not support template instance optimizations.
>
> It might.  How many people use compilers that don't
> support template instance optimizations?  How much extra
> code do those compilers add to an actual project?

What do you mean by "template instance optimizations"?  Are
you suggesting that some compilers are intelligent enough to
notice when A<T1>::fn() is exactly the same as A<T2>::fn()
and to commonise the implementation?

--
Richard Smith

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bpfvqu$9nl$1@online.de>...
...
> Using "vector" requires that you have a C++ compiler that is shipped with
> the STL, and it might generate extra code for every module if the compiler /
> linker pair does not support template instance optimizations.
>
> A built-in dynamic array type would relieve the programmer from such
> worries. ...

Why? How would you gaurantee that the implementation of the dynamic
array type was any more efficient than the implementation of
std::vector<>?

...
> > This is more complex than the above examples, but can still be
>  accomplished
> > with a user-defined class.  The nice thing about user-defined types is the
> > language does not have to have built-in ways to define every conceivable
> > datatype.
> >
>
> That's true, but if it's not a standard feature, people won't use it and
> still store or transmit data in a platform-dependent manner.

Standardizing it won't change that. People who can't be bothered with
it won't use it, even if it's standardized.

...
> > From what you've said, it sounds like you'd be better off just
>  implementing
> > the types you need in C++ then trying to create a new language to handle
> > these things.  Languages get too convoluted when they try to create new
> > syntax for everything - the power of object-oriented programming is that a
> > language can provide the minimum necessary types and users can create all
> > the aggregate types they need.
>
> So you think C++ is a minimal and lightweight programming language? ;-)

Yes, it is, at least when compared to what it would like like if every
feature similar to the ones you propose were actually implemented at
the language level.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Richard Smith wrote:
> Matt Seitz wrote:
>
>>>and it might generate extra code for every module if the compiler /
>>>linker pair does not support template instance optimizations.
>>
>>How many people use compilers that don't
>>support template instance optimizations?
>
> What do you mean by "template instance optimizations"?

I meant whatever the original poster meant.  To be clearer, I should have said
"compiler/linker pairs" as the original poster did.

> Are
> you suggesting that some compilers are intelligent enough to
> notice when A<T1>::fn() is exactly the same as A<T2>::fn()
> and to commonise the implementation?

No.  I am asking whether the claim that std::vector "might generate extra code
for every module if the compiler / linker pair does not support template
instance optimizations" is relevant for a signicant number of developers, or is
it just a hypothetical concern with little practical effect?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <HopKws.9Bv@news.boeing.com>, Kevin Saff
<google.com@kevin.saff.net> writes
>1) Macros that respect scope, namespaces, and optional strong-typing.
>No matter how many language constructs are added to avoid macros, it seems
>they still have their uses.  It might be best to admit their necessity and
>fix macros themselves instead of adding more workarounds for them.

Indeed which is why one of the proposals being considered by the
evolution group is to provide a mechanism for scoping macros.

>
>2) User-defined "metaclasses".
>C++ only provides two kinds of "metaclasses" that barely differ: struct and
>class.  Even the standard has the need to define sets of classes that are
>not easily described in the language itself (POD).  Also, consider how
>inheritance is inadequate for dealing with all the boiler-plate necessary to
>define a singleton, for instance.

I would not be so certain, as for all ideas for evolution of C++ it
would depend on a good well-presented proposal that passed cost-benefit
and impact analyses.

--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Bob Bell" <belvis@pacbell.net> schrieb im Newsbeitrag
news:c87c1cfb.0311202001.2188afec@posting.google.com...
> > This has the disadvantage that the template class "vector" has to be
> > available and properly implemented in the implementation.
>
> How much of a problem is that? Where is std::vector not available or
> implemented so poorly as to make this an issue?

On embedded systems, for example, you might want to use dynamic arrays, but
not want to use the STL.

Also, on simplified compiler implementations where templates aren't
available.

Although templates can be very useful, it doesn't mean that C++ has to
become entirely dependent on that language feature.


> > Also, if the compiler replicates the template instance's code over every
> > module, it can lead to code bloat.
>
> So we need to introduce VLAs for compilers that don't compile
> templates very well, which by the time the next standard is finalized
> won't be very many compilers.

I was talking about dynamic arrays not VLAs.

It would permit using C++ on embedded systems for example and still have
some comfortable features that don't rely on templates. When code size
matters, templates are a problem.

Even if you have a linker that successfully eliminates all template instance
duplicates, you still have a template instance for every type combination
that you used in the template. This can be very unnecessary, especially with
vector<> classes that do nothing but manage memory.

For base types, a dynamic array would be a more intelligent and code-saving
solution. A feature that should've been implemented in C++ long ago.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
news:8b42afac.0311200909.46fc5a49@posting.google.com...
> > to distinguish code blocks from one another. A valof{} expression does
the
> > same, but permits to return a result.
>
> I'm afraid that still leaves me unclear about the advantages of this
> feature. Perhaps a more specific example would make the usefullness
> clearer?

Since in C++ it's impossible to create local functions (which would also be
a neat feature), valof{} provides a good compromise.

Say, you have a complicated function that you don't want to split up in two,
for some reason, then you could use valof{} instead.

Here's an example of the use of scope blocks:

    void func( void ) {        // class member

            MyTree* bigTree = load();

            {
                    MyTree* optimizedTree = optimize( bigTree );
                    optimizedTree->save();
                    delete bigTree;
                    bigTree = optimizedTree;
            }

            {
                    MyTree* backEndTree = backend( bigTree );
                    backEndTree->save();
                    delete bigTree;
                    bigTree = backEndTree;
            }

    }

In these cases, there's more clarity when the scope blocks are within the
function.

Now let's go back to the valof{} blocks:

    void func( void ) {        // class member

            MyTree* bigTree = valof  MyTree* {
                    MyString s( userSelectFile() );
                    MyFile f; f.Load( s );
                    return loadTree( f );
            }

            bigTree->optimize();
    }

In this case, the valof{} clearly improves the clarity of the code. If you'd
put every such little code fragment into a new little class member, you
generate members that are used only once and for one purpose, which is bad
style, IMO, especially when the code would be intertwined with the logics of
one specific function.

> OK, so that's not quite the same as a VLA. VLAs have a potentially
> different size each time they are initialized, but do not change size
> during their own lifetimes.

Exactly. I read up on VLA's and basically it just means { int a = 5; int
b[a]; }. This is not the same what I was referring to. But this should've
been clear to you already when reading my example "int a[dynamic];". This
obviously means an array of dynamic size.

What I want is basically that you don't need to preset or fix the array
size, because in many cases you need array expansion and it'd be best to
leave it to the compiler / runtime code to decide when and how.


> Well, that's also true it the compiler replicates the code needed to
> implement the dynamic array in every module. That's purely a QoI
> issue.

Fact is, that a vector<> template class leads to more code than a built-in
dynamic array type. Especially if it can be supported directly by the
implementation somehow.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
news:URxkSCBfcdv$Ewuq@robinton.demon.co.uk...
> >A built-in dynamic array type would relieve the programmer from such
> >worries. Explicit range check declarations would also contribute to the
> >overall readability of the code. Plus, it would be possible then to
modify
> >code that used to work with regular arrays to be dynamic and/or range
> >checked.
>
> And where is the array going to expand (The core language by design
> never uses new/delete)?

The compiler would generate code for array access that would check if the
array index is out of bounds, and if so, resize the array.

If such a feature would be incorporated into the language, it would be
necessary of course to specify how the memory will be allocated and freed.

It could be, that during resizing, the global or class-embedded
array-new-operator would be called, and array-delete-operator likewise.


>  I cannot think of a single feature of a
> 'built-in' dynamic array that is not already provided by std::vector. In
> addition it is completely contrary to the design philosophy of C++ to
> introduce a built-in type that could be provided as a library type.

A built-in dynamic array type would be much more efficient than the
vector<>-Class. It would always use the same code for allocating / resizing,
unlike the dozens of template instances that you get even when you're doing
nothing but memory management.

But that should be obvious, shouldn't it?


> It seems to me that many of your proposals are concerned with QoI issues
> and are, perhaps, motivated by exposure to a very poor C++
> implementation. Legislation will not change that problem.

Well, let's see.

It's not just a QoI issue, it's a core design issue, that's why I made that
proposal.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Kevin Saff"" <google.com@kevin.saff.net> schrieb im Newsbeitrag
news:HopKws.9Bv@news.boeing.com...
> I don't see how your suggestion helps here.  If a compiler is so old/bad
it
> can't correctly handle vector how is adding dynamic arrays to the language
> spec going to help?  It will just mean 5 years of poor quality dynamic
array
> implementations, when proper vector support is available now.

Adding the dynamic array feature in the form I suggested it would be more
efficient and easier to implement than vector<>, plus it would not generate
code for every type, it would use array-new and array-delete, rather. That's
why I restricted it to base types. Otherwise you could use vector<> as well.


> > Also, if the range checking was a standard feature, it would also
generate
> > less code than with user-supplied classes.
>
> That may be true.  Give you range-checking now, though, and I'm sure
you'll
> want built-in _dynamic_ range-checking next year.

No, why would I?

Static range checking can be useful especially for beginners, but also for
experienced programmers who want to rule out sources of error.

> I don't see how byte ordering could be useful outside of I/O operations,
> where compared to the I/O bottleneck an extra function call or two would
> hardly be noticed?  Presumably one could use inline assembly to optimize
for
> specific platforms when necessary.  Put it in a place like boost.org, and
> I'm sure some people will use it.

My suggestion would permit programmers to read and write data structures
correctly byte-ordered directly from a stream, in a portable manner.

Using inline-assembly or extra-function calls make it more messy and less
portable.


> Of course not; I think it's already so complicated adding such new syntax
is
> unlikely to improve clarity.

These features are neither complex nor complicated to implement. Just a few
lines of code in the compiler. That's at least how I would do it. I've been
writing compilers for almost 15 years now.


> > As for my own programming language developments, I will still try to
think
> > of simpler and easier to use programming languages.  :-)
>
> I am sorry for being hard on you, though at a kidney per suggestion you
did
> go through about 5 lifetimes in writing that list.

Not sure what you mean by saying that, but it didn't take me much time to
come up with my suggestions. It took me more time to reply to all the
comments.

A few days ago I began learning Ada, and it just confirms my assumptions
that such features would be a good idea. Especially the data representation
and range checking features seem to be very important in Ada.

> 1) Macros that respect scope, namespaces, and optional strong-typing.

You already have that in C++. They're called "template classes" or "template
functions", respectively.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Ekkehard Morgenstern" wrote:
> "Bob Bell" <belvis@pacbell.net> schrieb im Newsbeitrag
> news:c87c1cfb.0311202001.2188afec@posting.google.com...
>>> This has the disadvantage that the template class "vector" has to be
>>> available and properly implemented in the implementation.
>>
>> How much of a problem is that? Where is std::vector not available or
>> implemented so poorly as to make this an issue?
>
> On embedded systems, for example, you might want to use dynamic
> arrays, but not want to use the STL.

Why would you not want to use std::vector on an embedded system ?

>
> Also, on simplified compiler implementations where templates aren't
> available.

Then those compilers are not C++ compliant. You want to add a feature to C++
compliance to accomodate theoretical compilers which are not C++ compliant.
That thinking is not logical.

>
> Although templates can be very useful, it doesn't mean that C++ has to
> become entirely dependent on that language feature.

They are part of the C++ language standard, and provide what you want
without having to change the language itself. Adding functionality to a
language, because you don't want to use something else which provides the
same functionality, is not a good reason to add a construct to C++.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bppvup$oqb$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>Adding the dynamic array feature in the form I suggested it would be more
>efficient and easier to implement than vector<>, plus it would not generate
>code for every type, it would use array-new and array-delete, rather. That's
>why I restricted it to base types. Otherwise you could use vector<> as well.

Please use standard terminology, do you mean operator new[]/delete[] or
the new and delete expressions for arrays.

If you are only going to provide the mechanism for fundamental types why
do you think it would not generate code for each type? Absolutely
nothing you can specify for your dynamic arrays is out of reach of good
compilers applied to std::vector for fundamental types and we are
actively looking at ways to improve the efficiency of vectors for more
complicated types (e.g. move ctors)

However if you really want to pursue this implement your ideas in a
compiler and demonstrate the utility.



--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bpptoo$mm6$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>Fact is, that a vector<> template class leads to more code than a built-in
>dynamic array type. Especially if it can be supported directly by the
>implementation somehow.

As a compiler is allowed to use 'magic' to implement standard library
functionality your assertion would appear to be false. However, unlike
core language features the library may use dynamic memory (i.e.
allocation from the heap)

--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote
(abridged):
> Since in C++ it's impossible to create local functions (which would
> also be a neat feature), valof{} provides a good compromise.

I would be more interested in a good proposal for local functions,
especially if they could capture local variables somehow and have external
linkage. Although valof is much simpler, I don't think it offers enough
benefit to be worth the trouble of updating compilers. I'd rather vendors
spent their time on better performance, tools, "export" etc.

Your example code would be shorter and simpler as:

     void func() {
         MyString s( userSelectFile() );
         MyFile f; f.Load( s );
         MyTree *bigTree = loadTree( f );
         bigTree->optimize();
     }

If the problem is that you need the file to be closed earlier, add
f.close() before the optimize().


> If you'd put every such little code fragment into a new little
> class member, you generate members that are used only once and for
> one purpose, which is bad style, IMO, especially when the code would
> be intertwined with the logics of one specific function.

I don't think separation of concerns is necessarily bad style, even if the
resulting function is called only once. I do think it is bad style to do
too much in one function. Your use of block scopes to partition a
functions code suggests to me that decomposition would be natural.

For what it's worth, I have many years practical experience with valof in
BCPL. I don't miss it in C/C++.

-- Dave Harris, Nottingham, UK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
news:8b42afac.0311210811.8116740@posting.google.com...
> ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in
message news:<bpfvqu$9nl$1@online.de>...
> Why? How would you gaurantee that the implementation of the dynamic
> array type was any more efficient than the implementation of
> std::vector<>?

It would use the array-new and array-delete operators directly. No type
treatment necessary, especially when you restrict it to base types only.


> > That's true, but if it's not a standard feature, people won't use it and
> > still store or transmit data in a platform-dependent manner.
>
> Standardizing it won't change that. People who can't be bothered with
> it won't use it, even if it's standardized.

If it's easy to use, people will use it.

Aside from academic discussion, in practice you often have the case when you
want to read or write a binary file or transmit data over a network.

A byte-ordering qualifier would greatly simplify that process, and make it
an almost bug-free-guaranteed endeavour.

> > So you think C++ is a minimal and lightweight programming language? ;-)
>
> Yes, it is, at least when compared to what it would like like if every
> feature similar to the ones you propose were actually implemented at
> the language level.
>

You must be joking. The features I suggested are just some lines of extra
code in the compiler. I'm a compiler writer, so I know how such features are
implemented.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bppu91$n07$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>"Bob Bell" <belvis@pacbell.net> schrieb im Newsbeitrag
>news:c87c1cfb.0311202001.2188afec@posting.google.com...
>> > This has the disadvantage that the template class "vector" has to be
>> > available and properly implemented in the implementation.
>>
>> How much of a problem is that? Where is std::vector not available or
>> implemented so poorly as to make this an issue?
>
>On embedded systems, for example, you might want to use dynamic arrays, but
>not want to use the STL.

You mean you want to burden the core language with requirements that
would make it just as problematical as using the STL.?

>
>Also, on simplified compiler implementations where templates aren't
>available.

No, you are making the compiler much more complicated because it will
have to have most of std::vector builtin to the core language.

>
>Although templates can be very useful, it doesn't mean that C++ has to
>become entirely dependent on that language feature.

And generic programming is immensely useful but that is not a reason to
create fundamental generic types.

>
>
>> > Also, if the compiler replicates the template instance's code over every
>> > module, it can lead to code bloat.
>>
>> So we need to introduce VLAs for compilers that don't compile
>> templates very well, which by the time the next standard is finalized
>> won't be very many compilers.
>
>I was talking about dynamic arrays not VLAs.
>
>It would permit using C++ on embedded systems for example and still have
>some comfortable features that don't rely on templates. When code size
>matters, templates are a problem.

And so would dynamic arrays because they would require just about the
same functionality that std::vector provides.

>
>Even if you have a linker that successfully eliminates all template instance
>duplicates, you still have a template instance for every type combination
>that you used in the template. This can be very unnecessary, especially with
>vector<> classes that do nothing but manage memory.

Only 'used' member functions are instantiated so the cost would be
almost exactly the same as using std::vector. It might even prove to be
higher as every TU using a dynamic array of T would have to initially
provide the appropriate functionality. If that is not provide via
callable functions it is harder for the linker to pull out duplication.

>
>For base types, a dynamic array would be a more intelligent and code-saving
>solution. A feature that should've been implemented in C++ long ago.

Sorry, but I absolutely disagree. Quite apart from anything else it
would require a completely new block of memory with its own memory
manager. I suspect that you have little idea of the effects of adding
dynamic arrays would have to the complexity of the language. You see it
as a simplification to std::vector, I see it as an unnecessary
complication.


However if you really want them, take GCC and add the feature and then
demonstrate its utility. Otherwise listen to the advice from
implementers.

>

--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bppus6$nh6$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>"Francis Glassborow" <francis@robinton.demon.co.uk> schrieb im Newsbeitrag
>news:URxkSCBfcdv$Ewuq@robinton.demon.co.uk...
>> >A built-in dynamic array type would relieve the programmer from such
>> >worries. Explicit range check declarations would also contribute to the
>> >overall readability of the code. Plus, it would be possible then to
>modify
>> >code that used to work with regular arrays to be dynamic and/or range
>> >checked.
>>
>> And where is the array going to expand (The core language by design
>> never uses new/delete)?
>
>The compiler would generate code for array access that would check if the
>array index is out of bounds, and if so, resize the array.
>
>If such a feature would be incorporated into the language, it would be
>necessary of course to specify how the memory will be allocated and freed.
>
>It could be, that during resizing, the global or class-embedded
>array-new-operator would be called, and array-delete-operator likewise.

You manage to completely miss the point. For excellent design reasons
the language guarantees that it will never use operator new (and new[])
nor operator delete (and delete[]) to acquire/release memory other than
through the new and delete expressions. Your dynamic arrays cannot
reside on the stack, cannot use static memory and by long term design
must not use the heap provided for allocation of dynamic memory. So your
proposal would require radical changes that break guarantees that have
been given about the way the language will behave.

>
>
>>  I cannot think of a single feature of a
>> 'built-in' dynamic array that is not already provided by std::vector. In
>> addition it is completely contrary to the design philosophy of C++ to
>> introduce a built-in type that could be provided as a library type.
>
>A built-in dynamic array type would be much more efficient than the
>vector<>-Class. It would always use the same code for allocating / resizing,
>unlike the dozens of template instances that you get even when you're doing
>nothing but memory management.

Interesting assertion but what is it based on? Unless a class has its
own overloaded version of new[] all vectors use exactly the same code
for acquiring and releasing memory that is what operator new[] and
operator delete[] are for.

>
>But that should be obvious, shouldn't it?

Obvious yes, but obvious that your proposal actually requires a second
distinct mechanism and as such results in larger code.

>
>
>> It seems to me that many of your proposals are concerned with QoI issues
>> and are, perhaps, motivated by exposure to a very poor C++
>> implementation. Legislation will not change that problem.
>
>Well, let's see.
>
>It's not just a QoI issue, it's a core design issue, that's why I made that
>proposal.

You have not persuaded me and until you do I will not want to spend
Committee time on it. Of course mine is by far from being the only voice
but I know of far more valuable items that are not likely to make it so
I guess that many others will come to the same conclusion, the possible
benefits (if any) do not justify the costs.

>

--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bppvup$oqb$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>You already have that in C++. They're called "template classes" or "template
>functions", respectively.

Actually they aren't they are called class templates and function
templates.

--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bppu91$n07$1@online.de>...
...
> Even if you have a linker that successfully eliminates all template instance
> duplicates, you still have a template instance for every type combination
> that you used in the template. This can be very unnecessary, especially with
> vector<> classes that do nothing but manage memory.

And how do dynamic arrays avoid this? Necessarily, the emmitted code
that handles a given type of dynamic array is different for different
types, the same as would be true with vector<>. As a built-in type,
that code is also likely to get inlined, just as is usually the case
with vector<>, which would tend to make the point moot.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bppu91$n07$1@online.de>...
> It would permit using C++ on embedded systems for example and still have
> some comfortable features that don't rely on templates. When code size
> matters, templates are a problem.

In poor implementations, maybe.

> Even if you have a linker that successfully eliminates all template instance
> duplicates, you still have a template instance for every type combination
> that you used in the template. This can be very unnecessary, especially with
> vector<> classes that do nothing but manage memory.

There is no reason why an implementation of std::vector cannot be as
efficient as the hypothetical dynamic arrays you describe.

You seem to think that

std::vector<int> x;
std::vector<long> y;

necessarily duplicates code. There is nothing in the standard that
says that must be true. There are implementation techniques that allow
standard library  vendors to avoid duplication and bloat. As time goes
on, more and more libary implementations will use those techniques.

> For base types, a dynamic array would be a more intelligent and code-saving
> solution. A feature that should've been implemented in C++ long ago.

There are many reasons to prefer extending the language by adding to
the library, not adding to the syntax.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Dave Harris" <brangdon@cix.co.uk> schrieb im Newsbeitrag
news:memo.20031124122824.1648B@brangdon.m...
> ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote
> (abridged):
> > Since in C++ it's impossible to create local functions (which would
> > also be a neat feature), valof{} provides a good compromise.
>
> I would be more interested in a good proposal for local functions,
> especially if they could capture local variables somehow and have external
> linkage.

That's very simple, just add the function declaration statement to the list
of permitted statements in statement blocks (in the language syntax
definition).

In compilers, it's a piece of cake to integrate them into the scope
management.

External symbol table resolution could occur the same as it does for
embedded classes or class members, X::Y::Z.

Code generators could provide extra parameters to the functions, one for
every level of embedded function scope, or similar scheme. This would allow
accessing variables in nested function contexts. Calling nested functions
externally would be possible only for static functions that have no access
to embedding scopes.


> Although valof is much simpler, I don't think it offers enough
> benefit to be worth the trouble of updating compilers.

It's just a few lines of extra code. All you need to do in the compiler is
to generate a code section in the function body that contains the
valof-block-code, which is very simple, and then you have to generate calls
to it. I estimate about 5-10 extra lines of compiler source for that. Now
that's a major task that needs to move planets, right?


> I'd rather vendors
> spent their time on better performance, tools, "export" etc.

Especially they should spend time on their code generators, what good is a
sophisticated CPU if its instruction set isn't used?


> Your example code would be shorter and simpler as:
>
>      void func() {
>          MyString s( userSelectFile() );
>          MyFile f; f.Load( s );
>          MyTree *bigTree = loadTree( f );
>          bigTree->optimize();
>      }
>
> If the problem is that you need the file to be closed earlier, add
> f.close() before the optimize().

It was just a fantasy example to illustrate the problem. You could picture
the same function with a hundred times more lines of code, and it would
still make sense to structure it.

In reality, source code is not always squeezable into neat little functions
that satisfy academic play of thought.

Just picture a situation in which you're not allowed to modify a class.
You're only allowed to modify a single function, and then you have to cram
3,000 lines of extra code into it. That's real world programming, not the
type of stuff you are talking about. Hence, it's necessary to provide
methods to structure the code, even if it's inside function blocks.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
news:8b42afac.0311240858.460b0ccc@posting.google.com...
> And how do dynamic arrays avoid this? Necessarily, the emmitted code
> that handles a given type of dynamic array is different for different
> types, the same as would be true with vector<>. As a built-in type,
> that code is also likely to get inlined, just as is usually the case
> with vector<>, which would tend to make the point moot.

Dynamic arrays, if restricted to base types, don't require their type for
resizing except for static inline reallocation expressions.

Reallocation could be done inline using malloc( sizeof(T) * n ), which
generates a function call with a parameter multiplied by a constant.

Using vector<>, with a generic implementation (i.e. that doesn't optimize
for the base types), you cannot use malloc(). Hence, the template-code is
instantiated at least once for every type. It's the main reason why C++
programs become so big in code size. Especially on Windows with the
widespread cheap compilers there, which often don't even resolve template
instances of the same type signature across module boundaries.

That's why the discussion is moot.

You can be sure, that as a programming language designer, I have thought
about all these things, and that my proposals aren't unfounded.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bpu30f$p2k$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>Just picture a situation in which you're not allowed to modify a class.
>You're only allowed to modify a single function, and then you have to cram
>3,000 lines of extra code into it. That's real world programming, not the
>type of stuff you are talking about. Hence, it's necessary to provide
>methods to structure the code, even if it's inside function blocks.

This is so far from reality as to be virtually valueless. When I wish to
define a function with complicated internals I do it like this:

file.cpp

// normal front matter
namespace {
// all the pieces that are required
}

mytype foo(/*whatever*/){
// call the pieces as necessary
}

To the outside world that is a single function, and after compilation it
may be a single chunk of code (as the compiler may well elect to inline
all the code from the unnamed namespace).

If I have data that requires to be accessed by several pieces I can put
a suitable class inside my unnamed namespace.

That is not to say that local functions have no use but just that they
have little use for code structuring.


--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

brangdon@cix.co.uk (Dave Harris) wrote in message news:<memo.20031124122824.1648B@brangdon.m>...
>
> For what it's worth, I have many years practical experience with valof in
> BCPL. I don't miss it in C/C++.

Me too. Of course, that could be because valof was not just used for
anonymous functions, but was essentially the _only_ way to define
non-trivial bodies for named functions in BCPL, and 90% of valofs
appeared in the form

let f(x, y) = valof
$(
...
resultis z
$)

With BCPL's "no dynamic free variables" rule (in C/C++ terms, the
scope of auto variables didn't extend inside nested functions) the
scope for creative use of anonymous functions was quite limited.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bpu3gu$c7a$1@online.de>, Ekkehard Morgenstern
<ekkehard.morgenstern@onlinehome.de> writes
>
>"James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
>news:8b42afac.0311240858.460b0ccc@posting.google.com...
>> And how do dynamic arrays avoid this? Necessarily, the emmitted code
>> that handles a given type of dynamic array is different for different
>> types, the same as would be true with vector<>. As a built-in type,
>> that code is also likely to get inlined, just as is usually the case
>> with vector<>, which would tend to make the point moot.
>
>Dynamic arrays, if restricted to base types, don't require their type for
>resizing except for static inline reallocation expressions.
>
>Reallocation could be done inline using malloc( sizeof(T) * n ), which
>generates a function call with a parameter multiplied by a constant.
>
>Using vector<>, with a generic implementation (i.e. that doesn't optimize
>for the base types), you cannot use malloc(). Hence, the template-code is
>instantiated at least once for every type. It's the main reason why C++
>programs become so big in code size. Especially on Windows with the
>widespread cheap compilers there, which often don't even resolve template
>instances of the same type signature across module boundaries.

Once again you are addressing 'poor' quality library implementations,
but we do not have to use those even if they are shipped with the
compiler.

>
>That's why the discussion is moot.
>
>You can be sure, that as a programming language designer, I have thought
>about all these things, and that my proposals aren't unfounded.

And you can be sure that quite a few of those responding are very
familiar with the issues, some as language designers and many as those
with a great deal of practical experience of implementation of both
compilers and libraries.

Please prioritise your efforts, I think the likelihood of C++ evolving
to include dynamic arrays of fundamental types is as close to zero as
makes no difference. It would breach another design criterion of C++,
UDTs are first class types.


--
Francis Glassborow      ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bpptoo$mm6$1@online.de>...
> "James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
> news:8b42afac.0311200909.46fc5a49@posting.google.com...
> > > to distinguish code blocks from one another. A valof{} expression does
>  the
> > > same, but permits to return a result.
> >
> > I'm afraid that still leaves me unclear about the advantages of this
> > feature. Perhaps a more specific example would make the usefullness
> > clearer?
>
> Since in C++ it's impossible to create local functions (which would also be
> a neat feature), valof{} provides a good compromise.
>
> Say, you have a complicated function that you don't want to split up in two,
> for some reason, then you could use valof{} instead.
>
> Here's an example of the use of scope blocks:
>
>     void func( void ) {        // class member
>
>             MyTree* bigTree = load();
>
>             {
>                     MyTree* optimizedTree = optimize( bigTree );
>                     optimizedTree->save();
>                     delete bigTree;
>                     bigTree = optimizedTree;
>             }
>
>             {
>                     MyTree* backEndTree = backend( bigTree );
>                     backEndTree->save();
>                     delete bigTree;
>                     bigTree = backEndTree;
>             }
>
>     }
>
> In these cases, there's more clarity when the scope blocks are within the
> function.
>
> Now let's go back to the valof{} blocks:
>
>     void func( void ) {        // class member
>
>             MyTree* bigTree = valof  MyTree* {
>                     MyString s( userSelectFile() );
>                     MyFile f; f.Load( s );
>                     return loadTree( f );
>             }
>
>             bigTree->optimize();
>     }

I find that rather confusing, and the following re-write to be much
clearer:

void func(void)
{
    MyString s(userSelectFile());
    MyFile f;
    f.Load(s);
    MyTree * bigTree = loadTree(f);
    bigTree->optimize();
}


> > OK, so that's not quite the same as a VLA. VLAs have a potentially
> > different size each time they are initialized, but do not change size
> > during their own lifetimes.
>
> Exactly. I read up on VLA's and basically it just means { int a = 5; int
> b[a]; }. This is not the same what I was referring to. But this should've
> been clear to you already when reading my example "int a[dynamic];". This
> obviously means an array of dynamic size.

It wasn't clear to me what you meant by an array of dynamic size, and
an VLA can be described as dynamic. It's not dynamic in the case that
you give, which is a legal use of a VLA, but that's not at all the
typical use of them. The case you gave could be emulated using a macro
named 'a' with an expansion of '5', and be legal even in C90. A far
more typical of VLAs is when the size actually is variable:

void matmul(int pages, int rows, int cols,
     double a[pages][rows],
     double b[rows][cols],
     double c[pages][cols]
){
    for(int page=0; page<pages; page++)
        for(int col=0; col<cols; col++)
        {
            double sum = 0.0;
            for(int row=0; row<rows; row++)
                sum += a[page][row]*b[row][col];
            c[page][col] = sum;
        }
}

For any given call to matmul(), the sizes of the arrays are fixed, but
each time it's called, they can be different, which is why I
considered this a possible interpretation of "dynamic array".

...
> > Well, that's also true it the compiler replicates the code needed to
> > implement the dynamic array in every module. That's purely a QoI
> > issue.
>
> Fact is, that a vector<> template class leads to more code than a built-in
> dynamic array type. Especially if it can be supported directly by the
> implementation somehow.

If your vendor provides a poor quality of implementation for vector<>,
you shouldn't count on them providing a decent quality implementation
of dynamic arrays. If they provide a good quality implmentation of
vector<>, you shouldn't see a lot of difference between them.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <c87c1cfb.0311241008.ec436b5@posting.google.com>,
 belvis@pacbell.net (Bob Bell) wrote:

> There is no reason why an implementation of std::vector cannot be as
> efficient as the hypothetical dynamic arrays you describe.
>
> You seem to think that
>
> std::vector<int> x;
> std::vector<long> y;
>
> necessarily duplicates code. There is nothing in the standard that
> says that must be true. There are implementation techniques that allow
> standard library  vendors to avoid duplication and bloat. As time goes
> on, more and more libary implementations will use those techniques.

<nod>  Metrowerks has been doing this for awhile now.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 24 Nov 2003 23:10:51 +0000, Ekkehard Morgenstern wrote:

>> I would be more interested in a good proposal for local functions,
>> especially if they could capture local variables somehow and have external
>> linkage.
>
> That's very simple, just add the function declaration statement to the list
> of permitted statements in statement blocks (in the language syntax
> definition).

What about passing such functions as pointers? What about making functions
which live longer than their enclosing scope? Both things are what makes
them useful - if they are merely called, it's easy to simulate them by hand
by passing free variables as parameters.

The first thing can be hacked without changing the representation of
function pointers. GCC supports local functions in C (but not in C++)
and passing them by pointer requires generating a piece of code on the
stack. Well, grsecurity patch for Linux breaks this by marking the stack
as non-executable.

The second thing is hard conceptually without garbage collection, I don't
know how to do this. Copying free variables to attach them to the function
would be inconsistent semantically because global variables are shared.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bpu3gu$c7a$1@online.de>...
> "James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
> news:8b42afac.0311240858.460b0ccc@posting.google.com...
> > And how do dynamic arrays avoid this? Necessarily, the emmitted code
> > that handles a given type of dynamic array is different for different
> > types, the same as would be true with vector<>. As a built-in type,
> > that code is also likely to get inlined, just as is usually the case
> > with vector<>, which would tend to make the point moot.
>
> Dynamic arrays, if restricted to base types, don't require their type for
> resizing except for static inline reallocation expressions.

What do you mean by base type? Base classes? Builtin types?

> Reallocation could be done inline using malloc( sizeof(T) * n ), which
> generates a function call with a parameter multiplied by a constant.
>
> Using vector<>, with a generic implementation (i.e. that doesn't optimize
> for the base types), you cannot use malloc().

Of course you can.

> Hence, the template-code is
> instantiated at least once for every type. It's the main reason why C++
> programs become so big in code size.

Excuse me? I've written pretty big programs that don't touch
templates, and I've written some pretty small ones with templates.

> Especially on Windows with the
> widespread cheap compilers there, which often don't even resolve template
> instances of the same type signature across module boundaries.

The thing I keep going back to is, why do you think a change in the
standard will help with compilers that aren't standard?

> That's why the discussion is moot.
>
> You can be sure, that as a programming language designer, I have thought
> about all these things, and that my proposals aren't unfounded.

If by "base types" you mean builtin types, then you haven't thought
about one of C++'s core ideals: to make user-defined types behave, as
much as possible, like the builtins. If you restrict your dynamic
array proposal to builtins, you're deviating rather sharply from this
ideal.

Bob

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

""Kevin Saff"" <google.com@kevin.saff.net> wrote in message news:HopKws.9Bv@news.boeing.com...
> I can think of two
> things that will never be in C++, that might be worth building a new
> language for:
>
> 1) Macros that respect scope, namespaces, and optional strong-typing.
> No matter how many language constructs are added to avoid macros, it seems
> they still have their uses.  It might be best to admit their necessity and
> fix macros themselves instead of adding more workarounds for them.

How about Lisp macros?

> 2) User-defined "metaclasses".
> C++ only provides two kinds of "metaclasses" that barely differ: struct and
> class.  Even the standard has the need to define sets of classes that are
> not easily described in the language itself (POD).  Also, consider how
> inheritance is inadequate for dealing with all the boiler-plate necessary to
> define a singleton, for instance.

Pet peeve of mine.  In C++ struct and class are the same (modulo syntactic sugar).
I would find it much clearer if the use of structs was restricted to PODs.

Of course, that would break so much existing code as to make the chance of it happening effectively nil.
Still, a man can dream...

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi all,

I'd like to suggest the following features for future standards of the C++
programming language. I have not read the more recent standard documents, so
I'm not sure whether some are already in the standard, so tell me if so.

1. The addition of the BCPL valof (value of) expression syntax.
        valof-expr := 'valof' type '{' statement-block '}' .
        It would be notated like " int c = valof int { return 3+5; } "
2. The addition of at least standard headers, if not new types, for
     bit-size-specific types, like "uint32_t".
3. The addition of optional range checking for standard array types.
           array-dim-def := '[' expr [ 'range' [ expr '..' expr ]
'checked' ] ']' .
           this could look like "int a[3 range checked 0..2]" or
          "int a[3 range checked]" for example.
4. The addition of dynamic arrays.
            array-dim-def := '[' expr | 'dynamic' ']'
            this could look like "int a[dynamic];"
5. The addition of optionally checked pointer types.
            pointer-def := 'checked' type '*';  // or similar
            this could look like "checked int* p;"
            a pointer like this would be checked during runtime before
            usage (like, at the first use in every block scope or something,
            or during every operation).
6. The addition of value range checking for integral or floating-point
    base types.
            range-checked-base-type :=
                [ 'range' [ expr '..' expr ] 'checked' ] base-type .
            This could look like "range 0..2 checked int a;"
            A check would be performed before every assignment to such
            a variable.
            A default range-checked variable, like "range checked int a;"
            would be checked for overflows in arithmetic operations also.
7. The addition of an optional byte ordering syntax for integral or
    floating-point base types.
            ordered-base-type := [ ( 'msblsb' | 'lsbmsb' ) 'ordered' ]
                    base-type .
           This would look like 'msblsb ordered int a = 0x12345678;'.
           This would permit setting the byte ordering for structure
            members, for example. The compiler would generate code
            to read and write such variables properly, for example.
            This way, reading and writing such fields from and to
            permanent storage or streams would be a piece of cake
            without any programming overhead.
8. The definition of anonymous classes.
            class-decl := ( 'anonymous' 'class' | 'class' identifier )
                      class-decl-body .
            this would look like
            "A* a = new anonymous class : public A { ... }"
            Constructors and destructors could use "anonymous()"
            then.

(I'll implement these features in my new Q2 (working title) programming
language, but it'd be great to find them in C++ as well.)

Regards,
Ekkehard Morgenstern.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ekkehard.morgenstern@onlinehome.de ("Ekkehard Morgenstern") wrote in message news:<bp3l5h$hm9$1@online.de>...
> Hi all,
>
> I'd like to suggest the following features for future standards of the C++
> programming language. I have not read the more recent standard documents, so
> I'm not sure whether some are already in the standard, so tell me if so.
>
> 1. The addition of the BCPL valof (value of) expression syntax.
>         valof-expr := 'valof' type '{' statement-block '}' .
>         It would be notated like " int c = valof int { return 3+5; } "

What is the use of this? How is this better than:

    int c = 3+5;


> 2. The addition of at least standard headers, if not new types, for
>      bit-size-specific types, like "uint32_t".

These were added in C99, and are likely to be added in some form to
the next version of C++.

> 4. The addition of dynamic arrays.
>             array-dim-def := '[' expr | 'dynamic' ']'
>             this could look like "int a[dynamic];"

I think you mean something similar to C99's variable length arrays. If
so, it needs to be considered very carefully. The C99 committee found
that VLAs had lots of complicated side-effects on the language
specification. In particular, sizeof(vla) has to be evaluated at run
time, rather than compile time. I suspect that the revisions to C++
that would be needed are much greater.

It's also less useful in C++, since C++ already has a way to declare
dynamically sized arrays (with somewhat different semantics):

     vector<int> a(initial_size);

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

James Kuyper wrote:
>
> I think you mean something similar to C99's variable length arrays. If
> so, it needs to be considered very carefully. The C99 committee found
> that VLAs had lots of complicated side-effects on the language
> specification. In particular, sizeof(vla) has to be evaluated at run
> time, rather than compile time. I suspect that the revisions to C++
> that would be needed are much greater.
>

One fairly obvious example is the interaction of VLA's with inheritance.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Kuyper" <kuyper@wizard.net> schrieb im Newsbeitrag
news:8b42afac.0311161239.1e75f3f4@posting.google.com...
> > 1. The addition of the BCPL valof (value of) expression syntax.
> >         valof-expr := 'valof' type '{' statement-block '}' .
> >         It would be notated like " int c = valof int { return 3+5; } "
>
> What is the use of this? How is this better than:
>
>     int c = 3+5;

It allows grouping of expressions in an extra scope.

Like, you'd sometimes create an isolated code block within a code block, as
in:

    {
            ...
            {
                ...
            }
    }

to distinguish code blocks from one another. A valof{} expression does the
same, but permits to return a result.

Bjarne Stroustrup once wrote in an issue of  "The C++ Programming Language"
(on page 4 of the Second Edition), that "C++ still lacks a VALOF block".

I agree that that would be a useful extension to the language. valof{}
blocks have some of the advantages of unnamed functions. At least you can
integrate code that would normally belong into a seperate function, but is
used only once, into a seperate block of the same function, to be moved out
later when necessary.

> > 4. The addition of dynamic arrays.
> >             array-dim-def := '[' expr | 'dynamic' ']'
> >             this could look like "int a[dynamic];"
>
> I think you mean something similar to C99's variable length arrays. If
> so, it needs to be considered very carefully. The C99 committee found
> that VLAs had lots of complicated side-effects on the language
> specification. In particular, sizeof(vla) has to be evaluated at run
> time, rather than compile time. I suspect that the revisions to C++
> that would be needed are much greater.

Since the compiler knows what type an array is of, it can generate code for
sizeof() appropriately, either generating a constant expression or an
intrinsic function call.

For example, if the dynamic array is to be internally represented by either
a specialized pointer type or a pointer to a specialized data structure,
implementation-dependent, then sizeof() could return a constant value if
applied to a structure containing a dynamic array, but return the array's
actual size when applied to the array itself.

With 'dynamic array' I mean an array that changes size dynamically during
runtime.

For example, it could be replaced by vector<T> internally, if so defined. It
would just be syntactically easier to write "int a[dynamic];" instead of
"vector<int> a;" and then some.

> It's also less useful in C++, since C++ already has a way to declare
> dynamically sized arrays (with somewhat different semantics):
>
>      vector<int> a(initial_size);

This has the disadvantage that the template class "vector" has to be
available and properly implemented in the implementation.

Also, if the compiler replicates the template instance's code over every
module, it can lead to code bloat.

A dynamic array for base types would resolve the cases of most frequent use.

Of course, then you could also integrate a "string" type into the language.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]