which add to the space allocated to an std::String

NO, string doesn't inherit any virtual function or have any virtual functions

which take nothing, they are not even in vtables

it takes like 64 bytes if i recall

NO, string doesn't inherit any virtual function or have any virtual functions

they have size

however the offsets are still there

You win speed and a LOT of ease for maybe 100 bytes

they have other things

You win speed and a LOT of ease for maybe 100 bytes

BUT THOSE HUNDRED BYTES CAN BE USED FOR BETTER THINGS

it takes like 64 bytes if i recall

neither in MSVC, nor in GCC stdlib, nor in Clang's, nor on intel's...

this is wrong

BUT THOSE HUNDRED BYTES CAN BE USED FOR BETTER THINGS

Hundred bytes? Thats not a lot and again, they help for speed

Al you save is 16 bytes at most

they help for ease of programming

That way you know that you won't fuck up with your chars

this is wrong

C is wayy harder than C++

but it doesnt have more things than C++

it doesnt make sense to use C

@ollirz time for you to tell me why C is fine on embedded systems 😉

0000000000400650 <.plt>: 400650: ff 35 b2 09 20 00 pushq 0x2009b2(%rip) # 601008 <_GLOBAL_OFFSET_TABLE_+0x8> 400656: ff 25 b4 09 20 00 jmpq *0x2009b4(%rip) # 601010 <_GLOBAL_OFFSET_TABLE_+0x10> 40065c: 0f 1f 40 00 nopl 0x0(%rax) 0000000000400660 <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@plt>: 400660: ff 25 b2 09 20 00 jmpq *0x2009b2(%rip) # 601018 <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev@GLIBCXX_3.4.21> 400666: 68 00 00 00 00 pushq $0x0 40066b: e9 e0 ff ff ff jmpq 400650 <.plt> 0000000000400670 <_ZNSaIcED1Ev@plt>: 400670: ff 25 aa 09 20 00 jmpq *0x2009aa(%rip) # 601020 <_ZNSaIcED1Ev@GLIBCXX_3.4> 400676: 68 01 00 00 00 pushq $0x1 40067b: e9 d0 ff ff ff jmpq 400650 <.plt> 0000000000400680 <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_@plt>: 400680: ff 25 a2 09 20 00 jmpq *0x2009a2(%rip) # 601028 <_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_@GLIBCXX_3.4.21> 400686: 68 02 00 00 00 pushq $0x2 40068b: e9 c0 ff ff ff jmpq 400650 <.plt> 0000000000400690 <__gxx_personality_v0@plt>: 400690: ff 25 9a 09 20 00 jmpq *0x20099a(%rip) # 601030 <__gxx_personality_v0@CXXABI_1.3> 400696: 68 03 00 00 00 pushq $0x3 40069b: e9 b0 ff ff ff jmpq 400650 <.plt> 00000000004006a0 <_Unwind_Resume@plt>: 4006a0: ff 25 92 09 20 00 jmpq *0x200992(%rip) # 601038 <_Unwind_Resume@GCC_3.0> 4006a6: 68 04 00 00 00 pushq $0x4 4006ab: e9 a0 ff ff ff jmpq 400650 <.plt> 00000000004006b0 <_ZNSaIcEC1Ev@plt>: 4006b0: ff 25 8a 09 20 00 jmpq *0x20098a(%rip) # 601040 <_ZNSaIcEC1Ev@GLIBCXX_3.4>

there are so many more things

there are so many more things

those are maybe 16 - 30 bytes

hold on the personality and unwind resume is not there

Unfortunately yes

I had to relearn C++

those are maybe 16 - 30 bytes

5 * 6 is already 40

30

there are more then 30 bytes

5 * 6 is already 40

So what?

Speed is wayy more critical than memory on today's machines

in fact, it has always been

Speed is wayy more critical than memory on today's machines

it is however it is actually not much of a speedup then what is originally saved

U know meaning of my name? I guess u wanna do a Google search

i'm 100 cool

it is faster to have homemade ones

i tend not to use strlen or anything like this

because i know the length from the read/recv operation

i'm 100 cool

Googled my name?

you can use that variable instead and do more complex processing without ever changing into a string

Googled my name?

i use net explorer

also sizeof(std::string) gives you 32 bytes of memory stored

it is however it is actually not much of a speedup then what is originally saved

strlen?

irregardless of the size of the array

strlen?

length of a null terminated

also sizeof(std::string) gives you 32 bytes of memory stored

whats the size of a pointer on 86x64?

8)

length of a null terminated

std::string::size(); whats the O of that one?

strlen?

whats the O of that one?

also sizeof(std::string) gives you 32 bytes of memory stored

Yeah, noticed gcc uses a trick for optimization that uses 8 more bytes

std::string::size(); whats the O of that one?

O(1)

whats the O of that one?

O(n)

"not too much of a speedup"

also sizeof(std::string) gives you 32 bytes of memory stored

and string_view gives 16 bytes

it is however it is actually not much of a speedup then what is originally saved

^

it is however it is actually not much of a speedup then what is originally saved

for a string longer than 64 bytes, the speedup is far noticeable

whats the size of a pointer on 86x64?

8 bytes so that means 24 bytes are string stuff

and string_view gives 16 bytes

(and O(1) size)

8 bytes so that means 24 bytes are string stuff

Yea

isnt that acceptable?

no

because it is complete shit

and useless

there are faster ways to process just using char*

no

so you prefer having a slow string that takes n bytes instead of having a fast wrapper for that slow string that takes n + 32 bytes?

there are faster ways to process just using char*

Not really

so you prefer having a slow string that takes n bytes instead of having a fast wrapper for that slow string that takes n + 32 bytes?

it is not a slow string

it is not a slow string

char* is slower than std::string

the functions are exactly the same

char* is slower than std::string

it is not

the functions are exactly the same

nope

the only case is strlen

it is not

how do you get the size of a string?

but strlen should NOT BE USED

the only case is strlen

every other function depends on the length of the string

how do you get the size of a string?

you get the length when you read it in

but strlen should NOT BE USED

rather?

you get the length when you read it in

and then?

and then?

you keep that length

you get the length when you read it in

yet printf uses it, like most of the standard C lib

and just update it

you keep that length

Isnt that what std::string encurages you to do/does?

.

Isnt that what std::string encurages you to do/does?

Let it slide, this guy have 0 practical sense, he is a C crazy guy like the Torvalds

Let it slide, this guy have 0 practical sense, he is a C crazy guy like the Torvalds

Yea