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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-21 07:08 +0000 |
| Message-ID | <k6071e$hb0$2@speranza.aioe.org> |
| In reply to | #27419 |
In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >> 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". And I have noticed that often when someone doesn't have any *actual* good arguments, they instead go meta, criticizing someone for the concepts or terminology they are using, rather than their actual arguments. > C++ is much *worse* for memory management than is 'C' Ok, you lost all credibility. I don't think it's necessary to go further.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-21 02:51 -0500 |
| Message-ID | <k609ik$hs2$1@dont-email.me> |
| In reply to | #27442 |
Juha Nieminen wrote: > In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >>> 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". > > And I have noticed that often when someone doesn't have any *actual* > good arguments, they instead go meta, criticizing someone for the > concepts or terminology they are using, rather than their actual > arguments. > Yeah, that was a bit snarkier than it perhaps should have been. I don't think the invocation of category errors in this sort of discussion is likely to be productive. Different languages live in semi-orthogonal domains, so there tends not to be a lot of synergy. Good language systems allow for interfacing to other language systems with a minimum of fuss. >> C++ is much *worse* for memory management than is 'C' > > Ok, you lost all credibility. I don't think it's necessary to go further. > I've built significant, non-embedded, production systems using only 'C' that used no dynamic allocation at all. It doesn't get any less worse than that. It wasn't difficult. You can do that in C++ too, but it's a lot less ... sensible. It is possible that there is a bias error I missed, but memory leaks were much less a problem when the state of the art was 'C', at least within the things I saw. As a *cultural* artifact, C++ made things worse for a while. This being said, newer languages are beginning to improve on that significantly. it well could be that 'C' simply kept otherwise sensible people from *doing* programming through barrier to entry. Ironic, since it was shrinkwrap 'C' compilers that helped popularize it... I have never understood why managing memory allocation manually was considered to be so onerous. Perhaps it's a personal failing. And limitation can be extremely important to the general creative process. I suppose my main gripe about C++ is just how much harder it made it to dynamically configure a running system. If all the cardinalities and sizes have to be declared at instantiation of all the objects, you have then to tear them all down and rebuild them when a message to reconfigure comes through. This can be a serious liability. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-21 21:09 +1300 |
| Message-ID | <aehouiFqjpsU5@mid.individual.net> |
| In reply to | #27453 |
On 10/21/12 20:51, Les Cargill wrote: > Juha Nieminen wrote: >> In comp.lang.c++ Les Cargill<lcargill99@comcast.com> wrote: > >>> C++ is much *worse* for memory management than is 'C' >> >> Ok, you lost all credibility. I don't think it's necessary to go further. >> > > I've built significant, non-embedded, production systems using only > 'C' that used no dynamic allocation at all. It doesn't get any less > worse than that. It wasn't difficult. You can do that in C++ too, but > it's a lot less ... sensible. Why? It's not uncommon to have static embedded C++ applications. > I have never understood why managing memory allocation manually was > considered to be so onerous. Perhaps it's a personal failing. And > limitation can be extremely important to the general creative process. It is also the cause of an awful lot of bugs.... > I suppose my main gripe about C++ is just how much harder it made it > to dynamically configure a running system. If all the cardinalities and > sizes have to be declared at instantiation of all the objects, you > have then to tear them all down and rebuild them when a message to > reconfigure comes through. This can be a serious liability. The difference to C here is? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-10-21 12:16 +0100 |
| Message-ID | <k60lhp$i3j$1@speranza.aioe.org> |
| In reply to | #27453 |
Les Cargill wrote: >>> C++ is much *worse* for memory management than is 'C' >> >> Ok, you lost all credibility. I don't think it's necessary to go further. >> > > I've built significant, non-embedded, production systems using only > 'C' that used no dynamic allocation at all. It doesn't get any less > worse than that. It wasn't difficult. You can do that in C++ too, but > it's a lot less ... sensible. Just because you were able to use a language without allocating any memory, it doesn't mean that some other language is suddenly plagued with memory allocation problems. Your argument becomes even sillier when considering that you are referring to a language which is an improper superset of the language you used to pull that stunt, which means that you can also pull that off with the language you tried to criticize. > It is possible that there is a bias error I missed, but memory leaks > were much less a problem when the state of the art was 'C', at > least within the things I saw. Again, that is a silly thing to say. Programmers cause memory leaks, not the language. In addition, with C++'s RAII it is considerably easier to take care of any memory allocation issue, while with C it is necessary to explicitly track every allocation/deallocation to be able to avoid memory leaks. > As a *cultural* artifact, C++ > made things worse for a while. Obviously, it hasn't. You may argue that programmers using the language may have misused it, but blaming the tools while leaving out the workman is a silly thing to do. <snip/> > I suppose my main gripe about C++ is just how much harder it made it > to dynamically configure a running system. You can't blame a language for any hypothetical problem caused by the way a system was designed. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-10-21 11:55 +0100 |
| Message-ID | <k60kb4$fbd$1@speranza.aioe.org> |
| In reply to | #27419 |
Les Cargill wrote: > 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. That assertion is questionable, if not completely nonsense. After all, with C++ it is quite possible to write code without a single explicit call to new/delete, but it won't be simple to write equivalent C code without a single call to malloc/free. And that's without even considering RAII. <snip/> >> 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". You are free to implement any solution which is, to your eye, prettier. The main point is that with C++ you already have a set of standard solutions at your disposal, which were already extensively tested and debugged. <snip/> >> 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. The problem with that assertion is that you are misrepresenting C and C++. While with C you are referring to essentially being exposed to the core language, as C's standard library is pretty limited, with C++ you are including everything plus the kitchen sink. Meanwhile, you failed to take into account that C++ can be presented as an improper superset of C, which means that if you are able to get a newbie to know 95% of everything they need to know about C to be productive in a matter of months, then you can also achieve the exact same thing with C++. Sure, some features won't be covered, but you don't need to use every bell and whistle provided by C++ to actually be productive. > 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++. That is completely irrelevant. Who said you had to use every trick in the book to be able to do anything with C++? It's quite possible to develop software with C++ while completely avoiding any number of features. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2012-10-27 05:30 -0700 |
| Message-ID | <2aa256ed-7b0f-4fd3-9e93-46af59fb678a@k6g2000vbr.googlegroups.com> |
| In reply to | #27419 |
On Oct 20, 7:45 pm, Les Cargill <lcargil...@comcast.com> wrote: > Juha Nieminen wrote: > > In comp.lang.c++ Ian Collins <ian-n...@hotmail.com> wrote: <snip> > 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". "category error" appear to cover what I'd been calling "type error". "you're comparing oranges with orchards!" "C++ is a superset of C because it's implemented in C" > > 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*. no. Not since 1962. Common Lisp is required to be compiled. Stalin an implementation of scheme (which is a Lisp) is one of the most aggressive whole program optimising compilers known. > > 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. use RAII. > 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 this in C++ as well > > 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. really. RAII isn't hard. My problem is large C++ programs written by people who've never heard of it... > 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. I find writing the exception handling stuff in C hard work. And so do other people. Which is why they often don't write it. If I'm using Win32 (yes its old- I know, sue me) I check the return of every function call. Tedious. > > 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. not to this one. Or maybe I'm not experienced enough. > 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++. just learning C's syntax and a few library calls still leaves you with plenty of pifalls to fall into. People do actually manage to write large complex systems in C++. And they work. > > 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++.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-10-20 09:06 -0400 |
| Message-ID | <k5u7jr$ffo$1@dont-email.me> |
| In reply to | #27397 |
On 10/19/2012 07:13 PM, Ian Collins wrote: ... > 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?". I've seen C++ used to create complex solutions to simple problems. My favorite example is use of the Singleton pattern to produce code with precisely the same potential dangers as would occur if a global variable was used, and much greater complexity. Because of course, global variables are "evil", and use of a named "pattern" is "good". Of course, overly complex solutions can also be created in C, and good programmers will produce better solutions, regardless of the language they use. However, I think the larger feature set of C++ does more to encourage this particular type of bad programming than C does. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-21 07:11 +0000 |
| Message-ID | <k6077s$hb0$3@speranza.aioe.org> |
| In reply to | #27412 |
In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote: > I've seen C++ used to create complex solutions to simple problems. And I have seen C++ used to create simple solutions to complex problems. So what? Just because a language *can* be used in a very sub-optimal manner, does that mean the language is bad? C can certainly be used in a horribly sub-optimal manner. Any language can. The argument that there exist incompetent programmers is quite silly.
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-10-21 11:56 +0100 |
| Message-ID | <k60kdd$fbd$3@speranza.aioe.org> |
| In reply to | #27444 |
Juha Nieminen wrote: > And I have seen C++ used to create simple solutions to complex problems. > So what? > > Just because a language *can* be used in a very sub-optimal manner, does > that mean the language is bad? C can certainly be used in a horribly > sub-optimal manner. Any language can. > > The argument that there exist incompetent programmers is quite silly. In addition, in some cases the incompetence lies in the people reading the code and criticizing it for some reason. Design patterns sometimes appear to be needlessly complicated solutions to simple problems because the people reading the code don't understand what the real problems are and therefore are not in a position to understand what represents an adequate solution. More specifically, design patterns tend to be used to write code that may sacrifice the appearance of simplicity with simplicity with regards to other criteria, such as refactoring and extending. Take, for example, the visitor pattern. It may appear completely nonsensical to essentially implement member functions in separate classes. If someone who is clueless looks at an implementation of a visitor pattern then they may criticize it for being a complex solution to a simple problem, because if someone needs to implement a new member function then all a person should do is implement a new member function. Yet, the visitor pattern provides a way to add a new operation to a class without having to modify the class itself, along with a few other significant advantages such as handling these operations as operators. To someone with a C backround, where functions are completely decoupled from objects, this advantage might not be exactly obvious, but just because someone isn't able to understand its purpose it doesn't mean it is needlessly complex; it just means that they faile to see the point. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-10-21 07:43 -0400 |
| Message-ID | <k60n5p$lvb$1@dont-email.me> |
| In reply to | #27444 |
On 10/21/2012 03:11 AM, Juha Nieminen wrote: > In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote: >> I've seen C++ used to create complex solutions to simple problems. > > And I have seen C++ used to create simple solutions to complex problems. > So what? > > Just because a language *can* be used in a very sub-optimal manner, does > that mean the language is bad? C can certainly be used in a horribly > sub-optimal manner. Any language can. > > The argument that there exist incompetent programmers is quite silly. Why? They do exist, and appear to have generated a large fraction of all of the code that gets written. In any event, your summary of my argument dropped the key point - that the greater complexity of C++ provides more temptations for incompetent programmers to generate overly complex code than C does. Of course, that doesn't prevent them from producing bad C code, but the bad C++ code that I've seen has been much more complex to untangle than the bad C code I've fixed. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-22 08:13 +0000 |
| Message-ID | <k62v7b$oav$1@speranza.aioe.org> |
| In reply to | #27464 |
In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote: > In any event, your summary of my argument dropped the key point - that > the greater complexity of C++ provides more temptations for incompetent > programmers to generate overly complex code than C does. My experience makes me disagree with the the last part. I would say that the limiting "simplicity" of C causes many incompetent programmers to create horrible code (much of which is caused *because* C is so archaic.) Many C advocates argue that the "simplicity" of the language somehow induces people to make straightforward, clear, simple and efficient implementations. That's not what I see at all. Instead, what I see quite often is really complicated code with tons of implied coding conventions (that exist solely to address things like memory management issues), and which is quite frankly horribly designed. Just take almost any C project out there and study its source code. You'll easily find 400+ LOC functions (with little to no comments), that use lots of repetition and/or are really obfuscated, oftentimes riddled with gotos, and so on and so forth. They often also suffer from inefficiency because the programmer did a "straightforward" job at implementing the task at hand. I'm not saying that *every* C program out there is like that. I'm saying that quite a significant portion of them are. There's nothing in C that would somehow induce or encourage people to make good code.
[toc] | [prev] | [next] | [standalone]
| From | Steve Thompson <stevet810@gmail.com> |
|---|---|
| Date | 2012-10-22 15:08 +0000 |
| Message-ID | <55nV5E.95v.TjMTe@gmail.com> |
| In reply to | #27486 |
On Mon, Oct 22, 2012 at 08:13:31AM +0000, Juha Nieminen wrote: > In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote: > > In any event, your summary of my argument dropped the key point - that > > the greater complexity of C++ provides more temptations for incompetent > > programmers to generate overly complex code than C does. > > My experience makes me disagree with the the last part. I would say that > the limiting "simplicity" of C causes many incompetent programmers to > create horrible code (much of which is caused *because* C is so archaic.) C maps relatively cleanly to the architecture of the stored program computer, at least for a non-SMP design. The language doesn't try to do a whole lot behind the scenes in making the language primitives work, except in cases where native types are too small for the language types, and then the math has to be simulated with those narrower instructions. In this sense it is conceptually minimalistic. > Many C advocates argue that the "simplicity" of the language somehow > induces people to make straightforward, clear, simple and efficient > implementations. That's not what I see at all. Instead, what I see > quite often is really complicated code with tons of implied coding > conventions (that exist solely to address things like memory management > issues), and which is quite frankly horribly designed. Just take almost > any C project out there and study its source code. You'll easily find > 400+ LOC functions (with little to no comments), that use lots of > repetition and/or are really obfuscated, oftentimes riddled with gotos, I like gotos. They make the recovery from an error conditions much easier to handle. Some of the code I have written would suck utterly if it were translated to a C that lacks the goto construct. I was once caught up in the "GOTO Considered Harmful" theology, and my code suffered accordingly. Judicious use of the statement is entirely reasonable in C. > and so on and so forth. They often also suffer from inefficiency because > the programmer did a "straightforward" job at implementing the task at > hand. Coding is not a science and nor is it a serious engineering discipline for the vast majority of programmers. Most of the time, a programmer of average skill will write something that works well enough for the problem at hand. Adding functionality or capabilities to such code later may be difficult or a practical impossibility, but it may be that the original writer was not given enough time, or expertise was not available in the design phase, to build something extensible. Part of the problem is the tool set. C comes with a standard library that encourages a certain style of coding. If you want an event- driven architecture, a different language is probably going to be a better choice. The language provides tools to make calculations with numbers, control-flow constructs to make decisions based on the value of the numbers, constructs to encourage a modular program design, and an interface to the operating system for input/output, etc. Everything else is up to the programmer. > I'm not saying that *every* C program out there is like that. I'm saying > that quite a significant portion of them are. There's nothing in C that > would somehow induce or encourage people to make good code. It's not the job of the language to "induce" good code. What is "good code" anyhow? Is good code easy to read and understand? Is good code merely correct? Is good code elegant and pretty? At any rate, good is a subjective quality. What may be good to a five-year old will be different from what an adult will consider as good. You seem to be saying that you know what good is when you see it, but I doubt you can define what you mean in terms that everyone will understand. Regards, Steve Thompson -- GOTO's are like guns. Safety is entirely contingent on the user.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-10-22 14:42 -0400 |
| Message-ID | <508593AA.5050501@verizon.net> |
| In reply to | #27486 |
On 10/22/2012 04:13 AM, Juha Nieminen wrote: > In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote: >> In any event, your summary of my argument dropped the key point - that >> the greater complexity of C++ provides more temptations for incompetent >> programmers to generate overly complex code than C does. > > My experience makes me disagree with the the last part. I would say that > the limiting "simplicity" of C causes many incompetent programmers to > create horrible code (much of which is caused *because* C is so archaic. I've seen incompetent C programmers produce horrible code, and I've seen incompetent C++ programmers produce horrible code; except for the comments I've already made about the matter (see below), I haven't notice much difference between the two different types of horribleness. From my previous message: >> Of course, that >> doesn't prevent them from producing bad C code, but the bad C++ code >> that I've seen has been much more complex to untangle than the bad C >> code I've fixed. So our experiences have been quit different. There's not much more useful that can be said about that.
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-10-21 10:12 +0100 |
| Message-ID | <k60e9l$1g0$1@speranza.aioe.org> |
| In reply to | #27412 |
James Kuyper wrote: > I've seen C++ used to create complex solutions to simple problems. My > favorite example is use of the Singleton pattern to produce code with > precisely the same potential dangers as would occur if a global variable > was used, and much greater complexity. Because of course, global > variables are "evil", and use of a named "pattern" is "good". I don't understand what you meant by that. The singleton design pattern and global variables are two entirely different things. It is not uncommon o declare singletons as global objects, and you cannot guarantee that an object type has a single object declared throughout the entire project just by declaring it a global object. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-20 13:24 -0500 |
| Message-ID | <k5uq98$42j$1@dont-email.me> |
| In reply to | #27387 |
Juha Nieminen wrote: > In comp.lang.c++ William Ahern <william@wilbur.25thandclement.com> wrote: >> Reasonable people can disagree about the merits of C viz-a-viz C++. But >> reasonable people cannot disagree that C is still very much in use in all >> the same places that C++ is used, for both new and old code. It's not >> relegated to device drivers and embedded work, by any stretch of the >> imagination. > > It's just that in an environment where both C and C++ are equally > viable options (which is most of the environments where you would > want to use either one), most experienced C++ programmers can't think > of any reason why they should limit themselves to C. Because, to be > frank, that would be quite a serious limitation. > Unless you put some serious time on on non-C++ 'C', you will think rather differently than someone who has. Path dependence is path dependent. > C++ might be big and have tons and tons of features, but once you become > really experienced with it, it just becomes so much *esier* to do things > with it than with C. I really do not know about that. Just the general schism over string types alone makes life much more difficult. The whole subject is fraught with massive observer bias. > Just the standard library alone makes life so much > easier (no matter if you are just making a quick 50-line test program > or a large 50k-line serious project.) > Or you get an old version of STL that's buggy and there's an observed problem that takes up to a *year* ( off and on - not continuous pushing ) to resolve. Which you do by replacing an stl::map() with a bleeding-edge string table in a 'C' fashion :) Also, I once had a ... data structure that I built with a need for associativity ( think arrays indexed by strings ) where it was twice the code* and half the performance to use STL than bash something out in 'C'. Oh, if STL had only had "foreach" from the start.... *no, I am not going to specify how that figure was arrived at... What we do is settle on classes of solutions, and stay there. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-21 07:16 +0000 |
| Message-ID | <k607h2$ika$1@speranza.aioe.org> |
| In reply to | #27417 |
In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >> Just the standard library alone makes life so much >> easier (no matter if you are just making a quick 50-line test program >> or a large 50k-line serious project.) > > Or you get an old version of STL that's buggy and there's an observed > problem that takes up to a *year* ( off and on - not continuous > pushing ) to resolve. When C programmers have to resort to problems that might have been relevant 20 years ago in order to make their case, I think that demonstrates quite well that they don't have any *actual* argument. > Also, I once had a ... data structure that I built with a need > for associativity ( think arrays indexed by strings ) where it > was twice the code* and half the performance to use STL than > bash something out in 'C'. Oh, if STL had only had "foreach" > from the start.... "The standard library cannot be used for this", is a rather weak argument for why the standard library is not useful. The standard library does not offer *everything*. So what? What it does offer is in practice very useful.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2012-10-21 13:57 -0500 |
| Message-ID | <k61gk7$isu$1@dont-email.me> |
| In reply to | #27445 |
Juha Nieminen wrote: > In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >>> Just the standard library alone makes life so much >>> easier (no matter if you are just making a quick 50-line test program >>> or a large 50k-line serious project.) >> >> Or you get an old version of STL that's buggy and there's an observed >> problem that takes up to a *year* ( off and on - not continuous >> pushing ) to resolve. > > When C programmers have to resort to problems that might have been > relevant 20 years ago in order to make their case, I think that > demonstrates quite well that they don't have any *actual* argument. > This was much, much more recent than that. People are *still running* 20 year old STL implementations... "So why don't you upgrade?" My very question. The answer was interesting. >> Also, I once had a ... data structure that I built with a need >> for associativity ( think arrays indexed by strings ) where it >> was twice the code* and half the performance to use STL than >> bash something out in 'C'. Oh, if STL had only had "foreach" >> from the start.... > > "The standard library cannot be used for this", is a rather weak > argument for why the standard library is not useful. It's an explicit demonstration of the *dis*utility of it. Dunno about you, but I don't get to point to that and say "abandon hope", I have to go fix it. > The standard > library does not offer *everything*. So what? What it does offer > is in practice very useful. > It *can* be. What we're arguing about is whether or not language features enable bad practice, and that's not going to be settled in one thread. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-22 08:17 +0000 |
| Message-ID | <k62ve1$oqf$1@speranza.aioe.org> |
| In reply to | #27470 |
In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote: >> When C programmers have to resort to problems that might have been >> relevant 20 years ago in order to make their case, I think that >> demonstrates quite well that they don't have any *actual* argument. > > This was much, much more recent than that. People are > *still running* 20 year old STL implementations... And this affects me how, exactly? Why should *I* care? Why should I choose C over C++ if some people are still running 20 year old STL implementations? >> "The standard library cannot be used for this", is a rather weak >> argument for why the standard library is not useful. > > It's an explicit demonstration of the *dis*utility of it. Dunno > about you, but I don't get to point to that and say "abandon > hope", I have to go fix it. I don't understand that at all. Since the standard library does not offer a solution for every single problem in existence, it's not useful? That's like one of the craziest arguments I have ever heard, even from a C advocate (and that's saying quite a lot; believe me, I have seen quite crazy stuff.)
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> |
|---|---|
| Date | 2012-10-20 22:41 +0200 |
| Message-ID | <1af3ab5d0684b0284d2be6344a542be3@msgid.frell.theremailer.net> |
| In reply to | #27340 |
Juha Nieminen <nospam@thanks.invalid> wrote: most of what you wrote is agreeable, snipped... > Also, C++ does have some features that are not offered by other languages. This is hard to believe. Would you be inclined to name a few? I'm not a C/C++ guy so I'll have to check but I really find it difficult to believe C or C++ could offer anything that isn't offered by other languages for a few reasons: C is not the oldest language, therefore it was based on ideas and languages that came before. C++ is based on C and other ideas and languages that came before. There have been many new languages since C++ and many many new ones since C. Aside from "features" that are really nothing more than quirks or bad design, are you really suggesting a language written 20 years ago based on a language written 20 years or so before that has features other languages don't offer? That would be interesting! Are you being pedantic and suggesting C++ has features that aren't presented exactly the same way in other languages, or are you suggesting C++ really has features that have no equivalents in other languages, or ???
[toc] | [prev] | [next] | [standalone]
| From | Dombo <dombo@disposable.invalid> |
|---|---|
| Date | 2012-10-21 01:04 +0200 |
| Message-ID | <k5vaiu$48n$1@dont-email.me> |
| In reply to | #27428 |
Op 20-Oct-12 22:41, Fritz Wuehler schreef: > Juha Nieminen <nospam@thanks.invalid> wrote: > > most of what you wrote is agreeable, snipped... > >> Also, C++ does have some features that are not offered by other languages. > > This is hard to believe. Would you be inclined to name a few? I'm not a > C/C++ guy so I'll have to check but I really find it difficult to believe C > or C++ could offer anything that isn't offered by other languages for a few > reasons: > > C is not the oldest language, therefore it was based on ideas and languages > that came before. C++ is based on C and other ideas and languages that came > before. There have been many new languages since C++ and many many new ones > since C. Aside from "features" that are really nothing more than quirks or > bad design, are you really suggesting a language written 20 years ago based > on a language written 20 years or so before that has features other > languages don't offer? That would be interesting! > > Are you being pedantic and suggesting C++ has features that aren't presented > exactly the same way in other languages, or are you suggesting C++ really > has features that have no equivalents in other languages, or ??? I don't know every programing language in existence, but as far as know there aren't that many programming languages that support RAII (deterministic destructors) and templates like C++ does. Also C++ has evolved significantly over the last 20 years. The C++ language I learned C++ 20 years ago is very different from C++ as we know it today. 20 years ago C++ was little more than C with classes; no templates, no standard library (or STL), no exceptions...etc. One cannot consider programming language features in isolation; the necessity/added-value of a feature and even if possibility of adding a feature depends on the language as a whole. Reasons that other programming languages do no support a certain features may be due to that it doesn't fit in well with other parts of the language (e.g. deterministic destructors), or that the language designer opted for a much less powerful but simpler alternative (e.g. generics instead of templates), or that the language designer doesn't believe that the feature is a good idea (e.g. operator overloading), or even leave a feature out entirely because other aspects of the language make the feature unnecessary (e.g. a dynamically typed language has little use for templates or generics).
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web