kalevi@kolttonen.fi (Kalevi Kolttonen) writes:

> In other words, I did not know that the implementations
> can "override" UB (i.e. UB according to C stardard) and
> turn it into Implementation Defined behavior.

The phrasing here is somewhat incorrect. Undefined behavior
is a specification, not a state of being. If a particular
construct is specified in the C standard as being undefined
behavior, it is still undefined behavior even if there is an
extension (documented by an implementation of interest) that
gives the construct a well-defined semantics in that
implementation.

Similarly, implementation-defined behavior is a specification,
not a state of being. Any constructs stated in the C standard
to have ID behavior are always implementation defined, but no
others are, and there is nothing an implementation can do to
change that. I suggest using "implementation specific", a
term not defined by the C standard, to refer to behavior that
a given implementation specifies but is not (or might not be)
implementation defined.

> That kind of ignorance is not something to be proud of.

Neither is it something to be ashamed of. We were all
beginners once, even with a long history of programming
experience. I didn't take an active interest in the ISO C
standard for a decade or so after it was first ratified,
because it wasn't relevant to what I was doing at the
time. Moreover the terminology used in the C standard
is rather unintuitive, or even counter-intuitive, in some
cases, so some level of misunderstanding isn't surprising.

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.

sobota, 22 lipca 2023 o 14:57:32 UTC+2 Bonita Montero napisał(a):
> Am 21.07.2023 um 15:06 schrieb fir:
>
> > that is what you belive... but i think you dont know c ...
>
> I've been programming C when I guess that you didn't exist.
> > in c you dont need to deal with every detail ..
> Of course you neeed. You'd have to do anything manually the
> STL does or you. People don't use anything comparable in C
> since C doesn't has the features to be as covenient with
> that like with C++. Real OOP, RAII and exceptions make the
> life much easier.

writing a container in c which i better than vector for me is a metter of few lines of code

for example my container for bullets in game

void AddBullet(float x,float y, float angle,
float vspeed, int life, unsigned color, int type, int owner, float power)
{ static int index = 0;

bullet[index].x = x;
bullet[index].y = y;
bullet[index].enabled = 1;
bullet[index].angle = angle;
bullet[index].life = life;//life;
bullet[index].v = vspeed ;
bullet[index].type = type ;
bullet[index].owner = owner ;
bullet[index].power = power ;
bullet[index].color = color ;

for(int i=0; i<bullet_max;i++)
{
index++; if(index>=bullet_max) index-=bullet_max;
if(bullet[index].enabled==0) return;
}

ERROR_("Out OF Space in bullet[]");
}

this is for static allocated array where you may add and deleta things dynamically with addiionel few lines you make it dynamically resizable - but the static is often okay

and that is about your mythical blabling about advantages of crappy designed pony++

sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
> 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.

i dont know what is emplace back and what you mean exponentiol growth
but something like vector in c you do

struct ExpressionList { int x; int y; unsigned long long tag;};
static ExpressionList* expression_list1 = NULL;
static int expression_list1_size = 0;

void expression_list1_AddOne(int i, int j)
{
expression_list1_size++;
expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
expression_list1[expression_list1_size-1] = {i,j};
return ;
}

if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
reallock called each time is practically near zero cost so its quite okay to call it by one
(add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
terribly good and fast container suited for your needs)

sobota, 22 lipca 2023 o 15:53:15 UTC+2 Bart napisał(a):
> 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.

few lines not few dosens

(the containers i showed 1-2 post before ilustrate this (one is static with deletion/insertion) and one is dynamic with only groving but you can combine them in one) ... [they are my ovn personal invention btw]

Am 22.07.2023 um 16:10 schrieb fir:
> sobota, 22 lipca 2023 o 14:57:32 UTC+2 Bonita Montero napisał(a):
>> Am 21.07.2023 um 15:06 schrieb fir:
>>
>>> that is what you belive... but i think you dont know c ...
>>
>> I've been programming C when I guess that you didn't exist.
>>> in c you dont need to deal with every detail ..
>> Of course you neeed. You'd have to do anything manually the
>> STL does or you. People don't use anything comparable in C
>> since C doesn't has the features to be as covenient with
>> that like with C++. Real OOP, RAII and exceptions make the
>> life much easier.
>
> writing a container in c which i better than vector for me is a metter of few lines of code
>
> for example my container for bullets in game
>
> void AddBullet(float x,float y, float angle,
> float vspeed, int life, unsigned color, int type, int owner, float power)
> {
> static int index = 0;
>
> bullet[index].x = x;
> bullet[index].y = y;
> bullet[index].enabled = 1;
> bullet[index].angle = angle;
> bullet[index].life = life;//life;
> bullet[index].v = vspeed ;
> bullet[index].type = type ;
> bullet[index].owner = owner ;
> bullet[index].power = power ;
> bullet[index].color = color ;
>
> for(int i=0; i<bullet_max;i++)
> {
> index++; if(index>=bullet_max) index-=bullet_max;
> if(bullet[index].enabled==0) return;
> }
>
> ERROR_("Out OF Space in bullet[]");
> }
>
> this is for static allocated array where you may add and deleta things dynamically with addiionel few lines you make it dynamically resizable - but the static is often okay
>
> and that is about your mythical blabling about advantages of crappy designed pony++

You're not doing what an emplace_back() does. There's a lot of
complexity taken from you and you'd have to do that manually
over and over every time in C.

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.

sobota, 22 lipca 2023 o 16:29:29 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 16:10 schrieb fir:
> > sobota, 22 lipca 2023 o 14:57:32 UTC+2 Bonita Montero napisał(a):
> >> Am 21.07.2023 um 15:06 schrieb fir:
> >>
> >>> that is what you belive... but i think you dont know c ...
> >>
> >> I've been programming C when I guess that you didn't exist.
> >>> in c you dont need to deal with every detail ..
> >> Of course you neeed. You'd have to do anything manually the
> >> STL does or you. People don't use anything comparable in C
> >> since C doesn't has the features to be as covenient with
> >> that like with C++. Real OOP, RAII and exceptions make the
> >> life much easier.
> >
> > writing a container in c which i better than vector for me is a metter of few lines of code
> >
> > for example my container for bullets in game
> >
> > void AddBullet(float x,float y, float angle,
> > float vspeed, int life, unsigned color, int type, int owner, float power)
> > {
> > static int index = 0;
> >
> > bullet[index].x = x;
> > bullet[index].y = y;
> > bullet[index].enabled = 1;
> > bullet[index].angle = angle;
> > bullet[index].life = life;//life;
> > bullet[index].v = vspeed ;
> > bullet[index].type = type ;
> > bullet[index].owner = owner ;
> > bullet[index].power = power ;
> > bullet[index].color = color ;
> >
> > for(int i=0; i<bullet_max;i++)
> > {
> > index++; if(index>=bullet_max) index-=bullet_max;
> > if(bullet[index].enabled==0) return;
> > }
> >
> > ERROR_("Out OF Space in bullet[]");
> > }
> >
> > this is for static allocated array where you may add and deleta things dynamically with addiionel few lines you make it dynamically resizable - but the static is often okay
> >
> > and that is about your mythical blabling about advantages of crappy designed pony++
> You're not doing what an emplace_back() does. There's a lot of
> complexity taken from you and you'd have to do that manually
> over and over every time in C.

and what is that emplace back doin?

in c (when writing my game prototypes or compiler etc) i just might need a
container for my records that is dynamic (adds, deletes, iterations, eventuall resizing) and fast
- and thsi is what i need... i didnt noticed any need for emplace back, whatever it is

Am 22.07.2023 um 16:19 schrieb fir:
> sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
>> 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.
>
>
> i dont know what is emplace back and what you mean exponentiol growth
> but something like vector in c you do
>
>
> struct ExpressionList { int x; int y; unsigned long long tag;};
> static ExpressionList* expression_list1 = NULL;
> static int expression_list1_size = 0;
>
> void expression_list1_AddOne(int i, int j)
> {
> expression_list1_size++;
> expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
> expression_list1[expression_list1_size-1] = {i,j};
> return ;
> }
>
> if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
> need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
> reallock called each time is practically near zero cost so its quite okay to call it by one
> (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
> terribly good and fast container suited for your needs)

You don't even have a clue what C++ does for you with the above code.
Consider for example the exponential growth of the vector to keep the
number of reallocations small; that would be much work in C.

Am 22.07.2023 um 16:33 schrieb fir:
> sobota, 22 lipca 2023 o 16:29:29 UTC+2 Bonita Montero napisał(a):
>> Am 22.07.2023 um 16:10 schrieb fir:
>>> sobota, 22 lipca 2023 o 14:57:32 UTC+2 Bonita Montero napisał(a):
>>>> Am 21.07.2023 um 15:06 schrieb fir:
>>>>
>>>>> that is what you belive... but i think you dont know c ...
>>>>
>>>> I've been programming C when I guess that you didn't exist.
>>>>> in c you dont need to deal with every detail ..
>>>> Of course you neeed. You'd have to do anything manually the
>>>> STL does or you. People don't use anything comparable in C
>>>> since C doesn't has the features to be as covenient with
>>>> that like with C++. Real OOP, RAII and exceptions make the
>>>> life much easier.
>>>
>>> writing a container in c which i better than vector for me is a metter of few lines of code
>>>
>>> for example my container for bullets in game
>>>
>>> void AddBullet(float x,float y, float angle,
>>> float vspeed, int life, unsigned color, int type, int owner, float power)
>>> {
>>> static int index = 0;
>>>
>>> bullet[index].x = x;
>>> bullet[index].y = y;
>>> bullet[index].enabled = 1;
>>> bullet[index].angle = angle;
>>> bullet[index].life = life;//life;
>>> bullet[index].v = vspeed ;
>>> bullet[index].type = type ;
>>> bullet[index].owner = owner ;
>>> bullet[index].power = power ;
>>> bullet[index].color = color ;
>>>
>>> for(int i=0; i<bullet_max;i++)
>>> {
>>> index++; if(index>=bullet_max) index-=bullet_max;
>>> if(bullet[index].enabled==0) return;
>>> }
>>>
>>> ERROR_("Out OF Space in bullet[]");
>>> }
>>>
>>> this is for static allocated array where you may add and deleta things dynamically with addiionel few lines you make it dynamically resizable - but the static is often okay
>>>
>>> and that is about your mythical blabling about advantages of crappy designed pony++
>> You're not doing what an emplace_back() does. There's a lot of
>> complexity taken from you and you'd have to do that manually
>> over and over every time in C.
>
> and what is that emplace back doin?
>
> in c (when writing my game prototypes or compiler etc) i just might need a
> container for my records that is dynamic (adds, deletes, iterations, eventuall resizing) and fast
> - and thsi is what i need... i didnt noticed any need for emplace back, whatever it is

You're a n00b and you never understood C++.

sobota, 22 lipca 2023 o 16:32:28 UTC+2 Bonita Montero napisał(a):
> 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.

struct String {char* str; /*more fields*/};

static String* strings = NULL;
static int strings_size = 0;
int strings_addOne(char* str) { strings_size++; strings = (String*) realloc(strings, trings_size * sizeof(String) ); strings[strings_size-1].str = str;}

int main()
{ strings_addOne("ala");
strings_addOne("ma");
strings_addOne("kota");

for(int i=0; i<strings_size;i++) printf(strings[i].str);
} not checked for typos but it is about that, vector in c but better

sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 16:19 schrieb fir:
> > sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
> >> 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.
> >
> >
> > i dont know what is emplace back and what you mean exponentiol growth
> > but something like vector in c you do
> >
> >
> > struct ExpressionList { int x; int y; unsigned long long tag;};
> > static ExpressionList* expression_list1 = NULL;
> > static int expression_list1_size = 0;
> >
> > void expression_list1_AddOne(int i, int j)
> > {
> > expression_list1_size++;
> > expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
> > expression_list1[expression_list1_size-1] = {i,j};
> > return ;
> > }
> >
> > if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
> > need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
> > reallock called each time is practically near zero cost so its quite okay to call it by one
> > (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
> > terribly good and fast container suited for your needs)
> You don't even have a clue what C++ does for you with the above code.
> Consider for example the exponential growth of the vector to keep the
> number of reallocations small; that would be much work in C.

realloc does it for you
check this thread

https://groups.google.com/g/comp.lang.c/c/YXejwDRKSAQ/m/E8ka_jpAAgAJ

sobota, 22 lipca 2023 o 16:48:34 UTC+2 fir napisał(a):
> sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
> > Am 22.07.2023 um 16:19 schrieb fir:
> > > sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
> > >> 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.
> > >
> > >
> > > i dont know what is emplace back and what you mean exponentiol growth
> > > but something like vector in c you do
> > >
> > >
> > > struct ExpressionList { int x; int y; unsigned long long tag;};
> > > static ExpressionList* expression_list1 = NULL;
> > > static int expression_list1_size = 0;
> > >
> > > void expression_list1_AddOne(int i, int j)
> > > {
> > > expression_list1_size++;
> > > expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
> > > expression_list1[expression_list1_size-1] = {i,j};
> > > return ;
> > > }
> > >
> > > if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
> > > need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
> > > reallock called each time is practically near zero cost so its quite okay to call it by one
> > > (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
> > > terribly good and fast container suited for your needs)
> > You don't even have a clue what C++ does for you with the above code.
> > Consider for example the exponential growth of the vector to keep the
> > number of reallocations small; that would be much work in C.
> realloc does it for you
> check this thread
>
> https://groups.google.com/g/comp.lang.c/c/YXejwDRKSAQ/m/E8ka_jpAAgAJ

you see there if you use

for(int i=1; i<100000; i++)
dipa = AllocChunk(dipa, i);

where dipa is
struct chunk {char* beg; char* end;};
and AloocChunk is

chunk AllocChunk(rchunk x, int size)
{
x.c.beg = (char*) realloc(x.c.beg, size );
x.c.end = x.c.beg + size -1;
return x;
}

the reallock will only work few times other times just return and do nothing (you dont need to hold end pointer as realoock holds it internally but its konda wrong (as there is no accas to it) so i personally prefer to keep both in form of so called chunk

thsi one offers just resizing but you often need not resizing but more ads and deletes the other code i show shows how to do it in c, you simply hold a static integer that iterates thru records and a flag /enabled in each record which yu set to zero if you want to free that record andhis record and a couple of i++ if you need to find first free record before insertion

that is what i use insetad of tiotally crapppy pony ++ stl vector for noobs

Am 22.07.2023 um 16:48 schrieb fir:
> sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
>> Am 22.07.2023 um 16:19 schrieb fir:
>>> sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
>>>> 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.
>>>
>>>
>>> i dont know what is emplace back and what you mean exponentiol growth
>>> but something like vector in c you do
>>>
>>>
>>> struct ExpressionList { int x; int y; unsigned long long tag;};
>>> static ExpressionList* expression_list1 = NULL;
>>> static int expression_list1_size = 0;
>>>
>>> void expression_list1_AddOne(int i, int j)
>>> {
>>> expression_list1_size++;
>>> expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
>>> expression_list1[expression_list1_size-1] = {i,j};
>>> return ;
>>> }
>>>
>>> if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
>>> need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
>>> reallock called each time is practically near zero cost so its quite okay to call it by one
>>> (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
>>> terribly good and fast container suited for your needs)
>> You don't even have a clue what C++ does for you with the above code.
>> Consider for example the exponential growth of the vector to keep the
>> number of reallocations small; that would be much work in C.
>
> realloc does it for you
> check this thread

Absolutely not. When you do an emplace_back the vecotr first checks
if there's enough capacity to hold another element. If not it allo-
cates new memory with a constant factor of the current size, _moves_
all current elements there (huge difference to memcpy()ing since
the objects can have an arbitrary complexity) increases the size by
one, constructs the new object according to the parameters passed
to emplace_back() and, if an exception occurs shrinks back the con-
tainer of the size (!= capacity) before.
Doing that in C would be a lot of work if you have non-trivial
objects as usual.

sobota, 22 lipca 2023 o 16:58:30 UTC+2 fir napisał(a):
> sobota, 22 lipca 2023 o 16:48:34 UTC+2 fir napisał(a):
> > sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
> > > Am 22.07.2023 um 16:19 schrieb fir:
> > > > sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
> > > >> 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.
> > > >
> > > >
> > > > i dont know what is emplace back and what you mean exponentiol growth
> > > > but something like vector in c you do
> > > >
> > > >
> > > > struct ExpressionList { int x; int y; unsigned long long tag;};
> > > > static ExpressionList* expression_list1 = NULL;
> > > > static int expression_list1_size = 0;
> > > >
> > > > void expression_list1_AddOne(int i, int j)
> > > > {
> > > > expression_list1_size++;
> > > > expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
> > > > expression_list1[expression_list1_size-1] = {i,j};
> > > > return ;
> > > > }
> > > >
> > > > if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
> > > > need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
> > > > reallock called each time is practically near zero cost so its quite okay to call it by one
> > > > (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
> > > > terribly good and fast container suited for your needs)
> > > You don't even have a clue what C++ does for you with the above code.
> > > Consider for example the exponential growth of the vector to keep the
> > > number of reallocations small; that would be much work in C.
> > realloc does it for you
> > check this thread
> >
> > https://groups.google.com/g/comp.lang.c/c/YXejwDRKSAQ/m/E8ka_jpAAgAJ
> you see there if you use
>
> for(int i=1; i<100000; i++)
> dipa = AllocChunk(dipa, i);
>
> where dipa is
> struct chunk {char* beg; char* end;};
> and AloocChunk is
>
> chunk AllocChunk(rchunk x, int size)
> {
> x.c.beg = (char*) realloc(x.c.beg, size );
> x.c.end = x.c.beg + size -1;
> return x;
> }
>
> the reallock will only work few times other times just return and do nothing (you dont need to hold end pointer as realoock holds it internally but its konda wrong (as there is no accas to it) so i personally prefer to keep both in form of so called chunk
>
> thsi one offers just resizing but you often need not resizing but more ads and deletes the other code i show shows how to do it in c, you simply hold a static integer that iterates thru records and a flag /enabled in each record which yu set to zero if you want to free that record andhis record and a couple of i++ if you need to find first free record before insertion
>
> that is what i use insetad of tiotally crapppy pony ++ stl vector for noobs
(in fact for ponys not noobs - ponny is better word for that )

Am 22.07.2023 um 16:42 schrieb fir:
> sobota, 22 lipca 2023 o 16:32:28 UTC+2 Bonita Montero napisał(a):
>> 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.
>
> struct String {char* str; /*more fields*/};
>
> static String* strings = NULL;
> static int strings_size = 0;
> int strings_addOne(char* str) { strings_size++; strings = (String*) realloc(strings, trings_size * sizeof(String) ); strings[strings_size-1].str = str;}
>
> int main()
> {
> strings_addOne("ala");
> strings_addOne("ma");
> strings_addOne("kota");
>
> for(int i=0; i<strings_size;i++) printf(strings[i].str);
> }
> not checked for typos but it is about that, vector in c but better

This doesn't do what I've shown. I've described that in the
ther posting. I think you don't program professionally at all.

Am 22.07.2023 um 17:00 schrieb fir:
> sobota, 22 lipca 2023 o 16:58:30 UTC+2 fir napisał(a):
>> sobota, 22 lipca 2023 o 16:48:34 UTC+2 fir napisał(a):
>>> sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
>>>> Am 22.07.2023 um 16:19 schrieb fir:
>>>>> sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
>>>>>> 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.
>>>>>
>>>>>
>>>>> i dont know what is emplace back and what you mean exponentiol growth
>>>>> but something like vector in c you do
>>>>>
>>>>>
>>>>> struct ExpressionList { int x; int y; unsigned long long tag;};
>>>>> static ExpressionList* expression_list1 = NULL;
>>>>> static int expression_list1_size = 0;
>>>>>
>>>>> void expression_list1_AddOne(int i, int j)
>>>>> {
>>>>> expression_list1_size++;
>>>>> expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
>>>>> expression_list1[expression_list1_size-1] = {i,j};
>>>>> return ;
>>>>> }
>>>>>
>>>>> if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
>>>>> need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
>>>>> reallock called each time is practically near zero cost so its quite okay to call it by one
>>>>> (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
>>>>> terribly good and fast container suited for your needs)
>>>> You don't even have a clue what C++ does for you with the above code.
>>>> Consider for example the exponential growth of the vector to keep the
>>>> number of reallocations small; that would be much work in C.
>>> realloc does it for you
>>> check this thread
>>>
>>> https://groups.google.com/g/comp.lang.c/c/YXejwDRKSAQ/m/E8ka_jpAAgAJ
>> you see there if you use
>>
>> for(int i=1; i<100000; i++)
>> dipa = AllocChunk(dipa, i);
>>
>> where dipa is
>> struct chunk {char* beg; char* end;};
>> and AloocChunk is
>>
>> chunk AllocChunk(rchunk x, int size)
>> {
>> x.c.beg = (char*) realloc(x.c.beg, size );
>> x.c.end = x.c.beg + size -1;
>> return x;
>> }
>>
>> the reallock will only work few times other times just return and do nothing (you dont need to hold end pointer as realoock holds it internally but its konda wrong (as there is no accas to it) so i personally prefer to keep both in form of so called chunk
>>
>> thsi one offers just resizing but you often need not resizing but more ads and deletes the other code i show shows how to do it in c, you simply hold a static integer that iterates thru records and a flag /enabled in each record which yu set to zero if you want to free that record andhis record and a couple of i++ if you need to find first free record before insertion
>>
>> that is what i use insetad of tiotally crapppy pony ++ stl vector for noobs
> (in fact for ponys not noobs - ponny is better word for that )

You're nervous and you don't program professionally at at.

sobota, 22 lipca 2023 o 16:59:45 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 16:48 schrieb fir:
> > sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
> >> Am 22.07.2023 um 16:19 schrieb fir:
> >>> sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
> >>>> 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.
> >>>
> >>>
> >>> i dont know what is emplace back and what you mean exponentiol growth
> >>> but something like vector in c you do
> >>>
> >>>
> >>> struct ExpressionList { int x; int y; unsigned long long tag;};
> >>> static ExpressionList* expression_list1 = NULL;
> >>> static int expression_list1_size = 0;
> >>>
> >>> void expression_list1_AddOne(int i, int j)
> >>> {
> >>> expression_list1_size++;
> >>> expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
> >>> expression_list1[expression_list1_size-1] = {i,j};
> >>> return ;
> >>> }
> >>>
> >>> if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
> >>> need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
> >>> reallock called each time is practically near zero cost so its quite okay to call it by one
> >>> (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
> >>> terribly good and fast container suited for your needs)
> >> You don't even have a clue what C++ does for you with the above code.
> >> Consider for example the exponential growth of the vector to keep the
> >> number of reallocations small; that would be much work in C.
> >
> > realloc does it for you
> > check this thread
> Absolutely not. When you do an emplace_back the vecotr first checks
> if there's enough capacity to hold another element. If not it allo-
> cates new memory with a constant factor of the current size, _moves_
> all current elements there (huge difference to memcpy()ing since
> the objects can have an arbitrary complexity) increases the size by
> one, constructs the new object according to the parameters passed
> to emplace_back() and, if an exception occurs shrinks back the con-
> tainer of the size (!= capacity) before.
> Doing that in C would be a lot of work if you have non-trivial
> objects as usual.

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

Am 22.07.2023 um 17:02 schrieb fir:
> sobota, 22 lipca 2023 o 16:59:45 UTC+2 Bonita Montero napisał(a):
>> Am 22.07.2023 um 16:48 schrieb fir:
>>> sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
>>>> Am 22.07.2023 um 16:19 schrieb fir:
>>>>> sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
>>>>>> 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.
>>>>>
>>>>>
>>>>> i dont know what is emplace back and what you mean exponentiol growth
>>>>> but something like vector in c you do
>>>>>
>>>>>
>>>>> struct ExpressionList { int x; int y; unsigned long long tag;};
>>>>> static ExpressionList* expression_list1 = NULL;
>>>>> static int expression_list1_size = 0;
>>>>>
>>>>> void expression_list1_AddOne(int i, int j)
>>>>> {
>>>>> expression_list1_size++;
>>>>> expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
>>>>> expression_list1[expression_list1_size-1] = {i,j};
>>>>> return ;
>>>>> }
>>>>>
>>>>> if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
>>>>> need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
>>>>> reallock called each time is practically near zero cost so its quite okay to call it by one
>>>>> (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
>>>>> terribly good and fast container suited for your needs)
>>>> You don't even have a clue what C++ does for you with the above code.
>>>> Consider for example the exponential growth of the vector to keep the
>>>> number of reallocations small; that would be much work in C.
>>>
>>> realloc does it for you
>>> check this thread
>> Absolutely not. When you do an emplace_back the vecotr first checks
>> if there's enough capacity to hold another element. If not it allo-
>> cates new memory with a constant factor of the current size, _moves_
>> all current elements there (huge difference to memcpy()ing since
>> the objects can have an arbitrary complexity) increases the size by
>> one, constructs the new object according to the parameters passed
>> to emplace_back() and, if an exception occurs shrinks back the con-
>> tainer of the size (!= capacity) before.
>> Doing that in C would be a lot of work if you have non-trivial
>> objects as usual.
>
> 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.

sobota, 22 lipca 2023 o 17:02:07 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 17:00 schrieb fir:
> > sobota, 22 lipca 2023 o 16:58:30 UTC+2 fir napisał(a):
> >> sobota, 22 lipca 2023 o 16:48:34 UTC+2 fir napisał(a):
> >>> sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
> >>>> Am 22.07.2023 um 16:19 schrieb fir:
> >>>>> sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
> >>>>>> 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.
> >>>>>
> >>>>>
> >>>>> i dont know what is emplace back and what you mean exponentiol growth
> >>>>> but something like vector in c you do
> >>>>>
> >>>>>
> >>>>> struct ExpressionList { int x; int y; unsigned long long tag;};
> >>>>> static ExpressionList* expression_list1 = NULL;
> >>>>> static int expression_list1_size = 0;
> >>>>>
> >>>>> void expression_list1_AddOne(int i, int j)
> >>>>> {
> >>>>> expression_list1_size++;
> >>>>> expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
> >>>>> expression_list1[expression_list1_size-1] = {i,j};
> >>>>> return ;
> >>>>> }
> >>>>>
> >>>>> if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
> >>>>> need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
> >>>>> reallock called each time is practically near zero cost so its quite okay to call it by one
> >>>>> (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
> >>>>> terribly good and fast container suited for your needs)
> >>>> You don't even have a clue what C++ does for you with the above code..
> >>>> Consider for example the exponential growth of the vector to keep the
> >>>> number of reallocations small; that would be much work in C.
> >>> realloc does it for you
> >>> check this thread
> >>>
> >>> https://groups.google.com/g/comp.lang.c/c/YXejwDRKSAQ/m/E8ka_jpAAgAJ
> >> you see there if you use
> >>
> >> for(int i=1; i<100000; i++)
> >> dipa = AllocChunk(dipa, i);
> >>
> >> where dipa is
> >> struct chunk {char* beg; char* end;};
> >> and AloocChunk is
> >>
> >> chunk AllocChunk(rchunk x, int size)
> >> {
> >> x.c.beg = (char*) realloc(x.c.beg, size );
> >> x.c.end = x.c.beg + size -1;
> >> return x;
> >> }
> >>
> >> the reallock will only work few times other times just return and do nothing (you dont need to hold end pointer as realoock holds it internally but its konda wrong (as there is no accas to it) so i personally prefer to keep both in form of so called chunk
> >>
> >> thsi one offers just resizing but you often need not resizing but more ads and deletes the other code i show shows how to do it in c, you simply hold a static integer that iterates thru records and a flag /enabled in each record which yu set to zero if you want to free that record andhis record and a couple of i++ if you need to find first free record before insertion
> >>
> >> that is what i use insetad of tiotally crapppy pony ++ stl vector for noobs
> > (in fact for ponys not noobs - ponny is better word for that )
> You're nervous and you don't program professionally at at.

well ponnys call themselves profesionally, but this profasionally mean something like a basic problems with logic so it isnt teribbly professional imo

sobota, 22 lipca 2023 o 17:07:38 UTC+2 Bonita Montero napisał(a):
> Am 22.07.2023 um 17:02 schrieb fir:
> > sobota, 22 lipca 2023 o 16:59:45 UTC+2 Bonita Montero napisał(a):
> >> Am 22.07.2023 um 16:48 schrieb fir:
> >>> sobota, 22 lipca 2023 o 16:34:50 UTC+2 Bonita Montero napisał(a):
> >>>> Am 22.07.2023 um 16:19 schrieb fir:
> >>>>> sobota, 22 lipca 2023 o 15:00:22 UTC+2 Bonita Montero napisał(a):
> >>>>>> 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.
> >>>>>
> >>>>>
> >>>>> i dont know what is emplace back and what you mean exponentiol growth
> >>>>> but something like vector in c you do
> >>>>>
> >>>>>
> >>>>> struct ExpressionList { int x; int y; unsigned long long tag;};
> >>>>> static ExpressionList* expression_list1 = NULL;
> >>>>> static int expression_list1_size = 0;
> >>>>>
> >>>>> void expression_list1_AddOne(int i, int j)
> >>>>> {
> >>>>> expression_list1_size++;
> >>>>> expression_list1 = (ExpressionList*) realloc(expression_list1, expression_list1_size * sizeof(ExpressionList) );
> >>>>> expression_list1[expression_list1_size-1] = {i,j};
> >>>>> return ;
> >>>>> }
> >>>>>
> >>>>> if you dont want you might not call reallock by evary add but realoock by *1.5 or bby +1000 or what you
> >>>>> need - but in fact the reallock casches it itself and did not do the reallock by one only really rare so this
> >>>>> reallock called each time is practically near zero cost so its quite okay to call it by one
> >>>>> (add flag enabled to mark record as deleted and some increment cursor code to find empty ones and you got
> >>>>> terribly good and fast container suited for your needs)
> >>>> You don't even have a clue what C++ does for you with the above code..
> >>>> Consider for example the exponential growth of the vector to keep the
> >>>> number of reallocations small; that would be much work in C.
> >>>
> >>> realloc does it for you
> >>> check this thread
> >> Absolutely not. When you do an emplace_back the vecotr first checks
> >> if there's enough capacity to hold another element. If not it allo-
> >> cates new memory with a constant factor of the current size, _moves_
> >> all current elements there (huge difference to memcpy()ing since
> >> the objects can have an arbitrary complexity) increases the size by
> >> one, constructs the new object according to the parameters passed
> >> to emplace_back() and, if an exception occurs shrinks back the con-
> >> tainer of the size (!= capacity) before.
> >> Doing that in C would be a lot of work if you have non-trivial
> >> objects as usual.
> >
> > 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.

i told you writing such things in c by hand is few lines of code, even if you need something more complex ypu may spend few days on it then use it rest of your life so it is not like you priobably imagine it takes years or months

and if you need something like half of google you may download library

c has some problems that makes some code in old c can be written so celan and short as it could (i wrote tens of times on it) but still is totally unparalebly cleener and better tnan pony++ (named also cobol++, new cobol or c++) - unserstand it or not but note many people has opinion quite other than you so maybe stop repeating it as a spam... if you want so seriously evengelise take my examples write it properly in such clean c and compare, i will not be writng it for you as i gut much better work to do and what you say is totally not interesting those are religious propaganda spam

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.

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)

Bonita Montero ha scritto:
> 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.

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

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.

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.