Re: Excessive use of 'this' and performance
Al wrote:
James Kanze wrote:
Al wrote:
<snip>
However, in C++, I disagree. Wasn't this what namespaces were supposed
to address? Wasn't it the idea that by including that header, you would
be protected from its clutter?
Sort of. Not that they really buy us much---I don't see a large
difference between mysql_set_local_infile_handler and
mysql::set_local_infile_handler in practice. And I suspect that
most of the cases where a symbol gets hidden are in base
classes, and not globals strictly speaking.
I think you're downplaying some of the advantages. A single function
interacting with the database might make 10-20 calls to the API. That's
a whole lot of mysql_* clutter that you could cut down with a simple:
using namespace mysql;
So the functions in question have two different names, and I
know longer know which function comes from where.
Furthermore, it can really help when these things nest and start forming
hierarchies. For instance, I could not even imagine how the .NET
framework libraries would work without namespaces.
Without them, we'd be stuck with true monstrosities like:
System_Web_UI_HtmlControls_HtmlInputRadioButton* button = new
System_Web_UI_HtmlControls_HtmlInputRadioButton(...);
System_Web_UI_HtmlControls_HtmlLink* link = new
System_Web_UI_HtmlControls_HtmlLink(...);
System_Web_UI_HtmlControls_HtmlTableCell* cell = new
System_Web_UI_HtmlControls_HtmlTableCell(...);
It'd be hideous, verbose and ultimately unmanageable, I think.
Contrast:
using System::Web::UI::HtmlControls;
HtmlInputRadioButton* button = new HtmlInputRadioButton(...);
HtmlLink* link = new HtmlLink(...);
HtmlTableCell* cell = new HtmlTableCell(...);
And these aren't esoteric or contrived examples. I just looked over
similar code recently.
I'd say that sort of proves my point. The latter is bad
practice, in that you end up not knowing where each function
comes from. And because you can do it, people end up creating
such nested attrocities.
[...]
Thanks! I hadn't thought of that, and it's a good point. I think in C#
this isn't as big a problem because naming conventions encourage things
like MemberName for public, _memberName or m_MemberName for
private/protected, and memberName for locals, so there would be a very
small chance of anything colliding.
Every C++ project I've been on has had a naming convention which
differentiates members and local variables. And has forbidden
"using namespace" (except in some cases very locally). The
result is that between SomeLib::someSymbol, mySomeSymbol (or
m_SomeSymbol) and someSymbol, I've never seen a collision. In
practice, the current rules don't cause problems, even if they
don't enforce good practice.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]