Re: Question about programming techniques



On Sat, 27 Jun 1998, Kasper Peeters wrote:

> 
> > well one problem is that templates basically generate source instead of
> > being interpreted themselves ... so if you do a list of ints and a list
> > of longs you suddenly have two implementations in the object file ...
> > which is far from optimal ....
> 
> You're not being fair here. If you are happy with explicit casts (in
> user code, rather than in the library) in a C container class library,
> then you could just as well use a container of 'void *' with STL to
> get the same effect.
Another round of exchanging pleasantries ;))))
Ok. It's a bit completly different thing, but it is probably the right
thing to do: Consider how OO languages like Smalltalk/ObjC/TOM handle
this:
- There are no void * pointers (not true for ObjC, but they are
                                rather not used in good ObjC code)
- Anything is an object.
- And as you can send any message to any object, you don't even
  need to bother to ``cast'' the objects of an array.
  (TOM is a bit peculiar, as it supports overloading on parameters
   AND return values, so it needs to know when compiling the methods
   from somewhere *g*)

Consider:

ObjectArray authors = [ObjectArray with ("Author A", "Author B")];

ObjectArray is not a template here. Its just an Array of Objects,
and as Strings are also objects, you can store Strings in there.

And it's completly typesafe, because if I store something
wrong in there, that will be catched when I try to use GnomeAbout ;)
(Why? because the other object probably lacks the methods needed
 to turn it into a char array for Gnome.)

> If you _do_ want casts to happen in the library, you'll have code
> dupication in the C implementation as well. And please note that the
> STL specs say nothing about the internals of the library. It is
> perfectly fine for an STL implementation to make all container types
> share one 'void *' core, and only have a typesafe interface (I'm
There are just some issues here:
-) a double needs obviously on the fly gzipping to fit into a void *
   (*eg* and it's probably architecture dependant)
-) Sometimes you want an array of structs (like GnomeUIInfos), not
   an array of ptrs to structs.
-) And if you start to store objects as (char *)+(len of object), than
   you have the problem that the generic code knows NOTHING aboout
   copy constructors, destructors, etc.
> simplifying here, but you get the point I hope).
Not really. We have a basic problem. Most general languages are
turing complete. So the discussion is somehow moot. But ignoring this
fact, you find, that C++ has many problems:
-) it tries to by highlevel and lowlevel at the some time.
   (For a correct implementation of this idea see Modula 3)
   *) This can give unwanted interferences.
   *) The highlevel ``OO'' style is way to lowlevel still:
      x) no garbage collection.
      x) pointers.
      x) to sumup it's unsafe.
   *) So many C programmers seem to feel, that it's better
      to implement some C++ features in C, and so to know what
      happens, instead of relying upon magic that may break from
      the compiler.
-) C is the API language of Unix. It's almost always ways easier
   to interface to C from other languages than to C++.
   (actually it's the REAL API language of Win32 too *g*)
   As Gnome strives to become a standard, C must be used as the
   API language. (Seems like KDE guys forgot about that part *g*)
-) fucked up OO model: copy by value is a STUPID idea for objects.
   *) It's understandable how this one become reality: mixing
      up of ADTs and OO.
   *) Notice that NO language except C++ uses this as a object model.
      It's always some kind of pointer to the object that is used.
-) C++ is popular because:
   *) hype in 80's.
   *) it's ``clean'' upgrade path from C.
   *) it being good for GUI. Actually, what most people mean is,
      that it's better for GUIs. And knowing often nothing else, they
      concluse it's good. Actually C++ is ways to low for normal
      application programming.

Ok, let's thing about doing systems in the size of R/3:
(I've had many discussions about this with collueges, about
 the feasibilty of a GNU R/3 *g*)
-) You sure need a lowlevel system programming language for some
   parts of the system. It must allow for all crazynesses, as
   the intended targets are probably CS majors that know
   what they do.
   Languages we found: C ObjC
-) application programmers. These guys probably don't know that
   much about programming, but they know about the business side.
   (locally here, we have ``business computer science'' majors)
   For these people, the language MUST be safe:
   So, C, C++, Pascal, etc. are out.
   It should also be efficient as the majority of the system will
   be written here: so interpreted languages are out.
   Languages we found: Modula3, Java, ``safe ObjC''.
   (The ObjC was an idea of stripping ObjC of the C parts,
    and making it work with the ObjC runtime -> ObjC would be
    then the natural lowlevel language. Actually, before implementing
    it, we found TOM, which provides the needed features and some more)
-) customizing programmer:
   needed features: safety, ...
   Here the classical interpreted languages come to mind. Additionally
   with TOM one can use TOM, because TOM programs are by default
   extensible and modifiable.
   (By default I mean, that TOM carries the mechanisms for extending
    classes, posing for another class, etc., so one has rather to
    design something stupid so that extension is hard.)
> 
> As far as Mico is concerned: it's not just the templates that make the
> thing big. The stubs are huge, and there are not many templates used
> there. A 2Mb shared library is not such a big problem, it's the 
> (non-shared) code in each application that makes things problematic.
> 
Admittingly, shared code is of lesser importance, but then, Gnome
aims at being portable -> Not every Unix has that a clever VM management
Linux has.

Andreas



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