Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)

From: Dr. Adrian Wrigley (amtw_at_linuxchip.demon.co.uk.uk.uk)
Date: 03/11/05 

Date: Fri, 11 Mar 2005 20:05:28 GMT

On Fri, 11 Mar 2005 19:32:31 +0100, Peter Koch Larsen wrote:

>
> "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> skrev i en
> meddelelse
> news:pan.2005.03.11.18.01.45.684764@linuxchip.demon.co.uk.uk.uk...
>> On Thu, 10 Mar 2005 17:39:13 -0500, REH wrote:
>>> Ada features I would love to have in C++:
>>> * "new types" and sub-ranges
>>
>> Agree strongly. (with compiler-generated checking!)
>
> This can be implemented mostly with templates.

the evidence I find is that these Ada features meet programmers'
needs (because they are widely used), yet the nearest equivalent
with templates is almost never used (I have never seen examples).
I don't think new template classes match the utility of new
types and subranges in practical terms (but I'm prepared to
be shown wrong!).

How, for example, do you create a new 2-D array indexed by
enumeration sub-ranges?

For example, what is the templated, range-checked equivalent of:
------------------------------------------
   generic
      type Index_T is (<>);
      type Intensity_T is digits <>;
   package CrossBright_P is
      type CrossIntensity_T is array (Index_T, Index_T) of Intensity_T;
-- more subprograms here
   end CrossBright_P;

   type EMSpectrum_T is (Gamma_Ray, X_Ray, Ultra_Violet, Visible, Infra_Red, Microwave, Radio_Wave);
   type Intensity_T is digits 6 range 0.0 .. 10_000.0;

   type CrossSpectrumIntensity_T is array (EMSpectrum_T, EMSpectrum_T) of Intensity_T;

   package MyCrossBright is new CrossBright_P (EMSpectrum_T, Intensity_T);

   CrossIntensity : MyCrossBright.CrossIntensity_T := (others => (others => Intensity_T'First));
--------------------------------------------------------------

>>> * runtime template instantiation (I think being able to instantiate
>>> generics dynamically is the coolest thing!)
>>
>> This would be nice!
>
> How would you do that without "compiling on the fly"?

same way as in Ada!

>>> * subprograms inside subprograms. I think it would be great for use
>>> with the STL (i.e., using a local function with std::foreach)
>>
>> Agree strongly.
>
> This will be part of the next standard, I hope. Still i do not believe it to
> be esential for use.

It is sometimes handy to use the C preprocessor for local functions

>>>* packages. namespaces are nice, but packages make modularity of very
>>> large system a lot easier. Especially now with "use type"
>>
>> Vital! C++ and C suffer a lot from not enforcing encapsulation,
>> allowing headers to break stuff etc. Better control of scope
>> and visibility. Better separation of interface and implementation
>>
>>>* representation specifications!!!!
>>
>> Agree.
>
> Why? What is the purpose - if not to restrict portability?

To get access to externally defined data storage!!
For example, hardware devices, network data representation,
interfacing to machine code etc.

...
>> -------------------------------------------------------------
>> My list of Ada features I would love to have in C++ adds:
>>
>> Concurrency. Tasks. Protected objects.
>> Distributed programs. Persistent variables.
>
> I doubt that this should be part of the standard. What is needed is
> specification of low-level features in e.g. multiprocessor environments.

I think portable concurrent or distributed programming is a paradigm
poorly (non) supported by C++. The current situation is a mess.

>> Eliminate large swathes of the C++ standard which leaves
>> the semantics up to the compiler!
>
> Most of these "implementation defined" parts are there for portability. To
> many definitions will make it more difficult to port C++ to other platforms.

But at least any difficulty is addressed once per platform,
rather than once for each program!

>> Named parameter association. Proper parameter modes
>> "out" and "in out" modes
>
> I do not see the purpose of the out-parameter. Why not simply return the
> value(s)?

How do you return multiple values?

> As for named parameter associations, these can again be implemented in a
> library.

Again, they are widely used in Ada code, but very rarely in C++.
I found the library implementation kludgey.

>> clarity over arrays. C++ gives you choice of pointers
>> C arrays, vectors. This is one example of where the
>> 'C' facilities were too limited, and C++ added
>> alternatives, rather fhan fixing what existed in C.
>> (and char *, char arrays, string etc)
>
> For C++ portability from C was (and is) an important issue. Thus there is no
> question about remocing e.g. pointer-arithmetic and decaying of arrays to
> pointers. This simply can not happen. Also some of these features are needed
> for an efficient implementation of low-level classes (e.g. std::vector).
> What you can do is not use these features. And it is just a matter of
> education to routinely use e.g. std::vector< t > and std::string instead of
> arrays and char pointers.

You can't routinely use only the new features, because library
code mainly uses the old features. (most libraries are supplied
via C-style header files)

>> Strong(er) typing, better enumerations, fixed point types,
>> modular types *and* non-modular types. Basic type attributes.
>
> There are some bad decisions in the type system - specifically i hate the
> automatic conversions from double to integral value. But again - this is
> something you have to live with.

(only if you have to use C++!)

>> More robust, more readable, less terse syntax, particularly
>> for complex templates (really!)
>
> Right. The template stuff could possibly have been more elegant.
>>
>> Portability without resorting to preprocessor directives
>> and conditional compilation
>
> I am not sure i follow you here. In what way do you want portability? Are
> you thinking of e.g. portability between an X-windows system and Windows? Or
> portability of lower-level constructs such as multithreading or networking?
> I wonder how Ada does this stuff.

portability for different type sizes (eg pointer widths, char signedness,
basic type ranges, data alignment)

>> associative arrays (from Perl)
>
> I thought Ada supported generic programming. Isn't it then just a question
> of creating a library?

it's a nuisance to have to define a suitable hashing function for
each type, particularly one you are several levels into a generic nesting!
The hashing function might need to be passed in at the top and
built in stages at each level. Not nice. (is there an alternative?) 

-- 
Adrian

Relevant Pages

  • Re: [OT] Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... the evidence I find is that these Ada features meet programmers' ... with templates is almost never used. ... > specification of low-level features in e.g. multiprocessor environments. ... I think portable concurrent or distributed programming is a paradigm ...
    (comp.lang.cpp)
  • BYTE Update: =?ISO-8859-15?Q?=A0Ada?= and the Language Renaissance
    ... Ada and the Language Renaissance ... The Ada 95 revision added object oriented features including ... Ada programming at: http://ada.krischik.com ...
    (comp.lang.ada)
  • Re: Improving Adas image - Was: 7E7 Flight Controls Electronics
    ... the many Run-time environments that an Ada program includes when it is ... As you know, when it comes to software, when we expect more features we ... Programming language can matter. ...
    (comp.lang.ada)
  • Re: Fortran vs. C++ : Which is best to choose now i
    ... >> As I understand things (and I'm NOT interested in a language war), ... >> programming through the template facility and associated standard ... performance *entirely* to templates. ... avoiding the OOP features entirely and coding in conventional C. ...
    (comp.lang.fortran)
  • Re: Conformance
    ... better than C for certain types of programming, and C is better than C++ ... You think that C will lose because it has far less features than C++. ... currently a superior language. ... libraries, some of which were last updated decades ago. ...
    (comp.std.c)