A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2001-May/014874.html below:

[Python-Dev] GC and ExtensionClass - a summary of the problem and a workaround

[Python-Dev] GC and ExtensionClass - a summary of the problem and a workaround [Python-Dev] GC and ExtensionClass - a summary of the problem and a workaroundGuido van Rossum guido@digicool.com
Thu, 17 May 2001 10:37:30 -0400
> [Skip] 
> 
> > Note that the parameter to the PyObject_HEAD_INIT macro is NULL. 
> > It would normally be the address of a type object (e.g.
> > &PyType_Type).  However, Jim Fulton pointed out that on Windows
> > you can't get the address of &PyType_Type object at compile time.
> 
> This is MS being passive-aggressive. If you tell MSVC the 
> source is C++, it will magically find the address of 
> PyType_Type at compile time, but their language lawyers 
> apparently  believe the C spec disallows this. Standards 
> conformant and incompatible -
> 
> what-MS-calls-"win-win"-ly y'rs
> 
> - Gordon

I don't think MS blames it on the language spec so much; it's probably
more that they use the spec as an excuse not to fix their
implementation.  The problem only occurs when the definition of the
symbol is in a different DLL than the reference.  This is why built-in
types like PyTuple_Type don't have this problem.  I guess for C++ they
have to do a dynamic initializer anyway, so they can make this work,
but they haven't bothered to make it work for C.

My other point is that Skip's problem is clearly a gtk bug: it
shouldn't have exposed the type before fully initializing it.

--Guido van Rossum (home page: http://www.python.org/~guido/)



RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4