Re: Can you help me summarize all the bad things with global variables?

From:

James Kanze <james.kanze@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Fri, 10 Sep 2010 10:26:08 -0700 (PDT)

Message-ID:

<63335d14-f2f2-41f0-a359-b8711e4b42aa@m1g2000vbh.googlegroups.com>

On Sep 10, 5:59 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:

On 10 sept, 19:00, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:

* =D6=F6 Tiib, on 10.09.2010 17:35:

On Sep 10, 5:55 pm, Stuart Redmann<DerTop...@web.de> wrote:

On 10 Sep., Goran Pusic wrote:

Global variables are mostly code obfuscation technique.

ROFL. I like this statement.

Global variables are quite evil, but I think it's far worse when the
programming language does not support any kind of information hiding
(like C in comparison to C++). So you never know which part of the
"interface" is meant to be used by you and which is just an internal
function. Whenever I look at the LINUX kernel I just wanna scream
(actually, that goes for _any_ C code, but, strangly, also for boost=

C? C does support information hiding sweetly. C++ has to use pimpl
idiom (i have also heard it named "compilation firewall" or "cheshire
cat technique") to reach level of information hiding that C has
naturally in it.

*Hark*. C is mostly a subset of C++. It's meaningless to
talk about information hiding support in C that isn't
present in C++.

Yes it is present but it is inconvenient to use without additional
indirection (and slight code bloat) from pimpl.

You declare both public and private interfaces in class header in C++.
In C there are no member functions so you use functions that take the
pointer to your "class" as first parameter. Therefore nothing else has
to be declared about that "class" but only the fact that struct with
such a name exists and public functions that manipulate it in header
file. Rest of it is implementation detail.

In other words, you implement the compilation firewall outside
of a class.

--
James Kanze