[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: }Re: [Sheflug] c++ & mem



> > Yes. C and C++ programs are written differently, and end up with
different
> > binaries, link differently, etc. etc. Witness the trouble RH got into
with
> > 7.
>
> Which if anything had more to do with paranoid Red Hat haters than
> anything else.

No, not really. Windows has been pretty much binary compatible since year
dot, RH7 broke a lot of things, C++ linkages included. I'm not a RedHat
hater, I use it at work every day (versions from 4 thru' 6, but not 7). It's
just that RH7 sucks eggs.

> > > Often you have to be explicit about it though (i.e. use flags).
> > Example?
> -fno-rtti

As far as GNU is concerned, space is sacrificed for speed, so all you get
with runtime type identing is extra stuff in .o's. It would be quite
possible, though, for gcc to optimise this out - if you don't use dynamic
casting, for example, there would be no reason (necessarily) to include
rtti.

> > Nope. Trying to do C++ features in C is called "c-front", and it isn't
great
> > (being polite). structs do not replicate objects, they don't even come
> > close. They can't encapsulate code (don't give me pointers to
functions),
>
> Pointers to functions are a valid way of doing things. And one of the main
> reasons Java sucks so badly.

No. Pointers to functions are "valid". So are pointers in general. But what
you don't realise, is pointers suck and Java doesn't :))

> > they don't data hide, they don't inherit, etc. etc. People write:
> > type func(types.. )
> > {
> >
> > }
>
> Data hiding as a language feature is for idiots. If you don't want to
> access private data, don't do it. Write up macros thus:

By this definition, so are types, etc. Anything which a compiler can check
at compile time? I.e., if you don't want to convert between these types,
don't do it. Hmmmmm......

> struct foo {
> int bar;
> };
>
> #define FOO_BAR(x) x.bar
>
> It's fast and clean. No, it doesn't have any compile time or run time
> checks, but you can write good code without it.

Fast and clean?! Anything which relies on C-preprocessor can hardly be
described "clean". You could write it as an inline function.. but then, as
you say, we lose the checking. Which is the whole point.

> > limits like this which just aren't there in C. OO certainly isn't a
frame of
> > mind, it requires language support to be done properly. Perl isn't OO,
> > neither is C. It is *possible* to write OO type programs in either
language,
> > but you end up replicating the OO functionality yourself. That isn't the
> > same as the language being OO.
>
> Any sane definition of OO vs. fucntional vs. structured
> will allow you to write OO code in C.

You can write OO in asm also. Obviously, since the OO code gets turned into
asm. That *DOESN'T* make asm OO. Just accept it - C++ is an OO language, as
is Java. C IS NOT.

> > man gcc: first line of description:
> >     "the C and C++ compilers are integrated".
> > . they just use different linkers, a lot of the rest of it is identical.
>
> Different linkers? Are you sure?

Different linkages, sorry.

> > Hmmm. It's "ugly", therefore it doesn't work. :) Not sure I agree with
that,
> > either. And how
> >     cout << "Value of myvar: " << myvar;
> > is "uglier" than
> >     fprintf(stdout, "Value of myvar: %d", myvar);
> > . I'll never know ;)
>
> Hmmm, try outputting it as hex, or as a floting point value to a certain
> precision. You can, but it takes twice as much code.

Output hex. Hmm....

        cout << "Value of myvar in hex: " << hex << myvar;

Gosh, that was tough ;) Not sure where you get your "twice as much code"
from....

Cheers,

Alex.

---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.