Dynamically tagged expression required

Dynamically tagged expression required

[Maciej Sobczak]

Hi,

procedure Hello is

    type Shape is tagged null record;
    type Triangle is new Shape with
      record
         SideLen : Positive;
      end record;

    A : Shape;
    B : Shape'Class := A;             -- (1)
    C : Triangle := (SideLen => 7);

begin

    A := C;                           -- (2)
    B := C;                           -- (3)

end Hello;


(2) does not compile, and this is what was expected.
(3) does not compile, neither, beucase "dynamically tagged expression 
required".

Interestingly, (1) is fine.

Why is (1) allowed?
Why is (3) not allowed?

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Dynamically tagged expression required

[Georg Bauhaus]

On Thu, 2005-12-08 at 14:50 +0100, Maciej Sobczak wrote:
> Hi,
> 
> procedure Hello is
> 
>     type Shape is tagged null record;
>     type Triangle is new Shape with
>       record
>          SideLen : Positive;
>       end record;
> 
>     A : Shape;
>     B : Shape'Class := A;             -- (1)
>     C : Triangle := (SideLen => 7);
> 
> begin
> 
>     A := C;                           -- (2)
>     B := C;                           -- (3)
> 
> end Hello;

Try this,

procedure Hello is

    type With_Angles(sides: Positive) is
      record
         SideLen : Positive;
      end record;

    A : With_Angles(sides => 4);
    B : With_Angles := A;             -- (1)
    C : With_Angles := (sides => 3, SideLen => 7);

begin

    A := C;                           -- (2)
    B := C;                           -- (3)

end Hello;


-- Georg 

Re: Dynamically tagged expression required

[Dmitry A. Kazakov]

On Thu, 08 Dec 2005 14:50:37 +0100, Maciej Sobczak wrote:

> procedure Hello is
> 
>     type Shape is tagged null record;
>     type Triangle is new Shape with
>       record
>          SideLen : Positive;
>       end record;
> 
>     A : Shape;
>     B : Shape'Class := A;             -- (1)
>     C : Triangle := (SideLen => 7);
> 
> begin
> 
>     A := C;                           -- (2)
>     B := C;                           -- (3)
> 
> end Hello;
> 
> (2) does not compile, and this is what was expected.
> (3) does not compile, neither, beucase "dynamically tagged expression 
> required".
> 
> Interestingly, (1) is fine.
> 
> Why is (1) allowed?

It is not an assignment, but initialization.

> Why is (3) not allowed?

B := B; -- Legal
B := Shape'Class (A); -- Legal
B := Shape'Class (C); -- Legal, but raises Constraint_Error

You cannot change the tag of a class-wide object, so it would have little
sense anyway. However if ":=" were considered as a dispatching operation,
then (3) should be made legal.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Dynamically tagged expression required

[Martin Krischik]

Maciej Sobczak wrote:

> Hi,
> 
> procedure Hello is
> 
>     type Shape is tagged null record;
>     type Triangle is new Shape with
>       record
>          SideLen : Positive;
>       end record;
> 
>     A : Shape;
>     B : Shape'Class := A;             -- (1)
>     C : Triangle := (SideLen => 7);

try:

        D : Shape'Class := C;

as well - it will work as well.
> 
> begin
> 
>     A := C;                           -- (2)
>     B := C;                           -- (3)
> 
> end Hello;
> 
> 
> (2) does not compile, and this is what was expected.
> (3) does not compile, neither, beucase "dynamically tagged expression
> required".
> 
> Interestingly, (1) is fine.
> 
> Why is (1) allowed?

because it is an initialization.

> Why is (3) not allowed?

because it is an assignment.

Read:

http://en.wikibooks.org/wiki/Ada_Programming/Subtypes
http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation


Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Dynamically tagged expression required

[Maciej Sobczak]

Martin Krischik wrote:

>>    A : Shape;
>>    B : Shape'Class := A;             -- (1)
>>    C : Triangle := (SideLen => 7);

>>begin
>>
>>    A := C;                           -- (2)
>>    B := C;                           -- (3)
>>
>>end Hello;

>>Why is (1) allowed?
> 
> because it is an initialization.

OK, so that explains why it's possible to use Shape'Class as a parameter 
in subroutine. Every time the subroutine is called, the parameter is 
*initialized* with the value, and therefore it can be different for each 
call:

procedure Draw(S : Shape'Class);

T : Triangle;
R : Rectangle;

and later:

Draw(T);   -- S initialized with T
Draw(R);   -- S initialized with R

Right?

>>Why is (3) not allowed?
> 
> because it is an assignment.

And this is where I want to dig deeper.

> http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation

This page says:

"The Class type is a real data type. You can declare variables of the 
class-wide type, assign values to them [...]"

"Assign values to them" is a problem here.
As the subject of my original post says (and what compiler told me), 
"dynamically tagged expression required".

What can I provide as a dynamically tagged expression?

It looks like some ShapeClassPtr.all is OK there, except that I get the 
CONSTRAINT_ERROR, if the new value has a different tag. This observation 
agrees with what Dmitry said - the tag of the class-wide object cannot 
be changed.

What other dynamically tagged expression can be provided as a right-hand 
side of the (default) assignment to the object of class-wide type?
Is this useful in practice?

Regards,

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Dynamically tagged expression required

[Jean-Pierre Rosen]

Maciej Sobczak a �crit :
> "Assign values to them" is a problem here.
> As the subject of my original post says (and what compiler told me), 
> "dynamically tagged expression required".
> 
> What can I provide as a dynamically tagged expression?
> 
Actually, the compiler message is technically correct, but rather unhelpful.

For the casual user, it is enough to say that in an assignment, the LHS 
and the RHS must have the same type. In your case, the RHS is of type 
Shape'Class, therefore the LHS must be of type Shape'Class (possibly 
thanks to a conversion).

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Dynamically tagged expression required

[Robert A Duff]

Maciej Sobczak <no.spam@no.spam.com> writes:

> Martin Krischik wrote:
> 
> >>    A : Shape;
> >>    B : Shape'Class := A;             -- (1)
> >>    C : Triangle := (SideLen => 7);
> 
> >>begin
> >>
> >>    A := C;                           -- (2)
> >>    B := C;                           -- (3)
> >>
> >>end Hello;
> 
> >>Why is (1) allowed?
> > because it is an initialization.
> 
> OK, so that explains why it's possible to use Shape'Class as a parameter
> in subroutine. Every time the subroutine is called, the parameter is
> *initialized* with the value, and therefore it can be different for each
> call:
> 
> procedure Draw(S : Shape'Class);
> 
> T : Triangle;
> R : Rectangle;
> 
> and later:
> 
> Draw(T);   -- S initialized with T
> Draw(R);   -- S initialized with R
> 
> Right?

Right.

> >>Why is (3) not allowed?
> > because it is an assignment.
> 
> And this is where I want to dig deeper.
> 
> > http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation
> 
> This page says:
> 
> "The Class type is a real data type. You can declare variables of the
> class-wide type, assign values to them [...]"
> 
> "Assign values to them" is a problem here.
> As the subject of my original post says (and what compiler told me),
> "dynamically tagged expression required".
> 
> What can I provide as a dynamically tagged expression?

You can convert to class-wide type.  But if the Tag is different,
that just turns a compile-time error into a run-time error.

> It looks like some ShapeClassPtr.all is OK there, except that I get the
> CONSTRAINT_ERROR, if the new value has a different tag. This observation
> agrees with what Dmitry said - the tag of the class-wide object cannot
> be changed.
> 
> What other dynamically tagged expression can be provided as a right-hand
> side of the (default) assignment to the object of class-wide type?
> Is this useful in practice?

Not very useful.  It would work in a case where you have some object Obj
of type Shape'Class, and you do something like:

    if Obj'Tag = A'Tag then
        A := Obj;

But that sort of thing doesn't come up very often.

If you want to change the Tag of an object, you can't -- you have to use
access types, and allocate a new object with the new Tag you want.
In my experience, class-wide types nearly always require use
of access types and heap allocation.

The reason Tags can't change is similar to the reason discriminants
can't change.  (Well, they can if the discrim has a default value,
but that's not allowed for tagged types.  We tried to allow it,
but it caused so many semantic anomalies that we gave up.
Tags don't have defaults, either.)

If Tags could change, then the size of objects could change, which would
pretty much require a heap-based implementation.  Ada doesn't like
implicit heap allocation, and so places this burden on the programmer.
The defaulted-discrim case (for untagged types) is different,
because the compiler can calculate the max possible size.

- Bob

Re: Dynamically tagged expression required

[Martin Krischik]

Robert A Duff wrote:

> If you want to change the Tag of an object, you can't -- you have to use
> access types, and allocate a new object with the new Tag you want.
> In my experience, class-wide types nearly always require use
> of access types and heap allocation.

Well ever since I started to use the indefinite containers of the booch
components I never needed another new for tagged records.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Dynamically tagged expression required

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Well ever since I started to use the indefinite containers of the booch
> components I never needed another new for tagged records.

You can use any of the indefinite containers in the standard library, with the
same effect.  

Some simple memory management ideas are to use a map, with the tag as the key
and objects of that (specific) type as the element; or use a list, and use
Splice to move objects off of one list and onto another.

Re: Dynamically tagged expression required

[Martin Krischik]

Matthew Heaney wrote:

> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>> Well ever since I started to use the indefinite containers of the booch
>> components I never needed another new for tagged records.
> 
> You can use any of the indefinite containers in the standard library, with
> the same effect.

This is of corse true. It is just that my first container library was IBM
Open-Class-Library. The OCL is a far higher level container library when
compared to the STL. And as such I prefer the Booch-Components over the
Ada.Containers.

I know you had different priorities when designing Charles and later
Ada.Containers - but there not mine:

* STL-like won't count for me - I don't like the STL.
* One Step vs. Thee step instantiation is is not that  important when you
are used to deciding if an IKeySortedSetAsAvlTree or an
IKeySortedSetAsTable is more appropriate for the task at hand.

Of corse the OCL/STL comparison guide only suggest "map<>" for all
IKeySortedSet variants - and the IKeySet, IMap and ISortedMap variants as
well - all just "map<>".

Just to clarify: There is also a default IKeySortedSet - for those who don't
want to make to much thinking when coosing a container.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Dynamically tagged expression required

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> * One Step vs. Thee step instantiation is not that important when you are
> used to deciding if an IKeySortedSetAsAvlTree or an IKeySortedSetAsTable is
> more appropriate for the task at hand.

That's the same as Ordered_Map and Hashed_Map.  And only a single instantiation
is necessary in both the STL and Ada standard container library.


> Of corse the OCL/STL comparison guide only suggest "map<>" for all
> IKeySortedSet variants - and the IKeySet, IMap and ISortedMap variants as
> well - all just "map<>".

I haven't read that guide but that sounds right.


> Just to clarify: There is also a default IKeySortedSet - for those who don't
> want to make too much thinking when choosing a container.

I wonder how this works?  Does it assume something about the key type (maybe
all types have a hash function a la Java, or have a relationship operator), or
does it just use a list underneath?  What is the time complexity?

Re: Dynamically tagged expression required

[Martin Krischik]

Matthew Heaney wrote:

>> Just to clarify: There is also a default IKeySortedSet - for those who
>> don't want to make too much thinking when choosing a container.
 
> I wonder how this works?  Does it assume something about the key type
> (maybe all types have a hash function a la Java, or have a relationship
> operator), or
> does it just use a list underneath? 

You had to define an key-access-class or (implicitly) use one predefined
key-access-classes for common cases.



> What is the time complexity? 

Choosing the right container variant has a great impact on time complexity.
That is why casual users of the OCL often said that to OCL is slow. But in
truth they have just chosen the wrong container for the task.

The OCL containers where build like LEGO blocks - there where fundamental
building block which where recombined to give quite large set of container:

IKeySet         
IKeyBag         
IMap 
IRelation 
ISet    
IBag 
IKeySortedSet
IKeySortedBag           
IPriorityQueue  
ISortedMap      
ISortedRelation         
ISortedSet      
ISortedBag      
IEqualitySequence       
ISequence       
IStack 
IDeque  
IQueue 
IHeap

Bur the real interesting part where the variants. For each of the base type
there where variants. i.E. IBag has the following variants:

IBagAsAvlTree 
IBagAsBstTree
IBagAsDilTable
IBagAsHshTable
IBagAsList 
IBagAsTable 
IBagOnBSTKeySortedSet 
IBagOnHashKeySet 
IBagOnSortedDilutedSequence
IBagOnSortedLinkedSequence 
IBagOnSortedTabularSequence

If you want and complete overview read:

http://www.mainserver.state.mn.us/bookmgr-cgi/bookmgr.exe/handheld/Connected/BOOKS/IBMBK.Z6CCO.CBCIT100.BOOK/2.6.1?SHELF=IBMBK.Z6CCO.CBCBS150.BKSHELF&DT=20030509155052
http://hikwww2.fzk.de/hik/orga/verdi/rs/Dokumentation/Cpp/Cpp/classref/ref/IBag.htm

IBM really put some effort in here and it is all going to the scrap heap.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Dynamically tagged expression required

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> This is of corse true. It is just that my first container library was IBM
> Open-Class-Library. The OCL is a far higher level container library when
> compared to the STL. And as such I prefer the Booch-Components over the
> Ada.Containers.

Why do you say that the OCL is a "higher-level library" than the STL or the Ada
standard library?  In the STL you say:

  map_t m;
  //...
  m[k] = e;
  m.erase(k);

and in Ada you say:

  M : Map;
begin
  --...
  M.Include (K, E);
  M.Exclude (K);


How much more high-level can a library be?  Considering your description of the
OCL (given in another post), did you really mean that it's more low-level?

Re: Dynamically tagged expression required

[Martin Krischik]

Matthew Heaney wrote:

> Martin Krischik <krischik@users.sourceforge.net> writes:
> 
>> This is of corse true. It is just that my first container library was IBM
>> Open-Class-Library. The OCL is a far higher level container library when
>> compared to the STL. And as such I prefer the Booch-Components over the
>> Ada.Containers.
> 
> Why do you say that the OCL is a "higher-level library" than the STL or
> the Ada
> standard library?  In the STL you say:
> 
>   map_t m;
>   //...
>   m[k] = e;
>   m.erase(k);
> 
> and in Ada you say:
> 
>   M : Map;
> begin
>   --...
>   M.Include (K, E);
>   M.Exclude (K);

It's the interface. i.E. The STL cursors tries to mimic the C pointer
behavior. Pointer arithmetic is low-level in my eyes.

The OCL rather tries to mimic a simple database. And databases are more high
level then pointers in my eyes.

> How much more high-level can a library be?  Considering your description
> of the OCL (given in another post), did you really mean that it's more
> low-level?

That depends where you enter the class Hirachie. If you jump in at the
abstract (IA..) or generic (IG...) level then yes you get your hands dirty
by low level stuff. But at least you can.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Dynamically tagged expression required

[Georg Bauhaus]

Martin Krischik wrote:

>>  map_t m;
>>  //...
>>  m[k] = e;
>>  m.erase(k);
>>
>>and in Ada you say:
>>
>>  M : Map;
>>begin
>>  --...
>>  M.Include (K, E);
>>  M.Exclude (K);
> 
> 
> It's the interface. i.E. The STL cursors tries to mimic the C pointer
> behavior. Pointer arithmetic is low-level in my eyes.

OTOH, Ada containers, too, have a number of high level operations,
for example Intersection of sets, Floor... No visible cursors involved.
I believe you don't have this in STL's set<>, instead there are
generic algorithms.

> The OCL rather tries to mimic a simple database. And databases are more high
> level then pointers in my eyes.

I think the plan for Ada.Containers is to go on working
on generic algorithms. If a container doesn't provide
a high level operation that is likely used frequently,
it can be provided either using a generic algorithm, or,
maybe, by extending the container type.

Re: Dynamically tagged expression required

[Georg Bauhaus]

Georg Bauhaus wrote:

> OTOH, Ada containers, too, have a number of high level operations,
> for example Intersection of sets, Floor...
ok not Foor :-(

Re: Dynamically tagged expression required

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccirtygr41.fsf@shell01.TheWorld.com...
...
> If you want to change the Tag of an object, you can't -- you have to use
> access types, and allocate a new object with the new Tag you want.
> In my experience, class-wide types nearly always require use
> of access types and heap allocation.

That's half right. Class-wide types nealry always require the use of access
types somewhere. But you don't necessarily have to use heap allocation; the
objects can be allocated on the stack, and 'Unchecked_Access used to create
the access values.

With proper use of controlled types, this can be completely safe, and much
of the time, it is better than heap allocation for all of the normal
reasons.

For this to work, the access types have to have a fairly controlled usage
(so that it is practical for Finalize to update them); it works best in a
library. Claw works this way, for instance.

                       Randy.

Re: Dynamically tagged expression required

[Martin Krischik]

Maciej Sobczak wrote:

> Martin Krischik wrote:
> 
>>>    A : Shape;
>>>    B : Shape'Class := A;             -- (1)
>>>    C : Triangle := (SideLen => 7);
> 
>>>begin
>>>
>>>    A := C;                           -- (2)
>>>    B := C;                           -- (3)
>>>
>>>end Hello;
> 
>>>Why is (1) allowed?
>> 
>> because it is an initialization.
> 
> OK, so that explains why it's possible to use Shape'Class as a parameter
> in subroutine. Every time the subroutine is called, the parameter is
> *initialized* with the value, and therefore it can be different for each
> call:
> 
> procedure Draw(S : Shape'Class);

You know this procedure won't dispatch?

> T : Triangle;
> R : Rectangle;
> 
> and later:
> 
> Draw(T);   -- S initialized with T
> Draw(R);   -- S initialized with R
> 
> Right?

Yes. But it only look like the parameter is initialized. Internally the
compiler likely to use a pointer to pass the paramer to speed up things.
Remember "in" parameter are also constant.

And for the dispatching calls the compiler allways uses a pointer.

>>>Why is (3) not allowed?
>> 
>> because it is an assignment.
> 
> And this is where I want to dig deeper.
> 
>> http://en.wikibooks.org/wiki/Ada_Programming/Object_Orientation
> 
> This page says:
> 
> "The Class type is a real data type. You can declare variables of the
> class-wide type, assign values to them [...]"
> 
> "Assign values to them" is a problem here.
> As the subject of my original post says (and what compiler told me),
> "dynamically tagged expression required".

> What can I provide as a dynamically tagged expression?
> 
> It looks like some ShapeClassPtr.all is OK there, except that I get the
> CONSTRAINT_ERROR, if the new value has a different tag. This observation
> agrees with what Dmitry said - the tag of the class-wide object cannot
> be changed.

Once the variable is initialized it becomes constained - you can only
assigned object of the same constain to them.

Simpler example:

declare
  Text : String := "Hello"; - (A)
begin
 Text := "World"  - (B)
 Text := "World!" - (C)
end

With (A) String becomes constrained to (1 .. 5). The assignment (B) is ok as
well. However (C) will fail - with the exclamation mark the text is 6
characters and the assignment will fail.

> What other dynamically tagged expression can be provided as a right-hand
> side of the (default) assignment to the object of class-wide type?
> Is this useful in practice?

To tell the truth: Up until now I have only initialized 'Class variables but
never reassigned them with a new value. Even more I just rename them:

http://en.wikibooks.org/wiki/Ada_Programming/Subtypes#Rename_view

That saves copying the data.

'Class is also usefull as element type for container types which can store
indefinite elements.

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Dynamically tagged expression required

[Matthew Heaney]

Martin Krischik <krischik@users.sourceforge.net> writes:

> And for the dispatching calls the compiler always uses a pointer.

This is a bit misleading.  It's better to say that tagged types are always
passed by reference.


> T'Class is also useful as then element type for container types which can
> store indefinite elements.

Yes.  The standard container library does indeed include indefinite versions of
all the containers.

Re: Dynamically tagged expression required

[Maciej Sobczak]

Martin Krischik wrote:

>>OK, so that explains why it's possible to use Shape'Class as a parameter
>>in subroutine. Every time the subroutine is called, the parameter is
>>*initialized* with the value, and therefore it can be different for each
>>call:
>>
>>procedure Draw(S : Shape'Class);
> 
> You know this procedure won't dispatch?

Yes, I want to dispatch *inside* it. I treat it as a more or less 
equivalent to this in C++:

void draw(Shape const &s);

(by more or less equivalent I mean that I'm likely to use them in the 
same design situations, not that they produce the same machine code, 
even if they do)


>>T : Triangle;
>>R : Rectangle;
>>
>>and later:
>>
>>Draw(T);   -- S initialized with T
>>Draw(R);   -- S initialized with R
>>
>>Right?
> 
> Yes. But it only look like the parameter is initialized. Internally the
> compiler likely to use a pointer to pass the paramer to speed up things.

I don't care. :)
I don't want to call something a "pointer" when it isn't in my program.

 > Remember "in" parameter are also constant.

Yes.

> Once the variable is initialized it becomes constained - you can only
> assigned object of the same constain to them.
> 
> Simpler example:
> 
> declare
>   Text : String := "Hello"; - (A)
> begin
>  Text := "World"  - (B)
>  Text := "World!" - (C)
> end

It makes sense now.
Thank you for all the responses,


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Dynamically tagged expression required

[Martin Krischik]

Maciej Sobczak wrote:

>> Yes. But it only look like the parameter is initialized. Internally the
>> compiler likely to use a pointer to pass the paramer to speed up things.
 
> I don't care. :)
> I don't want to call something a "pointer" when it isn't in my program.

I don't care either. But we at c.l.a had to repeat the << "in" is not slower
then "access" >> mantra so often that we just say it automatily now ;-) .

Martin

-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Dynamically tagged expression required

[Maciej Sobczak]

Martin Krischik wrote:

>>>Yes. But it only look like the parameter is initialized. Internally the
>>>compiler likely to use a pointer to pass the paramer to speed up things.
> 
>>I don't care. :)
>>I don't want to call something a "pointer" when it isn't in my program.
> 
> I don't care either. But we at c.l.a had to repeat the << "in" is not slower
> then "access" >> mantra so often that we just say it automatily now ;-) .

OK, I see. I think it's "normal" in some way - we (on other forums) are 
busy breaking myths about C++ as well. ;)

As for your mantra - depending on how compiler does its job, "in" might 
be actually *faster* than "access" for the following reason: "access" 
might imply indirection, whereas "in" might be just another (although 
const) name for the actual parameter, especially when the compiler 
inlines the whole call. I don't see anything that would forbid this and 
therefore I wouldn't be surprised to see such "inverse" effects in 
performance measurements. Is this reasoning correct for Ada?

Of course, it is good to follow some coding "wisdom" in order not to 
make things worse or more difficult for the compiler, but AARM 
specifically says that tagged types are passed by reference (6.2). This 
means that passing objects by access variable *only* with hope to get 
better performance would be a premature optimization here (and the root 
of all evil).


-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/

Re: Dynamically tagged expression required

[Martin Krischik]

Maciej Sobczak wrote:

> Martin Krischik wrote:
> 
>>>>Yes. But it only look like the parameter is initialized. Internally the
>>>>compiler likely to use a pointer to pass the paramer to speed up things.
>> 
>>>I don't care. :)
>>>I don't want to call something a "pointer" when it isn't in my program.
>> 
>> I don't care either. But we at c.l.a had to repeat the << "in" is not
>> slower then "access" >> mantra so often that we just say it automatily
>> now ;-) .
> 
> OK, I see. I think it's "normal" in some way - we (on other forums) are
> busy breaking myths about C++ as well. ;)
> 
> As for your mantra - depending on how compiler does its job, "in" might
> be actually *faster* than "access" for the following reason: "access"
> might imply indirection, whereas "in" might be just another (although
> const) name for the actual parameter, especially when the compiler
> inlines the whole call. I don't see anything that would forbid this and
> therefore I wouldn't be surprised to see such "inverse" effects in
> performance measurements. Is this reasoning correct for Ada?

"pass by register" is an option for Ada as well. Maybe not for Intel CPU due
to the limited amount of registers available.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com