[LLVMdev] Removal of Visual Studio project files.

[OvermindDL1]

On Mon, Nov 24, 2008 at 10:13 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> /* snip */

Thanks so much for that information.  :)

For note, this is my usual line I add to the end of my preprocessor
definitions in *every* single project I ever open now (thanks to some
very bad memories associated with not having them).

;_CRT_NONSTDC_NO_DEPRECATE;_CRT_SECURE_NO_DEPRECATE;_SECURE_SCL=0;_SCL_SECURE_NO_DEPRECATE;_HAS_ITERATOR_DEBUGGING=0

Most of those will be obvious, but as stated, both _SECURE_SCL and
_HAS_ITERATOR_DEBUGGING (especially this last one, you can 'sometimes'
get by with linking on just _SECURE_SCL, but not with
_HAS_ITERATOR_DEBUGGING for some forsaken reason) will cause very
nasty and horrible crashes if a program is linked together where one
part defines those and another part does not and there is *any*
sharing of anything in the stl between modules (yes, even
std::basic_string).  The crashes are near impossible to diagnose if
you do not know about these ahead of time.

As such, with any library I distribute, one of the build options
always includes one that defines these as well.  I follow a boost
style naming convention, so for a project like myLib a full build
would create files like these:
myLib_32dyp.lib
myLib_32dy.lib
myLib_32dsp.lib
myLib_32ds.lib
myLib_32ryp.lib
myLib_32ry.lib
myLib_32rsp.lib
myLib_32rs.lib
myLib_32rdyp.lib
myLib_32rdy.lib
myLib_32rdsp.lib
myLib_32rds.lib

Where 32 means it is 32-bit, d means it is a debug build, r means it
is a release build, r and d together mean it is a release build with
debug info, y is a dynamic library (uses a corresponding dll file), s
is a static lib, p means it has all my preprocessor defines from
above, no p means it does not.  A setup like this in cmake would be
perfect I would have to say (well, minus the dynamic libs since they
are not well supported).

I really wish I could have stuck with VS2k3, regardless of the
(surprisingly) few complience issues it had, it just ran as you would
expect, no hidden gotchas and other crap like these definitions.

And good god yes, when using the stl in some cases, without all of the
above, it adds so freaking much bound checking code that, quite
literally, there was a ~170 to 1 ratio of lines of assembly of bound
checking related code compared to *my* code.  Putting the defines in
shrunk it a great deal, and my code ran in over 20 times faster.  If I
wanted bounds checking I would use Java, I need speed and I right now
I would love to use some very colorful metaphors about the person at
Microsoft who initially came up with these retarded things.  It would
not be so bad if the linker identified the incompatible code and
choked like normal, but since it does not... I really hate that
person... I lost so much time and sanity...