Re: Teaching new tricks to an old dog (C++ -->Ada)
From: Ioannis Vranos (ivr_at_remove.this.grad.com)
Date: 03/23/05
- Next message: Andrey Tarasevich: "Re: std::string Destructor Throwing Exception"
- Previous message: gurumare_at_gmail.com: "Re: data validation"
- In reply to: Georg Bauhaus: "Re: Teaching new tricks to an old dog (C++ -->Ada)"
- Next in thread: Georg Bauhaus: "Re: Teaching new tricks to an old dog (C++ -->Ada)"
- Reply: Georg Bauhaus: "Re: Teaching new tricks to an old dog (C++ -->Ada)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 23 Mar 2005 22:53:46 +0200
Georg Bauhaus wrote:
> A vector has an index range built into the language C++.
> It was stated that type based indexing together with
> attributes helps both the writer and the compiler.
> No programmer effort needed.
>
> Elsewhere you say that it is possible and does make sense
> to work around this lack using compile time assertions,
> carfully placing them close to the object to which they are somehow
> related. (Effectively creating an ad-hoc meta-language written in
> templates. Only shows that the thing is indeed missing in C++.)
>
> It makes sense to know the bounds of a container,
> possibly in advance. Are you declaring that std::vector and
> not knowing the bounds is the only reasonable thing to do in
> programming?
>
> Type attributes are a mode of expression, available with
> types in Ada. You can build algorithms around language provided
> attributes, for example bounds, without having to resort to
> mere conventions and the hope that the compiler will do something
> useful with the conventional items.
OK, I think you are right. C++ lacks these, and I wonder why additional
keywords enabling this are not added in language proposals for future
standard revision (C++0x).
>
>> For fixed size arrays and containers it is true, the compiler does not
>> catch at compile time any out of boundaries access. However we can do
>> this explicitly, by using compile-time checked assertions.
>
>
> In other words, C++ array like types don't have these properties.
> I'm not saying this is catastrophic. It's just not available
> unless you roll your own. This has consequences for how you write
> your software. It has consequences for what your compiler can do.
> Some of them are interesing, because of template computing.
>
>
>> > No. I mean a double subtype whose values range from N.M to N'.M'.
>>
>>
>> May you give an example for a container along with such a subtype?
>
>
> It was given, starting this "sub"thread.
>
>> > Here you can see one point that you might want to demonstrate:
>> > The compiler won't tell you that there is something wrong
>> > with
>> >
>> > doors[10].SetOpen().SetNoVan();
>> >
>> > Worse, the program won't tell you either. This shows the missing
>> > link between vector indexing and the base type system in your
>> > approach. You could use
>> >
>> > doors.at(10).SetOpen().SetNoVan();
>> >
>> > and handle the exception _at run time_.
>> > In Ada, the compiler will tell you: "index value 10 is no good!"
>> > because the array "doors" can only be indexed by values effectively
>> > between 0 .. 9. These and only these are the values of the type
>> > enumerating the ten doors, and only these are allowed as index
>> > values x in expressios doors(x).
>> > No exception handling, no .at() needed when you listen to your
>> > compiler and fix the indexing error before you deliver a program.
>> > You get this for free as a result of the language's type handling
>> > at compile time.
>>
>>
>> Will the Ada compiler tell you this, for user-defined types too?
>
>
> An enum is a user defined type.
> Any unconstrained type (including more than array types)
> entails constrained objects, and the compiler may have a word
> in this.
> Maybe, if one gets used to template programming, the basis of the
> language is deliberately ignored?
> Ada just doesn't need templates for many things that are tried
> using templates in C++, because the things are already in the
> language.
>
>
>> Or is this restricted to built-in arrays? If the latest is true, then
>> its value isn't that much.
>
>
> Every bug that is found at compile time is worth a lot
> to me.
>
> Try telling someone that useful array attributes, and type attributes
> and object attributes in general, aren't of much value.
> What else are .begin() and .end() other than roll-my-own replacements
> for something that C style arrays lack, *language-wise*?
> Those working for an insurance company, in a stocks related business,
> in math related computing, statistics, etc. use *Array Programming
> Languages*. Why would they be doing this if good array support
> isn't worth something? What is the value of good array support in
> all those valuable Fortran computing libraries?
>
> Are you saying that a robust base type system isn't worth it because
> of the STL?
> Consider the effort is takes to get a useful STL made of
> basically, at-least-so-many-bits integers, pointers, and malloc().
>
> Please answer this question:
> Why is vector not implemented using vector? (I'm serious.)
OK I get your point, and you are right. These things would be nice to
have in C++, and I think it is possible to have them just by introducing
new keywords in the language, without breaking backwards compatibility.
I do not know why there is no proposal for these.
> The fastest possible element access in C++ is dereferencing a pointer.
> The fastest possible element access in STL/C++ is varying with container
> and method.
>
> Compare
>
> type Floor_Number is -2 .. 52;
> -- sky scraper
>
> type Door_Count is array(Floor_Number) of Natural;
>
> versus
>
> typedef char Floor_Number;
> typedef std::map<Floor_Number, unsigned int> Door_Count;
char does not feel well, one could use short but probably will use int.
> We are discussing fastest access, and type based indexing.
I can't understand why your code has faster access (I assume you mean
run-time efficiency).
> So my question again, what does it take, in C++, to replace
> Floor_Number as typedefed above with something that matches
> the given building's floors exactly?
I assume a vector that permits defining negative indices, and this is
easy to be defined. However I may assume that since no such vector
container is provided (even third-party), I may assume that either it is
not considered as needed, or it is believed that maps and hash_maps can
do the job.
To give another example, .NET does not provide such an array container
either, in its own containers collection. So why such a mainstream
framework does not provide an array type with negative indexing either?
This is not some kind of general proof, but for me it is an indication.
Again, I agree that boundary checking etc are useful and should be added
in C++ perhaps with additional keywords.
> The point is, how does a language help you writing
> correct and efficient programs. C++ the language doesn't
> have fixed size built in arrays. In some problem domains,
> fixed size arrays are very useful, if not essential.
>
> This is why many programming languages have them.
Just to be technically accurate. C++ has fixed size built in arrays. It
doesn't provide range checking for them though.
int array[4];
is a fixed size, stack based, built in array.
Fixed size in the heap:
int *parray= new int[4];
Also, standard library containers with fixed size are valarray and bitset.
-- Ioannis Vranos http://www23.brinkster.com/noicys
- Next message: Andrey Tarasevich: "Re: std::string Destructor Throwing Exception"
- Previous message: gurumare_at_gmail.com: "Re: data validation"
- In reply to: Georg Bauhaus: "Re: Teaching new tricks to an old dog (C++ -->Ada)"
- Next in thread: Georg Bauhaus: "Re: Teaching new tricks to an old dog (C++ -->Ada)"
- Reply: Georg Bauhaus: "Re: Teaching new tricks to an old dog (C++ -->Ada)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
