Repository navigation
"slots" member variable in object.h confuses Qt moc utility #41335
Description
| BPO | 1086854 |
|---|---|
| Nosy | @mwhudson, @loewis, @birkenfeld, @birkenfeld |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/birkenfeld'
closed_at = <Date 2006-02-20.22:27:51.000>
created_at = <Date 2004-12-17.04:07:56.000>
labels = ['build']
title = '"slots" member variable in object.h confuses Qt moc utility'
updated_at = <Date 2006-02-20.22:27:51.000>
user = 'https://bugs.python.org/jfriesne'bugs.python.org fields:
activity = <Date 2006-02-20.22:27:51.000>
actor = 'georg.brandl'
assignee = 'georg.brandl'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2004-12-17.04:07:56.000>
creator = 'jfriesne'
dependencies = []
files = []
hgrepos = []
issue_num = 1086854
keywords = []
message_count = 12.0
messages = ['23751', '23752', '23753', '23754', '23755', '23756', '23757', '23758', '23759', '23760', '23761', '23762']
nosy_count = 5.0
nosy_names = ['mwh', 'loewis', 'georg.brandl', 'georg.brandl', 'jfriesne']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1086854'
versions = []
Activity
jfriesne commentedon Dec 17, 2004
This isn't really a Python bug per se, but it's easy to fix so I'm
filing a bug report anyway. The problem is with the line
PyObject *name, *slots;
in the definition of struct _heaptypeobject at line 343 of
Include/object.h. I'm embedding Python into my app that uses
the TrollTech Qt GUI, and Qt has a preprocessor program
named "moc" that looks for certain non-standard keywords.
One of these keywords is the word "slots"... so having a
member variable named "slots" in Include/object.h confuses
moc and causes my app to have a build error. I was able to
fix the problem by renaming the "slots" member variable to
"xslots" in the Python source, but it would be nicer if it was
renamed in the official Python distribution so that the problem
doesn't come up for the next guy.
birkenfeld commentedon Sep 28, 2005
Logged In: YES
user_id=1188172
I can find 3 occurences in typeobject.c where the variable
would have to be renamed. Can you find any other?
jfriesne commentedon Sep 28, 2005
Logged In: YES
user_id=383828
Here is a file containing grep output showing all the lines
where I changed 'slots' to 'xslots' in my codebase:
http://www.lcscanada.com/jaf/xslots.zip
birkenfeld commentedon Sep 29, 2005
Logged In: YES
user_id=1188172
Okay. Most of your replacements are function parameters or
function local variables, do they have to be replaced too?
jfriesne commentedon Sep 29, 2005
Logged In: YES
user_id=383828
Unfortunately, yes, When compiling with Qt, the words "signals"
and "slots" become essentially reserved keywords, and any use of
them as variable names causes a compile error.
birkenfeld commentedon Sep 29, 2005
Logged In: YES
user_id=1188172
Ah, okay. However, I can't decide whether this will be done,
assigning to Martin for this case.
mwhudson commentedon Sep 30, 2005
Logged In: YES
user_id=6656
I'm not particularly convinced that this is a great idea. Python uses 'new'
and 'class' as C identifiers which mean you can't compile it as C++ -- but
Python isn't written in C++, so this is fine. Similarly, Python isn't designed
to be fed to moc -- so why feed it to moc?
jfriesne commentedon Sep 30, 2005
Logged In: YES
user_id=383828
On second thought, I believe mwh is right; most of those
changes are unnecessary. (I made the changes a long time
ago, so when I grepped for them the other day the memory for
their motivation wasn't fresh). The Python .c files aren't
fed to moc, so references to 'signals' and 'slots' in the .c
files should compile okay. It's just the references to
those identifiers in the Python .h files that cause a
problem, if the .h files are #included in a Qt-using C++
program, after #including a Qt header. So I think probably
just the original three changes are sufficient.
loewis commentedon Oct 2, 2005
Logged In: YES
user_id=21627
I would assume that the changes are necessary *only* in
header files, which means that only heaptype is to be changed.
I don't know what happened to the old principle of
protecting struct members against name collisions; I think
if they are to be renamed, their names should be ht_type,
ht_name, ht_slots. (I never understood the rationale for
this convention until this report: there always might be a
collision with a macro name).
Unfortunately, such a change is not so easy as it may sound:
it may break existing applications. Still, I think it should
be done, but only for 2.5.
Unassigning myself.
birkenfeld commentedon Feb 20, 2006
Logged In: YES
user_id=1188172
Assigning you again, Martin: should I change the names for 2.5?
loewis commentedon Feb 20, 2006
Logged In: YES
user_id=21627
Sure!
birkenfeld commentedon Feb 20, 2006
Logged In: YES
user_id=849994
Done in rev. 42531.