Productivity in programming of C++ programmers

[lilburne]

Re: Productivity in programming of C++ programmers

Siemel Naran wrote:[color=blue]
> "lilburne" <lilburne@godzi lla.net> wrote in message
> news:2o4qhhF6tj asU1@uni-berlin.de...
>[color=green]
>>
>>and within the A.i file you write
>>
>>#ifndef OUTLINE
>>inline A::A(int i) : m_i(i) {}
>>#endif[/color]
>
>
> All my compilers let you debug inline functions (Borland 6, MSVC 7, MSVC 6,
> gdb g++).
>[/color]

Hmmm! Can you set a breakpoint or just step in?

[Siemel Naran]

Re: Productivity in programming of C++ programmers

"lilburne" <lilburne@godzi lla.net> wrote in message
news:2o64haF75o d4U1@uni-berlin.de...[color=blue]
> Siemel Naran wrote:[/color]
[color=blue][color=green]
> > All my compilers let you debug inline functions (Borland 6, MSVC 7, MSVC[/color][/color]
6,[color=blue][color=green]
> > gdb g++).[/color]
>
> Hmmm! Can you set a breakpoint or just step in?[/color]

Both, at least on Borland 6! I just tried to set a breakpoint. I put
breakpoints in non-template functions. My file structure is: source code in
src\libname\fil e.cpp, and the headers are include\libname \various.hpp. Put
a breakpoint in any of the various files in the include directory, and the
debugger will hit the breakpoint. Thinking about it, I think that in debug
build the compiler makes all functions non-inline, so of course you should
be able to step through it. Presumably if you debug the release .exe or
..lib or .dll, stepping through individual assembly instructions, you won't
hit the breakpoint because if the code is really inline it won't be in the
..exe. Anyway, I don't have the bandwidth to test this.

Nevertheless, the rule about making all functions non-inline unless
profiling says to do so is a good one. I break the rule so that I don't
have to write lots of little short get/set functions in the cpp file. It's
a timesaver, and worth it. Though by the premise of the original post of
this thread it means I'm un unproductive programmer because I have fewer
lines of code :). However, if I have a file that has just one get/set
function, while the rest are long functions defined in the cpp file, then
I'll make the one get/set function pair (two functions), non-inline and
defined in the cpp file, just for consistency with the other functions.

[lilburne]

Re: Productivity in programming of C++ programmers

Siemel Naran wrote:
[color=blue]
> "lilburne" <lilburne@godzi lla.net> wrote in message
> news:2o64haF75o d4U1@uni-berlin.de...
>[color=green]
>>
>>Hmmm! Can you set a breakpoint or just step in?[/color]
>
>
> Both, at least on Borland 6! I just tried to set a breakpoint. I put
> breakpoints in non-template functions. My file structure is: source code in
> src\libname\fil e.cpp, and the headers are include\libname \various.hpp. Put
> a breakpoint in any of the various files in the include directory, and the
> debugger will hit the breakpoint. Thinking about it, I think that in debug
> build the compiler makes all functions non-inline, so of course you should
> be able to step through it. Presumably if you debug the release .exe or
> .lib or .dll, stepping through individual assembly instructions, you won't
> hit the breakpoint because if the code is really inline it won't be in the
> .exe. Anyway, I don't have the bandwidth to test this.
>[/color]

Probably some weirdness in the linker too to make it work
across libraries.
[color=blue]
> Nevertheless, the rule about making all functions non-inline unless
> profiling says to do so is a good one. I break the rule so that I don't
> have to write lots of little short get/set functions in the cpp file. It's
> a timesaver, and worth it. Though by the premise of the original post of
> this thread it means I'm un unproductive programmer because I have fewer
> lines of code :). However, if I have a file that has just one get/set
> function, while the rest are long functions defined in the cpp file, then
> I'll make the one get/set function pair (two functions), non-inline and
> defined in the cpp file, just for consistency with the other functions.
>[/color]

Consistency is a good thing. Personally I prefer not to have
implementation details in the headers just the API. I can
just about tolerate member variables, but to each their own.
I prefer to look in just one place (the source file) for
implementation rather than first looking in the source and
then having to go to the header. Anyone equating LOC and
programmer productivity is talking out of their arse.

[Siemel Naran]

Re: Productivity in programming of C++ programmers

"lilburne" <lilburne@godzi lla.net> wrote in message
news:2o79obF7ph 62U1@uni-berlin.de...
[color=blue]
> Consistency is a good thing. Personally I prefer not to have
> implementation details in the headers just the API. I can
> just about tolerate member variables, but to each their own.
> I prefer to look in just one place (the source file) for
> implementation rather than first looking in the source and
> then having to go to the header. Anyone equating LOC and
> programmer productivity is talking out of their arse.[/color]

You can have member variables in the cpp file. Look up the pointer to
implementation concept, where in the header you declare for example a nested
struct Imp, give your class a pointer or smart pointer to this Imp, and
freely define it in the cpp file. You insuluate derived classes from length
recompiles, plus you can easily add reference counting to your class now.

What is LOC?

[Siemel Naran]

Re: Productivity in programming of C++ programmers

"lilburne" <lilburne@godzi lla.net> wrote in message
news:2o79obF7ph 62U1@uni-berlin.de...[color=blue]
> Siemel Naran wrote:[/color]
[color=blue][color=green][color=darkred]
> >>Hmmm! Can you set a breakpoint or just step in?[/color]
> >
> > Both, at least on Borland 6! I just tried to set a breakpoint. I put
> > breakpoints in non-template functions. My file structure is: source[/color][/color]
code in[color=blue][color=green]
> > src\libname\fil e.cpp, and the headers are include\libname \various.hpp.[/color][/color]
Put[color=blue][color=green]
> > a breakpoint in any of the various files in the include directory, and[/color][/color]
the[color=blue][color=green]
> > debugger will hit the breakpoint. Thinking about it, I think that in[/color][/color]
debug[color=blue][color=green]
> > build the compiler makes all functions non-inline, so of course you[/color][/color]
should[color=blue][color=green]
> > be able to step through it. Presumably if you debug the release .exe or
> > .lib or .dll, stepping through individual assembly instructions, you[/color][/color]
won't[color=blue][color=green]
> > hit the breakpoint because if the code is really inline it won't be in[/color][/color]
the[color=blue][color=green]
> > .exe. Anyway, I don't have the bandwidth to test this.[/color]
>
> Probably some weirdness in the linker too to make it work
> across libraries.[/color]

I think the reason is that I compiled my library parse.lib in debug mode
into a debug lib file. Then I compiled my example.exe, and linked against
the debug parse.lib file, and I was therefore able to put breakpoints in the
inline function. Had I linked against the release parse.lib file, that
would probably not have been the case.

In the past, I found that creating a release parse.lib file, then compiling
example.exe in debug mode and linking against the release parse.lib file
caused my program to mysteriously crash at runtime. The reason I think is
that the class headers of the parse library define STL member variables,
like std::string, std::deque, etc. The parse.lib compiled in release mode
links against the release STL files, performs various compiler
optimizations, etc. My example.cpp includes the same headers, but compiles
in debug mode, so it does not do various optimizations, assumes that the
parse.lib file will link against the debug STL files, etc. So if both
parse.lib and example.exe are compiled in release mode, or both in debug
mode, then it works fine.

When I get more time, I'm going to use the pointer to implementation idea,
and define a nested struct Imp, and define it with all the STL member
variables in the cpp file. This might allow me to compile and run a debug
example.exe linked against a debug parse.lib.

[lilburne]

Re: Productivity in programming of C++ programmers

Siemel Naran wrote:
[color=blue]
> "lilburne" <lilburne@godzi lla.net> wrote in message
> news:2o79obF7ph 62U1@uni-berlin.de...
>[color=green]
>>
>>Probably some weirdness in the linker too to make it work
>>across libraries.[/color]
>
>
> I think the reason is that I compiled my library parse.lib in debug mode
> into a debug lib file. Then I compiled my example.exe, and linked against
> the debug parse.lib file, and I was therefore able to put breakpoints in the
> inline function. Had I linked against the release parse.lib file, that
> would probably not have been the case.[/color]

I'd sort of assumed that. What I was thinking about was just
how the debugger/linker resolves the situation where you
have inline functions defined in libA which are used by both
libB and libC. Perhaps it ignores multiple definitions.
[color=blue]
> In the past, I found that creating a release parse.lib file, then compiling
> example.exe in debug mode and linking against the release parse.lib file
> caused my program to mysteriously crash at runtime.[/color]

I recall a number of years ago that mixing and matching
release/debug in VC++ didn't work too well (and we don't use
the STL). A colleague killed the idea of mixing modes all
together by making our class sizes differ between
release/debug anyway.

[lilburne]

Re: Productivity in programming of C++ programmers

Siemel Naran wrote:
[color=blue]
> "lilburne" <lilburne@godzi lla.net> wrote in message
> news:2o79obF7ph 62U1@uni-berlin.de...
>
>[color=green]
>>Consistency is a good thing. Personally I prefer not to have
>>implementatio n details in the headers just the API. I can
>>just about tolerate member variables, but to each their own.
>>I prefer to look in just one place (the source file) for
>>implementatio n rather than first looking in the source and
>>then having to go to the header. Anyone equating LOC and
>>programmer productivity is talking out of their arse.[/color]
>
>
> You can have member variables in the cpp file. Look up the pointer to
> implementation concept, where in the header you declare for example a nested
> struct Imp, give your class a pointer or smart pointer to this Imp, and
> freely define it in the cpp file. You insuluate derived classes from length
> recompiles, plus you can easily add reference counting to your class now.[/color]

There is something to be said for the Chesire Cat trick as
it stops inlining altogether. On the downside it can make
whitebox testing harder. Besides the lengthy recompiles
usually come about through changes to low level classes
which in my experience don't tend to change their
implementation much anyway.
[color=blue]
> What is LOC?[/color]

Lines Of Code.