style Q: type .. is new String;

style Q: type .. is new String;

[tmoran]

Though I create new types regularly for numeric variables, I've only
rarely used other than the standard String type.  That saves doing type
conversions, but it would be nice to have strong type checking help me
detect errors.  Do other folks use new String types a lot and find it
works out well?

Re: style Q: type .. is new String;

[Stephen Leake]

tmoran@acm.org writes:

> Though I create new types regularly for numeric variables, I've only
> rarely used other than the standard String type.  That saves doing type
> conversions, but it would be nice to have strong type checking help me
> detect errors.  Do other folks use new String types a lot and find it
> works out well?

I think I've never created a new String type.

I think that's because I only use String for user interfaces, and in
that context there's not much point in strong typing.

On the other hand, I use numbers and record types to create models in
the rest of the code, so distinct types are useful.

-- 
-- Stephe

Re: style Q: type .. is new String;

[Robert A Duff]

tmoran@acm.org writes:

> Though I create new types regularly for numeric variables, 

Me, too.

>...I've only
> rarely used other than the standard String type.  That saves doing type
> conversions, but it would be nice to have strong type checking help me
> detect errors.  Do other folks use new String types a lot and find it
> works out well?

Only rarely.  For example, I have a message template type, which is a
string, but wants some stuff "filled in" at run time.  Otherwise, a
String is a String.  Integers, on the other hand, "measure" different
things -- it's useful to have the index of this-array be a different
type from the index of that-array.

- Bob

Re: style Q: type .. is new String;

[Robert I. Eachus]

tmoran@acm.org wrote:

> Though I create new types regularly for numeric variables, I've only
> rarely used other than the standard String type.  That saves doing type
> conversions, but it would be nice to have strong type checking help me
> detect errors.  Do other folks use new String types a lot and find it
> works out well?

No.  But my reason is different.  I use Bounded_String a lot in database 
type applications, where it is very appropriate.  (The database has a 
limit on the size of say, a Name, or a Street_Address, etc.)

In that context, it makes a lot of sense to have a different 
Bounded_String type for each field in the database, whether or not the 
fields actually have the same length.

Incidently, though, I don't usually make the Bounded_String instances 
private.  That way, when it does come time to actually display the 
results of a query, there is no need to have wrappers for the various 
Bounded_String to String conversion functions.


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

RE: style Q: type .. is new String;

[amado.alves]

>>Though I create new types regularly for numeric variables, I've only
>>rarely used other than the standard String type.  That saves doing type
>>conversions, but it would be nice to have strong type checking help me
>>detect errors.  Do other folks use new String types a lot and find it
>>works out well?

>No.  But my reason is different.  I use Bounded_String a lot...

Me too.  And I also use Unbounded_String a lot because it has the wonderful feature of memory magic (no memory associated with a US object is lost upon assignment or scope exit).  (Shameless publicity: I'll expound this memory magic approach to container design in Ada-Europe 2004 in the half day tutorial "No Pointers, Great Programs". See you there ;-)

Re: style Q: type .. is new String;

[Duncan Sands]

> Me too.  And I also use Unbounded_String a lot because it has the wonderful
> feature of memory magic (no memory associated with a US object is lost upon
> assignment or scope exit).  (Shameless publicity: I'll expound this memory
> magic approach to container design in Ada-Europe 2004 in the half day
> tutorial "No Pointers, Great Programs". See you there ;-)

What about performance?  I've always been worried about the time lost
allocating/deallocating memory all over the place.

Thanks,

Duncan.

RE: style Q: type .. is new String;

[amado.alves]

>>Me too.  And I also use Unbounded_String a lot because it has the wonderful
>>feature of memory magic (no memory associated with a US object is lost upon
>>assignment or scope exit).  (Shameless publicity: I'll expound this memory
>>magic approach to container design in Ada-Europe 2004 in the half day
>>tutorial "No Pointers, Great Programs". See you there ;-)

>What about performance?  I've always been worried about the time lost
>allocating/deallocating memory all over the place.

You still have that penalty when you do the memory management explicitly. A decently implemented unbounded container, if properly used, will not penalize you significantly more, if at all. Take a look at Charles.Vectors.Unbounded for example.

Now, if your talking hard real time, of course you need containers with absolutely predictable behaviour w.r.t. to the time their operations take. To achieve that you often write your own containers. This often has the unfortunate effect that the container and the application logics get intertwined. So a container library with real time features would be nice. Fortunately Charles-for-ARG (AI-302/2) has some time complexity features that I believe satisfy at least *soft* real time demands.

Every now and then I do experimental measures of direct vs. indirect memory managent (e.g. String vs. Unbounded_String) in real applications, and mostly I find that the time taken by memory allocation/deallocation is not significant. That is not surprising if you think that because memory allocation/deallocation is such a basic thing in the execution of programs the system mechanisms to achieve must be very optimized (and they indeed are if you look at them directly although I haven't done that in a long time).