
C++ in Coders at Work - pmarin
http://gigamonkeys.wordpress.com/2009/10/16/coders-c-plus-plus/
======
Maro
All this C++ hatred is weird.

If you need to do systems level programming (eg. write a database), and you
want to go beyond C's code organization capabilities, and you can select a
sensible subset of C++, it's a great language, and you get to control all
aspects of memory and CPU.

We're writing our database(s) in C++, and we're pretty much loving every
minute of it, and would not switch to C, Java, Erlang or whatever.

Of course we're a startup, so we got to select our own subset, write our own
containers, etc:

<http://github.com/scalien/scaliendb>

One downside is it's hard to find good C/C++ programmers on the market. The
vast majority of applicants cannot complete our first interview filter
(removing a characters from a C string and writing an instrusive stack in
C++):

<http://scalien.com/pdf/job.pdf>

~~~
suraj
Looking at your code a bit, it seems you are not using templates, operator
overloading, exceptions, STL or std::string. Your test framework also looks
custom built (aside: IMO UnitTest++ would have fit you style). I think if you
just changed class data to structure and member functions to accept structure
pointer, you would get a nice C representation (almost every class I looked at
had an Init method). In effect you are using C++ to avoid very small
boilerplate code in equivalent C program.

No wonder you find C++ pleasurable, you are using it as C with classes!
However, if you are working on an existing code base with mix of STL, boost
and bunch of other libraries, you would start feeling pain of using C++. In my
experience, every library author uses a different subset of C++ and as an
application writer, you often have to grapple with the glaringly different
idoms in your program. I find boost pleasurable to use; however looking at
boost source is enough to melt my mind.

Almost everywhere C++ (language and libraries) try to satisfy every corner
case and sacrifice usability of common case. e. g. STL iterators (at least I
have BOOST_FOREACH to soften them). Ah well this is probably contributing very
little to the discussion but I feel better now :) So let me redirect to [C++
FQA](<http://yosefk.com/c++fqa/>) and let yourself decide whether the points
in FQA make sense to you.

~~~
Maro
We do use templates in our containers:

[https://github.com/scalien/scaliendb/tree/master/src/System/...](https://github.com/scalien/scaliendb/tree/master/src/System/Containers)

Yes, we try to avoid op.overloading, exceptions, and we explicitly don't use
the STL, Boost, <any library>. All the code is ours, which is really nice if
you're debugging, finding performance problems, etc. It was our experience on
previous projects that pulling in outside libraries in a systems level project
like a database ends up wasting time (spent in understanding, debugging and
optimizing outside code) over just writing what you need. This has proven to
be a good call, we fix all bugs, however deep or nasty very quickly.

Thanks for the UnitTest++ tip.

~~~
JoeAltmaier
Folks might accuse you of NIH, but the quality of outside libraries is
variable, suitable for a prototype but for shipping code you need control of
ALL of it.

~~~
dkersten
C++ Standard Library and Boost are of very high quality. It's quite tough to
beat them.

~~~
dkarl
Plus they're open-source, so they're theoretically "yours" in the sense that
you can compile and deploy your own. If you find a bug in Boost, you can fix
it. We frequently deploy open-source libraries we've patched ourselves --
never Boost that I know of, but at least we know it wouldn't be a problem.

~~~
dkersten
Similarly, you can extend them (or at least make your own code compatible).

------
adrianN
I'm currently implementing a complicated algorithm in C++. I don't have to use
many language features for that, so I don't have a strong oppinion about them.

But what I can say is that, compared to Java, the tools for C++ coding suck.
Hard. In Eclipse you can write some gibberish and it automatically turns it
into valid Java that mostly does what you want. The Java debugger is excellent
and works without hickups. The experience you have with Eclipse and CDT just
isn't the same. No automatic inclusion of header files, autocompletion doesn't
always do what you want, no documentation included, even for the STL. Working
with gdb is painful, most of the time it is not possible to properly inspect
datastructures in memory and it is generally just easier to litter the code
with print statements.

~~~
srean

      In Eclipse you can write some gibberish and it automatically turns
      it into valid Java that mostly does what you want.
    

Isn't this the reason that many treat java programmers as suspect ? I think
IDEs are fine once you have mastered the language and the syntax, but it often
masks the gaps and deficiencies in one's own knowledge. I find that a bit
scary.

I understand that mine would be a minority view. Guess work at the IDE
together with TDD has significant fan following. Apparently it gets the job
done, if that be so, who am I to complain.

Edit: It seems I have hurt someone's ego :|

~~~
barrkel
No, I don't think this is a valid reason - in fact, I think it's a prejudice
which disguises an ignorance of why languages with productive IDEs are so
good.

An IDE with code completion means you can get more done without having to
waste time studying API docs; in fact, the IDE's editor can itself become the
most efficient doc lookup tool. This gives you more time and attention space
to point at your problem domain, rather than mere incidental details.

Object orientation with static typing is a big contributor to this, because
you start out with what you want to act on - the noun, which is usually a
local variable or field - and get completion on the actions available on that
noun. The contrast with functional and procedural styles is stark: there, you
need to know the symbolic name of what you want to do to something you already
have in hand, but editor completion is almost powerless to help you, because
of the order of tokens in the syntax.

~~~
swift
Statically typed "pure" functional languages have somewhat different tradeoffs
when it comes to looking up functions; the style of code completion common in
OO languages doesn't work, but because the type of a function encodes so much
more meaning about what the function does, you are often able to find the
function you are looking for just by giving its type to a tool like Haskell's
Hoogle. This is less automatic, but it enables you to search a large array of
libraries simultaneously, which is very helpful when you don't know what
library contains the function in question!

~~~
eru
Yes. And there's no reason you couldn't integrate Hoogle in your editor.

------
fossuser
That's interesting to me that so many people dislike C++. I prefer it to Java
(which I find extremely verbose), don't think its features are really that
complex and like its speed. I think it's a powerful object orientated
statically typed language.

It seems when compared to other statically typed languages (it doesn't really
make sense to compare with dynamically typed languages) C++ does a good job.
The STL prevents you from having to reimplement many things you might
otherwise need in C and the syntax is more natural or intuitive when compared
with C as well.

I have a feeling people just prefer what they're familiar with and make
sweeping generalizations or exaggerated claims about other languages and
technologies.

~~~
cageface
A lot of C++ bias lingers from the days when compiler support for more
sophisticated features like templates was very immature and buggy. C++ is much
more pleasant to code in now than it was when I first used it in 1997. I
certainly wouldn't want to write a webapp in C++, but for anything that
requires speed and direct control of memory C++ is still really the only game
in town and I quite enjoy it when it's the right tool for the job.

People describe Objective-C as "c with objects" done the right way but I'd
much rather code in C++ than Objective-C. I also don't really understand why
people say they prefer to write in pure C, at least not in 2011. Hacking
together a homegrown OO system in C with structs and function pointers and
macros doesn't sound any easier or simpler to me.

~~~
rubashov
> wouldn't want to write a webapp in C++

Actually, POCO has all the stuff you need to write a web-app: templating, form
handling, http request/reponse objects, etc. Not that I've done it, but it
looks like you could write a web-app using POCO::Net rather painlessly.

I like C++ and don't understand the frustration others express. I don't use a
subset, and neither do the other people I work with. We use pretty much the
whole thing, TMP, macros and all.

Being well familiar with C++ I can never see a clear reason to prefer
something like Java. Qt is better for GUI stuff. POCO is just as good, or
better, for network stuff. With C++ you can go ahead and marry the host
platform's system calls when that makes sense (i.e. write a unix program).

When it comes to scientific or graphics type libraries it seems like the
premier solution usually has a first class C++ interface. The Java equivalents
seem harder to evaluate. I did a bunch of GIS stuff recently, using proj.4 and
various other things. It sure appears to me that the Java/C# equivalents of
the GIS type libraries are less supported and less popular ports of the C++/C
ones.

If you have perl/python and C++ in your tool belt, I just don't see the need
to reach for the so-called C++ replacements. Aside from hiring considerations,
that is.

~~~
cageface
_Being well familiar with C++ I can never see a clear reason to prefer
something like Java._

I also much prefer C++ as a language but garbage collection is such a huge
productivity win that I'll always use a GC'd language if it's appropriate. No
matter how cleverly you abstract manual memory management away in C++ it's
still a real chore and a source of bugs.

------
stelfer
Man I am tired of hearing what Zawinski thought about C++ fifteen freaking
years ago. If you're good at C++, use it. If not, don't. If you want to get
good at it, practice. How is that different from any language?

------
jmspring
One thing to remember, especially when considering the discussion of C++ at
Netscape, it took awhile for most compilers to implement a consistent set of
the C++ features. Netscape was being built across a dozen or so platforms and
this was a major concern. If you have built Mozilla recently, the process to
do so is not a couple of click action it is somewhat involved. It was worse
way back when.

I've used C++ at the last for companies I have been involved with. The only
consistency has been that no place used the same subset of C++ features. It
usually boils down to what subset the team members are comfortable with.
Variations have included exceptions or not, whether or not to use multiple
inheritance, STL or Boost (yes, boost isn't really part of the C++ standard,
but things like shared ptrs are in TR1), whether or not to use TR1, etc.

I personally don't have a strong opinion, but there are people that abuse C++
in ways that produce lousy code -- classes as a way to have nearly global
variables, the whole C with classes approach, etc.

You really should use the right language for what you are working on and that
plays well with any libraries you may want to use.

~~~
cpeterso
For curious folks, here is Mozilla's C++ Portability Guide (last updated July
2010, so it is still pretty recent). It is _not_ a style guide. It contains
some good lessons about writing portable code for "25 different machines and
at least a dozen different C++ compilers."

[https://developer.mozilla.org/index.php?title=en/C%2B%2B_Por...](https://developer.mozilla.org/index.php?title=en/C%2B%2B_Portability_Guide)

------
cletus
The real shame about C++ is that it's the only mass market C-level language
with advanced features built on top of it. Don't get me wrong: I agree with
the author and his interviewees. I think C++ is a horrible language for the
very reasons described: everyone uses a different subset of it and it's
_hideously_ complicated.

For a more current view, see Linus Torvalds' comments [1] [2].

What I would like to see is a language very much like C (being low-level) with
a _few_ features built on top. What those features are I guess is the real
trick.

One thing I like about C++ is the constructor/destructor mechanism. It's very
explicit. The trend now is towards garbage collection (which, admittedly, you
can implement in C++). This is a trend I largely agree with. It's quicker and
cheaper to write software that way (IMHO). But there is still a place for
simper schemes as all GCs I've come across have issues.

One thing I think such a language _shouldn't_ be is object-oriented. To quote
Joel Spolsky [3]:

> A lot of us thought in the 1990s that the big battle would be between
> procedural and object oriented programming, and we thought that object
> oriented programming would provide a big boost in programmer productivity. I
> thought that, too. Some people still think that. It turns out we were wrong.
> Object oriented programming is handy dandy, but it's not really the
> productivity booster that was promised.

Or at least such objects should be very limited in scope. Linus addresses some
of the reasons for this, such as knowing which function is being called by
simply looking at a code snippet (typically a patch in his case).

When writing low-level code I certainly do _much_ prefer C over C++. But
having the tools to build automatic reference counting into C would be really
nice at times.

[1]: [http://thread.gmane.org/gmane.comp.version-
control.git/57643...](http://thread.gmane.org/gmane.comp.version-
control.git/57643/focus=57918)

[2]:
[http://www.realworldtech.com/forums/index.cfm?action=detail&...](http://www.realworldtech.com/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2)

[3]: <http://www.joelonsoftware.com/articles/APIWar.html>

~~~
barrkel
I strongly reject the idea that object orientation hasn't provided a big boost
to programmer productivity. In my view, it's enabled building systems that are
orders of magnitude larger and more complex because of the discipline it
enforces in modularity and the discoverability it lends to APIs.

I mean, do you remember the C written in the 80s? Often, the only unit of
modularity in common use was the translation unit, with static globals used
freely, structures with no visibility protection, having their inner guts
manipulated by different modules, frequently by manually tweaking the pointers
etc.? If you had an API that protected structural guts, you were almost always
essentially programming to an object oriented style, only with no help from
the language and compiler.

~~~
jon_hendry
I think a lot of the benefits of OO reuse have been lost due to platform
shifts. If you build a system on NeXTSTEP in the early 90s, then throw it out
and switch to Java, then throw it out and switch to C#, you're naturally going
to lose a lot of the efficiencies you theoretically could have taken advantage
of had you somehow managed to stay on NeXTSTEP or OpenStep all along.

And then, of course, you have mergers and acquisitions leading to code being
thrown away or warehoused or merged with other systems, or new management
deciding to start from scratch.

Basically, the industry doesn't really have a long enough attention span to
really make the most of OO code reuse.

~~~
barrkel
People have long talked about how OO failed to generate code reuse, but I
don't understand how they do it with a straight face. You reuse _masses_ of OO
code every time you write a non-trivial program using a modern standard
library.

I think the people making this criticism are looking in the wrong place for
the reuse, and / or had weird ideas of what could be reused, and how it could
be reused, to begin with.

The reuse that OO gives us comes from raising the level of abstraction with
which the program is written, in particular because runtime libraries are so
much larger ("batteries included", etc.). The hierarchical namespaces and
encapsulated structure of modern class libraries reduces their cognitive
overhead. For example, in .NET, you can work with WebRequest, TcpClient or
Socket, depending on what level of control you need; and the conventions for
working with these things are pretty uniform across the board. Larger
applications are self-similarly written at a higher level, reusing code
_within themselves_ in a framework-like way.

But the people who thought there was going to be some kind of central library
of domain-specific classes in your company, that you would reuse in multiple
disparate applications, I think that was always fairly naive; reuse implies
coupling, and coupling of things that are individually subject to change in
ways that affects their users is fraught with problems, and always has been.

The best candidates for reuse aren't usually representations of the domain
concepts that are central to a business, because each application in the
business will probably be wanting to do something quite unique with those
domain classes. Rather, it's concepts that are self-contained, universal, not
likely to change much over time nor need different intrinsic behaviour from
application to application, which are best suited to reuse.

~~~
Stormbringer
The biggest problem with OO is the abuses. I recently worked with a large
codebase where /none/ of the behaviour for objects was in the objects
themselves. Some Architect had come along and beaten it out of them with an
extreme application of the 'too many patterns' anti-pattern.

One way they justify this is to 'reduce coupling', and so your comment about
coupling tripped a red flag for me. Whenever I want to take the piss out of an
Architect I just tell them that we should 'add an extra layer of indirection'
to the design. 99% of the time they agree without realising that I'm
satirising them.

~~~
dkersten
" _where /none/ of the behaviour for objects was in the objects themselves_ "

Actually, this could be a good thing, depending on what the goals were. For
example, _non-member non-friend classes are often more OO than putting
everything into the class_ [1]. Furthermore, if you want to use function
overloading for multiple dispatch, the keeping the functions separate from the
objects is also useful. If your system is highly concurrent, keeping the code
and data separate can be quite helpful. Also keeping data in structure-of-
arrays form and using external functions to operate on these arrays can make
huge differences in terms of cache usage, potential parallelism and
vectorization of instructions.

Coupling _might_ be a reason to do this, but its certainly not the first
reason I think of. There are plenty of better reasons (and as always, not all
reasons apply to all codebases).

TL;DR: There are lots of reasons why doing this could be a good thing.

(fwiw, I like to do this with my core data structures because I believe code
and data should be kept separate (and that data is the more important of the
two). I _do_ like to provide _normal_ objects as an API though, because I
often feel that its a natural interface, but the internals of my code are
rarely very OO in the C++/Java sense).

[1] <http://www.gotw.ca/gotw/084.htm>

------
js2
_There is some decent code in Doom Classic, but it is all C, and I would
prefer to do new game development in (restrained) C++_

…

 _I had been harboring some suspicions that our big codebases might benefit
from the application of some more of the various “modern” C++ design patterns,
despite seeing other large game codebases suffer under them. I have since
recanted that suspicion._

[http://bethblog.com/index.php/2010/10/29/john-carmack-
discus...](http://bethblog.com/index.php/2010/10/29/john-carmack-discusses-
rage-on-iphoneipadipod-touch/)

------
freedrull
There are subsets of C++ that I just find too useful to pass up, particularly
STL data structures like strings and vectors. Why shouldn't I use them? I'm
just going to have to keep using them until I "blow my whole leg off" as they
say.

~~~
prog
I have to agree. I like STL + Boost a lot. I hope to try glib + C sometime.
From what I see, that might allow me to C and still meet standard application
needs.

~~~
freedrull
Good point, glib offers a ton of useful functions:
[http://library.gnome.org/devel/glib/2.6/glib-String-
Utility-...](http://library.gnome.org/devel/glib/2.6/glib-String-Utility-
Functions.html)

As you can see, its no std::string, but it can still save you some time.

------
martijn_himself
Interesting article. I do not have much experience in C++ but I am learning
Objective-C. Do any of the sentiments mentioned in the article carry over to
Objective-C? Or is that comparing apples and oranges? Is Objective-C a better
extension/ superset (whatever the formal name) to C?

~~~
pmjordan
Objective-C and C++ are _very_ different apart from their C ancestry. C++
doesn't make an especially good Obj-C replacement, and Obj-C is probably no
better at the situations where C++ excels than raw C. Objective-C is a higher-
level, dynamic-ish, highly-OO extension to C. (great for GUIs, not so great
for writing drivers) C++ is quite low level, not dynamic at all, and not
overly OO. C++ _is_ very expressive in many situations due to its generic and
automatic resource management features, which Obj-C lacks completely. (GUI
code is typically horrendous, driver writing is nicer than in C)

~~~
jimbokun
"(great for GUIs, not so great for writing drivers)"

Probably the most succinct description of the relative strengths of Objective
C and C++. Objective C for GUIs, C++ for drivers and embedded development.

~~~
bonch
NeXTStep drivers were written in Objective-C using a framework called
DriverKit, and this was on 90s machines.

Objective-C is just C; there is no inherent performance penalty other than the
dynamic dispatch of messages. In situations where that would actually be an
issue, you'd be avoiding object-oriented features in C++ as well.

However, driver performance bottlenecks are typically in I/O throughput, not
the language the driver was compiled in. The fact OS X drivers are written in
a C++ subset likely has to do with the demands of device manufacturers coming
over from MacOS 9, just like the existence of Carbon was to appease
application developers like Adobe.

------
brown9-2
Previous discussion on this same article:
<http://news.ycombinator.com/item?id=885482>

------
jarin
"I think the decision to be backwards-compatible with C is a fatal flaw."
--Guy Steele

The funny thing is Objective-C is also backwards-compatible with C and there
is a huge world of difference between programming in Objective-C and
programming in C++.

~~~
tjr
While Objective-C is backwards-compatible with C, it doesn't tend to be as
noticable as much as it is with C++. Objective-C feels like a markedly
different language in which you can do inline C if you want to, while C++
feels like more of an extension of C.

------
dan00
Why we're using C++? Because we're writing 3d graphics and memory heavy gui
applications for the engineering world. In this regard the combination of Qt
and OpenSceneGraph is quite nice.

I really can't understand, how someone can favour C for C++. Ok, C is the
easier language, but the better abstraction capabilities of C++ outweighs this
on a big code base.

------
oiuyuiopiuy
>..better than C++ unless efficiency is a concern

Like other construction materials are better than steel unless strength and
reliability are a concern.

------
maayank
I don't know, I enjoyed my time doing C++ work.

I think the key sentence is this: "I love to see how they do things because I
think they don’t rely on it for the stuff that it’s not really that good at
but totally use it as almost a metaprogramming language".

Using templates, it has by far the best metaprogramming abilities in a object
oriented language. I haven't used Smalltalk, but I've done production code in
C# and Java and whenever using them I always yearned to the metaprogramming
abilities of C++.

Slowly but steadily I'm gaining ground on Lisp, so who knows, maybe lisp
macros will satisfy this metaprogramming need in the near future :)

~~~
sedachv
If you want to see what C with macros would look like, check out C-Amplify:
<http://www.cliki.net/c-amplify>

------
bhavin
The following statement made by the Author doesn't sound like a programmer
(leave C++ expert alone).

 _"I think I once managed to read all the way through Stroustrup’s The C++
Programming Language and have looked at at least parts of The Design and
Evolution of C++. But I have never done any serious programming in it."_

All I can say is, any programmer worth his mettle would make such a
statement... Going through Stroustrups's book isn't possible if you're not
interested in C++ programming (given that its not part of For Dummies series),
IMHO. It is exactly like comparing it to a Novel. A programming guide is not
about reading, its about learning.

~~~
phugoid
I'm not sure what you mean. Have you read Stroustrup's book? It was my first
"practical" intro to object oriented programming, and I struggled with it.

I would describe it as Byzantine technology explained with an economy of words
that approaches poetry, at least in the way you must ponder each sentence. And
the exercises are stimulating, in the sense of a cattle prod. I enjoy that
sort of thing, in reasonable doses.

Since then I've stayed away from C++ unless it's externally imposed, and built
things with C and Python. I like a language whose basic features can fit in my
small brain, a language that gets out of the way.

------
rabc
I think the problem is in fact that nowadays developers jump into languagens
like Python, Ruby or PHP because it's easy to learn, easy to install and run
the environment and easy to code (you don't have to deal with memory or code
optimization).

C/C++ are the base for everything you code today. People start learn how to
code with languages like Java, jump straight into OOP. That's wrong.

Every developer should build at least a "hello world" in C, to know what's a
real code. Ever developer must know about memory management, to scale optimize
the code in any language. Other languages compilers do that for you, but you
really need to know how it works.

~~~
statictype
_I think the problem is in fact that nowadays developers jump into languagens
like Python, Ruby or PHP_

People have disliked C++ long before those languages existed or became
popular. A lot of people who have written and maintain large C++ code bases
will tell you straight up that they prefer C to C++.

~~~
copper

        A lot of people who have written and maintain large C++ code bases will tell you straight up that they prefer C to C++.
    

Perhaps that's the problem right there. As someone who has written a lot of
C++ for quite some time, the most nightmarish aspect tends to be working with
antique codebases.

The way people program in it has changed drastically over the last ten or so
years. It's possible to have a reasonably painless experience with modern C++
that is pretty much impossible with codebases with significant history.

A lot of that is because the compiler support simply wasn't mature enough, so
people did what they had to do to ship. If all you're dealing with is old C++
code, it's extremely easy to find that you prefer coding in C rather than C++
(which is almost what that old code really is).

~~~
agentultra
The true test of a language, IMO, is how it will rot over a decade or so.

I'm maintaining a C++ web application written 12 years ago. It's not pretty. I
cannot describe the difficulties even an experience C++ developer would have
in trying to understand and maintain it.

Fortunately modern C++ is pretty good. We've managed to tack on a legacy
compatibility layer via the Boost libs to give us a Python wrapper. It's still
running in production and is still pretty useable.

However, C/C++ still requires a fairly high cognitive load for a diminishing
return, IMO. There are other languages that are easier to understand and
maintain whose implementations are getting increasingly better at competing in
areas where C/C++ used to be the go-to choice. There are simply fewer cases
where I will reach for C++ these days where it used to be the only choice.

~~~
copper
You're absolutely right, of course - a webapp in C++ is not something that I'd
want to even volunteer to help maintain.

I'd just say that it's not the language that rots, but the libraries, and
preexisting code. There are still some areas where C++ is a good choice, but
for things like a webapp, there would have to be a really compelling reason to
choose it.

------
16s
I really enjoy C++. It's a "live and let live" language. Pick what you want to
use and be happy. Sure, not everyone picks the same pieces to use, but like in
everything, humans will have differences and C++ allows and encourages that.

You can do procedural, functional, OOP, generic, template meta-programming
etc. It has something for everyone and does not try to force anything down
your throat. That is why I love it.

I use it daily and am very productive with it.

Edit: grammar

~~~
loup-vaillant
> _does not try to force anything down your throat._

It forces me to relinquish a host of assumptions about most programs. This is
a huge source of bugs.

> _I use it daily and am very productive with it._

Meaning, you write lots of code? Or you solve lots of problems that weren't
introduced by C++ in the first place?

