sobota, 22 lipca 2023 o 23:20:42 UTC+2 fir napisał(a):
> 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

but ofc thinking that what is popular is good (not that what is realy good is good but what popular is good) is funny lame (sadly lame, funny i mean somewhat ironically - it is kinda gunny by the fact how many untrue and naive it is)

sobota, 22 lipca 2023 o 23:25:19 UTC+2 fir napisał(a):
> sobota, 22 lipca 2023 o 23:20:42 UTC+2 fir napisał(a):
> > 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
> but ofc thinking that what is popular is good (not that what is realy good is good but what popular is good) is funny lame (sadly lame, funny i mean somewhat ironically - it is kinda gunny by the fact how many untrue and naive it is)

this is just why c++ ebcome more popular ..simply becouse its stupid

with c it was different coze there is a think called golden era in a golden era (l;ike golden era of hip-hop, compouting, grunge music and more) there is not yet crowd but more narrow society and they are focused on real things and my get what is best - crowd appears with time and by its choices makes that marketing goes for mass tupidity and good things becoma a side river and maybe even vanishes sometimes

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

[on reading an uninitalized automatic object]

> Either Annex J is incorrect, or accessing an uninitalized
> automatic object is UB even if the object cannot possibly hold a
> trap representation. (I'd be satisfied either way; I'd like the
> standard to be internally consistent.)
>
> Perhaps someone else can find something in the standard that I've
> missed.

The claim in Annex J is a red herring. I will try to post soon
in comp.std.c with elaboration.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> [...]
>>
>>> 6.2.6.1 p5 says (in part)
>>>
>>> "Certain object representations need not represent a value of
>>> the object type. If such a representation is read by an lvalue
>>> expression that does not have character type, the behavior is
>>> undefined."
>>
>> Yes, but that's not why reading an uninitialized int object has
>> undefined behavior.
>>
>> If we know that, for example, CHAR_BIT==8, sizeof(int)==4,
>> INT_MAX==2147483647, and INT_MIN==-INT_MAX-1, then we can
>> rigorously infer that int has no padding bits, and no trap
>> representations.
>>
>>> Elsewhere we can find wording to say that uninitialised local
>>> variables and newly allocated storage contain indeterminate
>>> representations. This includes the possibility of non-value
>>> representations.
>>
>> Yes, but even if the memory happens to contain a valid
>> representation for type int, the representation is still
>> indeterminate. Indeterminacy is not defined by the bits making up
>> the representation.
>
> I know that indeterminacy is not defined by the bits, but I could
> not find any normative text that could lead one to conclude that
> accessing such an object is undefined from the indeterminacy
> itself. Where is it?
>
>> An indeterminate value is by definition "either an unspecified
>> value or a trap representation". Annex J lists "The value of an
>> object with automatic storage duration is used while it is
>> indeterminate" as an example of undefined behavior.
>
> Annex J is not normative text. And if we take Annex J as accurately
> conveying the intent, then the actual case being discussed (an
> allocated object with indeterminate representation) is, in fact, not
> undefined behaviour! Is that what was intended?

The discussion is confused because the C standard itself has
been confused. The statement in Annex J is misleading (I
wouldn't go so far as to say wrong, but it should be viewed
more as a rule of thumb than being completely accurate).

More complete explanation to be posted (I hope soon) in
comp.std.c.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> It's best to make things obvious to someone who knows a bit about programming
> but isn't necessarily very familiar with C.
>
> int fn(int a, int b, int c)
>
> is pretty obviously a function which takes three integers and returns an integer
> and if you don't know C you can easily guess that. Difficulties mount when you
> get away from the core language.

No. The audience for any C code I write is people who *are* familiar
with C. Catering to potential readers who don't know the language is
foolish.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/07/2023 21:21, Ben Bacarisse wrote:

[concerning various items in Annex J.2 (on undefined behavior)]

Annex J is more of a useful summary than absolutely accurate,
and my understanding is that the ISO C committee acknowledges
this view. As always, normative text takes precedence over
informative text if there is a conflict.

>>> Thus it's tempting to consider *q as being "almost always
>>> well-defined" but since my view is that the semantics of a
>>> construct should include all the possibilities, the only meaning
>>> we can put on "int p; printf("%d\n", p);" is "none".
>>
>> "No meaning" is, of course, just another way of saying "UB". But
>> it's important, I think, to note that it is UB even on systems
>> where non-value representations are not possible for ints. (i.e.,
>> almost every real-world system.)
>
> We should only note it if it's true! Is it?

It isn't. Further explanation to follow in comp.std.c.

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
>> 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.

Except that an overflow in a constant expression is a constraint
violation, and must be diagnosed at compile time.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 22/07/2023 18:05, David Brown wrote:
> On 22/07/2023 12:41, Bart wrote:
>> 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.

This is where we keep going around in circles with C.

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

So, ints have been 32 bits on my machines of interest for DECADEs, and
likely to remain so.

I don't really to need to keep qualifying it by saying Oh, ints are only
guaranteed to be 16 bits or more, so they might be 37 bits. Or, Use
'long' when you 32 bits or more, but they might end up as 64 bits - or more!

Or we use int32_t, and then we have a zoo of format codes to sort out if
we want to print anything out.

It is really tedious. So, just to save time in future, all posts of mine
will assume:

char types are 8 bits
short is 16 bits
int is 32 bits
long is never used (in my C compiler, it was a synonym for 'int')
long long is 64 bits

Maybe I should have done that long ago!

BTW here is a chart of what my personal tools have assumed over the
years and how they have progressed; these are the sizes of
non-width-specific types 'byte', 'int' and 'real' (floating point):

Machine word Byte Int Real

8 (Z80) 8 16 24/32 bits (early version used 24 bits)
16 (8086) 8 16 32
32 (80386) 8 32 32
64 (x64) 8 64 64

Over 35+ years, 'int' has changed twice; 'real' has changed once. In C
for those same targets, 'int' has changed once; float/double have not
changed (I assume they have been 32 and 64 bits).

So my product has been more volatile than C, and yet it is with C that
we have to pussy-foot around the exact size of 'int'!

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

Hence int = 64 bits. (Didn't Malcolm used to do a lot of campaigning for
64-bit ints? I didn't agree then; I do now!)

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

No need; use the 64-bit type. Unless you really need to go to 2**63 and
above in magnitude, then you might need the unsigned variety.

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

In GTK2 you find types like guint32.

In SDL3 you see types like Uint32 and lines like this:

typedef uint32_t Uint32;
typedef uint32_t khronos_uint32_t;

In OpenGL, there is GLint as an alias for int (perhaps it assumes a size
of int, and it is redefined on platforms where it it different).

I see this all the time; they can't all date back 25 years, and SDL3 is
quite recent.

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

The point is that in that parameter list, those type names completely
dominate. So it affects readability. Compare with my last example:

>>
>> i32 fn(i64 a, b, c);

This is what code could look like: it's uncluttered, and the
relationships are clear.

You obviously don't care about such matters. But C code often hurts my
eyes; my own examples have been too kind to show that!

Bart <bc@freeuk.com> writes:
> On 22/07/2023 18:05, David Brown wrote:
>> On 22/07/2023 12:41, Bart wrote:
[...]
>>> In C, it is 32 bits, which is much more limiting.
>>
>> No, "int" is not 32-bit in C.
>
> This is where we keep going around in circles with C.

No, this is where *you* keep going around in circles.

> In 1982 when I started on all this stuff in earnest, ints were 16-bits.

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.

[...]

> So, ints have been 32 bits on my machines of interest for DECADEs, and
> likely to remain so.

And you expect everyone else to care only about machines that are of
interest to you.

[...]

> It is really tedious. So, just to save time in future, all posts of
> mine will assume:
>
> char types are 8 bits
> short is 16 bits
> int is 32 bits
> long is never used (in my C compiler, it was a synonym for 'int')
> long long is 64 bits
>
> Maybe I should have done that long ago!
[...]

Expect less attention from me in the future.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> David Brown <david.brown@hesbynett.no> writes:
> [...]
>>> 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.
>
> Except that an overflow in a constant expression is a constraint
> violation, and must be diagnosed at compile time.

I'd forgotten that. But since I'm talking about non-sane
implementations that does mean that an expression must be evaluated.
For example, any expression involving only unsigned values will result
in a value that is in rage for the its.

--
Ben.

On 23/07/2023 00:38, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 22/07/2023 18:05, David Brown wrote:
>>> On 22/07/2023 12:41, Bart wrote:
> [...]
>>>> In C, it is 32 bits, which is much more limiting.
>>>
>>> No, "int" is not 32-bit in C.
>>
>> This is where we keep going around in circles with C.
>
> No, this is where *you* keep going around in circles.
>
>> In 1982 when I started on all this stuff in earnest, ints were 16-bits.
>
> 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.

So the computing world changes immeasurably between 1940 and 1982, but
apparently very little between then and now, at least regarding basic
machine architecture. Actually the 32-bit IBM 360 dates from 1964.

>> So, ints have been 32 bits on my machines of interest for DECADEs, and
>> likely to remain so.
>
> And you expect everyone else to care only about machines that are of
> interest to you.

And of interest to most people involved in systems programming. And of
interest to users of languages like C#, Java, D, Rust, Zig, Go, Nim and
Julia whose types all revolve around the same set of types I care about.

So, yeah, it is really only here that people are always banging on about
weird machine types, padding bits, and ones complement, to go with
EBCDIC. It's like we're still in the 1970s.

The set of types I'm talking about are so common, so widespread, that it
makes sense to assume that a discussion is about those unless someone
says otherwise.

But then, this 'forum' seems to be mainly about discussing the finer
points of the C standard than for anything actually practical.

> And you expect everyone else to care only about machines that are of
> interest to you.

I can turn it around and say, you expect everyone else to care about
obsolete 1s complement 36-bit mainframes, DSPs, and processors that
barely have a stack or any RAM? That is a very niche world.

Am 22.07.2023 um 23:15 schrieb fir:
> 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 ...

No, the problem is that you narly can't program at all.

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

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.

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... youre bulshitter based on belifs
- yopu belive for example you learned c in a week ..it is clear show that
what you make is putting bulshit on usenet...

note i dont say you cant program
ability to programming even large and hard programs is quite paralllel to
bulshitting ... in turn i can program - though i not program much as i do
more other things (like some study on literature, which also takes years
so i have no tiem to only code) [i probbaly wrote about 300k lines in life so
its not much a lot, probably there are a peple who wrote over a milion] -
but besides programming i did a lot of specific theory around c language
and partially around general programing and what i do is not posting crap bulshit belifs like you.. you know language for mass of ponys but your generalisations are silly and in fact crazy .. you may come and repeat bulsit i cint program 100 times it wouldnt rise your IQ eben +1 and there is a chcnce it will lower it in meantime

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

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)

niedziela, 23 lipca 2023 o 09:58:49 UTC+2 fir napisał(a):
> 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
i mean thirteen (13)

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

niedziela, 23 lipca 2023 o 09:53:03 UTC+2 fir napisał(a):
> so i have no tiem to only code) [i probbaly wrote about 300k lines in life so

i was thinking on this = maybe less than 300k 200-300k, i would say
after thinking) (my now favorite orgasm, furia and green fire took 100k in sum)
but there are yet others to sum on few tens of k and yet others, but some i cant memoprize for size as it was on span of years

i not code that mych as coding eats life

niedziela, 23 lipca 2023 o 11:03:38 UTC+2 fir napisał(a):
>
> i not code that mych as coding eats life

what if you code so much bonita that it eats your brain?
typical vulgar and toxic pony-style thinking... i see correspondence with this vulgar thinking, being "mass driven" pony and talking bulshit on c/c++

obviously the sadnes of talking with bulshitter is no long to hold
when getting back to ma spaceship again ;c

sobota, 22 lipca 2023 o 23:33:18 UTC+2 fir napisał(a):
> with c it was different coze there is a think called golden era in a golden era (l;ike golden era of hip-hop, compouting, grunge music and more) there is not yet crowd but more narrow society and they are focused on real things and my get what is best - crowd appears with time and by its choices makes that marketing goes for mass tupidity and good things becoma a side river and maybe even vanishes sometimes

i wanted to say "side stream" (and before 'market' not 'marked')

> > > you shouldnt go in crapy 'non trivial' objects - use proper ..c is not for mimicking crap

btw, site thought is that if we say on containers in c we say on array of structures
- and in this context i think it is good to use word 'record' (record of data),
its quite usefull name..and saying just 'structures' in array or structures in vector or structures in container is worse ..better just say its reciords

as to vector even this name in pony ++ is silly.. vector is float3 and things like that,
for sure soem shouldnt name such array with methods (functions) for add/remove/resize as an vector... though maybe this array should have some name but i dont know proper name for this (may call it dynamic array or just container for a time)

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

Am 23.07.2023 um 11:18 schrieb fir:
> niedziela, 23 lipca 2023 o 11:03:38 UTC+2 fir napisał(a):
>>
>> i not code that mych as coding eats life
>
> what if you code so much bonita that it eats your brain?
> typical vulgar and toxic pony-style thinking... i see correspondence with this vulgar thinking, being "mass driven" pony and talking bulshit on c/c++
>
> obviously the sadnes of talking with bulshitter is no long to hold
> when getting back to ma spaceship again ;c

You must be nervous that you keep answering to yourself.

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.

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 you ratio of "producing lies" is quite high here, its notably higher than average to this group (which is not terribly bad in this aspect, i mean there is not a big lot of lies here, and thats fortunate)