leor@pyr.gatech.EDU (Leor Amikam) (05/23/89)
I would be interested in obtaining any information regarding
any experiences anyone might have in developing with Glockenspiel
C++ for MicroSoft C under OS/2.
--
LEOR AMIKAM
Georgia Insitute of Technology, PO Box 34602 Atlanta Georgia, 30332
uucp: ...!{akgua,allegra,amd,hplabs,seismo,ut-ngp}!gatech!gitpyr!leor
ARPA: leor@pyr.ocs.gatech.edujonnyg@umd5.umd.edu (Jon Greenblatt) (08/04/89)
Has anyone out there had experience with Glockenspiel CommonView C++? I find C++ to be rather anoying but seeing as it's becomming a standard in OOPS it has become my next environment. I have not played with it long enough to get a real good opinion but I do have a few comments. My comments: 1: Usage of too many memory handles. I plan to put in a memory allocator I wrote for Xlisp to get around this problem. 2: The examples stink and are unreadable! 3: // I think the "//" commenting scheeme is horrible. 4: The windows interface looks too much like MS Windows C coding and does not take real advatage of OOPS to hide this. 5: Given that I have already written a superior OOPS windows interface in lisp I will probably port the C parts of it and make my own windows hierarchies if possible. I am real picky about not having my code look like a bunch C calls with studly caps, weird casts, and illogical parameters. 6: C++ still uses a rc file to further seperate the code from its meaning, once again I must write my own dialog box code like I did for Actor. 7: My opinion of C++ has always been "All the power of OOPS with less readability/flexability than C." There is a product called C_Talk which I have on order. The little I saw from it in the adds tells me it it much much better than Common View. Unfortianaly C++ is becoming a standard so we are all stuck with it. C_Talk is a small talk environment for C and has a browser and more reasonable classes. I hope to write a C_Talk to C++ translator in order to maintain my sanity. JonnyG.
jonnyg@umd5.umd.edu (Jon Greenblatt) (08/04/89)
In article <5157@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: > >1: Usage of too many memory handles. I plan to put in a memory allocator > I wrote for Xlisp to get around this problem. > > > JonnyG. Would anyone have a use for the memory allocator when I port it? I was able to crash windows very easily be creating too many C++ objects. CommonView allocates a new block of memory from windows everytime memory is needed or a new object is created. Any real app would blow away windows under this usage. The default is to allocate memory from the local heap but there are provisions to allocate from the global heap. There are problems and inefficiencies associated with both types of allocations when a lot of space is used or too many handles are used. My system uses 4-7 bytes of extra storage for each item allocated which is much lower than the overhead for global storage. Local storage in MS Windows is more efficient than global but it is easy to blow an application out of the water when too much is allocated (No warnings, MS Windows dies completely). Handles to memory still have to be stored even with local memory so there is still overhead. Other systems may be able to take advantage of this type allocator. Since apps under oops may have a tendency to use a lot of small chunks of dynamicaly allocated memory, my small memory allocator may prove usefull on other architectures. Under UNIX and most C based systems memory is allocated using a leat square algorithm. Where as this algoithm is fast, it wastes a lot of memory when creating a lot of small incongruent objects. I know I am not the first to come up with the better allocator but I have been using this under Xlisp for a few months and it preforms very efficiently. I have put this out in PD domain before and am willing to do so again. Any takers? JonnyG.
grg@otter.hpl.hp.com (Gerd Groos) (08/08/89)
Replied in comp.windows.ms
Gerdjonnyg@umd5.umd.edu (Jon Greenblatt) (08/08/89)
In article <10960005@otter.hpl.hp.com> grg@otter.hpl.hp.com (Gerd Groos) writes: >5. Maybe not the best object oriented windows interface. But a good and > usable one. > > Gerd. I agree. The reason why I was so hard on CommonView is I don't like reading C++ code! I'm still waiting to get my hands on C_Talk. From what I can tell from the C_Talk adds, the syntax is simpler but a lot more Mickey Mouse than C++. C_Talk advertizes a small talk like environment with a browser and other stuff. C_Talk is probably not as powerfull as C++ (only a guess) but it looks like they have written a more usable class tree from the examples in the adds. If your head was turned by the predudice of my first posting, don't worry. I just did that to get your attention. My main complaint with CommonView is the lack of readability compiled OOPS languages have so far. I wish the CommonView people well, from what I can tell this product is relatively new so a lot of stuff will probably be ironed out. NOTE: Followups go to comp.windows.ms Thanks for your attention, JonnyG.
cdb@midas.WR.TEK.COM (Christopher David Browne) (08/29/90)
I am currently using the Glockenspiel compiler on a VAX-VMS platform. I had some trouble with the level of quality control and customer support. The troubles I had were/are: 1) I had to go into the .hxx files and update them to work with the compiler. The include files were not named right when they were including themselves. 2) The documentation that I was given was for DOS and OS2. All the Command line arguments were given in terms of DOS. 3) Most of the iquiries about what is going intail a call to Dublin. What I would like from the net is if someone has a copy of the command line arguments for VAX-VMS and/or how exactly to call mxx on VAX-VMS to send the information to me. Thanks Chris Browne FAX (503) 645-8067
lindsay@sesame.lbl.gov (Lindsay Schachinger) (03/16/91)
We have purchased (for $3000) the Glockenspiel C++ compiler for the IBM RS/6000 from Imagesoft --- because it was the only C++ compiler available for the IBM. It turns out that on the distribution tape has no manual page for the compiler itself. My attempts to get a manual page from Imagesoft have been futile -- they don't even know what a manual page is, and though they have contacted Glockenspiel, I don't think they knew what to ask for. The tape has manual pages for the streams library and for the complex library but nothing for the compiler itself. Does anybody from Glockenspiel read the net, or does anybody know how I can send mail to Glockenspiel? Why is there no manual page for the compiler? Does anybody know where I can get one? Distributing a compiler for a Unix system with no manual page stinks. Lindsay Schachinger Lawrence Berkeley Lab lindsay@sesame.lbl.gov