Subject: Re: [sv-cc] SV-CC LRM - array of strings
From: Francoise Martinolle (fm@cadence.com)
Date: Wed Apr 16 2003 - 12:59:41 PDT
Andrzej,
I reread the string section and I don't think of it like a class. The only
which makes it look
like a class is that they have methods to get the string length, its value
etc...
Vera may have implemented it as a class, but there is nothing in the
specification that suggest that all implementations do it this way.
I think we are still okay in supporting string types and array of strings.
It may be
very inefficient in the current Vera/SV implementation if you
have to do string copies to pass it to C but I don't think there is
anything in the standard which would prevent DPI from supporting the string
SV type.
The only differences I see is that a C string will be null terminated while
a SV string is not
and SV strings are dynamically allocated as needed.
Francoise
'
At 02:01 PM 4/15/2003 -0400, Andrzej Litwiniuk wrote:
>Team,
>
>
>We have another problem, I'm afraid, resulting from the changes in SV 3.0 made
>by other committees. Do we want to permit arrays of strings?
>
>I was asked the following question by a person doing the review of the
>document
>for SV-CC:
>
> > one comment I have is how I would interface from SV, to a C function whose
> > prototype was
> > int f (char *argc[], int argv);
> >
> > as far as I could see in the document, a string (in SV) would become a
> > char* (in C)
> > but how would I get to *char[], it is almost like an array of strings
> in SV.
>
>A natural answer seemed to be "an open array of strings", i.e. something like
>this (in SV): import "DPI" function int f (string argc[], int argv);
>
>Then I realized that the current semantics of 'string' differs from the
>semantics assumed both in DirectC donation and in "17 items proposal".
>The type 'string' was originally intended to be very similar to a generic
>opaque pointer, with the sole difference that string literals, like "a text",
>would be interpreted as C-style char* pointers rather than as ASCII-based
>encoding of bit vectors.
>
>Now, after all additions to SV 3.0, string is a class rather than a C -style
>pointer. As a consequence, passing 'string' type argument requires that
>additional conversion will be performed; either a pointer must be extracted
>from a class object (and perhaps the actual string copied), or a new class
>instance be created with a copy of a string. Although this may be tolerable
>for individual values of type string crossing the interface, it defies
>the assumption that there will be no intrinsic overhead.
>
>Consider now an array of strings. Passing such an array would require
>pretty expensive translation.
>An array of strings will have different representations on both sides
>of an interface, hence it takes a translation: for the whole array and for
>each of its elements.
>A new array would have to be allocated and filled
>with pointers to newly allocated objects, be they class instances or copies of
>C strings.
>Situation is even worse, because memory will have to be dynamically allocated
>and hence memory leaks will be very likely.
>All those issues were absent with the original proposal (all strings would
>have
>been allocated statically by a compiler).
>
>IMO the solution is to keep a special flavour of a generic pointer ment
>for strings as a separate basic type. So there would be two variants of opaque
>pointers: 'handle' and 'cstring' (the actual name doesn't matter.)
>Actually, what I'm proposing here is a reversion to the original solution.
>You see, language definition is not a random collection of constructs, that
>could be mixed and matched at will :-)
>
>Note that classes are not supported in DPI, hence 'string' would not be
>permitted either. However, a conversion between a single object of class
>string
>and a single value of type 'cstring' would be supported.
>Therefore it would be possible to use an actual argument of type string (for
>all directions) for the formal argument of type 'cstring'.
>An array of 'string' would not match, however, an array of 'cstring'.
>
>
>Thanks,
>Andrzej
This archive was generated by hypermail 2b28 : Wed Apr 16 2003 - 13:03:04 PDT