Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #27254 > unrolled thread
| Started by | gus gassmann <gus@nospam.com> |
|---|---|
| First post | 2012-10-17 06:49 -0300 |
| Last post | 2012-10-19 07:37 -0400 |
| Articles | 20 on this page of 126 — 28 participants |
Back to article view | Back to comp.lang.c
C/C++ question about dynamic "static struct" gus gassmann <gus@nospam.com> - 2012-10-17 06:49 -0300
Re: C/C++ question about dynamic "static struct" Noob <root@127.0.0.1> - 2012-10-17 13:08 +0200
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 08:19 -0400
Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-17 15:19 +0000
Re: C/C++ question about dynamic "static struct" gus gassmann <gus@nospam.com> - 2012-10-17 18:47 -0300
Re: C/C++ question about dynamic "static struct" Ike Naar <ike@iceland.freeshell.org> - 2012-10-17 22:46 +0000
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 07:13 +0000
Re: C/C++ question about dynamic "static struct" Ike Naar <ike@sverige.freeshell.org> - 2012-10-18 22:45 +0000
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 18:58 -0400
Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-18 09:55 +0200
Re: C/C++ question about dynamic "static struct" jacob navia <jacob@spamsink.net> - 2012-10-18 10:13 +0200
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 08:23 +0000
Re: C/C++ question about dynamic "static struct" jacob navia <jacob@spamsink.net> - 2012-10-18 11:17 +0200
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-18 23:37 +1300
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-18 15:35 +0100
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-18 21:45 +1300
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-18 15:03 +0100
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-18 07:18 -0400
Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-18 17:43 +0200
Re: C/C++ question about dynamic "static struct" William Ahern <william@wilbur.25thandClement.com> - 2012-10-18 13:52 -0700
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-19 21:34 +1300
Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-19 11:03 +0200
Re: C/C++ question about dynamic "static struct" "BartC" <bc@freeuk.com> - 2012-10-20 14:03 +0100
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 09:27 +0000
Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-19 13:43 +0200
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 12:46 +0000
Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-19 10:14 -0700
Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-19 14:53 -0500
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 21:22 +0000
Re: C/C++ question about dynamic "static struct" William Ahern <william@wilbur.25thandClement.com> - 2012-10-19 11:21 -0700
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 21:29 +0000
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-19 18:53 -0400
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-20 12:13 +1300
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-20 05:55 +0000
Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-20 13:24 +0200
Re: C/C++ question about dynamic "static struct" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-20 12:54 +0100
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-20 06:45 -0700
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:20 +1300
Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-20 22:28 +0200
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:05 +0000
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 02:23 -0500
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:32 +0000
Re: C/C++ question about dynamic "static struct" "BartC" <bc@freeuk.com> - 2012-10-21 11:56 +0100
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 12:54 -0500
Re: C/C++ question about dynamic "static struct" ptyxs <kerloch@gmail.com> - 2012-10-22 13:43 +0200
Re: C/C++ question about dynamic "static struct" gwowen <gwowen@gmail.com> - 2012-10-26 03:37 -0700
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-26 07:33 -0500
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:14 -0700
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:08 -0700
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-20 13:44 -0500
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 09:09 +1300
Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-20 22:31 +0200
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 02:11 -0500
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 20:28 +1300
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:40 +0000
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 13:31 -0500
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 08:41 +1300
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 16:24 -0500
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 07:52 +0000
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-22 14:02 -0500
Re: C/C++ question about dynamic "static struct" gwowen <gwowen@gmail.com> - 2012-10-26 03:41 -0700
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-26 07:53 -0500
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-26 09:51 -0400
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-26 13:48 -0400
Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-26 07:35 -0700
Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-26 18:42 -0500
Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 04:21 -0700
Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-27 08:06 -0500
Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 06:50 -0700
Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-27 11:13 -0500
Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 12:02 -0700
Re: C/C++ question about dynamic "static struct" Paavo Helde <myfirstname@osa.pri.ee> - 2012-10-27 15:46 -0500
Re: C/C++ question about dynamic "static struct" ImpalerCore <jadill33@gmail.com> - 2012-10-27 20:24 -0700
Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-27 20:11 +0200
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:43 -0700
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-27 13:52 -0500
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-27 14:40 -0500
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:35 -0700
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-27 14:24 -0500
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:36 -0700
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:08 +0000
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 02:51 -0500
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-21 21:09 +1300
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 12:16 +0100
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 11:55 +0100
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:30 -0700
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-20 09:06 -0400
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:11 +0000
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 11:56 +0100
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-21 07:43 -0400
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 08:13 +0000
Re: C/C++ question about dynamic "static struct" Steve Thompson <stevet810@gmail.com> - 2012-10-22 15:08 +0000
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-22 14:42 -0400
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-21 10:12 +0100
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-20 13:24 -0500
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:16 +0000
Re: C/C++ question about dynamic "static struct" Les Cargill <lcargill99@comcast.com> - 2012-10-21 13:57 -0500
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 08:17 +0000
Re: C/C++ question about dynamic "static struct" Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-20 22:41 +0200
Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-21 01:04 +0200
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:23 +0000
Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-21 19:33 +0000
Re: C/C++ question about dynamic "static struct" Greg Martin <greg@softsprocket.com> - 2012-10-21 13:20 -0700
Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-23 15:44 +0000
Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-23 20:01 +0200
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-20 06:13 -0700
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-21 07:25 +0000
Re: C/C++ question about dynamic "static struct" Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-10-27 05:54 -0700
Re: C/C++ question about dynamic "static struct" Old Wolf <oldwolf@inspire.net.nz> - 2012-11-11 14:58 -0800
Re: C/C++ question about dynamic "static struct" gof@somewhere.invalid (Adam Wysocki) - 2012-11-12 10:33 +0000
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-18 12:19 +1300
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 07:06 +0000
Re: C/C++ question about dynamic "static struct" Noob <root@127.0.0.1> - 2012-10-18 11:36 +0200
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 09:28 +0000
Re: C/C++ question about dynamic "static struct" Noob <root@127.0.0.1> - 2012-10-19 12:07 +0200
Re: C/C++ question about dynamic "static struct" gus gassmann <gus@nospam.com> - 2012-10-19 08:03 -0300
Re: C/C++ question about dynamic "static struct" Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-20 07:14 +0200
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-19 06:58 -0400
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 08:29 -0400
Re: C/C++ question about dynamic "static struct" Richard Damon <news.x.richarddamon@xoxy.net> - 2012-10-17 08:35 -0400
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-17 08:49 -0400
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-18 07:10 +0000
Re: C/C++ question about dynamic "static struct" Keith Thompson <kst-u@mib.org> - 2012-10-18 12:11 -0700
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 09:30 +0000
Re: C/C++ question about dynamic "static struct" Keith Thompson <kst-u@mib.org> - 2012-10-19 03:05 -0700
Re: C/C++ question about dynamic "static struct" James Kuyper <jameskuyper@verizon.net> - 2012-10-19 07:37 -0400
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-21 02:23 -0500 |
| Message-ID | <k607ts$b0c$1@dont-email.me> |
| In reply to | #27441 |
Juha Nieminen wrote: > In comp.lang.c++ Nick Keighley <nick_keighley_nospam@hotmail.com> wrote: >>>> However, in the case of C the "simplicity" is not actually a factor >>>> that helps writing simple programs. On the contrary, the "simplicity" >>>> of the language is actually a limiting factor. Rather than help, it >>>> impedes the writing of simple programs, >> >> I simply disagree > > You are entitled to. However, do you have an actual *argument* against > what I said, other than "I simply disagree" and "for instance?" > > In things like Lisp, Haskell and Scheme, the simplicity of the language > usually translates to the code itself becoming simple and elegant. Often > you can express in a couple of lines what requires dozens of lines in C++ > and hundreds of lines in C. And those two lines are not obfuscated beyond > comprehension, but (when you know the language) are clear, simple and > elegant. > > There are several reasons for this, but one of the most important ones is > that the language doesn't burden the programmer with things like memory > management. > > Many C advocates try to ride on this concept of "simplicity", but what > they are doing is a glaring fallacy of equivocation. They are (perhaps > deliberately) confusing the brevity of the language specification with > the concept of "simplicity" when talking about programming languages. > No, I think the "simplicity" of 'C' is more akin to exploiting the representation of data itself. Knowing how stuff is laid out in memory offers some measure of relief from some of the bureaucracy of some systems. Granted, Scheme/Lisp et al will always be more elegant because functional notation always is. There are times to build perfect Pythagorean castles in the air, and there are times to solder wires to things. The trick is knowing when. > Just because the language specification is relatively short (and it's > relatively easy to make a compiler for it) doesn't make the language > *simple*. This is a different kind of "simplicity". A kind that does > *not* help the programmer, but on the contrary is a limitation. > So they tell us. So they tell us. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-21 07:32 +0000 |
| Message-ID | <k608ee$ke2$1@speranza.aioe.org> |
| In reply to | #27446 |
In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: > No, I think the "simplicity" of 'C' is more akin to exploiting > the representation of data itself. Knowing how stuff is laid out > in memory offers some measure of relief from some of the bureaucracy > of some systems. Having the know the exact layout of the data used in the program is a really niche use case. Hardly something relevant to the average program. Regardless, since we are comparing C to C++, and the argument is that C is "simpler" (and therefore many people prefer to use it), what makes to you think that it's not possible (or even harder) to know the exact memory layout of the data in a C++ program? If, for example, you need for some reason to define a struct in some precise manner, there's nothing in C++ stopping you from doing that. There's nothing that C can offer in this regard that's not possible in C++. (And before you argue "well, if you are restricting your C++ program to what C already does, why use C++ at all?" the answer is: To make the *rest* of the program, ie. the parts that do *not* need that kind of low-level tinkering, much easier.)
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-10-21 11:56 +0100 |
| Message-ID | <k60kh3$890$1@dont-email.me> |
| In reply to | #27450 |
"Juha Nieminen" <nospam@thanks.invalid> wrote in message news:k608ee$ke2$1@speranza.aioe.org... > In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >> No, I think the "simplicity" of 'C' is more akin to exploiting >> the representation of data itself. Knowing how stuff is laid out >> in memory offers some measure of relief from some of the bureaucracy >> of some systems. > > Having the know the exact layout of the data used in the program is a > really niche use case. Hardly something relevant to the average program. I develop dynamic languages for my own use. Unusually, these have always had a struct or 'record' data type, with the ability if necessary to precisely define the type and offsets of the elements (even more than C has!), as well as having just a bunch of dynamic elements when you don't care about how they are stored. And I use such structs all the time. Sometimes because it's necessary to interface with something with a specific layout; sometimes just for the pleasure of crafting a perfectly laid out, compact record type with no space wasted (with bonus points if it fits into a power-of-two size). I don't think it's a niche thing at all. If you rarely use it, then perhaps you have less need for a language like C anyway. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-21 12:54 -0500 |
| Message-ID | <k61cts$pr0$1@dont-email.me> |
| In reply to | #27450 |
Juha Nieminen wrote: > In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >> No, I think the "simplicity" of 'C' is more akin to exploiting >> the representation of data itself. Knowing how stuff is laid out >> in memory offers some measure of relief from some of the bureaucracy >> of some systems. > > Having the know the exact layout of the data used in the program is a > really niche use case. Hardly something relevant to the average program. > Where is that median/average program, anyway? For those, I use interpreters - Tcl and sometimes Python. > Regardless, since we are comparing C to C++, and the argument is that > C is "simpler" (and therefore many people prefer to use it), what makes > to you think that it's not possible (or even harder) to know the exact > memory layout of the data in a C++ program? > > If, for example, you need for some reason to define a struct in some > precise manner, there's nothing in C++ stopping you from doing that. > There's nothing that C can offer in this regard that's not possible > in C++. > It's not "possible" so much as it is "likely". Don't get me wrong; *yesterday*, I was working on about the third iteration of some C++ wrappers for very popular 'C' libraries. Very nice; makes the actual invoking solution much more elegant. Two of them were nothing more than a constructor and destructor apiece. One had exactly one more method than that. Turns 50 lines of 'C' into one line; a very easy-to-see improvement. > (And before you argue "well, if you are restricting your C++ program > to what C already does, why use C++ at all?" the answer is: To make > the *rest* of the program, ie. the parts that do *not* need that kind > of low-level tinkering, much easier.) > You're kind of begging the question a bit. If all the services are thoroughly bug free and never fail, then it's great. To badly paraphrase Voltaire, "hell is other people's code*." The more of it there is, the more bugs there are. *and we are them other people, too. There are all kinds of hubris we have to watch out for. Maintaining a balance is a constant struggle. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | ptyxs <kerloch@gmail.com> |
|---|---|
| Date | 2012-10-22 13:43 +0200 |
| Message-ID | <50853172.70902@gmail.com> |
| In reply to | #27467 |
Le 21/10/2012 19:54, Les Cargill a écrit : To badly > paraphrase Voltaire, "hell is other people's code*." The more of > it there is, the more bugs there are. > You probably meant 'to paraphrase Jean-Paul Sartre'... Voltaire has nothing to do with that sentence... Ptyxs
[toc] | [prev] | [next] | [standalone]
| From | gwowen <gwowen@gmail.com> |
|---|---|
| Date | 2012-10-26 03:37 -0700 |
| Message-ID | <74e65127-9534-4da9-901c-5808dc2eb4cc@10g2000vbu.googlegroups.com> |
| In reply to | #27498 |
On Oct 22, 12:43 pm, ptyxs <kerl...@gmail.com> wrote: > Le 21/10/2012 19:54, Les Cargill a écrit : > To badly> paraphrase Voltaire, "hell is other people's code*." The more of > > it there is, the more bugs there are. > > You probably meant 'to paraphrase Jean-Paul Sartre'... > Voltaire has nothing to do with that sentence... > Ptyxs Les was too busy correcting University Dons about category mistakes...
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-26 07:33 -0500 |
| Message-ID | <k6dvu7$t7i$1@dont-email.me> |
| In reply to | #27712 |
gwowen wrote: > On Oct 22, 12:43 pm, ptyxs <kerl...@gmail.com> wrote: >> Le 21/10/2012 19:54, Les Cargill a écrit : >> To badly> paraphrase Voltaire, "hell is other people's code*." The more of >>> it there is, the more bugs there are. >> >> You probably meant 'to paraphrase Jean-Paul Sartre'... >> Voltaire has nothing to do with that sentence... >> Ptyxs > > Les was too busy correcting University Dons about category mistakes... > LOLz! One a' them Frenchies, anyway! :) Trotting out "category error" on usenet is problematic - it's hard enough just getting people to agree to what words mean. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-10-27 05:14 -0700 |
| Message-ID | <d0eb0010-5ce9-4c0b-93f7-d38cc4895ac6@p11g2000vbi.googlegroups.com> |
| In reply to | #27450 |
On Oct 21, 8:32 am, Juha Nieminen <nos...@thanks.invalid> wrote: > In comp.lang.c++ Les Cargill <lcargil...@comcast.com> wrote: > > No, I think the "simplicity" of 'C' is more akin to exploiting > > the representation of data itself. Knowing how stuff is laid out > > in memory offers some measure of relief from some of the bureaucracy > > of some systems. > > Having the know the exact layout of the data used in the program is a > really niche use case. Hardly something relevant to the average program. besides it isn't true anyway. You have to know quite a bit about your compiler to know how data is laid out. In principle it can change at the drop of an optimisation flag > Regardless, since we are comparing C to C++, and the argument is that > C is "simpler" (and therefore many people prefer to use it), what makes > to you think that it's not possible (or even harder) to know the exact > memory layout of the data in a C++ program? > > If, for example, you need for some reason to define a struct in some > precise manner, there's nothing in C++ stopping you from doing that. > There's nothing that C can offer in this regard that's not possible > in C++. > > (And before you argue "well, if you are restricting your C++ program > to what C already does, why use C++ at all?" the answer is: To make > the *rest* of the program, ie. the parts that do *not* need that kind > of low-level tinkering, much easier.) yes I've seen programs with C down in the bowels doing lost of bit banging (near signal processing) but this was all embedded in classes that hid the nasty stuff from the rest of the program.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-10-27 05:08 -0700 |
| Message-ID | <3271d934-8231-4872-8e32-5863d539bee0@b19g2000vbt.googlegroups.com> |
| In reply to | #27441 |
On Oct 21, 8:05 am, Juha Nieminen <nos...@thanks.invalid> wrote: > In comp.lang.c++ Nick Keighley <nick_keighley_nos...@hotmail.com> wrote: > >> > However, in the case of C the "simplicity" is not actually a factor > >> > that helps writing simple programs. On the contrary, the "simplicity" > >> > of the language is actually a limiting factor. Rather than help, it > >> > impedes the writing of simple programs, > > > I simply disagree > > You are entitled to. However, do you have an actual *argument* against > what I said, other than "I simply disagree" and "for instance?" well I thought you were the one making the large claim; that a language that is "simple" because it's small and reasonably easy to learn isn't "simple" in its application. Obviously you can write horrible programs in any language. C (or reasonably well written C) is usually quite transparent. I have to admit these days I write C++. Even for noddy little programs (which I probably should be using a script for). std::vector, std::string just being too good to pass over. > In things like Lisp, Haskell and Scheme, the simplicity of the language > usually translates to the code itself becoming simple and elegant. probably never became good enough with any of these for it to kick. I quite like scheme but it never seemed to end up being really "simple". But I accept that's my fault. > Often > you can express in a couple of lines what requires dozens of lines in C++ > and hundreds of lines in C. And those two lines are not obfuscated beyond > comprehension, but (when you know the language) are clear, simple and > elegant. > > There are several reasons for this, but one of the most important ones is > that the language doesn't burden the programmer with things like memory > management. and garbage collection has its own problems > Many C advocates try to ride on this concept of "simplicity", but what > they are doing is a glaring fallacy of equivocation. They are (perhaps > deliberately) confusing the brevity of the language specification with > the concept of "simplicity" when talking about programming languages. > > Just because the language specification is relatively short (and it's > relatively easy to make a compiler for it) doesn't make the language > *simple*. This is a different kind of "simplicity". A kind that does > *not* help the programmer, but on the contrary is a limitation.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-20 13:44 -0500 |
| Message-ID | <k5urfv$bbd$1@dont-email.me> |
| In reply to | #27405 |
Juha Nieminen wrote: > In comp.lang.c++ Ian Collins <ian-news@hotmail.com> wrote: >>> I'm sure that's quite normal thinking for anyone who would label >>> themselves a "C++ programmer". However, you should not be surprised to >>> find very different thinking among the people frequenting comp.lang.c, >>> where this message is also cross-posted. Anyone bothering to monitor >>> comp.lang.c (and there's a fair number of us) can reasonably be expected >>> to choose the simplicity of C over the complexity of C++ in at least >>> some circumstances. You might question the validity of that choice, but >>> you can't expect such questions to go over very well in that newsgroup. >> >> A one who works with and enjoys both languages, the statement "choose >> the simplicity of C over the complexity of C++" is one I have trouble >> with. C is undoubtedly a simpler language, but the the solutions to >> many day to day problems are undoubtedly simpler in C++. >> >> So the choice is often "do I want the simple solution in a more complex >> language, or the more complex solution in a simple language?". > > That's also the problem I find with the "argument from simplicity", > as one could call it. > > When talking about C, making the simplicity argument is basically a > category error. Almost all arguments from "category error" are themselves category errors. So "mu". I've seen Oxford dons make massive piles of steaming nonsense out of "category error". > The argument is trying to appeal to the notion that > simpler higher-level languages (such as Lisp) are generally considered > better than overly complex languages. In those languages it is often > so that the same thing can be expressed in a much simpler and more > brief manner, and the result is much "leaner and cleaner" code than > in overly complicated languages. (For example the language specification > of Lisp is relatively short, yet the language itself is incredibly > expressive and powerful.) > > In other words, a simple language helps writing simple programs (that > are nevertheless very expressive.) > No, the thing about lisp is that it is *interpretive*. > However, in the case of C the "simplicity" is not actually a factor > that helps writing simple programs. On the contrary, the "simplicity" > of the language is actually a limiting factor. Rather than help, it > impedes the writing of simple programs, requiring many of even the > simplest tasks to have complex and error-prone implementations. It > often requires following strict coding conventions to avoid mistakes, > coding conventions that are completely unnecessary in truly simple > languages. Truly simple languages allow the programmer to concentrate > purely on the task at hand, without having to pay any attention to such > trivial and inconsequential matters as memory management and such. C++ is much *worse* for memory management than is 'C' - in that the possibility of memory leaks goes up. Absent writing GUI code, it's entirely possible to write entire deployable systems that use no dynamic memory at all in 'C'. indeed, that's been the shop standard most places I have worked. > C isn't that kind of language. In C the "simplicity" forces the > programmer to write complex programs that need to constantly be careful > about things that should normally be non-issues. > > This doesn't mean that C++ is a simple language in this regard. > However, C++ is a lot *better* in this regard than C. Yes, there are > coding conventions that need to be followed eg. because of memory > management reasons, but those conventions are simpler and easier to > follow, and much of the work is done automatically by the compiler. Not... really. Let's not confuse our preferences for facts, shall we? The subject is sufficiently complex that you have to figure out how to measure the thing being discussed - you can't constructively assert superiority with out doing a lot of work, and that's pretty boring work. It's actually both boring and terrifying. > C++ also offers many tools (in both native syntax and in the form of > the standard library) that makes many, many tasks a lot easier and > simpler than in C. > To my eye, the solutions there are uglier, and a choice like Tcl or Python makes C++ less interesting. Because interpreters provide a much better suite of "furniture". > The typical arguments that C++ is so much larger and more complex > than C, and that it requires significantly more learning, ring quite > hollow to the experienced C++ programmer. Because experienced programmer is experienced. The very basis for determining whether the language features are improvements is really complex and usually such discussions are simply people exposing biases. > Why would it matter to me > in the least bit if the language is large and requires a lot of > learning? That's completely inconsequential to me. Just... wow. It's a *huge* problem. I'm not "into languages" to be into languages, I am into them to be able to operate on teams that produce deployable systems that work without causing anybody any problems. A novice can really get 95% of everything they need to know about 'C' in a matter of months, while being productive under supervision. I am not sure there is a collection of ten people on the planet who , between them , know everything there is to know about C++. > It may be relevant > if we were talking about what a newbie programmer should learn, but > it's completely irrelevant to me. I know how to use the language > efficiently, and when given the choice between C or C++, there's just > no choice to make, because it's obvious. I choose the one that allows > me to implement the task at hand more easily, ie. C++. > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-21 09:09 +1300 |
| Message-ID | <aegemuFnpi3U12@mid.individual.net> |
| In reply to | #27419 |
On 10/21/12 07:44, Les Cargill wrote: > Juha Nieminen wrote: > >> However, in the case of C the "simplicity" is not actually a factor >> that helps writing simple programs. On the contrary, the "simplicity" >> of the language is actually a limiting factor. Rather than help, it >> impedes the writing of simple programs, requiring many of even the >> simplest tasks to have complex and error-prone implementations. It >> often requires following strict coding conventions to avoid mistakes, >> coding conventions that are completely unnecessary in truly simple >> languages. Truly simple languages allow the programmer to concentrate >> purely on the task at hand, without having to pay any attention to such >> trivial and inconsequential matters as memory management and such. > > C++ is much *worse* for memory management than is 'C' - in that > the possibility of memory leaks goes up. Absent writing GUI code, > it's entirely possible to write entire deployable systems that use no > dynamic memory at all in 'C'. indeed, that's been the shop > standard most places I have worked. You can do and some embedded code I've worked on does the same in C++. C simply can't do RAII, so C++ has a built in advantage when it comes to memory (or any other resource) management. The ability to automatically manage resources also removes the last excuse to use goto, but that's another story! >> C isn't that kind of language. In C the "simplicity" forces the >> programmer to write complex programs that need to constantly be careful >> about things that should normally be non-issues. >> >> This doesn't mean that C++ is a simple language in this regard. >> However, C++ is a lot *better* in this regard than C. Yes, there are >> coding conventions that need to be followed eg. because of memory >> management reasons, but those conventions are simpler and easier to >> follow, and much of the work is done automatically by the compiler. > > Not... really. Let's not confuse our preferences for facts, shall we? Just compare code using automatic resource management with code that does it by hand. Pay particular attention to the clean up code if the nth allocation in a function fails.... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2012-10-20 22:31 +0200 |
| Message-ID | <k5v1iq$gja$2@dont-email.me> |
| In reply to | #27423 |
Op 20-Oct-12 22:09, Ian Collins schreef: > On 10/21/12 07:44, Les Cargill wrote: >> Juha Nieminen wrote: >> >>> However, in the case of C the "simplicity" is not actually a factor >>> that helps writing simple programs. On the contrary, the "simplicity" >>> of the language is actually a limiting factor. Rather than help, it >>> impedes the writing of simple programs, requiring many of even the >>> simplest tasks to have complex and error-prone implementations. It >>> often requires following strict coding conventions to avoid mistakes, >>> coding conventions that are completely unnecessary in truly simple >>> languages. Truly simple languages allow the programmer to concentrate >>> purely on the task at hand, without having to pay any attention to such >>> trivial and inconsequential matters as memory management and such. >> >> C++ is much *worse* for memory management than is 'C' - in that >> the possibility of memory leaks goes up. Absent writing GUI code, >> it's entirely possible to write entire deployable systems that use no >> dynamic memory at all in 'C'. indeed, that's been the shop >> standard most places I have worked. > > You can do and some embedded code I've worked on does the same in C++. C > simply can't do RAII, so C++ has a built in advantage when it comes to > memory (or any other resource) management. The ability to automatically > manage resources also removes the last excuse to use goto, but that's > another story! > >>> C isn't that kind of language. In C the "simplicity" forces the >>> programmer to write complex programs that need to constantly be careful >>> about things that should normally be non-issues. >>> >>> This doesn't mean that C++ is a simple language in this regard. >>> However, C++ is a lot *better* in this regard than C. Yes, there are >>> coding conventions that need to be followed eg. because of memory >>> management reasons, but those conventions are simpler and easier to >>> follow, and much of the work is done automatically by the compiler. >> >> Not... really. Let's not confuse our preferences for facts, shall we? > > Just compare code using automatic resource management with code that > does it by hand. Pay particular attention to the clean up code if the > nth allocation in a function fails.... ...and other alternate/exceptional execution flows.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-21 02:11 -0500 |
| Message-ID | <k6077s$83o$1@dont-email.me> |
| In reply to | #27423 |
Ian Collins wrote: > On 10/21/12 07:44, Les Cargill wrote: >> Juha Nieminen wrote: >> >>> However, in the case of C the "simplicity" is not actually a factor >>> that helps writing simple programs. On the contrary, the "simplicity" >>> of the language is actually a limiting factor. Rather than help, it >>> impedes the writing of simple programs, requiring many of even the >>> simplest tasks to have complex and error-prone implementations. It >>> often requires following strict coding conventions to avoid mistakes, >>> coding conventions that are completely unnecessary in truly simple >>> languages. Truly simple languages allow the programmer to concentrate >>> purely on the task at hand, without having to pay any attention to such >>> trivial and inconsequential matters as memory management and such. >> >> C++ is much *worse* for memory management than is 'C' - in that >> the possibility of memory leaks goes up. Absent writing GUI code, >> it's entirely possible to write entire deployable systems that use no >> dynamic memory at all in 'C'. indeed, that's been the shop >> standard most places I have worked. > > You can do and some embedded code I've worked on does the same in C++. C > simply can't do RAII, Not in the specific manner Stoustrup used it, but it's perfectly easy to achieve the same goal. But RAII is much less a concern when you don't have exceptions... although I have seen people do things with setjmp()/longjmp() that were very very clever - including hooking hardware exceptions and hitting longjmp() with it. > so C++ has a built in advantage when it comes to > memory (or any other resource) management. The ability to automatically > manage resources also removes the last excuse to use goto, but that's > another story! > >>> C isn't that kind of language. In C the "simplicity" forces the >>> programmer to write complex programs that need to constantly be careful >>> about things that should normally be non-issues. >>> >>> This doesn't mean that C++ is a simple language in this regard. >>> However, C++ is a lot *better* in this regard than C. Yes, there are >>> coding conventions that need to be followed eg. because of memory >>> management reasons, but those conventions are simpler and easier to >>> follow, and much of the work is done automatically by the compiler. >> >> Not... really. Let's not confuse our preferences for facts, shall we? > > Just compare code using automatic resource management with code that > does it by hand. Pay particular attention to the clean up code if the > nth allocation in a function fails.... > Sorry, this really doesn't apply to any cases I've seen in a long time that were not GUI programs - and I believe I stipulated to "use something besides C++ for GUIs, please" upthread. 'Course, I'm the sort who would use a state machine to manage an overly onerous memory allocation problem - and in C++ - so... -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-21 20:28 +1300 |
| Message-ID | <aehmgmFqjpsU4@mid.individual.net> |
| In reply to | #27443 |
On 10/21/12 20:11, Les Cargill wrote: > Ian Collins wrote: >> On 10/21/12 07:44, Les Cargill wrote: >>> Juha Nieminen wrote: >>> >>>> However, in the case of C the "simplicity" is not actually a factor >>>> that helps writing simple programs. On the contrary, the "simplicity" >>>> of the language is actually a limiting factor. Rather than help, it >>>> impedes the writing of simple programs, requiring many of even the >>>> simplest tasks to have complex and error-prone implementations. It >>>> often requires following strict coding conventions to avoid mistakes, >>>> coding conventions that are completely unnecessary in truly simple >>>> languages. Truly simple languages allow the programmer to concentrate >>>> purely on the task at hand, without having to pay any attention to such >>>> trivial and inconsequential matters as memory management and such. >>> >>> C++ is much *worse* for memory management than is 'C' - in that >>> the possibility of memory leaks goes up. Absent writing GUI code, >>> it's entirely possible to write entire deployable systems that use no >>> dynamic memory at all in 'C'. indeed, that's been the shop >>> standard most places I have worked. >> >> You can do and some embedded code I've worked on does the same in C++. C >> simply can't do RAII, > > Not in the specific manner Stoustrup used it, but it's > perfectly easy to achieve the same goal. I'm sorry, but it isn't. RAII is one C++ feature that C can't do. > But RAII is > much less a concern when you don't have exceptions... Not at all. It can be used anywhere a resource has to be managed. It avoids the goto spaghetti often seen in C code to handle an allocation failure in a block of allocations. >> so C++ has a built in advantage when it comes to >> memory (or any other resource) management. The ability to automatically >> manage resources also removes the last excuse to use goto, but that's >> another story! >> >>>> C isn't that kind of language. In C the "simplicity" forces the >>>> programmer to write complex programs that need to constantly be careful >>>> about things that should normally be non-issues. >>>> >>>> This doesn't mean that C++ is a simple language in this regard. >>>> However, C++ is a lot *better* in this regard than C. Yes, there are >>>> coding conventions that need to be followed eg. because of memory >>>> management reasons, but those conventions are simpler and easier to >>>> follow, and much of the work is done automatically by the compiler. >>> >>> Not... really. Let's not confuse our preferences for facts, shall we? >> >> Just compare code using automatic resource management with code that >> does it by hand. Pay particular attention to the clean up code if the >> nth allocation in a function fails.... >> > > Sorry, this really doesn't apply to any cases I've seen in a long > time that were not GUI programs You obviously haven't looked at kernel and library code! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-21 07:40 +0000 |
| Message-ID | <k608t3$l9t$1@speranza.aioe.org> |
| In reply to | #27449 |
In comp.lang.c++ Ian Collins <ian-news@hotmail.com> wrote: >> But RAII is >> much less a concern when you don't have exceptions... > > Not at all. It can be used anywhere a resource has to be managed. It > avoids the goto spaghetti often seen in C code to handle an allocation > failure in a block of allocations. I have seen the exception-safety argument (ie. "RAII is mostly useful to make code exception-safe, but without support for exceptions they are not all that useful") quite many times, and I have always wondered where it comes from. RAII is most certainly very useful even if you didn't have exceptions. It makes code much safer and simpler at the same time. The more complicated the interactions between different modules and data containers, the more that stuff is passed around, the more useful RAII becomes in order to keep the program simple and safe.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-21 13:31 -0500 |
| Message-ID | <k61f2k$8jg$1@dont-email.me> |
| In reply to | #27449 |
Ian Collins wrote: > On 10/21/12 20:11, Les Cargill wrote: >> Ian Collins wrote: >>> On 10/21/12 07:44, Les Cargill wrote: >>>> Juha Nieminen wrote: >>>> >>>>> However, in the case of C the "simplicity" is not actually a factor >>>>> that helps writing simple programs. On the contrary, the "simplicity" >>>>> of the language is actually a limiting factor. Rather than help, it >>>>> impedes the writing of simple programs, requiring many of even the >>>>> simplest tasks to have complex and error-prone implementations. It >>>>> often requires following strict coding conventions to avoid mistakes, >>>>> coding conventions that are completely unnecessary in truly simple >>>>> languages. Truly simple languages allow the programmer to concentrate >>>>> purely on the task at hand, without having to pay any attention to >>>>> such >>>>> trivial and inconsequential matters as memory management and such. >>>> >>>> C++ is much *worse* for memory management than is 'C' - in that >>>> the possibility of memory leaks goes up. Absent writing GUI code, >>>> it's entirely possible to write entire deployable systems that use no >>>> dynamic memory at all in 'C'. indeed, that's been the shop >>>> standard most places I have worked. >>> >>> You can do and some embedded code I've worked on does the same in C++. C >>> simply can't do RAII, >> >> Not in the specific manner Stoustrup used it, but it's >> perfectly easy to achieve the same goal. > > I'm sorry, but it isn't. RAII is one C++ feature that C can't do. > I respectfully submit that you haven't thought that though. I won't bore you with the sea stories... but it's been done... What Stoustroup provided was an artifact that created a culture that tried to solve these problems. He did a great job. >> But RAII is >> much less a concern when you don't have exceptions... > > Not at all. Ah! You're avoiding my carefully chosen weasel - "much less than". :) > It can be used anywhere a resource has to be managed. It > avoids the goto spaghetti often seen in C code to handle an allocation > failure in a block of allocations. > People were successfully avoiding that spaghetti decades ago with much less powerful tools. So write a state machine, with one allocation per state and do *absolutely nothing else* until it terminates. It's the software equivalent of "get the money up front." If you have additional allocations later, just add states. Push successful states on a stack, and unwind on failure. Bada boom, bada bing. for extra credit, have the allocation requester extend the state machine in an abstract way. Use the __FILE__ and __LINE__ macros also in this stack, and write a dump routine. Presto! Asymptotically full memory leak disclosure. And then, to be a total creep, use a 'C' macro to substitute your scheme for malloc()/free().... I'd allocate the stack thingy very, very statically.... "But I don't want to write a state machine!" Well, you're not all that concerned about managing complexity then, are you? :) And I want a pony, too. I mean absolutely no offense, but comments like yours sound like learned helplessness to me. Break those chains! Take control of your destiny! Power to the proletariat! Strike that last one. But really, the project I first did that on was out of control and this helped stabilize things *immensely*. Operation without instrumentation is like using a credit card without reading the billing statements. >>> so C++ has a built in advantage when it comes to >>> memory (or any other resource) management. The ability to automatically >>> manage resources also removes the last excuse to use goto, but that's >>> another story! >>> >>>>> C isn't that kind of language. In C the "simplicity" forces the >>>>> programmer to write complex programs that need to constantly be >>>>> careful >>>>> about things that should normally be non-issues. >>>>> >>>>> This doesn't mean that C++ is a simple language in this regard. >>>>> However, C++ is a lot *better* in this regard than C. Yes, there are >>>>> coding conventions that need to be followed eg. because of memory >>>>> management reasons, but those conventions are simpler and easier to >>>>> follow, and much of the work is done automatically by the compiler. >>>> >>>> Not... really. Let's not confuse our preferences for facts, shall we? >>> >>> Just compare code using automatic resource management with code that >>> does it by hand. Pay particular attention to the clean up code if the >>> nth allocation in a function fails.... >>> >> >> Sorry, this really doesn't apply to any cases I've seen in a long >> time that were not GUI programs > > You obviously haven't looked at kernel and library code! > Heh. The One True Kernel, and Linus is its prophet? :) Oh, I have. it's *a* way. May you never hear the words "We want you to write a patch against the bridge code..." :) It's good code, but very branchey - you end up following lots of chains. *Generally*, that sort of activity is unnecessary. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-22 08:41 +1300 |
| Message-ID | <aej1ffFqjpsU7@mid.individual.net> |
| In reply to | #27468 |
On 10/22/12 07:31, Les Cargill wrote: > Ian Collins wrote: >> On 10/21/12 20:11, Les Cargill wrote: >>> Ian Collins wrote: >>>> >>>> C simply can't do RAII, >>> >>> Not in the specific manner Stoustrup used it, but it's >>> perfectly easy to achieve the same goal. >> >> I'm sorry, but it isn't. RAII is one C++ feature that C can't do. >> > > I respectfully submit that you haven't thought > that though. I won't bore you with the sea stories... > but it's been done... I certainly have thought it through. Please provide an example of RAII in C. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-21 16:24 -0500 |
| Message-ID | <k61p7m$7bn$1@dont-email.me> |
| In reply to | #27472 |
Ian Collins wrote: > On 10/22/12 07:31, Les Cargill wrote: >> Ian Collins wrote: >>> On 10/21/12 20:11, Les Cargill wrote: >>>> Ian Collins wrote: >>>>> >>>>> C simply can't do RAII, >>>> >>>> Not in the specific manner Stoustrup used it, but it's >>>> perfectly easy to achieve the same goal. >>> >>> I'm sorry, but it isn't. RAII is one C++ feature that C can't do. >>> >> >> I respectfully submit that you haven't thought >> that though. I won't bore you with the sea stories... >> but it's been done... > > I certainly have thought it through. Please provide an example of RAII > in C. > So we're talking RAII as modulo exceptions - unless longjmp() is alos an exception... So you *haven't* thought about it, then? It's not exactly rocket surgery. I am just enumerating my assumptions in responding to your post, not *accusing* you of anything. Essentially replace malloc()/free() with something that tracks allocation and provides instrumentation about the state of the heap. This is much simpler than it sounds... Given all the rash about it, I am surprised 'C' doesn't offer this natively, and that there were never commercial products of the same stripe. There's this: http://www.duckware.com/bugfreec/chapter5.html Very slanted towards some variant of Windows style, but it should give you the general idea. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-22 07:52 +0000 |
| Message-ID | <k62tv6$kjt$1@speranza.aioe.org> |
| In reply to | #27474 |
In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: > Essentially replace malloc()/free() with something that tracks > allocation and provides instrumentation about the state of the heap. > This is much simpler than it sounds... You are confusing RAII with gargabe collection. RAII is not the same thing as GC, and RAII is useful for a lot of other things besides memory management. Besides, what you are talking about above is *not* something that the standard C programming language offers, so you can hardly argue that C offers RAII.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-22 14:02 -0500 |
| Message-ID | <k6458k$14t$1@dont-email.me> |
| In reply to | #27485 |
Juha Nieminen wrote: > In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >> Essentially replace malloc()/free() with something that tracks >> allocation and provides instrumentation about the state of the heap. >> This is much simpler than it sounds... > > You are confusing RAII with gargabe collection. > It's not actually garbage collection, either... > RAII is not the same thing as GC, and RAII is useful for a lot of other > things besides memory management. > > Besides, what you are talking about above is *not* something that the > standard C programming language offers, so you can hardly argue that C > offers RAII. > Fair enough; I'm not sure what you were driving at then. It's fully possible for 'C' programs to leave no widowed resources, memory or otherwise. It's not even that difficult. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web