Please Review My HashTable Code(C++)
Visual Studio accepts >> with language extensions enabled (which shouldn't be turned off anyway).
Quote:Original post by Zao
Visual Studio accepts >> with language extensions enabled (which shouldn't be turned off anyway).
Visual Studio accepts HERESY!
Changes I didn't make:
"Don't use pointer to linked list, access it in-place. it will be .empty() anyway. "
-- I didn't do this because I didn't quite get this comment. The way my original code was made I needed to have a pointer to an array of linked lists. If I didn't dynamically allocate the list how could I expand and colapse the hash table at run time?
You get dynamically allocated lists from using vector. The problem here is that there is no justification to using an auto_ptr of an vector of lists. Just make it a vector of lists...
"Don't use pointer to linked list, access it in-place. it will be .empty() anyway. "
-- I didn't do this because I didn't quite get this comment. The way my original code was made I needed to have a pointer to an array of linked lists. If I didn't dynamically allocate the list how could I expand and colapse the hash table at run time?
You get dynamically allocated lists from using vector. The problem here is that there is no justification to using an auto_ptr of an vector of lists. Just make it a vector of lists...
Your hash functor interface looks dodgy. It should probably be a value type rather than something you store a reference to. Otherwise you require the user to make sure that the functor outlives the hash table, which isn't an intuitive way to use a container.
Quote:Original post by Zao
Visual Studio accepts >> with language extensions enabled (which shouldn't be turned off anyway).
Why not?
Quote:Original post by phresnelQuote:Original post by Zao
Visual Studio accepts >> with language extensions enabled (which shouldn't be turned off anyway).
Why not?
For one thing, even including windows.h isn't supported with language extensions disabled. Secondly, the compiler devs are quoted as saying that disabling language extensions opens you up for all kinds of crazy compiler bugs that don't surface otherwise.
Quote:Original post by cache_hitQuote:Original post by phresnelQuote:Original post by Zao
Visual Studio accepts >> with language extensions enabled (which shouldn't be turned off anyway).
Why not?
For one thing, even including windows.h isn't supported with language extensions disabled. Secondly, the compiler devs are quoted as saying that disabling language extensions opens you up for all kinds of crazy compiler bugs that don't surface otherwise.
Still, can doesn't mean should. :)
After a particularly painful port from Win to Mac made harder by language extension use, we added "ensure new code doesn't use VS language extensions" to our code review process.
Quote:Original post by ValereQuote:Original post by cache_hitQuote:Original post by phresnelQuote:Original post by Zao
Visual Studio accepts >> with language extensions enabled (which shouldn't be turned off anyway).
Why not?
For one thing, even including windows.h isn't supported with language extensions disabled. Secondly, the compiler devs are quoted as saying that disabling language extensions opens you up for all kinds of crazy compiler bugs that don't surface otherwise.
Still, can doesn't mean should. :)
After a particularly painful port from Win to Mac made harder by language extension use, we added "ensure new code doesn't use VS language extensions" to our code review process.
I don't know. I mean the only code you can effectively write with a program not using VS language extensions is a console app that doesn't interface with the windows api at all. which means you also can't use cross-platform libraries like boost that interface with the operating system.
Also, keep in mind this option means different things on different versions of the compiler. Older versions of visual studio even consider the for-loop scoping issue as part of this. Newer versions of visual studio have this as a separate option and /Za doesn't encompass this.
I agree that it makes porting easier, but at the same time, there's very little you can do on Windows with an app that uses /Za.
Sorry, I wasn't clear. We don't compile with /Za, but code that we write avoids the extensions except where you can't use the win32 API without them. Things like the >> to terminate nested template definitions wouldn't be allowed, for example.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
