C extension - new and init functions

[Paul Moore]

On 17 Nov, 09:40, Hrvoje Niksic <hnik... at xemacs.org> wrote:
> Paul  Moore <p.f.mo... at gmail.com> writes:
>
> > OK, but that allocates the initial buffer, which I will then
> > throw away.
>
> Why don't you use a constructor argument that allows specifying
> the initial buffer size?

That's an option, but I don't want to expose that argument to Python
code (as it would allow the user to create an object which wasn't
fully initialised - I only use the extra argument myself when there's
additional initialisation to do in C).

> > In practice, this isn't a significant issue (the overhead of
> > one allocation and one deallocation isn't going to wreck
> > things!) but it feels somehow clumsy. However, I can't see an
> > obvious way to refactor the code so that building the object
> > and assigning the buffer are separate - so that I can write a
> > function like Pattern_init, which allocates a differently
> > sized buffer (well, I could, but if I did, I'd have no way of
> > using it that respects subclassing...
>
> Another way would be to avoid allocating the buffer at all
> until it is actually needed.

The problem then is that I have to include null checks in a lot of
code that can otherwise assume that objects passed in have a valid
buffer.

Thinking it through, I think the extra dealloc/alloc and minor code
duplication probably isn't enough of an issue to compromise safety
over.

Thanks,
Paul.