>> I think they meant your code crashes a lot if it's written in C++ and hasn't
>> had lots of debugging.
>
>    I think it depends a lot on the competence of the C++ programmer(s).

I imagine it also varies considerably depending on how complicated 
whatever you're trying to implement is.

By the looks of it, these guys were trying to implement stuff like 
routing, statistics, license management, encryption, distributed lookup, 
and probably complex business rules as well, all in C++, while their 
servers get hammered by customers of tier-1 game titles. I'd imagine 
that kinda thing isn't fun.

> Granted, becoming a very competent C++ programmer
> may require more work than with some other languages, but it's not impossible.

I'd presume [although I could of course be wrong] that a company that 
develops exclusively in C++ would go out of their way to hire only the best.

>    Of course with C++ (and C and other C-compatible languages) the rare
> circumstance where you get a nightmarish bug can be pretty fun.

Yeah, gotta love bugs that move around depending on what compiler flags 
you set or which version of some 3rd party library you link to. (E.g., 
anything involving broken pointer arithmetic usually ends up causing 
random behaviour that varies depending on the exact compilation details.)

>    I wonder if something similar ever happens with the "safer" programming
> languages (eg. you get a "null pointer exception" or some other similar
> error and have absolutely no idea why, and no debugging tool is helping).

In Java, accessing a null pointer would throw an exception, which (if 
nothing else) will dump a stack trace to stderr.

In Haskell, accessing a null pointer would... be quite impressive, 
actually. Given that the core language itself has no notion of "pointer" 
nor what it means to be "null".

Probably the closest equivalent is the "head []" error. If some function 
was expecting a list of data, but at runtime that list happens to be 
empty, then the program prints "head []" to stderr and halts. [Unless 
you wrote some exception handling code, of course.]

Good luck figuring out where in the entire program the problem actually 
resides. What's that? Bracket the problem parts with print statements? 
Ah, but perhaps you're forgetting; Haskell does not execute code in the 
order written, and printing is only permitted from the IO monad.

Yes, there /is/ a debugger. No, it will /not/ give you a stack trace.

Post a reply to this message