Greg Brewer wrote:
> Does anyone else get the feeling that C/C++ is moving in the direction
> of Ada: too complicated because of design by committee.

Not for C, but I feel that C++ has already become far to complex for
mere mortals to understand.  I have called it the "PL/1 of the 90s"
in the past (which Bjarne did not appreciate), but my complaint is
based on the same complaints that people had about PL/1 in the 60s
and 70s - that the language and the library were too big to comprehend
by normal programmers.  At least PL/1 had official subsets.

Don't get me wrong, I like C++.  I just think it's awfully complex;
C++ most certainly is not a beginner's language.

> I originally liked C because it was very basic.

And it still is.  The ISO C committee added very little to change the
simplicity of the language, and have always avoided adding anything
that would unduly complicate the symmetry of the language or make
implementing it too difficult.  C is much simpler than C++, and far
easier to implement.  And this will always be so.

> I wonder why they took the approach with sizeof that they did?

Because it was not a drastic change to the semantics of the language,
and did not conflict with its stack-based execution model.  Also
because there already existed compilers that supported it.  (Don't
forget that most of the work of the committees is to codify existing
practice.)

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Greg Brewer wrote:
> I ran into this today.
>
>    int Something(char text[100]);
>    void Nothing(void) {
>       char text[80];
>       Something(text); // no warning, error or anything.
>    }
>
> I want the compiler to tell me if the array I'm passing isn't big
> enough.

C99 has this:

    int foo(char a[static 100]);

The 'static' tells the compiler that it can safely assume that
there are at least 100 (contiguous) elements in 'a'.

Presumably, (though not required by C99 semantics), if the prototype
is in scope, the compiler could also warn you if you attempt to pass
foo() an array that is too small.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <39DB522C.4103E3E3@tribble.com>, David R Tribble
<david@tribble.com> writes
>and the library were too big to comprehend
>by normal programmers.

Wow, what's your opinion of Java then?  No do not bother to answer.
There maybe problems with some elements of the C++ Standard Library but
I do not think that, in general, its size should be an issue. A couple
of classes have overly large interfaces but otherwise what would you
want to leave out?


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

One thing I (a hobbyist) would note is that you do not have to use or even
understand all the complexity of C++ to use it.  It can just be C, a
"better C", or a complex OOP language with polymorphism and inheritance
depending on your needs at the moment and what you want it to be for the
particular project at hand.

On Wed,  4 Oct 2000 17:09:42 GMT, David R Tribble <david@tribble.com> wrote:
>Greg Brewer wrote:
>> Does anyone else get the feeling that C/C++ is moving in the direction
>> of Ada: too complicated because of design by committee.
>
>Not for C, but I feel that C++ has already become far to complex for
>mere mortals to understand.  I have called it the "PL/1 of the 90s"
>in the past (which Bjarne did not appreciate), but my complaint is
>based on the same complaints that people had about PL/1 in the 60s
>and 70s - that the language and the library were too big to comprehend
>by normal programmers.  At least PL/1 had official subsets.
>
> ....


--
R o b e r t  P r i c e
======================
bobprice@enteract.com
http://www.enteract.com/~bobprice/

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

pdimov@techno-link.com wrote:
> Suppose that variable-length arrays of T have a distinct type, let's
> call it T[...].
>
> This would allow us to write a function that takes an array of any
> size as a parameter:
>
>   void f(T (&t) [...]);

C99 syntax has:

    void h(T a[*]);
    void g(T (*a)[*]);

The '[*]' means that the array parameter is a VLA, which is equivalent
to your '[...]' notation.

By extension, C++ could have:

    void f(T (&a)[*]);

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Greg Brewer wrote:
>> Does anyone else get the feeling that C/C++ is moving in the
>> direction of Ada: too complicated because of design by committee.

David R Tribble <david@tribble.com> wrote:
>> Not for C, but I feel that C++ has already become far to complex for
>> mere mortals to understand.  I have called it the "PL/1 of the 90s"
>> in the past (which Bjarne did not appreciate), but my complaint is
>> based on the same complaints that people had about PL/1 in the 60s
>> and 70s - that the language and the library were too big to
>> comprehend by normal programmers.  At least PL/1 had official
>> subsets.

Robert Price wrote:
> One thing I (a hobbyist) would note is that you do not have to use or
> even understand all the complexity of C++ to use it.  It can just be
> C, a "better C", or a complex OOP language with polymorphism and
> inheritance depending on your needs at the moment and what you want it
> to be for the particular project at hand.

That's fine if you are a C++ hobbyist.  I tend to avoid the more
complicated corners of the language for my hobbyist endeavors, too.

But consider how much a maintenance programmer (typically a junior
programmer) has to know in order to maintain the typical senior
programmer's code.  Old C++ was fairly small, but once they added
full templates, exceptions, and the STL it became an awfully large
beast.

That's not to say that C++ isn't useful, because it is, and can be
used to solve incredibly complex programming projects.  But no one
can deny that it takes a big investment of time and energy to learn.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

David R Tribble wrote:
>
> Greg Brewer wrote:
> > I ran into this today.
> >
> >    int Something(char text[100]);
> >    void Nothing(void) {
> >       char text[80];
> >       Something(text); // no warning, error or anything.
> >    }
> >
> > I want the compiler to tell me if the array I'm passing isn't big
> > enough.
>
> C99 has this:
>
>     int foo(char a[static 100]);
>
> The 'static' tells the compiler that it can safely assume that
> there are at least 100 (contiguous) elements in 'a'.

Wow, they really found a new use for static? ;-)

BTW, in what way does this help the compiler? After all, since
accessing past the end is undefined behaviour anyway, and since
the compiler doesn't have any need to access elemets not
explicitly accessed from within the program, the compiler
should be free to assume this anyway. And it also can warn
in the following situations:

int foo(char a[100])
{
  a[100] = 5; // not really illegal, but compiler may warn
}

int main()
{
  int b[50];
  foo(b); // not really illegal, but the compiler may warn
}

Therefore, what exactly does [static 100] provide which [100]
does not?
(I would see an advantage if the compiler were allowed top
assume that a has _at most_ 100 elements - i.e. accesses
beyond element 100 would be undefined behaviour; the statement
inside foo would be illegal).

>
> Presumably, (though not required by C99 semantics), if the prototype
> is in scope, the compiler could also warn you if you attempt to pass
> foo() an array that is too small.

It can do so, even if static is not given. It only needs
the number.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

David R Tribble <david@tribble.com> writes
>> C++ [...] and the library were too big to comprehend
>> by normal programmers.

Francis Glassborow wrote:
> Wow, what's your opinion of Java then?  No, do not bother to answer.
> There maybe problems with some elements of the C++ Standard Library
> but I do not think that, in general, its size should be an issue. A
> couple of classes have overly large interfaces but otherwise what
> would you want to leave out?

My point was more that the C++ *language* was too complicated
(especially with all the permutations of template semantics).

Java is a simpler language than C++.  C++ is most definitely not a
beginner's language.  Neither is Java, but the learning curve for it
isn't near as steep.

(BTW, a lot of what can be done with templates can be done with a root
'Object' class that is inherited by all UDTs.  C++ has the former,
Java the latter.)

It is true that both the C++ and Java libraries are quite large. But I
would rather have a larger library than a larger language.

FWIW, C, C++, and Java are my favorite languages.  Each has its
strengths and weaknesses.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

David R Tribble wrote:
> > One thing I (a hobbyist) would note is that you do not have to use or
> > even understand all the complexity of C++ to use it.  It can just be
> > C, a "better C", or a complex OOP language with polymorphism and
> > inheritance depending on your needs at the moment and what you want it
> > to be for the particular project at hand.
>
> That's fine if you are a C++ hobbyist.  I tend to avoid the more
> complicated corners of the language for my hobbyist endeavors, too.
>
> But consider how much a maintenance programmer (typically a junior
> programmer) has to know in order to maintain the typical senior
> programmer's code.  Old C++ was fairly small, but once they added
> full templates, exceptions, and the STL it became an awfully large
> beast.
>
> That's not to say that C++ isn't useful, because it is, and can be
> used to solve incredibly complex programming projects.  But no one
> can deny that it takes a big investment of time and energy to learn.

Before exceptions, templates and STL, C++ was fragmented into a large
number of dialects where each isolated group developed their own
solution to error handling and generic programming.  When you moved to a
new job, you had to forget all the stuff you learned and figure out how
the new group reimplemented the same capabilities.  With standard C++,
there is a much larger body of knowledge that you can readily move from
one project to the next.

Serious programming jobs require a large investment in learning the
development environment.  Better that investment be in knowledge that is
portable.

--
Jon Biggar
Floorboard Software
jon@floorboard.com
jon@biggar.org

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> You seem to have missed the where I said
> > the same as the argument vla[] as in "int foo(int vla[]) {return
> sizeof(vla);}"
> In either case, you have a variable length array.

That's not a variable-length array.  It's a pointer, and it happens to
point to an array of unknown length (which is not the same as variable
length).  "sizeof vla" applies the sizeof operator to the pointer, so
this is not usefully compared to applying sizeof to a VLA.  To apply
sizeof to the array, you'd need "sizeof *(int (*)[something])vla", and
at that point, either you're dealing with an array of known size, or
you're back to the original case.


paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul Jarc" <prj@po.cwru.edu> wrote in message
news:m31yxz7xib.fsf@multivac.student.cwru.edu...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > You seem to have missed the where I said
> > > the same as the argument vla[] as in "int foo(int vla[]) {return
> > sizeof(vla);}"
> > In either case, you have a variable length array.
>
> That's not a variable-length array.  It's a pointer, and it happens to
> point to an array of unknown length (which is not the same as variable
> length).  "sizeof vla" applies the sizeof operator to the pointer, so
> this is not usefully compared to applying sizeof to a VLA.  To apply
> sizeof to the array, you'd need "sizeof *(int (*)[something])vla", and
> at that point, either you're dealing with an array of known size, or
> you're back to the original case.

True; but, it looks nearly the same.  I wasn't that sure about it.  I ran
into this today.
   int Something(char text[100]);
   void Nothing(void) {
      char text[80];
      Something(text); // no warning, error or anything.
  }

I want the compiler to tell me if the array I'm passing isn't big enough.

Greg


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> "James Kuyper" <kuyper@wizard.net> wrote in message
> news:39D5221C.43D175F5@wizard.net...
> > Greg Brewer wrote:
> > >
> > > You seem to have missed the where I said
> > > > the same as the argument vla[] as in "int foo(int vla[]) {return
> > > sizeof(vla);}"
> > > In either case, you have a variable length array.  The only difference
> is
> > > that as an argument, you do not know how large the array actually is.
> >
> > Perhaps that would be an alternative way to do it, but that's not the
> > way it works in C99. A VLA's size must be specified at the point where
>
> How it works in C99 wasn't the point; I was responding to the comment
> >  to make it mean something inconsistent with other uses.
> to argue that my comments were indeed consistent with another usage.  In
> both cases, it is not possible to know at compile time the actual size.  I
> personally find this to be more consistant with existing usage.

My point is that the context you consider analogous isn't a VLA as far
as C99 is concerned. Here are some contexts that do involve VLAs and
pointers to variably-modified types:

#include<assert.h>
void func(int n, double arrayin[][n], double arrayout[][4])
{
 double vecin[n];
 double vecout[4];

 assert(n==4);

 // these are both sizeof((double*)[4])
 assert(sizeof(arrayin)==sizeof(arrayout));

 // These are all 4*sizeof(double)
 assert(sizeof(arrayin[0])==sizeof(arrayout[0]));
 assert(sizeof(vecin)==sizeof(vecout));
}

In C99, if you call func() with a first argument of 4, every single one
of those asserts will succeed. To my mind, that's what consistency would
call for. With the alternative that's been suggested for C++ on this
thread, any one of them after the first would fail if it had an
opportunity to do so.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
>    int Something(char text[100]);
>    void Nothing(void) {
>       char text[80];
>       Something(text); // no warning, error or anything.
>   }
>
> I want the compiler to tell me if the array I'm passing isn't big enough.

Then you should declare the parameter as a pointer to an array instead
of a pointer to a char:
    int Something(char (*text)[100]);
    void Nothing(void) {
        char text[80];
        Something(&text); // incompatible type
    }
Beware that this will also complain if the array is too large.  You'll
have to cast the pointer in that case.


paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

|> "Paul Jarc" <prj@po.cwru.edu> wrote in message
|> news:m31yxz7xib.fsf@multivac.student.cwru.edu...
|> > "Greg Brewer" <nospam.greg@brewer.net> writes:
|> > > You seem to have missed the where I said
|> > > > the same as the argument vla[] as in "int foo(int vla[]) {return
|> > > sizeof(vla);}"
|> > > In either case, you have a variable length array.
|> >
|> > That's not a variable-length array.  It's a pointer, and it happens =
to
|> > point to an array of unknown length (which is not the same as variab=
le
|> > length).  "sizeof vla" applies the sizeof operator to the pointer, s=
o
|> > this is not usefully compared to applying sizeof to a VLA.  To apply
|> > sizeof to the array, you'd need "sizeof *(int (*)[something])vla", a=
nd
|> > at that point, either you're dealing with an array of known size, or
|> > you're back to the original case.
|>=20
|> True; but, it looks nearly the same.  I wasn't that sure about it.  I =
ran
|> into this today.
|>    int Something(char text[100]);
|>    void Nothing(void) {
|>       char text[80];
|>       Something(text); // no warning, error or anything.
|>   }
|>=20
|> I want the compiler to tell me if the array I'm passing isn't big enou=
gh.

You aren't passing an array.  Arrays are no first class objects, but deca=
y
to pointers.  Embed the array in a structure to get what you want.

Andreas.

--=20
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanz=E4ckerstr. 10, D-90443 N=FCrnberg

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8rb0uc$1rqs$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>   int Something(char text[100]);
>   void Nothing(void) {
>      char text[80];
>      Something(text); // no warning, error or anything.
>  }
>
>I want the compiler to tell me if the array I'm passing isn't big enough.

At present the number has no meaning; the code might only use the first
20 bytes. The C99 use of "static" there (see this group (comp.std.c)
passim) would give the compiler the information it needs to do what you
want.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet       | Home: <clive@davros.org>
Fax: +44 20 8371 1037 | Thus plc             | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul Jarc" <prj@po.cwru.edu> wrote in message
news:m3itr96hkn.fsf@multivac.student.cwru.edu...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> >    int Something(char text[100]);
> >    void Nothing(void) {
> >       char text[80];
> >       Something(text); // no warning, error or anything.
> >   }
> >
> > I want the compiler to tell me if the array I'm passing isn't big
enough.
>
> Then you should declare the parameter as a pointer to an array instead
> of a pointer to a char:
>     int Something(char (*text)[100]);
>     void Nothing(void) {
>         char text[80];
>         Something(&text); // incompatible type
>     }
> Beware that this will also complain if the array is too large.  You'll
> have to cast the pointer in that case.

Thanks, that's useful.  I don't really care whether on not it complains if
its too large.  I would prefer it to complain; however, if it did not then
no harm done and not danger.  It's when then allocated space is smaller than
I think it is that the stack gets corrupted.

Greg

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Peter Dimov" <pdimov@mmltd.net> writes:
>> A related question, what is 'T' in the code below:
>>
>> template<class T> void f(T & t)
>> {
>> }
>>
>> f(vla);
>>
>> And should typeid(T) compare equal to typeid(a)?

Martin von Loewis wrote:
> [Corrected:]
>
> template<class T> void f(T & t)
> {
> }
>
> void bar(int n)
> {
>   int vla[n];
>   f(vla);
> }
>
> I would say that this is still ill-formed; following 3.5/8, the type
> of vla should have no linkage. In turn, you cannot use it as a
> template parameter.

But it might be reasonable to borrow the C99 syntax:

    template <class T>
    void foo(int n, T a[n])
    { ... }

    template <class T>
    void foo2(T a[*])
    { ... }

It would be simpler to just forget about trying to make runtime
template type evaluation a requirement for VLAs.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In comp.std.c++, the issue was raised of whether and how C++ could
accommodate C99 VLAs.

James Kuyper wrote:
>
> Greg Brewer wrote:
...
> > If compiletime evaluation of sizeof is desirable (I think it is) then just
> > return the sizeof a single item.  If the user wants the size of the whole
> > array then use "sz = sizeof(vla)*n;" instead.  I am not familar with typeid
> > so I have no clue.  In general, vla[n] should be treated by compiletime
> > operators as vla[1] or the same as the argument vla[] as in "int foo(int
> > vla[]) {return sizeof(vla);}"
>
> You'll be creating incompatibilities with C99 with that approach.

Greg Brewer wrote:
...
> ... I wonder why they took the approach with sizeof
> that they did?

There are people on comp.std.c who can answer that question better than
I can. Anyone care to chip in?

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
> If compiletime evaluation of sizeof is desirable (I think it is) then just
> return the sizeof a single item.  If the user wants the size of the whole
> array then use "sz = sizeof(vla)*n;" instead.

That'd be pretty ugly, I think.  If you don't like run-time sizeof,
then better to prohibit use of sizeof on an object whose size is not
known at compile time than to make it mean something inconsistent with
other uses.  But then, once it's decided that sizeof(vla) doesn't mean
something different from the size of the array, you might as well let
it mean just that, as a convenient shorthand for sizeof(vla[0])*n.
The only implementation burden this introduces, I think, is that n
must be remembered somewhere at run time.  But that can be optimized
away if sizeof(vla) is never used, so you only pay for what you use.

> ... I wonder why they took the approach with sizeof that they did?

I don't know.  Perhaps they agreed with what I said above.


paul

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Peter Dimov" <pdimov@mmltd.net> writes:

> "Fergus Henderson" <fjh@cs.mu.OZ.AU> wrote in message
> news:8quae1$qv6$1@mulga.cs.mu.OZ.AU...
> > David R Tribble <david@tribble.com> writes:
> >
> > >The complete type of the VLA object can only be determined at
> runtime,
> > >which causes some problems, such as evaluating sizeof(), typeid(),
> > >and the & operator.
> > >
> > >    int  n = ...;
> > >    int  vla[n];
> > >
> > >    size_t  sz = sizeof(vla);    // evaluated at runtime
> >
> > Yes, for compatibility with C99.
> >
> > >    const char *  t = typeid(vla).name();
> > >                                 // runtime eval?
> >
> > Yes, for consistency with sizeof().
>
> Do you mean that typeid(vla) would compare equal to typeid(a), where a
> is a statically allocated array with the same size?
>
> A related question, what is 'T' in the code below:
>
> template<class T> void f(T & t)
> {
> }
>
> f(vla);
>
> And should typeid(T) compare equal to typeid(a)?

Why not? Doing so requires nothing more complicated than run-time
  template instantiation, a source of overhead the C++ community has
  wanted for years! :-)

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

You seem to have missed the where I said
> the same as the argument vla[] as in "int foo(int vla[]) {return
sizeof(vla);}"
In either case, you have a variable length array.  The only difference is
that as an argument, you do not know how large the array actually is.

Greg Brewer



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> You seem to have missed the where I said
> > the same as the argument vla[] as in "int foo(int vla[]) {return
> sizeof(vla);}"
> In either case, you have a variable length array.  The only difference is
> that as an argument, you do not know how large the array actually is.

Perhaps that would be an alternative way to do it, but that's not the
way it works in C99. A VLA's size must be specified at the point where
it's defined. In the function declaration you can use '*' as the size of
a VM (variably modified) parameter, but in the function definition the
VLA's size must be specified. For example:

myVLA.h:
void f(int, int, double[][*]);
//also legal:
//void f(int n, int m, double[n][m]);

myVLA.c:
#include "myVLA.h"

double g(int n, double vector[])
{
 // some operation on vector,
}

void f(int n, int m, double array[n][m])
{
 double colvec[n];
 double rowvec[m];
 // Perform some operation on arr, using colvec and rowvec
 // to store intermediate results.
 g(n,colvec);
 // more details.
}


main.c:
#include "myVLA.h"

int main(void)
{
 double in[2][3]={{1.0,2.9,3.8},{4.7,5.6,6.5}};
 f(2,3,in);
 // other operations.
 return 0;
}

Note: 'colvec', and 'rowvec' are VLA's; 'array' is a pointer to a VM
type; 'in' is an ordinary array, and 'vector' is an ordinary pointer.
Also, you should understand that sizeof(array)==sizeof((double*)[m]),
sizeof(array[0])==m*sizeof(double), while
sizeof(colvec)==n*sizeof(double).

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Peter Dimov" <pdimov@mmltd.net> writes:

> A related question, what is 'T' in the code below:
>
> template<class T> void f(T & t)
> {
> }
>
> f(vla);
>
> And should typeid(T) compare equal to typeid(a)?

As it stands, this code is ill-formed (vla is not defined, top-level
expressions are not allowed). Correcting this, it could read

template<class T> void f(T & t)
{
}

void bar(int n)
{
  int vla[n];
  f(vla);
}

I would say that this is still ill-formed; following 3.5/8, the type
of vla should have no linkage. In turn, you cannot use it as a
template parameter.

Regards,
Martin

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>Here are a few other problems I thought of.
>
>The complete type of the VLA object can only be determined at runtime,
>which causes some problems, such as evaluating sizeof(), typeid(),
>and the & operator.
>
>     int  n = ...;
>     int  vla[n];
>
>     size_t  sz = sizeof(vla);    // evaluated at runtime
>
>     const char *  t = typeid(vla).name();
>                                  // runtime eval?
>
>     int  m = n;
>     int  (*p)[m] = &vla;         // runtime type check?

Also overload resolution:

void g(int (&)[3]);
void g(int (&)[4]);

void f(int n) {
     int a[n];
     g(a);       // resolved at runtime?
}

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Peter Dimov" <pdimov@mmltd.net> writes:

>"Fergus Henderson" <fjh@cs.mu.OZ.AU> wrote in message
>> David R Tribble <david@tribble.com> writes:
>>
>> >The complete type of the VLA object can only be determined at runtime,
>> >which causes some problems, such as evaluating sizeof(), typeid(),
>> >and the & operator.
>> >
>> >    int  n = ...;
>> >    int  vla[n];
>> >
>> >    size_t  sz = sizeof(vla);    // evaluated at runtime
>>
>> Yes, for compatibility with C99.
>>
>> >    const char *  t = typeid(vla).name();
>> >                                 // runtime eval?
>>
>> Yes, for consistency with sizeof().
>
>Do you mean that typeid(vla) would compare equal to typeid(a), where a
>is a statically allocated array with the same size?

Yes, that sounds good.

>A related question, what is 'T' in the code below:
>
>template<class T> void f(T & t)
>{
>}
>
>f(vla);

Hmm, these questions are getting trickier ;-)

I think that example should perhaps be ill-formed?
Likewise

 template <int I> void f(T[I] &t) { }

 int n = ...;
        int vla[n];
 f(vla);

and
 template <int I> void f(T[I] &t) { }

 int n = ...;
        int vla[n];
 f<n>(vla);

would also be ill-formed, just like

 template <int I> void f() { }

 int n = ...;
 f<n>();

currently is.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"James Kuyper" <kuyper@wizard.net> wrote in message
news:39D5221C.43D175F5@wizard.net...
> Greg Brewer wrote:
> >
> > You seem to have missed the where I said
> > > the same as the argument vla[] as in "int foo(int vla[]) {return
> > sizeof(vla);}"
> > In either case, you have a variable length array.  The only difference
is
> > that as an argument, you do not know how large the array actually is.
>
> Perhaps that would be an alternative way to do it, but that's not the
> way it works in C99. A VLA's size must be specified at the point where

How it works in C99 wasn't the point; I was responding to the comment
>  to make it mean something inconsistent with other uses.
to argue that my comments were indeed consistent with another usage.  In
both cases, it is not possible to know at compile time the actual size.  I
personally find this to be more consistant with existing usage.

Greg


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8r9u7j$s05$1@mulga.cs.mu.OZ.AU>,
  fjh@cs.mu.OZ.AU (Fergus Henderson) wrote:
> "Peter Dimov" <pdimov@mmltd.net> writes:

[...]

> >Do you mean that typeid(vla) would compare equal to typeid(a), where
a
> >is a statically allocated array with the same size?
>
> Yes, that sounds good.
>
> >A related question, what is 'T' in the code below:
> >
> >template<class T> void f(T & t)
> >{
> >}
> >
> >f(vla);
>
> Hmm, these questions are getting trickier ;-)
>
> I think that example should perhaps be ill-formed?

A definite possibility, although I had something different in mind.

Suppose that variable-length arrays of T have a distinct type, let's
call it T[...].

This would allow us to write a function that takes an array of any size
as a parameter:

void f(T (&t) [...]);

assuming that the reference can bind to statically-allocated arrays as
well.

In this case in the example above 'T' would be deduced as int[...];
this also implies that typeid(T) is compile-time evaluated and does not
compare equal to typeid(int[sizeof(vla)]).

--
Peter Dimov
Multi Media Ltd.


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> I don't see these as being much of a problem.
>
> If compiletime evaluation of sizeof is desirable (I think it is) then just
> return the sizeof a single item.  If the user wants the size of the whole
> array then use "sz = sizeof(vla)*n;" instead.  I am not familar with typeid
> so I have no clue.  In general, vla[n] should be treated by compiletime
> operators as vla[1] or the same as the argument vla[] as in "int foo(int
> vla[]) {return sizeof(vla);}"

You'll be creating incompatibilities with C99 with that approach.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:

>The complete type of the VLA object can only be determined at runtime,
>which causes some problems, such as evaluating sizeof(), typeid(),
>and the & operator.
>
>    int  n = ...;
>    int  vla[n];
>
>    size_t  sz = sizeof(vla);    // evaluated at runtime

Yes, for compatibility with C99.

>    const char *  t = typeid(vla).name();
>                                 // runtime eval?

Yes, for consistency with sizeof().

>    int  m = n;
>    int  (*p)[m] = &vla;         // runtime type check?

There's no C++ features used here, so the answer here should be the
same as in C99.  C99 says that this is undefined behaviour if
the sizes don't match.  The implementation can perform a runtime type
check, but is not required to.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Darn, I guess I'm going to have to learn more about the C99 standard before
voicing any more opinions.

Does anyone else get the feeling that C/C++ is moving in the direction of
ADA: too complicated because of design by committee.  I originally liked C
because it was very basic.  I wonder why they took the approach with sizeof
that they did?

Greg



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

> Darn, I guess I'm going to have to learn more about the C99 standard before
> voicing any more opinions.
>
> Does anyone else get the feeling that C/C++ is moving in the direction of
> ADA: too complicated because of design by committee.  I originally liked C
> because it was very basic.  I wonder why they took the approach with sizeof
> that they did?

My first problem with this is that C++ was intended to solve complex
  problems; I believe complex languages can make complex problems
  easier.

My second problem with this is that C++ as described in the ARM was
  already quite complex. The committee did not much increase the
  complexity of the core language (by 'core language', I mean ch
  1-16).

IOWs: C++ is complex because of the many kinds of problems it tries to
  solve, not because of the committee. (I think we are fortunate in
  that the C++ committee somehow avoided/overcame most of the problems
  that usually result from design by committee - but that is a
  somewhat separate issue.)

In any case, I feel that reading this ng can leave one with the
  impression that the complexities of C++ are much larger problem than
  they really are; the topic of comp.std.c++ is, almost by definition,
  the complicated parts of 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Fergus Henderson" <fjh@cs.mu.OZ.AU> wrote in message
news:8quae1$qv6$1@mulga.cs.mu.OZ.AU...
> David R Tribble <david@tribble.com> writes:
>
> >The complete type of the VLA object can only be determined at
runtime,
> >which causes some problems, such as evaluating sizeof(), typeid(),
> >and the & operator.
> >
> >    int  n = ...;
> >    int  vla[n];
> >
> >    size_t  sz = sizeof(vla);    // evaluated at runtime
>
> Yes, for compatibility with C99.
>
> >    const char *  t = typeid(vla).name();
> >                                 // runtime eval?
>
> Yes, for consistency with sizeof().

Do you mean that typeid(vla) would compare equal to typeid(a), where a
is a statically allocated array with the same size?

A related question, what is 'T' in the code below:

template<class T> void f(T & t)
{
}

f(vla);

And should typeid(T) compare equal to typeid(a)?

--
Peter Dimov
Multi Media Ltd.


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote:
>> BTW, some ports of Comeau C++ support VLAs in C mode, and I imagine
>> that we can also add it into C++ mode as a customization for clients
>> who feel that they really need it.

David R Tribble wrote:
>> I would think that the only complicating factors in adding VLAs to
>> C++ is dealing with proper constructor/destructor calls, and the fact
>> that sizeof(VLA) is evaluated at runtime.  But these problems are not
>> insurmountable.

James Kuyper wrote:
> Indeed - the solution for the ctor/dtor problem is the same as for
> ordinary arrays. The sizeof() issue might cause more problems, but I'm
> not sure exactly where.

Here are a few other problems I thought of.

The complete type of the VLA object can only be determined at runtime,
which causes some problems, such as evaluating sizeof(), typeid(),
and the & operator.

    int  n = ...;
    int  vla[n];

    size_t  sz = sizeof(vla);    // evaluated at runtime

    const char *  t = typeid(vla).name();
                                 // runtime eval?

    int  m = n;
    int  (*p)[m] = &vla;         // runtime type check?

But in spite of these problems, VLAs would probably be a useful
addition to C++.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I don't see these as being much of a problem.

If compiletime evaluation of sizeof is desirable (I think it is) then just
return the sizeof a single item.  If the user wants the size of the whole
array then use "sz = sizeof(vla)*n;" instead.  I am not familar with typeid
so I have no clue.  In general, vla[n] should be treated by compiletime
operators as vla[1] or the same as the argument vla[] as in "int foo(int
vla[]) {return sizeof(vla);}"

Greg


"David R Tribble" <david@tribble.com> wrote in message
news:39CF8C81.D4C1DC29@tribble.com...
> Here are a few other problems I thought of.
>
> The complete type of the VLA object can only be determined at runtime,
> which causes some problems, such as evaluating sizeof(), typeid(),
> and the & operator.
>
>     int  n = ...;
>     int  vla[n];
>
>     size_t  sz = sizeof(vla);    // evaluated at runtime
>
>     const char *  t = typeid(vla).name();
>                                  // runtime eval?
>
>     int  m = n;
>     int  (*p)[m] = &vla;         // runtime type check?
>
> But in spite of these problems, VLAs would probably be a useful
> addition 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8q2d8h$1f7$1@panix6.panix.com>, Greg Comeau
<comeau@panix.com> writes
>My experience is that requests are usually not easy to carry out, so
>that's not the issue per se, although what you say is mostly correct
>IMO.  Also, all of the C++ committee did/does not have knowledge of C89
>either,

But enough did, and it was a stable document throughout the process,
which was certainly not true of C++ during the process of producing C99.

>whether it was or is a base document or not. Anyway, the bottom
>line is that somebody needs to do the work is what is comes down too,

Actually, I am not convinced of this. Personally I view C89 as a kind of
'base' language from which two groups have derived new languages. Both
have tried to keep compatible with C89 but that is far as it went, and
IMHO as far as it should have gone. Certainly each can borrow ideas from
the other and when doing so should be careful not to add
incompatibilities in the use of these things.

>
>and it seems Tribble has.

For which we all owe him thanks.

Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8q53k6$1fuc$1@news.hal-pc.org>,
Greg Brewer <nospam.greg@brewer.net> wrote:
>"Greg Comeau" <comeau@panix.com> wrote in message
>news:8ptpfj$l4a$1@panix3.panix.com...
>> Martin Reinecke  <martin@mpa-garching.mpg.de> wrote:
>> >I'd like to know if there exists a policy for integrating the
>> >changes that were made to C by the C99 standard into C++.
>> >I'm most curious about the C99 variable-length arrays: is it likely
>> >that they will be introduced into C++ and if so, when would this happen?
>> As per above, nobody knows yet.  That said, why not use std::vector<>?
>
>For that matter, why not use new?

Indeed.  I was just throwing out another choice,
not the only choice.

>The reason is that stack management is
>much more efficient that heap management.

As an aside, I'll be curious to see if there are ever any
VLA implementations that actually will use the heap.

>I've always wondered why variable-length arrays weren't in from
>the beginning.

malloc() was probably thought to be ample enough.
Remember, C started as a sys prog lang.  Who wouldn't thought
that they wanted other things too? :)

>They are rather easy to implement: just add the
>array count times the size to the stack.

It's more involved than that, but yes, not the hardest
feature ever to have implemented.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
> [...]  I've always wondered why variable-length arrays weren't in
> from the beginning.  They are rather easy to implement: just add the
> array count times the size to the stack.

Well, it's a little more complicated, in that sizeof(VLA) is now
evaluated at runtime.  This was never the case in C89 or C++98.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Comeau wrote:
> BTW, some ports of Comeau C++ support VLAs in C mode, and I imagine
> that we can also add it into C++ mode as a customization for clients
> who feel that they really need it.

I would think that the only complicating factors in adding VLAs to C++
is dealing with proper constructor/destructor calls, and the fact that
sizeof(VLA) is evaluated at runtime.  But these problems are not
insurmountable.

Most of the new C99 features are fairly small additions, and are
probably fairly easy to add to C++.  It's only the few complicated
ones that are either difficult to add to C++ or simply don't make
sense for C++.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Greg Brewer wrote:
>
> For that matter, why not use new?  The reason is that stack management is
> much more efficient that heap management.  I've always wondered why
> variable-length arrays weren't in from the beginning.  They are rather easy
> to implement: just add the array count times the size to the stack.

Some systems require a fixed stack size for a function invocation,
computed at compile time.  I think that was a major reason for requiring
auto arrays to have a size computable at compile time.

Evidently the C committee decided that making things easy for such systems
was less important for C99 than providing arrays that could be sized at
runtime.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Greg Comeau wrote:
> > BTW, some ports of Comeau C++ support VLAs in C mode, and I imagine
> > that we can also add it into C++ mode as a customization for clients
> > who feel that they really need it.
>
> I would think that the only complicating factors in adding VLAs to C++
> is dealing with proper constructor/destructor calls, and the fact that
> sizeof(VLA) is evaluated at runtime.  But these problems are not
> insurmountable.

Indeed - the solution for the ctor/dtor problem is the same as for
ordinary arrays. The sizeof() issue might cause more problems, but I'm
not sure exactly where.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Bt3F36AdWOx5Ew3w@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <8q2d8h$1f7$1@panix6.panix.com>, Greg Comeau
><comeau@panix.com> writes
>>whether it was or is a base document or not. Anyway, the bottom
>>line is that somebody needs to do the work is what is comes down too,
>
>Actually, I am not convinced of this. Personally I view C89 as a kind of
>'base' language from which two groups have derived new languages. Both
>have tried to keep compatible with C89 but that is far as it went, and
>IMHO as far as it should have gone. Certainly each can borrow ideas from
>the other and when doing so should be careful not to add
>incompatibilities in the use of these things.

I'm unclear what you're not convinced of.

As I already mentioned, I seriously doubt that all C99 will,
or even could, or should be brought into C++.  But the fact of
the matter is that the same code base exist for many C compilers
for their C++ form, and so at the least features are going to
trickle back and forth, whether one likes it or not.  This
means C++ compiler are going to end up with C99'isms whether
C99 and C++ are on different paths from C89 or not.
Note the work I'm talking about above is not actually
incorporating all the C99'isms into C++, but giving
serious attention to what the incompatibilities are.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <39BF4A32.3845F7D4@mpa-garching.mpg.de>,
Martin Reinecke  <martin@mpa-garching.mpg.de> wrote:
>I'd like to know if there exists a policy for integrating the
>changes that were made to C by the C99 standard into C++.

No, at least to the best of my knowledge, there is no such
requirement.  I do seem to recall the C++ committee asked the
C committee to document the differences between C99 and C++
(or something like that), but that was more a request than
a demand (and I believe Dave Tribble has mostly done so
independetly at this point anyway).

>Is the goal to incorporate all changes to C into the next release
>of the C++ standard by default (except where this is impossible
>for some fundamental reason)?

No, there is no such goal.  If there is, then it's still will
be up for debate with the C++ revision period opens up.

>Or are only those changes incorporated
>which seem "useful" for C++

Again, it's up to the C++ committee so far, and they have not
formally discussed the topic in full, so it's still open.

>(this would mean that the languages could
>start to diverge and that C is no longer nearly a subset of C++)?

That's right, and some may or may not think that that's not a bad idea.

>I'm most curious about the C99 variable-length arrays: is it likely
>that they will be introduced into C++ and if so, when would this happen?

As per above, nobody knows yet.  That said, why not use std::vector<>?

BTW, some ports of Comeau C++ support VLAs in C mode, and I imagine
that we can also add it into C++ mode as a customization for clients
who feel that they really need it.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <8ptpfj$l4a$1@panix3.panix.com>, Greg Comeau
<comeau@panix.com> writes
>No, at least to the best of my knowledge, there is no such requirement.
>I do seem to recall the C++ committee asked the C committee to document
>the differences between C99 and C++ (or something like that), but that
>was more a request than a demand (and I believe Dave Tribble has mostly
>done so independetly at this point anyway).

Any such request would not have been easy to carry out as it would
require those concerned to have a substantial knowledge of C++. Before
anyone points out that there was such a requirement placed on C++ vis-a-
vis C89, note that C89 was a base document for C++, and so the C++
committee was expected to have some familiarity with C89



Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <n+U8DyAXy9w5EwLU@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <8ptpfj$l4a$1@panix3.panix.com>, Greg Comeau
><comeau@panix.com> writes
>>No, at least to the best of my knowledge, there is no such requirement.
>>I do seem to recall the C++ committee asked the C committee to document
>>the differences between C99 and C++ (or something like that), but that
>>was more a request than a demand (and I believe Dave Tribble has mostly
>>done so independetly at this point anyway).
>
>Any such request would not have been easy to carry out as it would
>require those concerned to have a substantial knowledge of C++. Before
>anyone points out that there was such a requirement placed on C++ vis-a-
>vis C89, note that C89 was a base document for C++, and so the C++
>committee was expected to have some familiarity with C89

My experience is that requests are usually not easy to carry out,
so that's not the issue per se, although what you say is mostly
correct IMO.  Also, all of the C++ committee did/does not have
knowledge of C89 either, whether it was or is a base document or not.
Anyway, the bottom line is that somebody needs to do the work
is what is comes down too, and it seems Tribble has.

- Greg
--
Comeau Computing / Comeau C/C++ ("so close" 4.2.44 betas starting)
TRY Comeau C++ ONLINE at http://www.comeaucomputing.com/tryitout
Email: comeau@comeaucomputing.com / WEB: http://www.comeaucomputing.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:8ptpfj$l4a$1@panix3.panix.com...
> Martin Reinecke  <martin@mpa-garching.mpg.de> wrote:
> >I'd like to know if there exists a policy for integrating the
> >changes that were made to C by the C99 standard into C++.
> >I'm most curious about the C99 variable-length arrays: is it likely
> >that they will be introduced into C++ and if so, when would this happen?
> As per above, nobody knows yet.  That said, why not use std::vector<>?

For that matter, why not use new?  The reason is that stack management is
much more efficient that heap management.  I've always wondered why
variable-length arrays weren't in from the beginning.  They are rather easy
to implement: just add the array count times the size to the stack.

Greg Brewer


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Martin Reinecke" <martin@mpa-garching.mpg.de> wrote...
> Is the goal to incorporate all changes to C into the next release
> of the C++ standard by default (except where this is impossible
> for some fundamental reason)? Or are only those changes incorporated
> which seem "useful" for C++ (this would mean that the languages could
> start to diverge and that C is no longer nearly a subset of C++)?

The later is more likely than the former. I doubt very much that C99 will be
completely intergated into C++, simply because there *are* fundamental
problems. Look back 6 months or so in comp.std.c++, and you'll find long
discussions about the incompatibilities between C99 and C++.

- Scott

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hello,

I'd like to know if there exists a policy for integrating the
changes that were made to C by the C99 standard into C++.

Is the goal to incorporate all changes to C into the next release
of the C++ standard by default (except where this is impossible
for some fundamental reason)? Or are only those changes incorporated
which seem "useful" for C++ (this would mean that the languages could
start to diverge and that C is no longer nearly a subset of C++)?

I'm most curious about the C99 variable-length arrays: is it likely
that they will be introduced into C++ and if so, when would this happen?

Thanks,
  Martin Reinecke

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin Reinecke wrote:
>
> I'd like to know if there exists a policy for integrating the
> changes that were made to C by the C99 standard into C++.

There is not.  There is no requirement that the C++ and C
standards retain any particular degree of compatibility,
although most members of both standards committees prefer
to retain as much compatibility as possible.

The different release schedules of the standards made it
difficult to ensure that C99 and C++98 would not drift apart.
Indeed, there is some drift.

Many of the new C99 features can be trivially added to a
future C++ standard. (Work has not yet begun on a new C++
standard, and there is no definite timetable for starting
such work.) Some new C99 features interact badly with C++,
and will require some study.

--
Steve Clamage, stephen.clamage@sun.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://reality.sgi.com/austern_mti/std-c++/faq.html              ]