I Keep Switching Back...

[Kamilche]

I'm looking at other languages. Some of them fool me into thinking
they're useful, and I change my home page to them... 'comp.lang.c++'
for instance. But I always end up switching it back to comp.lang.c.
:-D

When I redid my code into C++ recently, I saw some amazing bogosities.
Such as member functions being called before the constructors ran, and
member functions being called for NULL objects. Enough to make me
switch back to C, where function calling order is controlled by the
programmer, and proceeds in a safe and sane order. :-O

So - I'm baaaack. :-D I haven't encountered a good enough language yet
that has made me switch my home page permanently.

--Kamilche

[Ben Pfaff]

kl*******@home. com (Kamilche) writes:

When I redid my code into C++ recently, I saw some amazing bogosities.
Such as member functions being called before the constructors ran, and
member functions being called for NULL objects. Enough to make me
switch back to C, where function calling order is controlled by the
programmer, and proceeds in a safe and sane order. :-O

C++ has a really, really scary amount of complexity. Personally,
a few months ago I embarked on trying to learn it well enough to
use it for real projects, by way of buying all the best books on
it and summarizing their advice, with citations, into a "best
practices guide" for myself. So far, I have over 10,000 words
citing 18 books and articles, and I still have quite a way to go.
--
"I am worth much more brick-bat!!"
--Uday Joshi

[Joe Wright]

Kamilche wrote:

I'm looking at other languages. Some of them fool me into thinking
they're useful, and I change my home page to them... 'comp.lang.c++'
for instance. But I always end up switching it back to comp.lang.c.
:-D

When I redid my code into C++ recently, I saw some amazing bogosities.
Such as member functions being called before the constructors ran, and
member functions being called for NULL objects. Enough to make me
switch back to C, where function calling order is controlled by the
programmer, and proceeds in a safe and sane order. :-O

So - I'm baaaack. :-D I haven't encountered a good enough language yet
that has made me switch my home page permanently.

Welcome back. We've missed you.
--
Joe Wright mailto:jo****** **@earthlink.ne t
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Kamilche]

Richard Heathfield <do******@addre ss.co.uk.invali d> wrote in message news:<be******* ***@hercules.bt internet.com>.. .

Welcome back to the comp.lang.c newsgroup.

We've moved the coffee machine to make room for another server. You'll now
find it in the cafeteria, next to the swing doors.

Your cloakroom peg has been re-assigned, so please apply for a new one when
you pick up your swipe card.

Don't forget to unsubscribe from comp.lang.c++ :-)

:-D
Kamilche plops a plate of cookies next to the water cooler, and
surveys her old digs happily.

[Kamilche]

Ben Pfaff <bl*@cs.stanfor d.edu> wrote in message news:<87******* *****@pfaff.Sta nford.EDU>...

kl*******@home. com (Kamilche) writes:

C++ has a really, really scary amount of complexity. Personally,
a few months ago I embarked on trying to learn it well enough to
use it for real projects, by way of buying all the best books on
it and summarizing their advice, with citations, into a "best
practices guide" for myself. So far, I have over 10,000 words
citing 18 books and articles, and I still have quite a way to go.

Yeah, I believe it. But when push comes to shove, what I saw looked
and smelt more like bugs than complexity. I saw member functions being
called before the constructor was called, and learned you can't rely
on constructor initialization order for global objects. So I turned
them into pointers instead, and discovered that C++ will call member
functions for objects that DON'T EVEN EXIST. They can be NULL, and you
can still call their functions. The function gets a NULL 'this'
pointer!

The following code compiles and runs, and A() executes. Apparently the
object orientation of C++ is a thin scum over procedural programming,
UNRELIABLE procedural programming at that, to allow code like this to
execute. That's when I put it down and walked away from it.

class My
{
public:
void A()
{
if (this==NULL) printf("NULL Pointer ");
}
};

void main()
{
My *ptr=NULL;
ptr->A();
}

I feel that by going to C++, I'd be giving up the complexities
inherent in large C programs, for the undiscovered bugs in C++... ya
know? I know object oriented programming from other languages, such as
VB... and this is just not the way it should work.

I've been doing a huge amount of experimenting with hierarchical
objected oriented C systems. Right now, I'm looking at code
generation, or possibly heavy use of configuration files, to reduce
complexity... something where I can keep the high level 'big picture'
pseudocode in a text file, and either load it at startup, or auto
generate code from it.

[Niklas Norrthon]

kl*******@home. com (Kamilche) wrote in message news:<88******* *************** ****@posting.go ogle.com>...

I'm looking at other languages. Some of them fool me into thinking
they're useful, and I change my home page to them... 'comp.lang.c++'
Currently I mostly use C for my work, but I have some 10 years of C++
experience too. I also like other languages like to study scheme,
haskell et cetera, and my conclusion is that there is no "one
language" that is good for everything. C is a great language,
and so is C++.
When I redid my code into C++ recently, I saw some amazing bogosities.
Such as member functions being called before the constructors ran,
What did you do?

Perhaps something like the following?
Foo* x;
x->member_func( );
and
member functions being called for NULL objects.
The caller is responsible for initializing the objects, calling member
functions for NULL objects is just as much undefined behavior as
the "C" constructs:

int i;
i = i++ + ++i;

and

int* i;
*i = 42;
Enough to make me
switch back to C, where function calling order is controlled by the
programmer, and proceeds in a safe and sane order. :-O
You switch to C because you can't handle the responsibility to initialize
the objects before you use them? Perhaps pascal is a better language
for you...
The following code compiles and runs, and A() executes.
It doesn't for me. I get the following compile errors:

~% g++ -pedantic -ansi -Wall asdf.cc
asdf.cc: In method `void My::A()':
asdf.cc:6: `NULL' undeclared (first use this function)
asdf.cc:6: (Each undeclared identifier is reported only once
asdf.cc:6: for each function it appears in.)
asdf.cc:6: `printf' undeclared (first use this function)
asdf.cc: At top level:
asdf.cc:11: warning: return type for `main' changed to `int'

To fix it I have to include <cstdio>, change printf to std::printf, and
change "void main" to "int main".
Apparently the
object orientation of C++ is a thin scum over procedural programming,
UNRELIABLE procedural programming at that, to allow code like this to
execute. That's when I put it down and walked away from it.

class My
{
public:
void A()
{
if (this==NULL) printf("NULL Pointer "); // This can never be NULL, this test is not necessary. }
};

void main()
{
My *ptr=NULL;
ptr->A();
}

Dereferencing a NULL pointer. I don't understand why you are upset.
This is just as undefined behavior in C++ as the following C program
would be:

#include <stdio.h>

typedef void (*Func)(void);

struct Foo {
Func A;
};

int main ()
{
Foo* ptr = NULL;
ptr->Func();
return 0;
}

Anything can happen in the C-program above, including the output
of some text regarding null-pointers.

I can understand arguments about C++ being a complex language
with lots of things happening "under the hood", but supporting such
arguments with code that invokes undefined behavior, and would
do so even in C, if the constructs had been legal in C is silly.

/Niklas Norrthon

[Bruce Wheeler]

On 10 Jul 2003 00:26:13 -0700, kl*******@home. com (Kamilche) wrote:
....

The following code compiles and runs, and A() executes. Apparently the
object orientation of C++ is a thin scum over procedural programming,
UNRELIABLE procedural programming at that, to allow code like this to
execute. That's when I put it down and walked away from it.

class My
{
public:
void A()
{
if (this==NULL) printf("NULL Pointer ");
}
};

void main()
C++ requires int main, just as C does.
{
My *ptr=NULL;
ptr->A();
}

This is undefined behavior in C++. You are dereferencing a NULL pointer,
which is undefined in C++, just as it is in C. As a clc reader, you know
that anything can happen when undefined behavior is invoked, as in the
following analagous C fragment, also dereferencing a NULL pointer.

char* x = NULL,
strcpy(x, "Hello");

Both code fragments could run "normally", format your hard disk, or
cause a power outage in Birmingham, Alabama.

C++ has problems with undefined behavior similar to C. As Ben Pfaff
commented, C++ is also vastly more complicated than C, but if one writes
good, legal code (avoiding undefined behavior, among other things), C++
is a very useful language.

I would suggest that you learn to write legal C++ before you condemn it.

Regards,
Bruce Wheeler

[Chris Torek]

In article <88************ *************@p osting.google.c om>
Kamilche <kl*******@home .com> writes:

Yeah, I believe it. But when push comes to shove, what I saw looked
and smelt more like bugs than complexity. I saw member functions being
called before the constructor was called, and learned you can't rely
on constructor initialization order for global objects.
(This is probably the wrong newsgroup to gripe about such things,
but as far as I am concerned, this ordering problem is just the
tip of the iceberg.)
So I turned them into pointers instead, and discovered that C++ will
call member functions for objects that DON'T EVEN EXIST. They can be
NULL, and you can still call their functions. The function gets a NULL
'this' pointer!
Yes.
The following code compiles and runs, and A() executes. Apparently the
object orientation of C++ is a thin scum over procedural programming ...
Actually, it is a fairly thick layer. But for simple cases like
this one, there is a direct conversion from C++ to C:
class My
{
public:
void A()
{
if (this==NULL) printf("NULL Pointer ");
}
};
(You need to #include at least one header, and the printf here
should really be "std::cout <<", etc. But never mind that.) Here
the "class function" A() that is a member of the data structure
called "My" is obtained simply by gluing together the type ("My")
and the function name ("A"), which you can do manually in C by
spelling it My_A(). Of course, you give up the automatic "if the
type changes, the function name changes too" part that C++ gives
you.
void main()
{
My *ptr=NULL;
ptr->A();
}

This needs to be "int main()" just as in C.

In any case, the C++ compiler here just glues together (in a
more error-resistant way) the name "My" and the name "A", so
this is like writing the C code:

struct My { char dummy; };
/* dummy element required only because C forbids empty struct */

void My_A(struct My *this) {
if (this == NULL)
printf("NULL pointer\n");
}
int main(void) {
struct My *ptr = NULL;
My_A(ptr);
}

If you change member function A to "virtual", it stops working.
This is because a "virtual" member function is not built by name
-- i.e., we no longer just say "well gosh, `ptr' has type `My' so
we just call My_A() and supply `ptr' as a secret argument for the
`this' parameter". Instead, there is now a "virtual function table"
attached to the data type.

This is where C++ actually gives up something you can do manually
in C. For various (good and bad) reasons, the virtual function
table is essentially an operations vector, and the data structures
-- objects of type "My" -- point to the table. So in C we might
now write:

struct ops_for_My {
void (*A)(struct My *this);
};
static struct ops_for_My ops_for_My = { A };
struct My {
struct ops_for_My *vtable;
/* other data elements go here as needed */
};

When you create an actual object of type "My", the compiler will
fill in the "vtable pointer":

/* C code loose-equivalent of the C++ stuff */
ptr = ...;
ptr->vtable = &ops_for_My;

A later call of the form:

ptr->A(); // in C++

translates to the C call:

ptr->vtable->A(ptr);

and if "ptr->vtable" points to the default table, that calls the
default "My_A()" function. (A derived class that overrides the
default My_A() function just requires another ops table, with a
different "A" pointer.)

Although the need is somewhat specialized and occasional, note that
if you have written this in C, you now have a name for the vtable(s)
that implement the "virtual functions" for anything that is, or is
derived from, a "My". Clearly, if ptr==NULL, this:

ptr->vtable->A(ptr);

is not going to work -- but in C, we can do this instead, in
those rare cases where we want to:

ops_for_My.A(NU LL);

In C++ one has to resort to any number of workarounds -- not that
they are particularly horrible or anything; but it is annoying to
know that there is a virtual function table all set up, yet you
are not allowed to access it. You *must* have an instance of the
class in order to access that class's virtual function table.
(The easiest workaround is thus to have a static "dummy" instance.)

In any case, both regular "class functions" and "virtual functions"
are easy to do in C, using these techniques. C++ merely automates
some of the drudge-work, avoiding the opportunity to get it wrong,
but also requiring you to give up some control over it.
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Bruce Wheeler]

On 10 Jul 2003 01:30:46 -0700, ni***@passagen. se (Niklas Norrthon)
wrote:

A very nice post.

I posted something similar in a different subthread.

However,

class My
{
public:
void A()
{
if (this==NULL) printf("NULL Pointer ");// This can never be NULL, this test is not necessary.

Actually, 'this' can be NULL, as the method invocation is undefined
behavior if 'this' is NULL. Anything can happen. Some C++
implementations (VC++ in particular) actually have such code in tests in
library code.

}
};

void main()
{
My *ptr=NULL;
ptr->A();
}

Dereferencin g a NULL pointer. I don't understand why you are upset.
This is just as undefined behavior in C++ as the following C program
would be:

#include <stdio.h>

typedef void (*Func)(void);

struct Foo {
Func A;
};

int main ()
{
Foo* ptr = NULL;
ptr->Func();
return 0;
}

Anything can happen in the C-program above, including the output
of some text regarding null-pointers.

Correspondingly , anything (including invocation of the method) can
happen in the C++ example above, because it is also undefined behavior.

I can understand arguments about C++ being a complex language
with lots of things happening "under the hood", but supporting such
arguments with code that invokes undefined behavior, and would
do so even in C, if the constructs had been legal in C is silly.

/Niklas Norrthon

Regards,
Bruce Wheeler

[Zoran Cutura]

Kamilche <kl*******@home .com> wrote:

Ben Pfaff <bl*@cs.stanfor d.edu> wrote in message news:<87******* *****@pfaff.Sta nford.EDU>...

kl*******@home. com (Kamilche) writes:

C++ has a really, really scary amount of complexity. Personally,
a few months ago I embarked on trying to learn it well enough to
use it for real projects, by way of buying all the best books on
it and summarizing their advice, with citations, into a "best
practices guide" for myself. So far, I have over 10,000 words
citing 18 books and articles, and I still have quite a way to go.
Yeah, I believe it. But when push comes to shove, what I saw looked
and smelt more like bugs than complexity. I saw member functions being
called before the constructor was called, and learned you can't rely
on constructor initialization order for global objects. So I turned
them into pointers instead, and discovered that C++ will call member
functions for objects that DON'T EVEN EXIST. They can be NULL, and you
can still call their functions. The function gets a NULL 'this'
pointer!

You somehow drew the conclusion that C++ doesn't allow for programmers
to write buggy software, where would this come from? In C++ as in C
you're responsible for writing legal code, not the language.

The following code compiles and runs, and A() executes. Apparently the
object orientation of C++ is a thin scum over procedural programming,
UNRELIABLE procedural programming at that, to allow code like this to
execute. That's when I put it down and walked away from it.

class My
{
public:
void A()
{
if (this==NULL) printf("NULL Pointer ");
}
};

void main()
{
My *ptr=NULL;
ptr->A();
}

I feel that by going to C++, I'd be giving up the complexities
inherent in large C programs, for the undiscovered bugs in C++... ya
know? I know object oriented programming from other languages, such as
VB... and this is just not the way it should work.

I ask myself, why you want to give up C at all. If C is inappropriate
for a problem, use something different, but if it does the job (or if
you think you can do the job in C) why not just stick with it?

A mechanic wouldn't use a hammer when a screwdriver is needed, allthough
I bet that he/she could solve the job with a hammer too.

--
Z (Zo**********@d aimlerchrysler. com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond