Sunday, January 22, 2023

Digest for comp.lang.c++@googlegroups.com - 25 updates in 2 topics

Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 21 04:54PM -0800

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> It's a mess, and a hangover from C. C tresats string as character pointers,
 
No, a C string is by definition "a contiguous sequence of characters
terminated by and including the first null character". It is not a
pointer.
 
A *pointer to a string* is by definition "a pointer to its initial
(lowest addressed) character". Most manipulation of strings in C is
done via string pointers.
 
> and doesn't give you an easy way to tell if they are allocated on the heap, on
> the stack, or in read-only memory. So the C programmer has to be careful.
 
Right.
 
--
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 */
jak <nospam@please.ty>: Jan 22 10:46AM +0100

Il 22/01/2023 01:54, Keith Thompson ha scritto:
 
>> and doesn't give you an easy way to tell if they are allocated on the heap, on
>> the stack, or in read-only memory. So the C programmer has to be careful.
 
> Right.
 
pointer to a string? by definition? string pointers? Maybe you are
confusing programming languages. The C language has no string pointers.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jan 22 05:20AM -0500

On 1/22/23 04:46, jak wrote:
> Il 22/01/2023 01:54, Keith Thompson ha scritto:
...
>> A *pointer to a string* is by definition "a pointer to its initial
>> (lowest addressed) character". Most manipulation of strings in C is
>> done via string pointers.
...> pointer to a string? by definition? string pointers? Maybe you are
> confusing programming languages. The C language has no string pointers.
 
When he said "by definition", he meant it:
 
"A _pointer to a string_ is a pointer to its initial (lowest addressed)
character." (C standard (n2731) 7.1.1p1).
 
The phrase "pointer to a string" is in italics, an ISO convention
indicating that the sentence in which that phrase occurs constitutes the
official definition of the meaning of that term.
jak <nospam@please.ty>: Jan 22 12:17PM +0100

Il 22/01/2023 11:20, James Kuyper ha scritto:
 
> When he said "by definition", he meant it:
 
> "A _pointer to a string_ is a pointer to its initial (lowest addressed)
> character." (C standard (n2731) 7.1.1p1).
 
"pointer to a string" could be a pointer at the first element of an
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.
 
"R.Wieser" <address@not.available>: Jan 22 10:52AM +0100

"Richard Damon" <Richard@Damon-Family.org> wrote in message
news:bSYyL.44734$%os8.15496@fx03.iad...
> On 1/21/23 2:09 PM, R.Wieser wrote:
 
> So the "string pointer" type you are thinking of needs to be told, and
> remember the answer to the question, "Does this memory need to be freed?"
 
Its unclear to me which "string pointer" you are referring to there : the
result of the strdup() function, or the "char* message" variable it is
stored in.
 
But yes, that is pretty much what I was asking about - with the "being told"
part done by the programming language. With me just checking what it was
told.
 
Regards,
Rudy Wieser
"R.Wieser" <address@not.available>: Jan 22 11:56AM +0100

"Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in message
news:OtycnbSNHJxJ_1H-nZ2dnZfqnPudnZ2d@brightview.co.uk...
 
> A noble aim, but... the C++ and C language raw pointers are basically just
> "pointers to type xxx" They don't encapsulate how to free referenced
> resource(s).
 
:-) That was what I tried to get clear : if perhaps the current iteration of
the language perhaps had such a ... something. An "I'm static" bitflag would
have been enough for my purposes.
 
> You could analyse the pointer value and try to work out what region of
> memory it belongs to, but that will be non-portable and too much to
> reasonably ask, I'd say.
 
Athough I currently am way to much of a novice in the language that might
actually be something I would try - even if just to show myself that it
isn't a good idea.
 
> Simple is good, unless simple doesn't work! :)
 
Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It
Simple, Stupid") and I quite agree with.
 
> Looking at the std::string class, that addresses the "initialized by the
> user but changed by a routine" bit of the problem, which I'll suggest is
> 99% of the benefit you're after. [Pass strings as std::string& ]
 
Using the "document the function!" method you mentioned earlier I could also
tell the user that only dynamic strings are permitted as input.
 
> It could be addresed with the approach of embellished pointers.
 
I'm sorry, but currently I have absolutily /no idea/ what those are.
 
> (RPC) framework has to solve this issue because the calling and called
> routines typically are in different address spaces with no shared memory,
> and it's far from trivial!
 
You mean marshalling ? I had to do that in Windows (using my preferred
language, Assembly) when I tried to retrieve some data from a control on a
dialog that was part of another process - which included having to "remote
allocate" some memory to copy to/from.
 
> The problem is that C/C++ language in itself does not sufficiently
> describe pointer use to make this possible.
 
As above, thart was what I needed to make sure of - before I started to try
to create all kinds of complex-y solutions that would not be needed.
 
> E.g. a pointer could be a REF pointer to a single struct, or to an array,
> and structs can chain to other structs, possibly involving loops of
> pointers, or at least having multiple pointers to a single struct.
 
Hey ! I was trying to keep it simple ! :-)
 
But yes, I was thinking in the same direction. In my case I wanted to
provide and/or return the string as part of a structure. The structure
could be dynamic too, meaning that before the structure would be destroyed
all of the strings in it need to be destroyed first.
 
> But if you just want to provide one C-style API for one function with a
> modifiable IN/OUT parameter, just do something like:
 
> int AmendString (/*INOUT*/ char** ppString);
 
Ehhrrmm... I didn't even realize that I needed that notation. I skipped it
that specific notation by having the string pointer "hidden" in a structure.
 
> and clearly document callers responsibity, including how the string memory
> must initially be allocated by the caller, and how it must eventually be
> freed upon return.
 
Agreed.
 
The only problem is that my user is rather stupid. I'm not sure if I'm, at
some time in the future, will be able to use the function I wrote myself
without fouling up and wondering whatever I was thinking of when I wrote it.
:-)
 
Thanks for the explanation.
 
Regards,
Rudy Wieser
"R.Wieser" <address@not.available>: Jan 22 12:27PM +0100

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a62bie22.fsf@nosuchdomain.example.com...
 
> A *pointer to a string* is by definition "a pointer to its initial
> (lowest addressed) character".
 
To disambiguate :
 
Assuming that a "pointer to a string" is something a function like strdup()
returns, what do you call the (type of) variable that such a result is
stored in ?
 
... it often confuses the h*ll outof me when the word "stringpointer" is
used for both. :-\
 
 
Regards,
Rudy Wieser
Bo Persson <bo@bo-persson.se>: Jan 22 12:29PM +0100

On 2023-01-22 at 12:17, jak wrote:
>> character." (C standard (n2731) 7.1.1p1).
 
> "pointer to a string" could be a pointer at the first element of an
> array that contains a string, perhaps.
 
No, not "perhaps", but definitely. The term "pointer to a string" IS a
pointer to the first element of an array that contains a string. That's
what it says.
 
There are other pointers that can point to a char that is not part of a
string. Those are then not "pointer to a string".
"Öö Tiib" <ootiib@hot.ee>: Jan 22 03:42AM -0800

On Sunday, 22 January 2023 at 13:28:00 UTC+2, R.Wieser wrote:
> stored in ?
 
> ... it often confuses the h*ll outof me when the word "stringpointer" is
> used for both. :-\
 
A pointer to a string is (constrained in described way) pointer to a
character. So variable has to be of type pointer to a character.
jak <nospam@please.ty>: Jan 22 01:23PM +0100

Il 22/01/2023 12:29, Bo Persson ha scritto:
> what it says.
 
> There are other pointers that can point to a char that is not part of a
> string. Those are then not "pointer to a string".
 
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.
Paavo Helde <eesnimi@osa.pri.ee>: Jan 22 02:31PM +0200

22.01.2023 12:56 R.Wieser kirjutas:
 
> Athough I currently am way to much of a novice in the language that might
> actually be something I would try - even if just to show myself that it
> isn't a good idea
 
This is basically impossible. Yes, maybe you can tell on some platform
if a string pointer points to some address in the heap, stack or a
global static area. Alas, even if it points to heap, you still won't
know if you may or must call free() on the pointer. The string might be
allocated globally and meant to be in shared use for longer, or the
string might be a part of another data structure which your code doesn't
even know how to deallocate.
 
So it's not just a bad idea, but impossible, unless you want to severely
cripple the ways how strings may be used in your program.
 
 
>> Simple is good, unless simple doesn't work! :)
 
> Thats something I know as "KISS" ("Keep It Stupidly Simple" / "Keep It
> Simple, Stupid") and I quite agree with.
 
If you want to keep it simple, then just use C++ std::string, you can't
get simpler than that, unless switching over to Python(*) or something.
 
(*) Some might claim Python strings are actually more complicated than
in C++ because of codepage/unicode nuances, Python 2 / Python 3
differences, and hidden performance gotchas, e.g. the computational
complexity of Python string += operation is worse in Python than in C++.
Paavo Helde <eesnimi@osa.pri.ee>: Jan 22 02:53PM +0200

22.01.2023 14:23 jak kirjutas:
 
> 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.
 
ISO standard defines what C is or is not. It's not up to a random
internet commenter.
 
Of course ISO standard committee can change the wording in the next
version. If they do this and drop the definition of the term "pointer to
a string" from the next C standard, then C will not have such thing any
more. But until then it does.
David Brown <david.brown@hesbynett.no>: Jan 22 03:31PM +0100

On 22/01/2023 12:42, Öö Tiib wrote:
>> used for both. :-\
 
> A pointer to a string is (constrained in described way) pointer to a
> character. So variable has to be of type pointer to a character.
 
Exactly.
 
A "string" is "a contiguous sequence of characters terminated by and
including the first null character", as defined by the C standards and
therefore by C (for those that don't understand how the language is
defined).
 
So a "pointer to a string" is also a "pointer to character", though
pointers to characters do not necessarily point to strings. And since
there is no specific type for a "string" in C, you use "pointer to
character" types to hold "pointer to string" values.
"R.Wieser" <address@not.available>: Jan 22 03:57PM +0100

"Paavo Helde" <eesnimi@osa.pri.ee> wrote in message
news:tqjaaa$33tcp$1@dont-email.me...
>> Simple, Stupid") and I quite agree with.
 
> If you want to keep it simple, then just use C++ std::string, you can't
> get simpler than that, unless switching over to Python(*) or something.
 
I'll keep that in mind. Heck, I might even go and take a look at it some
time. :-)
 
Regards,
Rudy Wieser
"R.Wieser" <address@not.available>: Jan 22 03:40PM +0100

"嘱 Tiib" <ootiib@hot.ee> wrote in message
news:604d1f9c-51b9-4e7d-9c69-25b235a0eb5en@googlegroups.com...
>> used for both. :-\
 
> A pointer to a string is (constrained in described way) pointer to a
> character. So variable has to be of type pointer to a character.
 
Thats not what I ment. If an address which is pointing to a sequence of
characters is called a "pointer to a string" - normally referred to as "a
string pointer" - , what should the variable which stores that addres be
called ?
 
Regards,
Rudy Wieser
jak <nospam@please.ty>: Jan 22 07:04PM +0100

Il 22/01/2023 13:53, Paavo Helde ha scritto:
> version. If they do this and drop the definition of the term "pointer to
> a string" from the next C standard, then C will not have such thing any
> more. But until then it does.
 
The comments are feedback. Feedback helps. Faith sometimes kills.
jak <nospam@please.ty>: Jan 22 07:16PM +0100

Il 22/01/2023 19:04, jak ha scritto:
>> to a string" from the next C standard, then C will not have such thing
>> any more. But until then it does.
 
> The comments are feedback. Feedback helps. Faith sometimes kills.
 
... I thought about what happens in the Middle East. Faith is faith and
the laws are laws but what is written is not always right.
Richard Damon <Richard@Damon-Family.org>: Jan 22 01:24PM -0500

On 1/22/23 9:40 AM, R.Wieser wrote:
> called ?
 
> Regards,
> Rudy Wieser
 
A pointer to string (with type pointer to char).
 
Just like an int value (like 5) is the value of a given bit combination,
a variable that holds such a value is also called an int.
 
If you need to distinguish them, one is a value, and the other is a
variable (or object)
Richard Damon <Richard@Damon-Family.org>: Jan 22 01:24PM -0500

On 1/22/23 7:23 AM, jak wrote:
 
> 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.
 
Excpet that it DOES have strings, as defined in &.1.1p1
 
A string is a contiguous sequence of characters terminated by and
including the first null character.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 22 10:57AM -0800

> stored in ?
 
> ... it often confuses the h*ll outof me when the word "stringpointer" is
> used for both. :-\
 
Note that we're talking about C; C++, the topic of this newsgroup, is a
related but distinct language.
 
What C calls a "string" is very close to (probably identical to) what
C++ calls a "null-terminated byte string", or NTBS. The informal term
"C-style string" is common, to distinguish it from C++'s std::string.
 
In C, there is no string type (unless you define one yourself). The
language-defined term "string" is used to refer to a data format, not a
data type. An object of type "array of char" may or may not contain a
string (or multiple strings).
 
The C term "pointer to a string" is not analogous to, for example,
"pointer to an int". It is a language-defined phrase because the term
"pointer to a string" either would not make sense or would have a
different meaning in the absence of that definition. A pointer to a
string points to the initial (0th) element of the string, and can be
used via array arithmetic, indexing, and calls to library functions to
manipulate the string.
 
An object containing a *pointer to a string* is normally of type char*
or const char*.
 
Everything that can be done in C using C-style strings and C-style
string pointers can be done the same way in C++, but it's almost
always easier and safer to use std::string.
 
To answer your original question, given a char* value (say, a function
parameter), neither C nor C++ gives you a way to determine how the
memory it points to was allocated, and therefore how and whether it
should be deallocated. If you want to pass pointers around and let the
called function decide whether and how to deallocate it, you'll have to
pass that information somehow, probably as another argument or by
wrapping the pointer in a structure or class. Note also that memory
allocated by malloc() should be deallocated by calling free(), and
memory allocated by new should be deallocated by delete; mixing the two,
IIRC, has undefined behavior.
 
But again, std::string takes care of all of this for you.
 
--
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 */
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 22 11:00AM -0800


> 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.
 
That is both off-topic and incorrect.
 
C does not have a string type. C certainly does have strings. The
definition is quoted above.
 
The C standard makes extensive use of the term "string", particularly in
the library section. The meaning is clear and unambiguous. Removing
the definition from the language would require a great deal of work to
update the standard, and would have no benefit.
 
--
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 */
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Jan 22 11:46AM -0800

On Sunday, 22 January 2023 at 18:24:38 UTC, Richard Damon wrote:
> a variable that holds such a value is also called an int.
 
> If you need to distinguish them, one is a value, and the other is a
> variable (or object)
 
The snag is that C has no way of resolving the problem that a string has
an unknown number of bytes.
So
char *stringpointer;
*stringpointer = "foo";
 
Won't work. Unlike a pointer to a numerical type.
 
In C++, the std::string manages memory internally, so you can have this convenience.
The cost is that you lose control of the run time operations used to manage the
memory.
"R.Wieser" <address@not.available>: Jan 22 09:23PM +0100

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:875ycyiehv.fsf@nosuchdomain.example.com...
> function parameter), neither C nor C++ gives you a way to determine
> how the memory it points to was allocated, and therefore how and
> whether it should be deallocated.
 
I already assumed as much, but as I'm a novice in regard to the language I
had to make sure.
 
Who knows, maybe what we all have been referring to as "a pointer to a
string" is actually an object carrying a number of attributes and a
deconstructor too. :-)
 
Regards,
Rudy Wieser
"R.Wieser" <address@not.available>: Jan 22 09:16PM +0100

"Richard Damon" <Richard@Damon-Family.org> wrote in message
news:sbfzL.383809$iU59.50359@fx14.iad...
>> "pointer to a string" - normally referred to as "a string pointer" - ,
>> what should the variable which stores that addres be called ?
 
> A pointer to string (with type pointer to char).
 
Yep. Both referred to with the exact same name. And that confuses the h*ll
outof someone who has to listen to someone talking about two different
things, but uses the same word for both. :-(
 
Why do you think I asked ?
 
> If you need to distinguish them, one is a value, and the other is a
> 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 ...
 
Regards,
Rudy Wieser
David Brown <david.brown@hesbynett.no>: Jan 22 01:33PM +0100

> how Bonita could reply to a post that clearly wasn't from me in a totally
> unrelated group which somehow ends up quoting me and being coincidentally
> crossposted to comp.lang.c++.
 
I will say it again - it appears to be the result of a server glitch.
It may only have been visible in one server, it may have been passed on
to some other servers but not all servers. Some people (such as myself,
and Bonita) saw the original broken and header-jumbled cross post.
Others did not. Bonita replied to this mistaken cross-post, thinking it
was real. It is not actually that hard to understand, and does not need
paranoia or conspiracy theories as an explanation.
 
 
> I'm afraid I don't. I think he/she/it/whatever either did it on purpose or
> someone hacked her account. The fact that she's vanished from this group for
> a few days when she normally never stays away is rather telling.
 
Please stop.
 
Look, I know that both you and Bonita rub people the wrong way
sometimes, and you seem to have a particular dislike for each other.
But trust me on this, you are not that important. No one - not Bonita,
not anyone else - is going to hack a Usenet server to make a fake
cross-post to somehow pretend to be /you/. Hacking servers is a lot of
effort, as is writing a post like that one - even if Bonita doesn't like
you, you are not worth that much effort.
 
>> reason for suspecting Bonita is somehow intentionally behind this - it
>> would be completely bizarre behaviour.
 
> Well, I wouldn't say she's entirely rational sometimes.
 
She's not an idiot either.
 
It's unpleasant when people assume you have written something that you
did not write - whether it is due to a technical fault or intentional
behaviour. But do not fall for paranoia. Anyone here who doesn't like
you or doesn't like your posts will either ignore you, or say directly
what they dislike. And do not make matters worse by accusing Bonita of
doing things she clearly did not do - it is not any better for her to be
accused of writing the weird post than it is for /you/ to be accused of it.
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: