4 ms·

I don't write C or C++, but I do write a lot of C# and some occasional obj-C. Maybe I will get down voted for this, and I completely see merit in learning all y

by S_A_P 13y ago

I don't write C or C++, but I do write a lot of C# and some occasional obj-C. Maybe I will get down voted for this, and I completely see merit in learning all you can about a language and features as it makes developers more valuable to their employers. <now for the but> In my over 10 years as a developer, I rarely if EVER come across these sorts of problems. I've been in many problem domains and modeled many sorts of problems. I have come across these sorts of issues maybe 1 or 2 times. When I did come across this sort of problem a few hours of thought allowed me to come up with a rational solution that didn't require stretching the bounds a of a language. </but> So while Im all for academic curiosity and figuring out the way things work, I dont know that these sort of things are applicable as to whether someone can write code to do a job that is robust, scalable and reliable. So please excuse me while I go read my C++ books because I feel stupid...

FreezerburnV 13y ago
That's a pretty valid <but>...</but> tag. However, I would argue (based on what I know of software development and the stories that I've seen posted on occasion on HN) that knowing some of these oddities and details can come in a lot of handy someday. Even careful developers can accidentally run into some strange scenario which turns into one of these rarely-seen specifications, causing some bug. If you don't know these kinds of things, you'll have no clue where the bug could be coming from. And this is especially true in a language that can be as thorny as C++. As an example, in a program I'm working on which is still some ridiculously simple 100-line program, I shadowed a variable name inside a loop. (C++) I figured it would be ok because I was declaring the new variable after I was done using the previous one. But apparently, declaring a variable at all in a scope causes the new variable to be the one used inside that scope, even from the beginning. And considering the two variables were of a different type, it was causing a problem. Not hard to find in a small program, but might be harder to find in a large one. On the flipside, a lot of these issues might be relatively easy to find with a little intelligent Googling or asking Stack Overflow. But that time might have been better spent continuing development on the current project. And that time can add up.
Glide 13y ago
Haha yeah. I agree with you totally, however sometimes when the problem is a bug in another system and everything still seems completely rational this kind of knowledge is gold. My story was a C# WPF application and certain events were not being unregistered. It wasn't the language built in event registration but a weak even registration handler in a WPF library. It wasn't unregistering the event and it was odd to say the least because it was just an equals call. It turns out that the function was an anonymous function (that was defined as x = {...};) The strangest thing is that the anonymous function had a reference to it and I had thought that the references were being compared for equality. But it wasn't being matched... So I recommended the inline declaration be changed to an actual static method and the comparison worked. I think I gave some kind of explanation about how it most likely compared the address of the methods or something. Or the comparer for a Action<T> was different than "normal" objects. Half the fun of it is figuring out how things really work behind the scenes though. For the person figuring it out though.
Sharlin 13y ago
As a long-time (hobbyist) C++ programmer, I'd say many of the questions in the quiz are well-known gotchas that do break real-world code in subtle ways. Especially code by beginners that have Java or C# experience and expect C++ to be as well-mannered. That said, many other questions certainly pertain to more esoteric parts of the language, but that's not a bad thing - it provides some entertainment and headscratching even to those of us who might think they've seen it all :)

by S_A_P 13y ago

FreezerburnV 13y ago

That's a pretty valid <but>...</but> tag. However, I would argue (based on what I know of software development and the stories that I've seen posted on occasion on HN) that knowing some of these oddities and details can come in a lot of handy someday. Even careful developers can accidentally run into some strange scenario which turns into one of these rarely-seen specifications, causing some bug. If you don't know these kinds of things, you'll have no clue where the bug could be coming from. And this is especially true in a language that can be as thorny as C++. As an example, in a program I'm working on which is still some ridiculously simple 100-line program, I shadowed a variable name inside a loop. (C++) I figured it would be ok because I was declaring the new variable after I was done using the previous one. But apparently, declaring a variable at all in a scope causes the new variable to be the one used inside that scope, even from the beginning. And considering the two variables were of a different type, it was causing a problem. Not hard to find in a small program, but might be harder to find in a large one. On the flipside, a lot of these issues might be relatively easy to find with a little intelligent Googling or asking Stack Overflow. But that time might have been better spent continuing development on the current project. And that time can add up.

Glide 13y ago

Haha yeah. I agree with you totally, however sometimes when the problem is a bug in another system and everything still seems completely rational this kind of knowledge is gold. My story was a C# WPF application and certain events were not being unregistered. It wasn't the language built in event registration but a weak even registration handler in a WPF library. It wasn't unregistering the event and it was odd to say the least because it was just an equals call. It turns out that the function was an anonymous function (that was defined as x = {...};) The strangest thing is that the anonymous function had a reference to it and I had thought that the references were being compared for equality. But it wasn't being matched... So I recommended the inline declaration be changed to an actual static method and the comparison worked. I think I gave some kind of explanation about how it most likely compared the address of the methods or something. Or the comparer for a Action<T> was different than "normal" objects. Half the fun of it is figuring out how things really work behind the scenes though. For the person figuring it out though.

Sharlin 13y ago

As a long-time (hobbyist) C++ programmer, I'd say many of the questions in the quiz are well-known gotchas that do break real-world code in subtle ways. Especially code by beginners that have Java or C# experience and expect C++ to be as well-mannered. That said, many other questions certainly pertain to more esoteric parts of the language, but that's not a bad thing - it provides some entertainment and headscratching even to those of us who might think they've seen it all :)