By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,671 Members | 1,633 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,671 IT Pros & Developers. It's quick & easy.

Productivity in programming of C++ programmers

P: n/a
May I ask how productivity of a(C++) programmer can be measured?
If it is measured by number of code lines per day, what are the
estimated productivity of a programmer at beginer, intermediate (Me),
advance, master, guru,and sifu (B.Stroustrup, H.Sutter, S. Meyer)?
Thanks for your guidance.

P/S: Similar post has been sent to comp.lang.c++.moderated (probably
takes longer time)
Jul 22 '05
Share this Question
Share on Google+
51 Replies

P: n/a
Siemel Naran wrote:
"lilburne" <li******> wrote in message

Probably some weirdness in the linker too to make it work
across libraries.

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.

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.
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.

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.
Jul 22 '05 #51

P: n/a
Siemel Naran wrote:
"lilburne" <li******> wrote in message

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.

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.

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.
What is LOC?

Lines Of Code.

Jul 22 '05 #52

51 Replies

This discussion thread is closed

Replies have been disabled for this discussion.