Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #58253 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2015-03-16 22:55 +0100 |
| Last post | 2015-03-19 11:19 +0000 |
| Articles | 20 on this page of 84 — 20 participants |
Back to article view | Back to comp.lang.c
What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-16 22:55 +0100
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-16 22:55 +0000
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-16 16:41 -0700
Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-17 00:05 +0000
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-17 01:12 +0000
Re: What is "complexifying" C? Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 13:58 -0700
Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 07:16 +0100
Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 13:50 +0000
Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 14:59 +0100
Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:22 +0100
Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-17 16:16 +0100
Re: What is "complexifying" C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-17 14:39 +0000
Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-17 15:23 +0000
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:40 -0700
Re: What is "complexifying" C? Kaz Kylheku <kaz@kylheku.com> - 2015-03-18 22:49 +0000
Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 13:55 +0000
Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 15:37 +0000
Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-19 23:06 +0100
Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-19 22:38 +0000
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 19:43 +1300
Re: What is "complexifying" C? jacob navia <jacob@jacob.remcomp.fr> - 2015-03-20 07:49 +0100
Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 02:29 -0500
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-20 21:37 +1300
Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-20 03:40 -0500
Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-20 10:18 +0100
Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-21 00:19 -0500
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 03:15 -0700
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 13:51 +1300
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 15:21 +1300
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 00:57 -0700
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-22 22:28 +1300
Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-22 02:59 -0700
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 11:16 -0700
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 07:25 +1300
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-22 12:06 -0700
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:01 +1300
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-23 03:09 -0700
Re: What is "complexifying" C? fir <profesor.fir@gmail.com> - 2015-03-23 01:42 -0700
Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 19:32 +0100
Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-22 17:34 -0500
Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 20:07 -0400
Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-23 00:00 -0500
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:04 +1300
Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-23 23:22 -0400
Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 14:54 -0400
Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-23 00:35 +0100
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:06 +1300
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 17:25 +1300
Re: What is "complexifying" C? Martin Shobe <martin.shobe@yahoo.com> - 2015-03-22 23:33 -0500
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-23 18:01 +1300
Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 09:41 -0400
Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 10:23 -0400
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-24 07:10 +1300
Re: What is "complexifying" C? James Kuyper <jameskuyper@verizon.net> - 2015-03-23 14:57 -0400
Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 09:36 +0100
Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 08:42 +0000
Re: What is "complexifying" C? David Brown <david.brown@hesbynett.no> - 2015-03-24 11:23 +0100
Re: What is "complexifying" C? Richard Heathfield <rjh@cpax.org.uk> - 2015-03-24 10:52 +0000
Re: What is "complexifying" C? raltbos@xs4all.nl (Richard Bos) - 2015-03-29 16:58 +0000
Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-22 02:38 +0100
Re: What is "complexifying" C? Richard Damon <Richard@Damon-Family.org> - 2015-03-22 09:11 -0400
Re: What is "complexifying" C? Les Cargill <lcargill99@comcast.com> - 2015-03-20 06:30 -0500
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-20 10:31 +0000
Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-20 13:49 +0000
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 09:23 -0700
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-21 08:28 +1300
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-20 01:04 -0700
Re: What is "complexifying" C? Keith Thompson <kst-u@mib.org> - 2015-03-17 08:05 -0700
Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 16:08 +0100
Re: What is "complexifying" C? Keith Thompson <kst-u@mib.org> - 2015-03-17 11:09 -0700
Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 21:37 +0100
Re: What is "complexifying" C? Robert Wessel <robertwessel2@yahoo.com> - 2015-03-18 00:40 -0500
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-17 15:34 +0000
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-17 15:06 +0000
Re: What is "complexifying" C? Melzzzzz <mel@zzzzz.com> - 2015-03-17 00:05 +0100
Re: What is "complexifying" C? Greg Martin <greg.at.softsprocket@dot.com> - 2015-03-16 23:20 +0000
Re: What is "complexifying" C? Ian Collins <ian-news@hotmail.com> - 2015-03-17 16:42 +1300
Re: What is "complexifying" C? Mark Storkamp <mstorkamp@yahoo.com> - 2015-03-17 08:59 -0500
Re: What is "complexifying" C? jacob navia <jacob@spamsink.net> - 2015-03-17 15:18 +0100
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-17 14:41 +0000
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-18 15:47 -0700
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-19 00:26 +0000
Re: What is "complexifying" C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-19 03:23 -0700
Re: What is "complexifying" C? Bartc <bc@freeuk.com> - 2015-03-19 11:19 +0000
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | jacob navia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-03-20 07:49 +0100 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <megftf$vmn$1@speranza.aioe.org> |
| In reply to | #58465 |
Le 20/03/2015 07:43, Ian Collins a écrit : > Greg Martin wrote: >> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote: >>> >>> Look at what happened with complex numbers. There are MANY ways of doing >>> a complex division, if you care about speed, or accuracy or robustness, >>> or other criteria. With the language solution you >>> >>> 1) Complexify enormously ALL the C implementations that have to add that >>> feature. >>> >>> 2) You tie the user to its implementation decisions. He/she can't change >>> the way a complex division is done. >>> >>> Can you propose another solution? >>> >> >> You mean other then writing the code to do it? No. >> >> How does operator overloading remove the burden of writing the code? Or >> are you suggesting it's not possible for programmers to operate on >> complex numbers in C? > > His point was in a language with operating overloading (such as C++) you > don't have to change the core language in order to add new numeric > types, be they complex number of otherwise. > > The burden is removed from the language standard and implementation and > in the case of complex numbers, the user gets the flexibility of > choosing the underlying type and implementation. > EXACTLY! Mr Martin just doesn't want to answer. He says: "Just write the code todo it" without seeing that you can't write any code to do it since you can't rewrite complex division. It is wired into the compiler!
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-20 02:29 -0500 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <3dingapi21g9aj30pel30s2288h02r5c0g@4ax.com> |
| In reply to | #58465 |
On Fri, 20 Mar 2015 19:43:21 +1300, Ian Collins <ian-news@hotmail.com> wrote: >Greg Martin wrote: >> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote: >>> >>> Look at what happened with complex numbers. There are MANY ways of doing >>> a complex division, if you care about speed, or accuracy or robustness, >>> or other criteria. With the language solution you >>> >>> 1) Complexify enormously ALL the C implementations that have to add that >>> feature. >>> >>> 2) You tie the user to its implementation decisions. He/she can't change >>> the way a complex division is done. >>> >>> Can you propose another solution? >>> >> >> You mean other then writing the code to do it? No. >> >> How does operator overloading remove the burden of writing the code? Or >> are you suggesting it's not possible for programmers to operate on >> complex numbers in C? > >His point was in a language with operating overloading (such as C++) you >don't have to change the core language in order to add new numeric >types, be they complex number of otherwise. > >The burden is removed from the language standard and implementation and >in the case of complex numbers, the user gets the flexibility of >choosing the underlying type and implementation. Although in the case of something like complex, I can't work up a lot of sympathy for the compiler implementers. Or for that matter, adding bignum and decimal math. Really, a few more data types in a language like C is just not a big deal. And there are really a pretty small set of things you're really want to overload on the numeric operators anyway. While operator overloading certainly has its uses, I'd judge that a basic implementation of classes would be far more useful in C, just for the encapsulation. IMO, polymorphism ends up rather down the list, somewhere after inheritance. But that's me. Jacob obviously made a different judgment.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-20 21:37 +1300 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <cn24hhF9khqU2@mid.individual.net> |
| In reply to | #58468 |
Robert Wessel wrote: > On Fri, 20 Mar 2015 19:43:21 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> Greg Martin wrote: >>> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote: >>>> >>>> Look at what happened with complex numbers. There are MANY ways of doing >>>> a complex division, if you care about speed, or accuracy or robustness, >>>> or other criteria. With the language solution you >>>> >>>> 1) Complexify enormously ALL the C implementations that have to add that >>>> feature. >>>> >>>> 2) You tie the user to its implementation decisions. He/she can't change >>>> the way a complex division is done. >>>> >>>> Can you propose another solution? >>>> >>> >>> You mean other then writing the code to do it? No. >>> >>> How does operator overloading remove the burden of writing the code? Or >>> are you suggesting it's not possible for programmers to operate on >>> complex numbers in C? >> >> His point was in a language with operating overloading (such as C++) you >> don't have to change the core language in order to add new numeric >> types, be they complex number of otherwise. >> >> The burden is removed from the language standard and implementation and >> in the case of complex numbers, the user gets the flexibility of >> choosing the underlying type and implementation. > > > Although in the case of something like complex, I can't work up a lot > of sympathy for the compiler implementers. Or for that matter, adding > bignum and decimal math. Really, a few more data types in a language > like C is just not a big deal. Until you want to use one of those type for complex numbers... > And there are really a pretty small set of things you're really want > to overload on the numeric operators anyway. That's true. It's much more common in C++ to overload the function call or index operators. > While operator overloading certainly has its uses, I'd judge that a > basic implementation of classes would be far more useful in C, just > for the encapsulation. IMO, polymorphism ends up rather down the > list, somewhere after inheritance. But that's me. Jacob obviously > made a different judgment. I agree again. The one thing C++ can do that C can't is manage resource lifetime with constructors and destructors. But then again, if you want C++, you know where to find it... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-20 03:40 -0500 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <k4nngap5rqslntgg7djj2i5m5u4ni81k1b@4ax.com> |
| In reply to | #58474 |
On Fri, 20 Mar 2015 21:37:04 +1300, Ian Collins <ian-news@hotmail.com> wrote: >Robert Wessel wrote: >> On Fri, 20 Mar 2015 19:43:21 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> Greg Martin wrote: >>>> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote: >>>>> >>>>> Look at what happened with complex numbers. There are MANY ways of doing >>>>> a complex division, if you care about speed, or accuracy or robustness, >>>>> or other criteria. With the language solution you >>>>> >>>>> 1) Complexify enormously ALL the C implementations that have to add that >>>>> feature. >>>>> >>>>> 2) You tie the user to its implementation decisions. He/she can't change >>>>> the way a complex division is done. >>>>> >>>>> Can you propose another solution? >>>>> >>>> >>>> You mean other then writing the code to do it? No. >>>> >>>> How does operator overloading remove the burden of writing the code? Or >>>> are you suggesting it's not possible for programmers to operate on >>>> complex numbers in C? >>> >>> His point was in a language with operating overloading (such as C++) you >>> don't have to change the core language in order to add new numeric >>> types, be they complex number of otherwise. >>> >>> The burden is removed from the language standard and implementation and >>> in the case of complex numbers, the user gets the flexibility of >>> choosing the underlying type and implementation. >> >> >> Although in the case of something like complex, I can't work up a lot >> of sympathy for the compiler implementers. Or for that matter, adding >> bignum and decimal math. Really, a few more data types in a language >> like C is just not a big deal. > >Until you want to use one of those type for complex numbers... I meant that the compiler implementers (all several dozen of them?) should not find implementing a few extra types (like complex) particularly onerous, and then I have no problem using them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-03-20 10:18 +0100 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <megok4$7f0$1@dont-email.me> |
| In reply to | #58475 |
On 20/03/15 09:40, Robert Wessel wrote: > On Fri, 20 Mar 2015 21:37:04 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> Robert Wessel wrote: >>> On Fri, 20 Mar 2015 19:43:21 +1300, Ian Collins <ian-news@hotmail.com> >>> wrote: >>> >>>> Greg Martin wrote: >>>>> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote: >>>>>> >>>>>> Look at what happened with complex numbers. There are MANY ways of doing >>>>>> a complex division, if you care about speed, or accuracy or robustness, >>>>>> or other criteria. With the language solution you >>>>>> >>>>>> 1) Complexify enormously ALL the C implementations that have to add that >>>>>> feature. >>>>>> >>>>>> 2) You tie the user to its implementation decisions. He/she can't change >>>>>> the way a complex division is done. >>>>>> >>>>>> Can you propose another solution? >>>>>> >>>>> >>>>> You mean other then writing the code to do it? No. >>>>> >>>>> How does operator overloading remove the burden of writing the code? Or >>>>> are you suggesting it's not possible for programmers to operate on >>>>> complex numbers in C? >>>> >>>> His point was in a language with operating overloading (such as C++) you >>>> don't have to change the core language in order to add new numeric >>>> types, be they complex number of otherwise. >>>> >>>> The burden is removed from the language standard and implementation and >>>> in the case of complex numbers, the user gets the flexibility of >>>> choosing the underlying type and implementation. >>> >>> >>> Although in the case of something like complex, I can't work up a lot >>> of sympathy for the compiler implementers. Or for that matter, adding >>> bignum and decimal math. Really, a few more data types in a language >>> like C is just not a big deal. >> >> Until you want to use one of those type for complex numbers... > > > I meant that the compiler implementers (all several dozen of them?) > should not find implementing a few extra types (like complex) > particularly onerous, and then I have no problem using them. > Compiler implementers (all several dozen of them) usually have more important things to do than implement complex number handling - if that can be done by less niche developers, such as library writers, then that's a better solution. Some types, such as scaled integers, are best done by the compiler writers because on targets such as microcontrollers and DSP's the cpu often has special instructions to make this kind of thing much more efficient. And bignum support is in a category of its own - that requires memory management of some sort to support arbitrary precision, and that's not something you want baked into the compiler.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-21 00:19 -0500 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <3avpgahiv4sbui0a2t8sl79dqd0r18ent5@4ax.com> |
| In reply to | #58479 |
On Fri, 20 Mar 2015 10:18:45 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 20/03/15 09:40, Robert Wessel wrote: >> On Fri, 20 Mar 2015 21:37:04 +1300, Ian Collins <ian-news@hotmail.com> >> wrote: >> >>> Robert Wessel wrote: >>>> On Fri, 20 Mar 2015 19:43:21 +1300, Ian Collins <ian-news@hotmail.com> >>>> wrote: >>>> >>>>> Greg Martin wrote: >>>>>> On 2015-03-19, jacob navia <jacob@jacob.remcomp.fr> wrote: >>>>>>> >>>>>>> Look at what happened with complex numbers. There are MANY ways of doing >>>>>>> a complex division, if you care about speed, or accuracy or robustness, >>>>>>> or other criteria. With the language solution you >>>>>>> >>>>>>> 1) Complexify enormously ALL the C implementations that have to add that >>>>>>> feature. >>>>>>> >>>>>>> 2) You tie the user to its implementation decisions. He/she can't change >>>>>>> the way a complex division is done. >>>>>>> >>>>>>> Can you propose another solution? >>>>>>> >>>>>> >>>>>> You mean other then writing the code to do it? No. >>>>>> >>>>>> How does operator overloading remove the burden of writing the code? Or >>>>>> are you suggesting it's not possible for programmers to operate on >>>>>> complex numbers in C? >>>>> >>>>> His point was in a language with operating overloading (such as C++) you >>>>> don't have to change the core language in order to add new numeric >>>>> types, be they complex number of otherwise. >>>>> >>>>> The burden is removed from the language standard and implementation and >>>>> in the case of complex numbers, the user gets the flexibility of >>>>> choosing the underlying type and implementation. >>>> >>>> >>>> Although in the case of something like complex, I can't work up a lot >>>> of sympathy for the compiler implementers. Or for that matter, adding >>>> bignum and decimal math. Really, a few more data types in a language >>>> like C is just not a big deal. >>> >>> Until you want to use one of those type for complex numbers... >> >> >> I meant that the compiler implementers (all several dozen of them?) >> should not find implementing a few extra types (like complex) >> particularly onerous, and then I have no problem using them. >> > >Compiler implementers (all several dozen of them) usually have more >important things to do than implement complex number handling - if that >can be done by less niche developers, such as library writers, then >that's a better solution. > >Some types, such as scaled integers, are best done by the compiler >writers because on targets such as microcontrollers and DSP's the cpu >often has special instructions to make this kind of thing much more >efficient. > >And bignum support is in a category of its own - that requires memory >management of some sort to support arbitrary precision, and that's not >something you want baked into the compiler. They're certainly free to contract out some of that code. Heck, EDG will sell you a whole C++ compiler front end. I can't see that this would be any harder. OTOH, the basic complex operations are not exactly a mystery these days. And memory management is baked into a lot of compilers, just not commonly C ones. And it doesn't have to be very baked in - just call __internal_bignum_malloc() and demand the local C library support that if the user wants to use bignums.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-20 03:15 -0700 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <3cb9b37a-d3fa-478b-b116-bbb737753cc8@googlegroups.com> |
| In reply to | #58474 |
On Friday, March 20, 2015 at 8:37:12 AM UTC, Ian Collins wrote: > > I agree again. The one thing C++ can do that C can't is manage resource > lifetime with constructors and destructors. But then again, if you want > C++, you know where to find it... > lcc_win has garbage collection. So effectively you have automatic destructors. C++ allows you to do things like close a file or make an space invader explode in a destructor, but generally this is a bad idea (maybe not the space invaders). Destructors should just free memory, detaching should be done explicitly.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-22 13:51 +1300 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <cn6i19FdhbaU1@mid.individual.net> |
| In reply to | #58480 |
Malcolm McLean wrote: > On Friday, March 20, 2015 at 8:37:12 AM UTC, Ian Collins wrote: >> >> I agree again. The one thing C++ can do that C can't is manage resource >> lifetime with constructors and destructors. But then again, if you want >> C++, you know where to find it... >> > lcc_win has garbage collection. > So effectively you have automatic destructors. C++ allows you to do things like > close a file or make an space invader explode in a destructor, but generally this > is a bad idea (maybe not the space invaders). Destructors should just free > memory, detaching should be done explicitly. It certainly is not a bad idea, it is one of the most useful tools in the C++ toolbox. Amongst other things, it makes resource leaks a thing of the past. Automatic resource management also removes any possible justification for using goto and those horribly kludgy finalisers in other OO languages. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-22 15:21 +1300 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <cn6n93FdhbaU2@mid.individual.net> |
| In reply to | #58621 |
Stefan Ram wrote: > Ian Collins <ian-news@hotmail.com> writes: >> It certainly is not a bad idea, it is one of the most useful tools in >> the C++ toolbox. Amongst other things, it makes resource leaks a thing >> of the past. > > Only in the case of nested lifetimes (which can be handled by a stack). > But this is the easy case. > > Nested lifetime: When the creation of o0 happens before the creation of o1, > then the destruction of o1 happens before the destruction of o0. It is also the most common case. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-22 00:57 -0700 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <2a74b8f4-d5b5-417b-9277-cc668478bfce@googlegroups.com> |
| In reply to | #58621 |
On Sunday, March 22, 2015 at 12:52:02 AM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
> >
> > lcc_win has garbage collection.
> > So effectively you have automatic destructors. C++ allows you to do
> > things like close a file or make an space invader explode in a
> > destructor, but generally this is a bad idea (maybe not the space
> > invaders). Destructors should just free memory, detaching should be
> > done explicitly.
>
> It certainly is not a bad idea, it is one of the most useful tools in
> the C++ toolbox. Amongst other things, it makes resource leaks a thing
> of the past. Automatic resource management also removes any possible
> justification for using goto and those horribly kludgy finalisers in
> other OO languages.
>
I think you'll agree that this
class SpaceInvader()
{
double x, y;
~SpaceInvader()
{
putExposionOnScreen(x, y);
}
}
PlayerFire()
{
if(bullet_hit)
delete invader;
}
has a place only in joke code.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-22 22:28 +1300 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <cn7ga8FdhbaU4@mid.individual.net> |
| In reply to | #58629 |
Malcolm McLean wrote:
> On Sunday, March 22, 2015 at 12:52:02 AM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>>
>>> lcc_win has garbage collection.
>>> So effectively you have automatic destructors. C++ allows you to do
>>> things like close a file or make an space invader explode in a
>>> destructor, but generally this is a bad idea (maybe not the space
>>> invaders). Destructors should just free memory, detaching should be
>>> done explicitly.
>>
>> It certainly is not a bad idea, it is one of the most useful tools in
>> the C++ toolbox. Amongst other things, it makes resource leaks a thing
>> of the past. Automatic resource management also removes any possible
>> justification for using goto and those horribly kludgy finalisers in
>> other OO languages.
>>
> I think you'll agree that this
>
> class SpaceInvader()
> {
> double x, y;
> ~SpaceInvader()
> {
> putExposionOnScreen(x, y);
> }
> }
>
> PlayerFire()
> {
> if(bullet_hit)
> delete invader;
>
> }
>
>
> has a place only in joke code.
Maybe id does, but closing a file when it goes out of scope certainly
does not.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-22 02:59 -0700 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <cadf474f-5f80-4707-ad5b-d63066834fe2@googlegroups.com> |
| In reply to | #58635 |
W dniu niedziela, 22 marca 2015 10:28:50 UTC+1 użytkownik Ian Collins napisał:
> Malcolm McLean wrote:
> > On Sunday, March 22, 2015 at 12:52:02 AM UTC, Ian Collins wrote:
> >> Malcolm McLean wrote:
> >>>
> >>> lcc_win has garbage collection.
> >>> So effectively you have automatic destructors. C++ allows you to do
> >>> things like close a file or make an space invader explode in a
> >>> destructor, but generally this is a bad idea (maybe not the space
> >>> invaders). Destructors should just free memory, detaching should be
> >>> done explicitly.
> >>
> >> It certainly is not a bad idea, it is one of the most useful tools in
> >> the C++ toolbox. Amongst other things, it makes resource leaks a thing
> >> of the past. Automatic resource management also removes any possible
> >> justification for using goto and those horribly kludgy finalisers in
> >> other OO languages.
> >>
> > I think you'll agree that this
> >
> > class SpaceInvader()
> > {
> > double x, y;
> > ~SpaceInvader()
> > {
> > putExposionOnScreen(x, y);
> > }
> > }
> >
> > PlayerFire()
> > {
> > if(bullet_hit)
> > delete invader;
> >
> > }
> >
> >
> > has a place only in joke code.
>
> Maybe id does, but closing a file when it goes out of scope certainly
> does not.
>
are you sure? ;/
ps i somewhat doubt in need of closing,
yet as i doubt in need of 'opening'
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-22 11:16 -0700 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <946d02bc-ea08-44ac-9b3b-7e5092b7a05f@googlegroups.com> |
| In reply to | #58635 |
On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
>
> Maybe id does, but closing a file when it goes out of scope certainly
> does not.
>
The C++ code
class MyStream
{
FILE *fp;
~MyStream()
{
fclose(fp);
}
}
isn't joke code. But it's obviously written by someone unaware of the
fact that fclose() can return an error condition.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-23 07:25 +1300 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <cn8fo3FdhbaU5@mid.individual.net> |
| In reply to | #58678 |
Malcolm McLean wrote:
> On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>
>> Maybe id does, but closing a file when it goes out of scope certainly
>> does not.
>>
> The C++ code
>
> class MyStream
> {
> FILE *fp;
> ~MyStream()
> {
> fclose(fp);
> }
> }
>
> isn't joke code. But it's obviously written by someone unaware of the
> fact that fclose() can return an error condition.
How many C programmers check the return form fclose?
I just checked a large open source code base (the Illumos kernel) and
the there are ~3000 calls to fclose, ~1900 of those are of the form
"(void) fclose(fp)"
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-22 12:06 -0700 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <6d47d194-da07-45fb-9e12-b6d85483037b@googlegroups.com> |
| In reply to | #58679 |
On Sunday, March 22, 2015 at 6:25:16 PM UTC, Ian Collins wrote:
> Malcolm McLean wrote:
> > On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
> >> Malcolm McLean wrote:
> >>
> >> Maybe id does, but closing a file when it goes out of scope certainly
> >> does not.
> >>
> > The C++ code
> >
> > class MyStream
> > {
> > FILE *fp;
> > ~MyStream()
> > {
> > fclose(fp);
> > }
> > }
> >
> > isn't joke code. But it's obviously written by someone unaware of the
> > fact that fclose() can return an error condition.
>
> How many C programmers check the return form fclose?
>
> I just checked a large open source code base (the Illumos kernel) and
> the there are ~3000 calls to fclose, ~1900 of those are of the form
> "(void) fclose(fp)"
>
I seldom check fclose().
Normally you can get away with it, or, for scratch programs, putting
up an error message isn't going to help.
It's the general principle. Operations like closing files, which aren't
pure frees of memory, shouldn't be in destructors, at least in C++.
If at some point you need to move from unchecked fclose() to checked
fclose(), and all the FILE *s are wrapped up in C++ classes written
with the fclose() in the destructor, then you've got a major headache.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-03-23 17:01 +1300 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <cn9hgdF9hh7U1@mid.individual.net> |
| In reply to | #58682 |
Malcolm McLean wrote:
> On Sunday, March 22, 2015 at 6:25:16 PM UTC, Ian Collins wrote:
>> Malcolm McLean wrote:
>>> On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
>>>> Malcolm McLean wrote:
>>>>
>>>> Maybe id does, but closing a file when it goes out of scope certainly
>>>> does not.
>>>>
>>> The C++ code
>>>
>>> class MyStream
>>> {
>>> FILE *fp;
>>> ~MyStream()
>>> {
>>> fclose(fp);
>>> }
>>> }
>>>
>>> isn't joke code. But it's obviously written by someone unaware of the
>>> fact that fclose() can return an error condition.
>>
>> How many C programmers check the return form fclose?
>>
>> I just checked a large open source code base (the Illumos kernel) and
>> the there are ~3000 calls to fclose, ~1900 of those are of the form
>> "(void) fclose(fp)"
>>
> I seldom check fclose().
> Normally you can get away with it, or, for scratch programs, putting
> up an error message isn't going to help.
>
> It's the general principle. Operations like closing files, which aren't
> pure frees of memory, shouldn't be in destructors, at least in C++.
That goes against one of the cornerstones of modern C++: RAII. See
http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
> If at some point you need to move from unchecked fclose() to checked
> fclose(), and all the FILE *s are wrapped up in C++ classes written
> with the fclose() in the destructor, then you've got a major headache.
Actually you don't. You hare in a far better position than you would be
with the closes scattered throughout the code. You only have to change
the code in one place.
I use a reference counting object to manage file descriptors in my C++
code. I can call the object's close() member if I want to close a file
descriptor early, but I rarely do. If I want to add debug to file
closes I just add it to the objects destructor.
Many of the system libraries I use have void close_XXX() functions, so
there is no risk (real or perceived) in encapsulating this in an object
destructor. I know what ever my code does (return early, throw an
exception) I won't leak handles.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-03-23 03:09 -0700 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <97d8ab80-e8e4-4609-9171-aa1f35a49040@googlegroups.com> |
| In reply to | #58708 |
On Monday, March 23, 2015 at 4:01:26 AM UTC, Ian Collins wrote: > Malcolm McLean wrote: > > Actually you don't. You hare in a far better position than you would be > with the closes scattered throughout the code. You only have to change > the code in one place. > That's unlikely to work. If close fails, and you must handle the error, normally you'll have to report to the user that his file wasn't flushed properly (which is why fclose() is allowed to fail) and may be corrupt. Sometimes you might want to do a check on the file to see if most of it is recoverable. There's no quick fix you can apply to a C++ style destructor. At worst you'd be putting up options dialogs from the destructor and switching on a global "destructor call context" variable. It's obvious at this point that you can't handle the close() in the destructor.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-03-23 01:42 -0700 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <f4342749-b9dd-4dd4-9cf5-1963260176e8@googlegroups.com> |
| In reply to | #58682 |
W dniu niedziela, 22 marca 2015 20:06:46 UTC+1 użytkownik Malcolm McLean napisał:
> On Sunday, March 22, 2015 at 6:25:16 PM UTC, Ian Collins wrote:
> > Malcolm McLean wrote:
> > > On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
> > >> Malcolm McLean wrote:
> > >>
> > >> Maybe id does, but closing a file when it goes out of scope certainly
> > >> does not.
> > >>
> > > The C++ code
> > >
> > > class MyStream
> > > {
> > > FILE *fp;
> > > ~MyStream()
> > > {
> > > fclose(fp);
> > > }
> > > }
> > >
> > > isn't joke code. But it's obviously written by someone unaware of the
> > > fact that fclose() can return an error condition.
> >
> > How many C programmers check the return form fclose?
> >
> > I just checked a large open source code base (the Illumos kernel) and
> > the there are ~3000 calls to fclose, ~1900 of those are of the form
> > "(void) fclose(fp)"
> >
> I seldom check fclose().
> Normally you can get away with it, or, for scratch programs, putting
> up an error message isn't going to help.
>
> It's the general principle. Operations like closing files, which aren't
> pure frees of memory, shouldn't be in destructors, at least in C++.
> If at some point you need to move from unchecked fclose() to checked
> fclose(), and all the FILE *s are wrapped up in C++ classes written
> with the fclose() in the destructor, then you've got a major headache.
preposterous thing (i didnt know that) - normal in c++ ;c
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-03-22 19:32 +0100 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <20150322193240.6099d589@maxa-pc> |
| In reply to | #58678 |
On Sun, 22 Mar 2015 11:16:02 -0700 (PDT)
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
> On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
> > Malcolm McLean wrote:
> >
> > Maybe id does, but closing a file when it goes out of scope
> > certainly does not.
> >
> The C++ code
>
> class MyStream
> {
> FILE *fp;
> ~MyStream()
> {
> fclose(fp);
> }
> }
>
> isn't joke code. But it's obviously written by someone unaware of the
> fact that fclose() can return an error condition.
>
>
What can one do except log error condition? One can neither return
error nor throw exception (as it is no no throwing from destructor).
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-03-22 17:34 -0500 |
| Subject | Re: What is "complexifying" C? |
| Message-ID | <kogugaphmgio74fndff4s3fmta1lpfaqkh@4ax.com> |
| In reply to | #58680 |
On Sun, 22 Mar 2015 19:32:40 +0100, Melzzzzz <mel@zzzzz.com> wrote:
>On Sun, 22 Mar 2015 11:16:02 -0700 (PDT)
>Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
>
>> On Sunday, March 22, 2015 at 9:28:50 AM UTC, Ian Collins wrote:
>> > Malcolm McLean wrote:
>> >
>> > Maybe id does, but closing a file when it goes out of scope
>> > certainly does not.
>> >
>> The C++ code
>>
>> class MyStream
>> {
>> FILE *fp;
>> ~MyStream()
>> {
>> fclose(fp);
>> }
>> }
>>
>> isn't joke code. But it's obviously written by someone unaware of the
>> fact that fclose() can return an error condition.
>>
>>
>
>What can one do except log error condition? One can neither return
>error nor throw exception (as it is no no throwing from destructor).
I believe that's his point - doing the fclose in a dtor makes it very
hard to handle it failing in a meaningful way.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web