
C and C++ are not the same language. - wheels
http://blog.directededge.com/2009/05/21/c-and-c-are-not-the-same-language/
======
DarkShikari
While I don't agree with everything the guy says, this is a huge pet peeve of
mine: if someone says "C/C++" all the time, it is likely that they are skilled
at neither, because anyone who has done significant programming in both knows
quite well that the two are quite different in practice.

~~~
dryicerx
The two indeed totally different, but in lot of real world applications, the
two are used together, and they are very complementary.

For examples, lot of straight C wrapped in Classes, and accessed in a very C++
way. It's appropriate to say C/C++ for these.

------
dmix
Thanks for clarifying this; as someone who didn't take the usual CS in
university route this often confused me.

I've added C to my list of languages to learn after Python, mostly from
recommendation on HN and I want to get into machine learning.

~~~
mahmud
for M-L, brush up on your basic* math, and jack up on the probability and
statistics. an eetsy beetsy volume on numerical computing, just enough to
understand machine representation of numbers and enough to understand errors
(and their propagation!) should be enough.

don't hesitate to read engineering texts. the first few chapters of various
DSP texts should give you an idea of what to look for ("oh, so it's loops over
real-valued vectors! cool!") but if you read EE texts, feel free to ignore
complex variables (unless your earlier math text was good enough to introduce
them as vectors of two components :-)

An interactive language, preferably Octave/Matlab should come handy.

None of this will make sense right now, but hints are supposed by like that
;-)

\--

[Edit: * basic as in naive set theory, ability to reconstruct and prove
properties of Real numbers using Dedekin-cuts, basic proof techniques,
sequences, series, limits, functions as sets, basic trigonometric functions,
the derivative and the anti-derivative, and most importantly understanding the
various type of integrals, specially the Reimann. touching "real analysis"
from the standard and Non-Standard angles should be enough. All this could be
done in 2-3 months with the right texts. This is the minimal you will need to
understand things; the basic properties of the logarithms should come handy,
specially converting between logarithms of different bases (you will be
working on bases 10 and 2, while the natural number is more prominent in
engineering than CS.) ]

~~~
plinkplonk
I would add Linear Algebra to mahmud's (great) list of mathematical "stuff to
learn". A _lot_ of ML _needs_ Linear Algebra . (e.g Neural Networks, SVMs .. )

~~~
mahmud
Thanks for taking over the thread for me plinkplonk. I posted a dense teaser
and went to bed, then work for the rest of the day. You pretty much answered
all subsequent questions the way I would have :-)

Let me add that beginners couldn't go wrong with mathematics texts by Serge
Lang, first-rate mathematician and master teacher.

------
old-gregg
_Learning to think in C++ is much closer to learning to think in Java_

This is where I stopped reading. He mentioned "modern C++" many times, which
actually should mean that C++ moved away from rigid pseudo-OO GoF-inspired
structures, Java-style.

Java itself is a simplified snapshot of much older C++ (circa mid-90s) but
equipped with garbage collection. Memory management is an interesting,
actually, since C++ doesn't rely on heap allocation nearly as much as Java
does.

Well, long story short: no, "thinking in Java" is a terrible, terrible way of
describing how C++ programming should be done.

Thinking in _modern_ C++ is supposed to feel like you're trying to bolt on
Haskell's type system on top of C.

~~~
wheels
I'm not sure that's descriptive so much as an ideal.

In practice (mentioned this in the blog comments as well) I've found that the
C++ world is somewhat divided between what I'll label the Boost and Qt camps.

Boost, as kind of a conceptual child of the STL, has extended more along the
axis of exploring what's possible with the language, at times at the cost of
pragmatism. The Qt camp, on the other hand, tends to hide most of the heavy
use of generic programming in private classes and exposes more simplified
APIs, typically with minimal use of templates in public APIs.

I personally, as a former long-time KDE developer, fall firmly in the Qt camp
and it shows in the way that I write C++. It's also the style that's been
preferred in the two companies where I've been employed as a C++ developer.

Which is _modern_ is mostly a semantic issue. I'd wager that while advanced
template programming is more cutting-edge, it's also not in fact the way that
very much C++ today is actually written, which is the definition of modern I
was working with.

~~~
timr
The book that defines the genre ("Modern C++ Design", by Andrei Alexandrescu),
is all about template metaprogramming. I'd say that's the end of the semantic
debate.

Maybe you could say that I'm in a "camp", but the C++ style that Qt uses is
based on the outdated notion that compilers can't keep up with the "modern"
features of C++. That style is antiquated.

~~~
wheels
Current compilers still generate huge binaries for code that makes excessive
usage of templates; I've personally had to rip out a lot of heavily templated
code in the last year for that reason.

They also still (with the Intel compiler as a notable exception) generate
nonsensical error messages when templates are used heavily.

The latter reason is one of many that a lot of _C++ programmers_ don't do well
with heavy template usage. One naturally could fault those programmers, and I
think that's half-way fair, but in designing reusable APIs, API usability is
and should be a concern. The corollary seems is obviously a bad principle when
applied to (graphical) interfaces: if the users weren't so dumb it'd be easy
to understand. I believe the same holds true, generally, for API design.

Half-way related, I'm personally quite a fan of _Designing Qt-style C++ APIs_
:

<http://doc.trolltech.com/qq/qq13-apis.html>

As for "modernness" the point still stands; when some people say, "modern
music" they mean "avant garde". Others mean "the stuff on the radio". I mean
the stuff on the radio; Alexandrescu is the avante garde.

~~~
kingkongrevenge
Compilation speed and incomprehensible compiler errors remain an issues for
template heavy code but this is the first time I've heard complaints about
binary size. Can you educate?

Theoretically the incomprehensible compiler errors will go away in the next
couple years as compiler writers integrate C++0x "concepts."

~~~
wheels
Every specialization of a template creates a new instance of it with new
symbols. With heavily nested templating that can add up quite quickly.

The most problematic case at my last company was where there were several
hundred specializations (just one-liners) one after another in some of the
error handling code. Each of those specialized several more templates. I
managed to shave a few dozen MB off of the binary size (and remember, larger
binaries == more cache pressure) by replacing the templates with a base class
and virtual function.

------
plinkplonk
I am (a little) surprised at how well the C example reads vs the C++ version.
I would have thought that an OO design pattern (here, Observer) is where C++
syntax would be a better fit.

~~~
stcredzero
One of my professors, Carter Bays saw some C++ and said, "So, is C++ just the
new COBOL?"

(Dude wrote the world's _first implementation of merge sort_. It's saved on
paper punch-tape! And he has stuff in one of the 1st 3 Knuth books.)

------
swolchok
"But C++ often hits a sweet-spot between languages where high-level
abstractions are available with the raw power of C when you need it." He then
goes on to say he uses Ruby and not Python. Is Ruby missing nice C
integration? Python is oft-touted as the sweet spot here, although I have to
confess I haven't done a whole lot of Python/C or Python/C++ integration.

~~~
wheels
I just like Ruby more. You can connect both Python and Ruby to C APIs, and
I've done so in the past from Ruby.

C++ integration is usually moderately more annoying since once you start
moving beyond ordinal types cross-language communication becomes hairier. C
ends up being the lingua franca between programming environments a lot of the
time.

~~~
kingkongrevenge
It is just as easy to extend any of the scripting languages with C++ as it is
with C. SWIG and other systems like XS have built-in support for C++. Even if
that weren't true, you can just make your interface header files 'extern "C"'
yet enjoy the superior power of C++ in your implementation files.

There is no reason to favor C over C++ when extending a scripting language.

~~~
wheels
Right. By "I extended them with C", I meant, "I extended them with a C
interface"; the implementation was in C++.

------
dimitar
A quick question about c++

in std::cout << "Whoopee." << std::endl; is std::endl putting a newline char
after "Whoopee. "?

Anyway in the C example it could have been written puts("Whoopee."); instead
of printf("Whoopee. \n"); puts() places a \n after the char * it accepts as an
argument.

I'm sorry for the triviality here :)

~~~
stonemetal
std::endl will insert a new line, but it also flushes the buffer. So use'\n'
when you need a new line and don't want to flush the output buffer.

------
grandalf
I think if there were an extension to the STL for unicode, string handling and
simple sockets few people would even need ruby :)

~~~
dryicerx
Look in to Boost <http://www.boost.org/doc/libs>

------
arghnoname
It looks to me in the C version, he only frees the first listener. The C++
version also provides the listeners as a set. The C version doesn't mind if
you add the same listener multiple times, so to be apples to apples you'd use
a vector, but the code wouldn't change otherwise, so no problem there.

~~~
wheels
\- That's an array of pointers; the listeners themselves aren't malloced

\- The set / list difference is noted just below the code samples

