001. Why zero ? I like 0xDEADDEAD :) Seriously, how many compilers
does not issue warning on usage of uninitialzed variables ?

003. Declaring function inside functions always was a part of C++.
AFAIR, the only exceptiin is an extern "C" declarations. I don't know
what was a reason for this exception. Probably a good one.

002./004. I don't like this two at all. Both proposal share a common
virtue - an attempt to make writing code easier. IMHO, it is a wrong
goal for a "production" language like C++ ("production" as an opposite
to RAD or "quick and dirty" languages). The right goal is improving
readability. If by accident it happens to improve "writabily" too - so
good.

Now to my own wish list.
In principle, I would prefer to not add features at all and to remove
quite a bit. My main enemy is a static polymorphism in all forms,
including operators overloading. Of coarse I realize that removing
static polymorphism is not going to happen for at least two reasons:
1. The overwhelming majority of the C++ users think I am wrong about
it.
2. It breaks majority of the existing code.
But I have a dream.

Now let's assume that I have no choice - if I would not add my feature
somebody else would be allowed to add his - a nightmare.
Then I'd add a support for the envelop/letter pattern at the language
level.
Scott Meyers suggested this addition in his "Effective C++".
Unfortunatly he didn't elaborate about the possible syntax. As is, the
pattern is already usefull for big projects. However implementing it
as a part of the language would improve its usefullness quite a lot.

---
[ 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                       ]

Ok some wishes:
- remove export or make it really work
- make iostreams forward declarable again
- move vector or equivalent into the language itself (kills string as well)
- add in the missing bits of RTTI
- require all new extensions to be fully implemented by two vendors before
adoption
- make c++ posix friendly

well that was fun
bye


---
[ 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                       ]

danielgutson@hotmail.com wrote:
> 1) Type inference
> I'm afraid I joint a bit late to this thread, but have some doubts.
> It is not clear for me:
> * the type-inference rule
> * the benefit
>=20
> But, seeing the [explicitation of] the type of i, is not a matter of
> =B4specifying its type=B4 only, but also provides the information: "it=B4=
s a
> new variable", so the reader doesn=B4t need to go up and look for it.
>=20

I like the idea, but I would suggest the following:

- the automatic type inference should require the keywork 'auto', i.e.,

       std::vector<int> v;
       for (auto it=3Dv.begin(); it!=3Dv.end(); i++);

- it should not be allowed for integer or floating-point types, but only =
for
   types that can be exactly deduced from the initial value, i.e., the au=
to
   variable must have the same type as the init value.

The benefit is that working especially with STL would be much more conven=
ient.
This is the only library I used, where I thought, please give me an easy =
way
to get to the iterator type without cluttering my source code. And typede=
fs
are in most situations an overkill.

For integers and reals, the benefit is to small to justify it. The pitfal=
ls
might be worse.

Robert

---
[ 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 <z6o6a.54785$jM5.138193@newsfeeds.bigpond.com>, Nick Thurn
<thurni@bigpond.com> writes
>- move vector or equivalent into the language itself (kills string as well)

It is already as far in the language as it can conceivably get unless
you want vector to be a keyword which would break existing code. Because
it is part of the Standard C++ Library it can receive any special
treatment aka compiler magic, that an implementor wishes to provide.

What has that to do with string which is completely unrelated to vector.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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 <v5jrc7phuecd2c@corp.supernews.com>, Robert Graulich
<graulich@synopsys.com> writes
>I like the idea, but I would suggest the following:
>
>- the automatic type inference should require the keywork 'auto', i.e.,
>
>      std::vector<int> v;
>      for (auto it=v.begin(); it!=v.end(); i++);
>
>- it should not be allowed for integer or floating-point types, but only for
>  types that can be exactly deduced from the initial value, i.e., the auto
>  variable must have the same type as the init value.
>
>The benefit is that working especially with STL would be much more convenient.
>This is the only library I used, where I thought, please give me an easy way
>to get to the iterator type without cluttering my source code. And typedefs
>are in most situations an overkill.
>
>For integers and reals, the benefit is to small to justify it. The pitfalls
>might be worse.

This is just a small restricted corner of the larger issues that we are
already actively considering.


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

thurni@bigpond.com ("Nick Thurn") writes:
[snip]
> - make iostreams forward declarable again
[snip]

What about <iosfwd> ?

---
[ 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                       ]

ai@springtimesoftware.com ("David Spector") wrote in message
news:<v4qrg79o2vtjb2@corp.supernews.com>...

> However, saying that it requires an extra compiler pass makes the
> feature appear to have a significant cost.

> Typically, a compiler parses a program, builds the symbol table, and
> does limited semantic analysis during its first pass, then does
> optimization (using techniques such as dataflow analysis) and code
> generation in its second pass.

> Any compiler already has a central symbol table, which accumulates
> declarative and other information for each program symbol (identifier,
> etc.). In fact, it takes extra work to enforce order constraints in
> modern compilers. (When I implemented parsing and semantic analysis
> for a Fortran compiler, I had to add a field to the symbol structure
> to indicate what had been done so far, purely for the purpose of
> generating error messages when ordering constraints were violated.)

> Eliminating unnecessary order restrictions has only minimal cost in
> compiler programmers' time and the size of the compiler and its
> associated data. It has no impact on runtime performance or program
> correctness.

A lot depends on the language.  I'm not sure that there is any "typical"
with regards to how a compiler does things.  A modern C++ compiler will
probably only make one pass over the actual source code, doing the
preprocessing in parallel with the lexical analysis.  This pass will
build an internal representation of the program (generally on a function
by function basis), which in turn is used for all later work.  Building
this internal representation requires being able to parse the language
correctly, e.g. to distinguish between a declaration and a definition.
In C++, it is impossible to parse the language correctly without having
seen the preceding declarations; the language is not context
independant, and whether a particular user symbol refers to a variable
or a function, a type, or a template affects parsing significantly.  For
this reason, if the ordering constraints were relaxed, a C++ compiler
would have to make a preliminary pass to catch all of the declarations.
Noting, of course, which ones were in scope where.  And even then, I'm
not sure it would be possible; whether a statement is a declaration or
not depends on the declarations of the symbols used in it.

I think we can conclude that such a change would be expensive to
implement.  It would also break code, although how much, I don't know.
That's two very powerful arguments against it.

And I fail to see where it would buy us anything.  I've yet to see an
argument for it, other than the vague statement that it would be nice
(which I don't agree with).

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]

David Spector <ai@springtimesoftware.com> wrote:
>
> For example, in the common idiom "for (i = 0; i < n;
> i++)" the simplest basic datatype for i is easily
> determined to be int.

> "Andr    P   nitz" <poenitz@gmx.net> wrote...
>
> By what rule? Because n is an int?

"David Spector" wrote:
> Andr   , No. Because 0 is most simply represented as int.

That's going to upset novices who write "p=NULL".

You could ask the compiler to juggle with all possibilities and
wait for subsequent source code to make it obvious which type
was intended, but this has two problems.

Firstly, the compiler's idea of obvious will not match yours,
at least for some examples and some values of "you".

Secondly, whilst the compiler was looking ahead but before it had
bumped into something that resolves the ambiguity, it might see
declarations that depend on the ambiguous type. In fact, it might
see an arbitrary number of them. Then, if the ambiguity is finally
resolved to the "wrong" type (by a typing error), that might provoke
a syntax error on one of the uses of one of the dependent types
which is perfectly correct and far removed from either of the
original declarations and from the actual mistake.


---
[ 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                       ]

ai@springtimesoftware.com ("David Spector") wrote in message news:<v4njdph6bfj7d1@corp.supernews.com>...
> Andr   , No. Because 0 is most simply represented as int.
>
> And, by the way, note that the clumsiness of
>
> *    int i;
> *    for (i = 0; i < n; i++)
>
> was already recognized when the syntax
>
> *    for (int i = 0; i < n; i++)
>
> was introduced. I am advocating a further simpification,
>
> *    for (i = 0; i < n; i++)
>
> for which, I believe, the compiler can correctly determine
> type in all cases. If 'i' is a class instance, for example,
> the compiler will know that statically.

1) Type inference
I'm afraid I joint a bit late to this thread, but have some doubts.
It is not clear for me:
* the type-inference rule
* the benefit

In the case of the    for    idiom, we only have the type of the
boundaries as information for the type-inference process:

  for( i=0; i<n; i++)
we can only have the boundaries of i   s life: from 0 [constant expr] to
typeof(n),
if typeof(n) is int, then we could deduce:
     unsigned int

But, seeing the [explicitation of] the type of i, is not a matter of
   specifying its type    only, but also provides the information: "it   s a
new variable", so the reader doesn   t need to go up and look for it.

I think this would seriously impact in readability.

2) about initialization to 0, I like the compiler to warn me when I
forgot to initialize the variable. With this proposal, the compiler
wouldn   t be able to differentiate whether you forgot to initialize it
or wanted to be 0.
(and, btw, this would be only available for integral types and
pointers).
In the case of pointers, there is still a tendence in many languages
and dialects to avoid the NULL value (for example, in Cyclone, a 'safe
dialect of C', they created a new qualifier meaning    can never be
null   , declared as    @
[example]
    int@ x;
x is a pointer to int, that can never be null. The example above in
fact is invalid).

Hope my feedback is useful.

 Daniel.

---
[ 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                       ]

Andr   , No. Because 0 is most simply represented as int.

And, by the way, note that the clumsiness of

*    int i;
*    for (i = 0; i < n; i++)

was already recognized when the syntax

*    for (int i = 0; i < n; i++)

was introduced. I am advocating a further simpification,

*    for (i = 0; i < n; i++)

for which, I believe, the compiler can correctly determine
type in all cases. If 'i' is a class instance, for example,
the compiler will know that statically.

Because of undecidability, there may be cases where the
compiler cannot determine the type of a variable. In such
cases it can simply report an error.

And yes, this introduces another wish list item: that
language compilation "officially" include the workflow in
which it is used, namely an iterative software development
process. We no longer have to be handcuffed by the 1960's
paradigm of submitting a program build, waiting perhaps an
hour or more for a printout to be delivered. The interactive
paradigm is now almost universal.

David
-----------
"Andr    P   nitz" <poenitz@gmx.net> wrote in message
news:b1rbil$mbb$2@narses.hrz.tu-chemnitz.de...
> David Spector <ai@springtimesoftware.com> wrote:
> > Here is a wish list for C++.
...
> > 004. (Controversial) Adding an option to remove the
requirement for
> > declaring local variables, when the datatypes can be
statically determined.
> > For example, in the common idiom "for (i = 0; i < n;
i++)" the simplest
> > basic datatype for i is easily determined to be int.
>
> By what rule? Because n is an int?
>
> Andre'


---
[ 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                       ]

wolof@freemail.hu ("White Wolf") wrote
> please note, that as soon as you do not require
> declaration the compiler will have:

I'm pretty sure that David Spector wasn't trying to eliminate
declarations. He wrote:

> > Few other languages require declaration/definition ordering.

I think he wants this program to be legal:
    int main() { std::cout << "Hello world!\n"; }
    #include <iostream>

In other words, things do have to be declared, but not neccesarily
before the first use. Presumably this could be done with a multi-
pass compiler; one that scans for declarations first (and perhaps
several times, to handle co-dependancy issues), and then processes
everything else.

Mr. Spector, please correct me if I'm wrong...

---
[ 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                       ]

White Wolf, I agree with much that you said. And others here
have made some of the same points.

It appears that my desire to make writing programs easier
has blinded me to the many issues that result from the
complex nature of a programming language like C++.

By the way, concerning your assumption that I come from a
"Java/Clipper/anyotherruntimesymboltablestufflanguage
root", permit me to state that I have used interpretive
languages such as Javascript (not Java) only for a short
time. All my programming from now going back 13 years has
been in C++. For the 24 years before that I wrote in
assembly language, PL/I subsets, Modula-2, Simula 67, and
wrote various parts of compilers for Fortran, PL/I subsets,
Ada, and others, and did some language design. I published
an original paper on the efficient generation of full LR(1)
parser tables and created a prototype for that in C++. It is
interesting that such deep experience as I have had in
software engineering has apparently not ensured that I will
make correct statements!

Thanks to all for your insights and responses to my wish
list.

David

-----------
(Original posting omitted to save bandwidth)


---
[ 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                       ]

Allan, You are correct in your understanding of what I would
like to see.

However, saying that it requires an extra compiler pass
makes the feature appear to have a significant cost.

Typically, a compiler parses a program, builds the symbol
table, and does limited semantic analysis during its first
pass, then does optimization (using techniques such as
dataflow analysis) and code generation in its second pass.

Any compiler already has a central symbol table, which
accumulates declarative and other information for each
program symbol (identifier, etc.). In fact, it takes extra
work to enforce order constraints in modern compilers. (When
I implemented parsing and semantic analysis for a Fortran
compiler, I had to add a field to the symbol structure to
indicate what had been done so far, purely for the purpose
of generating error messages when ordering constraints were
violated.)

Eliminating unnecessary order restrictions has only minimal
cost in compiler programmers' time and the size of the
compiler and its associated data. It has no impact on
runtime performance or program correctness.

David
----------------
"Allan W" <allan_w@my-dejanews.com> wrote in message
news:7f2735a5.0302131354.4f3a80ea@posting.google.com...
> wolof@freemail.hu ("White Wolf") wrote
> > please note, that as soon as you do not require
> > declaration the compiler will have:
>
> I'm pretty sure that David Spector wasn't trying to
eliminate
> declarations. He wrote:
>
> > > Few other languages require declaration/definition
ordering.
>
> I think he wants this program to be legal:
>     int main() { std::cout << "Hello world!\n"; }
>     #include <iostream>
>
> In other words, things do have to be declared, but not
neccesarily
> before the first use. Presumably this could be done with a
multi-
> pass compiler; one that scans for declarations first (and
perhaps
> several times, to handle co-dependancy issues), and then
processes
> everything else.
>
> Mr. Spector, please correct me if I'm wrong...
...


---
[ 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 <v4njdph6bfj7d1@corp.supernews.com>, David Spector=20
<ai@springtimesoftware.com> writes
>Andr=E9, No. Because 0 is most simply represented as int.
>
>And, by the way, note that the clumsiness of
>
>*    int i;
>*    for (i =3D 0; i < n; i++)
>
>was already recognized when the syntax
>
>*    for (int i =3D 0; i < n; i++)
>
>was introduced. I am advocating a further simpification,
>
>*    for (i =3D 0; i < n; i++)
>
>for which, I believe, the compiler can correctly determine
>type in all cases. If 'i' is a class instance, for example,
>the compiler will know that statically.

The proposal allows the inclusion of a header file to silently change=20
the meaning of code. It is not the job of the Standard to legislate of=20
good programming practice so consider a header which includes:

static int i(0);

Now the meaning of a piece of code which includes
   for(i=3D0; i<n; i++);

depends on whether that headers is or is not included. I know the code=20
is ridiculous but it demonstrates a serious flaw in the proposal, and=20
one that cannot be fixed (perhaps the programmer intends the i to be one=20
from an outer scope.)

--=20
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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 <v4qrg79o2vtjb2@corp.supernews.com>, David Spector
<ai@springtimesoftware.com> writes
>Allan, You are correct in your understanding of what I would
>like to see.
>
>However, saying that it requires an extra compiler pass
>makes the feature appear to have a significant cost.
>
>Typically, a compiler parses a program, builds the symbol
>table, and does limited semantic analysis during its first
>pass, then does optimization (using techniques such as
>dataflow analysis) and code generation in its second pass.
>
>Any compiler already has a central symbol table, which
>accumulates declarative and other information for each
>program symbol (identifier, etc.). In fact, it takes extra
>work to enforce order constraints in modern compilers. (When
>I implemented parsing and semantic analysis for a Fortran
>compiler, I had to add a field to the symbol structure to
>indicate what had been done so far, purely for the purpose
>of generating error messages when ordering constraints were
>violated.)
>
>Eliminating unnecessary order restrictions has only minimal
>cost in compiler programmers' time and the size of the
>compiler and its associated data. It has no impact on
>runtime performance or program correctness.


And how am I supposed to cope with places where I want those order
restrictions? This is just an unacceptable (for me) tarpit.

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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@ntlworld.com (Francis Glassborow) wrote
> David Spector <ai@springtimesoftware.com> writes
> >003. Removing the prohibition on declaring functions inside of functions.
> >While I would use this rarely, the ability to control visibility can be
> >useful in promoting program safety and API simplicity.
>
> Where is there any such prohibition. In fact some of us wish that such a
> prohibition existed so that we could remove the gotchas that result from
> the rule that if a declaration can be a function declaration it is a
> function declaration.

I'm almost certain that when David wrote "declaring," he meant defining.
As in, defining a function other than inline members of private classes.

    int foo() {
        int values[] = { 40, 10, 100, 90, 20, 25 };
        int compare(const void*a, const void*b)
            { return ( *(int*)a - *(int*)b; }
        qsort (values, sizeof(values)/sizeof(values[0]),
                       sizeof(int), compare);
    }

---
[ 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                       ]

""David Spector"" wrote:
> 001. A option (not a pragma, because they are just advisory) that can
be
> specified in a source file to make the compiler generate code to zero
the
> local/automatic/stack frame before any initialization is done in it.
This
> feature would eliminate a significant percentage of uninitialized
variable
> and similar bugs or make it much easier to find and fix them.

This sounds like a QoI issue and a compiler command line argument!  In
my architecture there is no stack in the way you seem to mean...

> 002. Removing the requirement that identifiers be lexically declared
before
> they may be used (or defined), preserving the functionality of
ordering in
> certain cases, such as initializations. This would remove the need for
> almost all forward references. The only reason ordering was ever
there,
> IMHO, was to make the first C compilers easy to write (by obviating
any
> fixup patching). Few other languages require declaration/definition
> ordering.

Because the do lookup of names runtime.  Therefore the above would
violate the zero overhead principle and highly overcomplicate the
compilation process as well as it would make simple linkers useless.  I
hardly see any way to avoid declaration of classes if their members are
called/accessed.  Also please note, that as soon as you do not require
declaration the compiler will have:

- no idea what the name is (type?, variable?, function?)
- Koenig lookup and any name resoultion will be impossible

Suppose you write (without telling what f is):

f( 42);

What is f?  A function?  A template function - if it is: how will you
instantiate it without knowing it?  Is it s class with operator ()
overloaded?  is it a typo, and it had to be x.f(); ?

> 003. Removing the prohibition on declaring functions inside of
functions.
> While I would use this rarely, the ability to control visibility can
be
> useful in promoting program safety and API simplicity.

That might be a good idea, although one should assess the costs and the
benefits.  And AFAIK this can esaily be done right now by declaring a
local class with an overriden operator().

> 004. (Controversial) Adding an option to remove the requirement for
> declaring local variables, when the datatypes can be statically
determined.

Deep water, only for good swimmers!  I believe that it is nearly
always impossible to deduce the type.  Especially if it can be an
undeclared global... since you have just removed the need to declare
them.

> For example, in the common idiom "for (i = 0; i < n; i++)" the
simplest
> basic datatype for i is easily determined to be int.

Or char.  Or long.  Or long long int (when it is added).  Or short.  Or
std::stype_t.  Or std:ptrdiff_t.  Or std::vector::size_type and I could
continue it for ever.

> But a compiler would be free to choose char, short, long, signed,
unsigned,
> and even double, etc., if analysis showed that program correctness
> was preserved.

That analysis could not be done if you no-need-to-declare rule is in
effect.  As well as: don't we have enough traps and pitfalls in
implementation defined and undefined behavior not required to create
diagnostics?

Not to mention - well,m to mention - that your example shows some more
pitfalls:

for (i = 0; i < n; i++)

Is i global?  If there is a global i, should the compiler declare a
local i?  If a local i is declared, should it be declared for the for
statement only?  Should it be declared in the scope where the for
statement is?  Should it be declared one above?  At function level?

if (something) {
for (i = 0; i < n; i++) if (x[i]==12) break;
...}
if (something else) {
  ...
  if (i !=n) ...
  ...
}

if (something else2) {
  ...
  if (i == 3) ...
  ...
}

Are those the same i?  What is yes?  What if not?  What if there is a
global/member i?  How will anyone reading the code find out if the
global/member i is used there or a local one or 2 local ones or 3 local
ones or a local one for the for and the member for the rest or...???

> If the programmer
> truly wanted a specific datatype, then they would declare the variable
as is
> done at present.

I see no benefit in the above, only a loads of costs for compiler
implementors and huge amount of possible pitfalls for programmers and a
huge amount of study to figure out what the type should be.  And it is
way more than only the type.

> The requirement "can be statically determined" must be
> spelled out in detail.

I suspect that a few brilliant minds could do a preliminary assesment
within 6 month per kopf and then a few more months until it would get
into shape (just talking about the type, the scoping issue IMHO is
unsolvable).  All this is to ensure that lazy programmers do not need to
type variable declarations - which take up about 2% of a program source
code.  I do not see enough benefits here to even seriously think about
this.  What we would end up with is a class A nightmare.  Not to mention
the sudden rise of suicides of college students taking C++ language
courses.  They already need to learn more rules and hows than humanly
possible.  Even if it would be possible in any ways to make that
deduction of type and scope (which I highly doubt, esp. if globals
aren't declared) every C++ programmer would need to learn all those
rules by heart to be able to understand what the code does.  Not to
mention - OK, to mention - that introduction of a global/member variable
with the same name would silently change the meaning of the code int the
function.  You definitely do not want to go there!

> I love writing in javascript, where a lack of concern for
> efficiency allows variables to be used without being declared.

Well, I had the feeling that you have something to do with Java...  No
offense meant, but such nonsense suggestions and complaints usually come
from people with Java/Clipper/anyotherruntimesymboltablestufflanguage
root.  What a Sherlock Holmes I am: "Because the do lookup of names
runtime." I wrote at the very beginning.  And so does Java and
JavaScript.  In C++ that is simply impossible.

> In C++, such inefficiency is intolerable, so implied
> datatypes must never require runtime
> implementation ("variants").

Please (despite of the offending words I may have told) try to read and
consider what I wrote.  What you are asking for is simply impossible -
and even if it would be it would make programs incomprehensible to their
programmers.

WW aka Attila


---
[ 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                       ]

""David Spector"" wrote:
> 001. A option (not a pragma, because they are just advisory) that can
be
> specified in a source file to make the compiler generate code to zero
the
> local/automatic/stack frame before any initialization is done in it.
This
> feature would eliminate a significant percentage of uninitialized
variable
> and similar bugs or make it much easier to find and fix them.

This sounds like a QoI issue and a compiler command line argument!  In
my architecture there is no stack...

> 002. Removing the requirement that identifiers be lexically declared
before
> they may be used (or defined), preserving the functionality of
ordering in
> certain cases, such as initializations. This would remove the need for
> almost all forward references. The only reason ordering was ever
there,
> IMHO, was to make the first C compilers easy to write (by obviating
any
> fixup patching). Few other languages require declaration/definition
> ordering.

Because the do lookup of names runtime.  Therefore the above would
violate the zero overhead principle and highly overcomplicate the
compilation process as well as it would make simple linkers useless.  I
hardly see any way to avoid declaration of classes if their members are
called/accessed.  Also please note, that as soon as you do not require
declaration the compiler will have:

- no idea what the name is (type?, variable?, function?)
- Koenig lookup and any name resoultion will be impossible

Suppose you write (without telling what f is):

f( 42);

What is f?  A function?  A template function - if it is: how will you
instantiate it without knowing it?  Is it s class with operator ()
overloaded?  is it a typo, and it had to be x.f(); ?

> 003. Removing the prohibition on declaring functions inside of
functions.
> While I would use this rarely, the ability to control visibility can
be
> useful in promoting program safety and API simplicity.

That might be a good idea, although one should assess the costs and the
benefits.  And AFAIK this can esaily be done right now by declaring a
local class with an overriden operator().

> 004. (Controversial) Adding an option to remove the requirement for
> declaring local variables, when the datatypes can be statically
determined.

Deep water, only for good swimmers!  I believe that it is nearly
_always_ impossible to deduce the type.  Especially if it can be an
undeclared global... since you have just removed the need to declare
them.

> For example, in the common idiom "for (i = 0; i < n; i++)" the
simplest
> basic datatype for i is easily determined to be int.

Or char.  Or long.  Or long long int (when it is added).  Or short.  Or
std::stype_t.  Or std:ptrdiff_t.  Or std::vector::size_type and I could
continue it for ever.

> But a compiler would be free to choose char, short, long, signed,
unsigned,
> and even double, etc., if analysis showed that program correctness
> was preserved.

That analysis could not be done if you no-need-to-declare rule is in
effect.  As well as: don't we have enough traps and pitfalls in
implementation defined and undefined behavior not required to create
diagnostics?

Not to mention - well,m to mention - that your example shows some more
pitfalls:

for (i = 0; i < n; i++)

Is i global?  If there is a global i, should the compiler declare a
local i?  If a local i is declared, should it be declared for the for
statement only?  Should it be declared in the scope where the for
statement is?  Should it be declared one above?  At function level?

if (something) {
for (i = 0; i < n; i++) if (x[i]==12) break;
...}
if (something else) {
  ...
  if (i !=n) ...
  ...
}

if (something else2) {
  ...
  if (i == 3) ...
  ...
}

Are those the same i?  What is yes?  What if not?  What if there is a
global/member i?  How will anyone reading the code find out if the
global/member i is used there or a local one or 2 local ones or 3 local
ones or a local one for the for and the member for the rest or...???

> If the programmer
> truly wanted a specific datatype, then they would declare the variable
as is
> done at present.

I see no benefit in the above, only a loads of costs for compiler
implementors and huge amount of possible pitfalls for programmers and a
huge amount of study to figure out what the type should be.  And it is
way more than only the type.

> The requirement "can be statically determined" must be
> spelled out in detail.

I suspect that a few brilliant minds could do a preliminary assesment
within 6 month per kopf and then a few more months until it would get
into shape (just talking about the type, the scoping issue IMHO is
unsolvable).  All this is to ensure that lazy programmers do not need to
type variable declarations - which take up about 2% of a program source
code.  I do not see enough benefits here to even seriously think about
this.  What we would end up with is a class A nightmare.  Not to mention
the sudden rise of suicides of college students taking C++ language
courses.  They already need to learn more rules and hows than humanly
possible.  Even if it would be possible in any ways to make that
deduction of type and scope (which I highly doubt, esp. if globals
aren't declared) *every* C++ programmer would need to learn *all* those
rules by heart to be able to understand what the code does.  Not to
mention - OK, to mention - that introduction of a global/member variable
with the same name would silently change the meaning of the code int the
function.  You definitely do not want to go there!

> I love writing in javascript, where a lack of concern for
> efficiency allows variables to be used without being declared.

Well, I had the feeling that you have something to do with Java...  No
offense meant, but such nonsense suggestions and complaints usually come
from people with Java/Clipper/anyotherruntimesymboltablestufflanguage
root.  What a Sherlock Holmes I am: "Because the do lookup of names
runtime." I wrote at the very beginning.  And so does Java and
JavaScript.  In C++ that is simply impossible.

> In C++, such inefficiency is intolerable, so implied
> datatypes must never require runtime
> implementation ("variants").

Please (despite of the offending words I may have told) try to read and
consider what I wrote.  What you are asking for is simply impossible -
and even if it would be it would make programs incomprehensible to their
programmers.

WW aka Attila


---
[ 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                       ]

""David Spector"" <ai@springtimesoftware.com> wrote...
>
> 003. Removing the prohibition on declaring functions inside of
functions.
> While I would use this rarely, the ability to control visibility can
be
> useful in promoting program safety and API simplicity.

You mean defining, not declaring, I suppose. To a fair degree, this
is already possible with local classes. Did you have something else
in mind?


---
[ 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                       ]

Here is a wish list for C++.

 Please feel free to add your own wished-for features. Try to invent
features that are practical and do not violate the design philosophy of C++
(such as it is). The features must not make existing programs break.

001. A option (not a pragma, because they are just advisory) that can be
specified in a source file to make the compiler generate code to zero the
local/automatic/stack frame before any initialization is done in it. This
feature would eliminate a significant percentage of uninitialized variable
and similar bugs or make it much easier to find and fix them.

002. Removing the requirement that identifiers be lexically declared before
they may be used (or defined), preserving the functionality of ordering in
certain cases, such as initializations. This would remove the need for
almost all forward references. The only reason ordering was ever there,
IMHO, was to make the first C compilers easy to write (by obviating any
fixup patching). Few other languages require declaration/definition
ordering.

003. Removing the prohibition on declaring functions inside of functions.
While I would use this rarely, the ability to control visibility can be
useful in promoting program safety and API simplicity.

004. (Controversial) Adding an option to remove the requirement for
declaring local variables, when the datatypes can be statically determined.
For example, in the common idiom "for (i = 0; i < n; i++)" the simplest
basic datatype for i is easily determined to be int. But a compiler would be
free to choose char, short, long, signed, unsigned, and even double, etc.,
if analysis showed that program correctness was preserved. If the programmer
truly wanted a specific datatype, then they would declare the variable as is
done at present. The requirement "can be statically determined" must be
spelled out in detail. Otherwise, it would be compiler- and target-
dependent, and therefore not appropriate as an addition to C++. The program
could compile successfully in one environment, but fail to compile in
another. I love writing in javascript, where a lack of concern for
efficiency allows variables to be used without being declared. In C++, such
inefficiency is intolerable, so implied datatypes must never require runtime
implementation ("variants").

--

David Spector
President, Springtime Software


---
[ 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                       ]

""David Spector"" <ai@springtimesoftware.com> wrote...
>
> 002. Removing the requirement that identifiers be lexically declared
before
> they may be used (or defined), preserving the functionality of
ordering in
> certain cases, such as initializations. This would remove the need for
> almost all forward references. The only reason ordering was ever
there,
> IMHO, was to make the first C compilers easy to write (by obviating
any
> fixup patching). Few other languages require declaration/definition
> ordering.

This was discussed a little while ago. The main problem is that adding
new declarations after the point of use makes it very hard to write code
that definitely calls one of the functions declared before the point of
use. Anyone writing code in header files is likely to fall foul of this.


---
[ 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                       ]

""David Spector"" <ai@springtimesoftware.com> wrote...
>
> 001. A option (not a pragma, because they are just advisory) that can
be
> specified in a source file to make the compiler generate code to zero
the
> local/automatic/stack frame before any initialization is done in it.
This
> feature would eliminate a significant percentage of uninitialized
variable
> and similar bugs or make it much easier to find and fix them.

Zero is not the correct initial value for some, if not most, variables.
The correct action is for the programmer to initialise the variable.
Compilers are already free to warn about ther problem you mention (not
least because it takes the program into undefined behaviour) and I'm
not aware of any that don't.


---
[ 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                       ]

""David Spector"" <ai@springtimesoftware.com> wrote...
>
> 004. (Controversial) Adding an option to remove the requirement for
> declaring local variables, when the datatypes can be statically
determined.
> For example, in the common idiom "for (i = 0; i < n; i++)" the
simplest
> basic datatype for i is easily determined to be int. But a compiler
would be
> free to choose char, short, long, signed, unsigned, and even double,
etc.,
> if analysis showed that program correctness was preserved.

Or indeed any user defined type currently in scope which has a
constructor taking an integral or pointer value, and member or
applicable global operators for ++ and <. That would mean that
changes in obscure headers of which the original programmer knows
little of nothing could change the meaning of code.

> I love writing in javascript, where a lack of concern for
> efficiency allows variables to be used without being declared.
> In C++, such inefficiency is intolerable, so implied datatypes
> must never require runtime implementation ("variants").

What's the largest system anyone has ever created with Javascript?
I suspect it is measured in thousands of lines compared to millions
in the case of C++. I think *this* rather than the concern for
efficiency, is the reason why C++ takes such a strict line on declaring
things both explicitly and in advance.


---
[ 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                       ]

David Spector <ai@springtimesoftware.com> wrote:
> Here is a wish list for C++.
>
> 001. A option (not a pragma, because they are just advisory) that can be
> specified in a source file to make the compiler generate code to zero the
> local/automatic/stack frame before any initialization is done in it. This
> feature would eliminate a significant percentage of uninitialized variable
> and similar bugs or make it much easier to find and fix them.

I don't find such an extension very desirable. If you define variables "as
late as possible" you usually know a practical initial value. Moreover,
"zeroing" is not necessarily a valid initialization of objects, and at
least the compiler I use warns when I try to use the value an
uninitialized variable.

> 004. (Controversial) Adding an option to remove the requirement for
> declaring local variables, when the datatypes can be statically determined.
> For example, in the common idiom "for (i = 0; i < n; i++)" the simplest
> basic datatype for i is easily determined to be int.

By what rule? Because n is an int?

Andre'

--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)

---
[ 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 <v40iucecdmpo2c@corp.supernews.com>, David Spector
<ai@springtimesoftware.com> writes
>Here is a wish list for C++.
>
> Please feel free to add your own wished-for features. Try to invent
>features that are practical and do not violate the design philosophy of C++
>(such as it is). The features must not make existing programs break.
>
>001. A option (not a pragma, because they are just advisory) that can be
>specified in a source file to make the compiler generate code to zero the
>local/automatic/stack frame before any initialization is done in it. This
>feature would eliminate a significant percentage of uninitialized variable
>and similar bugs or make it much easier to find and fix them.

I fail to see how this would make it easier to find a bug, what it would
do is hide bugs which would immediately resurface anytime the code was
compiled without that option (e.g. when profiling shows that its use is
causing a critical slowdown.

>
>002. Removing the requirement that identifiers be lexically declared before
>they may be used (or defined), preserving the functionality of ordering in
>certain cases, such as initializations. This would remove the need for
>almost all forward references. The only reason ordering was ever there,
>IMHO, was to make the first C compilers easy to write (by obviating any
>fixup patching). Few other languages require declaration/definition
>ordering.

My understanding was that software engineering frowns on implicit
declarations. I would strongly resist attempts to make C++ less
demanding in this aspect, particularly as a language that uses
overloaded names would be very fragile in such a context.

>
>003. Removing the prohibition on declaring functions inside of functions.
>While I would use this rarely, the ability to control visibility can be
>useful in promoting program safety and API simplicity.

Where is there any such prohibition. In fact some of us wish that such a
prohibition existed so that we could remove the gotchas that result from
the rule that if a declaration can be a function declaration it is a
function declaration.

>
>004. (Controversial) Adding an option to remove the requirement for
>declaring local variables, when the datatypes can be statically determined.
>For example, in the common idiom "for (i = 0; i < n; i++)" the simplest
>basic datatype for i is easily determined to be int. But a compiler would be
>free to choose char, short, long, signed, unsigned, and even double, etc.,
>if analysis showed that program correctness was preserved. If the programmer
>truly wanted a specific datatype, then they would declare the variable as is
>done at present. The requirement "can be statically determined" must be
>spelled out in detail. Otherwise, it would be compiler- and target-
>dependent, and therefore not appropriate as an addition to C++.

Please demonstrate a case where such a type can be statically
determined. Why should the data type in your example not be an unsigned
int, a short int (supposing that n has that type) etc.

In addition, what happens when i matches a declaration in an outer
scope?

IMO we want the compiler to do less guessing not more.

> The program
>could compile successfully in one environment, but fail to compile in
>another. I love writing in javascript, where a lack of concern for
>efficiency allows variables to be used without being declared. In C++, such
>inefficiency is intolerable, so implied datatypes must never require runtime
>implementation ("variants").

--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

> What's the largest system anyone has ever created with Javascript?
> I suspect it is measured in thousands of lines compared to millions
> in the case of C++. I think *this* rather than the concern for
> efficiency, is the reason why C++ takes such a strict line on declaring
> things both explicitly and in advance.

  I completely agree. After years of dealing with obscure Fortran errors
caused by the compiler incorrectly assuming the type of a variable (or
introducing a new variable because of a typo), I think that strict
declaration enforcement is one of the best features of C++ (or C or Pascal
or Java for that matter... ;-) )

J.

---
[ 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                       ]

ai@springtimesoftware.com ("David Spector") wrote in message
news:<v40iucecdmpo2c@corp.supernews.com>...

> Here is a wish list for C++.

> 001. A option (not a pragma, because they are just advisory) that can
> be specified in a source file to make the compiler generate code to
> zero the local/automatic/stack frame before any initialization is done
> in it. This feature would eliminate a significant percentage of
> uninitialized variable and similar bugs or make it much easier to find
> and fix them.

I don't think I've ever had a bug due to an uninitialized local
variable in C++.  If we were to do something like this, I'd prefer the
Java solution (which makes it an error, requiring a diagnostic, if a
variable is used in a context in which the compiler cannot prove that it
has been initialized).  But I suspect that there are a few cases where
this would introduce unacceptable runtime overhead.

> 002. Removing the requirement that identifiers be lexically declared
> before they may be used (or defined), preserving the functionality of
> ordering in certain cases, such as initializations. This would remove
> the need for almost all forward references.

Could you give some examples where this would be useful?  The only cases
I can think of involve types, and the compiler must know whether a
symbol is a type or not in order to parse the language.

> The only reason ordering was ever there, IMHO, was to make the first C
> compilers easy to write (by obviating any fixup patching). Few other
> languages require declaration/definition ordering.

Really?  Of the languages I know with static type checking, Java is the
only one which doesn't require it, and that is only because Java doesn't
allow separation of the implementation and the interface specification.

> 003. Removing the prohibition on declaring functions inside of
> functions.  While I would use this rarely, the ability to control
> visibility can be useful in promoting program safety and API
> simplicity.

This has often been discussed.  In C++, I think local classes are more
in keeping with the language philosophy.  And local classes already
exist.

> 004. (Controversial) Adding an option to remove the requirement for
> declaring local variables, when the datatypes can be statically
> determined.  For example, in the common idiom "for (i = 0; i < n;
> i++)" the simplest basic datatype for i is easily determined to be
> int.

Unless, of course, n is a long.

> But a compiler would be free to choose char, short, long, signed,
> unsigned, and even double, etc., if analysis showed that program
> correctness was preserved.

That should make for some fun instances of function overload resolution
and/or template instantiation when the variable is used.

> If the programmer truly wanted a specific datatype, then they would
> declare the variable as is done at present. The requirement "can be
> statically determined" must be spelled out in detail. Otherwise, it
> would be compiler- and target- dependent, and therefore not
> appropriate as an addition to C++. The program could compile
> successfully in one environment, but fail to compile in another. I
> love writing in javascript, where a lack of concern for efficiency
> allows variables to be used without being declared.

I use AWK (and most recently, Perl) for that.  It's fine for programs up
to a certain size.  And in fact, I never use C++ for programs less than
about 10 lines -- to much work to fire up the compiler, etc., when I can
just type it in and execute directly with Perl or AWK.  Different tools
for different problems.  I don't see any reason why C++ should compete
with AWK at that level.  (There is a lot of overlap, and my first
classes in C++ -- String, AssocArray, RegExpr, and FieldArray -- were
all designed to give it some of the functionality of AWK.  For times
when the data set)

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ 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                       ]