Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Julio Di Egidio Newsgroups: comp.lang.c Subject: Re: So You Think You Can Const? Date: Thu, 9 Jan 2025 08:12:58 +0100 Organization: A noiseless patient Spider Lines: 50 Message-ID: References: <20250107130809.661@kylheku.com> <87a5c15ob0.fsf@bsb.me.uk> <86frlt83pm.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 09 Jan 2025 08:12:59 +0100 (CET) Injection-Info: dont-email.me; posting-host="e9d42356b81d42d02d68289eca9ecab3"; logging-data="2544429"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/GHqNAN+WAF/NmjWD+OYecFzu23502Wlg=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:tdZd1OpNppusaF16RsJpRzDQFkg= Content-Language: en-GB In-Reply-To: <86frlt83pm.fsf@linuxsc.com> Bytes: 2996 On 08/01/2025 21:12, Tim Rentsch wrote: > Julio Di Egidio writes: > > [...] > >> Say my program unit implements AVL trees, with (conceptually >> speaking) constructors/destructors, navigation and retrieval, and >> of course manipulation (inserting, deleting, etc.). >> >> My idea (but I would think this is pretty "canonical" and, if it >> isn't, I am missing the mark) is: my public functions take/give >> "sealed" instances (with const members to const data), as the user >> is not supposed to directly manipulate/edit the data, OTOH of >> course my implementation is all about in-place editing... > > A better choice is to put the AVL code in a separate .c file, > and give out only opaque types to clients. For example (disclaimer: > not compiled): > > // in "avl.h" > typedef struct avl_node_s *AVLTree; > // note that the struct contents are not defined in the .h file > > ... declare interfaces that accept and return AVLTree values ... > > // in "avl.c" > #include "avl.h" > struct avl_node_s { > // whatever members are needed > }; > > ... implementation of public interfaces and any supporting > ... functions needed > > > I might mention that some people don't like declaring a type name > that includes the pointerness ('*') as part of the type. I think > doing that is okay (and in fact more than just okay; better) in the > specific case where the type name is being offered as an opaque > type. > > Of course you could also make the opaque type be a pointer to a > 'const' struct type, if you wanted to, but the extra "protection" of > const-ness doesn't add much, and might actually cost more than it > buys you because of the additional casting that would be needed. Thank you, I like that... -Julio