Page 4 of 7 FirstFirst ... 23456 ... LastLast
Results 31 to 40 of 67

Thread: John Carmack's Comments On C/C++

  1. #31
    Join Date
    Mar 2008
    Posts
    206

    Default

    Quote Originally Posted by mark45 View Post
    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".

  2. #32
    Join Date
    Jul 2010
    Posts
    476

    Default

    Quote Originally Posted by h**2 View Post
    C++(11) does *exactly* this:
    Code:
    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.

  3. #33
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    303

    Default

    Quote Originally Posted by h**2 View Post
    C++(11) does *exactly* this:
    Code:
    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".

  4. #34
    Join Date
    Jun 2011
    Posts
    55

    Default

    Quote Originally Posted by log0 View Post
    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:

    Code:
    auto foo(auto i, auto j) {
        return i * j;
    }
    Last edited by Vax456; 01-15-2013 at 11:35 AM.

  5. #35
    Join Date
    Jun 2012
    Posts
    340

    Default

    Quote Originally Posted by F i L View Post
    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.

  6. #36
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    303

    Default

    Quote Originally Posted by newwen View Post
    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).

  7. #37
    Join Date
    Jul 2010
    Posts
    476

    Default

    Quote Originally Posted by Vax456 View Post
    Also, he's now fighting to get the auto keyword to be used as a form of template for the next revision:

    Code:
    auto foo(auto i, auto j) {
        return i * j;
    }
    OMG, me want this!!!

  8. #38
    Join Date
    Sep 2010
    Posts
    456

    Default

    Syntax being easy to read, expressive and flexible seems like it's the most important thing.
    (I notice that with the << it's easier to read, produces smaller code and is (less error prone?) shorter than printf.)
    (The use of the %s, %d specifiers has an issue since the type specification seems to conflict with the DRY principle of software engineering. )

  9. #39
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,533

    Default

    Quote Originally Posted by nslay View Post
    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 first one was D, the second one was C.

    Quote Originally Posted by Ancurio View Post
    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.
    Yea, it was an example that people picked up. In general I just feel that C++ is too reliant on all their operators, so code is no longer as easily readable if you are not familiar with the meaning of each.

    Quote Originally Posted by h**2 View Post
    C++(11) does *exactly* this:
    And for the reference, here's the D version (with an additional case and that is syntactically valid):
    Code:
    template foo(T, O : int) 
    {
        auto foo(T x, O y)
        {
        	return x * y;
        }
    }
    
    int main()
    {
        string  s = "text"; // 's' is text
        auto i = 0;      // 'i' is an int
        auto f = 0.0 ;   // 'f' is a double
    
        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'
        auto r4 = foo(i, f) ;// error: can't pass non-int as second parameter
        return 0;
    }

  10. #40
    Join Date
    Jun 2012
    Posts
    80

    Default

    Quote Originally Posted by GreatEmerald View Post
    The first one was D, the second one was C.



    Yea, it was an example that people picked up. In general I just feel that C++ is too reliant on all their operators, so code is no longer as easily readable if you are not familiar with the meaning of each.
    I think you're exaggerating C++'s reliance on operators since only two are used to define an extensible and cascaded input/output mechanism.

    Function overloading and the cascading behavior of operators make a strong case for this scheme ... no matter how unusual it looks.

    In the end, most C++ programmers don't write their own operators (except for extending stream operators). Those that do are often doing it for mathematical objects (where it makes sense) or string-like objects (where + and "concatenate" are universally synonymous).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •