Deutsch English Français Italiano |
<102690u$f6c1$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Muttley@DastardlyHQ.org Newsgroups: comp.lang.c Subject: Re: encapsulating directory operations Date: Mon, 9 Jun 2025 09:20:30 -0000 (UTC) Organization: A noiseless patient Spider Lines: 22 Message-ID: <102690u$f6c1$1@dont-email.me> References: <100h650$23r5l$1@dont-email.me> <1nj%P.3454$mAv4.2422@fx34.iad> <101nc3o$5pjd$1@raubtier-asyl.eternal-september.org> <h6H%P.676329$McHf.348392@fx15.iad> <101u8sb$25g28$1@raubtier-asyl.eternal-september.org> <3FC0Q.931590$G6Lf.397684@fx17.iad> <101v7d7$2cudl$1@raubtier-asyl.eternal-september.org> <CvF0Q.1165311$McHf.1120306@fx15.iad> <101v8ce$2d5it$1@raubtier-asyl.eternal-september.org> <0e9619f7d873a4ec436f017bac1192c73c5283e5.camel@gmail.com> <1020eu8$2pifl$1@raubtier-asyl.eternal-september.org> <1e3f53801e22a94356b9b0aded0ed7d33e67fd06.camel@gmail.com> <1021pgp$35sqk$1@raubtier-asyl.eternal-september.org> <1858c98adc50b2bec4021f15d0c5b94e2158f6b5.camel@gmail.com> <10223hq$38g0s$1@raubtier-asyl.eternal-september.org> <5484915e06dec7fa7a1371a9eb41801a00495079.camel@gmail.com> <1023gak$3nt1m$1@raubtier-asyl.eternal-september.org> <1023j6o$3ogga$1@dont-email.me> <10248l1$3tavs$1@raubtier-asyl.eternal-september.org> <1024910$3tdrq$1@dont-email.me> <10249is$3tavs$4@raubtier-asyl.eternal-september.org> Injection-Date: Mon, 09 Jun 2025 11:20:30 +0200 (CEST) Injection-Info: dont-email.me; posting-host="76991b7b20ddc336bd0b3c10aeffb176"; logging-data="498049"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19UwkFT6cUCb9etpHn3OqqO" Cancel-Lock: sha1:yi8m0ZWJwtkxupYgxPnyb1roEyE= Bytes: 2948 On Sun, 8 Jun 2025 17:18:03 +0200 Bonita Montero <Bonita.Montero@gmail.com> wibbled: >Am 08.06.2025 um 17:08 schrieb Muttley@DastardlyHQ.org: > >> Its no different to C++ exceptions except obviously no destructors >> are called so there's no chance to do a tidy up at each stack level. > >It's much more complicated than exceptions because the functions where >the error raises and where the error is "caught" need shared global >variables. C++ doesn't need that, just throw and catch and everything >is glued to the runtime. >And the problem with your solution is: All functions between the setjmp- >and the longjmp-calls don't have any cleanup, i.e. they don't handle >back their opened resources to the runtime or the kernel. With RAII in >combination with exceptions that's for free. >Do you really think setjmp() / longjmp() is a competitive solution ? >You're naive. Did you actually read what I wrote? Obviously in C++ you'd use exceptions but in C without any kind of built in exception mechanism they're better than nothing if you want to jump out of a deep stack.