
C++ killed my grandpappy - Is C++ hard and where are the C++ coders hiding? - bdfh42
http://www.hanselman.com/blog/CKilledMyGrandpappyIsCHardAndWhereAreTheCCodersHiding.aspx
======
ComputerGuru
I'm a C++ developer 18 hours of the day, and a .NET developer the other 6.

C++ is great. It's very powerful, it's very fast, and actually, very easy to
use. Especially on Windows.

If you want quick and dirty access to system functions, if you want to be able
to quickly open a pipe, write raw data to it, and be on your way. If you want
low-level access to a buffer, to the memory, to a file. If you want to do
basic string parsing. It's all there.

.NET is certainly a better _platform_ but it's not as inherently powerful. On
Linux, it's rather different because at this point you can do anything in
Python or Java that you can in C++ (except drivers and kernel modules, etc.).
On Windows, that's not exactly the case.

I love the control that C++ gives me. I can decide when a object is passed by
reference and when it's by value. I can send a object as constant by reference
_explicitly and therefore make no mistake about it_. I can use pointers to fly
to pre-determined locations in a buffer. I can jump pointers to access hard-
coded offsets in a struct. I choose _not_ to use templates willy-nilly and to
never do multiple inheritance. I don't use things that are hard to maintain,
but I take pride in using quick and dirty innovative solutions where it's
short on steps, but not short on self-explanatory functions (i.e. shortcuts in
functionality, not in LoC).

C++ is as complicated as you make it. It gives you a lot of rope to hang
yourself with. It gives you a lot of flexibility. It gives you a lot of power.
When writing a filesystem monitor that parses hundreds to thousands of events
per second, I use raw char* pointers and manual memory allocation (with a 3rd
party allocator, no less). When doing userland apps, I use automatic memory
management with smart pointers.

I _have_ all the flexibility and automation of .NET and Java - but I also have
the choice not to use it.

But stick a beginner in C++, and they'll fail to see that there are many
options, some of them even easier than their managed counterparts. They'll get
lost battling pointers and confusing their laws of inheritance, and they won't
see the forest for the trees. They'll overuse templates when they're not
necessary, and not use the well-syntaxed and to-the-point STL algorithms when
they're available.

In .NET, I find myself longing for raw memory access at times. I find myself
wishing that the .NET team bothered themselves to add wrappers to even more
Win32 functions and that I don't have to have a class full of 50 to 100
P/Invokes in order to get access to what I consider _for my needs_ to be
essential Win32 calls.

But .NET makes working with a team easy. It makes it easy to set standards and
stick to them. It makes it easy to keep track of objects. It makes it super
easy to integrate GUI and code in a way that makes sense (MFC begone!). I can
use .NET to write a terribly complicated app in a matter of an hour and have
it deployed with minimal effort spent on error proofing the application. I
don't have to worry about checking the return value of each and every call I
make - a single catch() that's well written will take care of it all. I don't
need to worry about finding headers that fit my coding style or bother myself
with linker errors. A ton of libraries exist only a "using ...." away.

The worst thing about C++, without doubt, isn't the language or the syntax:
it's the compilation problems. When you have multiple cyclic dependencies.
When you have functions to export, and similar functions already imported from
one of the dependencies you already have. DLL hell. Conflicting versions of
the CRT. Having to search for the source code of a module you wrote years and
years ago in order to re-compile it against the same C runtime that you're
using in your current project. Having to keep a copy of both .h and .lib files
for all your DLLs in order to use them again in a later project. Stuff like
that is where I _really_ appreciate the .NET way of doing things.

~~~
dfox
I believe that compilation problems you describe are caused by Microsoft's
development tools (and by some weird quirks of Windows as a platform) and not
by C/C++ itself. Every time I build something for Windows I get this feeling
that it's actually hostile to code reuse across projects and that is the case
even in .NET. Getting right import libraries (what are they for, anyway?) and
getting IDE to actually know that you intend to link something/use some
assembly seems horribly complicated in contrast to unix's #include <foo.h> and
ld ... -lfoo

Also, having five different almost-compatible ABIs for C is something that
really helps C/C++ programmers, especially in environment where it is common
to ship compiled binaries, that are often very hard to rebuild from scratch.

------
strlen
There's many reasons to criticize C++. None of them have to do with whether
it's "managed" or not. Whether to use a "managed" (i.e., garbage collected and
unable to perform unsafe memory access) language is an orthogonal issue;
applicability of either approaches depends on the problem at hand. Some
problems can't be solved without raw memory access, other problems can be
solved but only at great performance and reliability cost, others don't
benefit significantly from either approach yet others are dangerous or
difficult to solve without memory management.

The real criticism of C++ is that it's an accidentally complex language (1)
built by multiple warring tribes: one that wanted object orientation, the
other that wanted static typing, yet another that wanted generic programming.
What happened is that _all_ of them won. Nonetheless, there is likely more
than just a social reason no other language emerged for (relatively) high-
level systems (2) programming (not that it hasn't been tried e.g., Modula-3
and most recently -- and promisingly -- Go). The only real alternative seems
to be "C with objects" (e.g., glib or VFS layer in the Linux kernel).

That, however, still has nothing to do with what the article is about: is it
me, or are the Windows C++ APIs just _horribly_ designed? Qt, while far from
perfect, is a just a _lot_ easier to program to.

(1) It's fine for a language to be complex for a reason. Haskell is complex,
yet that's because it's based on a very different paradigm which brings many
advantages to the table. C is necessarily more complex than Python because
it's meant to make systems programming possible.

(2) Nonetheless the domain of systems programming (which I'm going to ad-hoc
define as something that requires dealing with memory addresses, the OS kernel
and physical hardware) is shrinking. It's now possible (in terms of getting
great performance) to write a database or a distributed lock manager in Java
or a web server in Python or Ruby. So I am going to use "systems programming"
here to mean operating system, driver, embedded, etc... development.

~~~
ComputerGuru
> _is it me, or are the Windows C++ APIs just horribly designed?_

There's your problem _right there_! Windows does NOT have an C++ APIs (if you
put COM aside). They're all legacy plain-C APIs and they're difficult to
fathom in our increasingly object-oriented world.

Keeping in mind backwards compatibility and isolation of memory management (no
objects or memory allocations are passed across memory boundaries due to
architectural reasons in the Windows platform itself and not due to the design
of the API) between libraries, the Win32 API is actually remarkably well
designed.

You've got C-based declarations for literally a hundred thousand functions,
each with varying functionality depending on what you want to use it to
accomplish. And it preserves backwards compatibility. And it has managed to
keep up with the latest tech and features. Plus, half-way through, they went
ahead and re-implemented each and every function in a Unicode version while
keeping the old ASCII version fully available.

I used to think the same. I used to look at Win32 and groan. But when I
realized the extent of its complexity, the domain constraints it was under (OS
design, DLL isolation, etc) the requirements (backwards compatibility, static
functions for literally _everything_ ).. it all made sense.

What gets me is _new_ languages that have way worse problems without the same
good reasons. Take a look at PHP and its strlen vs str_pad (why _ sometimes
and sometimes no?) and its str_replace(needle, needle, haystack) vs
strstr(haystack, needle)... that's uncalled for, badly designed, and with no
excuse.

~~~
alextingle
The WinAPI _is_ horribly designed. The choice of language has nothing to do
with it. A plain C API can be a joy to work with (e.g. pthreads, or any POSIX
API). There is just no excuse for the myriad of WinAPI functions that take 13
parameters in random order, most of which need to be set to 0, -1 or NULL to
get it to work.

~~~
ajuc
The excuse is backward compatibility, and it is also why linux binaries from 3
years ago doesn't work on new linux, and win32 binaries does (or at least did
before vista age).

PS I prefer linux way (clean the api, no matter old binaries), but that's
because I'm programmer, as a user I would love to just download old binary
from net and have it work without worrying about dependencies.

~~~
jussij
I was amazed to find that a version of the Zeus editor dating back to 1995
still runs fine on Windows 7 and that software is not even Win32. It's written
in Win16.

And here is the link to prove it: <http://www.zeusedit.com/z300/zeus-v103.zip>

~~~
ajuc
My last windows was xp, bu I've heard win7 was supposed to have virtual
machine with winXP to run older program. If so, this is cheating :)

~~~
ComputerGuru
Not really. You need to separately install the XP Virtual Machine software on
Windows 7. He means it actually runs "out of the box."

(Windows 7's XP emulation mode is nothing like the super cool Rosetta on OS X)

------
motters
Yes, I am also another C++ coder coming out of the closet!

I first learned C programming on a technology course in around 1992/3, and
then also learned C++ using the Borland compiler running on DOS. I've used C++
on and off ever since, both in commercial and hobby projects. I always
disliked MFC, which seemed horribly non-standard, and in the last 5 years have
been mainly using gcc as my preferred compiler. I briefly ventured in to the
world of MS C++.NET, but the code looked utterly horrifying with all the .NET
stuff crudely crowbarred into it.

I am completely aware of the advantages of managed code, and have also done
quite a lot of coding in C# (mono), and some in Java. Having been a C# fanboy
for a while I've recently reverted to C++ programming in the last year or so,
mainly due to software patent concerns. However, I would not describe myself
as a "language zealot", and have used multiple programming languages over the
years in a highly pragmatic fashion.

------
zwieback
I suspect the majority of C++ programmers is older (44 myself), has gotten
ranting and raving out of their system and are now quietly doing their jobs. I
remember heated discussions about dynamic vs. static typing or templates vs.
avoiding code bloat on Usenet but now I feel too complacent to pick any more
fights.

I think part of it also has to do with the availability of free alternatives
for all different paradigms. Back when a decent C++ compiler (Zortech!) would
set you back hundreds of dollars it was easier to get defensive about your
choice of programming tools and speak up.

When the job requires it I still use C++ but not as much as I did 10 years
ago; 15 years ago I was using only C++. C++ has survived Java, seems to be on
friendly terms with C# and will be still around when the functional bubble has
popped.

~~~
xenthral
I'm 24 and I've been coding C++ for the past 4 years, it was my first language
and remains the one I use the most, though I've used Ruby professionally most
recently, I'm trying to get a C++ gamedev job now.

So its not just the older crowd, it very much depends on what you're trying to
do I think.

------
enneff
The subtext of this article is "I found C++ daunting at first, but after I'd
been programming for a number of years I revisited it and found it quite
useful."

------
16s
I'm not sure C++ coders are hiding. They are in plain site in many industries.

Yes, compared to today's scripting, languages, C++ is hard (but not
impossible) to use. There are no soft, rounded edges to protect rash
programmers who make incorrect assumptions. Basically, C++ makes us stop and
really think about what we are asking the computer to do. It makes us evaluate
data structures, types and how we use those things.

Ruby and Python hide those details to a large degree (I use and like them
both) and there are times when that is OK, but we also need the rigor and
requirements found in C++.

If I could only have two languages, I would choose Python and C++. If only
one, then C++.

EDIT: Management sometimes want quick and dirty and out the door apps
yesterday! I would not suggest C++ for that unless you have an expert team,
but one of today's scripting languages would be fine for that sort of
environment. I may also note that environments such as that will not keep
expert development teams for long.

~~~
nuxi
> Yes, compared to today's scripting, languages, C++ is hard (but not
> impossible) to use. There are no soft, rounded edges to protect rash
> programmers who make incorrect assumptions. Basically, C++ makes us stop and
> really think about what we are asking the computer to do. It makes us
> evaluate data structures, types and how we use those things.

To me it looks like you're talking about C, rather than C++.

C++ always makes me stop and think how the compiler will react to certain
code, and how it is supposed to behave with regards to the ISO standard(s).
Actually reading the standard usually makes things worse (again, for me), so
I'd choose python anytime.

EDIT: (formatting)

------
ern
I see that some people in the comments on Hanselman's site are using the
terminology "C/C++". Back when I was learning C and C++, it was described as
poor form, and a sign that that the writer didn't know either language very
well.

Has it become more acceptable to conflate the two languages in recent years?

~~~
timr
No....what you're seeing is a side-effect of the fact that most critics of C++
these days don't actually know the language. It's still wrong to conflate C
and C++, but since most students now come up learning Java, they rarely
encounter C++ as its own language. It gets grouped together mentally with
those _"nasty, C-like languages"_ , and the stereotypes linger.

------
JoeAltmaier
Its not the antichrist; its not a panacea; its just another language. Its like
my yellow framing hammer; useful for one job, but I have other hammers too.

------
ajuc
Yay, you can write real app in C++.

Still - writing code againist windows api is begging for portability problems.
Why even bother with all those quirks, when there is qt and gtk, working on
Macs and Unices as well, and better designed?

I can only understand this, if it's just for fun. Peple have weird hobbys :)

EDIT: I also love, how they speak about .Net like it was the only alternative
to C++.

~~~
rodh257
Scott Hanselman is a .NET guy, most of his readers are .NET developers, he was
simply contrasting it with what the majority of his readers use.

------
alextingle
C++ in "it's a real language" shock!!!

