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

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-27 18:43:44

Throughout my career my software has needed to be at least as fast, and a
least as reliable, as the competition.  Worse, the growing size of the
problems that customers need to solve, and unconstrained bloat in operating
system software, has more than used up the extra speed and memory that
newer hardware provides.  So for me, a slow design is a bad design, and an
incorrect design is no design at all.

And of course we are way, way off topic by now.

At 04:11 PM 8/27/2002, Eric Woodruff wrote:
>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