|
Nemanja Trifunovic wrote:
Actually, my managers are ex-developers themselves, and we were a "real" software development shop before being bought by a localization company, so we try to keep all the good practices we once developed.
I suspected as much, my friend. Ex-developers can make the best managers, as they understand what we must deal with. The worst managers and executives I've ever had to deal with, simply didn't understand programming or the language/platform.
I've gone through a few company buy-outs, and none of them have been easy. If they keep those managers and trust them, things will go much better. My support is with you in maintaining the developer's art and the quality of code into the 21st century.
Cheers
|
|
|
|
|
Jim A. Johnson wrote:
Except when we have to deal with other programmers who absolutely refuse to use it, and who throw fits if "their" code is modified...
Oh, do I feel your (our) pain, Jim!
This is a fickle field, where designers may dictate ludiculously rigid interface prototypes that don't always fit, and primadonnas insist their code is "perfect".
I must be very out of place: when others have fixed or improved my code, I invariably thank them (unless they botched it). Why shouldn't I? They've saved me time and aggravation, while giving "my" code a better reputation. But if someone helps them, they throw fits, even if the changes are documented. I guess that's what they call "team spirit".
Cheers
|
|
|
|
|
Before anything else, const is a modifier that speaks to the programmer who is reading the code that the object in question is not meant to change its state.
Maybe the compiler can use this as a side effect and make things more optimal.
Still, there is an optimisation that I always use.
// notice argument is "const reference"
// meaning "don't copy the string, just pass a pointer (aka a reference) to it"
// also meaning "i promise that I will not change the original value"
void printName( const CString& name ) <br />
{<br />
cout << name << endl;<br />
}
// here the name object is simply copied (copy constructor invoked)
// notice that at least, this version requires
// (a) construction
// (b) destruction
// (c) copy
void printNameCopy( CString name )<br />
{<br />
cout << name << endl;<br />
}
|
|
|
|
|
FWIW, CString's copy constructor doesn't copy the string data unless the source string is locked - so in most cases, there's not too much savings gained by passing a CString reference over value. However, as you noted it does eliminate the overhead of two method calls (constructor/destructor), and so in tight loops this may be a worthwhile distinction.
"The time has come," the Walrus said,
"To talk of many things..."
|
|
|
|
|
Shog9 wrote:
CString's copy constructor doesn't copy the string data unless the source string is locked - so in most cases, there's not too much savings gained by passing a CString reference over value
Very true, but replace CString by almost any class or structure following the "concrete data type" with or without "copy on write", and the savings (aka optimisation) remains.
My point, however, is this:
When you pass a "const reference" const X&, you save a lot.
- the called method does not have to test for a NULL pointer.
- construction and destruction are not needed.
- the intention is made clear to the ultimate audience: the programmer who maintains the code.
I must point out that often I pass a const pointer, for cases where an argument is optional and my method must deal with presence or absence of a parameter.
Going back on something months or years later, I can immediatly tell whats going on.
References, const or otherwise, are your friend!
|
|
|
|
|
you are hitting you head against wall :headbang: 
|
|
|
|
|
It makes a huge difference
<italic>Work hard and a bit of luck is the key to success. You don`t need to be genius, to be rich.
|
|
|
|
|
.. customers or testers complain about it enough...
An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.
|
|
|
|
|
I never optimize my code on the first pass at writing an app. I usually wait until it gets passed the first QA trials to see how it performs. If there are noticeable bottlenecks then I'll take a second pass at the code.
Over the years I've learnt what is optimal code for many situations, so my first pass code is probably better optimized than if I was just starting out as a developer. Although in things like SQL, I'm still learning faster ways of doing things.
Michael
CP Blog [^]
|
|
|
|
|
I learned never to optimize code in the first pass of the development.
If all errors have been fixed, you can start optimizing things.
I work mostly with realtime systems, and these are already very fast. Since there's no OS like Windows installed on these systems.
So optimizing has no use most of the time.
"Every rule in a world of bits and bytes can be bend or eventually be broken"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
