Page 5 of 7 FirstFirst ... 34567 LastLast
Results 41 to 50 of 67

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

  1. #41
    Join Date
    Jul 2009
    Posts
    18

    Default

    Quote Originally Posted by GreatEmerald View Post
    Well, even the very basic printing to console. C is consistent in that it uses a function for that, printf(). And C++ uses the "cout" notation that looks way out of place.
    Well, the printing to console does not have anything to do with the language itself! You have to understand that C++ != STL and C != libc. Let me explain:
    cout is actually an object and you just call operator "<<" on it. cout is not a keyword, it's just name for a struct that someone made and the "<<" operator was just simply chosen because it looks nicer than (+,-,*...). You don't have to use the STL library. It's absolutely not mandatory or recommended. (Embedded systems don't use STL, Qt doesn't use STL...)
    Anyway, these operator overloading is a beautiful thing. You can do something like complexnum3 = complexnum1 + complexnum2 and you can define what + and = do. It's like automatic calling some function complexsum(c,a,b) without any overhead over ordinary function. The cout << is just like that. You can you use printf. You can write somehting new. You can even use inline assembly like in C.

  2. #42
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    307

    Default

    Quote Originally Posted by GreatEmerald View Post
    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;
    }
    That D code can be even prettier:
    Code:
    auto foo(T)(T x, int y)
    {
        return x * y;
    }
    
    void main()
    {
        auto s = "text"; // 's' is text
        auto i = 0;      // 'i' is an int
        auto f = 0.0 ;   // 'f' is a double
    
        auto r1 = 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
    }

  3. #43
    Join Date
    Sep 2010
    Posts
    474

    Default

    The choice of the word auto as a keyword for automatically determining type is an abomination in terms of expressiveness.
    The word autotype should have been used.
    (Auto is just too short and ambiguous. People are going to make mistakes easier.)

    Also in re factoring projects where the word auto had another meaning it's now more of a problem.
    You have to define an alias to know what has been re factored and what not. (Must see the difference easily remember, can't use things that rely on keywords being different.)

  4. #44
    Join Date
    Sep 2010
    Posts
    474

    Default

    Quote Originally Posted by GreatEmerald View Post
    How about this:
    Code:
    writeln("Today is January ", 15, ", ", 2013);
    Or even:
    Code:
    printf("Today is January %d, %d\n", 15, 2013);
    Really like the first one.
    Would like to do the following:

    Code:
    uint intvariable = 5;
    setWrite(std::cout);
    
    writeln("sghsfmhj",12," tyjumdnjmjdsgjhpg ", 2013," pesriprtu", intvariable);
    write(" pegihjesj");
    writeln(123);
    writeln({5}133);
    Would produce the following three lines of output:
    Code:
    sghsfmhj12 tyjumdnjmjdsgjhpg 2013 pesriprtu5
     pegihjesj123
      133
    (The {} is used for format specifying but is in front or behind the object to be converted to a string.)
    Also being able to do toString();
    With comma separated stuff like in the example.
    Also being able to do a toStringNl();
    Same as the previous function but with an endline behind it.
    Being able to use the << operator here:
    <<("sfsgfsf ", 45," sdrghjdsgol");

    (also use of {} with multiple parameters, Example: {6,"^"} Would reserve six places and have as second parameter a filler for the empty space, also multiple {} on one, cascading to form more interesting outputs)

    Short, easy readable, see what you get out of it, concise, very functional and high-level.
    Last edited by plonoma; 01-15-2013 at 12:39 PM. Reason: removed character at wrong place

  5. #45
    Join Date
    Jul 2010
    Posts
    503

    Default

    Quote Originally Posted by plonoma View Post
    The choice of the word auto as a keyword for automatically determining type is an abomination in terms of expressiveness.
    The word autotype should have been used.
    (Auto is just too short and ambiguous. People are going to make mistakes easier.)

    Also in re factoring projects where the word auto had another meaning it's now more of a problem.
    You have to define an alias to know what has been re factored and what not. (Must see the difference easily remember, can't use things that rely on keywords being different.)
    You mean too short and ambigous compared to short, long, double?

    And if you find it too hard to substitute auto, you might be using the wrong source code editor.

  6. #46
    Join Date
    Sep 2010
    Posts
    474

    Default

    It's not about how hard it is to substitute auto.
    It's about how easy it can be made to figure out which auto to substitute.

  7. #47
    Join Date
    Apr 2008
    Location
    Saskatchewan, Canada
    Posts
    465

    Default

    Quote Originally Posted by disgrace View Post
    the gc from d is not suitable for AAA games.
    Garbage collection is braindead. It's supposed to prevent programmers screwing up memory allocation and deallocation, but just gives them a whole new set of ways to screw up instead while sucking up performance and RAM.

    And if you're using STL in C++ you probably have to write 'new' or 'delete' about once a year.

  8. #48
    Join Date
    Dec 2008
    Location
    Vermont
    Posts
    104

    Default

    As I read TFA and the comments here, a slight paraphrase comes to mind... "Those who do not understand/remember classical structured programming are doomed to reinvent it - poorly."

    Back in the day, I did a pile of non-trivial code in both Pascal and Modula-2. I never did a device driver, but I did do a re-entrant interrupt handler as a DOS TSR way, way back. I interfaced to C graphics libraries, (SWIG didn't exist, back then, so I wrote .defs by hand.) both read and wrote legacy binary data of multiple types.

    Both languages were criticized for "not being able to do anything useful - only writing toy software," but I had quite a bit of useful code written in both. With Modula-2 another common criticism was that it didn't have a good collection of libraries. SWIG didn't exist back then, but I think it would render that issue moot, today. Both languages were also extended to become useful, and that is a valid criticism, though much less so with Modula-2 than with Pascal.

    The more common criticism against both was about "programming in a strait-jacket." But here we see Carmack voluntarily donning that strait-jacket in the name of readability and, I presume, reliability, debuggability, etc. What's more, since C/C++ don't directly have the strait-jacket features, he's working hard to get that stuff back with templates. In that same light, look at the fact that we're still seeing software bugs that Pascal/Modula-2 never would have let us make. Obviously there would still be bugs, and no doubt new categories of bugs, but we're still fighting entirely too many trivial bugs, even now.

    To be fair, neither Pascal nor Modula-2 were object-oriented without heavy extensions. I did do object-oriented-style programming with Modula-2, just like it can be done with C, but it's nicer when the language helps you. There is another variant called Modula-3 that is object oriented, but I haven't played with it.

    Then again, there are Oberon and Oberon-2. Those were Wirth's ventures into OO. The former was more of a teaching/experimental language, like Pascal, while the latter was meant to be practical. I hung out on the Oberon-2 Usenet group for a while. One of those "simplifications" was taking away variant records and the "packed" directive, which was my Swiss-army-knife for accessing legacy binary data. I brought this up on the list, asking how the heck I was supposed to work with legacy binary data. Their answer was to get all of those legacy applications re-coded into Oberon-2. That was about the time I quite following the language.

    About that time I shifted platforms to Linux, and never really picked up doing my own compiled code since, past "./config ; make ; make install". I do mostly Python these days. (and still wish for "var" and "const", so I know exactly how things are being passed)

  9. #49
    Join Date
    Mar 2008
    Posts
    210

    Default

    Quote Originally Posted by plonoma View Post
    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. )
    Ugh.. iostreams is the absolute worst part of the whole standard c++ libraries. It's slow, full of thread locks (due to locale being attached to the binary streambuf base class), bad design with "<<" (horrible for translation grammar).

    I'm not a huge fan of "auto" except in very limited cases. It looks like a vehicle for generating unmaintainable/unreadable code. Someone looking at this stuff dry has not idea what datatypes are contained in those variables. I'll limit "auto" for use with those ugly iterator declarations, thank you.
    Last edited by bnolsen; 01-15-2013 at 02:33 PM.

  10. #50
    Join Date
    Oct 2012
    Posts
    24

    Default

    Quote Originally Posted by bioinfornatics View Post
    D is far easier to read and write than C++.
    At beginning the language had some important bug that is the normal workflow for anything in informatic. Now the language is stable and for new code is better to start with D. Try it now
    I don't think it's easier to read, templates yes, the rest no. Much of the recent code ive seen recently seems to have diverged from C syntax which to me is the most readable.

Posting Permissions

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