[boost] Re: config.h[pp]

From: Reid Sweatman (reids_at_[hidden])
Date: 1999-07-15 16:40:30

> Well, there are several reasons why I really don't want to deal
> with this configuration stuff for non-standard compilers:
> - It is aweful work which sometime has significant impact on 
> the interface.
> - It kind of "blesses" this non-standard compiler.
> - It is more work.
> - I have used more than just egcs and found that there are 
> several compilers
>   which are sufficiently close to the standard to need no 
> work arounds.

I can understand that.  I wasn't really asking for every person who submits
code to Boost to write workarounds into his code; just that the library
ought to contain something that does so, whether it's a header file,
documentation, or whatever.

> Actually, this issue, namely a way to compile code for all platforms,
> would be much more interesting than the configuration stuff.

I don't know about more interesting <g>, but certainly more useful.

> Although none of the compilers is standard conforming, most implement
> all functionality which effects the actual interface. I think that
> I'm not limiting my code to a faction of the current compilers! What
> I have seen from EDG (this is the front-end eg. of the C++ compiler
> shipped by SGI, Siemens, Intel (I think), Comeau, KAI), 
> Visual Age C++,
> and egcs, and what I have heard about Metrowerk's, SUN's, and 
> HP's compiler
> I'm quite sure that these compile my code. This already covers a large
> range of platforms... And even if my code only compiles with egcs, if
> this makes an argument why egcs should be used in favor of some other
> compiler, this suits me fine!

Well, in terms of the compilers accounting for the bulk of released code,
all the compilers you name *are* a small fraction.  That's a very real
consideration for those of us who are forced to work with certain compilers.

> Just to make things clear: I'm not opposed to any form of 
> configuration
> header which is used to deal with functionality outside the 
> scope of the
> C++ standard (eg. file system access, GUI, threads, etc.). 
> However, I don't
> see any point in a configuration header which deals with 
> missing standard
> C++ features. ... and I think we agreed on standard C++ code anyway!

Yeah, I'd basically agree with all that.  And while I know that MS is much
more generally hated in Europe, and particularly Germany (got several
friends there, and they're uniform on that attitude <g>) than in the States,
I'd still like to personally kick Billy G.'s butt for the heel-dragging
"not-invented-here" syndrome.  I've got several friends working at MS, and
*they* have the same attitude towards the tools they have to work with <g>.

As for implicitly condoning a non-compliant implementation, I think the
effect will actually be the reverse; there's such a huge installed base of
VC++ that the effect of not providing work-arounds will be to make users not
use the Boost library.  Now before you say that's a good thing, I'd argue
that having a lot of people using good, compliant code, and having it made
obvious to them that it's being heavily kludged for their compiler will make
them either switch compilers or complain loudly in numbers to MS.  Either
way, I'd say that was a win.

On the other hand, I perfectly agree with your attitude on the time and
effort involved.  I've often worked as a consultant myself, and like you, I
don't do anything I don't get paid for.  As I said, I was hoping for an
over-riding mechanism of some sort that would involve minimal work for those
writing Boost libraries to include, or even just a set of docs on how to
modify Boost code for compliance.  As I said in another post, I'd be willing
to work on such a thing, save that I'm *still* discovering ways in which
VC++ is non-compliant.  I believe someone commented that VC++ 6.0 SR3 is
still supporting only the 1996 working-spec of C++.  At first, when I heard
that we may be switching to CodeWarrior, I was aghast at having to learn yet
another product with a steep learning curve while trying to do production
code.  But if it's really compliant and has a decent editor and optimizer,
I'm all for it.  On the topic of Gcc, I haven't looked at it in a few years,
but I once tore apart some of its modules to fix some bugs, and I was
horrified at the general code quality; it may be compliant, but personally,
I find it hard to trust spaghetti like that was.  One program was nothing
but an 8,000-line switch statement.  Good Lord!  Maybe that's changed by
now, but I doubt it; codebases take on a life of their own and get
perpetuated forever.  I should know...I inherited one that was supposed to
have been retired two projects ago when I took my current job <g>.  That's
added up to making a project I could have coded from scratch in two months
take more than six.

Anyway, on a totally different tack, had you considered combining a hash
lookup with one of your DPQ classes?  I've gone over your code now (some
nice work there, BTW), and think I can append hashing to the f_heap class
fairly easily.  In games, you quite often need a cache manager that accesses
things much more frequently than it changes their priorities.  In a case
like that, it's often much faster (with careful size tweaking after doing
some profiling) to do the lookups via hash, and the priority changes via the
tree.  Actually, you could speed things a bit more by hashing to find a node
to change priorities on, and use the tree only when popping from the queue,
thus substituting an amortized constant cost for a logarithmic one much of
the time.

I'd also like to ask if you ever considered using splay trees?  Too much
restructuring overhead?  I'm not sure, but it might actually have lower
overhead, because while it tends to move more things around, it has slightly
more efficient operations to do so.  Most other trees use a sort of bubble
sort to restore the heap invariant.  I guess there might be a break point in
N where one became more efficient than the other.  Anyway, I digress into
rambling mode (I'm a ramblin' guy... <g>).

Oh, is the copy you e-mailed me still your latest, or have you posted a
newer one somewhere.  At this point I'm pretty sure I'll either use your
f_heap template as is, or write one based on it that's more focused on my
particular application statistics.

Hmmmn.  I guess there's one other thing that had occurred to me, too.  In
the f_heap template you store the data in the nodes, but in the d_heap you
use the tree for lookup into a container class, list.  It occurred to me
(while trying to solve the cache manager problem I mentioned, and with a
mental nudge from Andy Glew--thanks, Andy-- that you could also use the SGI
STL hash_map class as the base container and combine hashing with d_heap's
that way.  Of course, the tree restructuring would be a tad messier than for
f_heaps.  I guess the real objection you'd have would be that hash_map isn't
part of the C++ standard.  But what the hey, you could write your own.  Or
that might be a decent addition to Boost in its own right.  Anyway, I've
taken too much of your time already (all too easy to do when you type 90
wpm--I trained as a concert pianist <g>).

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications