XPost: alt.os.development   
   From: mailbox@dmitry-kazakov.de   
      
   On Mon, 20 Feb 2006 17:55:06 +0300, Maxim S. Shatskih wrote:   
      
   > 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.   
      
   The relation between software developing and maintenance is about 1:9.   
      
   >> [ Popularity proves nothing, but bad taste. ]   
   >   
   > I do not think that the notion of "taste" is appliable to engineering.   
      
   Software developing isn't an engineering, alas.   
      
   >> = not composable. That's the whole point.   
   >   
   > So are the language embedded mutexes, like Java's "synchronized" keyword.   
      
   That's their problem. I said before, that mutex is a too low-level concept.   
   There are higher-level mechanisms, some of them exclude deadlocking. There   
   was some progress in this field in recent years. Refer Ravenscar profile   
   for further information.   
      
   >> [ 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.   
      
   In case you have a wrong impression that I am an academician. No, I'd like   
   to be one, but I am a professional software architect, that's what I am   
   paid for. Our clients are large automotive and avionics firms. Trust me, a   
   lot of engineering is going on there.   
      
   >> 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".   
      
   Hmm, I don't know what you are talking about. The issue is re-dispatch from   
   methods. Like:   
      
   class Foo   
   {   
      virtual void Bar ();   
      virtual void Baz ();   
   };   
      
   void Foo::Baz ()   
   {   
      Bar (); // This dispatches, but it shouldn't,   
           // because dispatch already happened to come to Baz   
   }   
      
   > Why? The C++ axiom of "only the structure types are objects" is very easy to   
   > comprehend and follow, it is not complex.   
      
   Yep, Orwellian "all animals are equal, but some animals are more equal than   
   others."   
      
   >>> 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.   
      
   That's the point.   
      
   >> 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.   
      
   In practice it means a manual implementation of cascaded dispatch, with a   
   good chance to have some combinations undefined, wrong or self-recursive.   
      
   >>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.   
      
   Wrong. Please, read the standard.   
      
   >> 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   
      
   Would you pay for? The market is ruined.   
      
   --   
   Regards,   
   Dmitry A. Kazakov   
   http://www.dmitry-kazakov.de   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)