Invisible wrote:
> printf() - obviously.
> 
> Any operation involving strings seems to require you to use functions
> with names like "strnmsx" or something. (What, you couldn't afford a few
> more octets for some extra letters?)

When C just started, function names were actually quite limited.

Nowadays, we just abbreviate for the hell of it :P

> Manual memory management is tricky in any language, but at least in
> (say) Pascal, strings are managed for you. And let's face it, strings
> are *the* most common reason for using variable-sized arrays.

In C++, there is a string class that manages most stuff for you.

string a = "foo", b = "bar";

string c = a + b;

> I spent about 3 days trying to figure out the syntax for making function
> pointers work. After endless segfaults, I just gave up. It was too hard.

Function pointers are far from an easy feature.

> What insane nutcase thought that making assignment an expression as a
> good idea? Seriously, WTF? That's excellent. So if I say "if (x = 5)..."
> then my program will silently fail to work correctly, and I'll probably
> spend hours if not days trying to figure out why.

Any good compiler will warn about it; at least if you explicitly ask for it
(it's annoying when the if(x=5) is intentional and you can't make the
compiler shut up about it, a common workaround is if ((x = 5)) which looks
kind of ugly)

> Boolean operators and bitwise operators. Which is which? Which ones are
> the short-circuit ones, and which aren't? I can never remember.

Think of bitwise operators as arithmetic operations.

int foo = 0 * func()

Would it be sane not to execute func() for its side effects just because the
expression is already 0 and it wouldn't change anything? I don't think so.
So the same happens for bitwise operators, they don't short-circuit.

if (foo != NULL && !foo->items.empty() && foo->items[0].isValid())

If foo is null, the first part of the expression is false. If the second
part is ran anyway, your program crashes (null pointer deference).

If foo->items is empty, the second part of the expression is false. If the
third part is ran anyway, your program may crash, or read random data from
memory, or behave unexpectedly (reading off bounds of a standard container
without bounds-checking is the same as reading off array bounds).

You *want* short-circuiting :)

> What's the difference between #include "" and include <>?

I'm not *completely* sure. I think "" searches in the current directory and
other directories listed in the compiler's include path (-I in Unix), while
<> searches in the system include path (/usr/include). So you'd use "" for
your own headers.

Post a reply to this message