Hi,

Dag Sverre Seljebotn wrote:
> I've might have touched upon this one before, actually I cannot 
> remember. At any rate I know I've got no answer.
> 
> Can anyone think of a reason why C string literals are allocated as 
> variables in C source? I.e. what happens now is
> 
> static char __pyx_k_2[] = "AB";
> static PyObject *__pyx_kp_2;
> ...
> 
> static __Pyx_StringTabEntry __pyx_string_tab[] = {
>    {&__pyx_kp_2, __pyx_k_2, sizeof(__pyx_k_2), 0, 1, 0},
>    {0, 0, 0, 0, 0, 0}
> };
> 
> This leads to bookkeeping etc. in Symtab.py, and IMO also makes the C 
> source less readable. Would it be possible to simplify this and instead do
> 
> static __Pyx_StringTabEntry __pyx_string_tab[] = {
>    {&__pyx_kp_2, "AB", 2, 0, 1, 0},
>    {0, 0, 0, 0, 0, 0}
> };
> 
> ?

AFAIR, there may also be references to __pyx_k_2 in the C source, but
that's worth checking. In any case, char* literals currently end up in the
same place as the char* basis of str/unicode literals.

I wouldn't mind putting them right into the string tab, though, and
declaring them "const char*" there (if the C-API in Py2.3 allows it, don't
remember).


> One could argue that the literal can be reused -- however the C compiler 
> will in most (all?) cases optimize/collapse identical string constants

I doubt that it will do that in many cases. It can really only do that for
a const char*. All other char sequences are free to be mutated in place.

BTW, I doubt that it's worth merging Python string references. They are
either identifiers, in which case the interning hits, or longer strings, in
which case it's less likely there's more than one of them.


> (The background is that string literals etc. should also be moved to 
> code generation, so that, say, pruning a StringNode in a transform 
> doesn't make the string constant linger in the scope. Part of this is
> already in place but the final steps are not done. See 
> http://trac.cython.org/cython_trac/ticket/99 )

Sounds like a bit of work, but it sounds worthwhile.

Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to