On the evolution of programming style: How far C++ has moved from its C roots

http://blog.feabhas.com/2012/03/on-the-evolution-of-programming-style/

by ehamberg • 14 years ago

98 71 14 years ago

blog.feabhas.com

Impossible• 14 years ago

It's interesting that with a modern C++ compiler all of these programs are equally valid. This is both the biggest strength and the biggest flaw of C++.

I imagine the size differences are overhead from bringing in STL and maybe template instantiation and are relatively fixed? I would have liked to see performance benchmarks as well as executable size to see if the program has gotten slower, faster, or remained basically the same.

JoachimSchipper2• 14 years ago

Templates typically expand to one chunk of code per type handled, so no, executable size does expand if you use a lot of them.

(A C++ fan would counter that they are faster than pointer-based generic algorithms like C's qsort and that you'd get the same code size manually typing it out.)

ajax775• 14 years ago

Whether or not you are a C++ fan, templatized algorithms ARE often faster than their C-based, generic counterparts. Any decent C++ compiler should be able to inline generic code while C often relies on function pointers. I'm not saying this is always the case, but often. std::sort beating qsort is a typical argument, though I'm not sure the two algorithms are equivalent excepting language-specific constructs (http://stackoverflow.com/questions/4708105/performance-of-qs...)

As for size, you're absolutely right, though for many scenarios that appears to be less and less a pressing concern. Perhaps the biggest drawback is compilation time.

greyfade• 14 years ago

No, the majority of that overhead is from the use of `iostream`s (which are known to be pretty bloated compared to `printf` and friends), the use of exceptions (try/catch is a morass of stack-unwinding code), and the added bloat of class information (RTTI and symbols in particular).

If it were compiled with full optimizations and the final binaries stripped, they'd be much closer in size. Moreso if exceptions are disabled or if the class is replaced with a simple function taking/returning tuples.

alextgordon3• 14 years ago

Not only is iostream bloated, but it often injects a static constructor into every translation unit (which visibly angers the – usually calm – LLVM style guide[1]). Oh and it's really godawfully slow unless you turn off a magic flag somewhere[2].

Friends don't let friends use iostream.

[1] http://llvm.org/docs/CodingStandards.html#ll_iostream

[2] http://stackoverflow.com/questions/9371238/why-is-reading-li...

Suncho• 14 years ago

There's a huge difference between using exceptions and littering your code with a bunch of try/catch blocks. When exceptions are used properly, you see very little error handling code.

alextgordon3• 14 years ago

Let me give one other way of doing it: "C++ without classes"

    std::pair<double, double> findRoot(double a, double b, double c) {
        if (a == 0.0)
            throw std::invalid_argument("a has value 0.0!");
    
        double root1 = (-b + sqrt(b*b - 4*a*c)) / (2*a);
        double root2 = (-b - sqrt(b*b - 4*a*c)) / (2*a);
    
        return std::pair<double, double>(root1, root2);
    }

It seems too many C++ programmers see a problem and think "Hey, let's use classes!".

matthavener• 14 years ago

Reminds me of one of my favorite all time John Carmack tweets:

"Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function."

https://twitter.com/#!/ID_AA_Carmack/status/5351230045120102...

marshray3• 14 years ago

Exactly. The function is perhaps the most powerful and useful abstraction in all of computer science.

I always found it absurd that some languages force you to write "Math.cos(...)".

colomon• 14 years ago

Ha! I was going to post a Perl 6 version of this to show how much shorter it is when you don't go through all the rigamarole, but of course you remind us that it's that short in C++ if you do it in a sensible manner. Bravo.

alexchamberlain2• 14 years ago

What's std::pair if it isn't a class?

alextgordon3• 14 years ago

There's nothing inherently wrong with classes. I use classes occasionally. But if you don't need to use one for everything. C++ isn't Java.

ajross8• 14 years ago

Surely alextgordon's point was that defining a solution in terms of a class where a function was more appropriate was bad, not that use of existing abstract types is to be avoided.

YogSothoth2• 14 years ago

a struct ;-) ... http://www.cplusplus.com/reference/std/utility/pair/

dxbydt• 14 years ago

if you are comfortable with returning tuples, perhaps the inputs should be a tuple as well...

     def findRoot(p:(Double,Double,Double)) = {
       assert(p._1 != 0)
       val n = sqrt(p._2*p._2-4*p._1*p._3)
       val d = 2*p._1
       ( (-p._2+n)/d, (-p._2-n)/d )
     }
      ----
      scala> findRoot((6,-6,-36))
      res0: (Double, Double) = (3.0,-2.0)

ajross8• 14 years ago

Not sure how we got to Scala, but in (non-varargs) C linkage the whole metaphor of "funtion arguments" is inherently a "tuple" to begin with. They only exist in tandem with each other, never in isolation. There's no real value I can see to trying to double-abstract it.

nooop• 14 years ago

> if you are comfortable with returning tuples, perhaps the inputs should be a tuple as well...

why should they?

YogSothoth2• 14 years ago

I'm with you alex, I tend to only use classes when I've got to maintain state, I just use a function otherwise. Here's how I'd likely code this ...

  #include <iostream>
  #include <string>
  #include <cmath>
  
  using std::string;
  using std::cout;
  using std::endl;
  
  static bool findRoots(
     double a,
     double b,
     double c,
     double &rootOne,
     double &rootTwo,
     string &errMsg
  )
  {
     if(a == 0.0)
     {
        errMsg = "Parameter 'a' cannot be zero";
        return(false);
     }
  
     double discriminant = b * b - 4 * a * c;
  
     if(discriminant < 0.0)
     {
        errMsg = "Discriminant cannot be less than zero";
        return(false);
     }
  
     double dSqrt = sqrt(discriminant);
     double twoA  = 2 * a;
  
     rootOne = (-b + dSqrt) / twoA;
     rootTwo = (-b - dSqrt) / twoA;
  
     return(true);
  }
  
  int main()
  {
     double a[] = { 0.0, 2.0, 2.0 };
     double b[] = { 1.0, 3.0, 1.0 };
     double c[] = { 2.0, 2.0, 0.0 };
  
     double rootOne;
     double rootTwo;
     string errMsg;
  
     for(int n = sizeof(a) / sizeof(a[0]), i = 0; i < n; i ++)
     {
        cout << "a: " << a[i] << ", b: " << b[i] << ", c: " << c[i] << endl;
  
        if(findRoots(a[i], b[i], c[i], rootOne, rootTwo, errMsg))
        {
           cout << rootOne << " " << rootTwo << endl;
        }
        else
        {
           cout << errMsg << endl;
        }
  
        cout << endl;
     }
  
     return(0);
  }

VMG• 14 years ago

thank you for your answer, but next time better use something like http://gist.github.com

alexk73• 14 years ago

This is even more C++11-ish: (Not tested, my compiler at work is not C++11 compliant.)

    constexpr tuple<double, double> Roots(double a, double b, double c)
    {
        return (a == 0.0) ? throw invalid_argument("a has value 0.0!") :
            tuple<double, double>{
                (-b + (sqrt((b * b) - 4 * a * c))) / 2*a,
                (-b - (sqrt((b * b) - 4 * a * c))) / 2*a
            };
    }

jsnell• 14 years ago

That's just horrible. The readability of the function has been totally destroyed by conditional operator. What's the imaginary C++11-ish benefit?

hythloday4• 14 years ago

  return /* ... */ throw invalid_argument("");

really valid C++11?

dalke3• 14 years ago

The linked page say "The typical C solution is to create a structure to hold the quadratic equation parameters." That seems like sticking 'C with classes' into something which doesn't need classes in the first place. Why wouldn't the standard solution for C use pointers to pass the return parameters? Something like:

    #include <math.h>
    #include <errno.h>
    int findRoot(double a, double b, double c, double *root1, double *root2) {
        double discriminant, q;
        if (a == 0.0) {
            return EDOM;
        }
        discriminant = b*b-4*a*c;
        if (discriminant < 0) {
            return EDOM;
        }
        q = -(b+copysign(sqrt(discriminant), b)) / 2;
        *root1 = q/a;
        *root2 = c/q;
        return 0;
    }

This style is quite in line with a number of math packages I've used in C. Since the author used a numerically unstable solution, I suspect there's a lack of domain inexperience in what library users expect from a math package. Eg., why would I go through the overhead of copying my input parameters to a temporary struct when I could just pass them directly to the function?

ansgri• 14 years ago

Make it a template (parameterized with coefficient and solution type) and you'll get very generic and efficient solution across all mentioned 'dialects' of c(++). It has the added bonus that this routine can be converted to vector form almost without breaking the interface: just make a, b, c pointers and specify length. And you can specialize templates when you'll want to rewrite float32_t-version in assembly.

Numeric code is really inappropriate for demonstration of new C++ features, as good (fast!) numeric code is most often C with templates.

naner• 14 years ago

It seems too many C++ programmers see a problem and think "Hey, let's use classes!".

That's usually a result of people coming from Java doing C++ work.

eps• 14 years ago

That's usually a result of people erroneously thinking of themselves as C++ experts.

cbsmith• 14 years ago

Honestly, given the problem context, a function is obviously the way to go. There isn't enough other context to give you a guideline for having an object model.

In a larger context, you might want to actually have an object/struct that represents a quadratic equation. The weird thing though was having an object for a quadratic equation and not having another object for its root (or more likely, either have a binomial class or just one generic polynomial class). I'm trying to think of a context where that makes any sense at all... and not finding it.

ajross8• 14 years ago

The subject matter is interesting enough. But if it's a discussion on style, why is the code presented so unbelievably bad?

Needless duplication of code; simple one-line declarations (i.e. a struct with three doubles) spread out over 5; empty constructors with trivial initializer lists defined outside the class header; needless empty destructors defined (again, outside the class declaration) for classes without virtual functions; "} else {" spread out across three lines (pet peeve of mine).

The disaster of an Error enumerant deserves a paragraph all by itself. It's got only two values, "OK" and "FAIL". Guess which one evaluates to boolean truth? (And yes, I'm aware of how errno and the like work -- but error codes tend to be something other than "FAIL").

This looks like code generated by an IT employee at a local soap manufacturing company, not something to be seriously considered by people interested in C++ evolution.

hythloday4• 14 years ago

Guess which one evaluates to boolean truth?

The one that is an error?

ajross8• 14 years ago

No. If there is more than one error condition that needs to be handled by the caller, then sure. Enumerate them and provide a "SUCCESS" value. But if you are seriously arguing that "enum { OK, FAIL };" is good code, I weep.

edit to avoid stringy flame thread: but it's a discussion on STYLE. If this was an example of how to write an error API, I wouldn't care (I probably wouldn't read it either). But it's a discussion about how C/C++ is written by presumably talented authors, and by inference how other people should write code. And the code sucks, sorry. And I'm horrified at your identification of dead code and needless whitespace as "syntactic fluff" not worthy of consideration as an important part of style.

mseebach2• 14 years ago

> This looks like code generated by an IT employee at a local soap manufacturing company

Too bad you go and ruin a perfectly reasonable comment with that crap.

ajross8• 14 years ago

Which moral calculus allows you to call someone else's work "crap", where I can't cast aspersions on the quality of technology adoption in the soap manufacturing industry?

michaelhoffman• 14 years ago

I know the point is to discuss style, but I wish he had done it in a way that didn't include a textbook example of floating point programming that can yield inaccurate results. An accurate way wouldn't be so difficult:

http://en.wikipedia.org/wiki/Quadratic_equation#Floating_poi...

ajax775• 14 years ago

It should be noted, it's very clear his executable sizes are for a Debug compilation. I tossed the same code for the final example into VC10, and sure enough in release mode the compiled size is 10KB, and in debug it's just less than the size he stated. This is for 64-bit.

I'm not sure what point it serves to compare debug mode executable sizes, but that should be clearly stated in the article. As other people stated, the final example really ought to lose the wrapping class in the spirit of C++11 brevity and functional decomposition.

malkia• 14 years ago

Pointless... Because at the time you want to suck out performance of any of those, you would have to stick your guns to the provided macros or inline functions from Intel, ARM, IBM (PowerPC/AltiVec), etc. - and reimplement this using them - SSE2, AVX, whatever.

This is not even funny....

And packing three doubles in structures - good programming technique? Okay.. That's enough (it might be good sometimes, but not always)

bfrog• 14 years ago

I think the overusage of classes is directly related to schools teaching Java instead of C or lisp or... well anything else.

KonradKlause• 14 years ago

Looks like the author of the C solution has never written a lot of C, but too much C++. ;-D

cheez• 14 years ago

This is a dumb example. Should have used a root finder. C sucks with those.

azth2• 14 years ago

Page not found :/ Does anyone have a cache of the article's text?

atesti2• 14 years ago

Here you go, courtesy of bing cache: http://pastehtml.com/view/bswjqr9ry.html

azth2• 14 years ago

Thanks! :)

On the evolution of programming style: How far C++ has moved from its C roots

Related Stories