Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #19026 > 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 153 — 30 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" 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" Öö Tiib <ootiib@hot.ee> - 2012-10-19 11:40 -0700
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" Öö Tiib <ootiib@hot.ee> - 2012-10-19 13:52 -0700
Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-19 14:13 -0700
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-19 21:24 +0000
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-20 11:47 +1300
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" Öö Tiib <ootiib@hot.ee> - 2012-10-21 15:05 -0700
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" Öö Tiib <ootiib@hot.ee> - 2012-10-27 05:04 -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" google@ianshome.com - 2012-10-23 12:03 -0700
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" Les Cargill <lcargill99@comcast.com> - 2012-10-21 13:47 -0500
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 08:46 +1300
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-22 03:02 +0100
Re: C/C++ question about dynamic "static struct" Juha Nieminen <nospam@thanks.invalid> - 2012-10-22 08:04 +0000
Re: C/C++ question about dynamic "static struct" Tobias Müller <troplin@bluewin.ch> - 2012-10-21 18:54 +0000
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 08:49 +1300
Re: C/C++ question about dynamic "static struct" Tobias Müller <troplin@bluewin.ch> - 2012-10-21 20:07 +0000
Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-21 13:53 -0700
Re: C/C++ question about dynamic "static struct" Ian Collins <ian-news@hotmail.com> - 2012-10-22 09:54 +1300
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-22 02:41 +0100
Re: C/C++ question about dynamic "static struct" Tobias Müller <troplin@bluewin.ch> - 2012-10-22 06:12 +0000
Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-22 20:52 +0000
Re: C/C++ question about dynamic "static struct" Öö Tiib <ootiib@hot.ee> - 2012-10-22 16:30 -0700
Re: C/C++ question about dynamic "static struct" Stuart <DerTopper@web.de> - 2012-10-23 11:22 +0200
Re: C/C++ question about dynamic "static struct" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-10-23 16:58 +0000
Re: C/C++ question about dynamic "static struct" Rui Maciel <rui.maciel@gmail.com> - 2012-10-22 02:22 +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" Öö Tiib <ootiib@hot.ee> - 2012-10-20 07:43 -0700
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" Öö Tiib <ootiib@hot.ee> - 2012-10-21 10:36 -0700
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" Stuart <DerTopper@web.de> - 2012-10-24 12:01 +0200
Re: C/C++ question about dynamic "static struct" Dombo <dombo@disposable.invalid> - 2012-10-24 20:31 +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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-19 21:34 +1300 |
| Message-ID | <aechkfFnpi1U1@mid.individual.net> |
| In reply to | #19062 |
On 10/19/12 09:52, William Ahern wrote: > In comp.lang.c Stuart<DerTopper@web.de> wrote: >> On 10/18/12 James Kuyper wrote: >> [snip] >>> I'm primarily a C programmer, so I may be >>> missing out some elegant C++ way of doing that, but the following >>> inelegant (and untested) code should do the job: >> [snip] > >> I'm intrigued. I have never ever met someone who described himself as a C >> programmer. May I ask what kind of business you are in? My guess is your >> line of work includes either device drivers, embedded devices, kernel code >> or something else that forces you to write C instead of C++. In all these >> years I have never met someone who used C instead of C++ unless he was >> forced to do so. > > Well, you have now. I've worked in several shops (both small and billion > dollar companies) which were C only by choice. The consensus was that the > cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work. > When you're writing high availability server software, the fewer moving > parts the better. That's one situation where the C++ subset of C + RAII can be an excellent choice. > C++ can be too big. You can certainly cherry pick features, but different > people cherry pick different features. And you also need someone who > understands _all_ the features to go through and grok those used and unused. That is why it is important that choice of features is a team decision. I have assisted a team who's chose to use just RAII and function overloaded and another who jumped in boots and all with boost. Both succeeded and both made the best choice for their projects and skill sets. > Plus, there's linking, interoperability, etc, which is more of a pain. And > C++'s strict typing can lead to code bloat and/or excessive casting. I can't say I've seen either and I'm not sure how that could arise. > There are lots of cool features in C++, but often those features are better > implemented in other languages. It can be easier to use C + [insert other > language], then just C++. So, depending on your perspective, C++'s winning > features can seem middling to someone willing to use more than a single > language. Unless like me you happen to be a driver writer! > I'm guessing that you come from a Windows background and/or graduated > college in the past 3 or 4 years. That's usually how it goes, IME. C++ > didn't make waves in the Unix world until a few years ago, and then it took > off with Google and Apple**, especially when they picked up their college > recruitment. C++ grew up in Microsoft-land and in Microsoft-friendly > universities which dumped SUN--or never had the history to begin with. Which > isn't a slight, just an observation about the peculiarities of C++ culture. It's not my sector, but I know C++ and Motif was very popular in the banking world back in the 90s. Maybe it still is. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Stuart <DerTopper@web.de> |
|---|---|
| Date | 2012-10-19 11:03 +0200 |
| Message-ID | <k5r50b$s5f$1@dont-email.me> |
| In reply to | #19062 |
Stuart wrote in reply to James Kuyper: [snip] >> I'm intrigued. I have never ever met someone who described himself [James >> Kuyper, whom I replied to at that time, not William Ahern] as a C >> programmer. May I ask what kind of business you are in? My guess is your >> line of work includes either device drivers, embedded devices, kernel code >> or something else that forces you to write C instead of C++. In all these >> years I have never met someone who used C instead of C++ unless he was >> forced to do so. Am 10/18/12 William Ahern wrote: > Well, you have now. I've worked in several shops (both small and billion > dollar companies) which were C only by choice. The consensus was that the > cost/benefit of C++ didn't pan out, particularly for backend, non-GUI work. > When you're writing high availability server software, the fewer moving > parts the better. > > C++ can be too big. You can certainly cherry pick features, but different > people cherry pick different features. And you also need someone who > understands _all_ the features to go through and grok those used and unused. In all the shops I have worked so far this choice was always up to me. To put it more correctly, whenever I felt that the established programming techniques became insufficient due to the restricted set of compiler features, I made a presentation that showed how much effort a particaluar, hitherto unused compiler feature can save. And if you use the right words, your boss can almost never disagree with you because any new technique that saves anything must be good! ;-) > Plus, there's linking, interoperability, etc, which is more of a pain. And > C++'s strict typing can lead to code bloat and/or excessive casting. > > There are lots of cool features in C++, but often those features are better > implemented in other languages. Do you mind giving an example? I often find that I have the wish to use another programming language because it has some library that does not exist under C++ (I haven't found platform independent C++ GUI library that satisfies my needs, for example), but that should not be an argument against the programming language itself because one just had to implement a similar library for C++. There should be nothing inherent to GUI programming that makes this problem space incompatible with the C++ programming language, I think, although the qt people think that reflection is a good thing for GUI programming. But that is a story for another day... Scripting can also be a good argument against C++. Although there are efforts to provide C++ scripting environments, this is probably too difficult a task for the open-source community (and the industry does not seem to be bothered with such a thing). I have only ever seen BGB who designed a language called BGBScript that resembles C and can be either compiled and interpreted, but chances are little that his language will become main-stream. > It can be easier to use C + [insert other > language], then just C++. So, depending on your perspective, C++'s winning > features can seem middling to someone willing to use more than a single > language. Interesting point. However, I always considered the additional friction that stems from making two programming languages interoperate too much an effort, so I decided to stick to a programming language that can to "everything". Maybe that is a wrong thing to do (the last company I worked at decided to use C++ for the hardware communication layer and C# for the GUI, but that never really took off). > I'm guessing that you come from a Windows background and/or graduated > college in the past 3 or 4 years. That's usually how it goes, IME. C++ > didn't make waves in the Unix world until a few years ago, That always struck me as odd. After all, C++ was not invented by some large company that wants to dictate what people should want (as it feels when I use C# or Java) but by a single guy whom you can chat with in a newsgroup. Almost grassroots, as one could say. > and then it took > off with Google and Apple**, especially when they picked up their college > recruitment. C++ grew up in Microsoft-land and in Microsoft-friendly > universities which dumped SUN--or never had the history to begin with. Which > isn't a slight, just an observation about the peculiarities of C++ culture. Windows background, true, but not due to university. My hometown university only offers a undergraduate course that is more or less a introductory course for languages like Ada, C++ and Java. So one should not be surprised to meet postdocs in computer science that don I started to code in C++ ten years ago when I worked during semester break at Fraunhofer institute. They used Borland's C++ compiler (* sniff, remembering the good old times *). I had a look at some book that showed how to write Win32 GUI apps with C and I found it awful. All those gigantic switch statements, brrr ... Admittedly, there may be some wrapper libraries for Win32 API that were written in C, but I couldn't find a suitable one. Apparently C programmers were supposed to use the Win32 API directly, I guess. Regards, Stuart
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-10-20 14:03 +0100 |
| Message-ID | <k5u7fm$em4$1@dont-email.me> |
| In reply to | #19068 |
"Stuart" <DerTopper@web.de> wrote in message news:k5r50b$s5f$1@dont-email.me... > Scripting can also be a good argument against C++. Although there are > efforts to provide C++ scripting environments, this is probably too > difficult a task for the open-source community (and the industry does not > seem to be bothered with such a thing). I have only ever seen BGB who > designed a language called BGBScript that resembles C and can be either > compiled and interpreted, but chances are little that his language will > become main-stream. There's a language called C++Script (http://calumgrant.net/cppscript/index.html#). According to the docs, you can use this to write dynamically-typed scripting programs very easily, and yet the result will compile under C++. (That C++ makes this possible ought to be impressive; but to me it shows that C++ is too much about language-building features, rather than programming.) The BGBScript project I believe was supposed to be a version of ECMA/Javascript; I guess you could call these 'mainstream'. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-19 09:27 +0000 |
| Message-ID | <k5r6da$at5$1@speranza.aioe.org> |
| In reply to | #19062 |
In comp.lang.c++ William Ahern <william@wilbur.25thandclement.com> wrote: > There are lots of cool features in C++, but often those features are better > implemented in other languages. That sounds to me like the typical discussion where someone is trying to define what makes humans different from animals, and each time he says "humans can do this" someone argues "well, (some obscure species) can do that too!" Most of the "better" languages also have drawbacks. The drawbacks might not always be related to the language itself (although in many cases there are those too), but about the environment. For example, C# is in principle better than C++ in many aspects, but trying to use it is quite limiting because, in practice, you will be restricting yourself to programming for Windows (or the Xbox 360.) (Yes, I know that there exist C# implementations for other platforms too, but they just tend to be way more limited then Microsoft's C#, and a typical C# program written for Windows will likely not compile for those other platforms because there's so much Windows-specific stuff in a typical C# program. Also, there's the issue that C# programs are about 3 times slower than equivalent C++ programs...) Java excels at portability, and gives a good challenge to C and C++ in the programming language shootout (and in fact beats C and C++ 100-0 in situations where one just must allocate millions of tiny objects dynamically and there's no way around it). However, on a more average level it tends to be slower, more resource-consuming, and always requires a runtime environment (which makes it unsuitable for some applications). It also has some annoyances at the language level. Also, C++ does have some features that are not offered by other languages. They might offer something that resembles it in a limited manner, but is not quite as useful. For example, garbage collection is often touted as a better replacement for RAII, but people who say this do not understand that RAII is useful for much more than just memory management. Some even claim that "generics" (they cannot be called "templates" because that's a curseword) are better than C++ templates, while not seeing how much more powerful templates are to "generics". The vast majority of languages out there do not support value-based objects; while this is not always useful, in many situations it certainly is, as it allows for very significant speed and memory usage optimizations (which is one of the reasons why C++ tends to be so fast compared to those, when competently used.) > It can be easier to use C + [insert other > language], then just C++. Ironically, your typo there actually makes the sentence better. ;)
[toc] | [prev] | [next] | [standalone]
| From | Stuart <DerTopper@web.de> |
|---|---|
| Date | 2012-10-19 13:43 +0200 |
| Message-ID | <k5recc$f0i$1@dont-email.me> |
| In reply to | #19069 |
William Ahern wrote: >> There are lots of cool features in C++, but often those features are better >> implemented in other languages. On 10/19/12 Juha Nieminen wrote: > That sounds to me like the typical discussion where someone is trying to > define what makes humans different from animals, and each time he says > "humans can do this" someone argues "well, (some obscure species) can do > that too!" I rather thought that -- for a change -- we had a rather different discussion, e.g. why some people prefer C over C++ (William original stated that he considered himself rather a C programmer than a C++ programmer). That caught my interest because I always thought that hardly anyone used C instead of C++ (unless outer circumstances dictated that C must be used). In my eyes this looks as if someone bought a Audi TT and contented himself never to drive faster than 80kmh/50mph (case in point: my professor :-) [snip] > Java excels at portability, and gives a good challenge to C and C++ in > the programming language shootout (and in fact beats C and C++ 100-0 > in situations where one just must allocate millions of tiny objects > dynamically and there's no way around it). You mean Java beats C++'s standard allocator, don't you? SCNR, but I don't want to start another flame war (this has already gone to far IMHO). >> It can be easier to use C + [insert other >> language], then just C++. > > Ironically, your typo there actually makes the sentence better. ;) Didn't caught it until you pointed it out. Nice one. Doesn't mean that I agree, though, since I hear from more and more people that they use a multitude of programming languages in a single project. Makes me feel like a relict. Regards, Stuart
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-19 12:46 +0000 |
| Message-ID | <k5ri2t$87d$1@speranza.aioe.org> |
| In reply to | #19081 |
In comp.lang.c++ Stuart <DerTopper@web.de> wrote: > That caught my interest because I always thought that > hardly anyone used C instead of C++ (unless outer circumstances dictated > that C must be used). Many people use C, some for good reasons, others out of stubborness even though they do know the limitations of C and advantages of other languages (whether they actually *acknowledge* it or not is another story), and yet others use it for completely misinformed reasons. >> Java excels at portability, and gives a good challenge to C and C++ in >> the programming language shootout (and in fact beats C and C++ 100-0 >> in situations where one just must allocate millions of tiny objects >> dynamically and there's no way around it). > > You mean Java beats C++'s standard allocator, don't you? SCNR, but I > don't want to start another flame war (this has already gone to far IMHO). The C/C++ standard allocator tends to have horrendous efficiency (not helped by the fact that it's basically impossible to make it a compacting allocator, which is perfectly possible in a JVM.) In order to get good allocation speed in C/C++ you have to resort to other means, bypassing the system allocator (ie. bypassing it for individual allocations; of course you still allocate big chunks at a time from it). Even then, it's still difficult to match the allocation speed of a good JVM (which can perform some types of cache optimizations that are very difficult, if not impossible, to do in a C/C++ program.) Luckily, it's relatively rare to need to allocate millions of individual small objects in C++ (because objects can be handled by value.)
[toc] | [prev] | [next] | [standalone]
| From | ImpalerCore <jadill33@gmail.com> |
|---|---|
| Date | 2012-10-19 10:14 -0700 |
| Message-ID | <b4c60861-a90b-4dfd-99d1-acfa5812ab82@o8g2000yqh.googlegroups.com> |
| In reply to | #19085 |
On Oct 19, 8:46 am, Juha Nieminen <nos...@thanks.invalid> wrote: > In comp.lang.c++ Stuart <DerTop...@web.de> wrote: > > > That caught my interest because I always thought that > > hardly anyone used C instead of C++ (unless outer circumstances dictated > > that C must be used). > > Many people use C, some for good reasons, others out of stubborness even > though they do know the limitations of C and advantages of other languages > (whether they actually *acknowledge* it or not is another story), and yet > others use it for completely misinformed reasons. > > >> Java excels at portability, and gives a good challenge to C and C++ in > >> the programming language shootout (and in fact beats C and C++ 100-0 > >> in situations where one just must allocate millions of tiny objects > >> dynamically and there's no way around it). > > > You mean Java beats C++'s standard allocator, don't you? SCNR, but I > > don't want to start another flame war (this has already gone to far IMHO). > > The C/C++ standard allocator tends to have horrendous efficiency (not > helped by the fact that it's basically impossible to make it a compacting > allocator, which is perfectly possible in a JVM.) > > In order to get good allocation speed in C/C++ you have to resort to other > means, bypassing the system allocator (ie. bypassing it for individual > allocations; of course you still allocate big chunks at a time from it). > Even then, it's still difficult to match the allocation speed of a good > JVM (which can perform some types of cache optimizations that are very > difficult, if not impossible, to do in a C/C++ program.) > > Luckily, it's relatively rare to need to allocate millions of individual > small objects in C++ (because objects can be handled by value.) It's still possible to layer a slab allocator on top of the general purpose allocator in C optimized for small objects. It's not trivial to implement, but you can make an allocator tuned to allocate pages that are sliced up into fixed sized blocks, and then write a wrapper over that to handle slabs of aligned block sizes as a kind of "small object" allocator. But it's definitely not readily available from the C standard library. In the use case of a linked list, the ability to allocate a list's nodes from a fixed-block slab can greatly improve its allocation speed and its cache consistency (useful for improving it's performance when traveling the list) over the general purpose allocator, which throws everything and the kitchen sink into the same blob memory (which will really hurt cache consistency). If the list objects are of fixed size, like a linked list of integers, one can have a slab allocator for the list nodes, and a slab allocator for the 'int' objects, and you'll reap the same benefits (with the bonus of blasting that memory away at the slab level when done with the linked list). Of course this increases the programmer's complexity over just using the standard allocator, but it's certainly possible. Best regards, John D.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2012-10-19 14:53 -0500 |
| Message-ID | <XnsA0F1E8F23D9ACmyfirstnameosapriee@216.196.109.131> |
| In reply to | #19085 |
Juha Nieminen <nospam@thanks.invalid> wrote in news:k5ri2t$87d$1@speranza.aioe.org: > > The C/C++ standard allocator tends to have horrendous efficiency (not > helped by the fact that it's basically impossible to make it a > compacting allocator, which is perfectly possible in a JVM.) Now I'm curious. Is there any fundamental reason why "C/C++ standard allocator tends to have horrendous efficiency" (leaving aside the compacting bit)? I'm sure people have put a lot of wisdom and work into standard allocators, why would my custom allocator on top of the standard one behave better? Cheers Paavo
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-10-19 13:52 -0700 |
| Message-ID | <02f11126-3697-46db-ba7e-bcf63667bb52@googlegroups.com> |
| In reply to | #19102 |
On Friday, 19 October 2012 22:53:59 UTC+3, Paavo Helde wrote: > Juha Nieminen <nospam@thanks.invalid> wrote in > news:k5ri2t$87d$1@speranza.aioe.org: > > > > The C/C++ standard allocator tends to have horrendous efficiency (not > > helped by the fact that it's basically impossible to make it a > > compacting allocator, which is perfectly possible in a JVM.) > > Now I'm curious. Is there any fundamental reason why "C/C++ standard > allocator tends to have horrendous efficiency" (leaving aside the > compacting bit)? I'm sure people have put a lot of wisdom and work into > standard allocators, why would my custom allocator on top of the standard > one behave better? I can give some statistics that may variate from OS and compiler and hardware but rough about average desktop computer: * allocating million of little objects takes about half a second. * destroying million of little objects takes about 5 seconds. * allocating little object takes at least 32 bytes of memory. So it is clearly bad idea to allocate lot of < 32 byte objects separately. Better is to pool them somehow and/or to use intrusive containers, intrusive reference counting and/or to pass < 32 byte objects by value. I think that Juha has had bad experience with that above. On the flip-side he probably has no experience how Java's garbage collector also hangs an application for 15 minutes with 6GB of application's memory used. So allocating lot of little crap is harmful for both languages, just that C++ has more and better ways how to climb out of the hole.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2012-10-19 14:13 -0700 |
| Message-ID | <a4605ae4-a24d-48e0-bbb5-6db313960f47@googlegroups.com> |
| In reply to | #19104 |
On Friday, 19 October 2012 23:52:19 UTC+3, Öö Tiib wrote: > On the flip-side he probably has no experience how Java's garbage collector > also hangs an application for 15 minutes with 6GB of application's memory > used. To clarify: I see that what I wrote might leave impression that one collection takes so long. No. Not GC alone, but an algorithm that does lots of little allocations. The profiling shows that majority of the effort goes to GC. Getting rid of dynamic allocations would give order of magnitude speedup. That is very difficult to achieve with Java where idiomatic code has 'new' every third line.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-19 21:24 +0000 |
| Message-ID | <k5sgf2$md2$2@speranza.aioe.org> |
| In reply to | #19104 |
Öö Tiib <ootiib@hot.ee> wrote: > I think that Juha has had bad experience with that above. On the > flip-side he probably has no experience how Java's garbage collector > also hangs an application for 15 minutes with 6GB of application's > memory used. So allocating lot of little crap is harmful for both > languages, just that C++ has more and better ways how to climb out > of the hole. I'm not saying there aren't situations in Java when the GC engine becomes a real resource hog, but in typical-sized programs handling typical amounts of data it's not very usual, AFAIK. I suppose that both in Java and C++ you need to know how to optimize your memory usage if you want maximum efficiency.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-20 11:47 +1300 |
| Message-ID | <aee3klFnpi3U2@mid.individual.net> |
| In reply to | #19107 |
On 10/20/12 10:24, Juha Nieminen wrote: > Öö Tiib<ootiib@hot.ee> wrote: >> I think that Juha has had bad experience with that above. On the >> flip-side he probably has no experience how Java's garbage collector >> also hangs an application for 15 minutes with 6GB of application's >> memory used. So allocating lot of little crap is harmful for both >> languages, just that C++ has more and better ways how to climb out >> of the hole. > > I'm not saying there aren't situations in Java when the GC engine > becomes a real resource hog, but in typical-sized programs handling > typical amounts of data it's not very usual, AFAIK. The same could be said for C++ and the standard allocator. In both languages it is extreme cases that cause problems. I guess with it's greater flexibility, C++ offers more opportunities for optimisation. > I suppose that both in Java and C++ you need to know how to optimize > your memory usage if you want maximum efficiency. Indeed. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-19 21:22 +0000 |
| Message-ID | <k5sgah$md2$1@speranza.aioe.org> |
| In reply to | #19102 |
In comp.lang.c++ Paavo Helde <myfirstname@osa.pri.ee> wrote: > Now I'm curious. Is there any fundamental reason why "C/C++ standard > allocator tends to have horrendous efficiency" (leaving aside the > compacting bit)? I'm sure people have put a lot of wisdom and work into > standard allocators, why would my custom allocator on top of the standard > one behave better? According to my tests, the two major reasons for the slowness are cache inefficiency and thread-safety. Especially in situations where little random-sized blocks of memory are constantly being allocated and deallocated pretty at random (at least from the allocator's point of view, which obviously doesn't see any logic, just the allocation requests), the memory gets more and more fragmented, and the list of free blocks gets more and more randomized. This means that after a little while most memory blocks will be located at wildly random locations, causing lots of cache misses (both when allocated and deallocated, and also when accesses from the program). This is where memory compaction could help a lot. Even if the compaction takes some resources, the end result is that after the process subsequent allocations will be enormously faster (because they are much more cache friendly.) The overall speed of the program could see significant increases (depending a lot on the program, of course.) Cache optimality is not something to be dismissed lightly. Even inside your own code you can achieve enormous speedups by organizing the memory usage such that it becomes more cache-efficient (by increasing cache locality.) A program can become several times faster just because of this. The other reason is that the C standard allocator (also used by C++) is thread-safe: It's ready as-is to be used in multithreaded programs. This inevitably causes overhead (which would be unneeded especially in a single-threaded program.) While according to my experiments it has got a lot better (perhaps because of development, or because of better hardware, or possibly a combination of both), it still causes a quite measurable slowdown. I don't know exactly how a JVM memory allocator solves both problems, but seemingly they tend to be pretty good at it (helped by the fact that Java's semantics allows for things like memory compaction.)
[toc] | [prev] | [next] | [standalone]
| From | William Ahern <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2012-10-19 11:21 -0700 |
| Message-ID | <e9i8l9-t0k.ln1@wilbur.25thandClement.com> |
| In reply to | #19069 |
In comp.lang.c++ Juha Nieminen <nospam@thanks.invalid> wrote: > In comp.lang.c++ William Ahern <william@wilbur.25thandclement.com> wrote: > > There are lots of cool features in C++, but often those features are > > better implemented in other languages. > That sounds to me like the typical discussion where someone is trying to > define what makes humans different from animals, and each time he says > "humans can do this" someone argues "well, (some obscure species) can do > that too!" It's all pointless. It's just annoying when C++ programmers become incredulous that there are still C dinosaurs walking the earth. It's like PHP programmers disbelieving that there are still Perl programmers. 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.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-19 21:29 +0000 |
| Message-ID | <k5sgnj$n8t$1@speranza.aioe.org> |
| In reply to | #19099 |
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. 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. 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.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-10-19 18:53 -0400 |
| Message-ID | <5081D9DA.6020103@verizon.net> |
| In reply to | #19108 |
On 10/19/2012 05:29 PM, Juha Nieminen wrote: ... > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-10-20 12:13 +1300 |
| Message-ID | <aee54mFnpi3U5@mid.individual.net> |
| In reply to | #19110 |
On 10/20/12 11:53, James Kuyper wrote: > On 10/19/2012 05:29 PM, Juha Nieminen wrote: > .... >> 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. > > 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?". -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2012-10-20 05:55 +0000 |
| Message-ID | <k5tedc$dpd$1@speranza.aioe.org> |
| In reply to | #19111 |
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. 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.) 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 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. 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. 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. 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. 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 | Stuart <DerTopper@web.de> |
|---|---|
| Date | 2012-10-20 13:24 +0200 |
| Message-ID | <k5u1lf$fb2$1@dont-email.me> |
| In reply to | #19115 |
On 10/19/12 James Kuyper 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. Umm, my question (which started this whole sub-thread) was not meant to critisize C programmers. I rather think that every C programmer is already a C++ programmer in disguise, since (mostly) all he has to do is to rename the source file from .c to .cpp/.cc/.mm. He can't do that if the project at hand forbids this. I was more or less interested whether C programmers deliberately chose C over C++ or whether they had no other choice. [snip] On 10/20/12 Juha Nieminen wrote: > 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. 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.) > > 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 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. > 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. > > 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. 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. 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++. Nicely put, almost textbook. There is another argument that could convince me to use C instead of C++: If the simplicity of the language C allowed it to be both compiled as well as interpreted, then I would favour C (AFAIK, Java's syntax was deliberately kept "simple" so that code can be added at run-time, something that would be real nightmare under C++). However, there is no such C interpreter (at least I don't know one). Just a side note: Apparently Apple thinks that C++ is so much more complicated than C that their Xcode IDE refuses to refactor ObjectiveC++ code whereas it accepts ObjectiveC code just fine. Strange, but true. Regards, Stuart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-10-20 12:54 +0100 |
| Message-ID | <0.0f5489a18d5c2e430316.20121020125445BST.871ugt1hq2.fsf@bsb.me.uk> |
| In reply to | #19120 |
Stuart <DerTopper@web.de> writes: <snip> > There is another argument that could convince me to use C instead of > C++: If the simplicity of the language C allowed it to be both > compiled as well as interpreted, then I would favour C (AFAIK, Java's > syntax was deliberately kept "simple" so that code can be added at > run-time, something that would be real nightmare under C++). However, > there is no such C interpreter (at least I don't know one). Well, there's TinyCC. Not exactly an interpreter, but a very fast compiler built as a library so you can embed C in other applications. E.g. you can compile and run a string. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c++
csiph-web