From: fogal"@tfslaptop.uni-due.de
{ The quoting is getting excessive. Please trim your quoting and try to
include only the minimum necessary to establish the context. -mod }
On 2013-02-05, Ian Collins wrote:
> tom fogal wrote:
>> Hi, thanks for the replies, some minor clarifications below.
>>
>> On 2013-01-30, Ian Collins wrote:
>>> tom fogal wrote:
>>>> On 2013-01-28, Ian Collins wrote:
>>>>> tom fogal wrote:
>>>>>> I often hit a problem testing code and haven't seen a good solution
>>>>>> for it. The issue is that I typically want to test code which is not
>>>>>> 'exposed' and I'm curious if anyone has a better solution than I do.
>>>>>
>>>>> The best technique is to expose the functionality.
>>>>>
>>>>>> Here's a very simplified example: a module 'A' exposes a function 'F'.
>>>>>> Internally, 'F' calls a function 'internal', which I'd like to test.
>> [snip]
>>>>> Consider putting the work done by internal() in to a discrete class of
>>>>> its own and test that. The more complexity from F() you can extract
>>>>> into testable components, the easier it is to test (and maintain) it.
>> [snip]
>>>> Now my
>>>> file containing 'F's definition has to include/read another file. All
>>>> of the internal() symbols are now external,
>>>
>>> Or part of the new object.
>>>
>>>> bloating my executables.
>>>
>>> ?
>>
>> I almost hate to berate the topic, because you're getting me to
>> agree on other grounds, but these symbols then appear in my
>> executable. If I have a bunch of static functions in a translation
>> unit, they might as well not be there when the final piece of
>> software is built. Once they become non-static, they exist in my
>> executable. Therefore, my executables become larger.
>
> I still don't see how. Yes an executable with debugging information
> will contain more symbols, but a stripped executable will not.
I just double-checked in both gcc-based and llvm-based
environments, and this is actually not the case. Stripped or no,
the lack of 'static' on a function creates larger executables. The
size increase is proportional to the function name (i.e. symbol
name, I imagine).
I don't MSVC available to me at the moment.
[snip]
>>> I have a large number of what are now utility classes that started life
>>> as private functionality extracted from other classes. The "improved
>>> code reuse" argument for object extraction isn't a myth. So the long
>>> term effect, to coin your phrase, is reduced physical entropy of my
>>> code. I have less duplicated code doing similar work.
>>
>> I am not sure we are using the same terminology. I am using
>> "physical" to refer to the more obvious mechanics of how source
>> code relates. Number of includes in a file. Places where an
>> external library is interfaced. Etc.
>
> OK. I've never considered those to be a metric worth considering. Even
> one included header can bring in dozens of nested library headers, so
> why worry?
I put forth at least a modicum of effort in my current primary
codebase to ensure the set of includes is minimal. I like to think
that we interface to external libraries in one place and one place
only, so only that interface ends up pulling in the library / all
the headers it may need.
Of course, this changes over time and is so is never perfect.
I've worked on projects which are less diligent about this, and
found build times quickly go through the roof. I've also seen
codebases which more diligent, and they are joyous to work with.
I guess we've strayed far off-topic now, but nonetheless still
interesting territory. I'd be very interested in your/others'
alternative methods for keeping build times under control.
-tom
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
