C++0x



  • @MasterPlanSoftware said:

    @bstorer said:
    Hmmm, anyone wanna rewrite SSDS in C++0x?
     

    Obviously, we should rewriting C++0x in SSDS.

    Great, now I'm thinking about how to make SSDS Turing complete. 



  •  @bstorer said:

    ...stuff...

    I'm arguing against C++, I guess I thought that was clear.  I just think it's odd to go for a mostly-academic flaw such as it's undecidability when there is so much else to hate.  Even if the grammar were decidable, C++ would be a burdensome language.  I think the root of C++'s problems lay in it's combination of low-level and high-level abstraction techniques.  It seems like the opposite of a domain-specific language in that it tries to solve every problem and it can be made to work if you have the time, skill and patience, but it still blows.  Every encounter I've ever had with C++ has made me glad I don't have to program in it, including this discussion.  I mean, fuck, it took a few dozen posts just to flesh out whether the grammar was truly undeciable and professed C++ programmers have made many incorrect statements in this thread that had to be retracted.  I'm not claiming to know more about the language, just that outwardly it seems unmanageable when professionals can spend so much time arguing about what are pretty fundamental aspects of the language specification. 



  • @tster said:

    this is all part of their thinking that a programing language is the same as a program.  Notice when they said that it's fine that parsing C++ is undeterminate because all lanugauages can have undeterminate programs.  

    Nice interpretation. The point I actually was trying to make was that C++ templates allow you to express computations that are preformed at compile time. So the compiler becomes the run time environment (and in some sense, parts of the source code are programs that are executed by the compiler). Nevermind that there actually is a final program which is sort of the result from the first one.

    So, because I can express more-or-less general computations in templates, which must be evaluated compile time, it is obvious that templates (or any meta-programming) have the same limitations as any other programs. Which was the point I was trying to make.



  • @morbiuswilters said:

     @bstorer said:

    ...stuff...

    I'm arguing against C++, I guess I thought that was clear.  I just think it's odd to go for a mostly-academic flaw such as it's undecidability when there is so much else to hate.  Even if the grammar were decidable, C++ would be a burdensome language.  I think the root of C++'s problems lay in it's combination of low-level and high-level abstraction techniques.  It seems like the opposite of a domain-specific language in that it tries to solve every problem and it can be made to work if you have the time, skill and patience, but it still blows.  Every encounter I've ever had with C++ has made me glad I don't have to program in it, including this discussion.  I mean, fuck, it took a few dozen posts just to flesh out whether the grammar was truly undeciable and professed C++ programmers have made many incorrect statements in this thread that had to be retracted.  I'm not claiming to know more about the language, just that outwardly it seems unmanageable when professionals can spend so much time arguing about what are pretty fundamental aspects of the language specification.

     

    I entirely agree with you.  The whole undecidability thing came up because it's mentioned in the C++ FQA, and was quoted here.  I just think it reeks of bad design, like many things in the language. 



  • @bstorer said:

    I entirely agree with you.  The whole undecidability thing came up because it's mentioned in the C++ FQA, and was quoted here.  I just think it reeks of bad design, like many things in the language. 

    Granted, C++ is far from perfect, but so far I've failed to find any suitable replacement. I've looked at (and tried) a bunch, e.g. Java/Scala, Python, Lua, Erlang, Haskell (briefly), ... While they all have their uses, they sometimes just get into my way (in particular, inline assembly is a bitch). And with C/C++ one can easily link against plenty of libraries out there without having to write all sorts of wrappers and stuff.

    So if anyone can suggest a good language for doing numerical simulations and stuff, I'm listening. :-) (And no, Fortran is not a valid suggestion.)



  • @cvi said:

    @bstorer said:
    I entirely agree with you.  The whole undecidability thing came up because it's mentioned in the C++ FQA, and was quoted here.  I just think it reeks of bad design, like many things in the language.

    Granted, C++ is far from perfect, but so far I've failed to find any suitable replacement. I've looked at (and tried) a bunch, e.g. Java/Scala, Python, Lua, Erlang, Haskell (briefly), ... While they all have their uses, they sometimes just get into my way (in particular, inline assembly is a bitch). And with C/C++ one can easily link against plenty of libraries out there without having to write all sorts of wrappers and stuff.

    So if anyone can suggest a good language for doing numerical simulations and stuff, I'm listening. :-) (And no, Fortran is not a valid suggestion.)

     

    If you need to do a bunch of assembly, by all means, use C++.  Actually, no, use C.   And then do the rest in Python or any other of the hundred squajillion languages that provide C hooks.  As far as numerical simulations, I dunno, MATLAB or Octave?



  • I backed out of this discussion a while ago when I realized I was in over my head with regards to the whole issue of decidability of a language.  However, I can't stay quiet about the claims that C++ is an "absolute monstrosity" of a language.  The "evidence" for this that was put forward was that work-arounds were used to deal with limitations of the language in just about every program they have seen.  I am sorry, but as a regular C++ programmer (keep in mind, though, I am not a CS major), I think that is a lame excuse to diss C++.  Having been a teacher assistant in programming classes, I have seen students perform all sorts of workarounds to PERCIEVED problems with the language when they just don't want to bother learning the language.  I see it all the time in codes that my fellow meteorologists write.  Yet, I find myself able to write out C++ programs without crazy little workarounds, and without using some obscure feature of C++.  Most of what I use can be found at www.cppreference.com -- I would like to see somebody claim that the features expressed there are "obscure" or "niches".

    @bstorer said:

      As far as numerical simulations, I dunno, MATLAB or Octave?
     

    For the most part, they just aren't fast enough. 



  • @bstorer said:

    Actually, no, use C.
     

    Agreed.  I can't see any reason to prefer C++ over C except for to gain OO features.  There are some additions that are nice, for sure, like // comments (before they made it into C) and being able to declare variables anywhere in a code block (OK, that one's in C99 too, but full compiler conformance is still not there).  No really compelling reasons aside from gaining OO.  And if you don't need OO, no reasons at all.



  • @WeatherGod said:

    I backed out of this discussion a while ago when I realized I was in over my head with regards to the whole issue of decidability of a language.  However, I can't stay quiet about the claims that C++ is an "absolute monstrosity" of a language.  The "evidence" for this that was put forward was that work-arounds were used to deal with limitations of the language in just about every program they have seen.

    Can you cite the post where this was claimed?  I don't recall seeing it, and don't care enough to go digging for it.

    I am sorry, but as a regular C++ programmer (keep in mind, though, I am not a CS major)

    That's fine.  You don't have to have a degree in computer science to discuss it.

    I think that is a lame excuse to diss C++.

    I do, too.  If you're using constant work arounds, you're probably using the language wrong.  This reminds of the front page post where the guy had turned C++ into Pascal or something.

    Having been a teacher assistant in programming classes, I have seen students perform all sorts of workarounds to PERCIEVED problems with the language when they just don't want to bother learning the language.
     

    Me, too.  But there's also the reverse problem: people perceiving no problems with the language because they haven't bother to learn any other language.

    I see it all the time in codes that my fellow meteorologists write.

    Just out of curiosity, where do you do that you see a bunch of meterologists writing code?  Do you work for NWS (or your country's equivalent) or something?

    Yet, I find myself able to write out C++ programs without crazy little workarounds, and without using some obscure feature of C++.  Most of what I use can be found at www.cppreference.com -- I would like to see somebody claim that the features expressed there are "obscure" or "niches".

    They aren't obscure or niches, but they do have bizarre behaviors.  From a quick glance, www.cppreference.com appears to contain little more than the STL.  If that constitutes the total of what you're doing in C++, then you'd be well suited to using another language.  Still, if speaking only in terms of what's wrong with the STL, try out this little bit of code:

    #include <string>
    

    int foo (std::string z) { return z.size();}

    int main ()
    {
    foo(7);
    return 0;
    }
    </string>


    which gets you this error message:

    $ g++ testA.cpp
    testA.cpp: In function `int main()':
    testA.cpp:9: error: invalid conversion from `int' to `const char*'
    testA.cpp:9: error: initializing argument 1 of `std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
    Whee!</char></char>

    <char><char>

    @bstorer said:
      As far as numerical simulations, I dunno, MATLAB or Octave?
    </char></char>
    For the most part, they just aren't fast enough.
     

    Don't sell MATLAB short.  It'll do most complex math faster than most people's implementations.  Its math is extremely well written, even if it's clumsy as a general purpose language.  I seem to recall it having C hooks, but I could be mistaken.  Maybe I'm thinking of Mathematica?  Although, now that I mention it, Mathematica is pretty sweet.  Wolfram is the man!



  • @bstorer said:

    Still, if speaking only in terms of what's wrong with the STL, try out this little bit of code:


    Yeah, templates turn out relatively horrible error messages. For fun, try boost::spirit (BNF grammars in C++). I once had a grammar that had grown to ~130 loc; some small typo in the grammar produced error output of about ~3MB. I think I still have the output somewhere...

    @bstorer said:

    Don't sell MATLAB short.  It'll do most complex math faster than most people's implementations.  Its math is extremely well written, even if it's clumsy as a general purpose language.  I seem to recall it having C hooks, but I could be mistaken.  Maybe I'm thinking of Mathematica?  Although, now that I mention it, Mathematica is pretty sweet.  Wolfram is the man!

    My personal experience with Matlab varies somewhat; IMO Matlab is great at some stuff (stuff that generally involves lots of matrices, and whenever there's a toolbox for it), but if you can't fit your problem into a set of pre-existing functions, I've found matlab to be rather slow. Of course one could use mex to call C/C++ methods from matlab, and AFAIK there are ways to call Java code as well.

    Generally I've found that writing "good" matlab programs boils down to knowing a bunch of semi-obscure tricks, which seem to involve turning loops into a bunch of matrix/vector operations and some funky function calls. Meh.

    As for Mathematica: I think it's pretty cool. On the other hand, I've never been forced to write a larger program in Mathematica; a friend of mine who wrote lots of code in Mathematica during his thesis however did swear about it pretty much all the time...



  • @bstorer said:

    Can you cite the post where this was claimed?  I don't recall seeing it, and don't care enough to go digging for it.

    http://forums.thedailywtf.com/forums/p/8109/153392.aspx#153392

    @bstorer said:

    Just out of curiosity, where do you do that you see a bunch of meteorologists writing code?  Do you work for NWS (or your country's equivalent) or something?

    Computer programming skills is fast becoming the most sought-after skill in meteorologists.  If you can't program and you want a job as a meteorologist, you will have a hard time finding a job.  Currently, I am a PhD research student working on weather radar software.

     

    They aren't obscure or niches, but they do have bizarre behaviors.  From a quick glance, www.cppreference.com appears to contain little more than the STL.  If that constitutes the total of what you're doing in C++, then you'd be well suited to using another language.  Still, if speaking only in terms of what's wrong with the STL, try out this little bit of code:

    #include 

    int foo (std::string z) { return z.size();}

    int main ()
    {
    foo(7);
    return 0;
    }

    which gets you this error message:

    $ g++ testA.cpp
    testA.cpp: In function `int main()':
    testA.cpp:9: error: invalid conversion from `int' to `const char*'
    testA.cpp:9: error: initializing argument 1 of `std::basic_string<_CharT, _Traits, _Alloc>::basic_string(const _CharT*, const _Alloc&) [with _CharT = char, _Traits = std::char_traits, _Alloc = std::allocator]'

    If you are referring to the attempt at doing an implicit conversion from 'int' to 'const char*', that is only because that is what you programmed.  A character pointer is the closest type to an int, which is what you passed.  If you are referring to the outputted error message showing the template stuff-- yeah, I never really liked that, but I have gotten used to it.  As for using the STL, because I tend to create general-purpose meteorology libraries, I find it best to utilize the STL as much as possible -- particularly for the interface to my libraries.

    @bstorer said:

    Don't sell MATLAB short.  It'll do most complex math faster than most people's implementations.  Its math is extremely well written, even if it's clumsy as a general purpose language.  I seem to recall it having C hooks, but I could be mistaken.  Maybe I'm thinking of Mathematica?  Although, now that I mention it, Mathematica is pretty sweet.  Wolfram is the man!
     

    Yes, matlab can do fast calculations, particularly if you take advantage of element-by-element math operations (as opposed to looping over each element).  However, when you are creating a complex numerical simulation of a tornado, and you need it done *fast*, Fortran (ugh!) or C/C++ is your choice.  The C hooks you are talking about is mexglx (i think).



  • @bstorer said:

    @WeatherGod said:

    And we see this sort of programming where....?
     

    Who cares where we see it, or even if we see it?  The question is whether or not C++ has an undecidable grammar, and specifically, if the parameter list of a function definition can be undecidable.  Clearly, it can. 

     

     

     Translation: C++ allows me to kick myself in the balls, so i'm better not using it or i'll end doing it just for fun.



  • @WeatherGod said:

    @bstorer said:

    Can you cite the post where this was claimed?  I don't recall seeing it, and don't care enough to go digging for it.


    http://forums.thedailywtf.com/forums/p/8109/153392.aspx#153392

    Fair enough.  Thanks. 

    Computer programming skills is fast becoming the most sought-after skill in meteorologists.  If you can't program and you want a job as a meteorologist, you will have a hard time finding a job.  Currently, I am a PhD research student working on weather radar software.

    See, that's interesting.  Yesterday, I wrote some code to optimize lowest-bidder construction bids with performance constraints.  You got to work with hurricanes and shit.  Advantage, you.  I was actually completely unaware that there was such demand for programmers in meterology.  I guess this is really the future of programming: being a programmer and an expert in something else.  Reminds me of the book The Sparrow, but I digress...

    If you are referring to the attempt at doing an implicit conversion from 'int' to 'const char*', that is only because that is what you programmed.  A character pointer is the closest type to an int, which is what you passed.  If you are referring to the outputted error message showing the template stuff-- yeah, I never really liked that, but I have gotten used to it.  As for using the STL, because I tend to create general-purpose meteorology libraries, I find it best to utilize the STL as much as possible -- particularly for the interface to my libraries.

    I was referring to the deep magic going on behind the scenes in STL, but now that you mention it, C++'s coercion rules are a bit of a WTF in their own right. 

    Yes, matlab can do fast calculations, particularly if you take advantage of element-by-element math operations (as opposed to looping over each element).  However, when you are creating a complex numerical simulation of a tornado, and you need it done *fast*, Fortran (ugh!) or C/C++ is your choice.  The C hooks you are talking about is mexglx (i think).
     

    I assume if you're simulating a tornado or something, you're using some library to do your math.  Not knowing what kind of math, I could only guess (LAPACK? fftw? GSL? Some proprietary thing I've never heard of?).  Still, if you're using a library, I assume it's been optimized as much as MATLAB is.  If not, and you're writing it all from scratch whenever you need it, may I suggest switching to/writing a library?



  • @cvi said:

    @bstorer said:

    I entirely agree with you.  The whole undecidability thing came up because it's mentioned in the C++ FQA, and was quoted here.  I just think it reeks of bad design, like many things in the language. 

    Granted, C++ is far from perfect, but so far I've failed to find any suitable replacement. I've looked at (and tried) a bunch, e.g. Java/Scala, Python, Lua, Erlang, Haskell (briefly), ... While they all have their uses, they sometimes just get into my way (in particular, inline assembly is a bitch). And with C/C++ one can easily link against plenty of libraries out there without having to write all sorts of wrappers and stuff.

    So if anyone can suggest a good language for doing numerical simulations and stuff, I'm listening. :-) (And no, Fortran is not a valid suggestion.)

    Have you looked at "D"? It appears to be an object-oriented C relative with, among other things, the ability to link against C libraries.



  • @Carnildo said:

    @cvi said:
    @bstorer said:

    I entirely agree with you.  The whole undecidability thing came up because it's mentioned in the C++ FQA, and was quoted here.  I just think it reeks of bad design, like many things in the language.

    Granted, C++ is far from perfect, but so far I've failed to find any suitable replacement. I've looked at (and tried) a bunch, e.g. Java/Scala, Python, Lua, Erlang, Haskell (briefly), ... While they all have their uses, they sometimes just get into my way (in particular, inline assembly is a bitch). And with C/C++ one can easily link against plenty of libraries out there without having to write all sorts of wrappers and stuff.

    So if anyone can suggest a good language for doing numerical simulations and stuff, I'm listening. :-) (And no, Fortran is not a valid suggestion.)

    Have you looked at "D"? It appears to be an object-oriented C relative with, among other things, the ability to link against C libraries.

     

    There's also Objective-C.



  • @bstorer said:

    I assume if you're simulating a tornado or something, you're using some library to do your math.  Not knowing what kind of math, I could only guess (LAPACK? fftw? GSL? Some proprietary thing I've never heard of?).  Still, if you're using a library, I assume it's been optimized as much as MATLAB is.  If not, and you're writing it all from scratch whenever you need it, may I suggest switching to/writing a library?

     

    In the meteorology field, LAPACK is king.  As well as utilizing MPC (which I have not done myself).  While MatLab will be optimized in doing a particular set of calculations, only a compiled language can take advantage of various memory and processing optimizations.  Therefore, Fortran and C codes will be faster than anything MatLab can do.  I have even made C++ programs that performed as fast as their Fortran counterpart.



  • Objective C is nice (I have seen it used a few times, but not in meteorology).  I haven't heard of "D"... I will have to look it up.  I have been meaning to teach myself Python just for kicks.  The problem with utilizing any of these languages outside the realm of CS is that most other people in your field will have no clue what these languages are.  And if your program can not be understood by the student or fellow scientists that take up your project, it is doom to failure.



  • @bstorer said:

    See, that's interesting. Yesterday, I wrote some code to optimize lowest-bidder construction bids with performance constraints. You got to work with hurricanes and shit. Advantage, you. I was actually completely unaware that there was such demand for programmers in meterology. I guess this is really the future of programming: being a programmer and an expert in something else. Reminds me of the book The Sparrow, but I digress...

    Lots of places where you need to have programming skills. I study complex/dynamic systems (after having started out at physics), and currently I spend most of my time writing simulation stuff. Nothing as cool as hurricanes, but still. (Clouds and rain droplets are a recurring topic around here, though).

    @bstorer said:

    @Carnildo said:

    Have you looked at "D"? It appears to be an object-oriented C relative with, among other things, the ability to link against C libraries.
     

    There's also Objective-C.

    I've looked into D some time ago, and read some short info on Obj-C. Might give them another/a shot sometime.



  • @MPS said:

    You feel compelled to do the same thing in every thread where I post. What is different about this one?

    You still haven't read the thread, have you? (Hint: look at the thread's first page)

    I can't [i]help[/i] but being compelled to post in every thread you post in. You post in every goddamned one. Somehow, though, you seem to think I've been "compelled" even when I had already posted in a thread before you. And you claim [i]I[/i] have the big head. Retroactive compulsion, huh.

    On the other hand, this thread still isn't much different than the rest. You still haven't added anything of note. Par for the course with you.

    This is why I've been saying that making your stupidity obvious to all is a public service. The sooner people realize how dull-witted and disruptive you are, the sooner they'll stop replying to your disruptive comments. It has been working, too. If I see you acting retarded, I'll point it out for all to laugh. If you don't like it, stop acting retarded.

    Feel free to do the same to me. Indeed, I invite you to. You're going to have a much harder time at it than I am.



  • @WeatherGod said:

    Objective C is nice (I have seen it used a few times, but not in meteorology).  I haven't heard of "D"... I will have to look it up.  I have been meaning to teach myself Python just for kicks.  The problem with utilizing any of these languages outside the realm of CS is that most other people in your field will have no clue what these languages are.  And if your program can not be understood by the student or fellow scientists that take up your project, it is doom to failure.
     

    In your case, I get why you use C++.  You need a low level language, but you want strings and vectors.  If you switch to another language, everybody else is going to be bitter because they don't know it.  But Python is nice for the parts that aren't time critical, because it does all those things and plays nicely with C/C++.  Objective C is the same way, and it's far more similar to C, but not as fancy.

    I haven't used D, but I've read a bit about it, and I've only had good experiences with Digital Mars compilers (not that making compilers necessarily means they're capable of designing a language).  It does look nifty.  I'd be interested to see its performance.

    @cvi said:

    Lots of places where you need to have programming skills. I study complex/dynamic systems (after having started out at physics), and currently I spend most of my time writing simulation stuff. Nothing as cool as hurricanes, but still. (Clouds and rain droplets are a recurring topic around here, though).

    Why does everybody else's job sound cooler than mine?  Quick!  Somebody working on Generic Accounting Packing #1,238,113 post so I can feel better about myself at your expense!



  • @poopdeville said:

    @MPS said:
    You feel compelled to do the same thing in every thread where I post. What is different about this one?

    You still haven't read the thread, have you? (Hint: look at the thread's first page)

    I can't help but being compelled to post in every thread you post in. You post in every goddamned one. Somehow, though, you seem to think I've been "compelled" even when I had already posted in a thread before you. And you claim I have the big head. Retroactive compulsion, huh.

    On the other hand, this thread still isn't much different than the rest. You still haven't added anything of note. Par for the course with you.

    This is why I've been saying that making your stupidity obvious to all is a public service. The sooner people realize how dull-witted and disruptive you are, the sooner they'll stop replying to your disruptive comments. It has been working, too. If I see you acting retarded, I'll point it out for all to laugh. If you don't like it, stop acting retarded.

    Feel free to do the same to me. Indeed, I invite you to. You're going to have a much harder time at it than I am.

     

    Sorry, but your game is up. I am not a little slashdot troll that came here to try and ruin another forum.

    You, OTOH, are.

    http://forums.anti-slash.org/viewtopic.php?t=1425&highlight=

    http://slashdot.org/comments.pl?sid=180487&cid=14939679

    Go away little boy. Stop being a little nuisance.



  • @WeatherGod said:

    ...several replies about C++...

    Obviously I'm engaging in some hyperbole and no language is perfect, but C++ is still pretty bad.  If you don't have experience with other languages, you might not realize this.  Additionally, you'll notice I also felt the decidability argument -- while not over my head -- was pretty small potatoes.

     

    The stuff on cppreference.com is very basic.  Strings, streams and vectors.  Now I understand that your job may require you to write in C++ because it's standard for your industry or there are libraries you have to link against, but if given a choice I'd use something else.   If you need speed, use C.  The OOP aspects of C++ are so full of pitfalls that unless all of your classes are just simple containers for variables and functions, you are going to feel the pain.  Inheritence, object pointers, memory management, constructors and destructors, statics, initialization lists, templates and exceptions all conspire to make your life a living hell.  The Bible of C++ Hate is the C++ FQA (previously referenced here).  If your experience has not resulted into you running head-first into these problems, then I am happy for you.  Then again, you probably don't need to be using C++.

     

    A big problem with C++ is that it combines low-level and high-level programming.  It promises the abstraction of OOP with the performance of assembly.  Unfortunately, it frequently fails to deliver on both accounts.  If you aren't using the advanced OOP or meta-programming features of C++, you might consider just plain C or as somebody suggested, a scripting languages with C bindings so you can do assembly parts in assembly and the rest in something like perl, php or python.  Most modern scripting languages have great string, vector and hash/associative array performance.  The IO performance can sometimes hurt in scripting languages, but it's usually not terrible.  The math performance and feature set usually sucks, though.  You might want to write extensions in C/asm that handle these parts if you are doing calculation-intensive scientific apps.

     

    Additionally, if you are working on Linux (and I infer from your avatar that you are) then you will discover some really nasty interactions between strings, streams and the glibc IO functions.  It has to do with buffering that's being done automatically in C++ and by the glibc functions, which results in all kinds of thrashing.  You can fix it by turning off buffering in the glibc functions but that has other side effects that end up biting you in the ass.  I've spent many dozens of hours debugging IO issues in C++ on Linux, where the C++ code was actually significantly slower than identical perl, even including the start-up time for the perl parser.  Obviously C is the fastest choice for this.  C strings have overflow issues, but some simple tricks like using protected pages to kill the program in the event of overflow will take care of that.  This can usually be encapsulated in a macro or inline function for all string handling, keeping all of your buffers protected.  There are plenty of examples of these types of techniques in FOSS server apps written in C.  C++ is a lot better on Windows, but that's because Microsoft has taken care to sand off rough edges and define best practices that avoid some of the more common pitfalls.  It doesn't fix everything about the language, but it does make it a little more manageable.



  • @morbiuswilters said:

    C strings have overflow issues, but some simple tricks like using protected pages to kill the program in the event of overflow will take care of that.  This can usually be encapsulated in a macro or inline function for all string handling, keeping all of your buffers protected.  There are plenty of examples of these types of techniques in FOSS server apps written in C.
     

    Samba in particular has all sorts of magic so that even though you're using C, you can do a lot of the things you'd do in C++ in a fairly similar (or better) way.



  • @bstorer said:

    Samba in particular has all sorts of magic so that even though you're using C, you can do a lot of the things you'd do in C++ in a fairly similar (or better) way.

    Anything written by Daniel Bernstein will be an interesting study in writing secure code.  I'm not suggesting you use all of his methods, just that he tends to be very knowledgeable about security pitfalls in C.  He uses very little of the stdlib because of so many flaws in various implementations.  His code is usually uncommented and difficult to read, but if you are willing to take some time, you will learn some neat tricks for safely handling networking, memory and untrusted data.  He also has several good essays on these subjects.  I do not actually like the software that he writes though, as it is usually cranky, creaky and difficult to maintain.  Still, he knows his shit.



  • @morbiuswilters said:

    The stuff on cppreference.com is very basic.  Strings, streams and vectors.  Now I understand that your job may require you to write in C++ because it's standard for your industry or there are libraries you have to link against, but if given a choice I'd use something else.   If you need speed, use C.  The OOP aspects of C++ are so full of pitfalls that unless all of your classes are just simple containers for variables and functions, you are going to feel the pain.  Inheritence, object pointers, memory management, constructors and destructors, statics, initialization lists, templates and exceptions all conspire to make your life a living hell.  The Bible of C++ Hate is the C++ FQA (previously referenced here).  If your experience has not resulted into you running head-first into these problems, then I am happy for you.  Then again, you probably don't need to be using C++.

    I have never run into any problems with regards to pointers, memory management, etc because I have choosen C++ over C.  In addition, utilizes OOP really helps to modularize my code and make it easier for other people to understand.  I will admit that C++'s exception design is a POS, but that is about all I will yield.  I have no need to do template metaprogramming, so I don't care if that is a wtf.

    Additionally, if you are working on Linux (and I infer from your avatar that you are) then you will discover some really nasty interactions between strings, streams and the glibc IO functions.  It has to do with buffering that's being done automatically in C++ and by the glibc functions, which results in all kinds of thrashing.  You can fix it by turning off buffering in the glibc functions but that has other side effects that end up biting you in the ass.  I've spent many dozens of hours debugging IO issues in C++ on Linux, where the C++ code was actually significantly slower than identical perl, even including the start-up time for the perl parser.  Obviously C is the fastest choice for this.  C strings have overflow issues, but some simple tricks like using protected pages to kill the program in the event of overflow will take care of that.  This can usually be encapsulated in a macro or inline function for all string handling, keeping all of your buffers protected.  There are plenty of examples of these types of techniques in FOSS server apps written in C.  C++ is a lot better on Windows, but that's because Microsoft has taken care to sand off rough edges and define best practices that avoid some of the more common pitfalls.  It doesn't fix everything about the language, but it does make it a little more manageable.

     

    Again, this is another thing that I have never had a problem with.  As a matter of fact, I find using C++'s strings and streams much safer and also allows me to produce cleaner code because I don't have to worry about pointers and the likes.  Yes, there is a slight performance hit, and I also do like to use sprintf() and lament how C++ never made a string equivalent, but that isn't the main part of my work.  As for C++ being better on Windows, I have had more trouble there then on Linux.  Anyone recall the fiasco from Visual C++ (version 6.0, I believe?) where MS defined the .end() iterator of a container incorrectly and caused container objects passed through the DLL boundary to iterate pass the end?  At one company I worked at, the problems of VC++ 6.0 caused them to create, from scratch, their own implementation of STL.  Meanwhile, they were perfectly happy with gnu's implementation.



  • @WeatherGod said:

    In addition, utilizes OOP really helps to modularize my code and make it easier for other people to understand.

    So you're just using objects as collections of variables and functions, then?  You're not using a lot of inheritence, interfaces, event handling, virtuals, etc..?   Then you probably aren't going to run into most of those problems.   Read the FQA I linked to if you want more info, but it sounds like C++ is working for you.  For a lot of people it is a PITA, though, because they try to use the advanced OOP alongside the lower-level features inherited from C.  Things like the boost libs ease the pain, but only somewhat and at that point you're pratically doing Java anyway..

     

    @WeatherGod said:

    As a matter of fact, I find using C++'s strings and streams much safer and also allows me to produce cleaner code because I don't have to worry about pointers and the likes.

    I'm guessing you mean C strings?  C++ strings and streams are just objects and are any non-trivial program will probably have to pass around pointers to them.

     

    @WeatherGod said:

    Yes, there is a slight performance hit, and I also do like to use sprintf() and lament how C++ never made a string equivalent, but that isn't the main part of my work.

    Boost includes some string formatting stuff.  It's not 100% equivalent to sprintf but it's close enough.  Then again, if you are using C++ strings then performance of string parsing probably isn't that critical to you so you can just cast to and from a C string and use sprintf to your heart's content.  Easy to do in a safe manor.

     

    Other than that, it sounds like C++ works for you.  Like I said, YMMV, but I find it useless as do many people.  If I need speed I will use C and if I need OOP I will use Java, php, perl, python or whatever else.  A lot of CS grads were taught C++, though, so they don't know better and after using it for so long have a tendency to defend and work around its inadequacies without actually looking at alternatives.



  • @morbiuswilters said:

    @WeatherGod said:

    In addition, utilizes OOP really helps to modularize my code and make it easier for other people to understand.

    So you're just using objects as collections of variables and functions, then?  You're not using a lot of inheritence, interfaces, event handling, virtuals, etc..?   Then you probably aren't going to run into most of those problems.   Read the FQA I linked to if you want more info, but it sounds like C++ is working for you.  For a lot of people it is a PITA, though, because they try to use the advanced OOP alongside the lower-level features inherited from C.  Things like the boost libs ease the pain, but only somewhat and at that point you're pratically doing Java anyway..

    For the most part, yeah.  I do a little bit of inheritence and I also create interfaces to various data sources that my program uses.  As for event handling... because my programs are mainly for command-line computational and data processing, I have no need to do event handling.  The most I have done event handling is when I used Qt's graphical library.  I use virtuals in the little bit of inheritance that I do, and it really makes my life easier.  I do find Boost to be a bit excessive, but their RegEx module is very nice (especially compared to C's regex functions).  I got great performance out of it and I was able to use Perl's regex syntax which some of my professors at the time were used to. 

     

    @WeatherGod said:

    As a matter of fact, I find using C++'s strings and streams much safer and also allows me to produce cleaner code because I don't have to worry about pointers and the likes.

    I'm guessing you mean C strings?  C++ strings and streams are just objects and are any non-trivial program will probably have to pass around pointers to them.

     

    No, I mean C++ strings.  Because I don't have to deal with allocation and null termination for each and every string I make and use, it is much safer.  I am more likely to make a mistake when dealing with string pointers.  And non-trivial programs can also utilize references, which is typically what the programmer really wants rather than the pointer.

     

    A lot of CS grads were taught C++, though, so they don't know better and after using it for so long have a tendency to defend and work around its inadequacies without actually looking at alternatives.

    I have seen similar behavior in my field with a language called GrADS.  I have had professors and students think that it is the most wonderful thing since sliced bread -- only because it is the second thing they learned after Fortran.  It is difficult get people to understand there are other languages out there that can perform well.  Keep in mind that most people in my field were only taught Fortran and BASIC.  To them, C is the next generation language.  It is hard enough to get them to see anything beyond that. 



  • @WeatherGod said:

    I use virtuals in the little bit of inheritance that I do, and it really makes my life easier.

    C++'s virtual classes are one of the banes of my existence.  There's a whole new set of rules when you bring in virtual functions.

    @WeatherGod said:

    Keep in mind that most people in my field were only taught Fortran and BASIC.  To them, C is the next generation language.
     

    That is so terribly, terribly sad.



  • @WeatherGod said:

    No, I mean C++ strings.  Because I don't have to deal with allocation and null termination for each and every string I make and use, it is much safer.  I am more likely to make a mistake when dealing with string pointers.  And non-trivial programs can also utilize references, which is typically what the programmer really wants rather than the pointer.

    Since you aren't writing business software, you don't really need to worry that much about untrusted data and security, I would think.  That's the biggest pain with C strings, but you can resolve it easily with the tricks I mentioned above.  True, it's a workaround, but you gain the benefit of speed.  C++ strings aren't much faster (and can actually be slower) than string manipulation in perl, but properly-done C strings blows them all away.

     

    Still, it sounds like C++ is working fine for you, which is great, but you aren't using the features that give people fits.  From my perspective, I will avoid C++ like the plague.  Good luck with your programming, though.  It sounds like you've mastered the pragmatic part of "it just works for me" which a lot of CS grads never seem to get.  That's why you have endless religious wars over which language is better. 



  • @cvi said:

    @bstorer said:

    I entirely agree with you.  The whole undecidability thing came up because it's mentioned in the C++ FQA, and was quoted here.  I just think it reeks of bad design, like many things in the language. 

    Granted, C++ is far from perfect, but so far I've failed to find any suitable replacement. I've looked at (and tried) a bunch, e.g. Java/Scala, Python, Lua, Erlang, Haskell (briefly), ... While they all have their uses, they sometimes just get into my way (in particular, inline assembly is a bitch). And with C/C++ one can easily link against plenty of libraries out there without having to write all sorts of wrappers and stuff.

    So if anyone can suggest a good language for doing numerical simulations and stuff, I'm listening. :-) (And no, Fortran is not a valid suggestion.)

     

     

    Eisel. 



  •  @bstorer said:

    @WeatherGod said:

    I use virtuals in the little bit of inheritance that I do, and it really makes my life easier.

    C++'s virtual classes are one of the banes of my existence.  There's a whole new set of rules when you bring in virtual functions.

    @WeatherGod said:

    Keep in mind that most people in my field were only taught Fortran and BASIC.  To them, C is the next generation language.
     

    That is so terribly, terribly sad.

     i learned basic on an atari in the 80s, and my first school experience with programming was fortran. it was either that or pascal, and i really didn't want to interface with macintoshes that badly. the next year they offered C, (or maybe C++), but i had decided that programming wasn't my life's work. I dabble in .net and i know a bit of java, c++, and a couple of other worthless languages. But sometimes, when there's no one around, i write really tight basic code, and convert it to C, and compile that. Good times :-)



  • @GeneWitch said:

    But sometimes, when there's no one around, i write really tight basic code, and convert it to C, and compile that. Good times :-)
     

    Bothering to write tight BASIC?  Now that's sick. 


Log in to reply