XPost: alt.os.development   
   From: maxim@storagecraft.com   
      
   > >     About Ada. The "widespread" of Ada in real-world software business   
   >proves   
   > > my position and not yours :-)   
   >   
   > The most widespread languages are definitely COBOL and most probably VB.   
      
   Wrong. Please name the software products written in COBOL and VB. Neglectable   
   amount, compared to C/C++ software. Neglectable amount even to Java now.   
      
   Nearly nobody is developing in COBOL in 2000ies, so is VB6 - there were major   
   efforts in most companies to port their legacy VB6 software to Java and .NET.   
      
   > [ Popularity proves nothing, but bad taste. ]   
      
   I do not think that the notion of "taste" is appliable to engineering.   
   Effectivity - yes, taste - no. "Popular" does not mean "bad" automatically, and   
   has a major advantage of being well-known, lesser issues, and good community   
   support.   
      
   > Well, flying Airbus or Boeing I wouldn't rely on programmers not making   
   > stupid errors. Fortunately, their software is written in Ada, not in K&R C.   
      
   There was a very old funny story about the attempt in writing the firmware for   
   some F-16 internals in Ada. The figher went backside-top on crossing the Earth   
   equator due to software bug. After this, Ada was abandoned and the assembler   
   remained as the primary tool :-)   
      
   > > Most inter-module calls are done with no mutexes held. This is a must. This   
   is   
   > > a default - you must not do any, say, API calls with mutexes held. You must   
   not   
   > > do callbacks to upper layers while you have any mutexes held. If the things   
   are   
   > > otherwise and this is allowed - then this must be documented.   
   >   
   > = not composable. That's the whole point.   
      
   So are the language embedded mutexes, like Java's "synchronized" keyword. The   
   only thing which they can do is to throw an exception on deadlock, how funny   
   (the frame-based try/catch exception model is notorios for being unable to   
   recover from the exception, since it's exact cause is not known at all in   
   "catch" operator. It can only report the error and die).   
      
   Anyway calling APIs while holding a mutex is evil, since it introduces the   
   possibility of the deadlocks and reduces the scalability. Mutexes must be used   
   only to guard your own data structures. Calling std::vector::operator[] on your   
   own data structure from under the mutex is fine, calling CreateWindow or   
   connect() is a disaster.   
      
   > [ When discipline is claimed to be a solution, that implies the tool is   
   > wrong. ]   
      
   Then there is no correct tools in the whole world, only the illusion of these   
   :-) the good practicizing engineers know this very well.   
      
   > If that were true, we would still have been programming in hexadecimal   
   > codes.   
      
   No. The only advantage of the higher-level languages is to reduce the amount of   
   coding, and reduce the burden on coder's attention. Nothing more.   
      
   Assembler imposes major load on coder's attention, is not portable and has no   
   advantages over C in nearly all cases (except the CPU-specific opcodes and   
   extremely high-perf things). That's why C is used instead of assembler - the   
   very practical and describable cause.   
      
   With heavy language-embedded features, you must keep in mind how they are   
   implemented with all the gory details, otherwise, you will hit some problems   
   very soon.   
      
   > Strong manifested typing is good, when properly implemented. C++ violates   
   > type contracts in several places. For example, when methods re-dispatch.   
   > This is a safety breach, because a derived type may override methods you   
   > call from your specific [and tested] implementation.   
      
   Only virtual methods can be overriden this way, and, by declaring something   
   "virtual" in the base class, you just make a hint for derived class   
   implementors - "and this is for override".   
      
   > >> 1. Small value objects cannot have classes (int)   
   > >   
   > > Why is this bad?   
   >   
   > Any language irregularity adds complexity.   
      
   Why? The C++ axiom of "only the structure types are objects" is very easy to   
   comprehend and follow, it is not complex.   
      
   >OS badly needs small efficient   
   > polymorphic objects.   
      
   ...and no widespread OS uses them internally in the kernel code :-)   
      
   >Consider all sorts of smart-pointers, arena-pointers,   
   > GC-pointers, handles [pointers enforcing accessibility rules] etc.   
      
   All of these pointers can be implemented in C++ with ease, like the MS's   
   _com_ptr_t. C++ is very strong in this.   
      
   > > C++ classes are _structure types only_. If you need int as a   
   > > class (for what?) - write your own "class Int", it's trivial.   
   >   
   > As a class it will have vtab pointer.   
      
   It will not unless you will declare at least 1 virtual member function. Just   
   plain a C structure of single "int", which is the same in-memory object as   
   "int" itself.   
      
   > Write (Where : in out Device; What : Thing);   
   >    -- Dispatches on both Device and Thing.   
      
   Yes, this one will not work without hard-coding some ways for Device and Thing   
   to investigate the capabilities on one another. In COM architecture, this is a   
   well suggested way - Thing must discover the capabilities of Device from most   
   sophisticated to least, and choose the most-sophisticated-still-supported   
   method of writing itself :-)   
      
   But is it needed in practice? In practice, it is:   
      
       Device::Write(StandardFormatData d);   
       virtual  StandardFormatData Thing::Serialize();   
       Thing::Write(Device dev)   
       {   
           dev.Write(this.Serialize());   
       }   
      
   or such.   
      
   > >> 4. Construction model is unsound (no dispatch in c/dtors)   
   > >   
   > > C++ suggests all dtors to be virtual for all classes which have at least 1   
   > > virtual method. So, the problem is solved.   
   >   
   > Please, refer to the C++ standard.   
      
   Having virtual dtors is a good coding practice recommened by the language   
   author.   
      
   >You cannot dispatch from a c/dtors.   
      
   You can from dtors, not from ctors though - the object is not built yet, no   
   proper vtbl pointer.   
      
   > Yes, and because these OSes are notably bad, I conclude that probably it   
   > was unwise to write them in C...   
      
   Oh, yes, everything in this world is bad, but nobody have implemented anything   
   better (Windows is - roughly - the same quality as Linux nowadays in technical   
   sense). :-)   
      
   It is well-known why the complex languages like Ada (and yes, even C++) are not   
   used in OSes. The result will be 100% tied to this language and nothing else   
   can be used in development for this OS, which is a bad idea. C is optimal in   
   this case - not assembler, has high-level constructs, but they require no   
   runtime support - like the C++'s exceptions do require. I expect Ada to require   
   lots of runtime support for its features.   
      
   --   
   Maxim Shatskih, Windows DDK MVP   
   StorageCraft Corporation   
   maxim@storagecraft.com   
   http://www.storagecraft.com   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)