dmg@ssc-vax.UUCP (David Geary) (05/19/89)
In article <11549@ulysses.homer.nj.att.com>, Jerry Schwarz writes:
+ No. And in 2.0 the default behavior never copies the _vptr. The _vptr
+ is associated with an object when the object is allocated and cannot
+ be changed. Copying the _vptr "breaks" the C++ type system.
I've been using C for a long time (well, 5 years anyway), and I am
just starting to jump into C++. I've read BS ;-), and also another
book - "C++ Programming", by John Berry, and have played around with
creating some classes for the past week or so.
I think I have a pretty good handle on the basics of oop and C++,
but what I'd like to know is *how* C++ is implemented. I have
Glockenspiel C++ on an Apollo, but I don't know how to get the
"compiler" to let me see it's C output. (Anybody know?)
Anyway, Jerry's posting is a perfect example of my ignorance ;-).
What *is* a _vptr? I have also heard reference to the VTABLE
in previous postings. What are these animals?
Of course, I don't expect anybody to describe everything that
cfront does, but it'd sure give me more understanding of C++ if
I knew what it was doing *behind my back* in C.
Thanks...
*************************************************************************
"The dog up and died, he up and died. After 20 years, he still grieves"
Mr. Bojangles, Nitty Gritty Dirt Band
*************************************************************************
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ David Geary, Boeing Aerospace, Seattle ~
~ "I wish I lived where it *only* rains 364 days a year" ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~jss@hector.UUCP (Jerry Schwarz) (05/21/89)
In article <2671@ssc-vax.UUCP> dmg@ssc-vax.UUCP (David Geary) writes: > > Anyway, Jerry's posting is a perfect example of my ignorance ;-). >What *is* a _vptr? I have also heard reference to the VTABLE >in previous postings. What are these animals? > When a class has virtual member functions its representation contains a pointer (called a virtual pointer, or "vptr" for short) to a table (called a virtual table or "vtbl" for short) that has entries indicating the actual functions to be called when a virtual function is called. Thus given something like struct Base { virtual void f() ; } ; struct Derived : public Base { void f() ; } ; void fct(Base* b) { b->f() ; } // actual call involves using vptr to find the vtbl // entry that says exactly how to invoke f. // This is neccessary because Base::f or Derived::f // must be called depending on whether b points to an // object that was allocated as a Base or as a Derived. Jerry Schwarz AT&T Bell Labs, Murray Hill
jima@hplsla.HP.COM (Jim Adcock) (05/25/89)
> I think I have a pretty good handle on the basics of oop and C++, > but what I'd like to know is *how* C++ is implemented. I have > Glockenspiel C++ on an Apollo, but I don't know how to get the > "compiler" to let me see it's C output. (Anybody know?) Depending on the compiler, I've used a number of different techniques to do this. One simple way is to wait for an indication that "cc" is executing, then abort the compile. In my case, this would leave behind a ..c file with the intermediate C code. Some compilers may have a -F or -Fc option that directs intermediate C code to standard output. Or they may have a +i option to leave behind the intermediate C file after compilation. Once you have the intermediate C file, then the real fun begins! Where *did* this *stuff* come from !?!? Is this *really* C !?!? Depending on the compiler you have, the situation may be better or worse [and my guess is the situation is going to get worse before it gets better -- as more advanced features are added to the language.] To analyse the intermediate C code, I typically do one of two things 1) compile it and look at the assembly code generated 2) try to edit the "C" code generated down to something that vaguely resembles what was originally programmed in C++. Usually option 1) is more expedient, and the assembly code is more readily understandable than the "C" code generated! [Again, how bad the situation is depends on the C++ compiler you have.] Option 1) assumes you have a good optimizing C compiler. If not, you need to get one. C++ using C as an intermediate representation is miserable without a good optimizing C compiler. [cfront using gcc as a backend seems to be a good combination] Option 2) can take an hour or two for a small C++ compilation. I typically start by throwing away the part of the file generated by #includes. Next I throw away #line statements. Then I reverse encode variable names. Next I try getting rid of gratuitous (&glop)->part code, rewriting these as glop.part. Next I look at comma expressions, throwing away trailing comma parts that don't have side effects, and don't get assigned to. I change the comma expressions back to statements, rebalancing the parentheses as I go. Next, I get rid of the extra parentheses, and rename temporaries generated by C++ from something like: "__0013210321squigglesquawk" to "tmpx". Then I get rid of extraneous type conversions, and remove the struct thisandthat required by C, and reverse encode method names to something similar to their original names. By this time I'm either ready to give up; or I have something pretty close to vanilla-C. So, the point being, even if you can get an intermediate "C" file, analysing what a C++ compiler is doing is a royal pain in the butt. Still, in the absence of documentation on what C++ compilers are doing, and why, this is the only real way to really learn the C++ language, and its implementations, so I think its worth the effort.
thomasw@vlsi3.CS.Concordia.CA (Thomas Wieland 1728423) (05/31/89)
In article <6590133@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >> .... I have >> Glockenspiel C++ on an Apollo, but I don't know how to get the >> "compiler" to let me see it's C output. (Anybody know?) We have Designer C++ for our Suns (version 1.2, rel. 3d), which uses the Glockenspiel compiler/preprocessor. On our system, you can get the C source by feeding the driver one of the following switches: @c,@k compile, keep C source (.c) files generated by C++ compiler @t translate C++ to C only, keep generated C source (.c) files Also possibly useful: @p compile, keep preprocessed C++ source files (.ixx, .i) Note: options starting with "@" are case insensitive and can also start with "!", ie. "@c", "@C", "!c", and "!C" are all one and the same. >So, the point being, even if you can get an intermediate "C" >file, analysing what a C++ compiler is doing is a royal pain >in the butt. I agree wholeheartedly. >Still, in the absence of documentation on what C++ compilers >are doing, and why, this is the only real way to really learn the >C++ language, and its implementations, so I think its worth >the effort. I have to agree again, unfortunately (with regard to lack of implementation information.) Thomas Wieland thomasw@jupiter.cs.concordia.can