| Richard Damon <Richard@Damon-Family.org>: Jan 21 04:32PM -0500 On 1/21/23 2:09 PM, R.Wieser wrote: > Thanks for the well-aimed reply. > Regards, > Rudy Wieser So the "string pointer" type you are thinking of needs to be told, and remember the answer to the question, "Does this memory need to be freed?" |
| Mike Terry <news.dead.person.stones@darjeeling.plus.com>: Jan 21 10:10PM On 21/01/2023 19:09, R.Wieser wrote: > My post was more in the direction that /either of/ those string types could > be returned, and I would like to create a "safe release" routine for such a > pointer. A noble aim, but... the C++ and C language raw pointers are basically just "pointers to type xxx" They don't encapsulate how to free referenced resource(s) - pointers to an object on the stack, or in static program storage, or on the C/C++ heap or even in the OS process heap will all typically look similar, i.e. just 32- or 64-bit (or whatever) address space pointer values. You could analyse the pointer value and try to work out what region of memory it belongs to, but that will be non-portable and too much to reasonably ask, I'd say. C++ functions could return some kind of embellished pointer - a class object including the pointer and also the capability within the class of freeing the referenced resources in various ways depending on how the resource was created. The embellishment would increase the memory required for a 'pointer', so this might not be a good idea e.g. if your app might have large arrays of such pointers. Basically, if there were a /simple/ answer to your original question, there would be no interesting debate, but there's not - so you need to carefully balance costs/benefits. Simple is good, unless simple doesn't work! :) >> so that it can be correctly freed by the caller. > Thats good for a simple situation. I was also thinking of a string pointer > which could be initialized by the user but changed by a routine. There are two aspects here, and it's good to keep them separate. Looking at the std::string class, that addresses the "initialized by the user but changed by a routine" bit of the problem, which I'll suggest is 99% of the benefit you're after. [Pass strings as std::string& ] The remaining "I really want to return pointers to memory allocated (and so to be later freed) in several different ways decided at run-time ALL FROM THE SAME FUNCTION" is a separate problem. It could be addresed with the approach of embellished pointers. The standard library supports custom allocators which can serve as template arguments for containers like std::string, so you could have a std::string with an embellished pointer - but, so much added complexity for what?? If you're more interested in C APIs, using raw pointers etc., then the whole topic of responsibilities for managing memory between callers and called functions IN GENERAL is quite subtle. DCE's Remote Procedure Call (RPC) framework has to solve this issue because the calling and called routines typically are in different address spaces with no shared memory, and it's far from trivial! The problem is that C/C++ language in itself does not sufficiently describe pointer use to make this possible. E.g. a pointer could be a REF pointer to a single struct, or to an array, and structs can chain to other structs, possibly involving loops of pointers, or at least having multiple pointers to a single struct. Also pointers need to be understood as IN/OUT/INOUT in terms of which way data is being passed to/from a function, which affects the rules for managing the memory. If you're interested in the GENERAL solution for this kind of problem the DCE RPC documentation (or Microsofts DCOM which uses RPC) relating to memory management would at least give you a good idea of the issues. But if you just want to provide one C-style API for one function with a modifiable IN/OUT parameter, just do something like: int AmendString (/*INOUT*/ char** ppString); and clearly document callers responsibity, including how the string memory must initially be allocated by the caller, and how it must eventually be freed upon return. Mike. |
| Pluted Pup <plutedpup@outlook.com>: Jan 21 01:03PM -0800 On Thu, 19 Jan 2023 07:18:58 -0800, David Brown wrote: > seen a few posts end up in the wrong groups today. I have no idea if > Muttley's post is appropriate or not in rec.arts.books - I'm sure it > makes more sense in the context of threads there. The crap post was from rec.arts.books, which has for about 15 years been subject to robo-posted spam by "Ilya Shambat". Bonita reposted the crap with a crosspost. > is bigotry and has no place anywhere. I'm assuming you did not mean to > write that way, but you should choose your words more carefully in the > future.) "Ilya Shambat" is Jewish. I'm glad Object C programmers are wising up and improving their coding by antisemitism, despite the ban on antisemitism. |
| Pluted Pup <plutedpup@outlook.com>: Jan 21 02:01PM -0800 On Sat, 21 Jan 2023 13:03:35 -0800, Pluted Pup wrote: > "Ilya Shambat" is Jewish. > I'm glad Object C programmers are wising up and improving > their coding by antisemitism, despite the ban on antisemitism. Think outside the box. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment