Jackson Hoy Loper wrote:
> stl iterators are still pretty much useless in cython, which seems
> rather unfortunate.
>
> one Ravi Lanka brought up the basic issue this april... it's a matter
> of initializing classes without default constructors. as far as i
> know the issue is still unresolved (despite Greg Ewing's comment; see
> below). do we expect this guy to get solved any time soon? it may
> seem trivial, but scipy still uses STL, and unordered_map is the best
> hash table support around right now...
>
> thoughts:
>
> 1) iterators don't have a constructor that takes no arguments, so
> you can't ever say
>
> cdef STLiterator k # no constructor can be found
>
> 2) cython balks at taking the address of temporaries, so you can't
> use pointers...
>
> cdef STLiterator *k
> k=&(mySTLcontainer.begin()) # can't take address of non-lvalue
>
> 3) I see that Greg Ewing proposed declaring functions like
> myhash.begin() "as though" they returned pointers, but I cannot
> understand what this means. The function does not return a pointer,
> and c++ notes this with due gravitas. Unless you have control over
> the source code or want to write a shim, this will not work. It's a
> dangerous idea, anyway, if I understand it correctly. It's a tragedy
> that not everything is a pointer in this world, but it is also the
> cold, cold reality... (until c++ tr1 goes through, anyway...)
>
> I'd be happy to take this on, as far as the code goes (though I
> confess I haven't looked at the source yet). I'm not sure how
> controversial this is, but I'm personally pretty clear that we should
> put our declarations in the c code wherever they're declared in the
> cython code. there's a pretty deep sense in which this is the "right"
> answer. mixed code & declarations is officially kosher in C, too, as
> of ISO C99. it's true, there are a few oldschool makefiles out there
> compiling with -ansi -pedantic-errors, but -std=gnu99 has now nearly
> tripled -ansi -pedantic-errors on google. And most of the hits for
> the latter are about how it's causing everybody trouble and they're
> going to drop it. I could well be wrong, but I really don't think
> it's an issue, especially with the prevalence of distutils.
>
Hi,
better C++ support is something everybody wants, I think, it just isn't
high enough on the priority list of the usual list of Cython
contributors. So if you are willing to take it on as far as code goes
I'm sure everybody is willing to see if something can be sorted out.
I think the mixed code & declarations issue as such is pretty easy to
handle (in the sense of conflicting with existing codebases) with a
compiler directive/option. There already is a --cplus option for Cython
which could turn this on.
So a first step could thus be to start initializing variables at the
point of the "cdef" statement if --cplus is turned on. I'm +1 for this
myself.
There is a related issue though that worries me: Cython doesn't have
block variable scoping, so syntax like this:
def f(...):
if should_process:
cdef myiterator t = items.begin()
... process items
...
isn't allowed, and that means that writing STL code will be a bit
cumbersome even if this was supported. To some degree this can be
mitigated by inner functions though (once those are supported):
def f(...):
def process_items():
cdef myiterator t = items.begin()
...
if should_process:
process_items()
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
