Re: Anybody in US using ADA ? One silly idea..

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Tue, 21 Jan 2003 02:10:37 GMT, "Hillel Y. Sims"
<usenet@phatbasset.com> wrote:

>"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>news:b0e5vu$ognn6$1@ID-77047.news.dfncis.de...
>> Hillel Y. Sims wrote:
>>
>[templated C++ sort() is faster than qsort()]
>>
>> This is a wrong comparison. A correct one would be an instance of a
>generic
>> subroutine vs. an inlined subroutine and, note, when the type is
>statically
>> known.
>
>sort<int>() vs. sort_ints()? In that case the performance should really be
>exactly the same (since as you say, it really *is* to a large extent just a
>bunch of text substitution :-). The benefit is that you don't need to
>rewrite or copy/paste the code over and over for each unique type, the
>compiler does it automatically (while maintaining full type safety, unlike
>dumb macros) -- and better yet, when you fix a bug in the generic version,
>it is immediately fixed for all instantiations automatically (vs.
>sort_ints(), sort_floats(), sort_strings(), sort_xyz())

This is an advantage of generics over blind preprocessing. The problem
is whether same can be achieved without both.

Consider class-wide sort written for all arrays derived from some
abstract array of comparable elements. If that sort is inlined, then
then compiler theoretically would have all necessary information to
make code as efficient as generic sort could. Presently it is
impossible in both Ada and C++.

>> > How do you compare gotos to generics? Generics do not destroy structured
>> > code. I just don't understand the analogy.
>>
>> They are as chaotic as gotos. They destroy the type structure of the
>program
>> as gotos do the control flow. Hyman Rosen gave us a brilliant example of
>> generic code for handling dimensioned values. But get a programmer from
>> street and ask him why and how it works. Programming should be as simple
>as
>> tooth powder. (:-))
>
>No argument that some crazy stuff can be done that is really difficult to
>interpret by humans. I'm not sure you've really made the case "generics
>considered harmful" though yet..
>
>> > It can actually help. For example, in the case of the standard C++
>> > container class std::vector<T> -- there can be a specialization defined
>(I
>> > forget if it is mandated by the Standard, but it is possible anyhow) for
>> > all std::vector<T*> such that they are inherited from std::vector<void*>
>> > with just the necessary casts thrown in by the compiler (inline). This
>can
>> > eliminate a large amount of unnecessary code bloat for all
>instantiations
>> > of vectors of pointer types.
>>
>> With pointer types we do not need generics at all, because all pointers
>are
>> of some predictable size.
>
>However, full type safety is maintained without requiring programmers to
>manually do (error-prone) casting.
>
>>Then it is not the actual problem. The problem is
>> that std::vector is not a type, so even std::vector* cannot exist.
>
>Sure it can:
>
>template <typename T>
>void f(std::vector<T>* pVec)
>{
>   pVec->clear();
>   //etc...
>}

This gives nothing because you just moved T from one place to another.
It just highlights the problem. Once you made something generic, then
everything using that becomes generic as well. That's alone is bad.
Buf for inherently non-static things (like class-wide pointers in my
example) it is catastrophic, because there cannot be solution for
them.

---
Regards,
Dmitry Kazakov
www.dmitry-kazakov.de