[Pyrex] [Cython] Pyrex and const (Re: constify Cython output all over the place (newbie approach))

[Kirill Smelkov]

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.