Re: Can you help me summarize all the bad things with global variables?
On 10 sept, 21:46, Goran <goran.pu...@gmail.com> wrote:
On Sep 10, 5:35 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
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.
But C++ code does not __have__ to use pimpl. The thing you spoke about
later here with C is just as doable in C++. It's not as if because
there's other features, I __have__ to use them. It's more that "type =
code+data" idea is enough most of the time, and compiler supports it.
You are right. If some features that C++ provides are not needed then
you can pick simple (C-like) solution too.
And with equivalent C++ solution, at least I don't have to write "this-
" all the time, e.g.:
*.h
struct opaque_type_ref {};
void api(opaque_type_ref&, params); // rinse, repeat
*.cpp
namespace // implementation
{
class type : public opaque_type_ref
{
void api(params)
{
// "no this->" zone here.
}
}
type& impl(opaque_type_ref& obj) { return static_cast<type&>(obj); }
}
void api(opaque_type_ref& obj, params)
{
impl(obj).api(params);
}
This example does not solve the major inconvenience of such opaque
pointer style information hiding in general case of C++ class. Pimpl
has to be usually used because in C++ you often want to let the users
to derive from a class (if it hides its internals using compilation
firewall or not does not really matter)... and that means you have to
make virtual interface and protected interface visible.
In C you do not have inheritance so that removes that whole issue. In C
++ it is only special case when you do not need or allow
inheritance ... but information hiding is always good.