| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
1 parent 5e02c78 commit ca72589
2 files changed
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -177,16 +177,9 @@ the module. We'll expand this example later to have more interesting behavior. | |||
| 177 | 177 | For now, all we want to be able to do is to create new :class:`Noddy` objects. | |
| 178 | 178 | To enable object creation, we have to provide a :c:member:`~PyTypeObject.tp_new` implementation. | |
| 179 | 179 | In this case, we can just use the default implementation provided by the API | |
| 180 | - function :c:func:`PyType_GenericNew`. We'd like to just assign this to the | ||
| 181 | - :c:member:`~PyTypeObject.tp_new` slot, but we can't, for portability sake, On some platforms or | ||
| 182 | - compilers, we can't statically initialize a structure member with a function | ||
| 183 | - defined in another C module, so, instead, we'll assign the :c:member:`~PyTypeObject.tp_new` slot | ||
| 184 | - in the module initialization function just before calling | ||
| 185 | - :c:func:`PyType_Ready`:: | ||
| 186 | - | ||
| 187 | - noddy_NoddyType.tp_new = PyType_GenericNew; | ||
| 188 | - if (PyType_Ready(&noddy_NoddyType) < 0) | ||
| 189 | - return; | ||
| 180 | + function :c:func:`PyType_GenericNew`. :: | ||
| 181 | + | ||
| 182 | + PyType_GenericNew, /* tp_new */ | ||
| 190 | 183 | ||
| 191 | 184 | All the other type methods are *NULL*, so we'll go over them later --- that's | |
| 192 | 185 | for a later section! | |
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -308,7 +308,7 @@ static PyTypeObject Null_Type = { | |||
| 308 | 308 | 0, /*tp_dictoffset*/ | |
| 309 | 309 | 0, /*tp_init*/ | |
| 310 | 310 | 0, /*tp_alloc*/ | |
| 311 | - 0, /* see PyInit_xx */ /*tp_new*/ | ||
| 311 | + PyType_GenericNew, /*tp_new*/ | ||
| 312 | 312 | 0, /*tp_free*/ | |
| 313 | 313 | 0, /*tp_is_gc*/ | |
| 314 | 314 | }; | |
@@ -338,11 +338,19 @@ PyDoc_STRVAR(module_doc, | |||
| 338 | 338 | static int | |
| 339 | 339 | xx_exec(PyObject *m) | |
| 340 | 340 | { | |
| 341 | - /* Due to cross platform compiler issues the slots must be filled | ||
| 342 | - * here. It's required for portability to Windows without requiring | ||
| 343 | - * C++. */ | ||
| 341 | + /* Slot initialization is subject to the rules of initializing globals. | ||
| 342 | + C99 requires the initializers to be "address constants". Function | ||
| 343 | + designators like 'PyType_GenericNew', with implicit conversion to | ||
| 344 | + a pointer, are valid C99 address constants. | ||
| 345 | + | ||
| 346 | + However, the unary '&' operator applied to a non-static variable | ||
| 347 | + like 'PyBaseObject_Type' is not required to produce an address | ||
| 348 | + constant. Compilers may support this (gcc does), MSVC does not. | ||
| 349 | + | ||
| 350 | + Both compilers are strictly standard conforming in this particular | ||
| 351 | + behavior. | ||
| 352 | + */ | ||
| 344 | 353 | Null_Type.tp_base = &PyBaseObject_Type; | |
| 345 | - Null_Type.tp_new = PyType_GenericNew; | ||
| 346 | 354 | Str_Type.tp_base = &PyUnicode_Type; | |
| 347 | 355 | ||
| 348 | 356 | /* Finalize the type object including setting type of the new type | |
| Back | FazBrowse Home | New Git URL |
0 commit comments