On Saturday, 22 July 2023 at 16:07:38 UTC+1, Bonita Montero wrote:
>
> > you shouldnt go in crapy 'non trivial' objects - use proper ..c is not for mimicking crap
> 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 are right here. For example my GIF file code, implemented in pure C, uses
a red black tree to mkae the LZW codec efficient. That was a lot of work
(htouhg the tree is written genrically and can be recycled). In C++, you
can get the same functionality for free with an STL set. Where you need a
structure other than an array, C++ does have a clear advantage.

sobota, 22 lipca 2023 o 17:42:49 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 17:18 schrieb fir:
>
> > i told you writing such things in c by hand is few lines of code, ...
>
> You don't understand what the C++ containers do. If there wouldn't
> be a large productivity ehancement with C++ over C people would use C.
> You for sure never programmed professionally.

i think people dont use c becouse its to good and to hard for them

see like in movies or music, people prefers crap becouse it better suit their style of being - few listen to dave brubeck, keith jarret, rhmaninov or something decent they play total crap ..same effect you go in languages and your pony mind sayst to you what mass choses is good and things looks not like that..besides many people probably dont know c becouse c is in fact not so easy..need a dose of brain

sobota, 22 lipca 2023 o 17:49:42 UTC+2 Malcolm McLean napisał(a):
> On Saturday, 22 July 2023 at 16:07:38 UTC+1, Bonita Montero wrote:
> >
> > > you shouldnt go in crapy 'non trivial' objects - use proper ..c is not for mimicking crap
> > 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 are right here. For example my GIF file code, implemented in pure C, uses
> a red black tree to mkae the LZW codec efficient. That was a lot of work
> (htouhg the tree is written genrically and can be recycled). In C++, you
> can get the same functionality for free with an STL set. Where you need a
> structure other than an array, C++ does have a clear advantage.

it rather meand you dont know library for this in co or dont know how to write it - or you just dont want...it doesnt eman bonita montero is right..coz in c are people who know how to do this

sobota, 22 lipca 2023 o 17:57:49 UTC+2 fir napisał(a):
> sobota, 22 lipca 2023 o 17:49:42 UTC+2 Malcolm McLean napisał(a):
> > On Saturday, 22 July 2023 at 16:07:38 UTC+1, Bonita Montero wrote:
> > >
> > > > you shouldnt go in crapy 'non trivial' objects - use proper ..c is not for mimicking crap
> > > 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 are right here. For example my GIF file code, implemented in pure C, uses
> > a red black tree to mkae the LZW codec efficient. That was a lot of work
> > (htouhg the tree is written genrically and can be recycled). In C++, you
> > can get the same functionality for free with an STL set. Where you need a
> > structure other than an array, C++ does have a clear advantage.
> it rather meand you dont know library for this in co or dont know how to write it - or you just dont want...it doesnt eman bonita montero is right..coz in c are people who know how to do this

ofc its ok to ay "i prefer" c++ stl, well "im not"
its okay to say some prefer that or that but bonita dont says what she prefers she puts a bullshit /(at least unproven theories for me personally its bulshit) that c++ crappy containers are better..and c++ writing is generally better (not only i cant agree with that spam)

sobota, 22 lipca 2023 o 17:43:07 UTC+2 fir napisał(a):
> 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? isnt that stupid do compare pony++ with libraries with c withaut any? does it not make you think? c libraries have simpler interface
> but it also has strong advanteges (and this c++ name mangling is trash)
>
> in fact as i said for containers for my usage i dont use libraries as whet i ever need
> was a few pices of code i am able to write myself with no problem
>
> (im not programming 'professionally' but you may name it i code hobbystically or legendary depending what you need.. seeing that profesionally i would feel ashemed (if not worse) to be such professional - and this insulting me for writing or not writing professionally is ponish (pony-ish)

as to this legandary coding im not in form last years so it dont looks to much bad i could say i code more hobbysticaly then legendary now (i dont code to much though overally) but once i got few legandary pieces of c spirit language design

Am 22.07.2023 um 17:45 schrieb jak:

> <https://github.com/Mashpoe/c-vector/blob/master/vec.c>

Having the same facilities like in C is inconvenient and slower.
With generic containers you have specialized code for each type.
With real OOP you have a much more convenient usage. With RAII
you have initialization and creation in one place and you don't
have to care for cleanup. With excpetions you won't have to care
for the errors where they happen but just in a central place.

Am 22.07.2023 um 17:48 schrieb Bart:
> On 22/07/2023 15:32, Bonita Montero wrote:
>> Am 22.07.2023 um 15:53 schrieb Bart:
>>> On 22/07/2023 14:00, Bonita Montero wrote:
>>>> Am 22.07.2023 um 07:30 schrieb Blue-Maned_Hawk:
>>>>> On 7/21/23 03:32, Bonita Montero wrote:
>>>>>> <snip />
>>>>>>
>>>>>> If you're know C++ halfway you're multiple times faster than
>>>>>> with C, where you have to deal with every details yourself.
>>>>>
>>>>> Okay, where's your evidence for that?
>>>>
>>>> Show me the C-code for that:
>>>>
>>>> vector<string> vs;
>>>>
>>>> void fn( char const *str )
>>>> {
>>>>      vs.emplace_back( str );
>>>> }
>>>>
>>>> Thats just an example how convenient the STL is. Imagine what effort
>>>> you need to do the exponential growth of the vector yoursel. And you
>>>> don't need to deal with the errors of emplace_back where they happen,
>>>> but just catch bad_alloc some call levels above.
>>>> C++ is full of such convenient features which make a lot of work in C.
>>>
>>>
>>> If you going to use a function anyway, and not special syntax like vs
>>> += str, then you can emulate this in C easily. Sure you need a few
>>> dozen lines of code, but how big is the STL that you'd need to
>>> compile into every program.
>>
>> Show me how to do what I did in C. The above code increases the size
>> of the vector, thereby increasing the capacity exponentially (amortized
>> constant overhead) if necessary, constructs the string-object, thereby
>> allocating the storage of the string and if that fails the capacity
>> remains and the size is the old. That's a lot of work you'd have to
>> do in C over and over since it lacks the language facilites to to
>> that as convenient.
>
> I misunderstood your code to be defining a string which it then appends
> to, that's how clear it was!
>
> So my C equivalent created a suitable string type which it then appended
> to in a loop like this:
>
>     appendsv(s, "Hello");
>
> The whole C 'library' to create, append to and free such a type was 50
> lines of code.

In C++ it is one emplace_back and everythin happens as efficient as
possible. And you won't happen to manage exponential growth with 50
lines of code. And with iterator debugging you get use-after-free
and out-of-bounds debugging for free while debugging.
What C++ provides can't be resembled in C in the same convenient way.

>
> I then compared it in speed with a C++ version that did the same thing:
>
>  #include <iostream>
>  using namespace std;
>
>  string vs;
>
>  int main(void) {
>     for (int i=0; i<100000000; ++i)
>         vs +="Hello";
>
>      std::cout << vs.size();
>  }
>
> Optimised, it ran in 0.8 seconds. My optimised C ran in 0.55 seconds.
>
> BTW if I leave off the `()` at the end of that C++ code, I get 400 lines
> of impenetrable error messages.

Am 22.07.2023 um 17:51 schrieb fir:
> sobota, 22 lipca 2023 o 17:42:49 UTC+2 Bonita Montero napisał(a):
>> Am 22.07.2023 um 17:18 schrieb fir:
>>
>>> i told you writing such things in c by hand is few lines of code, ...
>>
>> You don't understand what the C++ containers do. If there wouldn't
>> be a large productivity ehancement with C++ over C people would use C.
>> You for sure never programmed professionally.
>
> i think people dont use c becouse its to good and to hard for them

No, it's because development in C costs multiple times more.
C is easy to learn, I've learned it when I was 14 in a week.
But writing large programs with that is hard because you've
to deal with every detail yourself.

> rest unread

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.

On 21/07/2023 17:14, Bart wrote:>
> On 21/07/2023 13:52, David Brown wrote:
> > On 21/07/2023 12:21, Bart wrote:
> >> On 21/07/2023 02:28, Keith Thompson wrote:
> >> > Bart <bc@freeuk.com> writes:
> >> >> On 21/07/2023 00:58, Keith Thompson wrote:
> >> >>> No, it's not. It's exactly the output the program produced
when I
> >> >>> compiled and ran it.
> >> >>> Please explain what you mean by "fake result". Are you
> insinuating
> >> >>> that
> >> >>> I lied about it?
> >> >>
> >> >> No. gcc on my machine hard-codes that output without bothering to
> >> >> execute the comparison to see what the hardware does with it.
> >> >
> >> > Are you saying that that's what you meant by "fake result"?
Are you
> >> > saying there's something "fake" about not emitting an ADD
> >> instruction in
> >> > response to a C "+" operation? Is evaluating 2+2 at compile time
> >> > "fake"?
> >>
> >> Transforming 2+2 is more acceptable since the result is always going
> >> to be consistent. It is not controversial.
> >
> > If it is merely "more" acceptable, then it is still controversial.
There
> > will be people who don't understand how the C language works who
feel it
> > should be translated into assembly instructions to add 2 and 2.
>
> 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.

>
> Actually it is also required for ?:
>
Would you care to elaborate? There's nothing special about ?:

>
> > Why would you think it would do that? There's nothing
> > hardware-dependent in Keith's program.
> >
> > When I am investigating how a compiler treats particular code
pieces, I
> > usually don't bother running it at all on any hardware - it's a
lot more
> > efficient and insightful (to me) to use godbolt and look at the
> > generated assembly. The hardware is irrelevant,
>
> The generated assembly depends entirely on the hardware.
True. But optimisations like the ones under discussion do not, and I
find them easier to see with godbolt. It is also very easy to check
different compilers, letting you see the effect of different hardware. I
think we can all read some basic x86-64 assembly.

>
> > If you had looked up instead, you'd have seen Keith's point flying
over
> > your head.
>
> I suspect Keith had not even bothered looking at the output, whether
> running on a real machine, or even at the generated code.
>
It would not occur to me to accuse Keith of lying. Even if he were the
kind of character who might lie, why would he do so for something so
easily checked?

Personally, /I/ might not have bothered running such code - I might not
even have bothered using godbolt, because I know how gcc handles these
things. But I would not then have claimed that I /had/ run it.

> Some of us are more practically minded.
>
> (I think that of those discussing this here, I'm the only one who has
> had to generate real code for real machines for real applications, from
> source code like this. )
And I think that is irrelevant. We are discussing C, undefined
behaviour, and demonstrating with real-world handling of it in
real-world compilers. Little experiments with a single very limited
compiler are not important - not to the theory, obviously, but not in
practice either since practically no one uses your tools. (As always,
don't take that as mockery of your tools - it's just facts. Users of
gcc outnumber users of your compiler by about a million to one.)

>
>
> >> It's a like taking a program that calculates and prints fib(36), and
> >> then discovering that the winning compiler or interpreter is only
> >> emitting puts("14930352") and not doing the actual work.
> >>
> >
> > And that would be perfectly reasonable. We already know you have no
> > idea how to benchmark tools.
>
> And that comment suggests *you* have no idea! Recursive Fibonacci is a
> famous benchmark that involves very large numbers of function calls.
> That allows you to compare how languages and implmentations cope.
Yes, that's true. But /I/ know how to run a benchmark of Fibonacci
implementations. You don't, as you have demonstrated many times before,
and then followed by complaints about gcc not playing fair.

>
> One that always takes 0 seconds because it has completely elided the
> user's code would be useless.
And that's why you don't know how to benchmark tools.

>
> > Different code could give different results. Different versions
of gcc
> > could give different results. Different flags could give different
> > results.
>
> On the same hardware.
Yes, that's UB for you.

>
> > It's undefined behaviour - only a fool would expect some
> > particular consistent choice of output. /That/ is the point. It
would
> > be nice if you tried harder to understand.
>
> Apparently C23 has finally admitted that signed integers predominantly
> use two's complement representation. But they have to keep overflow as
> UB, *BECAUSE* of compilers like gcc which have invested so much into
> exploiting it.
No, they keep signed integer overflow as undefined behaviour because
there is no useful definition of what it would do, and keeping it as UB
gives programmers useful tools - it helps them find errors in their code
more easily, it makes it easier to reason about the code, and it gives
them more efficient results. That is why the solid majority of voters
in the C standards committee (and the C++ committee, who made a similar
change to fix on two's complement representation) did not want wrapping
overflow.

>
> 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 wrapping is a side-effect of efficient ALU hardware
implementation, nothing more. It's not something you want in a language.

>
> >> That is, comparing INT_MIN with INT_MAX. Because if you do this:
> >>
> >> int b = INT_MAX;
> >> int a = b+1; // yields INT_MIN even with gcc
> >
> > It /might/ yield INT_MIN. It might not.
> The probablity is near 100% that it will do so on x64 and likely most
> other two's complement machines.
No, it is not. The hardware does not define the language.

>
> If you had to put money on what the output might be here:
>
> int a=INT_MAX;
> a=a+1;
> printf("%d\n", a);
>
> what would you go for?
I wouldn't - plain and simple. It makes no sense to bet on something
that does not have a defined behaviour!

> If the program was run again, would you make the
> same choice, or would you genuinely think the result might be different?
> I suspect I might win a lot of money from you!
I do agree that it's very unlikely that you'd get different outputs on
different runs with a simple case like this. On a more complex case,
you might get different outputs with seemingly irrelevant changes to the
input, when there is UB involved. I have seen cases where apparently
unrelated changes to other parts of the source code have affected the
output in unpredictable ways due to UB.

>
> Some of us are realists. However, even I would be hesitant of putting
> that into a real program, but /because/ of the reputation of C compilers
> regarding overflow.
I am a realist too - that's why I don't put stupid and meaningless
constructs in my source code (at least, not knowingly!)

Am 22.07.2023 um 17:49 schrieb Malcolm McLean:

> You are right here. For example my GIF file code, implemented in pure C,
> uses a red black tree to mkae the LZW codec efficient. That was a lot of
> work (htouhg the tree is written genrically and can be recycled). In C++,
> you can get the same functionality for free with an STL set. Where you
> need a structure other than an array, C++ does have a clear advantage.

Keep care ! Red-black-trees are usually faster if you have about
the same number of insertions vs. inserts and deletes. If you
look up mostly an AVL-tree is faster. And if the map is large
enough that it doesn't fit into cache and you have mostly cache
misses while accessing the nodes an AVL-tree is always faster
since the nodes can be reached with shorter paths.
STL's map is usually implemented as a red-black-tree.
I've developed a similar C++20 container with an AVL-tree.

On 21/07/2023 22:06, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
> [on mixed-type arithmetic]
>
>> Banning mixed '+' means not being able to do things like u+1.
>
> (where u is a variable with an unsigned type -- say unsigned int)
>
> No, there are solutions for such cases. It would be possible to pick
> the result type from those involved in the expression by allowing all
> literal constants to be polymorphic. The rules, in a C-like language
> would say that, since all the constant sub-expressions have values that
> can be represented in the unsigned type, the result would be unsigned.
>
> You would still have to ban
>
> int i = 1; unsigned u = 42;
> ...
> u + i
>
> because type errors should be diagnosed at compile time.
>

Ada does this - constants written out literally in source code are
polymorphic and adapt their type according to the context. (I
discovered this in a discussion about overloading - in Ada, you can have
return-type overloading as well overloading on function argument like in
C++.)

Bonita Montero ha scritto:
> Am 22.07.2023 um 17:45 schrieb jak:
>
>> <https://github.com/Mashpoe/c-vector/blob/master/vec.c>
>
> Having the same facilities like in C is inconvenient and slower.
> With generic containers you have specialized code for each type.
> With real OOP you have a much more convenient usage. With RAII
> you have initialization and creation in one place and you don't
> have to care for cleanup. With excpetions you won't have to care
> for the errors where they happen but just in a central place.
>
>

You asked for an example and I found an example for you. Even I admit
that you can write much better code than the one shown from example.
But let me tell you that your trust in the C++ standard libraries is
misplaced for both speed and security. This can be demonstrated by the
fact that heavy C++ users very often rewrite the standard library
containers. To give you an example Unreal Engine has replaced the (std)
vector with the "TArray". This is because when writing games you have to
run fast.

On 22/07/2023 12:41, Bart wrote:
> On 22/07/2023 05:49, Malcolm McLean wrote:
> > On Friday, 21 July 2023 at 23:03:15 UTC+1, Bart wrote:
> >> On 21/07/2023 22:34, Keith Thompson wrote:
> >>> Bart <b...@freeuk.com> writes:
> >>>> On 21/07/2023 17:56, David Brown wrote:
> >>>>> On 21/07/2023 17:40, Bart wrote:
> >>>>>> i32 etc are not C type names, they are handy colloquialisms that
> >>>>>> everyone understands (except Ben and Keith possibly).
> >>>>>
> >>>>> We all understand them - we don't like them. They are utterly
> pointless
> >>>>> abbreviations.
> >>>>
> >>>> I post in other forums and nobody has any problem with them, no
> matter
> >>>> what language is the topic. To repeat: they are not official C types.
> >>>> `i32` is a convenient, lingua franca way of saying `signed 32-bit
> integer`.
> >>>
> >>> Other forums aren't dedicated to the C language.
> >> Whatever the language and whatever its actual denotations, everyone
> >> understands what I mean by i32 or sometimes int32. There are fewer
> >> pedantics than in this forum.
> >>>> Alternately I can write `unsigned long long int` in place of `u64`,
> >>>> I'm sure that would make everyone happy.
> >>>
> >>> Why are you pretending not to know that unsigned long long is not
> >>> necessarily exactly 64 bits?
> >> Is uint64_t guaranteed to be exactly 64 bits? Even on non-64-bit
> hardware?
> >>>
> >>>> Obviously I can't write `uint64_t` since that would only be
> meaningful
> >>>> if `stdint.h` has been processed, something that cannot be determined
> >>>> in an informal discussion in English.
> >>>
> >>> You can't be serious.
> >> Dead serious:
> >>
> >> uint64_t abc;
> >>
> >> gcc says:
> >>
> >> error: unknown type name 'uint64_t'
> >>
> >> Pedantic, yes, but so are you lot being. But if a typedef for uint64_t
> >> can be assumed, why not one for u64?
> >>
>
> > This was a nuisance. Some implementations had stdint.h, others did not,
> > and so you had to use conditional defines to get the types. It was
> tempting
> > to roll your own.
> > Also, the situations where you genuinely need a type of known width are
> > rare.
>
> So the choice is to use...? In my languages `int` is 64 bits, which can
> represent pretty much everything.

Just because you don't actually /need/ a type of specific size, does not
mean you don't use them - they may be convenient, even if they are
slightly overspecified.

Usually types such as "int_fast32_t" or "uint_fast64_t" more accurately
describe what you want. But some programmers will often write "int32_t"
and "uint64_t" - for good reasons or less good ones. I am quite happy
with the standard names for the fixed size types, but I do find the
"fast" type names a bit cumbersome.

It is also common to use "int" and "long" - they have their guaranteed
sizes. And since code is not usually highly portable, you may have more
information - if you are using POSIX calls in your code or writing for
Windows, you know "int" is 32-bit.

>
> In C, it is 32 bits, which is much more limiting.

No, "int" is not 32-bit in C. In many C implementations it is, and a
lot of C code is able to assume it is 32-bit because the code is already
limited portability. But on small systems (regularly used today), it is
16-bit, and on a few niche systems (such as Cray-1) it is 64-bit.

> But the next size up
> is not obvious: `long long int`? Too long! `long`? It might be only 32
> bits still. `int64_t`? But that is now the fixed size type you wanted to
> avoid!

I can't speak for Malcolm, but I personally would not say fixed size
types are something to avoid. But it is still fair to say you don't
actually /need/ to know the exact size of a type in most circumstances -
you merely need to know that it is big enough for the values you put in it.

Often for cases where you need a big integer type, there is already a
more suitably named standard type such as "size_t".

And some people like to use their own application-specific type names
for different purposes, making it easier to keep track of what things
actually are. (This is much more common in C++ than in C, where you can
make strong types in this way.)

>
>
> > However nowadays it's rare to come across a compiler that doesn't
> have stdint.h.

<stdint.h> has been standard since C99, and was common in pre-C99
compilers. You have to be dealing with /very/ old tools not to have
<stdint.h>.

> > Whilst the names are ugly, it's better to have standard names than to
> define your
> > own. Otherwise you get a mess as every third party defines their own
> fixed width
> > types.
>
> Many programs and libraries still define their own types, sometimes on
> top of stdint.h. So you still get that mess.

Some do, yes - many programs and libraries have a history stretching
back before C99.

>
> And where they don't, you have source which is such a sea of `uint64_t`
> that you can hardly make out the real code:
>
>     int32_t fn(int64_t a, int64_t b, int64_t c);
>
> Compare with:
>
>     i32 fn(i64 a, i64 b, i64 c);

Really? /That/ is your argument now? I could agree with a lot of what
you said earlier, and I think it is a shame that the commonly used
integer type in modern C on x86 systems is not 64 bits. But arguing
that saving a few letters is an advantage is pretty pathetic.

>
> or even, if you could do this in C (you can't):
>
>     i32 fn(i64 a, b, c);
>
> Here you can easily see, even in black and white, that there are three
> parameters a, b, c which all share the same type. To me, C syntax makes
> things needlessly elaborate.
>
>

Am 22.07.2023 um 19:00 schrieb jak:
> Bonita Montero ha scritto:
>> Am 22.07.2023 um 17:45 schrieb jak:
>>
>>> <https://github.com/Mashpoe/c-vector/blob/master/vec.c>
>>
>> Having the same facilities like in C is inconvenient and slower.
>> With generic containers you have specialized code for each type.
>> With real OOP you have a much more convenient usage. With RAII
>> you have initialization and creation in one place and you don't
>> have to care for cleanup. With excpetions you won't have to care
>> for the errors where they happen but just in a central place.
>>
>>
>
>
> You asked for an example and I found an example for you. ...

I don't need such an example I simply wanted to say that doing
the same needs much more effort in C and if you have such a lib
it's still

> But let me tell you that your trust in the C++ standard libraries
> is misplaced for both speed and security

STL-code's performance is nearly optimal. And with iterator
debugging it's easier to write secure code as in C.

> This can be demonstrated by the fact that heavy C++ users
> very often rewrite the standard library containers.

Almost no one does this.

> To give you an example Unreal Engine has replaced the
> (std) vector with the "TArray". This is because when
> writing games you have to run fast.

The only thing that vector does not optimal is to default
initialize any content. I have my own ndi_t wich is an
encapsulation of any type without default-initialization.

Bonita Montero ha scritto:
> Am 22.07.2023 um 19:00 schrieb jak:
>> Bonita Montero ha scritto:
>>> Am 22.07.2023 um 17:45 schrieb jak:
>>>
>>>> <https://github.com/Mashpoe/c-vector/blob/master/vec.c>
>>>
>>> Having the same facilities like in C is inconvenient and slower.
>>> With generic containers you have specialized code for each type.
>>> With real OOP you have a much more convenient usage. With RAII
>>> you have initialization and creation in one place and you don't
>>> have to care for cleanup. With excpetions you won't have to care
>>> for the errors where they happen but just in a central place.
>>>
>>>
>>
>>
>> You asked for an example and I found an example for you. ...
>
> I don't need such an example I simply wanted to say that doing
> the same needs much more effort in C and if you have such a lib
> it's still
>
> > But let me tell you that your trust in the C++ standard libraries
> > is misplaced for both speed and security
>
> STL-code's performance is nearly optimal. And with iterator
> debugging it's easier to write secure code as in C.
>
> > This can be demonstrated by the fact that heavy C++ users
> > very often rewrite the standard library containers.
>
> Almost no one does this.
>
> > To give you an example Unreal Engine has replaced the
> > (std) vector with the "TArray". This is because when
> > writing games you have to run fast.
>
> The only thing that vector does not optimal is to default
> initialize any content. I have my own ndi_t wich is an
> encapsulation of any type without default-initialization.

Since this time you almost gave me reason, I don't insist and I keep my
score point.
:^D

On 22/07/2023 17:24, Bonita Montero wrote:
> Am 22.07.2023 um 17:48 schrieb Bart:

>> I misunderstood your code to be defining a string which it then
>> appends to, that's how clear it was!
>>
>> So my C equivalent created a suitable string type which it then
>> appended to in a loop like this:
>>
>>      appendsv(s, "Hello");
>>
>> The whole C 'library' to create, append to and free such a type was 50
>> lines of code.
>
> In C++ it is one emplace_back and everythin happens as efficient as
> possible. And you won't happen to manage exponential growth with 50
> lines of code.

That's exactly what it does do. In fact, that's the problem of trying to
do it in 50 lines, you want to reduce the growth curve when it gets to a
a certain level. That would need a 3-4 more lines.

Having automatically-managed arrays is convenient, but in the programs I
write at this level, would only be a small part of a project.

It would not be worth switching everything to a massively more
complicated and slow-to-compile language.

Am 22.07.2023 um 20:02 schrieb Bart:

> Having automatically-managed arrays is convenient, but in the programs I
> write at this level, would only be a small part of a project.

Absolutely not. Growing vectors are extemely common.

> It would not be worth switching everything to a massively more
> complicated and slow-to-compile language.

The language is more complex, but if you know the language
solving your tasks becomes a lot more more easier.

On 21/07/2023 11:29, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> The compiler knows that for any int, "n + 1" is bigger than "n". It
>> generates code accordingly.
> [...]
>
> Quibble: for any int value *for which n + 1 is defined*, n + 1 is
> greater than n. (And for any int value for which n + 1 is not defined,
> which is only INT_MAX, UB means the compiler can do what it likes.)
>

(Just for information - I appreciate these "quibbles" and little
corrections from you, and others. I don't usually reply to them,
because they are correct and stand on their own. If I disagreed, I'd
reply, but I don't think an agreement post would add anything but more
posts to an already huge thread. Usually I already know the point being
made, but omitted it in my post because putting in all the detail can
hide the real meaning of the post. But it can be a good thing to make
these "quibble" posts for others reading the thread.)

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

> On 21/07/2023 22:06, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> [on mixed-type arithmetic]
>>
>>> Banning mixed '+' means not being able to do things like u+1.
>> (where u is a variable with an unsigned type -- say unsigned int)
>> No, there are solutions for such cases. It would be possible to pick
>> the result type from those involved in the expression by allowing all
>> literal constants to be polymorphic. The rules, in a C-like language
>> would say that, since all the constant sub-expressions have values that
>> can be represented in the unsigned type, the result would be unsigned.
>> You would still have to ban
>> int i = 1; unsigned u = 42;
>> ...
>> u + i
>> because type errors should be diagnosed at compile time.
>
> Ada does this - constants written out literally in source code are
> polymorphic and adapt their type according to the context. (I discovered
> this in a discussion about overloading - in Ada, you can have return-type
> overloading as well overloading on function argument like in C++.)

As does Haskell. But it can be confusing: [3.4, 1] is just a list, but
[3.4, floor 1] is a type error.

--
Ben.

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.

<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? Making some arithmetic operations undefined results is a
structure with no simple mathematical description.

> 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.

--
Ben.

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 think to say you learn c you need at least write 100k lines (which takes a 10 months of intense coding day bay day by most day time, yet skipping some initial 30k you need to probably write and send to trashbin when learning basics) or better 200k or 300k - and this is not all becouse to learn c you need tu understand it deeply, and learn some good style

sobota, 22 lipca 2023 o 18:24:37 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 17:48 schrieb Bart:
> > On 22/07/2023 15:32, Bonita Montero wrote:
> >> Am 22.07.2023 um 15:53 schrieb Bart:
> >>> On 22/07/2023 14:00, Bonita Montero wrote:
> >>>> Am 22.07.2023 um 07:30 schrieb Blue-Maned_Hawk:
> >>>>> On 7/21/23 03:32, Bonita Montero wrote:
> >>>>>> <snip />
> >>>>>>
> >>>>>> If you're know C++ halfway you're multiple times faster than
> >>>>>> with C, where you have to deal with every details yourself.
> >>>>>
> >>>>> Okay, where's your evidence for that?
> >>>>
> >>>> Show me the C-code for that:
> >>>>
> >>>> vector<string> vs;
> >>>>
> >>>> void fn( char const *str )
> >>>> {
> >>>> vs.emplace_back( str );
> >>>> }
> >>>>
> >>>> Thats just an example how convenient the STL is. Imagine what effort
> >>>> you need to do the exponential growth of the vector yoursel. And you
> >>>> don't need to deal with the errors of emplace_back where they happen,
> >>>> but just catch bad_alloc some call levels above.
> >>>> C++ is full of such convenient features which make a lot of work in C.
> >>>
> >>>
> >>> If you going to use a function anyway, and not special syntax like vs
> >>> += str, then you can emulate this in C easily. Sure you need a few
> >>> dozen lines of code, but how big is the STL that you'd need to
> >>> compile into every program.
> >>
> >> Show me how to do what I did in C. The above code increases the size
> >> of the vector, thereby increasing the capacity exponentially (amortized
> >> constant overhead) if necessary, constructs the string-object, thereby
> >> allocating the storage of the string and if that fails the capacity
> >> remains and the size is the old. That's a lot of work you'd have to
> >> do in C over and over since it lacks the language facilites to to
> >> that as convenient.
> >
> > I misunderstood your code to be defining a string which it then appends
> > to, that's how clear it was!
> >
> > So my C equivalent created a suitable string type which it then appended
> > to in a loop like this:
> >
> > appendsv(s, "Hello");
> >
> > The whole C 'library' to create, append to and free such a type was 50
> > lines of code.
> In C++ it is one emplace_back and everythin happens as efficient as
> possible. And you won't happen to manage exponential growth with 50
> lines of code. And with iterator debugging you get use-after-free
> and out-of-bounds debugging for free while debugging.
> What C++ provides can't be resembled in C in the same convenient way.
> >
sure as efficient as possinle, what with i once give example of how this pony fast is

it was sorting 1M of ints it was 110 ms (on old machine i tested) on c++ stl sort
whare handrafted c code i gogled was about 27 ms or something

guess why its general tendency and your code will beat libs (though gnereally result may not be as such impressive)

sobota, 22 lipca 2023 o 19:06:45 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 19:00 schrieb jak:
> > Bonita Montero ha scritto:
> >> Am 22.07.2023 um 17:45 schrieb jak:
> >>
> >>> <https://github.com/Mashpoe/c-vector/blob/master/vec.c>
> >>
> >> Having the same facilities like in C is inconvenient and slower.
> >> With generic containers you have specialized code for each type.
> >> With real OOP you have a much more convenient usage. With RAII
> >> you have initialization and creation in one place and you don't
> >> have to care for cleanup. With excpetions you won't have to care
> >> for the errors where they happen but just in a central place.
> >>
> >>
> >
> >
> > You asked for an example and I found an example for you. ...
>
> I don't need such an example I simply wanted to say that doing
> the same needs much more effort in C and if you have such a lib
> it's still

you show here pitfals in your logic and for me it is a correspondence youre so mass-driven (you belive what is popular is good - which is oposite to real,
the 'marked' for good things is imo (partially metaphorificaly speaking) 10 times
more small (or even yet less) than 'market' for medicore-crappy things - this is becouse
for quality of taste and intelligence of users (coders in such respect),

> > But let me tell you that your trust in the C++ standard libraries
> > is misplaced for both speed and security
> STL-code's performance is nearly optimal. And with iterator
> debugging it's easier to write secure code as in C.
> > This can be demonstrated by the fact that heavy C++ users
> > very often rewrite the standard library containers.
> Almost no one does this.
> > To give you an example Unreal Engine has replaced the
> > (std) vector with the "TArray". This is because when
> > writing games you have to run fast.
> The only thing that vector does not optimal is to default
> initialize any content. I have my own ndi_t wich is an
> encapsulation of any type without default-initialization.

sobota, 22 lipca 2023 o 23:16:10 UTC+2 fir napisał(a):
> sobota, 22 lipca 2023 o 19:06:45 UTC+2 Bonita Montero napisał(a):
> >
> > I don't need such an example I simply wanted to say that doing
> > the same needs much more effort in C and if you have such a lib
> > it's still
> you show here pitfals in your logic and for me it is a correspondence youre so mass-driven (you belive what is popular is good - which is oposite to real,
> the 'marked' for good things is imo (partially metaphorificaly speaking) 10 times
> more small (or even yet less) than 'market' for medicore-crappy things - this is becouse
> for quality of taste and intelligence of users (coders in such respect),

market ofr stupidity (stupid tv , stupid music, stupid games, stupid programming, stupid books etc) is much more large than market for good alternative, music games, books, programming languages - this is becouse the clients are on average stupid and need stupid content not ambitious

companies in turn need to hare people, as thet are average they hire such people as they can hire...not the elite