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

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-08-27 17:11:38

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