mgardi@watdcsu.waterloo.edu (M.Gardi - ICR) (12/28/88)
I should first mention that I am new to this newsgroup, and as such this question may have been asked already (or even worse, is a silly question). I am curious if anyone has a problem with the fact that c++ has a mixture of object data types, and standard C data types. I have just been looking at smaltalk and its philosophy of 'everything is an object'. The reason I am asking is that I am getting a little confused trying to visualize a really generic queue in C++. Say for instance that an object pointer is a pointer to an unsigned long. If the queue is then designed to work on objects defined thus, how does one work on datatypes such as integers, or doubles etc. Does one have to create a function that converts all defined datatypes to objects? I would really appreciate some comments on this...even if they are merely intended to clear up some misconceptions I may have... p.
dw@siemens.UUCP (Dan Wolfson) (12/29/88)
We are using C++ to and yacc to develop an interpreter under UN*X and need to port it to VMS. Does anyone have any recommendations for a C++ environment which will support large source code files? The problem is that the yacc output is fairly large and the OASYS compiler (ver 1.1) that we have yields an internal cfront error. (We also have a bison problem, but that is another story...Any recommendations or suggestions would be appreciated. Thank You, Dan Wolfson
vilot@csdpie.dec.com (Michael J. Vilot) (12/31/88)
> I am curious if anyone has a problem with the fact that c++ has a mixture of > object data types, and standard C data types. I have just been looking at > smaltalk and its philosophy of 'everything is an object'. This turns out to be an interesting question. What you'll find in SmallTalk _implementations_ are special optimisations for "primitive" data types (e.g. integers) to make them efficient enough for traditional hardware. C++ inherits C's "systems programming" orientation, and naturally implements these "primitive" types efficiently: "Features that would incur run-time or memory overheads even when not used were avoided. For example, ideas that would make it necessary to store ``housekeeping information'' in every object were rejected; if a user declares a structure consisting of two 16-bit quantities, that structure will fit into a 32-bit register." -- The C++ Programming Language, p. 3 > [ question on generic queue ] > how does one work on datatypes such as integers, > or doubles etc. Does one have to create a function that converts all defined > datatypes to objects? Not _all_. Implicit and explicit conversions can simplify matters. The arithmetic conversions of R6.6 (p. 253) are defined to cope with the built-in types. You can provide explicit conversions [R7.2.3, p. 258] in any user-define classes. Take the trouble to learn the conversion rules. Like the operator precedence hierarchy, a clear understanding of them can often simplify your code. == Mike Vilot e-mail: vilot%ontologic@erl.mit.edu or: vilot%keeper.dec@decwrl.dec.com when that fails: (508)467-6166 [for now]
mat@mole-end.UUCP (Mark A Terribile) (01/02/89)
> ... Does anyone have any recommendations for a C++ environment which will > support large source code files? The problem is that the yacc output is > fairly large and the OASYS compiler (ver 1.1) that we have yields an > internal cfront error. (We also have a bison problem, but that is another > story...Any recommendations or suggestions would be appreciated. If the problem really is space, there are some things that I can suggest for dealing with the Oasys packaging of cfront. Contrary to what ought to be happening in cfront, there is some memory lost when processing each function. What this means is that you should split files when you can. It also means that you should reduce the size of yyparse. You might also look for a way (I haven't tried) to take the yyparse table initializations out of the code that cfront sees and put them into a file that is compiled seperately, perhaps as C rather than as C++. Some magic with make, the C preprocessor, and your source code might do the job, perhaps with a little help from your sed(1). If you can do it in a function, don't do it in yyparse. Likewise, watch for inlines that are ``plausible'' but that are more costly than you can afford. yyparse probably will trigger lots of initialization constructors unless you pass arguments to functions by reference; watch out. If you must, create a special non-inline version of your functions, make them private, and make yyparse a friend. (ugh!) Or create a friend class with private functions that do those things and make yyparse a friend of *it*. (Better.) I got some mail from Oasys about versions of C++ for the 386; presumably these versions use the unsegmented large addressing model. If so, you have another option, albeit an expensive one. -- (This man's opinions are his own.) From mole-end Mark Terribile