access & address

access & address

[Hans Van den Eynden]

An access is not a pointer. System.Address is a pointer. I know that
there are
functions to convert an access to an Address. But are there functions
to convert an access to an Address?? And what about Ada's type safety
than ??

Re: access & address

[Martin Krischik]

Hello,

> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1347924.5V7QhTSfdI@linux1.krischik.com...
>> Unlike C/C++ where you can't switch type safety on even when you
> desperately
>> need it.

> You obviously know nothing about C++ then.

I sure C++. All I have to say is:

unsigned A = -1;
char B = 256;

If you are very very luck your compiler will warn you.

And that are only the primitive examples. We have not even spoken about the
failure called "typedef" which should really be called "type_rename".

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: access & address

[CBFalconer]

Martin Krischik wrote:
>
... snip ...
> 
> I sure C++. All I have to say is:
> 
> unsigned A = -1;
> char B = 256;
> 
> If you are very very luck your compiler will warn you.

We recently had an unholy row about this in c.l.c, as applied to
the error returns from strtoul().

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Re: access & address

[Martin Krischik]

CBFalconer wrote:

> Martin Krischik wrote:
>>
> ... snip ...
>> 
>> I sure C++. All I have to say is:
>> 
>> unsigned A = -1;
>> char B = 256;
>> 
>> If you are very very luck your compiler will warn you.
> 
> We recently had an unholy row about this in c.l.c, as applied to
> the error returns from strtoul().

Only the error returns are wacky? 

"followed by a single  optional `+' or `-' sign."

What do you need a '-' in 'unsigned long int'? And it even gets better:

"The strtoul() function returns either the result of the conversion or, if
there was a leading minus sign,  the negation  of the result of the
conversion, unless the original (non-negated) value would overflow;"

Which negative valued in 'unsigned long int'?

You don't need to answer - there where just rethoric question. It's just
that my opinion on C has hit a new all time low.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: access & address

[Martin Krischik]

Marc A. Criley wrote:

> "Xenos" <dont.spam.me@spamhate.com> wrote:
>>
>> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
>> news:1347924.5V7QhTSfdI@linux1.krischik.com...
>> > Unlike C/C++ where you can't switch type safety on even when you
>> desperately
>> > need it.
>> >
>> You obviously know nothing about C++ then.
> 
> Despite years now of professional programming with C++, I must've missed
> the compiler option that tells the compiler to verify that scalar types
> are not being confused.
 
> Don't tell me I can write a class to make this check, no one writes
> classes
> to keep track of item counts.

Actually I did! An Ada::Range template.

Most used type is "Ada::Natural" since most C++ programmers can't even get
int and unsigned right and sadly they do write libraries I have to use.

There is of corse a weekness:

typedef Ada::Range<int, 1, 12> Month;
typedef Ada::Range<int, 1, 12> US_Hours;

And please: I know I could use classes. But that is just another ugly hack!
And why must save and secure be an ugly hack?

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: access & address

[Xenos]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1982479.VT7X1MC7VE@linux1.krischik.com...
> Most used type is "Ada::Natural" since most C++ programmers can't even get
> int and unsigned right and sadly they do write libraries I have to use.
That's a very insulting, generalizing, and incorrect statement.  Besides, if
you think Ada'a Natural  is equivalent to C++'s unsigned, that is what is
sad.

>
> There is of corse a weekness:
>
> typedef Ada::Range<int, 1, 12> Month;
> typedef Ada::Range<int, 1, 12> US_Hours;
>
> And please: I know I could use classes. But that is just another ugly
hack!
> And why must save and secure be an ugly hack?
>
One man's ugly hack is another's versatility.  Besides, you don't have to
use a class to make your above instanitations unique.  You can use enums.
If you define an enum such as:

enum month {First_Month = 0, Last_Month = 12};

The C++ standard says that any value within the range is valid (actually its
any value less than or equal to the closed power of 2, not less than 12, but
close enough).  It also treats month as a unique type for overload
resolution. So, your typedef becomes:

typedef Ada::Range<month, First_Month, Last_Month> Month;  Which will be
unique from Hours.  You, of course, will still proclaim it an ugly hack, but
you don't need an extra class (and you now have "better" names for your
months than 1-12).  Besides, ugly or not, the language does give you the
ability to overcome its weaknesses.  Ugly is a different matter.

Regards.

Re: access & address

[Martin Krischik]

Xenos wrote:

> 
> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1982479.VT7X1MC7VE@linux1.krischik.com...

>> Most used type is "Ada::Natural" since most C++ programmers can't even
>> get int and unsigned right and sadly they do write libraries I have to
>> use.

> That's a very insulting, generalizing, and incorrect statement. 

Born out of experience. Prehaps I have just seen to much code where the
result of sizeof or std::string::lenght was stored in an int or long or
whatever else is just available. The returnvalue for both is size_t.

I am not suprising that Win64 takes so long to finish.

And then there was the infamous netscape installer which refused the
installation because I had "-2147483648" bytes free. Well, the drive had in
fact 6GB free and the 32 bit free function returend maximum availability -
4GB.

> Besides,
> if
> you think Ada'a Natural  is equivalent to C++'s unsigned, that is what is
> sad.

No. Natural is an int with only positive values. Which means that it can be
savely converted into either int or unsigned int.

>> There is of corse a weekness:
>>
>> typedef Ada::Range<int, 1, 12> Month;
>> typedef Ada::Range<int, 1, 12> US_Hours;
>>
>> And please: I know I could use classes. But that is just another ugly
> hack!
>> And why must save and secure be an ugly hack?

> One man's ugly hack is another's versatility.

Well, I see the difference between a hack and versatility it terms of syntax
clutter (I am not against typing if it make things clear) and sematic
clutter (Does the average developer understand what i am doing)

> Besides, you don't have to  
> use a class to make your above instanitations unique.  You can use enums.
> If you define an enum such as:
> 
> enum month {First_Month = 0, Last_Month = 12};
> 
> The C++ standard says that any value within the range is valid (actually
> its any value less than or equal to the closed power of 2, not less than
> 12, but
> close enough).  It also treats month as a unique type for overload
> resolution. So, your typedef becomes:
> 
> typedef Ada::Range<month, First_Month, Last_Month> Month;  Which will be
> unique from Hours.  You, of course, will still proclaim it an ugly hack,
> but you don't need an extra class (and you now have "better" names for
> your
> months than 1-12). 

Well actually, for the type Month it is quite cool.

> Besides, ugly or not, the language does give you the 
> ability to overcome its weaknesses.  Ugly is a different matter.

But there are two killer question:

Does the stl have it?
Does the average library vendor use it?

I am not sitting on an island programming for fun.

With Regards

Martin 

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: access & address

[Xenos]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:1137756.92Qd5cOqoD@linux1.krischik.com...
> Born out of experience. Prehaps I have just seen to much code where the
> result of sizeof or std::string::lenght was stored in an int or long or
> whatever else is just available. The returnvalue for both is size_t.
>
Actually no, the type of std::string::length() is std::string::size_type
which may or may not be std::size_t.  Although, there is nothing necessarily
wrong with putting the value in int or long.  It comes down to knowing your
data.  int is guaranteed to hold a value of at least 65535.

Re: access & address

[Martin Krischik]

Xenos wrote:

> 
> "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> news:1137756.92Qd5cOqoD@linux1.krischik.com...
>> Born out of experience. Prehaps I have just seen to much code where the
>> result of sizeof or std::string::lenght was stored in an int or long or
>> whatever else is just available. The returnvalue for both is size_t.

> Actually no, the type of std::string::length() is std::string::size_type
> which may or may not be std::size_t.

I know that. 

> Although, there is nothing 
> necessarily
> wrong with putting the value in int or long.  It comes down to knowing
> your
> data. 

Currently I enjoy patching together the libraries of two different vendors.
Both of which have a C interface. That puts a real new twist to "knowing
your data". And only when PC-lint runs I know when the two interfaces won't
fit together.

> int is guaranteed to hold a value of at least 65535. 

I thought int must only be signed 16bit - and that goes only to 32767. While
size_t need to be large enough to hold any size. Hence it is unsigned. And
on one of my machines it is actually 64 bit.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: access & address

[Rich Herrick]

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:3025014.yqGbeSrbak@linux1.krischik.com...
> Currently I enjoy patching together the libraries of two different
vendors.
> Both of which have a C interface. That puts a real new twist to "knowing
> your data". And only when PC-lint runs I know when the two interfaces
won't
> fit together.

I had to convert a large piece of middleware from Ada (83) to C a few years
back.  My company scheduled 3 MM to do the work.  I did it in a week.  I
don't know what that says, except maybe its a little easier than going the
other way.

>
> > int is guaranteed to hold a value of at least 65535.
>
> I thought int must only be signed 16bit - and that goes only to 32767.
While
> size_t need to be large enough to hold any size. Hence it is unsigned. And
> on one of my machines it is actually 64 bit.

Internally, signness doesn't matter on the size of the value that can be
represented.  The only time it matter, is in intrepretation.  Maybe this was
your argument about not liking how C deals with signness?  For good or ill,
C was a "step above" Assembly, were signness is only an issue when choosing
your instructions.  The same quantity can be 65535 or -1 (assuming 2's comp.
in this can) depending on what instruction is used.  C standard says that
a -1 assigned to an unsigned variable will give that variable's type's max.
size.


At work I do a lot of Ada (mostly 83, but we are moving to 95--yeah!), C and
C++.  For my own stuff, I prefer C++, when I don't have to worry about
someone dying if my code does.  That's just my preference--my hammer against
your saw.

Regards.

Re: access & address

[Björn Persson]

Xenos wrote:

> If you define an enum such as:
> 
> enum month {First_Month = 0, Last_Month = 12};
> 
> The C++ standard says that any value within the range is valid (actually its
> any value less than or equal to the closed power of 2, not less than 12, but
> close enough).

So I can assign 15 to it? Which month would that be? And which month is 
number 0? That's not what I call "close enough".

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: access & address

[Xenos]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]


"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:0hSbd.106246$dP1.397440@newsc.telia.net...
Xenos wrote:

>> If you define an enum such as:
>>
>> enum month {First_Month = 0, Last_Month = 12};
>>
>> The C++ standard says that any value within the range is valid (actually
its
>> any value less than or equal to the closed power of 2, not less than 12,
but
>> close enough).

>So I can assign 15 to it? Which month would that be? And which month is
>number 0? That's not what I call "close enough".

No, perhaps my example was a little too simplicistic, or you knew what I
meant and just choose to be snide.  By "close enough" I was referring to my
explination of the standard.  0 was a type-o, and beg your forgiveness for
making one.  I know that when I am writing in Ada, I magically never make
one and you must not either.  First, you can't assign 15 to it, you can't
assign an integer to an enum in C++ without an explicit cast.  My point was
that just specifying the upper bound is good enough to guarantee the
language internally uses an integer type with a big enough range to
accomodate you.  If I were to actually do months is would be something like:

enum months {january, february, .... , december};

and not use numbers.  The example was just to show you how you could make
the template types unique without needing to define another class.  The
ranged class should by defined in such a way that only its base type T (in
this case months) is castable to it.

regards.

Re: access & address

[Björn Persson]

Xenos wrote:

> 0 was a type-o

I thought it might be, but so many programmers like to count everything 
from zero so I couldn't be sure. And the enumeration would have had a 
valid value represented as 0 anyway, just like it would have had a valid 
value represented as 15, wouldn't it?

> My point was
> that just specifying the upper bound is good enough to guarantee the
> language internally uses an integer type with a big enough range to
> accomodate you.

So by "close enough" you meant "enough bits to be able to represent all 
values from 1 to 12"? Then I misunderstood you. It looked like you meant 
"close enough to actually enforcing the restriction that only values 
from 1 to 12 are valid".

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: access & address

[Martin Krischik]

Bjï¿œrn Persson wrote:

> Xenos wrote:
> 
>> 0 was a type-o
> 
> I thought it might be, but so many programmers like to count everything
> from zero so I couldn't be sure. And the enumeration would have had a
> valid value represented as 0 anyway, just like it would have had a valid
> value represented as 15, wouldn't it?
> 
>> My point was
>> that just specifying the upper bound is good enough to guarantee the
>> language internally uses an integer type with a big enough range to
>> accomodate you.
> 
> So by "close enough" you meant "enough bits to be able to represent all
> values from 1 to 12"? Then I misunderstood you. It looked like you meant
> "close enough to actually enforcing the restriction that only values
> from 1 to 12 are valid".

Well, he was referring to my Ada::Range<> template. And in thar respect it
is enough to have all values between 1 .. 12. Once the enum is used to
instantiate my template as in Ada::Range<Month, January, December> then
1 .. 12 would indeed be enforced as well.

And, praise where praise is due: xenos enum trick for creating strongly
typed integers in C++ is indeed best I have seen until now. Only now the
C/C++ enum has tree different jobs to do - For my taste a bit overburdened
for one language construct.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: access & address

[Xenos]

"Marc A. Criley" <mcNOSPAM@mckae.com> wrote in message
news:2t7jm8F1sp752U1@uni-berlin.de...
> "Xenos" <dont.spam.me@spamhate.com> wrote:
> >
> > "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
> > news:1347924.5V7QhTSfdI@linux1.krischik.com...
> > > Unlike C/C++ where you can't switch type safety on even when you
> > desperately
> > > need it.
> > >
> > You obviously know nothing about C++ then.
>
> Don't tell me I can write a class to make this check, no one writes
classes
> to keep track of item counts.  And if I create a CApples class and a
> COranges class that includes quantities and prevents me from mixing Apples
> and Oranges, why is it that _I_ then have to code up the range checking,
> when every Ada programmer would write:
>
>   type Apple_Count  is range 0 .. 500;
>   type Orange_Count is range 0 .. 120_000;
>
> and let the compiler do both type safety and range checking.
>
Your point was not that you disliked the way you "switched on" type safety
in C++.  You said you could not do it; you're point was incorrect.  Don't
make a statement, and when told you're wrong say, "oh, yeah you can do X,
but I don't like X."  Such does not maintain the veracity of your statement.

Nothing prevents you from mixing Apples and Oranges, you just have to tell
C++ how you want this accomplished.  Plus, you can tell the compiler whether
to allow an implicit conversion or not with the explicit keyword.  Weren't
you just arguing for type-safely?  You say C++ is not type-safe, yet you
complain you can't just mix apples and oranges.

Yes, Ada has more type safety than C++, but saying is completely without any
is just plain wrong (even C has *some*).  Yes, its type-safety with
numerical and (decayed) arrays could be better.  Its safety with classes is
very strong.  Enumerations are close, except for allowing implicit
conversion to int and not automatically range-checking.  Even type-safety
for pointer types is very strong, allowing only implicit conversions to
void* and base-class pointer types (it is, of course, missing Ada's strong
scoping rules for access types).

Re: access & address

[Martin Krischik]

Xenos wrote:

> 
> "Marc A. Criley" <mcNOSPAM@mckae.com> wrote in message
> news:2t7jm8F1sp752U1@uni-berlin.de...
>> "Xenos" <dont.spam.me@spamhate.com> wrote:
>> >
>> > "Martin Krischik" <krischik@users.sourceforge.net> wrote in message
>> > news:1347924.5V7QhTSfdI@linux1.krischik.com...
>> > > Unlike C/C++ where you can't switch type safety on even when you
>> > desperately
>> > > need it.
>> > >
>> > You obviously know nothing about C++ then.
>>
>> Don't tell me I can write a class to make this check, no one writes
> classes
>> to keep track of item counts.  And if I create a CApples class and a
>> COranges class that includes quantities and prevents me from mixing
>> Apples and Oranges, why is it that _I_ then have to code up the range
>> checking, when every Ada programmer would write:
>>
>>   type Apple_Count  is range 0 .. 500;
>>   type Orange_Count is range 0 .. 120_000;
>>
>> and let the compiler do both type safety and range checking.
>>
> Your point was not that you disliked the way you "switched on" type safety
> in C++.

Not not about dislike. The problem is that we all have to work with 3rd
party libraries - and non of the other do it. Only features which are used
by the mayoritiy of the developers of a give language are true features.
The rest is just academic talk.

> Nothing prevents you from mixing Apples and Oranges, you just have to tell
> C++ how you want this accomplished.  Plus, you can tell the compiler
> whether
> to allow an implicit conversion or not with the explicit keyword.

When "explicit" was invented the C++ designers missed to one off change for:

typedef explicit int Apple_Count;
typedef explicit int Orange_Count;

Then perhaps the STL would have used "typedef explicit" - and them most of
the C++ developers as well. And then we would have type safety. As it is is
I have seen things like the following more then once:

std:string X = ...;
int X_Len = X.length ();

(std::string::lenght () returns size_t and not int)

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com