From: mailbox@dmitry-kazakov.de   
      
   On 25 Feb 2007 07:55:15 -0800, Seweryn Habdank-Wojewódzki wrote:   
      
   > Dmitry A. Kazakov wrote:   
   >   
   >>> They forgen that on DSP float and double are other than   
   >>> on AMD Opteron 64bit.   
   >>   
   >> This is why higher-level languages have elaborated numeric types rather   
   >> than "guess-which-double." I fail to see how your complain, that C++   
   >> numeric types aren't portable, could serve in defence of either C++ or   
   >> templates!??? (:-))   
   >   
   > I do not know what is the problem. My Kalman-bucy filter is working on   
   > DSP and also on PC, without any problems.   
      
   Should it mean that you withdraw your complain about portability of   
   algorithms implemented in terms of double? That would be silly.   
      
   >> Last but not least, there might be some difficulties with certifying   
   >> class-wide subprograms, but what about certifying C++, and one with   
   >> templates? No chance.   
   >   
   > Try to use templates and disassembler then you will understand what is   
   > the power of them. Look calefuly that temaplates disappears from the   
   > code if they are not used, so the coverage is rather 100% if   
   > programmer will not creat template explicitely and do not use it.   
      
   I fail to see here any relation to the issue whether a templated code is   
   certifiable. What is your point?   
      
   >>> T & multiply ( T const & rhs, T const & lhs, T & result );   
   >>                                                                ^^^^^^^^   
   >>                                                          What is this ????   
   >   
   > What do you think?   
      
   That this does not look like an infix operation, which multiplication is.   
      
   >> Hmm, that was illegal. Granted, I didn't look into the latest C++   
   >> standard. Are you sure that local objects can be returned by reference:   
   >>   
   >> char []& Array_Factory ()   
   >> {   
   >>    char Local [20];   
   >>   
   >>    return Local;      // Is it legal?   
   >> }   
   >   
   > No this is not legal, but construction above is legal. And works on   
   > stack as you want to.   
      
   How can something illegal work? You claimed that local objects can be   
   returned by reference. Now as we have rebutted this, we are back to my   
   initial point that C++ cannot return polymorphic objects on the stack.   
      
   >> You don't see problems with memory leaks and dangling pointers?   
   >   
   > Generally not. If I am sure what I doing I newer have memory leaks and   
   > dangling pointers. Especially I do not beliewe that any language that   
   > has any kind of dynamic whatever have no dangling pointers. In Java   
   > there is quite popular: NullPointerExceptrion - it means the reference   
   > is not set to proper object or even more is set set to anything.   
      
   You are confusing dangling pointers and null pointers.   
      
   >> Then they suffer same problems as pointers do:   
   >>   
   >> 1. Aliasing   
   >   
   > Shaw me the real problem with aliasing in C++. Alasing is a problem   
   > when you do nasty code, when you combine raw C functions with C++. I   
   > am using C++ for RT systems from 3 years and I had never this problem.   
   >   
   >> 2. Heap allocation.   
   >   
   > Hmm... Show me real problem with that. I will prepare small tool in C+   
   > + and we can compare performance.   
   >   
   >> 3. Memory management problem   
   >   
   > And what? Again, shaw me the problem with memory in good styled C++   
   > code. I do not care about not very flexible C programmers which   
   > prefers malloc and free, then smart pointers.   
      
   Correct me if I am wrong. You admit existence of the mentioned above   
   problems, but propose to solve them by a better training and more   
   disciplined programming? I.e. the language design faults should come at   
   cost of the layman programmers. Wouldn't it be better to allocate the   
   resources and efforts spent on training and discipline to workaround a   
   messy language, rather on solving the core application domain problems,   
   such as dealing with fuzzy sets?   
      
   >> In question was, whether templates can switch implementations at run time.   
   >   
   > Not. This question can not be put. Because none said such a thing. the   
   > think is that you can do many things in templates, but only if they   
   > are done in compilation time.   
      
   One implies another.   
      
   >>> Basic_argument_type;   
   >>   
   >> What is Basic_argument_type? Argument of what? Which properties it has?   
   >> etc. It is a negligence to have such kind "I-don't-know/care-what" types.   
   >   
   > Yes,. This is the bottom of the dynamic programming.   
      
   This is called software design, it is not specific to dynamic programming,   
   whatever that term might mean.   
      
   > Look on Java. They have JObejct. What is that?   
      
   I am not sure what is your point here.   
      
   > This is object to have all objects in one tree.   
      
   No, this is technically impossible. There cannot be a self-consistent type   
   system with single ancestor for all types.   
      
   As for JObject, it has specific methods which can be identified. These   
   methods then determine the purpose and the context where JObject comes in   
   question and where it does not. If Java did not do that, that's Java's   
   problem. It is not my favorite language anyway.   
      
   My point is that an analysis of the interface of the class at hand is an   
   essential part of software design. In our case the domain set of a fuzzy   
   set is *not* all JObject. Before you do anything, you have to define the   
   class of domain sets. Templates wake an illusion that one could skip that   
   vital design step. This not even generic's fault. Contracted generics don't   
   suffer this particular problem. It is very specific to C++ templates alone.   
      
   --   
   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)