Ok, the thing is that "C arrays mapping" is a strange case.
The problem with C arrays is that the have a known size, and
the '\0' ending char is just a coincidence, ie you can define
char hi_a [] = {'h','e','l','l','o'};
char hi_b [] = "hello";
and both will be different
sizeof(hi_a) -> 5
sizeof(hi_b) -> 6
strlen(hi_a) -> undefined
strlen(hi_b) -> 5
and in the python side you will get
hi_a -> 'hello'
hi_b -> 'hello\0'
note that you can also put '0' char in between
char hi_a [] = {'h','e',0,'l','o'};
sizeof(hi_a) -> 5
strlen(hi_a) -> 2
So, in your case, maybe is better to use
const char* const BeginString_FIX44 = "FIX.4.4";
since that will be properly understood in C,C++ and in the python side
(and you don't need the std::string). In that case the use of 'strlen'
is explicit, and in the python side you will not see the '\0' ending
character.
Marcelo
Oren Miller wrote:
Marcello,
It doesn't look quite right to me. The code that gets generated is as
follows:
pyobj = SWIG_FromCharArray(FIX::BeginString_FIX44,
sizeof(FIX::BeginString_FIX44));
This compiles for sure, but when I print out the value, I get this:
'FIX.4.4\x00'
Which shows me a python string that contains a NULL value at the end
like a C string.
If I change the generated code to this:
pyobj = SWIG_FromCharArray(FIX::BeginString_FIX44,
strlen(FIX::BeginString_FIX44));
Then printing out the value gives me:
'FIX.4.4'
Which seems to me what I should be getting, and is the same value I
got when I was using std::strings.
--oren
On May 28, 2004, at 10:44 AM, Marcelo Matus wrote:
Is the SWIG CVS version working for you now?
Marcelo
Oren Miller wrote:
Yeah, I should have mentioned that I did not have this problem with
1.3.21. I moved to the CVS version so I could get directors with
throw specifiers, which worked, but then this cropped up.
On May 26, 2004, at 11:19 AM, William.Fulton@xxxxxxx wrote:
-----Original Message-----
From: swig-admin@xxxxxxxxxxxxxxx
[mailto:swig-admin@xxxxxxxxxxxxxxx]On
Behalf Of David Beazley
Sent: 26 May 2004 16:22
To: Oren Miller
Cc: swig@xxxxxxxxxxxxxxx
Subject: [Swig] bug while wrapping const char arrays without an
explicitly defined size
Oren Miller writes:
Using the latest CVS version:
If I have a char array defined like this:
const char BeginString_FIX44[8] = "FIX.4.4";
The wrapper for this is generated correctly like so:
static PyObject *_wrap_BeginString_FIX44_get() {
PyObject *pyobj;
pyobj = SWIG_FromCharArray(FIX::BeginString_FIX44, 8);
return pyobj;
}
However, if it is defined like so:
const char BeginString_FIX44[] = "FIX.4.4";
This gets generated:
static PyObject *_wrap_BeginString_FIX44_get() {
PyObject *pyobj;
pyobj = SWIG_FromCharArray(FIX::BeginString_FIX44, );
return pyobj;
}
As you can see the size is missing which of course results in
compilation errors. It would seem to me in this case Swig
should count
up the characters in the string and place the value as the second
parameter to FromCharArray. I'd be happy to try to create
a patch but
am not familiar with the source and would need someone to
point me to
the module where this generation occurs. Thanks.
Where is SWIG_FromCharArray() coming from? I don't remember that
function being part of the SWIG API (I sure didn't write it anyways).
SWIG developers: Is there some reason the normal PyObject API
functions are not being used here???
Not sure, but I checked SWIG-1.3.21 and it works.
PyString_FromString is used. We ought to add this to one of the
testcases in any case.
William
Visit our website at http://www.ubs.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
_______________________________________________
Swig maillist - Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig
