TTCN3-User,
I'm going through TCI spec (Part-6) version 3.2.1 and I'm interested in the
C binding in Section 9.
But I don't see the C definition for TciValue and TciType?
Can someone tell me where to look them up or why they are not defined?

Thanks,

RTP

Hi,

My understanding is that these types have not standardized on purposes
.. But they have to be provided by TTCN-3 RTSes, i.e., data structures
are tool proprietary.
I guess the idea of the standard has been in these two cases to
standardize _operations_ to access data structures instead of the data
structures themselves. That enables you still to reuse TCI
implementations with different tools.

Salut,
Stephan


> TTCN3-User,
> I'm going through TCI spec (Part-6) version 3.2.1 and I'm
> interested in the C binding in Section 9.
> But I don't see the C definition for TciValue and TciType?
> Can someone tell me where to look them up or why they are not defined?
>
> Thanks,
>
> RTP

Hi

I had the same problem. These types are not used in TTCN environment
(TM, CD, TL, ...) by value. You have to pass them to TE with a set of
functions to obtain their data. Because of that they are ment to be
vendor specific.

I think it is not a good approach. For example if you plan to create
universal TM library (independent from other vendors) you have to
declare that values somehow. The problem is that these types are ment to
be abstract base classes of a large class hierarchy. As C language does
not support classes they can be defined only as 'void *' (it is the way
I declared them).

I filed 2 CRs on that:
- CR0000828 (ipt-bugs.dyndns.org/mantis/view.php?id=828) - for
'void *' definition
- CR0000829 (ipt-bugs.dyndns.org/mantis/view.php?id=829) - for
adding C++ language mappings

Best Regards

Mateusz Pusz


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
>Sent: Tuesday, April 24, 2007 9:35 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TciValue & TciType
>
>Hi,
>
>My understanding is that these types have not standardized on purposes
>.. But they have to be provided by TTCN-3 RTSes, i.e., data structures
>are tool proprietary.
>I guess the idea of the standard has been in these two cases to
>standardize _operations_ to access data structures instead of the data
>structures themselves. That enables you still to reuse TCI
>implementations with different tools.
>
>Salut,
>Stephan
>
>
>> TTCN3-User,
>> I'm going through TCI spec (Part-6) version 3.2.1 and I'm
>> interested in the C binding in Section 9.
>> But I don't see the C definition for TciValue and TciType?
>> Can someone tell me where to look them up or why they are
>not defined?
>>
>> Thanks,
>>
>> RTP
>

Hi Mateusz,

I can see your point. If you have a library implementing a TCI interface
you essentially have to recompile it before using it.
Also you are forced to do that any time a tool vendor changes their
internal data structure .... Hmmm

Comments from tool vendor side? TCI writers?

stephan

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Pusz, Mateusz
> Sent: 24 April 2007 09:55
> To: TTCN3
> Subject: Re: TciValue & TciType
>
> Hi
> =20
> I had the same problem. These types are not used in TTCN
> environment (TM, CD, TL, ...) by value. You have to pass them
> to TE with a set of functions to obtain their data. Because
> of that they are ment to be vendor specific.
> =20
> I think it is not a good approach. For example if you plan to
> create universal TM library (independent from other vendors)
> you have to declare that values somehow. The problem is that
> these types are ment to be abstract base classes of a large
> class hierarchy. As C language does not support classes they
> can be defined only as 'void *' (it is the way I declared them).
> =20
> I filed 2 CRs on that:
> - CR0000828
> (ipt-bugs.dyndns.org/mantis/view.php?id=3D828) - for
> 'void *' definition
> - CR0000829
> (ipt-bugs.dyndns.org/mantis/view.php?id=3D829) - for
> adding C++ language mappings
>
> Best Regards
>
> Mateusz Pusz
> =20
>
> >

---

Original Message

---

> >From: active_ttcn3 : mts stf133 ttcn version 3 - active=20
> members only
> >[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
> >Sent: Tuesday, April 24, 2007 9:35 AM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: TciValue & TciType
> >
> >Hi,
> >
> >My understanding is that these types have not standardized
> on purposes
> >.. But they have to be provided by TTCN-3 RTSes, i.e., data
> structures
> >are tool proprietary.
> >I guess the idea of the standard has been in these two cases to
> >standardize _operations_ to access data structures instead
> of the data
> >structures themselves. That enables you still to reuse TCI
> >implementations with different tools.
> >
> >Salut,
> >Stephan
> >
> >=20
> >> TTCN3-User,
> >> I'm going through TCI spec (Part-6) version 3.2.1 and I'm=20
> >> interested in the C binding in Section 9.
> >> But I don't see the C definition for TciValue and TciType?
> >> Can someone tell me where to look them up or why they are=20
> >not defined?
> >>=20
> >> Thanks,
> >>=20
> >> RTP
> >
>

Hi again

I have just realized that "void *" is not a solution for that problem.
User must have more information how to deal with those types.

Lets assume that someone plan to write CH library that is capable of
connecting geographically distributed TEs. Connections will be handled
by TCP/UDP connections or RPC stack. There are several functions in CH
interface that need to pass TciValue and TciType types to the neighbour.
It is not possible with "void *" approach. So it comes again to vendor
specific solutions.

I think that having vendor specific solutions in an interface of
standardized library is not a good thing. It does not encourage to
create independent libraries and influences on the TTCN-3 standard
popularity.

I am rather new to TTCN-3 so I can be wrong. If yes, correct me please.

Best Regards

Mateusz Pusz


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
>Sent: Tuesday, April 24, 2007 11:57 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TciValue & TciType
>
>Hi Mateusz,
>
>I can see your point. If you have a library implementing a TCI
>interface
>you essentially have to recompile it before using it.
>Also you are forced to do that any time a tool vendor changes their
>internal data structure .... Hmmm
>
>Comments from tool vendor side? TCI writers?
>
>stephan
>
>>

---

Original Message

---

>> From: active_ttcn3 : mts stf133 ttcn version 3 - active
>> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Pusz, Mateusz
>> Sent: 24 April 2007 09:55
>> To: TTCN3
>> Subject: Re: TciValue & TciType
>>
>> Hi
>> =20
>> I had the same problem. These types are not used in TTCN
>> environment (TM, CD, TL, ...) by value. You have to pass them
>> to TE with a set of functions to obtain their data. Because
>> of that they are ment to be vendor specific.
>> =20
>> I think it is not a good approach. For example if you plan to
>> create universal TM library (independent from other vendors)
>> you have to declare that values somehow. The problem is that
>> these types are ment to be abstract base classes of a large
>> class hierarchy. As C language does not support classes they
>> can be defined only as 'void *' (it is the way I declared them).
>> =20
>> I filed 2 CRs on that:
>> - CR0000828
>> (ipt-bugs.dyndns.org/mantis/view.php?id=3D828) - for
>> 'void *' definition
>> - CR0000829
>> (ipt-bugs.dyndns.org/mantis/view.php?id=3D829) - for
>> adding C++ language mappings
>>
>> Best Regards
>>
>> Mateusz Pusz
>> =20
>>
>> >

---

Original Message

---

>> >From: active_ttcn3 : mts stf133 ttcn version 3 - active=20
>> members only
>> >[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
>> >Sent: Tuesday, April 24, 2007 9:35 AM
>> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>> >Subject: Re: TciValue & TciType
>> >
>> >Hi,
>> >
>> >My understanding is that these types have not standardized
>> on purposes
>> >.. But they have to be provided by TTCN-3 RTSes, i.e., data
>> structures
>> >are tool proprietary.
>> >I guess the idea of the standard has been in these two cases to
>> >standardize _operations_ to access data structures instead
>> of the data
>> >structures themselves. That enables you still to reuse TCI
>> >implementations with different tools.
>> >
>> >Salut,
>> >Stephan
>> >
>> >=20
>> >> TTCN3-User,
>> >> I'm going through TCI spec (Part-6) version 3.2.1 and I'm=20
>> >> interested in the C binding in Section 9.
>> >> But I don't see the C definition for TciValue and TciType?
>> >> Can someone tell me where to look them up or why they are=20
>> >not defined?
>> >>=20
>> >> Thanks,
>> >>=20
>> >> RTP
>> >
>>
>

Dear TTCN-3 Users,

Recompiling a user-implemented adapter source code once vendor changes does not sound like a big deal for me. It takes much more time to develop the code than to compile it. And you would need to re-link the thing anyway, against new libraries, and you probably don't change vendor every day. I personally see no problem in delegating a decision on relevant typedef to the vendor. Void pointer sounds like one viable solution to me. Or am I missing something?

Best regards,
Alexey

Stephan Schulz <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote: Hi Mateusz,

I can see your point. If you have a library implementing a TCI interface
you essentially have to recompile it before using it.
Also you are forced to do that any time a tool vendor changes their
internal data structure .... Hmmm

Comments from tool vendor side? TCI writers?

stephan

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Pusz, Mateusz
> Sent: 24 April 2007 09:55
> To: TTCN3
> Subject: Re: TciValue & TciType
>
> Hi
> =20
> I had the same problem. These types are not used in TTCN
> environment (TM, CD, TL, ...) by value. You have to pass them
> to TE with a set of functions to obtain their data. Because
> of that they are ment to be vendor specific.
> =20
> I think it is not a good approach. For example if you plan to
> create universal TM library (independent from other vendors)
> you have to declare that values somehow. The problem is that
> these types are ment to be abstract base classes of a large
> class hierarchy. As C language does not support classes they
> can be defined only as 'void *' (it is the way I declared them).
> =20
> I filed 2 CRs on that:
> - CR0000828
> (ipt-bugs.dyndns.org/mantis/view.php?id=3D828) - for
> 'void *' definition
> - CR0000829
> (ipt-bugs.dyndns.org/mantis/view.php?id=3D829) - for
> adding C++ language mappings
>
> Best Regards
>
> Mateusz Pusz
> =20
>
> >

---

Original Message

---

> >From: active_ttcn3 : mts stf133 ttcn version 3 - active=20
> members only
> >[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
> >Sent: Tuesday, April 24, 2007 9:35 AM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: TciValue & TciType
> >
> >Hi,
> >
> >My understanding is that these types have not standardized
> on purposes
> >.. But they have to be provided by TTCN-3 RTSes, i.e., data
> structures
> >are tool proprietary.
> >I guess the idea of the standard has been in these two cases to
> >standardize _operations_ to access data structures instead
> of the data
> >structures themselves. That enables you still to reuse TCI
> >implementations with different tools.
> >
> >Salut,
> >Stephan
> >
> >=20
> >> TTCN3-User,
> >> I'm going through TCI spec (Part-6) version 3.2.1 and I'm=20
> >> interested in the C binding in Section 9.
> >> But I don't see the C definition for TciValue and TciType?
> >> Can someone tell me where to look them up or why they are=20
> >not defined?
> >>=20
> >> Thanks,
> >>=20
> >> RTP
> >
>

Hi,

From what I understand, one of the objectives of standardizing TRI and TCI
is that TE can connect to any IUT using standard SA and can be managed by
any standard TM. If these two types are not standardized, we can not have a
true "plug-&-play" type of system. By that I meant if all the
interfaces/Types are defined, we can do the following totally independently:

1) Compile TTCN using Vendor X's compiler;

2) Running it using TM from Vendor Y.

3) Use a test tool from vendor Z to connect to IUT.



Right now Item-1 and Item-2 are coupled together by these couple of types.



Thanks,

RTP


On 4/24/07, Pusz, Mateusz <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
>
> Hi
>
> I had the same problem. These types are not used in TTCN environment
> (TM, CD, TL, ...) by value. You have to pass them to TE with a set of
> functions to obtain their data. Because of that they are ment to be
> vendor specific.
>
> I think it is not a good approach. For example if you plan to create
> universal TM library (independent from other vendors) you have to
> declare that values somehow. The problem is that these types are ment to
> be abstract base classes of a large class hierarchy. As C language does
> not support classes they can be defined only as 'void *' (it is the way
> I declared them).
>
> I filed 2 CRs on that:
> - CR0000828 (ipt-bugs.dyndns.org/mantis/view.php?id=828) - for
> 'void *' definition
> - CR0000829 (ipt-bugs.dyndns.org/mantis/view.php?id=829) - for
> adding C++ language mappings
>
> Best Regards
>
> Mateusz Pusz
>
>
> >

---

Original Message

---

> >From: active_ttcn3 : mts stf133 ttcn version 3 - active
> >members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
> >Sent: Tuesday, April 24, 2007 9:35 AM
> >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> >Subject: Re: TciValue & TciType
> >
> >Hi,
> >
> >My understanding is that these types have not standardized on purposes
> >.. But they have to be provided by TTCN-3 RTSes, i.e., data structures
> >are tool proprietary.
> >I guess the idea of the standard has been in these two cases to
> >standardize _operations_ to access data structures instead of the data
> >structures themselves. That enables you still to reuse TCI
> >implementations with different tools.
> >
> >Salut,
> >Stephan
> >
> >
> >> TTCN3-User,
> >> I'm going through TCI spec (Part-6) version 3.2.1 and I'm
> >> interested in the C binding in Section 9.
> >> But I don't see the C definition for TciValue and TciType?
> >> Can someone tell me where to look them up or why they are
> >not defined?
> >>
> >> Thanks,
> >>
> >> RTP
> >
>

Hi,

Plus I want to add that I'm trying T3DevKit. That's the problem that I ran
into.

T3DevKit only supports two vendors at the moment but there are many more
ttcn3 compilers out there. But if we've the two types standardized, T3DevKit
can support all compiler vendors without keep adding more vendor specific
code and the same will go to whoever develops TM.

It is this openness will add on to ttcn3's adaptability.



Thanks,

RTP


On 4/24/07, RTP Techie <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
>
>
> Hi,
>
> From what I understand, one of the objectives of standardizing TRI and TCI
> is that TE can connect to any IUT using standard SA and can be managed by
> any standard TM. If these two types are not standardized, we can not
> have a true "plug-&-play" type of system. By that I meant if all the
> interfaces/Types are defined, we can do the following totally independently:
>
>
> 1) Compile TTCN using Vendor X's compiler;
>
> 2) Running it using TM from Vendor Y.
>
> 3) Use a test tool from vendor Z to connect to IUT.
>
>
>
> Right now Item-1 and Item-2 are coupled together by these couple of types.
>
>
>
> Thanks,
>
> RTP
>
>
> On 4/24/07, Pusz, Mateusz <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:
> >
> > Hi
> >
> > I had the same problem. These types are not used in TTCN environment
> > (TM, CD, TL, ...) by value. You have to pass them to TE with a set of
> > functions to obtain their data. Because of that they are ment to be
> > vendor specific.
> >
> > I think it is not a good approach. For example if you plan to create
> > universal TM library (independent from other vendors) you have to
> > declare that values somehow. The problem is that these types are ment to
> > be abstract base classes of a large class hierarchy. As C language does
> > not support classes they can be defined only as 'void *' (it is the way
> > I declared them).
> >
> > I filed 2 CRs on that:
> > - CR0000828 (ipt-bugs.dyndns.org/mantis/view.php?id=828) - for
> > 'void *' definition
> > - CR0000829 (ipt-bugs.dyndns.org/mantis/view.php?id=829) - for
> > adding C++ language mappings
> >
> > Best Regards
> >
> > Mateusz Pusz
> >
> >
> > >

---

Original Message

---

> > >From: active_ttcn3 : mts stf133 ttcn version 3 - active
> > >members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
> > >Sent: Tuesday, April 24, 2007 9:35 AM
> > >To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > >Subject: Re: TciValue & TciType
> > >
> > >Hi,
> > >
> > >My understanding is that these types have not standardized on purposes
> > >.. But they have to be provided by TTCN-3 RTSes, i.e., data structures
> > >are tool proprietary.
> > >I guess the idea of the standard has been in these two cases to
> > >standardize _operations_ to access data structures instead of the data
> > >structures themselves. That enables you still to reuse TCI
> > >implementations with different tools.
> > >
> > >Salut,
> > >Stephan
> > >
> > >
> > >> TTCN3-User,
> > >> I'm going through TCI spec (Part-6) version 3.2.1 and I'm
> > >> interested in the C binding in Section 9.
> > >> But I don't see the C definition for TciValue and TciType?
> > >> Can someone tell me where to look them up or why they are
> > >not defined?
> > >>
> > >> Thanks,
> > >>
> > >> RTP
> > >
> >
>
>

Hi,

few comments with regards to tool independency. Although TTCN-3
standards define the TRI and TCI there are some vendor specific
interpretations with regards to the TRI and the TCI functionality. These
are details but in practise the details cause some additional work. So,
true plug-and-play is not possible in practise today.

In addition, the fact that tool vendors use different target languages
(C, C++, Java etc.) causes integration problems if one wants to have one
executable. This can be solved by using multiple binaries that
communicate via sockets. However, sockets cause performance penalty
which is sometimes an undesired feature of this workaround.

My point is that even there are standard interfaces, interoperability is
an issue because of different interpretations of the standards.

BR,
Risto


________________________________

From: active_ttcn3 : mts stf133 ttcn version 3 - active members
only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext RTP Techie
Sent: 24 April, 2007 16:00
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TciValue & TciType




Hi,

From what I understand, one of the objectives of standardizing
TRI and TCI is that TE can connect to any IUT using standard SA and can
be managed by any standard TM. If these two types are not
standardized, we can not have a true "plug-&-play" type of system. By
that I meant if all the interfaces/Types are defined, we can do the
following totally independently:

1) Compile TTCN using Vendor X's compiler;

2) Running it using TM from Vendor Y.

3) Use a test tool from vendor Z to connect to IUT.



Right now Item-1 and Item-2 are coupled together by these couple
of types.



Thanks,

RTP



On 4/24/07, Pusz, Mateusz <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:

Hi

I had the same problem. These types are not used in TTCN
environment
(TM, CD, TL, ...) by value. You have to pass them to TE
with a set of
functions to obtain their data. Because of that they are
ment to be
vendor specific.

I think it is not a good approach. For example if you
plan to create
universal TM library (independent from other vendors)
you have to
declare that values somehow. The problem is that these
types are ment to
be abstract base classes of a large class hierarchy. As
C language does
not support classes they can be defined only as 'void *'
(it is the way
I declared them).

I filed 2 CRs on that:
- CR0000828
(ipt-bugs.dyndns.org/mantis/view.php?id=828) - for
'void *' definition
- CR0000829
(ipt-bugs.dyndns.org/mantis/view.php?id=829) - for
adding C++ language mappings

Best Regards

Mateusz Pusz


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of
Stephan Schulz
>Sent: Tuesday, April 24, 2007 9:35 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TciValue & TciType
>
>Hi,
>
>My understanding is that these types have not
standardized on purposes
>.. But they have to be provided by TTCN-3 RTSes, i.e.,
data structures
>are tool proprietary.
>I guess the idea of the standard has been in these two
cases to
>standardize _operations_ to access data structures
instead of the data
>structures themselves. That enables you still to reuse
TCI
>implementations with different tools.
>
>Salut,
>Stephan
>
>
>> TTCN3-User,
>> I'm going through TCI spec (Part-6) version 3.2.1 and
I'm
>> interested in the C binding in Section 9.
>> But I don't see the C definition for TciValue and
TciType?
>> Can someone tell me where to look them up or why they
are
>not defined?
>>
>> Thanks,
>>
>> RTP
>

Hi,



If a standard allows for more than one interpretation, one can thus conclude
that the standard is:

a) ambiguous (on purpose, or by accident)

b) incomplete in its specification.





Any standard should strive to avoid the possibility of ambiguous
interpretation. :-). ( Not always easy).



Cheers,



Claude.



_____

From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of This email address is being protected from spambots. You need JavaScript enabled to view it.
Sent: 24 April 2007 16:01
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TciValue & TciType



Hi,



few comments with regards to tool independency. Although TTCN-3 standards
define the TRI and TCI there are some vendor specific interpretations with
regards to the TRI and the TCI functionality. These are details but in
practise the details cause some additional work. So, true plug-and-play is
not possible in practise today.



In addition, the fact that tool vendors use different target languages (C,
C++, Java etc.) causes integration problems if one wants to have one
executable. This can be solved by using multiple binaries that communicate
via sockets. However, sockets cause performance penalty which is sometimes
an undesired feature of this workaround.



My point is that even there are standard interfaces, interoperability is an
issue because of different interpretations of the standards.



BR,

Risto




_____


From: active_ttcn3 : mts stf133 ttcn version 3 - active members only
[This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of ext RTP Techie
Sent: 24 April, 2007 16:00
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: Re: TciValue & TciType



Hi,

From what I understand, one of the objectives of standardizing TRI and TCI
is that TE can connect to any IUT using standard SA and can be managed by
any standard TM. If these two types are not standardized, we can not have
a true "plug-&-play" type of system. By that I meant if all the
interfaces/Types are defined, we can do the following totally independently:


1) Compile TTCN using Vendor X's compiler;

2) Running it using TM from Vendor Y.

3) Use a test tool from vendor Z to connect to IUT.



Right now Item-1 and Item-2 are coupled together by these couple of types.



Thanks,

RTP




On 4/24/07, Pusz, Mateusz <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:

Hi

I had the same problem. These types are not used in TTCN environment
(TM, CD, TL, ...) by value. You have to pass them to TE with a set of
functions to obtain their data. Because of that they are ment to be
vendor specific.

I think it is not a good approach. For example if you plan to create
universal TM library (independent from other vendors) you have to
declare that values somehow. The problem is that these types are ment to
be abstract base classes of a large class hierarchy. As C language does
not support classes they can be defined only as 'void *' (it is the way
I declared them).

I filed 2 CRs on that:
- CR0000828 (ipt-bugs.dyndns.org/mantis/view.php?id=828) - for
'void *' definition
- CR0000829 (ipt-bugs.dyndns.org/mantis/view.php?id=829) - for
adding C++ language mappings

Best Regards

Mateusz Pusz


>

---

Original Message

---

>From: active_ttcn3 : mts stf133 ttcn version 3 - active
>members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Stephan Schulz
>Sent: Tuesday, April 24, 2007 9:35 AM
>To: This email address is being protected from spambots. You need JavaScript enabled to view it.
>Subject: Re: TciValue & TciType
>
>Hi,
>
>My understanding is that these types have not standardized on purposes
>.. But they have to be provided by TTCN-3 RTSes, i.e., data structures
>are tool proprietary.
>I guess the idea of the standard has been in these two cases to
>standardize _operations_ to access data structures instead of the data
>structures themselves. That enables you still to reuse TCI
>implementations with different tools.
>
>Salut,
>Stephan
>
>
>> TTCN3-User,
>> I'm going through TCI spec (Part-6) version 3.2.1 and I'm
>> interested in the C binding in Section 9.
>> But I don't see the C definition for TciValue and TciType?
>> Can someone tell me where to look them up or why they are
>not defined?
>>
>> Thanks,
>>
>> RTP
>