Martin v. Löwis wrote:
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers. For example, nobody
Thanks to all for a rather insightful discussion, it's always fun to
learn that after 28 years of C programming the language still has
little corners that I know absolutely nothing about:-)
Practically speaking, though, I've adopted MAL's solution for the
time being:
/* The keyword array
On 2/14/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's
On 2/14/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
The compiler in question is gcc and the warning can be turned off with
-Wno-write-strings. I think we'd be better off leaving that option
on, though. This warning will help me find places where I'm passing a
Jeremy Hylton wrote:
Perhaps there is some value in finding functions which ought to expect
const char*. For that, occasional checks should be sufficient; I cannot
see a point in having code permanently pass with that option. In
particular not if you are interfacing with C libraries.
I don't
On 2/12/06, Greg Ewing [EMAIL PROTECTED] wrote:
[A large head-exploding set of rules]
Blarg.
Const - Just Say No.
+1
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
const rules wink.
Jeremy
On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/12/06, Greg Ewing [EMAIL PROTECTED] wrote:
[A large head-exploding
+1
On 2/13/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
const rules wink.
Jeremy
On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/12/06,
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
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
Tim Peters wrote:
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
[Tim]
If he had _stuck_ to that, we wouldn't be having this discussion :-)
(that is, nobody passes string literals to
PyArg_ParseTupleAndKeywords's kws
Jeremy Hylton wrote:
The compiler in question is gcc and the warning can be turned off with
-Wno-write-strings. I think we'd be better off leaving that option
on, though. This warning will help me find places where I'm passing a
string literal to a function that does not take a const char*.
M.-A. Lemburg wrote:
It's the consequences: nobody complains about tacking const on to a
former honest-to-God char * argument that was in fact not modified,
because that's not only helpful for C++ programmers, it's _harmless_
for all programmers. For example, nobody could sanely object (and
Martin v. Löwis wrote:
then, in C++, 4.4p4 [conv.qual] has a rather longish formula to
decide that the assignment is well-formed. In essence, it goes
like this:
[A large head-exploding set of rules]
Blarg.
Const - Just Say No.
Greg
___
Greg Ewing wrote:
FWIW, Annex D also defines these features as deprecated:
- the use of static for objects in namespace scope (AFAICT
including C file-level static variables and functions)
- C library headers (i.e. stdio.h)
Things like this are really starting to get on my groat.
It used
Bengt Richter wrote:
Would it make sense to use a typedef for readability's sake? E.g.,
typedef const char * p_text_literal;
and then use
p_text_literal, const p_text_literal *
in the signature, for read-only access to the data? (hope I got that right).
(also testing
On Fri, 10 Feb 2006 18:02:03 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const.
Bengt Richter wrote:
Will a typedef help?
A typedef can never help. It is always possible to reformulate
a program using typedefs to one that doesn't use typedefs.
Compiling your program with the const modification line
removed gives
martin.c: In function 'int main()':
martin.c:18: error:
On Sat, Feb 11, 2006, Martin v. L?wis wrote:
Not at all. People appear to completely fail to grasp the notion of
deprecated in this context. It just means it may go away in a
future version, implying that the rest of it may *not* go away in a
future version.
That future version might get
On Sat, 11 Feb 2006 14:14:00 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
[EMAIL PROTECTED] wrote:
Bengt Richter wrote:
Will a typedef help?
A typedef can never help. It is always possible to reformulate
a program using typedefs to one that doesn't use typedefs.
I realize that's true for
Hi Tim,
On Fri, Feb 10, 2006 at 12:19:01PM -0500, Tim Peters wrote:
Oh, who cares? I predict Jack's problem would go away if we changed
the declaration of PyArg_ParseTupleAndKeywords to what you intended
wink to begin with:
PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject
Martin v. Löwis wrote:
That future version might get published in 2270,
There are *already* differences which make C and C++
annoyingly incompatible. One is the const char * const *
issue that appeared here. Another is that it no longer
seems to be permissible to forward-declare static things,
Aahz wrote:
That future version might get published in 2270, when everybody has
switched to C++, and compatibility with C is no longer required.
Just for the clarification of those of us who are not C/C++ programmers,
are you saying that this is different from the meaning in Python, where
Greg Ewing wrote:
There are *already* differences which make C and C++
annoyingly incompatible. One is the const char * const *
issue that appeared here.
Of course there are differences. C++ has classes, C doesn't.
C++ has function overloading, C doesn't.
C++ has assignment from char** to
OMG. Are we now adding 'const' modifiers to random places? I thought
const propagation hell was a place we were happily avoiding by not
falling for that meme. What changed?
--Guido
On 2/10/06, Jack Jansen [EMAIL PROTECTED] wrote:
I keep running into problems with the const modifications to
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OMG. Are we now adding 'const' modifiers to random places? I thought
const propagation hell was a place we were happily avoiding by not
falling for that meme. What changed?
I added some const to several API functions that take char* but
On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote:
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OMG. Are we now adding 'const' modifiers to random places? I thought
const propagation hell was a place we were happily avoiding by not
falling for that meme. What changed?
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
It looks like a solution may be to define it as const char * const *
rather than const char **. I'll see if that works.
Jeremy
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jeremy Hylton wrote:
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an
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
On 2/10/06, Martin v. Löwis [EMAIL PROTECTED] 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
[Jeremy Hylton]
...
I admit that I'm also puzzled by Jack's specific question. I don't
understand why an array passed to PyArg_ParseTupleAndKeywords() would
need to be declared as const. I observed the problem in my initial
changes but didn't think very hard about the cause of the problem.
On 2/10/06, Jeremy Hylton [EMAIL PROTECTED] wrote:
It looks like a solution may be to define it as const char * const *
rather than const char **. I'll see if that works.
No. It doesn't work. I'm not sure about this one either, but some
searching suggests that you can pass a char** to a
[Jeremy]
It looks like a solution may be to define it as const char * const *
rather than const char **. I'll see if that works.
[Jeremy]
No. It doesn't work. I'm not sure about this one either, but some
searching suggests that you can pass a char** to a function taking
const char* const*
On 2/10/06, Jeremy Hylton [EMAIL PROTECTED] 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,
which is incredibly cumbersome. After
[Jeremy]
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,
which is incredibly cumbersome. After some discussion on python-dev,
I made
On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
If he had _stuck_ to that, we wouldn't be having this discussion :-)
(that is, nobody passes string literals to
On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy]
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,
which is incredibly
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
[Tim]
If he had _stuck_ to that, we wouldn't be having this discussion :-)
(that is, nobody passes string literals to
PyArg_ParseTupleAndKeywords's kws argument).
[Jeremy]
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/10/06, Tim Peters [EMAIL PROTECTED] wrote:
[Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
If he had _stuck_ to that, we wouldn't be having this
Jeremy Hylton wrote:
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
Martin v. Löwis wrote:
FWIW, Annex D also defines these features as deprecated:
- the use of static for objects in namespace scope (AFAICT
including C file-level static variables and functions)
- C library headers (i.e. stdio.h)
Things like this are really starting to get on my groat.
It
On Fri, 10 Feb 2006 17:53:39 +0100, Thomas Wouters [EMAIL PROTECTED] wrote:
On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote:
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote:
OMG. Are we now adding 'const' modifiers to random places? I thought
const propagation hell was a
42 matches
Mail list logo
