[isugamedev-devel] re[6]: imagelib

[Kevin M. <ke...@vr...>]

> 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

you write your own?  yuk...  i think code reuse is more important than lib 
size.  these really should be inlined.  i guess we 
could use stlport instead, but that might not be good either (whole new 
set of problems).


200k dll depending on a 400k dll isn't bad or pretentious.  more of my 
philosophy:  size doesn't matter, functionality does.  I think it's really 
powerful if a lib gives you an easy interface with as little code to 
maintain as possible.  this usually means more code behind the scenes, 
which I think is ok, and explains the 200k/400k thing as totally ok. 

I think it is especially ok when you're only adding on an extra 400k, 
400k is small if you consider that you're getting well tested code 
that you don't have to personally maintain.  I'd rather invest 
my time into the game, and not into string, vector, list code. :(

kevin


On Wed, 16 Jan 2002, Chad Austin wrote:

> > 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
> 
> _______________________________________________
> ISUGameDev-devel mailing list
> ISU...@li...
> https://lists.sourceforge.net/lists/listinfo/isugamedev-devel
> 

-- 
@--@---@---@----@-----@------@------@-----@----@---@---@--@
Kevin Meinert                                  __  _   __  
http://www.vrac.iastate.edu/~kevn         \  ||  \| \ /  ` 
Virtual Reality Applications Center        \ ||.-'|--\\    
Howe Hall, Iowa State University, Ames Iowa \||  \|   \`__,
-----------------------------------------------------------