John Carmack's Comments On C/C++

[F i L]

It seems you're describing Vala.

Does Vala work like that? I know it's variables are, by default, non-null types.. but I thought it was still classic ref-counting/smart-pointer stuff. My proposal would be more optimized (in theory) since 'var' memory would be directly tied to their scope, and all clean-up code (for both vars & refs) could be statically determined. Thereby avoiding the need to count references on variable assignment... now that I think about it though, I guess Vala could implement similar optimizations for their non-nullable types. Do you know if this is the case?

There's also more things about Vala that I don't appreciate.. namely no operators or method overloads (also, I'm not really a fan of the overly-airy C#-like syntax, but it's not that bad). I talked to a Vala dev once, and he informed me that was due mostly to Vala's tie to GObject linking and the fact that Vala is OOC and designed to play perfectly with C.

I would still like to know about any optimization information you're aware of though (or any links you might have on the topic).

[gamerk2]

I was responding to a comment about "the perfect language".

An oxymoron if I ever heard one.

Personally, I prefer C++ (though I admit I have yet to use D on a project of any size) for the majority of my work. Despite its occasional oddities, its simply the easiest to develop with (aside from C# for a Windows program) and easiest to expand.

My least favorite language is the one I'm stuck with for the next decade: Ada, which comes in just ahead of Assembly on my list.

[Vax456]

That auto stuff is neat. I can't understand why it took them so long, should have been added to the spec together with the templates.

As I understand, Bjarne Stroustrup has been fighting to get it in for over 20 years, but there were compatibility problems with C that were only worked out in time for C++11.

Also, he's now fighting to get the auto keyword to be used as a form of template for the next revision:

auto foo(auto i, auto j) {
    return i * j;
}

[F i L]

C++(11) does *exactly* this:

template<typename T>
T foo(const T x &, const int y) 
{
    return x * y;
}

int main()
{
    char  s[] = "text"; # 's' is text
    auto i = 0;      # 'i' is an int
    auto f = 0.0 ;   # 'f' is a float

    auto r = foo(s, i) ;# error: can't pass text as a first parameter
    auto r2 = foo(f, i) ;# works: because compiler can multiply a 'int' and a 'float'
    auto r3 = foo(i, i) ;# works: compiler can compile 'int' and 'int'
    return 0;
}

Yes, but my original point with that code was about how to design a language which was both powerful/efficient and fully strong-typed (like C++/D) and also simple to write & understand with a syntax not shy of weak-typed language (like Javascript/Python).

It's of course possible in C++, and the same thing is much cleaner looking in D. However, it's still chalk full of all kinds of extra keywords and qualifiers. C++ gets much more complicated once you start adding in compile-time conditions, etc. D is better, but there's still a lot of it's syntax design which, IMO, could be improved (and never will, since it's strives to be compatible with C). I was responding to a comment about "the perfect language".

[log0]

C++(11) does *exactly* this:

template<typename T>
T foo(const T x &, const int y) 
{
    return x * y;
}

int main()
{
    char  s[] = "text"; # 's' is text
    auto i = 0;      # 'i' is an int
    auto f = 0.0 ;   # 'f' is a float

    auto r = foo(s, i) ;# error: can't pass text as a first parameter
    auto r2 = foo(f, i) ;# works: because compiler can multiply a 'int' and a 'float'
    auto r3 = foo(i, i) ;# works: compiler can compile 'int' and 'int'
    return 0;
}

That auto stuff is neat. I can't understand why it took them so long, should have been added to the spec together with the templates.

[bnolsen]

What exactly got you disappointed in D? Just curious.

Very high number of keywords for a starting language. No way to avoid garbage collection. Seemed too much like "design by fad".

[h**2]

Not really. The language could be fully strong-typed, but also support typeless parameters. The compiler would analyse the function, and determine the restrictions each typeless parameter required, then give compiler errors if the code tries to pass a variable which doesn't meet those restrictions. These functions would be template function, which new version being compiled out with each unique set of param types used (therefor, special restrictions would be required for key Shared Object functions). eg:

func foo(x, y:int) # 'x' is typeless, 'y' must be an int
{
    return x * y
}

func main
{
    var s = "text" # 's' is text
    var i = 0      # 'i' is an int
    var f = 0.0    # 'f' is a float

    var r = foo(s, i) # error: can't pass text as a first parameter
    var r = foo(f, i) # works: because compiler can multiply a 'int' and a 'float'
    var r = foo(i, i) # works: compiler can compile 'int' and 'int'
}

In the code above, two versions of 'foo' would be compiled out... one taking in a (float, int), and one taking in an (int, int).

C++(11) does *exactly* this:

template<typename T>
T foo(const T x &, const int y) 
{
    return x * y;
}

int main()
{
    char  s[] = "text"; # 's' is text
    auto i = 0;      # 'i' is an int
    auto f = 0.0 ;   # 'f' is a float

    auto r = foo(s, i) ;# error: can't pass text as a first parameter
    auto r2 = foo(f, i) ;# works: because compiler can multiply a 'int' and a 'float'
    auto r3 = foo(i, i) ;# works: compiler can compile 'int' and 'int'
    return 0;
}

[Ancurio]

It seems you're describing Vala.

Vala doesn't generate code for its "generics".


Also, as to "printf() vs cout", that just seems like such a stupid and unnecessary discussion.
You're not discussing languages, only conventions of standard libraries at best. Also,
who said you're forced to use std::cout in C++? Just use printf instead if that's what you like.
I, personally, prefer my "qDebug() << object" because it's very fast to write and easy to read.
Compare that to

char *s = object_as_string(object);
printf("Object: %s\n", s);
free(s);

As soon as types get more complex, printf fails miserably.

[nslay]

How about this:

writeln("Today is January ", 15, ", ", 2013);

Or even:

printf("Today is January %d, %d\n", 15, 2013);

The first one would never work in C. See stdarg.h for more information. In C++11, you can use variadic templates for a writeln() function as you described. But then, at the very worst, the compiler will produce a unique function for every output format you use. More likely, the compiler will inline such templated writeln() functions.

The second example requires you remember %d for outputting integers. That's OK for basic types. But what about system typedefs like size_t? Is that %u, %lu, or %llu? This is such a problem that C99 introduced macros in stdint.h for printf and scanf type specifiers for integer typedefs.

In all fairness, the compiler usually corrects misuses of printf, or at the very least prints a warning.

Neither example allows you to extend input/output to new types (in fact, it is illegal to pass anything but atomic types to ellipsis functions like printf).

EDIT:
Just so you know, the first example is not possible in C++ prior to C++11.

[susikala]

Without making too much of a C-fanboyism point, I always thought that printf was the best, most simple and most elegant solution to combining logic and presentation. It actually does it very well, in strictly separating presentation and logic. Every other solution, including using <<, ., + or simply tons of function calls, or at the ugliest the php way of jumping fro and to html, always feels wrong.