Hi Greg,
В сообщении от Четверг 15 мая 2008 Greg Ewing написал(a):
> There's something I've been meaning to ask people
> about. Until I find a way of handling const properly,
> I'm considering having Pyrex put this at the top of
> its generated files:
>
> #define const
>
> so that all Pyrex-generated code will be a totally
> const-free zone.
>
> But I don't want to do this if there's a chance
> it could break something. Can anyone think of any
> problems it could cause?
I think this is going to be trouble at least when interfacing with external
C++ code and libraries - at least at link time.
All C++ compilers I know put function signature into it's name (there is even
C++ ABI rules for this), and 'const' too affects this, look:
$ cat c++const.cpp
void dosmth_1(int *p)
{}
void dosmth_2(const int *p)
{}
$ g++ -c c++const.cpp
$ nm c++const.o
00000000 T _Z8dosmth_1Pi
00000006 T _Z8dosmth_2PKi
U __gxx_personality_v0
So you see, "void dosmth_1(int *)" was mangled into _Z8dosmth_1Pi, and
"void dosmth_2(const int *p)" into _Z8dosmth_2PKi. Note extra 'K' character.
Now, if we empty "#define const ", we'll fool C++ compiler to try to link with
another signature for functions where const was present, and this will be a
failure at link time.
This is what first comes to my mind -- there are probably other issues as well.
With this explanation, I'm -1 to the "#define const <empty>" idea, and also
I think that instead, it would be better to spend our energy and time to
add proper const support.
What do you think?
Thanks,
Kirill.
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
