niedziela, 23 lipca 2023 o 14:03:42 UTC+2 fir napisał(a):
> niedziela, 23 lipca 2023 o 13:44:05 UTC+2 Bonita Montero napisał(a):
> > Am 23.07.2023 um 09:52 schrieb fir:
> > > niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
> > >> Am 22.07.2023 um 23:07 schrieb fir:
> > >>
> > >>> sure as efficient as possinle, what with i once give example of how this pony fast is
> > >> Why should you have given such an example ? You're not aware
> > >> what C++ does for you because you don't unterstand the language.
> > >
> > >
> > > it is counter example for your belifs...
> > If things would be easier in C than in C++ people woudln't use C++.
> its your belif... have you seen concept of reasoning? this is concept saying you shouldnt belive in random things : like a lot of statemants which are lies and you post (liek im nervous (im quite calm, but my ear hurts me recently, jm happy Jankos win on KOI etc), i cant programming, " If things would be easier in C than in C++ people woudln't use C++." and many other belifs with no justification
>
> you dont fear lies so you live in lies - thats sad but its more your problem than mine, you also spred lies here which in turn is troll activity
> > The opposite is the truth. The language is more complex but solving
> > actual problems becomes much more manageable because you won't need
> > to deal with the same problems in detail over and over.

note btw im not exactly say easier.. i more say "better" (originally it was yet on something other it was a negation of some false statement) , ... it doesnt necessary mean using c-way is not easier coz this easier has many meaning and many contexts (for exampel it may be easier if you elarn something but it may be harder to learn something if you then want to use it easier..e.asier depends on many things)

niedziela, 23 lipca 2023 o 14:03:42 UTC+2 fir napisał(a):
> niedziela, 23 lipca 2023 o 13:44:05 UTC+2 Bonita Montero napisał(a):
> > Am 23.07.2023 um 09:52 schrieb fir:
> > > niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
> > >> Am 22.07.2023 um 23:07 schrieb fir:
> > >>
> > >>> sure as efficient as possinle, what with i once give example of how this pony fast is
> > >> Why should you have given such an example ? You're not aware
> > >> what C++ does for you because you don't unterstand the language.
> > >
> > >
> > > it is counter example for your belifs...
> > If things would be easier in C than in C++ people woudln't use C++.
> its your belif...

important factors here are for example popularity, belifs and knowledge

people dont do some things becouse they dont know things ..if they would know they would do other things ..but they dont know - and they do what they belive/assume

niedziela, 23 lipca 2023 o 14:31:28 UTC+2 fir napisał(a):
> niedziela, 23 lipca 2023 o 14:03:42 UTC+2 fir napisał(a):
> > niedziela, 23 lipca 2023 o 13:44:05 UTC+2 Bonita Montero napisał(a):
> > > Am 23.07.2023 um 09:52 schrieb fir:
> > > > niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
> > > >> Am 22.07.2023 um 23:07 schrieb fir:
> > > >>
> > > >>> sure as efficient as possinle, what with i once give example of how this pony fast is
> > > >> Why should you have given such an example ? You're not aware
> > > >> what C++ does for you because you don't unterstand the language.
> > > >
> > > >
> > > > it is counter example for your belifs...
> > > If things would be easier in C than in C++ people woudln't use C++.
> > its your belif...
> important factors here are for example popularity, belifs and knowledge
>
> people dont do some things becouse they dont know things ..if they would know they would do other things ..but they dont know - and they do what they belive/assume

i myself dont know a lot of things (i dont know languages like this rust or other (javascript) too much, and thats kinda sad becouse thsi javascript is interesting, and there is lot to learn bou i got no energui and strictly time for that..i stiok to c as i think its totally worth and here its also a lot to lern potentially: for example this container for speeding up collision detections, hopw to do that properly and more)

niedziela, 23 lipca 2023 o 14:14:29 UTC+2 fir napisał(a):
> niedziela, 23 lipca 2023 o 14:03:42 UTC+2 fir napisał(a):
> > niedziela, 23 lipca 2023 o 13:44:05 UTC+2 Bonita Montero napisał(a):
> > > Am 23.07.2023 um 09:52 schrieb fir:
> > > > niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
> > > >> Am 22.07.2023 um 23:07 schrieb fir:
> > > >>
> > > >>> sure as efficient as possinle, what with i once give example of how this pony fast is
> > > >> Why should you have given such an example ? You're not aware
> > > >> what C++ does for you because you don't unterstand the language.
> > > >
> > > >
> > > > it is counter example for your belifs...
> > > If things would be easier in C than in C++ people woudln't use C++.
> > its your belif... have you seen concept of reasoning? this is concept saying you shouldnt belive in random things : like a lot of statemants which are lies and you post (liek im nervous (im quite calm, but my ear hurts me recently, jm happy Jankos win on KOI etc), i cant programming, " If things would be easier in C than in C++ people woudln't use C++." and many other belifs with no justification
> >
> > you dont fear lies so you live in lies - thats sad but its more your problem than mine, you also spred lies here which in turn is troll activity
> > > The opposite is the truth. The language is more complex but solving
> > > actual problems becomes much more manageable because you won't need
> > > to deal with the same problems in detail over and over.
> note btw im not exactly say easier.. i more say "better" (originally it was yet on something other it was a negation of some false statement) , ... it doesnt necessary mean using c-way is not easier coz this easier has many meaning and many contexts (for exampel it may be easier if you elarn something but it may be harder to learn something if you then want to use it easier..e.asier depends on many things)

for example im unable tos ay now what is easier to learn c or c++

c is hard becous its imo hard to understand c (becouse c is wise, has deep and wise concepts )
c++ is also hard becouse its complex and idiotic

im unable to say what is harder

Am 23.07.2023 um 14:03 schrieb fir:
> niedziela, 23 lipca 2023 o 13:44:05 UTC+2 Bonita Montero napisał(a):
>> Am 23.07.2023 um 09:52 schrieb fir:
>>> niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
>>>> Am 22.07.2023 um 23:07 schrieb fir:
>>>>
>>>>> sure as efficient as possinle, what with i once give example of how this pony fast is
>>>> Why should you have given such an example ? You're not aware
>>>> what C++ does for you because you don't unterstand the language.
>>>
>>>
>>> it is counter example for your belifs...
>> If things would be easier in C than in C++ people woudln't use C++.
>
> its your belif... ....

You never programmed C++ and you've been never into professional
software development. You want to persuade others to use tools
which whouldn't overburden you.

According to your replies to yourself you must be very nervous.

Rest unread.

Am 23.07.2023 um 09:58 schrieb fir:
> niedziela, 23 lipca 2023 o 03:30:58 UTC+2 Bonita Montero napisał(a):
>> Am 22.07.2023 um 23:06 schrieb fir:
>>> sobota, 22 lipca 2023 o 18:27:34 UTC+2 Bonita Montero napisał(a):
>>>> Am 22.07.2023 um 17:42 schrieb fir:
>>>>> sobota, 22 lipca 2023 o 17:07:38 UTC+2 Bonita Montero napisał(a):
>>>>>> That's not crap but standard data structures, handled with the most
>>>>>> efficient way. Have a look at what an unordered_map saves you a lot
>>>>>> of work. This is needed really often and in C++ that's a few lines
>>>>>> of code.
>>>>>
>>>>> you think c has no libraries? ...
>>>>
>>>> It's impossible to write sth. like the STL or other libraries
>>>> in C with the same convenience. C doesn't have the language
>>>> facilities for that.
>>>> You can't persuade the world to use a language which doesn't
>>>> overburden you.
>>>
>>> good joke "c is easy to learn" ...
>>
>> I learned it in a week when I was 14 in the 90s.
>
> i was thirty and do assembly coding on C64 (C i began to learn - quite late
> just in a week when wtc attack was, maybe 3 days after it - from very old book
> i incidentally found at home)..it took me good 10 years to learn it (i thionk i learned it 'totally' something around 2014 something like that) .. and even though now here i found sole small piece i not fully understand (i dont understand varargs macros fully (though i understand it mostly) as i procastrinate it - though i should learn it
> probably)

You still struggle with C. No chance for C++.

niedziela, 23 lipca 2023 o 15:16:21 UTC+2 Bonita Montero napisał(a):
> Am 23.07.2023 um 14:03 schrieb fir:
> > niedziela, 23 lipca 2023 o 13:44:05 UTC+2 Bonita Montero napisał(a):
> >> Am 23.07.2023 um 09:52 schrieb fir:
> >>> niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
> >>>> Am 22.07.2023 um 23:07 schrieb fir:
> >>>>
> >>>>> sure as efficient as possinle, what with i once give example of how this pony fast is
> >>>> Why should you have given such an example ? You're not aware
> >>>> what C++ does for you because you don't unterstand the language.
> >>>
> >>>
> >>> it is counter example for your belifs...
> >> If things would be easier in C than in C++ people woudln't use C++.
> >
> > its your belif... ....
>
> You never programmed C++ and you've been never into professional
> software development. You want to persuade others to use tools
> which whouldn't overburden you.
>
i told you what i think about this 'professional' i see it sorta ironically

its your belif i want to "persuade" - ands its your another lie (probably your tenth lie here or something) i dont want to "persuade".. i just want to deny false (or unproven/not justified) statements which my brainwash people ahich you put here as spam..your main problems here are maybe wuite trivial
1) you dont fear of lies (more worse you dont fear to evengelize them)
2) you dont get a feel of generalization (becouse its ok to say thay a) you prefer c++ personally (its okay no problem) b) you know some context where you think c++ is much better than c as you know it (it might be..not to say its true but it might be true, sometimes it is true for sure, sometimes not) ..it would be better if you would say narrow and tru statements instead of broad and fales and yet in big amount (which is just spam.. it would be spam even if it would be tru as imagine some user who spams "matrix algebra is superior, calculus sucks" or oposite "matrix algebra sucks, calculus is superior" (or may also sapm that both are superior or both suck) its to general and to annoying if some post a hundreds of th like your ponny evengelisation who you put maniacally -its often liek half of what you post is such kind of spam ...im weary of explaining it more i think i said a lot of it..you should lower this spam becouse its not good content..and thats it..
i need to go moaybe i will code some piece of my 2d space game i toy recently)

niedziela, 23 lipca 2023 o 15:17:07 UTC+2 Bonita Montero napisał(a):
> You still struggle with C. No chance for C++.

at least one belif that may be true

Bart <bc@freeuk.com> writes:
>On 23/07/2023 00:38, Keith Thompson wrote:

> > Nope. int was commonly 16 bits on the implementations you used. K&R1,
> > published 4 years earlier, includes a table show implementations with
> > 16-bit, 32-bit, and 36-bit int.
>
>I'm not talking about 4 years earlier, but the last 42 years at last. 42
>years before 1982, it was 1940, and there were no computers at all.

That statement is incorrect, there were computers earlier than 1940;
I've actually had components (the memory drum) from one in my possession temporarily
circa 1980 and even took its inventor out to dinner once.

Am 23.07.2023 um 15:39 schrieb fir:
> niedziela, 23 lipca 2023 o 15:16:21 UTC+2 Bonita Montero napisał(a):
>> Am 23.07.2023 um 14:03 schrieb fir:
>>> niedziela, 23 lipca 2023 o 13:44:05 UTC+2 Bonita Montero napisał(a):
>>>> Am 23.07.2023 um 09:52 schrieb fir:
>>>>> niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
>>>>>> Am 22.07.2023 um 23:07 schrieb fir:
>>>>>>
>>>>>>> sure as efficient as possinle, what with i once give example of how this pony fast is
>>>>>> Why should you have given such an example ? You're not aware
>>>>>> what C++ does for you because you don't unterstand the language.
>>>>>
>>>>>
>>>>> it is counter example for your belifs...
>>>> If things would be easier in C than in C++ people woudln't use C++.
>>>
>>> its your belif... ....
>>
>> You never programmed C++ and you've been never into professional
>> software development. You want to persuade others to use tools
>> which whouldn't overburden you.
>>
> i told you what i think about this 'professional' i see it sorta ironically

No, there's a strong definition on that and you're not part of that.

Rest unread.

On 23/07/2023 12:43, Bonita Montero wrote:
> Am 23.07.2023 um 09:52 schrieb fir:
>> niedziela, 23 lipca 2023 o 03:30:09 UTC+2 Bonita Montero napisał(a):
>>> Am 22.07.2023 um 23:07 schrieb fir:
>>>
>>>> sure as efficient as possinle, what with i once give example of how
>>>> this pony fast is
>>> Why should you have given such an example ? You're not aware
>>> what C++ does for you because you don't unterstand the language.
>>
>>
>> it is counter example for your belifs...
>
> If things would be easier in C than in C++ people woudln't use C++.

I have a low opinion of C, but that of C++ is so far down the scale that
it would be negative.

Sure, it appears to tick all the boxes, on paper, but when you see it
for real, you realise what a monstrosity of a language it is, and such
an appallingly badly designed one.

It's also much harder to implement, and hard to compile efficiently.

If I had to write some program, I would be able to use C, even though I
don't like it, in the same way I could use assembly.

But I wouldn't be able to use C++ unless I used the C subset of it.

> The opposite is the truth. The language is more complex but solving
> actual problems becomes much more manageable because you won't need
> to deal with the same problems in detail over and over.

The complexity is in the wrong place: it concentrates on providing
language-building features (templates, classes, inheritance,
overloads...) so that it can provide the features you really need, like
vectors and first-class strings, but defining them via those
language-building features.

My view is that it should instead just provide those vectors and string
types, built-in.

And for all its abilities, even C++ will have trouble providing anything
other than zero-based arrays; this is in my systems language, not C:

['A'..'Z']int table

The 'table' variable is a regular array, not a hash-map or any other
kind of container, and has 26 elements, indexed from 65.

On 23/07/2023 14:45, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 23/07/2023 00:38, Keith Thompson wrote:
>
>>> Nope. int was commonly 16 bits on the implementations you used. K&R1,
>>> published 4 years earlier, includes a table show implementations with
>>> 16-bit, 32-bit, and 36-bit int.
>>
>> I'm not talking about 4 years earlier, but the last 42 years at least. 42
>> years before 1982, it was 1940, and there were no computers at all.
>
> That statement is incorrect, there were computers earlier than 1940;
> I've actually had components (the memory drum) from one in my possession temporarily
>
>

I stand to be corrected then. I didn't do any research to make my
remark, it was based on remembering that most early machines I'd heard
about were post-1940.

Still, things changed significantly over the next 40 years (which is
about the point I entered the game, hardware-wise), but from my POV they
then changed little over the next 40, other than in scale.

Certainly the power-of-two word sizes we're talking about were already
very common.

> circa 1980 and even took its inventor out to dinner once.

I guess that wasn't Babbage you're talking about then, but someone else!

Am 23.07.2023 um 15:56 schrieb Bart:

> I have a low opinion of C, but that of C++ is so far down the scale that
> it would be negative.

With C++ you have a fraction of the code an reusable components
wich are impossible with the C language facilities. With that
you save money and you have less debugging.

> It's also much harder to implement, and hard to compile efficiently.

C++ components like the STL are also available in external C libraries.
But there's no generic programming which would make the code as perfor-
mant.

> The complexity is in the wrong place: it concentrates on providing
> language-building features (templates, classes, inheritance,
> overloads...) so that it can provide the features you really need,

This features are needed and make less work and less bugs.

On 2023-07-23, Bart <bc@freeuk.com> wrote:
> My view is that it should instead just provide those vectors and string
> types, built-in.

If some language features can be implemented as a library, and work
as well as built-in features, that is an overhelmingly preferrable
implementation approach. Developing a core set of language features
which provide the extensibility so that one can have a
library-programmed array with the same syntactic sugars and efficiencies
of a built-in one is a much smarter approach than shoehorning everything
into the language: parser features for vectors, intermediate code
generation for the vector syntax, specialized type checking and whatnot
for the vectors ...

The entire problem with C++ is not that it emobides this idea, but
that it keeps betraying it; it keeps keeps accumulating built-in crud
like a giant, dirty, snowball. If you don't use C++ for five, ten years,
you cannot recognize it.

At this point, built-in vectors and strings would make C++ monumentally
worse. (Even in someone's private fork, where the library-based strings
and vectors are removed.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 22/07/2023 22:56, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 21/07/2023 17:14, Bart wrote:>
>
>>> C requires reduction of constant-expressions for compile-time
>>> expressions, and within conditional expressions of the preprocessor.
>>
>> Yes.
>>
>>> So the mechanism for doing that is already there; it is not optional.
>>
>> When you have a "constant expression" that is used wherever a "constant"
>> (what some people inaccurately call "integer literal") can be used, the
>> compiler must evaluate the expression at compile time. Apart from that, it
>> is all optional.
>>
>> Thus for "int x = 1 + 2;", the "1 + 2" must be evaluated at compile time
>> for a file-scope or static variable, but can be evaluated at run time if it
>> is a local variable.
>
> Objects with static storage duration are "initialized only once, prior
> to program startup". In any sane implementation, the calculation will
> be done by the compiler. But in principle the calculation and
> initialisation could be done by executable code that runs before main.
>

Of course - compilers can do anything that gives the same observable
behaviour. The norm is that C toolchains put initialised static
duration data into a single section of the executable, with the initial
values as a binary section. Depending on the platform, either the
initial data section is loaded then made writeable, or is copied to
writeable ram on startup. But there is no requirement that it be done
this way - merely a requirement that it /could/ be done this way.
(Unlike in C++, where statically allocated data can have non-constant
initialisation calculated at run-time before main starts.)

> <cut>
>>> In my languages and compilers, signed integer overflow has never been
>>> undefined. It's a choice.
>>>
>> A bad choice. Seriously. I mean, what kind of screwed up idea of numbers
>> do you have to have to think it's a good idea that adding two positive
>> numbers can give you a negative number?
>
> Two's complement numbers form a commutative ring. What's wrong with
> that?

Nothing - but equally, it has no benefit. It gives nothing particularly
useful.

Now, if you were to redefine your multiplication and have your n-bit
numbers set up as a GF(2 ** n) finite field, you'd have some new useful
properties. You'd be able to divide any integers, except for division
by 0, without any fractions. But would it be useful, other than for
people working on error correction algorithms? No, I don't believe so.

Similarly, I don't believe defining the behaviour of signed integer
arithmetic overflow actually helps anyone (other than occasional very
niche situations when you really do want modulo behaviour). When you
overflow integer arithmetic, you get the wrong answer for pretty much
every situation. I am at a loss as to why a predictable wrong answer is
an improvement over an unpredictable wrong answer - surely the aim of
the game is to avoid wrong answers in the first place.

> Making some arithmetic operations undefined results is a
> structure with no simple mathematical description.

Agreed. But it lets you have useful rules, leading to simplification
for both the compiler and the programmer. Knowing that as long as the
programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
similar rules always holds true can be useful.

Of course, that means the programmer is responsible for ensuring that
"n" is not INT_MAX at that point in the code, and may have to take steps
to make sure of that. But they must do so anyway, regardless of how
integer overflow is or is not defined, because the any definition would
almost certainly be wrong.

So you lose nothing, and gain something, by having the behaviour undefined.

Even better, IMHO - when something is undefined behaviour, a compiler or
debugging tool can consider it an error. That means you can use tools
to help catch bugs in your code - static analysis of potential
overflows, or run-time error handling. But if the behaviour is defined
in some way, then it is not an error - the compiler has to assume that
you intentionally wrapped your integers.

I for one would rather have help getting my programs correct, than a
language that blindly accepted all my mistakes.

There are some rare occasions where modulo behaviour is useful. There
are also occasions where saturation would be more helpful, or some kind
of NaN behaviour similar to floating point arithmetic. There is no
reason to consider wrapping as somehow "correct" overflow behaviour.

>
>> Two's complement wrapping is a side-effect of efficient ALU hardware
>> implementation, nothing more. It's not something you want in a
>> language.
>
> I'd make the opposite argument. Making overflow undefined in C was a
> consequence of hardware that behaved that way, nothing more. It has
> found a niche in modern optimising compilers, but that's a side effect.
>

It is certainly possible that C originally made overflow UB because
different hardware worked in different ways in the early days of C. But
I think that if that had been the sole motivation and people thought
two's complement wrapping would be useful, it would have made more sense
to make overflow behaviour implementation defined rather than explicitly
undefined.

But I do not believe any language has defined signed integer overflow to
be modulo wrapping because it is a good idea mathematically, or useful
for applications - languages do so only if they want to give /some/
definition to it, regardless of its usefulness. And since two's
complement wrapping is a side-effect of almost all hardware
implementations for the last 50 years or more, that's what is picked -
anything else would be hugely expensive, and surprising to programmers.

Remember what the C standards actually say here, in 6.5p5 :

"""
If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined or not
in the range of representable values for its type), the behavior is
undefined.
"""

Overflow is an "exceptional condition" with results "not mathematically
defined" or where the result is not representable by the type. That
sounds to me very much like saying if the result doesn't make sense in
the program, the C language doesn't try to impose a sense on it.

On 23/07/2023 01:22, Bart wrote:
>
> On 22/07/2023 18:05, David Brown wrote:

> > No, "int" is not 32-bit in C.
>
> This is where we keep going around in circles with C.

"We" don't have a problem with how "int" in C works. /You/ have a
problem with it.

>
> In 1982 when I started on all this stuff in earnest, ints were 16-bits.
>
> Until 32-bit processors become common in the 1990s, when ints become 32
> bits. Where they've been ever since. (I'm talking about home and
> business computers of that era, which now probably includes laptops,
> tablets and smartphones.)
>
In the majority of processors sold today, "int" is 16-bit. It's true
that the proportions are changing and it may not be long before 32-bit
"int" is in the majority. But we are not talking about something from
decades ago - we are talking about /today/.

It really bugs me when some people insist on believing the world
revolves around their own tiny little slice of reality, and refuse to
open their eyes and look around - no matter how many times they are told.

You can use whatever names or sizes you like in your own little
languages for your own amusement. And if you are writing non-portable C
code for systems that all have 32-bit int, you can assume int is 32-bit
if you want.

But if you want to talk about the C language, talk about the C language,
not a needlessly restricted subset of its implementations.

On 23/07/2023 16:24, David Brown wrote:
> On 22/07/2023 22:56, Ben Bacarisse wrote:
> Similarly, I don't believe defining the behaviour of signed integer
> arithmetic overflow actually helps anyone (other than occasional very
> niche situations when you really do want modulo behaviour). When you
> overflow integer arithmetic, you get the wrong answer for pretty much
> every situation.

That's not true.

INT_MAX + 1 - 1 will give the correct answer. If you instead write it
like this:

typedef unsigned int u32;
(int)((u32)INT_MAX + (u32)1 - (u32)1);

then even C agrees that is well-behaved, despite probably performing
exactly the same machine operations (where the compiler deigns to
actually let it, that is, in actual code where variables are used and
the steps are in different expressions)).

So, it's possible to view most signed operations as though there were
implicits casts to convert to unsigned and back again, for the purposes
of making them well-defined in C. But then, why the need for an /any/ cast?

(Some operations will give different results between signed and
unsigned, like shifts.)

> I am at a loss as to why a predictable wrong answer is
> an improvement over an unpredictable wrong answer - surely the aim of
> the game is to avoid wrong answers in the first place.

Are you talking about signed arithmetic here? Because your comments can
equally to unsigned arithmetic.

>
>> Making some arithmetic operations undefined results is a
>> structure with no simple mathematical description.
>
> Agreed. But it lets you have useful rules, leading to simplification
> for both the compiler and the programmer. Knowing that as long as the
> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
> similar rules always holds true can be useful.

> Of course, that means the programmer is responsible for ensuring that
> "n" is not INT_MAX at that point in the code, and may have to take steps
> to make sure of that. But they must do so anyway, regardless of how
> integer overflow is or is not defined, because the any definition would
> almost certainly be wrong.
>
> So you lose nothing, and gain something, by having the behaviour
undefined.

I thought I'd try a test, and compiled one of my generated-C programs
with both -O3 and -O3 -fwrapv, to see if there was actually any gain in
performance due to taking advantage of UB.

(The program was an interpreter running a JPEG-decoder script.)

Sure enough, I saw a 4% gain in performance, so that I'd have to admit
that that would be handy...

.... until I looked at the test results more carefully: the faster
results were when compiled with -fwrapv, so integer overflow was not UB!

Having well-defined wrapping behaviour was faster in this case (I only
did one test). However the executable was slightly bigger by 0.25%.

So, what I'd wanted to ask was, is the UB really worth it overall? What
improvements you get purely with -fwrapv in general? As I showed I got a
slight slowdown.

On 23/07/2023 16:34, Kaz Kylheku wrote:
> On 2023-07-23, Bart <bc@freeuk.com> wrote:
>> My view is that it should instead just provide those vectors and string
>> types, built-in.
>
> If some language features can be implemented as a library, and work
> as well as built-in features, that is an overhelmingly preferrable
> implementation approach. Developing a core set of language features
> which provide the extensibility so that one can have a
> library-programmed array with the same syntactic sugars and efficiencies
> of a built-in one is a much smarter approach than shoehorning everything
> into the language: parser features for vectors, intermediate code
> generation for the vector syntax, specialized type checking and whatnot
> for the vectors ...

Remember, Bart's view of a perfect language is a language /he/ designs,
/he/ implements, and /he/ uses. There's no need to consider anyone else
or their needs or wants.

The C++ philosophy allows people to use ready-made template classes like
std::vector<> if that suits their needs. If they need something similar
but with, say, slightly different balances of run-time complexity for
some operations, then the C++ programmer can make their own alternative
that can be used just as easily. That one of the many advantages of
putting things in libraries where possible, rather than the core language.

But for Bart, putting something in the core language is the same as
putting it in application code - he writes the compiler and the
application code. And he can't imagine different users having different
needs, because he is the only user for his languages.

>
> The entire problem with C++ is not that it emobides this idea, but
> that it keeps betraying it; it keeps keeps accumulating built-in crud
> like a giant, dirty, snowball. If you don't use C++ for five, ten years,
> you cannot recognize it.
>

A big challenge is that whenever some better (or at least alternative)
way of expressing something is added to the language, you still need to
keep the old way for compatibility. When concepts were added, the
horrendous and ugly std::enable_if<> feature was outdated by something a
lot clearer and simpler. But the language is not made clearer and
simpler because of that - now it supports both (and any language
features needed to make std::enable_if<> work).

Pretty much the only solution is to start again - keep the good parts of
C++, but throw out the ugly parts that could now be done better. But
doing that would of course mean you don't have C++ any more. Herb
Sutter is trying this, with his "cpp2" concept - a language that tries
to be cleaner and neater but can be transcompiled directly to C++. It
remains to be seen where that will go.

> At this point, built-in vectors and strings would make C++ monumentally
> worse. (Even in someone's private fork, where the library-based strings
> and vectors are removed.)
>

Agreed.

But surely all this is for comp.lang.c++, not comp.lang.c ?

On 2023-07-23, Bart <bc@freeuk.com> wrote:
> On 23/07/2023 16:24, David Brown wrote:
> > On 22/07/2023 22:56, Ben Bacarisse wrote:
> > Similarly, I don't believe defining the behaviour of signed integer
> > arithmetic overflow actually helps anyone (other than occasional very
> > niche situations when you really do want modulo behaviour). When you
> > overflow integer arithmetic, you get the wrong answer for pretty much
> > every situation.
>
> That's not true.
>
> INT_MAX + 1 - 1 will give the correct answer. If you instead write it
> like this:

This is something the compiler can advantage of, regardless of
whether the behavior is defined to the programmer.

When we write a + 3 - c, then, if the compiler knows that the
underlying target language has wrapping behavior with no ill
consequences, it can rearrange the calculation to a - c + 3. (For
whatever reason, such has having previously calculated a - c in another
expression, and the consolidation of non-constant terms allows the
result to be reused.)

If overflow has negative/undefined consequences in the target language,
then the rearrangement cannot be made; the programmer may have written
the calculation in that order way on purpose, and verified that it
doesn't overflow or underflow.

(Speaking of "underlying target language", defined wrapping arithmetic
can help writers of languages that translate to C, in the same way.)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 23/07/2023 16:54, David Brown wrote:
> On 23/07/2023 01:22, Bart wrote:
>>
>> On 22/07/2023 18:05, David Brown wrote:
>
>> > No, "int" is not 32-bit in C.
>>
>> This is where we keep going around in circles with C.
>
> "We" don't have a problem with how "int" in C works. /You/ have a
> problem with it.
>
>>
>> In 1982 when I started on all this stuff in earnest, ints were 16-bits.
>>
>> Until 32-bit processors become common in the 1990s, when ints become
>> 32 bits. Where they've been ever since. (I'm talking about home and
>> business computers of that era, which now probably includes laptops,
>> tablets and smartphones.)
>>
> In the majority of processors sold today, "int" is 16-bit. It's true
> that the proportions are changing and it may not be long before 32-bit
> "int" is in the majority. But we are not talking about something from
> decades ago - we are talking about /today/.
>
> It really bugs me when some people insist on believing the world
> revolves around their own tiny little slice of reality, and refuse to
> open their eyes and look around

It is a HUGE slice of reality.

You like to distort that reality by using the vast numbers of $1 chips
that are in everything, that happen to use 16-bit ints in their C compilers.

A better comparison would be in the number of distinct C programs
programmed using 16-bit ints, or the number of developers doing so, or
maybe even counting all developers across all languages.

Since, by your measure, the instances of programs in C using 16-bit
ints, would also outnumber the instances of programs in every other
language put together.

> It really bugs me when some people insist on believing the world
> revolves around their own tiny little slice of reality

Here's a quick survey of some other languages:

Go has an 'int' type which is 32 bits in 32-bit systems,
and 64 bits on 64-bit ones.

D has an 'int' type of 32 bits

Java has an 'int' type of 32 bits

C# has an 'int' type of 32 bits

Rust has an `isize` type that is 32/64 bits in 32/64-bit
systems

Notice there is no mention of 16 bit systems in Go and Rust. I don't
know whether those others work on 16-bit systems, but I doubt they lose
any sleep over them.

So quite a few languages, their developers, and their users, must also
be living in their own tiny slice of reality where ints are either 32 or
64 bits.

Or perhaps it's just frustrated embedded C developers stuck with using
under-powered processors who have a warped view of it.

> But if you want to talk about the C language, talk about the C language,
> not a needlessly restricted subset of its implementations.

How about talking about the C language as it is actually used by the
majority of developers, rather than marginalising everyone in the 90%
group where int actually is 32 bits and suggesting they are in the minority.

(I don't know the actual figures, but neither do you.)

On Sunday, 23 July 2023 at 17:57:04 UTC+1, Bart wrote:
> On 23/07/2023 16:54, David Brown wrote:
>
> > It really bugs me when some people insist on believing the world
> > revolves around their own tiny little slice of reality, and refuse to
> > open their eyes and look around
> It is a HUGE slice of reality.
>
> You like to distort that reality by using the vast numbers of $1 chips
> that are in everything, that happen to use 16-bit ints in their C compilers.
>
> A better comparison would be in the number of distinct C programs
> programmed using 16-bit ints, or the number of developers doing so, or
> maybe even counting all developers across all languages.
>
> Since, by your measure, the instances of programs in C using 16-bit
> ints, would also outnumber the instances of programs in every other
> language put together.
> > It really bugs me when some people insist on believing the world
> > revolves around their own tiny little slice of reality
>
> Or perhaps it's just frustrated embedded C developers stuck with using
> under-powered processors who have a warped view of it.
>
C has largely been replaced by C++ for desktop and large computer
development. Even gcc is now written in C++.But not for embedded
programming, Embedded devices are not under powered, in fact a lot
of the time they are grossly over-powered - a 2MHz processor might be
doing nothing other than update the LED of an 8 segment display
every second. But throwing the latest Intel Pentium at the job would
increase the price ridiculously. Keeping costs down is the name of the
game in consumer electronics.

On 23/07/2023 18:56, Bart wrote:
> On 23/07/2023 16:54, David Brown wrote:
> > On 23/07/2023 01:22, Bart wrote:
> >>
> >> On 22/07/2023 18:05, David Brown wrote:
> >
> >>  > No, "int" is not 32-bit in C.
> >>
> >> This is where we keep going around in circles with C.
> >
> > "We" don't have a problem with how "int" in C works.  /You/ have a
> > problem with it.
> >
> >>
> >> In 1982 when I started on all this stuff in earnest, ints were 16-bits.
> >>
> >> Until 32-bit processors become common in the 1990s, when ints become
> >> 32 bits. Where they've been ever since. (I'm talking about home and
> >> business computers of that era, which now probably includes laptops,
> >> tablets and smartphones.)
> >>
> > In the majority of processors sold today, "int" is 16-bit.  It's true
> > that the proportions are changing and it may not be long before 32-bit
> > "int" is in the majority.  But we are not talking about something from
> > decades ago - we are talking about /today/.
> >
> > It really bugs me when some people insist on believing the world
> > revolves around their own tiny little slice of reality, and refuse to
> > open their eyes and look around
>
> It is a HUGE slice of reality.
>
> You like to distort that reality by using the vast numbers of $1 chips
> that are in everything, that happen to use 16-bit ints in their C
> compilers.
>
> A better comparison would be in the number of distinct C programs
> programmed using 16-bit ints, or the number of developers doing so, or
> maybe even counting all developers across all languages.

Adding developers from different languages would not be at all helpful -
many don't have sized integers.

Of course most C programmers today work for targets that have 32-bit
int. That's not the point. The point is you are /wrong/ to suggest
that C ints are 32-bit. I gave (approximate) data points to show that
you are not only wrong in theory (which is without doubt the case), but
wrong in practice.

If you want to talk only about C on a particular implementation or
target, it's fine to say "int on x86-64 is 32-bit". But if you are
talking about C in general, the C standards define what "int" means.

You might not have noticed, but this is /not/ "comp.lang.c.x86-64".
Here, the main focus is on the C language, not particular
implementations. And yes, sometimes people here enjoy discussing the
hypothetical technicalities as well as real-world practicalities.

>
> Since, by your measure, the instances of programs in C using 16-bit
> ints, would also outnumber the instances of programs in every other
> language put together.

They probably do, yes. But we are not talking about other languages.

>
> > It really bugs me when some people insist on believing the world
> > revolves around their own tiny little slice of reality
>
> Here's a quick survey of some other languages:

I'll snip the irrelevant parts.

>
> > But if you want to talk about the C language, talk about the C language,
> > not a needlessly restricted subset of its implementations.
>
> How about talking about the C language as it is actually used by the
> majority of developers, rather than marginalising everyone in the 90%
> group where int actually is 32 bits and suggesting they are in the
> minority.
>

I'm not marginalising anyone. /You/ are. No one is suggesting that
int's are always 16-bit - we are merely saying that the C language, in
theory and in practice, does not guarantee that ints are 32-bit. It's
really quite a simple matter.

> (I don't know the actual figures, but neither do you.)
>

No, I have only rough estimates based on what I read on industry-related
news sites. It's possible to get hold of more exact figures, but such
reports cost a great deal of money.

On 23/07/2023 19:15, David Brown wrote:
> On 23/07/2023 18:56, Bart wrote:
>> How about talking about the C language as it is actually used by the
>> majority of developers, rather than marginalising everyone in the 90%
>> group where int actually is 32 bits and suggesting they are in the
>> minority.
>>
>
> I'm not marginalising anyone. /You/ are. No one is suggesting that
> int's are always 16-bit - we are merely saying that the C language, in
> theory and in practice, does not guarantee that ints are 32-bit. It's
> really quite a simple matter.

The majority of people programming today will be using 32/64-bit
machines, and using languages that have settled on 32/64-bit types,
where that aspect has been exposed.

Including C. Since C is used in the OSes of those systems, in the APIs
of countless libraries, and is used to implement or be the target of
half those languages.

But you are saying all those people above cannot assume a 32-bit int,
because a small number of embedded C developers are using machines where
the compiler has chosen a 16-bit type.

Presumably yours and Keith's advice, if they want to assume a 32-bit
int, is to instead use a fixed-width type, or take their chances with
'long'.

OK, then why not advise those embedded developers against assuming `int`
is 16 bits, because it could conceivably be 32 bits or even 64?

So nobody uses `int`; great result! It still leaves the problem of
integer literals having a `int` type that now doesn't match their chosen
alternative.

I guess if somebody is really worried that a decade or two in the
future, 'int' may change upwards (in my 4-decade career it's changed up
once in C), or their application software might be ported to a PIC, they
can use an assert.

David Brown <david.brown@hesbynett.no> writes:

> On 22/07/2023 22:56, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 21/07/2023 17:14, Bart wrote:>
>>
>>>> C requires reduction of constant-expressions for compile-time
>>>> expressions, and within conditional expressions of the preprocessor.
>>>
>>> Yes.
>>>
>>>> So the mechanism for doing that is already there; it is not optional.
>>>
>>> When you have a "constant expression" that is used wherever a "constant"
>>> (what some people inaccurately call "integer literal") can be used, the
>>> compiler must evaluate the expression at compile time. Apart from that, it
>>> is all optional.
>>>
>>> Thus for "int x = 1 + 2;", the "1 + 2" must be evaluated at compile time
>>> for a file-scope or static variable, but can be evaluated at run time if it
>>> is a local variable.
>> Objects with static storage duration are "initialized only once, prior
>> to program startup". In any sane implementation, the calculation will
>> be done by the compiler. But in principle the calculation and
>> initialisation could be done by executable code that runs before main.
>>
>
> Of course - compilers can do anything that gives the same observable
> behaviour. The norm is that C toolchains put initialised static duration
> data into a single section of the executable, with the initial values as a
> binary section. Depending on the platform, either the initial data section
> is loaded then made writeable, or is copied to writeable ram on startup.
> But there is no requirement that it be done this way - merely a requirement
> that it /could/ be done this way. (Unlike in C++, where statically
> allocated data can have non-constant initialisation calculated at run-time
> before main starts.)
>
>> <cut>
>>>> In my languages and compilers, signed integer overflow has never been
>>>> undefined. It's a choice.
>>>>
>>> A bad choice. Seriously. I mean, what kind of screwed up idea of numbers
>>> do you have to have to think it's a good idea that adding two positive
>>> numbers can give you a negative number?
>> Two's complement numbers form a commutative ring. What's wrong with
>> that?
>
> Nothing - but equally, it has no benefit. It gives nothing particularly
> useful.

There's nothing wrong with it but relies on a screwed up idea of
numbers?

> Now, if you were to redefine your multiplication and have your n-bit
> numbers set up as a GF(2 ** n) finite field, you'd have some new useful
> properties.

It gives nothing particularly useful, but is the essential basis for
something you describe as having new useful properties?

> You'd be able to divide any integers, except for division by
> 0, without any fractions. But would it be useful, other than for people
> working on error correction algorithms? No, I don't believe so.

That's because the special division operator is of narrow use. That's
why it's not widely available in hardware. But the operations that make
two's complement numbers into a ring are widely available in hardware.

> Similarly, I don't believe defining the behaviour of signed integer
> arithmetic overflow actually helps anyone (other than occasional very niche
> situations when you really do want modulo behaviour).

I think it can make reasoning about the programs easier.

> When you overflow
> integer arithmetic, you get the wrong answer for pretty much every
> situation. I am at a loss as to why a predictable wrong answer is an
> improvement over an unpredictable wrong answer - surely the aim of the game
> is to avoid wrong answers in the first place.

Yes, but you get the right answers by thinking clearly and understanding
what the parts of a program do. I think that easier with plain two's
complement arithmetic.

From a practical point of view, where almost no one reasons about code
any more and everyone replies on testing, you want well-defined
semantics where overflow is trapped at run-time.

>> Making some arithmetic operations undefined results is a
>> structure with no simple mathematical description.
>
> Agreed. But it lets you have useful rules, leading to simplification for
> both the compiler and the programmer. Knowing that as long as the
> programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
> similar rules always holds true can be useful.

Interesting. Can you give an example where this rule helps a programmer
(and plain two's complement would not)?

> Of course, that means the programmer is responsible for ensuring that "n"
> is not INT_MAX at that point in the code, and may have to take steps to
> make sure of that. But they must do so anyway, regardless of how integer
> overflow is or is not defined, because the any definition would almost
> certainly be wrong.

Yes, none of that is specific to undefined overflow.

> So you lose nothing, and gain something, by having the behaviour
> undefined.

You example might help me see the gain.

> Even better, IMHO - when something is undefined behaviour, a compiler or
> debugging tool can consider it an error. That means you can use tools to
> help catch bugs in your code - static analysis of potential overflows, or
> run-time error handling. But if the behaviour is defined in some way, then
> it is not an error - the compiler has to assume that you intentionally
> wrapped your integers.
>
> I for one would rather have help getting my programs correct, than a
> language that blindly accepted all my mistakes.

Tools should be to targeted at programmers. If there is a tool for C
that can detect signed arithmetic overflow, there should be one that can
detect wrapping in two's complement arithmetic. Maybe no one implements
such things, but that's not the fault of the language semantics.

> There are some rare occasions where modulo behaviour is useful. There are
> also occasions where saturation would be more helpful, or some kind of NaN
> behaviour similar to floating point arithmetic. There is no reason to
> consider wrapping as somehow "correct" overflow behaviour.

Indeed. I don't consider it as somehow "correct".

>>> Two's complement wrapping is a side-effect of efficient ALU hardware
>>> implementation, nothing more. It's not something you want in a
>>> language.
>> I'd make the opposite argument. Making overflow undefined in C was a
>> consequence of hardware that behaved that way, nothing more. It has
>> found a niche in modern optimising compilers, but that's a side effect.
>
> It is certainly possible that C originally made overflow UB because
> different hardware worked in different ways in the early days of C. But I
> think that if that had been the sole motivation and people thought two's
> complement wrapping would be useful, it would have made more sense to make
> overflow behaviour implementation defined rather than explicitly
> undefined.

That would require documenting all the possible behaviours. I might
have been left as undefined because no one was confident that they could
list all the real-world choices that mattered.

--
Ben.

On Sunday, 23 July 2023 at 22:10:25 UTC+1, Ben Bacarisse wrote:
> David Brown <david...@hesbynett.no> writes:
>
> > Agreed. But it lets you have useful rules, leading to simplification for
> > both the compiler and the programmer. Knowing that as long as the
> > programmer hasn't made a mistake earlier in their code, "n + 1 > n" and
> > similar rules always holds true can be useful.
> Interesting. Can you give an example where this rule helps a programmer
> (and plain two's complement would not)?
>
I'm doing audio programming for my hobby project at the moment, so let's
give a (hypothetical) audio problem. The 16 bit signed samples come in with
a DC bias (the average value, which should be zero), which (unrealistically
but not too unrealistically) is known at compile time.

So
#define DC_BIAS_CORRECTION 1
#define dc_correct(pcm)(pcm + DC_BIAS_CORRECTION)

if (dccorrect(pcm) > pcm)
/* dc correction increases the value, take appropriate action) */

So we've got if( n + 1 > n) in code, without the programmer writing
any aburdity.
Now what will the action be? Of course the code will be written for 32 bit machines,
so it's

int correctedpcm = dccorrect(pcm);
if (correctedpcm > 32768) /* not SHRT_MAX! Samples must fir in 16 bits */
/* dc correction has caused the sample to overflow */
correctedpcm = pcm; /* what can we do? Just reset to original value and hope */

Now with David Brown's scheme, when we move this code to a processor with
16 bit ints, the if() expression is undefined. But because it's UB, the compiler
correctly guesses that we want it to be true. Then the assignment is also UB
(the dc_correct macro hasn't been written correctly), but it will do what we want.
So ir works, With Ben's system (the commutative ring) the test return false, and it
fails