Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #15273 > unrolled thread

Methods for understanding complex, real world, C++ code?

Back to article view | Back to comp.lang.c++

Contents

  Methods for understanding complex, real world,  C++ code? mathog <dmathog@gmail.com> - 2012-04-10 08:54 -0700
    Re: Methods for understanding complex, real world, C++ code? "K. Frank" <kfrank29.c@gmail.com> - 2012-04-10 12:55 -0700
      Re: Methods for understanding complex, real world, C++ code? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 09:23 -0700
        Writing extensions, like VBA "macros", Perl or JavaScript.  @Jeff-Relf.Me - 2012-04-11 11:22 -0700
        Re: Methods for understanding complex, real world, C++ code? Lynn McGuire <lmc@winsim.com> - 2012-04-11 14:35 -0500
        Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-11 21:53 +0000
          Re: Methods for understanding complex, real world, C++ code? mathog <dmathog@gmail.com> - 2012-04-12 12:01 -0700
        Re: Methods for understanding complex, real world, C++ code? "K. Frank" <kfrank29.c@gmail.com> - 2012-04-11 16:06 -0700
        Re: Methods for understanding complex, real world, C++ code? Christopher Pisz <someone@somewhere.net> - 2012-04-12 11:46 -0500
        Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-12 22:32 -0400
          Re: Methods for understanding complex, real world, C++ code? nick_keighley_nospam@hotmail.com - 2012-04-13 02:16 -0700
            Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-15 10:21 +0000
              Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-15 19:33 -0400
                Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-16 09:59 +0900
                  Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-15 21:32 -0400
                    Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-17 09:32 +0900
                      Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-17 02:06 +0000
                        Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-17 11:35 +0900
                        Re: Methods for understanding complex, real world, C++ code? Ian Collins <ian-news@hotmail.com> - 2012-04-17 16:06 +1200
                          Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-17 15:24 +0000
                            Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-18 04:50 +0900
                              Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-17 20:18 +0000
                                Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-18 10:31 +0900
                                  Re: Methods for understanding complex, real world, C++ code? scott@slp53.sl.home (Scott Lurndal) - 2012-04-18 01:36 +0000
                                    Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-18 11:00 +0900
                      Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-18 22:09 -0400
                        Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-19 11:41 +0900
                          Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-18 23:04 -0400
                            Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-19 13:33 +0900
                        Re: Methods for understanding complex, real world, C++ code? Ian Collins <ian-news@hotmail.com> - 2012-04-19 15:56 +1200
                          Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-19 22:54 -0400
                            Re: Methods for understanding complex, real world, C++ code? Miles Bader <miles@gnu.org> - 2012-04-20 14:31 +0900
                Re: Methods for understanding complex, real world, C++ code? Tobias Müller <troplin@bluewin.ch> - 2012-04-16 06:39 +0000
                  Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-18 22:25 -0400
                    Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-19 13:58 +0000
                      Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-19 23:39 -0400
                        Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-22 16:37 +0000
                    Re: Methods for understanding complex, real world, C++ code? Dombo <dombo@disposable.invalid> - 2012-04-19 23:20 +0200
                      Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-19 23:54 -0400
                Re: Methods for understanding complex, real world, C++ code? nick_keighley_nospam@hotmail.com - 2012-04-17 03:50 -0700
                  Re: Methods for understanding complex, real world, C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-17 12:01 +0000
    Re: Methods for understanding complex, real world,  C++ code? Ian Collins <ian-news@hotmail.com> - 2012-04-11 08:04 +1200
    Re: Methods for understanding complex, real world,  C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-10 22:26 +0000
      Rewrite it.  @Jeff-Relf.Me - 2012-04-10 16:31 -0700
        Re: Rewrite it.  nick_keighley_nospam@hotmail.com - 2012-04-11 01:20 -0700
          Re: Rewrite it.  Rui Maciel <rui.maciel@gmail.com> - 2012-04-11 10:06 +0100
            Re: Rewrite it.  nick_keighley_nospam@hotmail.com - 2012-04-11 03:45 -0700
              Building a "house" that you can live in for decades to come.  @Jeff-Relf.Me - 2012-04-11 08:52 -0700
                Re: Building a "house" that you can live in for decades to come.  Miles Bader <miles@gnu.org> - 2012-04-12 13:19 +0900
      Re: Methods for understanding complex, real world, C++ code? "K. Frank" <kfrank29.c@gmail.com> - 2012-04-10 17:37 -0700
        Re: Methods for understanding complex, real world, C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-12 21:40 -0400
    Re: Methods for understanding complex, real world,  C++ code? michael.boehnisch@gmail.com - 2012-04-10 17:29 -0700
      Re: Methods for understanding complex, real world,  C++ code? Rui Maciel <rui.maciel@gmail.com> - 2012-04-11 10:02 +0100
    Re: Methods for understanding complex, real world,  C++ code? jgk@panix.com (Joe keane) - 2012-04-11 22:36 +0000
      Re: Methods for understanding complex, real world, C++ code? Noah Roberts <roberts.noah@gmail.com> - 2012-04-11 16:05 -0700
        Re: Methods for understanding complex, real world, C++ code? Robert Wessel <robertwessel2@yahoo.com> - 2012-04-11 19:37 -0500
    Re: Methods for understanding complex, real world,  C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-12 21:48 -0400
      Re: Methods for understanding complex, real world,  C++ code? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-04-15 09:56 +0000
        Re: Methods for understanding complex, real world,  C++ code? Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2012-04-15 19:43 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#15433 — Re: Methods for understanding complex, real world, C++ code?

scott@slp53.sl.home (Scott Lurndal) writes:
>>Where these recent projects?  It took a while for namespaces to be 
>>widely used after they were introduced in the '98 standard.
>
> About half before, the other half after.   However, since none of them
> used STL (see above), namespaces weren't that useful.

What do namespaces have to do with the STL...?

-miles

-- 
Brain, n. An apparatus with which we think we think.

[toc] | [prev] | [next] | [standalone]

#15434 — Re: Methods for understanding complex, real world, C++ code?

Miles Bader <miles@gnu.org> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>>Where these recent projects?  It took a while for namespaces to be 
>>>widely used after they were introduced in the '98 standard.
>>
>> About half before, the other half after.   However, since none of them
>> used STL (see above), namespaces weren't that useful.
>
>What do namespaces have to do with the STL...?
>

Ok.  I used STL here to refer to the standard C++ library which
includes std:: namespace et alia.   My bad.   We used none of that.

scott

[toc] | [prev] | [next] | [standalone]

#15441 — Re: Methods for understanding complex, real world, C++ code?

scott@slp53.sl.home (Scott Lurndal) writes:
>>>>Where these recent projects?  It took a while for namespaces to be 
>>>>widely used after they were introduced in the '98 standard.
>>>
>>> About half before, the other half after.   However, since none of them
>>> used STL (see above), namespaces weren't that useful.
>>
>>What do namespaces have to do with the STL...?
>
> Ok.  I used STL here to refer to the standard C++ library which
> includes std:: namespace et alia.   My bad.   We used none of that.

Er, but anyway, my question was:  Why does not using the STL make
namespaces any less useful?

-miles

-- 
Cannon, n. An instrument employed in the rectification of national boundaries.

[toc] | [prev] | [next] | [standalone]

#15442 — Re: Methods for understanding complex, real world, C++ code?

Miles Bader <miles@gnu.org> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>Where these recent projects?  It took a while for namespaces to be 
>>>>>widely used after they were introduced in the '98 standard.
>>>>
>>>> About half before, the other half after.   However, since none of them
>>>> used STL (see above), namespaces weren't that useful.
>>>
>>>What do namespaces have to do with the STL...?
>>
>> Ok.  I used STL here to refer to the standard C++ library which
>> includes std:: namespace et alia.   My bad.   We used none of that.
>
>Er, but anyway, my question was:  Why does not using the STL make
>namespaces any less useful?

Because everything in our code was part of one of our classes.  Either static
data/function members or regular members.   All of which are impliciltly or
explicitly qualified by the class name.  There was no need for namespaces.

scott

[toc] | [prev] | [next] | [standalone]

#15443 — Re: Methods for understanding complex, real world, C++ code?

scott@slp53.sl.home (Scott Lurndal) writes:
>>Er, but anyway, my question was:  Why does not using the STL make
>>namespaces any less useful?
>
> Because everything in our code was part of one of our classes.  Either static
> data/function members or regular members.   All of which are impliciltly or
> explicitly qualified by the class name.  There was no need for namespaces.

Er, OK, but then of course your classes themselves are in the global
namespace.

You might consider that OK, but many would consider it a good use of
namespaces to collect all those classes in a library / module /
whatever namespace (maybe with some sub-namespaces as well).

... and of course, either way, there seems to be no connection with
whether one uses STL / std:: or not...

-miles

-- 
=====
(^o^;
(()))
*This is the cute octopus virus, please copy it into your sig so it can spread.

[toc] | [prev] | [next] | [standalone]

#15461 — Re: Methods for understanding complex, real world, C++ code?

Miles Bader wrote:
> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo>  writes:
>>> Real namespaces are better than "glued on" adhoc namespaces because
>>> they allow _either_ explicit references or implicit [with "using"]
>>> references, and that choice is in the hands of the user [of the
>>> namespace] where it belongs.  The appropriate choice can differ,
>>> for the same namespace, depending on the context of the use.
>>
>> Well, because "explicit" references are possible without namespaces,
>> the only feature they are adding seems to be allowing to use the
>> "implicit" ones.
>
> That doesn't mean one always has to use that feature.  However the
> _ability_ to use that feature is important.
>
>> By mentioning of "write-only" code in my original answer I was trying
>> to make a point that "more choices" is not necessarily equivalent to
>> "better". Specifically, "more choices" provided by namespaces may be
>> desirable for code writer but be rather hurtful for reader.
>
> "More explicit" names are not always "more readable," and can often be
> _less_ readable, because the constant repetition obscures what's
> actually meaningful.
>
> A reasonable use of namespaces makes things explicit when that's the
> most readable, and makes things implicit when _that's_ the most
> readable.
>
> Glued-on adhoc "namespaces" do not give you that choice, and so in the
> end can result in less readable code.
Not quite true. Nobody prevents you from using small names locally if you 
overuse your "big names". E.g. implementing delegating long public names to 
shorter static,
anonymous-namespace-scoped or protected names.

For other classes/modules -- yes, I prefer to force using longer names. And this 
is because "you" is not really "you" but someone else whose choice of names is 
outside your control -- and this is true for any sizable project.

Many people forget that the programming is not talking to oneself or one's 
compiler or computer but collaboration with other people who can be expected to 
sometimes act unwisely (from one's point of view).

As an example of good naming: Windows or X API names may be annoyingly long but 
certainly unambiguous (which is to me the best kind of "expressive") and do not 
tempt people to overload them (I mean, they are C, so they cannot really be 
overload but even if they were C++ I don't think people would rush to overload 
such calls).

> -miles
>

-Pavel

[toc] | [prev] | [next] | [standalone]

#15463 — Re: Methods for understanding complex, real world, C++ code?

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
>> Glued-on adhoc "namespaces" do not give you that choice, and so in the
>> end can result in less readable code.
>
> Not quite true. Nobody prevents you from using small names locally if
> you overuse your "big names". E.g. implementing delegating long public
> names to shorter static, anonymous-namespace-scoped or protected
> names.

Er, how?  The only ways I can think of are very annoying, requiring one
to explicitly add a definition for _every name_.

> For other classes/modules -- yes, I prefer to force using longer
> names. And this is because "you" is not really "you" but someone else
> whose choice of names is outside your control -- and this is true for
> any sizable project.
>
> Many people forget that the programming is not talking to oneself or
> one's compiler or computer but collaboration with other people who can
> be expected to sometimes act unwisely (from one's point of view).

Yes, we know that.  Please don't be condescending.

Excessive use of names with long redundant prefixes can be obfuscating,
making code _less_ readable.  You can disagree with that, of course,
but that's more or less the point:  there is no consensus among on this
issue among reasonable people.

-miles

-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

[toc] | [prev] | [next] | [standalone]

#15464 — Re: Methods for understanding complex, real world, C++ code?

Miles Bader wrote:
> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo>  writes:
>>> Glued-on adhoc "namespaces" do not give you that choice, and so in the
>>> end can result in less readable code.
>>
>> Not quite true. Nobody prevents you from using small names locally if
>> you overuse your "big names". E.g. implementing delegating long public
>> names to shorter static, anonymous-namespace-scoped or protected
>> names.
>
> Er, how?  The only ways I can think of are very annoying,
Below you asked me not to be condescending and I apologize in advance. but this 
is exactly the point: you are talking about annoyance *for the writer* and do 
not seem to care of a reader. The reader (of the code using long name or of the 
in-scope code using short name) will not find reading names that are making 
sense annoying. What s/he will find annoying is reading stumbling blocks when a 
short "expressive" name like "write" or, even worse '+', makes him/her jump via 
hundreds of definitions of "write" or 'operator*" (at extreme, mentally 
instantiating templates and applying conversion rules) to understand what this 
"write" means at this particular call site instead of just reading 
writeBlueCrocodileToGreenSwamp() or mul_tri_block_matrices_strassen() and 
immediately knowing what's going on (I made up ugly names on purpose; IMHO they 
are infinitely better than sleeky-and-meaningless "write" or "*" as they are).

requiring one
> to explicitly add a definition for _every name_.
That's what I meant:

void
LongLongLongLongLongExternOrPublicName(...)
{
ShortStaticOrAnonNamespaceOrProtectedNameForUseInSameFileOrClassScope(...);
// admittedly, not too short here :-)
}

I am not sure whether or not this is what you called "annoying".

>
>> For other classes/modules -- yes, I prefer to force using longer
>> names. And this is because "you" is not really "you" but someone else
>> whose choice of names is outside your control -- and this is true for
>> any sizable project.
>>
>> Many people forget that the programming is not talking to oneself or
>> one's compiler or computer but collaboration with other people who can
>> be expected to sometimes act unwisely (from one's point of view).
>
> Yes, we know that.  Please don't be condescending.
>
> Excessive use of names with long redundant prefixes can be obfuscating,
> making code _less_ readable.  You can disagree with that, of course,
> but that's more or less the point:  there is no consensus among on this
> issue among reasonable people.
>
> -miles
>

-Pavel

[toc] | [prev] | [next] | [standalone]

#15466 — Re: Methods for understanding complex, real world, C++ code?

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
> Below you asked me not to be condescending and I apologize in
> advance. but this is exactly the point: you are talking about
> annoyance *for the writer* and do not seem to care of a reader.

No.  I'm talking about both.  [Which should be pretty obvious, as I
keep saying it explicitly...]

-miles

-- 
Alone, adj. In bad company.

[toc] | [prev] | [next] | [standalone]

#15465 — Re: Methods for understanding complex, real world, C++ code?

On 04/19/12 02:09 PM, Pavel wrote:
>
> As an example of good naming: Windows or X API names may be annoyingly long but
> certainly unambiguous (which is to me the best kind of "expressive") and do not
> tempt people to overload them (I mean, they are C, so they cannot really be
> overload but even if they were C++ I don't think people would rush to overload
> such calls).

The X API uses the shortest possible prefix: X.  At least 2 characters 
shorter than any qualified namespace name..

The function names are also as concise as reasonably possible, Certainly 
not "annoyingly long".

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#15481 — Re: Methods for understanding complex, real world, C++ code?

Ian Collins wrote:
> On 04/19/12 02:09 PM, Pavel wrote:
>>
>> As an example of good naming: Windows or X API names may be annoyingly long but
>> certainly unambiguous (which is to me the best kind of "expressive") and do not
>> tempt people to overload them (I mean, they are C, so they cannot really be
>> overload but even if they were C++ I don't think people would rush to overload
>> such calls).
>
> The X API uses the shortest possible prefix: X. At least 2 characters shorter
> than any qualified namespace name..
Isn't that exactly what I suggest? Quoting my advice that IMHO spurred the 
discussion:

"always get *part of* the namespace name into the class name"

>
> The function names are also as concise as reasonably possible,
Sometimes they are and sometimes not. Why XSetCloseDownMode() cannot be simply 
XSetCloseMode() is not quite clear to me. Is there close up mode in X?

>  Certainly not "annoyingly long".
Actually, I agree -- I personally am fine with them (even with that CloseDown) 
as should be clear from my post. I was simply relating to Miles Bider's point 
"because the constant repetition obscures what's actually meaningful" -- 
"annoying" seems to be a fair summary of this quote, doesn't it?

-Pavel

[toc] | [prev] | [next] | [standalone]

#15486 — Re: Methods for understanding complex, real world, C++ code?

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> writes:
>>  Certainly not "annoyingly long".
>
> Actually, I agree -- I personally am fine with them (even with that
> CloseDown) as should be clear from my post. I was simply relating to
> Miles Bader's point "because the constant repetition obscures what's
> actually meaningful" --
> "annoying" seems to be a fair summary of this quote, doesn't it?

But X, with its short-n-sweet prefix is both an exception (obviously
not every package can use a single-letter name, and meaningful names
tend to be much olonger), and illustration of another problem with
hard-wired prefixes:

Because they're attached to _everything_ software authors often try to
pick the shortest possible prefix they think they can get away with,
which can result in both some awkward naming (your package is called
"ThreadExplorer", and has a module called "Manager", but you use a
prefix of "threxmgr" -- not _that_ bad, but you can see how things can
get shaky), and skipping some naming altogether (i.e., everything just
gets shoved into the top-level "namespace").

-miles

-- 
  Dinanzi a me non fuor cose create
se non etterne, e io etterno duro.
Lasciate ogne speranza, voi ch'intrate.

[toc] | [prev] | [next] | [standalone]

#15403 — Re: Methods for understanding complex, real world, C++ code?

Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
> It's not even that. The whole purpose of namespaces is to to use using 
> on them (whether declaration or directive) and avoid typing the 
> namespace part of the name in many cases (otherwise, why to use them 
> at all and not to glue them to the names?).

What's really useful about namespaces is that you don't have to use
qualified names _inside_ the _same_ namespace. Most classes that I use are
actually defined in the current namespace, and I like to explicitely
qualify all others.

Tobi

[toc] | [prev] | [next] | [standalone]

#15462 — Re: Methods for understanding complex, real world, C++ code?

Tobias Müller wrote:
> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo>  wrote:
>> It's not even that. The whole purpose of namespaces is to to use using
>> on them (whether declaration or directive) and avoid typing the
>> namespace part of the name in many cases (otherwise, why to use them
>> at all and not to glue them to the names?).
>
> What's really useful about namespaces is that you don't have to use
> qualified names _inside_ the _same_ namespace. Most classes that I use are
> actually defined in the current namespace, and I like to explicitely
> qualify all others.
>
> Tobi
Yes, but this works with utility classes as well. Of course, namespaces are more 
convenient in that they are open..

At the same time, openness they creates an uncertainty ("is this all stuff I 
need to know about XYZ or there is something else in another source file?").

Note I am not against using namespaces, what I say exactly is:
a. There is no free cheese; more opportunities mean more possibilities for abuse 
(and from Murphy laws we know all of them will be exploited).
b. For classes, I often prefer to prefix names within namespace with some *part* 
(or abbreviation) of namespace name.
c. For standalone functions, I (almost always) prefer using utility classes to 
namespaces. This is because, whereas non-static member function call site may 
give some idea of its class (maybe the object is defined locally or for a change 
has a good name), standalone function's call site does not carry any info of its 
enclosing scope (if it is a namespace).

-Pavel

[toc] | [prev] | [next] | [standalone]

#15469 — Re: Methods for understanding complex, real world, C++ code?

On Thu, 2012-04-19, Pavel wrote:
> Tobias Müller wrote:
>> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo>  wrote:
>>> It's not even that. The whole purpose of namespaces is to to use using
>>> on them (whether declaration or directive) and avoid typing the
>>> namespace part of the name in many cases (otherwise, why to use them
>>> at all and not to glue them to the names?).
>>
>> What's really useful about namespaces is that you don't have to use
>> qualified names _inside_ the _same_ namespace. Most classes that I use are
>> actually defined in the current namespace, and I like to explicitely
>> qualify all others.
>>
>> Tobi
> Yes, but this works with utility classes as well. Of course, namespaces are more 
> convenient in that they are open..
>
> At the same time, openness they creates an uncertainty ("is this all stuff I 
> need to know about XYZ or there is something else in another source file?").

IMO it's a fake uncertainty, because you don't need to know
*everything* about a namespace to use some of it. (If you *do*, maybe
it should have been a class, but you usually don't need to know
everything about large classes, either.)

> Note I am not against using namespaces, what I say exactly is:
> a. There is no free cheese; more opportunities mean more possibilities for abuse 
> (and from Murphy laws we know all of them will be exploited).
> b. For classes, I often prefer to prefix names within namespace with some *part* 
> (or abbreviation) of namespace name.
> c. For standalone functions, I (almost always) prefer using utility classes to 
> namespaces. This is because, whereas non-static member function call site may 
> give some idea of its class (maybe the object is defined locally or for a change 
> has a good name), standalone function's call site does not carry any info of its 
> enclosing scope (if it is a namespace).

Maybe I'm missing something, but doesn't the line

  foo:sort(a, b);

say that sort() comes from namespace 'foo'?  Or is it using sort()
from *within* foo that worries you?

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#15483 — Re: Methods for understanding complex, real world, C++ code?

Jorgen Grahn wrote:
> On Thu, 2012-04-19, Pavel wrote:
>> Tobias Müller wrote:
>>> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo>   wrote:
>>>> It's not even that. The whole purpose of namespaces is to to use using
>>>> on them (whether declaration or directive) and avoid typing the
>>>> namespace part of the name in many cases (otherwise, why to use them
>>>> at all and not to glue them to the names?).
>>>
>>> What's really useful about namespaces is that you don't have to use
>>> qualified names _inside_ the _same_ namespace. Most classes that I use are
>>> actually defined in the current namespace, and I like to explicitely
>>> qualify all others.
>>>
>>> Tobi
>> Yes, but this works with utility classes as well. Of course, namespaces are more
>> convenient in that they are open..
>>
>> At the same time, openness they creates an uncertainty ("is this all stuff I
>> need to know about XYZ or there is something else in another source file?").
>
> IMO it's a fake uncertainty, because you don't need to know
> *everything* about a namespace to use some of it. (If you *do*, maybe
> it should have been a class, but you usually don't need to know
> everything about large classes, either.)
Well, one of the principles of good OO design is to keep class's behaviors 
"highly cohesive". Something like "one class -- one concept with consistent set 
of highly cohesive behaviors". Cohesive behaviors beg for completeness (say, if 
you see function declarations to add to container but not remove from it, you 
will likely see something is missing and start searching for where it is).

Now, with the namespace, if we decide cohesion is not a goal, the only goal left 
seems to be (correct me if I am wrong) to use short tell-me-nothing names 
without confusing *compiler* (which is the last guy to be concerned with IMHO).

On the other hand, if cohesion *is* a goal in designing a namespace, 
completeness should be, too, and the above-mentioned uncertainty should be a 
fair concern.

This is not to say namespaces are always bad.
>
>> Note I am not against using namespaces, what I say exactly is:
>> a. There is no free cheese; more opportunities mean more possibilities for abuse
>> (and from Murphy laws we know all of them will be exploited).
>> b. For classes, I often prefer to prefix names within namespace with some *part*
>> (or abbreviation) of namespace name.
>> c. For standalone functions, I (almost always) prefer using utility classes to
>> namespaces. This is because, whereas non-static member function call site may
>> give some idea of its class (maybe the object is defined locally or for a change
>> has a good name), standalone function's call site does not carry any info of its
>> enclosing scope (if it is a namespace).
>
> Maybe I'm missing something, but doesn't the line
>
>    foo:sort(a, b);
>
> say that sort() comes from namespace 'foo'?  Or is it using sort()
> from *within* foo that worries you?
This may be of minor concern. The main concern is other usage, namely using 
directive and declaration, which allow using sort() from outside (although 
sort() is not too bad; 'get()', 'send()' or 'notify()' would be much more 
interesting (unless it's ::send() :-) ). Not to mention operator+ which is even 
worse than add() which is bad enough as it is).

Both usages you exemplify (foo::sort(a, b) externally and sort(a,b) within foo) 
are not specific to namespaces; you could easily do same with foo being a 
utility class.

On a side note, I do not think I am getting across my point that I am not 
against namespaces but few their specific [ab]uses that proliferate short 
telling-me-nothing names.

>
> /Jorgen
>

-Pavel

[toc] | [prev] | [next] | [standalone]

#15519 — Re: Methods for understanding complex, real world, C++ code?

On Fri, 2012-04-20, Pavel wrote:
> Jorgen Grahn wrote:
>> On Thu, 2012-04-19, Pavel wrote:
>>> Tobias Müller wrote:
>>>> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo>   wrote:
>>>>> It's not even that. The whole purpose of namespaces is to to use using
>>>>> on them (whether declaration or directive) and avoid typing the
>>>>> namespace part of the name in many cases (otherwise, why to use them
>>>>> at all and not to glue them to the names?).
>>>>
>>>> What's really useful about namespaces is that you don't have to use
>>>> qualified names _inside_ the _same_ namespace. Most classes that I use are
>>>> actually defined in the current namespace, and I like to explicitely
>>>> qualify all others.
>>>>
>>>> Tobi
>>> Yes, but this works with utility classes as well. Of course, namespaces
>>> are more convenient in that they are open..
>>>
>>> At the same time, openness they creates an uncertainty ("is this all stuff I
>>> need to know about XYZ or there is something else in another source file?").
>>
>> IMO it's a fake uncertainty, because you don't need to know
>> *everything* about a namespace to use some of it. (If you *do*, maybe
>> it should have been a class, but you usually don't need to know
>> everything about large classes, either.)

> Well, one of the principles of good OO design is to keep class's behaviors 
> "highly cohesive". Something like "one class -- one concept with consistent set 
> of highly cohesive behaviors". Cohesive behaviors beg for completeness (say, if 
> you see function declarations to add to container but not remove from it, you 
> will likely see something is missing and start searching for where it is).

> Now, with the namespace, if we decide cohesion is not a goal, the only goal left 
> seems to be (correct me if I am wrong) to use short tell-me-nothing names 
> without confusing *compiler* (which is the last guy to be concerned with IMHO).

I hope you are wrong, because that is of course a ridiculous goal.

My goal with namespaces is roughly this: if I am tempted to add a
prefix to a set of class and function names, templates, constants and
so on, I put them in a namespace instead. And this is when they seem
to form a subsystem in some way; when I already think of them as
related, I might as well make that explicit in the code.

I typically don't use "using" etc much -- I spell out the namespace name.
Not having to use it *within* the namespace is a big enough benefit.

[snip]

> On a side note, I do not think I am getting across my point that I am not 
> against namespaces but few their specific [ab]uses that proliferate short 
> telling-me-nothing names.

True. It seems to me there's not much use for them when you've
removed the part you see as abuse.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#15479 — Re: Methods for understanding complex, real world, C++ code?

Op 19-Apr-12 4:25, Pavel schreef:
> Tobias Müller wrote:
>> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>>> It's not even that. The whole purpose of namespaces is to to use using
>>> on them (whether declaration or directive) and avoid typing the
>>> namespace part of the name in many cases (otherwise, why to use them
>>> at all and not to glue them to the names?).
>>
>> What's really useful about namespaces is that you don't have to use
>> qualified names _inside_ the _same_ namespace. Most classes that I use
>> are
>> actually defined in the current namespace, and I like to explicitely
>> qualify all others.
>>
>> Tobi
> Yes, but this works with utility classes as well. Of course, namespaces
> are more convenient in that they are open..
>
> At the same time, openness they creates an uncertainty ("is this all
> stuff I need to know about XYZ or there is something else in another
> source file?").

These days many editors will tell you what is in the namespace after you 
entered its name. Anyway why do you need to know everything that is in a 
namespace?

> Note I am not against using namespaces, what I say exactly is:
> a. There is no free cheese; more opportunities mean more possibilities
> for abuse (and from Murphy laws we know all of them will be exploited).

True, more isn't necessarily better. But that doesn't mean that any 
feature that can be abused should be avoided. If one leaves out every 
feature that can be abused, one is left with a very small programming 
language.

Especially with C++ language features should be used judiciously. That 
is not to say they should not be used at all.

> b. For classes, I often prefer to prefix names within namespace with
> some *part* (or abbreviation) of namespace name.

This creates the same "uncertainty" you mentioned above (though a decent 
editor solves this problem as well).

> c. For standalone functions, I (almost always) prefer using utility
> classes to namespaces. This is because, whereas non-static member
> function call site may give some idea of its class (maybe the object is
> defined locally or for a change has a good name), standalone function's
> call site does not carry any info of its enclosing scope (if it is a
> namespace).

You may have point here, but frankly I'm not sure what the point is you 
are trying to make. Do you mean that if you use a static member function 
in a class you are forced to always specify its scope, whereas a 
standalone function in a namespace you can get by with just specifying 
the name of function if you are in calling it from the same namespace or 
have somewhere a 'using namespace' directive in the compilation unit? In 
that case I somewhat agree. Not enough to avoid namespaces altogether, 
but I'm reluctant to use the 'using namespace' directive to avoid nasty 
surprises.

[toc] | [prev] | [next] | [standalone]

#15484 — Re: Methods for understanding complex, real world, C++ code?

Dombo wrote:
> Op 19-Apr-12 4:25, Pavel schreef:
>> Tobias Müller wrote:
>>> Pavel<pauldontspamtolk@removeyourself.dontspam.yahoo> wrote:
>>>> It's not even that. The whole purpose of namespaces is to to use using
>>>> on them (whether declaration or directive) and avoid typing the
>>>> namespace part of the name in many cases (otherwise, why to use them
>>>> at all and not to glue them to the names?).
>>>
>>> What's really useful about namespaces is that you don't have to use
>>> qualified names _inside_ the _same_ namespace. Most classes that I use
>>> are
>>> actually defined in the current namespace, and I like to explicitely
>>> qualify all others.
>>>
>>> Tobi
>> Yes, but this works with utility classes as well. Of course, namespaces
>> are more convenient in that they are open..
>>
>> At the same time, openness they creates an uncertainty ("is this all
>> stuff I need to know about XYZ or there is something else in another
>> source file?").
>
> These days many editors will tell you what is in the namespace after you entered
> its name. Anyway why do you need to know everything that is in a namespace?
>
>> Note I am not against using namespaces, what I say exactly is:
>> a. There is no free cheese; more opportunities mean more possibilities
>> for abuse (and from Murphy laws we know all of them will be exploited).
>
> True, more isn't necessarily better. But that doesn't mean that any feature that
> can be abused should be avoided. If one leaves out every feature that can be
> abused, one is left with a very small programming language.
>
> Especially with C++ language features should be used judiciously. That is not to
> say they should not be used at all.
>
>> b. For classes, I often prefer to prefix names within namespace with
>> some *part* (or abbreviation) of namespace name.
>
> This creates the same "uncertainty" you mentioned above
The "uncertainty" I mentioned above had nothing to do with prefixing names; it 
was related to the fact that namespaces, as opposed to classes, are open (that 
is, more declarations can be added to a namespace in a different compilation unit).

This kind of uncertainty aside, I cannot understand how adding a prefix to a 
name can create any uncertainty whatsoever

  (though a decent editor
> solves this problem as well).
>
>> c. For standalone functions, I (almost always) prefer using utility
>> classes to namespaces. This is because, whereas non-static member
>> function call site may give some idea of its class (maybe the object is
>> defined locally or for a change has a good name), standalone function's
>> call site does not carry any info of its enclosing scope (if it is a
>> namespace).
>
> You may have point here, but frankly I'm not sure what the point is you are
> trying to make. Do you mean that if you use a static member function in a class
> you are forced to always specify its scope, whereas a standalone function in a
> namespace you can get by with just specifying the name of function if you are in
> calling it from the same namespace or have somewhere a 'using namespace'
> directive in the compilation unit? In that case I somewhat agree.
Yes
Not enough to
> avoid namespaces altogether,
Avoiding namespaces altogether is not something I advocate; I simply gave my 
advices on readability that included avoiding what I feel is abusing namespaces.
but I'm reluctant to use the 'using namespace'
> directive to avoid nasty surprises.
I use it sometimes, to include my company's namespaces where names are built in 
accordance with the above rules. The code is generally readable then; sometimes 
an unqualified prefixed name is puzzling; but it is almost never ambiguous or 
misleading; and the prefix at very least gives a good clue what namespace it may 
be in.

I generally do not use it to include external or Standard C++ library namespaces 
(sometimes I use "using namespace std;" for brevity in short examples, probing 
snippets or in this group but I am getting rid of these if I am to productionize 
the code).

-Pavel

[toc] | [prev] | [next] | [standalone]

#15425 — Re: Methods for understanding complex, real world, C++ code?

On Monday, April 16, 2012 12:33:44 AM UTC+1, Pavel wrote:
> Jorgen Grahn wrote:
> > On Fri, 2012-04-13, nick_keighley_nospam@hotmail.com wrote:
> >> On Friday, April 13, 2012 3:32:59 AM UTC+1, Pavel wrote:

<snip>

> >>> the following is not even technical at all:
> >>>
> >>> - Try to gain friends, not enemies, among your co-workers. Explain your
> >>> ideas.
> >>> Take other people's ideas 

I'll do that. And for the sake of quiet life I may use something that I think could be better. but...

> >>> (sometimes do it even if you believe their
> >>> ideas have no technical merit)

...I simply couldn't do this. How could you put something in your code that had /no/ technical merit!

> >> sorry I'm too Geek to even *think* this! I'd rather saw my own head
> >> off. Friends? Friends!? we're computer programmers we don't have no
> >> stinking friends!
> >
> > Either there are no morons in your workplace, you're deluding
> > yourself, or you're in for a difficult time ...

probably a combination of 2 and 3! maybe it's my inner pedant but i though you said "of no technical merit"?

> > I do what he describes.  I wish I could also do it without
> > rensentment. Sometimes it's as if you've built a 1 mile bridge over a
> > ravine, and you know all too well that you were convinced to build one
> > foot in the middle out of spaghetti ...
> 
> To me the best way to avoid the resentment is to really, honestly, try to 
> understand, 

well I try...

<snip>

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web