Saturday, September 24, 2022

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

JiiPee <kerrttuPoistaTama11@gmail.com>: Sep 24 08:22PM +0300

I have done C++ since 1997. I personally do not understand why use C if
C++ is extented C and has more in it (and thats why I immediately
swiched from C to C++ when I found C++).
 
But language-fight aside :) .. I have a serious/honest question:
What is the best way to represend a string in C language? How do best C
programmers represend a string?
 
Because I am worried that that the length of the string is not
"protected" as there is no private in C language.
 
In C++ it is well protected and safe something like this:
 
class String {
// all access functions
 
private:
int m_lenght;
};
 
So, it is basically impossible to have a wrong lenght value for a string.
Am I right that C programmers do it something like:
 
struct String {
char* data;
int lenght;
};
 
but obviously somebody might put: lenght = 99999999999, and then its
going bad....
 
How do C programmers make string safe that the above problem does not
occur (that the lenght of the string goes wrong)?
Bo Persson <bo@bo-persson.se>: Sep 24 09:00PM +0200

On 2022-09-24 at 19:22, JiiPee wrote:
> going bad....
 
> How do C programmers make string safe that the above problem does not
> occur (that the lenght of the string goes wrong)?
 
By not storing the length separately? You just have to call strlen each
time you need to know the length.
Gawr Gura <gawrgura@mail.hololive.com>: Sep 24 12:29PM -0700

On 9/24/22 10:22, JiiPee wrote:
> going bad....
 
> How do C programmers make string safe that the above problem does not
> occur (that the lenght of the string goes wrong)?
 
In C, if you really want to protect data from someone else mishandling
it then you can use an opaque type. In a header you would write:
 
struct string;
 
struct string* create_string(const char *const data);
void destroy_string(struct string *const str);
size_t get_string_length(const struct string *const str);
/* etc. */
 
In the corresponding source file you would define struct string.
Consumers of the header file don't know the structure of struct string
so they are required to access it through the provided procedures rather
than directly manipulating it.
 
I think that this kind of protection is often unnecessary though. Access
modifiers in C++ help keep things sane but they don't provide any real
guarantee against outside manipulation. If someone really wants to
modify your object they can always convert it to a char array and fiddle
with it.
Paavo Helde <eesnimi@osa.pri.ee>: Sep 24 11:04PM +0300

24.09.2022 20:22 JiiPee kirjutas:
> };
 
> but obviously somebody might put: lenght = 99999999999, and then its
> going bad....
 
In most C code I have seen there has been no attempt to store the string
length separately. It's just a char array, when you need the string
length you call strlen().
 
If there is a C struct encapsulating the string and its length, in
well-written C code it should be only manipulated via dedicated access
functions, never directly. The C programmers are trusted to follow such
rules.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 01:25PM +0200

Am 22.09.2022 um 11:41 schrieb Juha Nieminen:
> that honestly too much to type?)
 
> At least their string type is named "String". I wouldn't have been
> surprised if it had been "Str". Must have been a lapsus.
 
If that are your arguments against a lanuage - don't program at all.
David Brown <david.brown@hesbynett.no>: Sep 24 05:05PM +0200

On 23/09/2022 16:21, Ralf Goertz wrote:
>>> surprise "-O6":
 
>> Anything higher than -O3 is the same as -O3 in gcc.
 
> Oh okay. I don't know where I got the idea that 6 was the maximum.
 
I've seen other compilers that go up to -O6. gcc has taken the path of
having explicit control flags for different optimisations, for those
that want more control, rather than having many levels. After all, as
you have seen, a higher numerical level does not always relate well to
higher speeds.
 
>> tuning options.
 
> -march=native makes "-O2" a little bit slower and "-O3" a little bit
> faster but the former is still 11% faster.
 
Interesting. "-march=native" usually makes things faster (or smaller) -
rarely slower. Maybe your processor is newer than your compiler, so it
doesn't really know about the details. Or maybe you were just unlucky.
 
If you see particular slowdown effects and poor code, and it is the same
even with relatively current gcc versions, you can always report it.
Missed or poor optimisation issues are not often the highest prioritised
issues for gcc development (unlike incorrect code bugs), but the
developers like to have them in the bugzilla list. It makes it easier
to see when an issue is affecting many people. (If you want to look at
the generated code with different gcc versions and different compiler
options, <https://godbolt.org> is your website of choice.)
 
> Thanks for your explanations.
 
No problem.
red floyd <no.spam.here@its.invalid>: Sep 24 12:33PM -0700

On 9/24/2022 8:05 AM, David Brown wrote:
 
> that want more control, rather than having many levels.  After all, as
> you have seen, a higher numerical level does not always relate well to
> higher speeds.
 
I understand that the Spinal Tap compiler, written by Nigel Tufnel, goes
up to 11.
ram@zedat.fu-berlin.de (Stefan Ram): Sep 24 07:16PM

>How do C programmers make string safe that the above problem does not
>occur (that the lenght of the string goes wrong)?
 
C programmers are in comp.lang.c.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 11:38AM +0200

Am 21.09.2022 um 22:23 schrieb Andrey Tarasevich:
> support.
 
> https://stackoverflow.com/questions/2886931/difference-fixed-width-strings-and-zero-terminated-strings
 
> It has never been intended for use with zero-terminated strings.
 
The problem with that is that you can't pass a string copied like that
reliably to any C-API that requires a null-terminated string. It would
have been better if strncpy() would always return a null-terminated
string, thereby making the last character zero if necessary.
For me this API rather looks mostly useless.
Muttley@dastardlyhq.com: Sep 24 09:43AM

On Sat, 24 Sep 2022 11:38:28 +0200
>have been better if strncpy() would always return a null-terminated
>string, thereby making the last character zero if necessary.
>For me this API rather looks mostly useless.
 
The C strings API is also inconsistent because snprintf() always adds a
terminating null whether the arguments fit into the string or not.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 11:59AM +0200

>> For me this API rather looks mostly useless.
 
> The C strings API is also inconsistent because snprintf() always adds
> a terminating null whether the arguments fit into the string or not.
 
I don't consider this inconsistent because one API is unusable,
thereby almost non-existing.
Richard Damon <Richard@Damon-Family.org>: Sep 24 06:27AM -0400

On 9/24/22 5:38 AM, Bonita Montero wrote:
> have been better if strncpy() would always return a null-terminated
> string, thereby making the last character zero if necessary.
> For me this API rather looks mostly useless.
 
And that is because strncpy wasn't intended to create a "C-API" string,
but to fill a char[N] field in a struct.
 
There were many spots those existed without a required terminating NULL.
David Brown <david.brown@hesbynett.no>: Sep 24 04:22PM +0200

On 23/09/2022 16:03, Bonita Montero wrote:
 
>> No.
 
> If you use non-native types with atomics they use STM, and that's
> really slow. That's while no one uses atomic for non-native types.
 
There are a number of ways to implement atomics that are larger than a
single bus operation can handle, or that involve multiple bus
operations. Different processor types have different solutions, and
some are optimised or limited to particular setups (such as single
writer, single processor, etc.). Some processors can handle atomic
accesses for sizes that are bigger than native C/C++ types (such as
128-bit accesses). Some cannot handle atomic writes for the bigger
native types.
 
And non-aligned accesses might be supported for volatile accesses, while
not being atomic.
 
In summary - you are making so many assumptions it is easiest just to
say you are wrong.
 
 
 
>> They /do/ work - they just do what they are supposed to do, not what
>> you think they should do.
 
> No, they have actually no effect.
 
Perhaps some of your misconceptions are valid within your limited little
world of x86 programming on Windows with MSVC. There is a wider world
out there, and even if you never enter it, please stop making posts in a
general C++ newsgroup full of invalid assumptions that only applies to
such a limited subset of C++.
David Brown <david.brown@hesbynett.no>: Sep 24 04:25PM +0200

On 23/09/2022 19:52, Philipp Klaus Krause wrote:
 
>> There are no volatile versions which could be used to ensure that
>> something like an "memset" to wipe memory would actually be run.
> Are you looking for C23 memset_explicit?
 
Yes - although I'd forgotten the name. It will certainly solve one of
the functions I see as missing.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 04:25PM +0200

Am 24.09.2022 um 16:22 schrieb David Brown:
 
> There are a number of ways to implement atomics that are larger than
> a single bus operation can handle, or that involve multiple bus
> operations. ...
 
It's always done by STM, and that's slow.
 
> out there, and even if you never enter it, please stop making posts in a
> general C++ newsgroup full of invalid assumptions that only applies to
> such a limited subset of C++.
 
I was referring to what you said and you forgot what you said.
David Brown <david.brown@hesbynett.no>: Sep 24 05:09PM +0200

On 24/09/2022 16:25, Bonita Montero wrote:
>> a  single bus operation can handle, or that involve multiple bus
>> operations. ...
 
> It's always done by STM, and that's slow.
 
No, it is not. You really have no idea about these things - repeating
yourself does not make it any less myopic. I think I'm done trying to
explain them to you.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 05:14PM +0200

Am 24.09.2022 um 17:09 schrieb David Brown:
>>> operations. ...
 
>> It's always done by STM, and that's slow.
 
> No, it is not. ...
 
I checked the disassembly of atomics beyond native types with
MSVC, clang Windows / Linux and g++ - you don't.
If you don't use STM you use the kernel and the atomic operation
never fails. Try that out yourself: atomics beyond native types
can fail, so you have STM.
Keith Thompson <Keith.S.Thompson+u@gmail.com>: Sep 24 11:53AM -0700

Richard Damon <Richard@Damon-Family.org> writes:
[...]
> And that is because strncpy wasn't intended to create a "C-API"
> string, but to fill a char[N] field in a struct.
 
> There were many spots those existed without a required terminating NULL.
 
NUL, null, null character, or '\0', not NULL (which is a null pointer
constant).
 
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 08:58PM +0200

Am 24.09.2022 um 20:53 schrieb Keith Thompson:
 
>> There were many spots those existed without a required terminating NULL.
 
> NUL, null, null character, or '\0', not NULL (which is a null pointer
> constant).
 
I woudln't have understood Richard without your help.
olcott <polcott2@gmail.com>: Sep 24 08:29AM -0500

On 9/24/2022 7:45 AM, Mr Flibble wrote:
 
> (N.B. I will continue to boast about this important original solution
> to the halting problem until all of you stop engaging with Olcott and
> his non-solution to the halting problem.)
If my rebuttal to the halting problem proofs was incorrect then at least
one person could correctly point out an error. So far no one has done
that. Many people did point out their own false assumptions though.
 
> std::cout << "Input halts: " << H(P, P) << std::endl;
> }
 
> When the simulator detects the call to H in P
 
This violates my copyright and would not work because you copied my idea
incorrectly. H could detect a call to itself in P that does not have P
as its input. This P could terminate normally.
 
 
> Thoughts? I am probably missing something obvious as my idea
> appears to refute [Strachey 1965] and associated HP proofs which
> great minds have mulled over for decades.
 
It violates my copyright and would not work because you copied my work
incorrectly.
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
olcott <polcott2@gmail.com>: Sep 24 12:46PM -0500

On 9/24/2022 12:02 PM, Mr Flibble wrote:
>>> infinite_loop: goto infinite_loop;
>>> return;
>>> }
 
 
*Here is a copy of my function dating back before any of your versions*
 
On 4/15/2022 1:33 PM, olcott wrote:
> if (H(x, x)) //
> HERE: goto HERE;
> }
 
(a) Three of the names are identical.
(b) The structure is identical.
(c) You added the same "return" instruction that I added.
(d) You converted the u32 x parameter to void function pointer as I have.
 
You copied my work verbatim, then applied the exact same adaptations to
my work that I applied, and only changed the name of the loop.
 
*A court of law would construe this as copyright violation*
*Cease and desist violating my copyright*
 
--
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer
Manfred <noname@add.invalid>: Sep 24 04:24PM +0200

On 9/10/2022 7:04 PM, Scott Lurndal wrote:
 
>> C is a good language to learn programming
>> but actually not to solve real tasks.
 
> I think you have that backwards. Really.
 
Definitely.
Manfred <noname@add.invalid>: Sep 24 04:31PM +0200

On 9/12/2022 12:05 PM, Bo Persson wrote:
 
>> That's a function that returns a my_class object.
 
> It's a function only if x is a type. But x is a value, like in the int
> case, so it is a constructor call.
 
Ironically, I think this kind of proves the case.
 
 
> struct my_class f;
> init(&f, x);
 
> And now it is suddenly obvious EXACTLY what happens?  :-)
 
:)
gazelle@shell.xmission.com (Kenny McCormack): Sep 24 03:54PM

In article <tgn3v7$1ui4$1@gioia.aioe.org>, Manfred <noname@add.invalid> wrote:
...
>>> but actually not to solve real tasks.
 
>> I think you have that backwards. Really.
 
>Definitely.
 
Normally, one would assume that the first text quoted above was just a typo
or a cut-and-paste error or something like that.
 
But you should note who wrote it. Bonita is an unabashed C++ promoter and C
basher (and general, all around, lunatic). It was intended as written.
 
--
"The party of Lincoln has become the party of John Wilkes Booth."
 
- Carlos Alazraqui -
Bonita Montero <Bonita.Montero@gmail.com>: Sep 24 06:07PM +0200

Am 24.09.2022 um 17:54 schrieb Kenny McCormack:
> or a cut-and-paste error or something like that.
 
> But you should note who wrote it. Bonita is an unabashed C++ promoter and C
> basher (and general, all around, lunatic). It was intended as written.
 
C is an outdated language. It's much likely to make mistakes with C than
with C++ or Rust f.e. and you have a magnitude more work to do the same
thing.
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)