Re: [isugamedev-devel] imagelib

[Chad A. <ae...@ae...>]

> why does it matter if we link against ms DLLs?  just because M$ is dumb,
> why should we be?  the DLL is easily available, and I think can be
> distributed with the games we make.

It's not on Win95 machines by default, and therefore adds to the footprint of
the library.  For gamedev purposes, I wouldn't mind shipping the MS C++ runtime
as well, but I think it's rather pretentious to make a 200k DLL depend on the
400k msvcp60.dll for a few simple things like strings and vectors which can
easily be done without.

The way I usually temporarily go about this is defining library::string and
library::list and library::vector classes that are as close to source-compatible
with the standard C++ library as possible until the runtime support is better,
at which point I'll just typedef the std:: classes.

> standard C++ is perfectly valid, and is a good thing
> to use.   We could convert what I've got over to use read(), open(), and
> close(), but yuk.  It doesn't matter a lot to me, but... shouldn't std::
> be inlined?  maybe not the iostreams, huh?  I still don't like using
> non-C++ just because of M$ dumbness with their DLLs.  Seems like we're
> screwing the elegant-ness of our code just to avoid some restriction their
> compiler imposes on us.  do they have a static version of that DLL?  that
> could solve it maybe.

VC++ strings aren't 100% inlined either.  You can do static builds, but you
can't statically link to libc++ and dynamically to libc at the same time.  :(  I
agree, it does suck, but a lot of thing sucks and sometimes it's worth it to
work around them.  And ideally, you should have already abstracted out I/O so
you can support UTF-8 and whatnot in Windows.  ;)

> I agree with you, few depends is exactly what I was going for.  but I
> don't take that literally.  I take it to mean only few _third_party_
> depends.

Okay.  Either way, it's pretty easy to get away with not using std::string and
std::vector, especially when the benefits are there.

> my philosohy is, if it comes with the compiler, you can always distribute
> it with the code, no big deal, if it annoys you, choose a different
> compiler.. :)  otherwise, avoid other 3rd party libs as much as possible.
> my PCX, SGI, BMP, TGA loaders are all stand-alone.  the PNG one I wrote
> needs zlib only...

If that's your philosophy, that's fine by me.  :)  But I don't go by that
philosophy.  ;)  There are other things to take into account, and DLL/download
size (unfortunately) is one of them.

At least I don't follow the Mozilla C++ coding rules! 
http://www.mozilla.org/hacking/portable-cpp.html