Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Memory and error management approaches |
| Date | 2015-11-03 09:48 +1300 |
| Message-ID | <d9q0hqF7v31U2@mid.individual.net> (permalink) |
| References | <n179ne$64b$1@speranza.aioe.org> <d9ooh3F6ovuU4@mid.individual.net> <n17app$82n$1@speranza.aioe.org> <d9opetF6ovuU6@mid.individual.net> <n17cgd$cf2$1@speranza.aioe.org> |
Morten W. Petersen wrote: > On 02.11.2015 10:41, Ian Collins wrote: >> Morten W. Petersen wrote: >>> On 02.11.2015 10:25, Ian Collins wrote: >>> [...] >>>>> And then have a function that goes through this error structure and >>>>> deals with everything. >>>>> >>>>> This should work regardless the parsing succeeds or fails, and would >>>>> also work with setjmp/longjmp. >>>> >>>> You should forget about setjmp/longjmp and just handle errors locally. >>> >>> Why? >> >> It will inevitably end in tears and/or much unnecessary complexity. > > Well, the error structure will contain pointers and be maybe 20 pointers > big, and these pointers will in turn be linked lists if there is more > than one entry.. > > If all dynamically allocated memory is freed and streams are closed on a > longjmp, what's the problem? You have introduced a laborious, manual and therefore error prone overhead to each resource allocation and release. There are good reasons why no attempt at bolting on an exception mechanism on to C has ever caught on. > And by the way, is it proper practice to close streams when done with > them, or should that be left to the caller? He who opens, closes. >>>>> Any thoughts on this? A while ago someone wrote on comp.lang.c about >>>>> writing a custom memory manager for performance; is that something that >>>>> could be coupled with all of this? >>>> >>>> Most of the platforms I'm familiar with provide specialised memory >>>> allocator libraries, you shouldn't have to roll yet another one for >>>> something as simple as XML parsing. >>> >>> Well it will also provide a (simple?) DOM and writer as well. >>> >>> So for example a search could be optimized by having certain things >>> on one memory page etc. >> >> Trying to add such micro-optimisations on modern CPUs is seldom worth >> the effort. > > Well that would depend on the data type and size wouldn't it? The time to look at custom allocation is after extensive testing and profiling shows a bottleneck with dynamic memory. -- Ian Collins
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:17 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:25 +1300
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 10:36 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-02 22:41 +1300
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 11:05 +0100
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:15 +0000
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 20:31 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:48 +1300
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:17 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 10:29 +1300
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 13:48 -0800
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-02 22:31 +0100
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:02 +1300
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 15:21 -0800
Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-03 17:24 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-04 14:38 +1300
Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-04 10:48 -0800
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-04 11:28 -0800
Re: Memory and error management approaches James Kuyper <jameskuyper@verizon.net> - 2015-11-04 14:54 -0500
Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-06 07:50 +0000
Re: Memory and error management approaches <william@wilbur.25thandClement.com> - 2015-11-06 11:40 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-07 09:38 +1300
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-06 20:55 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 02:23 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-07 11:29 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 04:18 -0800
Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 05:41 -0800
Re: Memory and error management approaches asetofsymbols@gmail.com - 2015-11-07 06:27 -0800
Re: Memory and error management approaches Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-11-07 18:20 +0100
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-07 10:28 -0800
Re: Memory and error management approaches gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-07 19:01 +0000
Re: Memory and error management approaches raltbos@xs4all.nl (Richard Bos) - 2015-11-10 16:14 +0000
Re: Memory and error management approaches Gareth Owen <gwowen@gmail.com> - 2015-11-10 21:13 +0000
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-10 19:26 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:25 -0800
Re: Memory and error management approaches "Morten W. Petersen" <morphex@gmail.com> - 2015-11-06 10:05 +0100
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 02:15 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 12:01 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 06:05 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 17:18 +0000
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 09:27 -0800
Re: Memory and error management approaches Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-02 23:02 +0000
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 12:07 +1300
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 15:23 -0800
Re: Memory and error management approaches supercat@casperkitty.com - 2015-11-02 10:28 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 09:34 +1300
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-02 14:05 -0800
Re: Memory and error management approaches Ian Collins <ian-news@hotmail.com> - 2015-11-03 11:27 +1300
Re: Memory and error management approaches Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-03 18:15 -0800
csiph-web