| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 22 03:28PM -0500 On 1/22/23 06:17, jak wrote: > Il 22/01/2023 11:20, James Kuyper ha scritto: ... > array that contains a string, perhaps. You argue a lot about the > definitions contained in the "ISO", perhaps the writers should be > convinced to use greater precision. ISO is the International Standards Organization. They are responsible for defining the C language. Terms defined in that standard are specialized jargon whose meaning, in the context of C, might differ from what you'd expect if you made the mistake of parsing them as ordinary English words - that is the purpose of defining such jargon, to provide more precise and slightly different definitions than ordinary English might provide. In the context of the C standard, those definitions are authoritative. In that context, how do you think that definition fails to be sufficiently precise? Can you give an example of a case where you might imagine that it's ambiguous whether or not the definition applies? |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 22 03:39PM -0500 On 1/22/23 07:23, jak wrote: > Il 22/01/2023 12:29, Bo Persson ha scritto: ... > ISO standard can cancel that definition because the C does not have > strings but only an agreement that allows the functions to use array as > strings. C has strings, because the C standard provides a definition of what a C string is. It's not a data type as you might expect from using other languages. In C, it's only a data storage format recognized by many C standard library functions, and as such defining it is the very first sentence in the section defining the C standard library: "A string is a contiguous sequence of characters terminated by and including the first null character." (7.1.1p1) The previously referenced definition of a "pointer to a string" occurs shortly thereafter. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 22 03:47PM -0500 On 1/22/23 06:27, R.Wieser wrote: > stored in ? > ... it often confuses the h*ll outof me when the word "stringpointer" is > used for both. :-\ C doesn't have a string type, just a data storage format for strings that is recognized by many standard library functions. Since there is no string type, there's no specific pointer type that is used for storing such pointers. Any pointer type might point at the first character of a string, but the most useful types for such pointers are those that can be passed to or or used to store the value returned from those library functions without requiring an explicit conversion. Those functions generally take arguments and/or return values of char* or const char* types. I don't remember if there are any that use unsigned char rather than char, but it would be possible. Other useful types would be [const] void*, which in C (unlike C++) allows implicit conversions to and from [const] char*. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 22 01:07PM -0800 >> variable > You know that, I know that. But listening to people talking about both > using the same "string pointer" name I have to wonder if they do ... If I understand you correctly, the two things you're referring to are the pointer *value* and an *object* of pointer type that holds that value. There's nothing special about pointers to strings here. The same confusion occurs with, for example, a pointer to an int (which is convenient, because we can discuss this without dragging C into the discussion). int n = 42; int* ptr = &n; The result of evaluating the expression `&n`, or the expression `ptr`, is a value of type `int*`. We commonly refer to this value as "a pointer" (or "an address"). The object named `ptr` is an object (variable) of type `int*`. We also commonly refer to this object as "a pointer" (though not as "an address"). Similarly we can refer either to `42` or to the object `n` as "an integer" or "an int". Usually this isn't a problem. In most contexts, the distinction between a value of some type and an object/variable that holds a value of some type either isn't important or is sufficiently clear from the context. For cases where the ambiguity is important, I find it useful to think of the word "pointer" (as well as "array", "integer", etc.) as an adjective rather than a noun. Thus we can refer to a *pointer value*, or a *pointer object", or a *pointer type*, or a *pointer expression*, all of which are clearly distinct concepts. I'll note that the C and C++ standards often do not use this level of precision (and in most cases they probably don't need to). <OT> For C's definition of a "pointer to a string", I'd say it refers to a *value* of pointer type. An object of type char* might have a current value that is a pointer to a string, but then after a value is assigned to it it might not. The state of being a "pointer to a string" applies to the value, not to the object that currently happens to hold such a value. I don't recall seeing a use of the term "pointer to a string" that was confusing because it could refer to either a value or an object. </OT> -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 21 03:52PM -0800 On 5/12/2022 12:16 PM, Chris M. Thomasson wrote: > Using my experimental vector field to generate a fractal formation. Here > is generation two: > https://fractalforums.org/gallery/1612-120522191048.png Just a test of the current state of my fractal system... https://fractalforums.org/gallery/1612-210123234637.png C++ is great! :^) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment