c++ - Decorate a char* and char const* by pointer acquisition : good practice? -


hello wanted poll public idea of doing string class (like std::string) have feature of being able work on buffers provided client.

what dangers forsee ? classic smell ? etcaetera

i mean so:

char ext[64] = {0}; my::string s(ext, my::string::acquire_rw); size_t len = s.size(); size_t pos = s.find("zboub"); my::string s2(s);   // uses true (alloc+)copy semantic here. 

so forsee 2 strategies: acquire_rw , acquire_ro permit modification of characters in ext or not. , in ro case non-const method, , rw cases in methods buffer has expanded; alloc & copy @ moment only.

in way, my::string type becomes decorator of char* type.

of course being careful of not freeing external buffer before decorator left requirement client.

thanks sharing concerns

the answer 'good practice' difficult. say, in general not practice, specific use cases practice. depends how can trust client on lifetime of provided memory. in general: no trust. in special cases: ok.

there 1 rather important thing consider performance wise:

do plan use implicit sharing (with copy on write , reference counting) of allocated variants of strings? or plan use value semantics (always copy, never reference)?

in multiprocessor , multithreaded environments value semantics preferred way strings. performance gain using implicit sharing destroyed necessary locking in multithreaded environments.

note suggestion may still makes sense when multithreaded: can use copy-on-write when going external memory allocated variant (no locking necessary), , value semantics on (also no locking necessary). best.

i imagine variant works in specific use cases example memory-mapped file lots of strings , not want store copies of these small strings , fragment memory.

however, in general case not worry , use std::string.


Comments

Popular posts from this blog

Hatching array of circles in AutoCAD using c# -

ios - UITEXTFIELD InputView Uipicker not working in swift -

Python Pig Latin Translator -