69 replies to this topic

[tstrimple]

I did say language and tools. ;)

That the language still allows you to make that exact same mistake in exactly the same way doesn't make it look like an upgrade =P

 

 

True, the tools for the language are what's better. 

Edited by tstrimple, 13 February 2013 - 02:47 PM.

[achild]

Oh gee.

• Anything threading
  • Implementing a reusable, thread-safe, intrusive copy-on-write base for classes (2 levels of thread safety required!!)
  • Any undocumented or hard to find caveat to a windows api call. Ex: WatiForMultipleObjects in some threading situations
• Different STL optimization flags set in a single project. This caused random crashes in random places I spent a looong time "debugging" in code which was actually correct.
• MSVC producing the same .obj filename out of two separate source codes in separate directories which themselves have the same filename. UGH. Major linking problems.
• C++ implicit casting has nailed me hard more than once.

[ApochPiQ]

Oh, don't worry on that account, we already upgraded our language.  
Which, incidentally, also solves ApochPiQ's bug in the post above this.

Actually, the implicit NULL conversion to literal 0 in my code is a total red herring. The actual evil is squarely with default parameters, and can be trivially reconstructed even with all the parameters being of primitive non-pointer types.

[phantom]

It looks like C#.

 
I did say language and tools. ;)

 
Oh, don't worry on that account, we already upgraded our language.  
Which, incidentally, also solves ApochPiQ's bug in the post above this.

You know, I'm sure with a higher than default warning level and 'warnings as errors' I've seen the compiler catch this error before now (reports as a warning, warning as error fails the compile).

Now, it won't catch you when you make this mistake...

auto it = std::begin(someContainer);
auto end = std::end(someContainer);
bool found = false;
while(it != end && !found)
{
    found = *it == searchItem;
}

Opps...

[Servant of the Lord]

@ApochPiQ: Then I fail, cause I can't spot it at all. 

(Ignoring the lack of actual inheritance in the structs, which I presume isn't the bug)

Edited by Servant of the Lord, 13 February 2013 - 03:50 PM.

[ApochPiQ]

I'll rephrase it slightly:

struct Base
{
    Base(int oldValue, int newValueWeJustAdded, int oldValueWithDefault = 42);
};

struct EverythingMustBeOne : Base
{
    EverythingMustBeOne()
        : Base(1, 1, 1)
    {  }
};

struct EverythingMustBeTwo : Base
{
    EverythingMustBeTwo()
        : Base(2, 2)
    {  }
};

Assume that Extremely Bad Things™ happen if the value of oldValueWithDefault in EverythingMustBeTwo is not 2.

[swiftcoder]

You know, I'm sure with a higher than default warning level and 'warnings as errors' I've seen the compiler catch this error before now (reports as a warning, warning as error fails the compile).

Gcc requires -Wall and -extra to catch it. Clang catches it by default.

 

(incidentally, this discussion is occurring over here as well).

[Sik_the_hedgehog]

Now, it won't catch you when you make this mistake...

auto it = std::begin(someContainer);
auto end = std::end(someContainer);
bool found = false;
while(it != end && !found)
{
    found = *it == searchItem;
}

Opps...

 

Lesson: stick to for loops when doing that kind of iterations.

[phantom]

Lesson: stick to for loops when doing that kind of iterations.

I prefer the 'while' construct; imo it better expresses the intent of the loop.
'for' tends to imply you'll hit a whole range where 'while' is more a 'while these conditions are true' and, in my mind, is better for a search.

Would have prefered to have used an std algorithm however, would have been clearer and without the mistake...

[Icebone1000]

http://www.gamedev.net/topic/617629-works-with-x64-debug-x64-release-and-x32-debug-but-not-with-x32-release/

 

If werent by gamedev...Ive had gave up on programming many times..(learned new stuff in that one)

Edited by Icebone1000, 14 February 2013 - 08:34 AM.