RE: [boost] Re: Re: Re: #ifndef paradigm

From: David Bergman (davidb_at_[hidden])
Date: 2002-08-27 18:48:39

Eric,

I totally agree with you on the optimizing angle. There is far too much
focus on that in certain communities and software libraries. The reason
for me to have co-dependencies would not be to "optimize" performance,
but rather that some problems and their solutions lend themselves
conceptually well to a mutually recursive framework.

(I can see the man with the moderator hat coming now...)

/David

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Eric Woodruff
Sent: Tuesday, August 27, 2002 6:12 PM
To: boost_at_[hidden]
Subject: [boost] Re: Re: Re: #ifndef paradigm

That just goes back to the old idea of programmers solidifying their
profession and future employment. A good design will save a company
thousands of dollars (based on man hours at a developers average
salary). For an inhouse project, it's likely cheaper to buy all new
computers then to "optimize" the software. And even if they did optimize
it, it would be specific to the old platform. Once they were forced to
upgrade in 2 years to keep up with the times, the "optimization" would
now run slower. (Reflecting on cost again, there are plenty of developer
hours spent un-optimizing old
code.)

For end-user software, people are complacent with slow applications all
the time (which are likely cause because some team leader decided that
in their framework, the ostensible overhead of a virtual function
pointer was too much compared to their method of using a C-style array,
a 40 line switch statement and a lookup of some data in a heap tree).

No matter how you personally justify so-called unacceptability of
runtime costs in a domain, the justification is moot while the lifetime
of the software is just beginning.

Which design do you want to live with for 5 years? The reach of your
decision goes way beyond the C++ programmer community.

(There are limited situations where optimization is necessary, just like
there were exceptions to everything I pointed on on this thread.
However, that doesn't mean that the optimization is the correct general
implementation, it is a domain-specific implementation. Any
implementation like that should be designed so it can instantly be
replaced with its correct counter-part when the time comes, because it
always does. An optimization should be explicit and/or difficult to use
so it promotes its own removal -- a required parameter at build time for
instance.)

You will often find a bad design many more times than you will find a
true optimization (probably put there because another bad design created
the bottleneck!). A bad design is unfit and noisey -- one sign is that
the implementation is full of a lot of pedestrian code around a method
call just to prepare to call the method.

Interestingly, computers are very adaptive. If the developer fails to
spend time thinking, the computer will take the hit and spend time
processing. (I don't consider a dereference processing. Nor do I
consider object allocation to be overhead -- It is part of the runtime
system that allows highlevel concepts to be represented. These concepts
bridge the gap between the hardware and the end user, allowing the
system to directly and efficiently perform what the user needs in an
acceptable amount of time.)

----- Original Message -----
From: Rob Stewart
Newsgroups: gmane.comp.lib.boost.devel
Sent: Tuesday, 2002:August:27 16:53
Subject: Re: Re: Re: #ifndef paradigm

From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
>
> In any example, so complex as that, certainly the interface of 
> Location would not expose the fact that its implementation depends on 
> road
segments.
> Any pure OO concept generally has to have the separation between 
> interface and implementation.
>
> Co-dependent headers means you have a bad design. Period. (I'm not 
> saying that there are NEVER situations where one might have 
> codependent in
lowlevel
> headers of some framework, but it is rare, and a comment is necessary 
> to explain why that lowlevel header had to violate idealism.)

I quite disagree with your unequivocal declaration.  Real life sometimes
rears its head and requires that you forgo OO purity, particularly when
the alternative involves more expensive approaches.  For example, using
the Pimple idiom is a great way to avoid such dependencies in headers,
but it carries runtime costs that may not be acceptable in a given
domain or application.

One can say that one should avoid cross-header dependencies, but one
cannot be so dogmatic as to say that failure to avoid them means, by
definition, the design is wrong.  Clearly, in a particular domain, one
may have the luxury of stating that they must be avoided, but that
doesn't generalize to the entire C++ programming community.

--
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost