[Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
Jeremy Hylton
jeremy at alum.mit.edu
Fri Feb 10 18:14:28 CET 2006
More information about the Python-Dev mailing list
Fri Feb 10 18:14:28 CET 2006
- Previous message: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
- Next message: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2/10/06, "Martin v. Löwis" <martin at v.loewis.de> wrote: > Jeremy Hylton wrote: > > I added some const to several API functions that take char* but > > typically called by passing string literals. In C++, a string literal > > is a const char* so you need to add a const_cast<> to every call site, > > That's not true. > > A string literal of length N is of type const char[N+1]. However, > a (deprecated) conversion of string literals to char* is provided > in the language. So assigning a string literal to char* or passing > it in a char* parameter is compliant with standard C++, no > const_cast is required. Ok. I reviewed the original problem and you're right, the problem was not that it failed outright but that it produced a warning about the deprecated conversion: warning: deprecated conversion from string constant to 'char*'' I work at a place that takes the same attitude as python-dev about warnings: They're treated as errors and you can't check in code that the compiler generates warnings for. Nonetheless, the consensus on the c++ sig and python-dev at the time was to fix Python. If we don't allow warnings in our compilations, we shouldn't require our users at accept warnings in theirs. Jeremy
- Previous message: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
- Next message: [Python-Dev] Baffled by PyArg_ParseTupleAndKeywords modification
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list