Board index » cppbuilder » Re: State of C++0x

Re: State of C++0x


2004-06-05 12:21:59 AM
cppbuilder17
Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >writes:
[snip]
Quote
On the other hand, C++ and lisp have different strengths, and if they
have the same kinds of features,
'strengths' is included into, but not identical to, 'features'. I
don't think that C++ has more strengths that Common Lisp, as a
programming language specification. The real-world differences
(performance of executables, availability of libraries) comes from the
state of the market.
Quote
then the difference between them
approaches mere syntax.
Syntax matters. See Lisp macros. The Haskell and OCaml guys tried to
add macros to their languages and the results are not very appealing,
or so the reports say. And don't get me started on readability :-)
Quote
When two languages are identical except for
syntax, one of them is not necessary.
Language A provides a clean, elegant and versatile syntax whereas
language B is really ugly but compatible with language C <sic>. Which
one wins?
Programmers are lazy, aren't they? ;-)
--
Oscar
 
 

Re:Re: State of C++0x

Russell Hind wrote:
Quote
I do like the idea of type safety still being tracked by the compiler,
but I still wouldn't like to see code that declares 'autos' as members
of a class, then somewhere in the class you see

class A
{
auto m_a;
};
That's not it. An auto variable must always be initialized. It's not a
variant type that can hold just about anything. It's a strictly typed
variable, where the type is dediced from the expression on the right:
auto i = 5; // it's an int
auto d = 3.14; // it's a double
auto it = container.begin(); // it's an iterator
Every C++ construct can be abused. But if it's used correctly, auto can
produce a readable code.
Tom
 

Re:Re: State of C++0x

Oscar Fuentes < XXXX@XXXXX.COM >writes:
Quote
>When two languages are identical except for
>syntax, one of them is not necessary.

Language A provides a clean, elegant and versatile syntax whereas
language B is really ugly but compatible with language C <sic>. Which
one wins?
Notice, I didn't say which one was not necessary... :)
Quote
Programmers are lazy, aren't they? ;-)
It's a virtue.
--
Chris (TeamB);
 

{smallsort}

Re:Re: State of C++0x

Tamas Demjen < XXXX@XXXXX.COM >writes:
Quote
Russell Hind wrote:

>I do like the idea of type safety still being tracked by the
>compiler, but I still wouldn't like to see code that declares
>'autos' as members of a class, then somewhere in the class you see
>class A
>{
>auto m_a;
>};

That's not it. An auto variable must always be initialized. It's not a
variant type that can hold just about anything. It's a strictly typed
variable, where the type is dediced from the expression on the right:

auto i = 5; // it's an int
auto d = 3.14; // it's a double
auto it = container.begin(); // it's an iterator

Every C++ construct can be abused. But if it's used correctly, auto
can produce a readable code.
I think his concern was to declare a member as 'auto', and initilize
it in the constructor initialzer list, which would be an unambiguous
way to initialize the variable.
This would run into trouble if there were multiple constructors that
all initialized it with slightly different types (like long, int, and
char). Then it'd either have to be ambiguous, or have some arbitrary
rule determineing what the final type would be (maybe the largest
size?)
Naw, I think an auto member shouldn't be accepted. It's just too easy
to get wrong. A template parameter is good enough for most purposes
anyway.
--
Chris (TeamB);
 

Re:Re: State of C++0x

Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >writes:
Quote
I think his concern was to declare a member as 'auto', and initilize
it in the constructor initialzer list, which would be an unambiguous
way to initialize the variable.

This would run into trouble if there were multiple constructors that
all initialized it with slightly different types (like long, int, and
char). Then it'd either have to be ambiguous, or have some arbitrary
rule determineing what the final type would be
Make it an error.
Quote
(maybe the largest size?)
More implicit type casts on the language? Bad idea, IMO.
Quote
Naw, I think an auto member shouldn't be accepted. It's just too easy
to get wrong. A template parameter is good enough for most purposes
anyway.
Auto members would be ok on template classes *only*. Like this:
template <typename T>class Foo {
auto m;
public:
Foo(T a) : m( bar(a) ) {}
auto get_m() const { return m; } // A getter
void set_m(typeof(m) v) { m = v } // A setter
};
--
Oscar
 

Re:Re: State of C++0x

Quote
I think his concern was to declare a member as 'auto', and initilize
it in the constructor initialzer list, which would be an unambiguous
way to initialize the variable.
That's right, using auto as a member function can not be allowed. I
don't see anything about that in the draft standard, which means it's
not going to be allowed. The auto member has at least two problems, as
you mentioned, what if there are multiple constructors, and what if the
constructor is not inline. When you include a header file, you must know
the size of the class in order to create an instance of it, and if the
type information is not in the header file but in the CPP, that's
completely wrong. In order to deduce the type, you really have to have
the initialize the auto varibale right on the spot, either of the
following two ways:
auto x = 1;
auto x(1);
There are many other things to consider, for example, polymorphism:
class Base { virtual void f(); };
class Descendant : public Base { virtual void f(); };
Base* p = new Descendant;
auto a = *p; // is this a Base or a Descendant?
I guess that's why the standardization takes so long. You have to think
of everything.
Tom
 

Re:Re: State of C++0x

Tamas Demjen < XXXX@XXXXX.COM >writes:
Quote
>I think his concern was to declare a member as 'auto', and initilize
>it in the constructor initialzer list, which would be an unambiguous
>way to initialize the variable.

That's right, using auto as a member function can not be allowed. I
don't see anything about that in the draft standard, which means it's
not going to be allowed. The auto member has at least two problems, as
you mentioned, what if there are multiple constructors, and what if
the constructor is not inline. When you include a header file, you
must know the size of the class in order to create an instance of it,
and if the type information is not in the header file but in the CPP,
that's completely wrong. In order to deduce the type, you really have
to have the initialize the auto varibale right on the spot, either of
the following two ways:
auto x = 1;
auto x(1);
As stated on my previous message, 'auto' data members would be
meaningful on template classes only. This may invalidate your
objections.
Quote
There are many other things to consider, for example, polymorphism:
class Base { virtual void f(); };
class Descendant : public Base { virtual void f(); };
Base* p = new Descendant;
auto a = *p; // is this a Base or a Descendant?
*p is of type Base, so the above is Base a(*p).
Quote
I guess that's why the standardization takes so long. You have to
think of everything.
Right. The real problem with C++ standardization taking so long is,
IMHO, overcoming reactionary people.
--
Oscar
 

Re:Re: State of C++0x

Oscar Fuentes wrote:
Quote
(performance of executables, availability of libraries) comes from the
state of the market.
Maybe
felix.sourceforge.net/
Felix is new, high power, Open Source, community based programming
language which provides an ML style type system with a syntax that
C++ programmers should find easy to learn. It generates C++ and
supports both use of C++ types as primitives, as well as embedding
in existing C++ written architectures in a natural manner.
Unlike many other scripting languages, Felix boasts seamless
integration with C and C++ code bases, which it achieves by adopting
the C/C++ object model directly.