Dear TTCN-3 friends, fans and haters,

the first draft version of part 10 of the TTCN-3 standard “Using C/C++
with TTCN-3“ is available. It has been produced with the help of
Emmanuelle Chaulot-Talmon (ETSI), Matti Karki (VTT, Finland) and Andreas
Nyberg (Nokia, Finland).

Basically, this first draft has the same contents as the initial
document presented at the last ETSI MTS meeting in Berlin, because we
didn’t receive comments on this initial document so far. However, the
document is now in the ETSI ES (European Standard) form and at the next
ETSI MTS meeting we would like to increase its status to Draft ES (DES).

In case that you want to have a look into this new part 10 and want to
comment on this document, please send me an Email
(This email address is being protected from spambots. You need JavaScript enabled to view it.). I will send you a word copy of
the document.

Comments which should be considered at the next MTS meeting are needed
until Friday, 30. September 2005.

Best regards
Jens Grabowski

--
======================================================================
Prof. Dr. Jens Grabowski
Institute for Informatics phone: +49 551 39 14690
University of Goettingen fax: +49 551 39 14415
Lotzestrasse 16-18
DE-37083 Göttingen This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) www.swe.informatik.uni-goettingen.de
======================================================================

Please

Send me a copy of the document.

Regards

/Tomas Lindqvist
* Office: +46 63 195183
* Mobile: +46 70 544 95 85
* :<<This email address is being protected from spambots. You need JavaScript enabled to view it.>>
H Box 3093, Akademigatan 3, 831 03 Östersund
" <<www.telecanetworks.se>>

---

Original Message

---

From: Jens Grabowski [This email address is being protected from spambots. You need JavaScript enabled to view it.]
Sent: den 21 september 2005 13:45
To: This email address is being protected from spambots. You need JavaScript enabled to view it.
Subject: TTCN-3 part 10: Using C/C++ with TTCN-3


Dear TTCN-3 friends, fans and haters,

the first draft version of part 10 of the TTCN-3 standard "Using C/C++
with TTCN-3" is available. It has been produced with the help of
Emmanuelle Chaulot-Talmon (ETSI), Matti Karki (VTT, Finland) and Andreas
Nyberg (Nokia, Finland).

Basically, this first draft has the same contents as the initial
document presented at the last ETSI MTS meeting in Berlin, because we
didn't receive comments on this initial document so far. However, the
document is now in the ETSI ES (European Standard) form and at the next
ETSI MTS meeting we would like to increase its status to Draft ES (DES).

In case that you want to have a look into this new part 10 and want to
comment on this document, please send me an Email
(This email address is being protected from spambots. You need JavaScript enabled to view it.). I will send you a word copy of
the document.

Comments which should be considered at the next MTS meeting are needed
until Friday, 30. September 2005.

Best regards
Jens Grabowski

--
======================================================================
Prof. Dr. Jens Grabowski
Institute for Informatics phone: +49 551 39 14690
University of Goettingen fax: +49 551 39 14415
Lotzestrasse 16-18
DE-37083 Göttingen This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) www.swe.informatik.uni-goettingen.de
======================================================================

Oh, please send me a copy .
Regards!
Pan

---

Original Message

---

From: "Jens Grabowski" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Sent: Wednesday, September 21, 2005 7:44 PM
Subject: TTCN-3 part 10: Using C/C++ with TTCN-3


Dear TTCN-3 friends, fans and haters,

the first draft version of part 10 of the TTCN-3 standard “Using C/C++
with TTCN-3“ is available. It has been produced with the help of
Emmanuelle Chaulot-Talmon (ETSI), Matti Karki (VTT, Finland) and Andreas
Nyberg (Nokia, Finland).

Basically, this first draft has the same contents as the initial
document presented at the last ETSI MTS meeting in Berlin, because we
didn’t receive comments on this initial document so far. However, the
document is now in the ETSI ES (European Standard) form and at the next
ETSI MTS meeting we would like to increase its status to Draft ES (DES).

In case that you want to have a look into this new part 10 and want to
comment on this document, please send me an Email
(This email address is being protected from spambots. You need JavaScript enabled to view it.). I will send you a word copy of
the document.

Comments which should be considered at the next MTS meeting are needed
until Friday, 30. September 2005.

Best regards
Jens Grabowski

--
======================================================================
Prof. Dr. Jens Grabowski
Institute for Informatics phone: +49 551 39 14690
University of Goettingen fax: +49 551 39 14415
Lotzestrasse 16-18
DE-37083 Göttingen This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) www.swe.informatik.uni-goettingen.de
======================================================================

Dear list members,

I have looked over the latest version of this document, which was prepared for
the last MTS meeting. In addition to formal mistakes (empty or meaningless
sections copied from the ETSI skeleton) I have found several technical problems.
I think many of the problems are so significant that this document should be
accepted as an ETSI standard only after a major technical revision.

Since nobody has sent any technical comments about this document to this mailing
list I would like to share my opinions with you.

With best regards,
Zoltan


General comments
================

- The C/C++ input is not defined properly (see the comment for Section 1 below).

- The realization of the mapping is not possible in some cases. The Introduction
states that this document uses explicit mapping. This means one can develop a
C/C++ -> TTCN-3 converter tool that creates the TTCN-3 equivalents of the header
files and the generated modules can be imported into the user's TTCN-3 modules.
However, the ducument specifies non-static mapping for some C++ entities (e.g.
functions with variable arguments or template classes). In these cases the TTCN-
3 equivalents depend on not only the C/C++ declaration, but on its usage as well
(or the resulting set of TTCN-3 definitions will be infinite). Such mapping
cannot be implemented by a simple converter. The only possible way to implement
the mapping is that the compiler of the TTCN-3 tool reads the C/C++ code and
instantiate the appropriate TTCN-3 definitions in its internal symbol table on
demand (i.e. when they are referenced from the regular TTCN-3 modules).

- There is a mapping given for built-in types of C/C++. The status of the
equivalent TTCN-3 types is unclear. Which module they are defined in?
Are they delivered with the TTCN-3 tool or the user shall provide them?
Can they be used without defining them in a C/C++ aware TTCN-3 tool?

- The document lacks a common naming convention for the resulting TTCN-3
entities. The TTCN-3 identifiers are somehow derived from C/C++ identifiers
and/or scope names, but the algorithm of name transformations is not described
anywhere. (See also the comment for section 4)


Comments for specific sections
==============================

1. Scope

It is unclear what a header file is.
C and C++ programs are composed of one or more translation units. It is required
that a translation unit shall be valid according to the syntax and static
semantic rules of C/C++ languages. A translation unit may contain declarations
and definitons. Each function or (global) variable of the program shall be
defined in exactly one translation unit, but it can be declared in several ones.
Although it is not mandatory, it is a good and widely used technique to use the
C preprocessor to construct translation units from multiple files. It is also a
common technique to declare each language element in exactly one (header) file.
It is a good, but less common practice to create all files of a C/C++ program in
such way that the preprocessor output of every file yields a valid translation
unit. Note that in case of header files the preprocessed output contains only
declarations.

I guess the scope of this document should be a header file with at least the
above extra restrictions. This implies the following problems:
- When the syntax of a C/C++ translation unit is validated the preprocessor
directives are not visible anymore.
- Most C/C++ interface definitions are based on common interfaces (e.g.
the header files that are parts of the C/C++ standard or system libraries),
which usually do not fulfill the above requirements. The system headers cannot
be omitted because the file to be mapped is simply invalid without them (e.g.
due to references to system data types).

3 Definitions, symbols and abbreviations

This section contains nothing, but the text of the ETSI template.

4 Names and Scoping

Unlike C/C++ TTCN-3 has a flat namespace because the result of the mapping are
modules or definitions at module scope. Thus it is necessary to combine one
single TTCN-3 identifier from several C/C++ identifiers.
Name construction is used in several sections of the document, but it is always
done in an ad-hoc way. The precise algorithm is not specified anywhere. It is
not trivial at all to define the rules such that each valid C/C++ name hierarchy
is mapped to a valid and unique TTCN-3 name.

Note: The C++ compilers must solve the same problem when they have to map the
names of C++ entities to symbol names used by the linker. This mapping is called
mangling. Mangling solves the following C++ related issues in a consistent and
unified way:
- namespaces
- member functions of classes and static class members
- polymorphic functions
- operator overloading
- pointers, references in function arguments
- const modifiers
- template instantiation
Although the way of mangling is compiler-dependent the authors of this standard
should study the algorithms of a specific C++ compiler to take some basic ideas.
Those algorithms cannot be used directly as they are optimized for symbol
length. Thus the mangled names produced by C++ compilers are not very user
friendly.

7 Integer types

Why are the sizes of C/C++ integer types explicitly restricted in TTCN-3? They
are implementation defined, like the size of TTCN-3's integer type. The tool
that realizes the mapping should rather set the appropriate type constraints.
LLONG_MIN, LLONG_MAX and ULLONG_MAX are defined in C. How can they be visible
from TTCN-3?

9.1 C++ specific structure types

Classes are mapped to modules. Namespaces are also mapped to modules.
What is the mapping of a class defined in a namespace?

Table 10 gives two alternative mappings (external functions or
signatures) for the same C++ construct. What determines which one will be used
in a certain case?

9.3 Anonymous types

How will it be mapped if an anonymous type is used to declare anything other
than a single member?

struct Person {
struct {
int phone;
} phone1, phone2, *phonePtr;
};

9.3.1 C++ specific anonymous types

The mapping of member functions called "MyFunction" is wrong. The "this"
pointer shall be passed to them somehow.

12 Enumeration types

Why are C/C++ enumeration types are mapped to CppInt? There are two arguments,
both are false:
- Edition 3 of TTCN-3 CL allows negative integers enumerated values.
- Using this mapping we loose more than we can gain. For instance, any integer
value can be passed to a function that accepts an enum. It would be rather
better to propose a new additional predefined function in
TTCN-3 CL that could perform the enumerated -> integer conversion in an explicit
way.

13 Function types

It is unclear how the required and the provided interfaces are distinguished in
the C/C++ header file.

What does the resulting TTCN-3 port type belong to? A header file, class or
something else. How shall those port types be instantiated (should there be one
or more instances)?

In case of unspecified number of arguments (Table 17) there are infinite
possible argument combinations. How is it decided which combinations to include
in the mapping?

13.1 C++ specific function types

It is unclear when the suffix is used in function names and what it shall
contain. See also the comments for section 4.
It is not a good idea to use suffixes only in case of polymorphism: When a new
variant is introduced in an existing interface the mapping of the existing
function will change. Example:
First version of the interface:
void print (int value); // mapped to print (non-polymorphic) Second version:
void print(int value); // mapping will change to print_int!
void print(const char *string); // mapped to print_constcharptr

Functions that return objects are not mentioned anywhere. It is unspecified what
the corresponding TTCN-3 signature should return (a pointer or an object).

14.1 C++ specific pointer types

Once a C++ object is created how can its pointer be dereferenced (e.g.
in order to access its data members)? That is, how can MyClassPtr be converted
to MyClassType?

What about the reverse direction: object -> pointer struct EmbeddedClass { void
foo(); }; struct MyClass {
EmbeddedClass embeddedObject
};
I have an object of MyClass (a variable of type MyClassType). How can I call the
member function foo() on the member field embeddedObject? The equivalent of
foo() expects EmbeddedClassPtr and not EmbeddedClassType.

It is unspecified when the pointer definitions and new/delete functions are
created. Are they created for all classes? And what about pointers to pointers,
pointers to pointers to pointers, etc?

What is the difference between signature CMyClass of Table 20 and signature
NewMyClass of Figure 5? There are other similarities: DMyClass and
DeleteMyClass.

It is unclear when the external functions or the signatures are used.
They cannot be both present at the same time because of the clashing names.

14.3 C++ specific pointers to members

What is the mapping of C/C++ pointers to function? It is not specified anywhere.

15 Array types

Why is the "record of" construct used in the mapping of C/C++ arrays?
Why are length ranges used instead of fixed length?
TTCN-3 arrays would be more appropriate.

16 Reference types

There is no possibility to obtain the reference of an object. The opposite
direction (accessing an object using its reference) is missing too. Conversion
between pointers and references would be also useful.
That is, there should be predefined conversion routines between TTCN-3 types
MyClassType, MyClassPrt and MyClassRef in all possible directions.

17.1 Inheritance

Contradiction: On Table 24 type BaseType is defined within module Base.
However, type PersonType on Table 9 does not have its own module.

What is the naming convention for base class fields in case of multiple
inheritance? What about virtual inheritance?

It would be better to provide a SubClassPrt -> SuperClassPrt conversion function
instead of duplicating inherited member functions.

18 Template specifications

The set of possible template instances is infinite. How can it be decided which
instances are needed?
It would be better to leave out template classes from the mapping (in a similar
way as parameterized ASN.1 types are not visible from TTCN-3).
Only explicitly instantiated template classes should be mapped. Example:
typedef MyString<char> MyCharString;
In this case MyCharString would be mapped as a regular class.

22 Access specifiers

There is no reason to show protected members in the TTCN-3 view of classes. At
C++ language level there is no way to access them from outside the class. Low-
level and dirty hacks are needed in the realization to read or modify a
protected data member or call a protected member functions. Moreover, there is
no such thing as polymorphism or implicit cast in TTCN-3 where protected members
are also candidates.

23 Preprocessor directives

Preprocessor directives should not be mapped to anything as the mapping should
be performed on the preprocessor output (see the comments for section 1).
The preprocessor is used for low-level text manipulation, which does not have
direct relation to C/C++ declarations.
Moreover, in general it is impossible to decide what a preprocessor macro does
by seeing the macro itself. It can be analyzed only within the context that it
is being used. The arguments of macros are not necessarily values, they can be
anything: keywords, fragments of identifiers, etc.

24 Lexical conventions

There are many potential clashes between the mapped names of C/C++ identifiers.
These should be avoided or at least resolved. See also the comments for section
4.

--
János Zoltán Szabó This email address is being protected from spambots. You need JavaScript enabled to view it.
Test Competence Center Tel: +36-1-437-7635
Ericsson Telecommunications Ltd. Fax: +36-1-437-7576
H-1037 Budapest, Laborc u. 1., Hungary Mob: +36-30-350-2496
Intranet: ttcn.ericsson.se/ ECN: 831-7635

Dear Janos,

sorry for the late reply. First of all thank you very much for your
comments. We believe that most of them are valid and corrections should
be done in the document. However, we hoped to receive such comments
before the last MTS meeting which would have allowed us to resolve the
problems before the documents goes for vote. Since this doesn't happen
we (you) have to go the official way.

This means you should contact György (he is probably responsible for the
Ericsson vote or knows who is responsible) and attach your comments to
the Ericsson vote. If the vote for the document is yes, we try to
resolve all comments before publication. After publication the normal CR
mechanism will be used to improve and correct the document.

However, this official mechanism does not prevent us from entering the
technical discussion with you in order to resolve as much of your
comments as soon as possible. Matti Karki (and I believe also Andreas
Nyberg) are working on your comments and will soon either reply to this
list or contact you directly.

By addressing your comments in this way, we hope we can avoid a NO-vote
from Ericsson.

Btw. the reason for the formal mistakes (empty or meaningless sections
copied from the ETSI skeleton) is that 'experience' has shown that it is
easier to delete them at the latest point in time rather then
re-introduce them again after they have been deleted.

Best regards
Jens Grabowski



János Zoltán Szabó schrieb:
> Dear list members,
>
> I have looked over the latest version of this document, which was
> prepared for the last MTS meeting. In addition to formal mistakes (empty
> or meaningless sections copied from the ETSI skeleton) I have found
> several technical problems. I think many of the problems are so
> significant that this document should be accepted as an ETSI standard
> only after a major technical revision.
>
> Since nobody has sent any technical comments about this document to this
> mailing list I would like to share my opinions with you.
>
> With best regards,
> Zoltan
>
>
> General comments
> ================
>
> - The C/C++ input is not defined properly (see the comment for Section 1
> below).
>
> - The realization of the mapping is not possible in some cases. The
> Introduction states that this document uses explicit mapping. This means
> one can develop a C/C++ -> TTCN-3 converter tool that creates the TTCN-3
> equivalents of the header files and the generated modules can be
> imported into the user's TTCN-3 modules. However, the ducument specifies
> non-static mapping for some C++ entities (e.g. functions with variable
> arguments or template classes). In these cases the TTCN-3 equivalents
> depend on not only the C/C++
> declaration, but on its usage as well (or the resulting set of TTCN-3
> definitions will be infinite). Such mapping cannot be implemented by a
> simple converter. The only possible way to implement the mapping is that
> the compiler of the TTCN-3 tool reads the C/C++ code and instantiate the
> appropriate TTCN-3 definitions in its internal symbol table on demand
> (i.e. when they are referenced from the regular TTCN-3 modules).
>
> - There is a mapping given for built-in types of C/C++. The status of
> the
> equivalent TTCN-3 types is unclear. Which module they are defined in?
> Are they delivered with the TTCN-3 tool or the user shall provide them?
> Can they be used without defining them in a C/C++ aware TTCN-3 tool?
>
> - The document lacks a common naming convention for the resulting TTCN-3
> entities. The TTCN-3 identifiers are somehow derived from C/C++
> identifiers and/or scope names, but the algorithm of name
> transformations is not described anywhere. (See also the comment for
> section 4)
>
>
> Comments for specific sections
> ==============================
>
> 1. Scope
>
> It is unclear what a header file is.
> C and C++ programs are composed of one or more translation units. It is
> required that a translation unit shall be valid according to the syntax
> and static semantic rules of C/C++ languages. A translation unit may
> contain declarations and definitons. Each function or (global) variable
> of the program shall be defined in exactly one translation unit, but it
> can be declared in several ones.
> Although it is not mandatory, it is a good and widely used technique to
> use the C preprocessor to construct translation units from multiple
> files. It is also a common technique to declare each language element in
> exactly one (header) file. It is a good, but less common practice to
> create all files of a C/C++ program in such way that the preprocessor
> output of every file yields a valid translation unit. Note that in case
> of header files the preprocessed output contains only declarations.
>
> I guess the scope of this document should be a header file with at least
> the above extra restrictions. This implies the following problems:
> - When the syntax of a C/C++ translation unit is validated the
> preprocessor directives are not visible anymore.
> - Most C/C++ interface definitions are based on common interfaces (e.g.
> the header files that are parts of the C/C++ standard or system
> libraries), which usually do not fulfill the above requirements. The
> system headers cannot be omitted because the file to be mapped is simply
> invalid without them (e.g. due to references to system data types).
>
> 3 Definitions, symbols and abbreviations
>
> This section contains nothing, but the text of the ETSI template.
>
> 4 Names and Scoping
>
> Unlike C/C++ TTCN-3 has a flat namespace because the result of the
> mapping are modules or definitions at module scope. Thus it is necessary
> to combine one single TTCN-3 identifier from several C/C++ identifiers.
> Name construction is used in several sections of the document, but it is
> always done in an ad-hoc way. The precise algorithm is not specified
> anywhere. It is not trivial at all to define the rules such that each
> valid C/C++ name hierarchy is mapped to a valid and unique TTCN-3 name.
>
> Note: The C++ compilers must solve the same problem when they have to
> map the names of C++ entities to symbol names used by the linker. This
> mapping is called mangling. Mangling solves the following C++ related
> issues in a consistent and unified way:
> - namespaces
> - member functions of classes and static class members
> - polymorphic functions
> - operator overloading
> - pointers, references in function arguments
> - const modifiers
> - template instantiation
> Although the way of mangling is compiler-dependent the authors of this
> standard should study the algorithms of a specific C++ compiler to take
> some basic ideas. Those algorithms cannot be used directly as they are
> optimized for symbol length. Thus the mangled names produced by C++
> compilers are not very user friendly.
>
> 7 Integer types
>
> Why are the sizes of C/C++ integer types explicitly restricted in
> TTCN-3? They are implementation defined, like the size of TTCN-3's
> integer type. The tool that realizes the mapping should rather set the
> appropriate type constraints.
> LLONG_MIN, LLONG_MAX and ULLONG_MAX are defined in C. How can they be
> visible from TTCN-3?
>
> 9.1 C++ specific structure types
>
> Classes are mapped to modules. Namespaces are also mapped to modules.
> What is the mapping of a class defined in a namespace?
>
> Table 10 gives two alternative mappings (external functions or
> signatures) for the same C++ construct. What determines which one will
> be used in a certain case?
>
> 9.3 Anonymous types
>
> How will it be mapped if an anonymous type is used to declare anything
> other than a single member?
>
> struct Person {
> struct {
> int phone;
> } phone1, phone2, *phonePtr;
> };
>
> 9.3.1 C++ specific anonymous types
>
> The mapping of member functions called "MyFunction" is wrong. The "this"
> pointer shall be passed to them somehow.
>
> 12 Enumeration types
>
> Why are C/C++ enumeration types are mapped to CppInt? There are two
> arguments, both are false:
> - Edition 3 of TTCN-3 CL allows negative integers enumerated values.
> - Using this mapping we loose more than we can gain. For instance, any
> integer value can be passed to a function that accepts an enum. It would
> be rather better to propose a new additional predefined function in
> TTCN-3 CL that could perform the enumerated -> integer conversion in an
> explicit way.
>
> 13 Function types
>
> It is unclear how the required and the provided interfaces are
> distinguished in the C/C++ header file.
>
> What does the resulting TTCN-3 port type belong to? A header file, class
> or something else. How shall those port types be instantiated (should
> there be one or more instances)?
>
> In case of unspecified number of arguments (Table 17) there are infinite
> possible argument combinations. How is it decided which combinations to
> include in the mapping?
>
> 13.1 C++ specific function types
>
> It is unclear when the suffix is used in function names and what it
> shall contain. See also the comments for section 4.
> It is not a good idea to use suffixes only in case of polymorphism: When
> a new variant is introduced in an existing interface the mapping of the
> existing function will change. Example:
> First version of the interface:
> void print (int value); // mapped to print (non-polymorphic)
> Second version:
> void print(int value); // mapping will change to print_int!
> void print(const char *string); // mapped to print_constcharptr
>
> Functions that return objects are not mentioned anywhere. It is
> unspecified what the corresponding TTCN-3 signature should return (a
> pointer or an object).
>
> 14.1 C++ specific pointer types
>
> Once a C++ object is created how can its pointer be dereferenced (e.g.
> in order to access its data members)? That is, how can MyClassPtr be
> converted to MyClassType?
>
> What about the reverse direction: object -> pointer
> struct EmbeddedClass {
> void foo();
> };
> struct MyClass {
> EmbeddedClass embeddedObject
> };
> I have an object of MyClass (a variable of type MyClassType). How can I
> call the member function foo() on the member field embeddedObject? The
> equivalent of foo() expects EmbeddedClassPtr and not EmbeddedClassType.
>
> It is unspecified when the pointer definitions and new/delete functions
> are created. Are they created for all classes? And what about pointers
> to pointers, pointers to pointers to pointers, etc?
>
> What is the difference between signature CMyClass of Table 20 and
> signature NewMyClass of Figure 5? There are other similarities: DMyClass
> and DeleteMyClass.
>
> It is unclear when the external functions or the signatures are used.
> They cannot be both present at the same time because of the clashing
> names.
>
> 14.3 C++ specific pointers to members
>
> What is the mapping of C/C++ pointers to function? It is not specified
> anywhere.
>
> 15 Array types
>
> Why is the "record of" construct used in the mapping of C/C++ arrays?
> Why are length ranges used instead of fixed length?
> TTCN-3 arrays would be more appropriate.
>
> 16 Reference types
>
> There is no possibility to obtain the reference of an object. The
> opposite direction (accessing an object using its reference) is missing
> too. Conversion between pointers and references would be also useful.
> That is, there should be predefined conversion routines between TTCN-3
> types MyClassType, MyClassPrt and MyClassRef in all possible directions.
>
> 17.1 Inheritance
>
> Contradiction: On Table 24 type BaseType is defined within module Base.
> However, type PersonType on Table 9 does not have its own module.
>
> What is the naming convention for base class fields in case of multiple
> inheritance? What about virtual inheritance?
>
> It would be better to provide a SubClassPrt -> SuperClassPrt conversion
> function instead of duplicating inherited member functions.
>
> 18 Template specifications
>
> The set of possible template instances is infinite. How can it be
> decided which instances are needed?
> It would be better to leave out template classes from the mapping (in a
> similar way as parameterized ASN.1 types are not visible from TTCN-3).
> Only explicitly instantiated template classes should be mapped. Example:
> typedef MyString<char> MyCharString;
> In this case MyCharString would be mapped as a regular class.
>
> 22 Access specifiers
>
> There is no reason to show protected members in the TTCN-3 view of
> classes. At C++ language level there is no way to access them from
> outside the class. Low-level and dirty hacks are needed in the
> realization to read or modify a protected data member or call a
> protected member functions. Moreover, there is no such thing as
> polymorphism or implicit cast in TTCN-3 where protected members are also
> candidates.
>
> 23 Preprocessor directives
>
> Preprocessor directives should not be mapped to anything as the mapping
> should be performed on the preprocessor output (see the comments for
> section 1).
> The preprocessor is used for low-level text manipulation, which does not
> have direct relation to C/C++ declarations.
> Moreover, in general it is impossible to decide what a preprocessor
> macro does by seeing the macro itself. It can be analyzed only within
> the context that it is being used. The arguments of macros are not
> necessarily values, they can be anything: keywords, fragments of
> identifiers, etc.
>
> 24 Lexical conventions
>
> There are many potential clashes between the mapped names of C/C++
> identifiers. These should be avoided or at least resolved. See also the
> comments for section 4.
>

--
======================================================================
Prof. Dr. Jens Grabowski
Institute for Informatics phone: +49 551 39 14690
University of Goettingen fax: +49 551 39 14415
Lotzestrasse 16-18
DE-37083 Göttingen This email address is being protected from spambots. You need JavaScript enabled to view it.
(Germany) www.swe.informatik.uni-goettingen.de
======================================================================