Saturday, January 21, 2023

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

David Brown <david.brown@hesbynett.no>: Jan 21 01:06PM +0100

> something to the wrong newsgroup. But that doesn't explain Bonita's
> change of the Subject: header, nor her citation of the wrong time and
> wrong author when quoting that message.
 
I saw the same post in c.l.c++ /before/ Bonita quoted it. It had ended
up in part of a different thread (that Muttley had been involved in),
and appeared to have been posted by Muttley to recs.art.books, and
somehow had appeared in c.l.c++ as well and had a jumbled subject.
 
I assume Bonita thought Muttley posted it, because that's how it looked.
(I assumed Muttley had written it and posted it to recs.art.books, and
merely the newsgroup was mixed up by a server fault.)
 
I think that a server fault jumbled several header lines - the author,
the subject, and the newsgroups, at the very least. I can't see any
reason for suspecting Bonita is somehow intentionally behind this - it
would be completely bizarre behaviour.
 
So AFAICS this is just "undefined behaviour" in a server somewhere that
resulted in jumbled cross-posts.
Muttley@dastardlyhq.com: Jan 21 03:50PM

On Fri, 20 Jan 2023 17:21:57 -0000 (UTC)
>impersonating you (Muttley@dastardlyhq.com) with the intention of making you
>look irrational or you completely misinterpreted my posts you are quoting and
>I can't even imagine what interpretation would make your reply make sense.
 
Sorry, I obviously misread. I thought you were implying that because the
post on rec.... came from the same server as the one I used then it must have
been me who posted it.
Muttley@dastardlyhq.com: Jan 21 03:56PM

On Sat, 21 Jan 2023 13:06:09 +0100
>up in part of a different thread (that Muttley had been involved in),
>and appeared to have been posted by Muttley to recs.art.books, and
>somehow had appeared in c.l.c++ as well and had a jumbled subject.
 
I never saw it in this group, only Bonitas copy of it. I really can't see
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 assume Bonita thought Muttley posted it, because that's how it looked.
 
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.
 
>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.
Pluted Pup <plutedpup@outlook.com>: Jan 21 01:03PM -0800

On Thu, 19 Jan 2023 07:18:58 -0800, David Brown wrote:
 
> seen a few posts end up in the wrong groups today. I have no idea if
> Muttley's post is appropriate or not in rec.arts.books - I'm sure it
> makes more sense in the context of threads there.
 
The crap post was from rec.arts.books, which has for about
15 years been subject to robo-posted spam by "Ilya Shambat".
Bonita reposted the crap with a crosspost.
 
> is bigotry and has no place anywhere. I'm assuming you did not mean to
> write that way, but you should choose your words more carefully in the
> future.)
 
"Ilya Shambat" is Jewish.
 
I'm glad Object C programmers are wising up and improving
their coding by antisemitism, despite the ban on antisemitism.
"R.Wieser" <address@not.available>: Jan 21 03:28PM +0100

Hello all,
 
I'm a rather newbie to C++ programming who is trying figure out how to deal
with string pointers - or rather, with what they point at.
 
Case in point :
 
char* message = "hello world";
char* message = strdup("hello world");
 
I can user either of those in a function and return the pointer, and the
caller will be none-the-wiser which form (the static or dymnamic string) it
gets.
 
The problem is that the dynamic one needs to be "free"d but tyhe static one
not. How do I look at that "message" pointer whats "in" it so I can take
the correct action.
 
By the way: the same thing goes for when I want to replace a string. I don't
think that C++ has a garbage-collector running, so I need to do it myself.
:-)
 
Regards,
Rudy Wieser
Paavo Helde <eesnimi@osa.pri.ee>: Jan 21 04:40PM +0200

21.01.2023 16:28 R.Wieser kirjutas:
 
> I can user either of those in a function and return the pointer, and the
> caller will be none-the-wiser which form (the static or dymnamic string) it
> gets.
 
This is C++, so just return a std::string from your function, and forget
everything about C-style strings, malloc, free and strdup. Good riddance!
Bonita Montero <Bonita.Montero@gmail.com>: Jan 21 03:57PM +0100

Am 21.01.2023 um 15:40 schrieb Paavo Helde:
 
> This is C++, so just return a std::string from your function, and forget
> everything about C-style strings, malloc, free and strdup. Good riddance!
 
And local variables which are top-level variables (f.e. not part of
a pair) are implicitly move constructed. So you won't have to move
the return.
Richard Damon <Richard@Damon-Family.org>: Jan 21 10:13AM -0500

On 1/21/23 9:28 AM, R.Wieser wrote:
> :-)
 
> Regards,
> Rudy Wieser
 
There is no portable way of telling. As others have mentioned,
std:string lets you get around this problem. In a standard
implementation this will copy the static string into the heap, so
std:string knows to always delete its version.
 
In embedded applications where space may be tight, I use a replacement
version for std::string that looks where the pointer for the string is
coming from, and if it is in system flash, I know it can't change, so I
don't copy it, and inside the string class keep track of that fact.
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Jan 21 08:04AM -0800

On Saturday, 21 January 2023 at 14:28:24 UTC, R.Wieser wrote:
 
> By the way: the same thing goes for when I want to replace a string. I don't
> think that C++ has a garbage-collector running, so I need to do it myself.
> :-)
 
It's a mess, and a hangover from C. C tresats string as character 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.
 
In C++ there is a std::string. Normally when you are using C++, you should make
sure that all strings are turned into std::strings at the earliest opportunity.
Becasue of the magic of destructors, you then needn't worry about the memory the
string points to.
An std::string can be assigned like a variable. Which is frequently useful.
Assignment is relatively expensive because it tends to involve an allocation
and a copy, but it's rare for string assignment to be a time critical step.
Muttley@dastardlyhq.com: Jan 21 04:20PM

On Sat, 21 Jan 2023 16:40:20 +0200
>> gets.
 
>This is C++, so just return a std::string from your function, and forget
>everything about C-style strings, malloc, free and strdup. Good riddance!
 
Unless you want to parse the string which may involve chopping it about. Then
its simpler to use a C string and pointers rather than mess about with
inefficient substr() etc.
"R.Wieser" <address@not.available>: Jan 21 05:53PM +0100

"Richard Damon" <Richard@Damon-Family.org> wrote in message
news:KiTyL.760492$GNG9.106194@fx18.iad...
> On 1/21/23 9:28 AM, R.Wieser wrote:
 
>> char* message = "hello world";
>> char* message = strdup("hello world");
...
>> take
>> the correct action.
 
> There is no portable way of telling.
 
I was already afraid of that.
 
Regards,
Rudy Wieser
Paavo Helde <eesnimi@osa.pri.ee>: Jan 21 08:15PM +0200


> Unless you want to parse the string which may involve chopping it about. Then
> its simpler to use a C string and pointers rather than mess about with
> inefficient substr() etc.
 
If you want to speed up substring processing, then there is
std::string_view for you. As fast as plain pointers and much cleaner.
Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Jan 21 06:29PM

On 21/01/2023 14:28, R.Wieser wrote:
> :-)
 
> Regards,
> Rudy Wieser
 
As others have said - in C++ we have a string class, which would be the much preferred approach.
Also with resources generally which need to be managed (freed at some point to avoid resource leaks)
the common approach is for those resources to be represented by classes that free the resources when
they go out of scope (or earlier by calling some kind of dispose method).
 
But this doesn't really answer your question... If you had asked the question in comp.lang.c it
would be more relevant as there is no string class, and the question deserves a literal answer.
 
The answer is that the documentation for using the function in question needs to clearly specify
whether or not the caller is responsible for freeing particular resources returned by the function.
 
So perhaps the function documentation might say "Caller is responsible for freeing the returned
string, using free() function". Of course, if you're writing the called function, and want to
return some literal string, you would need to strdup() that literal string yourself, so that it can
be correctly freed by the caller. (The topic is more general than just freeing memory - calls to
the OS often return other resources like handles representing kernal objects, or GUI objects, and
sometimes those resources must be freed by the caller, and sometimes they represent pre-existing
objects owned elsewhere in the system that the caller mustn't free. The whole question of resource
ownership can be troublesome for callers, so the only answer is good documentation. Maybe function
naming conventions like create_xx() vs get_xx() etc. can help, but documentation is the key.
 
Regards,
Mike.
Bonita Montero <Bonita.Montero@gmail.com>: Jan 21 07:30PM +0100


> Unless you want to parse the string which may involve chopping it about. Then
> its simpler to use a C string and pointers rather than mess about with
> inefficient substr() etc.
 
What's wrong with sth. like this ?
 
string substr()
{
string hw( "hello world!" );
hw.erase( hw.begin(), hw.begin() + 6 );
hw.resize( 5 );
return hw;
}
"R.Wieser" <address@not.available>: Jan 21 08:09PM +0100

"Mike Terry" <news.dead.person.stones@darjeeling.plus.com> wrote in message
news:tPqdnZTbnINss1H-nZ2dnZfqnPadnZ2d@brightview.co.uk...
 
> the question deserves a literal answer.
 
Thats what I thought too.
 
> The answer is that the documentation for using the function in question
> needs to clearly specify whether or not the caller is responsible for
> freeing particular resources returned by the function.
 
My post was more in the direction that /either of/ those string types could
be returned, and I would like to create a "safe release" routine for such a
pointer.
 
> Of course, if you're writing the called function, and want to return some
> literal string, you would need to strdup() that literal string yourself,
> so that it can be correctly freed by the caller.
 
Thats good for a simple situation. I was also thinking of a string pointer
which could be initialized by the user but changed by a routine.
 
Ofcourse, the "you may only provide type 'X' there" documentation rule could
also be applied there. I was just hoping that I could create a bit more
flexibility.
 
Thanks for the well-aimed reply.
 
Regards,
Rudy Wieser
"Öö Tiib" <ootiib@hot.ee>: Jan 21 04:38AM -0800

> you try to assign a too large or negative value to a uint8_t anyway?
> Another C++17 solution looking for a problem IMO.
 
> Thanks anyway.
 
It was indeed another addition to standard library that failed.
Strictly it is enumerated variant of unsigned char (that can have more bits than 8).
Committee keeps adding features that do not satisfy any of needs in industry.
Sole bonus of std::byte was that annoying IDB of enumerated types upgraded
to UB by C++17 was made well defined at least for unsigned enums in C++20.
Muttley@dastardlyhq.com: Jan 21 04:10PM

On Sat, 21 Jan 2023 04:38:27 -0800 (PST)
>Strictly it is enumerated variant of unsigned char (that can have more bits
>than 8).
>Committee keeps adding features that do not satisfy any of needs in industry.
 
Well quite.
 
>Sole bonus of std::byte was that annoying IDB of enumerated types upgraded
>to UB by C++17 was made well defined at least for unsigned enums in C++20.
 
On a purely technical note, I assumed the definition would be rather tortuous
along the lines of:
 
enum class byte
{
a = 0,
b = 1,
:
etc
:
};
 
But in the clang header it simply does:
 
enum class byte : unsigned char {};
 
Which is new syntax to me, didn't realise you could do that. Not sure what
the curly brackets signify in this case but I learnt something new anyway.
Richard Damon <Richard@Damon-Family.org>: Jan 21 11:23AM -0500


> enum class byte : unsigned char {};
 
> Which is new syntax to me, didn't realise you could do that. Not sure what
> the curly brackets signify in this case but I learnt something new anyway.
 
The curly braces are around the enumaration values of the enum, just
like a regular enum.
 
the ": unsigned char" declares the underlying type for the enum, so it
is defined to have that specific size.
Muttley@dastardlyhq.com: Jan 21 04:34PM

On Sat, 21 Jan 2023 11:23:54 -0500
>> the curly brackets signify in this case but I learnt something new anyway.
 
>The curly braces are around the enumaration values of the enum, just
>like a regular enum.
 
Sorry, I meant what is the point of the curly brackets after "unsigned char"
in the definition. You can put identifiers between them but they seem to be
ignored and it fails to compile if you try to use them. eg:
 
fenris$ cat t.cc
enum class mybyte : unsigned char {a,b,c};
 
int main()
{
mybyte b{1};
mybyte c{a};
}
fenris$ c++ -std=c++17 t.cc
t.cc:6:11: error: use of undeclared identifier 'a'
mybyte c{a};
^
1 error generated.
fenris$
Muttley@dastardlyhq.com: Jan 21 04:40PM

On Sat, 21 Jan 2023 16:34:55 -0000 (UTC)
> ^
>1 error generated.
>fenris$
 
I realise replying to yourself is bad form but I was being thick - I needed
to qualify the identifier. This works as expected outputting 1 and 2:
 
#include <iostream>
 
enum class mybyte : unsigned char {a,b,c};
 
int main()
{
mybyte b1{1};
mybyte b2{mybyte::c};
 
std::cout << (int)b1 << ", " << (int)b2 << std::endl;
}
Richard Damon <Richard@Damon-Family.org>: Jan 21 11:46AM -0500


> Sorry, I meant what is the point of the curly brackets after "unsigned char"
> in the definition. You can put identifiers between them but they seem to be
> ignored and it fails to compile if you try to use them. eg:
 
since it is a class enum, the namespece of the labels are the enum,
 
so given
 
enum class mybyte : unsigned char { a, b, c};
 
you can do
 
mybyte b(mybyte::a);
 
Sebastian Nibisz <snibisz@gmail.com>: Jan 20 05:56PM -0800

piątek, 20 stycznia 2023 o 21:26:27 UTC+1 Chris M. Thomasson napisał(a):
> were invented by Joe Seigh, a friend of mine from long ago over on
> comp.programming.threads. I did one a while back:
 
> https://groups.google.com/g/comp.lang.c++/c/FBqOMvqWpR4/m/gfFd4J2GBAAJ
I don't know this thread. I will read.
Sebastian Nibisz <snibisz@gmail.com>: Jan 20 05:56PM -0800

piątek, 20 stycznia 2023 o 21:39:26 UTC+1 Chris M. Thomasson napisał(a):
> > Performance is close to RCU for reads and better for writes. Atomic reads and writes are much faster. Pointer construction is slower, but this time is amortized by other operations.
> I am assuming that your work can allow one to create a lock-free stack
> without having to worry about the ABA problem. Is that correct?
Yes.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 20 06:01PM -0800

On 1/20/2023 5:56 PM, Sebastian Nibisz wrote:
>> I am assuming that your work can allow one to create a lock-free stack
>> without having to worry about the ABA problem. Is that correct?
> Yes.
 
Great: I need to find some time to study up on your work! Well done.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jan 20 07:18PM -0800

On 1/20/2023 12:39 PM, Chris M. Thomasson wrote:
>> this time is amortized by other operations.
 
> I am assuming that your work can allow one to create a lock-free stack
> without having to worry about the ABA problem. Is that correct?
 
I am of course referring to allocating and freeing a node. ABA can still
bite somebody in the posterior if they reuse nodes outside of a
collector. It's not in our realm then. If a user reuses nodes outside of
the system, ABA is there.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)