Article View: pl.comp.lang.c
Article #267803Re: Ciemna strona C++
From: Maciej Sobczak
Date: Wed, 05 Dec 2007 14:14
Date: Wed, 05 Dec 2007 14:14
61 lines
4413 bytes
4413 bytes
On 5 Gru, 14:44, Sektor van Skijlen <ethou...@guess.if.gmail.com.is.valid.or.invalid> wrote: > > Funkcje podane przez użytkownika są ZAMIAST a nie PRZED. > > set_terminate() ustawia funkcję, wobec której standard wymaga, aby > > zakończyła program. Nie ma sensu rozważać, co się dzieje potem. > > Gdzie tak przepraszam wyczytałeś, bo ja niczego takiego w standardzie nie > widzę Przecież sam zacytowałeś: > typedef void (* unexpected_handler )(); [...] > 2 Required behavior: An unexpected_handler shall not return. See also 15.5.2. [...] > typedef void (* terminate_handler )(); [...] > 2 Required behavior: A terminate_handler shall terminate execution of the > program without returning to the > caller. Zwróć uwagę na shall powyżej, w obu przypadkach. > Czy na podstawie standardu jesteś więc w stanie określić, czy: > - wolno nie kończyć programu w terminate() Nie wolno. > - implementacji wolno utłuc program abort()-em jeśli użytkownik nie ubije > wcześniej programu w swoim handlerze terminate()? Wolno. Skoro użytkownik *nie spełnił wymagań* nałożonych przez standard na jego handler, to skazuje program na UB. Implementacja może swobodnie utłuc taki program. > Nie przyglądałem się, jak to jest w standardzie - o tym, że oryginalna > terminate() i tak jest wołana po funkcji użytkownika, przeczytałem w DEC++. W takim razie jest to informacja na temat DEC++. > Nie wiem, na ile jest to sprawa implementacji, ale jedynym sposobem wymuszenia > na użytkowniku, żeby w swoim handlerze spowodował zakończenie programu jest > spowodowanie zakończenia programu po jej zakończeniu. Ponieważ w domyślnej > sytuacji nic innego nie robi (a kończy program i tak w ten sam sposób), więc > metodą logicznej eliminacji jedyną sensowną implementacją spełniającą wymogi > standardu jest wywołać abort() zaraz po wykonaniu funkcji użytkownika - > najwyżej użytkownik zakończy program poprzez exit() zanim do tego dojdzie. Nie widzę takiego wymagania, nawet jeśli sam bym tak to zaimplementował. > Ale nawet zakładając, że tak rzecze standard, nie zmienia to faktu: większość > tutoriali twierdzi stanowczo, że funkcja ta używana jest ZAMIAST oryginalnego > handlera, "trochę zapominając" wspomnieć, że funkcja ta MUSI spowodować > również zakończenie programu. Widocznie te tutoriale nie są tak dokładne jak standard. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com
Technical Details
Message-ID:
<240a4947-994a-4b71-8aab-358ad88da5a9@e25g2000prg.googlegroups.com>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!news.internetia.pl!news.nask.pl!news.nask.org.pl!news.germany.com!postnews.google.com!e25g2000prg.googlegroups.com!not-for-mailReferences:
<fghgeo$spf$1@nemesis.news.tpi.pl> <fh1tjd$dtt$1@bozon2.softax.pl> <fh2lj6$qkh$1@news.vectranet.pl> <fha3as$pap$1@bozon2.softax.pl> <fhaj8u$e02$1@news.vectranet.pl> <fhf09d$ohq$1@bozon2.softax.pl> <fhfi9l$640$1@news.vectranet.pl> <fhurmu$5d9$1@bozon2.softax.pl> <fhv020$8k1$1@news.vectranet.pl> <fi1bs4$nn3$1@bozon2.softax.pl> <fi27ds$gt1$1@kujawiak.man.lodz.pl> <1195688300.8426.30.camel@qrnik> <fi3ems$7ig$1@kujawiak.man.lodz.pl> <1195734091.8426.77.camel@qrnik> <fi6n5f$fpr$1@kujawiak.man.lodz.pl> <1195858230.20523.107.camel@qrnik> <fie2un$cbn$1@kujawiak.man.lodz.pl> <1196076390.30869.52.camel@qrnik> <fj1tmo$52u$1@kujawiak.man.lodz.pl> <1101d6ea-b312-4214-b153-8e1cc26a99ba@n20g2000hsh.googlegroups.com> <fj69vc$te$1@kujawiak.man.lodz.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!newsfeed.gazeta.pl!opal.futuro.pl!news.internetia.pl!news.nask.pl!news.nask.org.pl!news.germany.com!postnews.google.com!e25g2000prg.googlegroups.com!not-for-mail From: Maciej Sobczak <see.my.homepage@gmail.com> Newsgroups: pl.comp.lang.c Subject: Re: Ciemna strona C++ Date: Wed, 5 Dec 2007 06:14:03 -0800 (PST) Organization: http://groups.google.com Lines: 77 Message-ID: <240a4947-994a-4b71-8aab-358ad88da5a9@e25g2000prg.googlegroups.com> References: <fghgeo$spf$1@nemesis.news.tpi.pl> <fh1tjd$dtt$1@bozon2.softax.pl> <fh2lj6$qkh$1@news.vectranet.pl> <fha3as$pap$1@bozon2.softax.pl> <fhaj8u$e02$1@news.vectranet.pl> <fhf09d$ohq$1@bozon2.softax.pl> <fhfi9l$640$1@news.vectranet.pl> <fhurmu$5d9$1@bozon2.softax.pl> <fhv020$8k1$1@news.vectranet.pl> <fi1bs4$nn3$1@bozon2.softax.pl> <fi27ds$gt1$1@kujawiak.man.lodz.pl> <1195688300.8426.30.camel@qrnik> <fi3ems$7ig$1@kujawiak.man.lodz.pl> <1195734091.8426.77.camel@qrnik> <fi6n5f$fpr$1@kujawiak.man.lodz.pl> <1195858230.20523.107.camel@qrnik> <fie2un$cbn$1@kujawiak.man.lodz.pl> <1196076390.30869.52.camel@qrnik> <fj1tmo$52u$1@kujawiak.man.lodz.pl> <1101d6ea-b312-4214-b153-8e1cc26a99ba@n20g2000hsh.googlegroups.com> <fj69vc$te$1@kujawiak.man.lodz.pl> NNTP-Posting-Host: 128.141.44.124 Mime-Version: 1.0 X-Trace: posting.google.com 1196864043 29958 127.0.0.1 (5 Dec 2007 14:14:03 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 5 Dec 2007 14:14:03 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: e25g2000prg.googlegroups.com; posting-host=128.141.44.124; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9,gzip(gfe),gzip(gfe) Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit