jonnyg@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)
CommonView is a C++ library sold with the Glockenspiel C++ compiler.
Here an example for those unfamiliar with it.
This 'Doodle' example opens a window and lets you draw lines in it
with the mouse. Compiles down to a normal MS Windows application.
Compare it with SDK's doodle example...
// -------------------------------------
#include <CommonVu.hxx> // CommonView library declarations
class DoodleWind : public TopAppWindow
{
Point LastPt;
protected:
long far MouseDrag ( MouseEvt );
long far MouseButtonDn ( MouseEvt );
};
void App::far Start() // window's main()
{
DoodleWind Doodle; // open window
Doodle.EnableSysMenu (); // appearance (not mandatory)
Doodle.EnableBorder (); // ""
Doodle.SetCaption ( "Doodle" ); // title (not mandatory)
Doodle.Show (); // display it
Exec (); // kick off ms window event handler
}
long DoodleWind::far MouseButtonDn ( MouseEvt Evt ) // called if MouseButtons
{ // pushed in this window
LastPt = Evt.Where (); // remember start point
}
long DoodleWind::far MouseDrag ( MouseEvt Evt ) // called when mouse is dragged
{
MoveTo ( LastPt );
LineTo ( LastPt = Evt.Where ()); // draw line
}
// -------------------------------------
> The examples stink and are unreadable!
Better read the manual.
> The windows interface looks too much like MS Windows C coding.
Compare the Glockenspiel source examples with the SDK ones.
Which ones are easier to read?
To quote Glockenspiel: (manual page CV1-5):
CommonView makes no attempt to iron out differences in the look
and feel of different systems. That's because someone running an
application on a Sun doesn't want it to look and feel like PS/2
and conversely.
> 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.
Use dialog.exe to interactively build dialog boxes etc. in MS Windows with
the mouse.
> 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.
Could you tell me more?
>I was able to crash windows very easily be creating too many C++ objects.
Happened to me when stack/heapsize was to small in the .def file
My personal opinion on CommonView:
1. It uses an accepted language (C++). Applications get all the
MS Windows functionality for free (hardware independance, handling etc.).
2. Glockenspiel guarantees (so they write) portability between MS Windows
and PS/2 (the OS/2 window manager). They told me they are working on
a X11 version (via Motif).
3. I see several advantages of CommonView over 'C' MS Windows programming:
1. Easier to learn. It took me two weeks to get into CommonView
without previous window programming experience. And it was fun.
2. CommonView hides the setup and handling of data structures that
makes up most of any 'C' MS Windows source code.
3. I had no need for Windows software or hardware debuggers.
CommonView does the MS Windows housekeeping, so you can't mess
it up. The usual logical bugs in my code are easy to find as
the application doesn't hang.
4. Not much point using Glockenspiel's compiler without extended memory.
5. CommonView let's you do any MS Window call via handles. This is
nice if you do unusual things like interfacing hardware.
5. Maybe not the best object oriented windows interface. But a good and
usable one.
Gerd.
--------------------------------------------------------------
A good programmer can produce Fortran programs in any languagejonnyg@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.
grg@otter.hpl.hp.com (Gerd Groos) (08/11/89)
C++ seems to be one of the more efficient OOPL's for 'small' machines
like the PC. The code may look ugly on first sight - but so does C code.
I am no C++ or CommonView fanatic just helps me do the job with some fun.
Actor and C_Talk seem to invent their own languages. Isn't it quite a task
to design a language, implement it, do a windows interface and create a
nice environment? I would be interested in comments on Actor and C_Talk.
Are there any others? What is CASE:W? Could someone give me the
address/phonenumber of C_TALK?
I am using windows/386 as a 'programming environment'. I have some
notepad editors and windowed DOS prompts on the screen. I can at least
quickly switch between compiling and editing as well as edit several
files on the screen.
>> Looks like [C_Talk has] written a more usable class tree
Here's the class tree for CommonView (some newer classes are not mentioned):
Accel
App
Bitmap
Brush
Caret
Color
Control
TextControl
Button
RadioButton
PushButton
CheckBox
Edit
MultiLineEdit
SingleLineEdit
ListBox
FixedIcon
FixedText
ScrollBar
HorizScrollBar
WndHorizScrollBar
VertScrollBar
WndVertScrollBar
Cursor
Event
ControlEvt
ExposeEvt
FocusChangeEvt
KeyEvt
MenuCommandEvt
MenuInitEvt
MenuSelectEvt
MouseEvt
MoveEvt
ReSizeEvt
ScrollEvt
EventContext
Window
AppWindow
TopAppWindow
ChildAppWindow
DialogWindow
Font
Icon
Menu
SysMenu
MessBox
ErrorBox
Pair
Dimension
Range
Point
Selection
Pen
Rectangle
ResString
Gerd