Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #19026 > unrolled thread

C/C++ question about dynamic "static struct"

Back to article view | Back to comp.lang.c++

Contents

  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 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8  Next page →

#19127

On Oct 20, 12:24 pm, Stuart <DerTop...@web.de> wrote:
> On 10/19/12 James Kuyper wrote:
> On 10/20/12 Juha Nieminen 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.

bizzare definition of "C++ programmer". Many of the people I classify
as "C programmers" *you'd* classify as "C++ programmers"!. Some of
these people were actually using a C++ compiler and sometimes weren't
aware they were using C++ (using true and false for instance); but
nevertheless they were C programmers. To be a C++ programmer I submit
you have to use a significant part of non-C C++.

> > 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.

I'm not sure I agree

> > 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.

I'm not sure I'd call Common Lisp "simple"... Scheme maybe.

> > 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,

I simply disagree

> > requiring many of even the
> > simplest tasks to have complex and error-prone implementations.

for instance?

> > It
> > often requires following strict coding conventions to avoid mistakes,

I'm not aware of these coding conventions

> > 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.

I'm more aware of the coding conventions required in C++ (RAII for
instance)

> > 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]

#19137

On 10/21/12 02:45, Nick Keighley wrote:
>> On 10/19/12 James Kuyper wrote:
>>
>>> 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,
>
> I simply disagree
>
>>> requiring many of even the
>>> simplest tasks to have complex and error-prone implementations.
>
> for instance?

Almost anything that involves a dynamically sized set of data.  One 
operation I often have to perform is reading often very large lists of 
string, number pairs into an associative array indexed by the string or 
a set sorted by the number.  Almost one liners in C++.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#19138

Op 20-Oct-12 15:45, Nick Keighley schreef:
> On Oct 20, 12:24 pm, Stuart <DerTop...@web.de> wrote:
>> On 10/19/12 James Kuyper wrote:
>> On 10/20/12 Juha Nieminen 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.
>
> bizzare definition of "C++ programmer". Many of the people I classify
> as "C programmers" *you'd* classify as "C++ programmers"!. Some of
> these people were actually using a C++ compiler and sometimes weren't
> aware they were using C++ (using true and false for instance); but
> nevertheless they were C programmers. To be a C++ programmer I submit
> you have to use a significant part of non-C C++.

My experience is that people with a lot of experience with C coding 
actually have a disadvantage when trying to become a good C++ 
programmers. Though the C way of doing things still work with C++ 
compilers it is far from idiomatic C++.

[toc] | [prev] | [next] | [standalone]

#19146

In comp.lang.c++ Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
>> > However, in the case of C the "simplicity" is not actually a factor
>> > that helps writing simple programs. On the contrary, the "simplicity"
>> > of the language is actually a limiting factor. Rather than help, it
>> > impedes the writing of simple programs,
> 
> I simply disagree

You are entitled to. However, do you have an actual *argument* against
what I said, other than "I simply disagree" and "for instance?"

In things like Lisp, Haskell and Scheme, the simplicity of the language
usually translates to the code itself becoming simple and elegant. Often
you can express in a couple of lines what requires dozens of lines in C++
and hundreds of lines in C. And those two lines are not obfuscated beyond
comprehension, but (when you know the language) are clear, simple and
elegant.

There are several reasons for this, but one of the most important ones is
that the language doesn't burden the programmer with things like memory
management.

Many C advocates try to ride on this concept of "simplicity", but what
they are doing is a glaring fallacy of equivocation. They are (perhaps
deliberately) confusing the brevity of the language specification with
the concept of "simplicity" when talking about programming languages.

Just because the language specification is relatively short (and it's
relatively easy to make a compiler for it) doesn't make the language
*simple*. This is a different kind of "simplicity". A kind that does
*not* help the programmer, but on the contrary is a limitation.

[toc] | [prev] | [next] | [standalone]

#19151

Juha Nieminen wrote:
> In comp.lang.c++ Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
>>>> However, in the case of C the "simplicity" is not actually a factor
>>>> that helps writing simple programs. On the contrary, the "simplicity"
>>>> of the language is actually a limiting factor. Rather than help, it
>>>> impedes the writing of simple programs,
>>
>> I simply disagree
>
> You are entitled to. However, do you have an actual *argument* against
> what I said, other than "I simply disagree" and "for instance?"
>
> In things like Lisp, Haskell and Scheme, the simplicity of the language
> usually translates to the code itself becoming simple and elegant. Often
> you can express in a couple of lines what requires dozens of lines in C++
> and hundreds of lines in C. And those two lines are not obfuscated beyond
> comprehension, but (when you know the language) are clear, simple and
> elegant.
>
> There are several reasons for this, but one of the most important ones is
> that the language doesn't burden the programmer with things like memory
> management.
>
> Many C advocates try to ride on this concept of "simplicity", but what
> they are doing is a glaring fallacy of equivocation. They are (perhaps
> deliberately) confusing the brevity of the language specification with
> the concept of "simplicity" when talking about programming languages.
>

No, I think the "simplicity" of 'C' is more akin to exploiting
the representation of data itself. Knowing how stuff is laid out
in memory offers some measure of relief from some of the bureaucracy
of some systems.

Granted, Scheme/Lisp et al will always be more elegant because
functional notation always is.

There are times to build perfect Pythagorean castles in the air,
and there are times to solder wires to things. The trick is knowing
when.

> Just because the language specification is relatively short (and it's
> relatively easy to make a compiler for it) doesn't make the language
> *simple*. This is a different kind of "simplicity". A kind that does
> *not* help the programmer, but on the contrary is a limitation.
>

So they tell us. So they tell us.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#19155

In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote:
> No, I think the "simplicity" of 'C' is more akin to exploiting
> the representation of data itself. Knowing how stuff is laid out
> in memory offers some measure of relief from some of the bureaucracy
> of some systems.

Having the know the exact layout of the data used in the program is a
really niche use case. Hardly something relevant to the average program.

Regardless, since we are comparing C to C++, and the argument is that
C is "simpler" (and therefore many people prefer to use it), what makes
to you think that it's not possible (or even harder) to know the exact
memory layout of the data in a C++ program?

If, for example, you need for some reason to define a struct in some
precise manner, there's nothing in C++ stopping you from doing that.
There's nothing that C can offer in this regard that's not possible
in C++.

(And before you argue "well, if you are restricting your C++ program
to what C already does, why use C++ at all?" the answer is: To make
the *rest* of the program, ie. the parts that do *not* need that kind
of low-level tinkering, much easier.)

[toc] | [prev] | [next] | [standalone]

#19163

"Juha Nieminen" <nospam@thanks.invalid> wrote in message 
news:k608ee$ke2$1@speranza.aioe.org...
> In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote:
>> No, I think the "simplicity" of 'C' is more akin to exploiting
>> the representation of data itself. Knowing how stuff is laid out
>> in memory offers some measure of relief from some of the bureaucracy
>> of some systems.
>
> Having the know the exact layout of the data used in the program is a
> really niche use case. Hardly something relevant to the average program.

I develop dynamic languages for my own use. Unusually, these have always had 
a struct or 'record' data type, with the ability if necessary to precisely 
define the type and offsets of the elements (even more than C has!), as well 
as having just a bunch of dynamic elements when you don't care about how 
they are stored.

And I use such structs all the time. Sometimes because it's necessary to 
interface with something with a specific layout; sometimes just for the 
pleasure of crafting a perfectly laid out, compact record type with no space 
wasted (with bonus points if it fits into a power-of-two size).

I don't think it's a niche thing at all. If you rarely use it, then perhaps 
you have less need for a language like C anyway.

-- 
bartc 

[toc] | [prev] | [next] | [standalone]

#19170

Juha Nieminen wrote:
> In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote:
>> No, I think the "simplicity" of 'C' is more akin to exploiting
>> the representation of data itself. Knowing how stuff is laid out
>> in memory offers some measure of relief from some of the bureaucracy
>> of some systems.
>
> Having the know the exact layout of the data used in the program is a
> really niche use case. Hardly something relevant to the average program.
>

Where is that median/average program, anyway? For those, I use
interpreters - Tcl and sometimes Python.

> Regardless, since we are comparing C to C++, and the argument is that
> C is "simpler" (and therefore many people prefer to use it), what makes
> to you think that it's not possible (or even harder) to know the exact
> memory layout of the data in a C++ program?
>
> If, for example, you need for some reason to define a struct in some
> precise manner, there's nothing in C++ stopping you from doing that.
> There's nothing that C can offer in this regard that's not possible
> in C++.
>

It's not "possible" so much as it is "likely". Don't get me wrong;
*yesterday*, I was working on about the third iteration of some C++
wrappers for very popular 'C' libraries. Very nice; makes the actual
invoking solution much more elegant. Two of them were
nothing more than a constructor and destructor apiece. One had exactly
one more method than that. Turns 50 lines of 'C' into one line;
a very easy-to-see improvement.

> (And before you argue "well, if you are restricting your C++ program
> to what C already does, why use C++ at all?" the answer is: To make
> the *rest* of the program, ie. the parts that do *not* need that kind
> of low-level tinkering, much easier.)
>

You're kind of begging the question a bit. If all the services are
thoroughly bug free and never fail, then it's great. To badly
paraphrase Voltaire, "hell is other people's code*." The more of
it there is, the more bugs there are.

*and we are them other people, too.

There are all kinds of hubris we have to watch out for. Maintaining
a balance is a constant struggle.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#19197

Le 21/10/2012 19:54, Les Cargill a écrit :
To badly
> paraphrase Voltaire, "hell is other people's code*." The more of
> it there is, the more bugs there are.
>
You probably meant 'to paraphrase Jean-Paul Sartre'...
Voltaire has nothing to do with that sentence...
Ptyxs

[toc] | [prev] | [next] | [standalone]

#19243

On Oct 22, 12:43 pm, ptyxs <kerl...@gmail.com> wrote:
> Le 21/10/2012 19:54, Les Cargill a écrit :
> To badly> paraphrase Voltaire, "hell is other people's code*." The more of
> > it there is, the more bugs there are.
>
> You probably meant 'to paraphrase Jean-Paul Sartre'...
> Voltaire has nothing to do with that sentence...
> Ptyxs

Les was too busy correcting University Dons about category mistakes...

[toc] | [prev] | [next] | [standalone]

#19249

gwowen wrote:
> On Oct 22, 12:43 pm, ptyxs <kerl...@gmail.com> wrote:
>> Le 21/10/2012 19:54, Les Cargill a écrit :
>> To badly> paraphrase Voltaire, "hell is other people's code*." The more of
>>> it there is, the more bugs there are.
>>
>> You probably meant 'to paraphrase Jean-Paul Sartre'...
>> Voltaire has nothing to do with that sentence...
>> Ptyxs
>
> Les was too busy correcting University Dons about category mistakes...
>

LOLz!

One a' them Frenchies, anyway! :) Trotting out "category error" on
usenet is problematic - it's hard enough just getting people to agree
to what words mean.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#19267

On Oct 21, 8:32 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> In comp.lang.c++ Les Cargill <lcargil...@comcast.com> wrote:

> > No, I think the "simplicity" of 'C' is more akin to exploiting
> > the representation of data itself. Knowing how stuff is laid out
> > in memory offers some measure of relief from some of the bureaucracy
> > of some systems.
>
> Having the know the exact layout of the data used in the program is a
> really niche use case. Hardly something relevant to the average program.

besides it isn't true anyway. You have to know quite a bit about your
compiler to know how data is laid out. In principle it can change at
the drop of an optimisation flag

> Regardless, since we are comparing C to C++, and the argument is that
> C is "simpler" (and therefore many people prefer to use it), what makes
> to you think that it's not possible (or even harder) to know the exact
> memory layout of the data in a C++ program?
>
> If, for example, you need for some reason to define a struct in some
> precise manner, there's nothing in C++ stopping you from doing that.
> There's nothing that C can offer in this regard that's not possible
> in C++.
>
> (And before you argue "well, if you are restricting your C++ program
> to what C already does, why use C++ at all?" the answer is: To make
> the *rest* of the program, ie. the parts that do *not* need that kind
> of low-level tinkering, much easier.)

yes I've seen programs with C down in the bowels doing lost of bit
banging (near signal processing) but this was all embedded in classes
that hid the nasty stuff from the rest of the program.

[toc] | [prev] | [next] | [standalone]

#19266

On Oct 21, 8:05 am, Juha Nieminen <nos...@thanks.invalid> wrote:
> In comp.lang.c++ Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:

> >> > However, in the case of C the "simplicity" is not actually a factor
> >> > that helps writing simple programs. On the contrary, the "simplicity"
> >> > of the language is actually a limiting factor. Rather than help, it
> >> > impedes the writing of simple programs,
>
> > I simply disagree
>
> You are entitled to. However, do you have an actual *argument* against
> what I said, other than "I simply disagree" and "for instance?"

well I thought you were the one making the large claim; that a
language that is "simple" because it's small and reasonably easy to
learn isn't "simple" in its application. Obviously you can write
horrible programs in any language. C (or reasonably well written C) is
usually quite transparent.

I have to admit these days I write C++. Even for noddy little programs
(which I probably should be using a script for). std::vector,
std::string just being too good to pass over.

> In things like Lisp, Haskell and Scheme, the simplicity of the language
> usually translates to the code itself becoming simple and elegant.

probably never became good enough with any of these for it to kick. I
quite like scheme but it never seemed to end up being really "simple".
But I accept that's my fault.

> Often
> you can express in a couple of lines what requires dozens of lines in C++
> and hundreds of lines in C. And those two lines are not obfuscated beyond
> comprehension, but (when you know the language) are clear, simple and
> elegant.
>
> There are several reasons for this, but one of the most important ones is
> that the language doesn't burden the programmer with things like memory
> management.

and garbage collection has its own problems

> Many C advocates try to ride on this concept of "simplicity", but what
> they are doing is a glaring fallacy of equivocation. They are (perhaps
> deliberately) confusing the brevity of the language specification with
> the concept of "simplicity" when talking about programming languages.
>
> Just because the language specification is relatively short (and it's
> relatively easy to make a compiler for it) doesn't make the language
> *simple*. This is a different kind of "simplicity". A kind that does
> *not* help the programmer, but on the contrary is a limitation.

[toc] | [prev] | [next] | [standalone]

#19133

Juha Nieminen wrote:
> In comp.lang.c++ Ian Collins <ian-news@hotmail.com> wrote:
>>> I'm sure that's quite normal thinking for anyone who would label
>>> themselves a "C++ programmer". However, you should not be surprised to
>>> find very different thinking among the people frequenting comp.lang.c,
>>> where this message is also cross-posted. Anyone bothering to monitor
>>> comp.lang.c (and there's a fair number of us) can reasonably be expected
>>> to choose the simplicity of C over the complexity of C++ in at least
>>> some circumstances. You might question the validity of that choice, but
>>> you can't expect such questions to go over very well in that newsgroup.
>>
>> A one who works with and enjoys both languages, the statement "choose
>> the simplicity of C over the complexity of C++" is one I have trouble
>> with.  C is undoubtedly a simpler language, but the the solutions to
>> many day to day problems are undoubtedly simpler in C++.
>>
>> So the choice is often "do I want the simple solution in a more complex
>> language, or the more complex solution in a simple language?".
>
> That's also the problem I find with the "argument from simplicity",
> as one could call it.
>
> When talking about C, making the simplicity argument is basically a
> category error.

Almost all arguments from "category error" are themselves category 
errors. So "mu". I've seen Oxford dons make massive piles of steaming
nonsense out of "category error".

> The argument is trying to appeal to the notion that
> simpler higher-level languages (such as Lisp) are generally considered
> better than overly complex languages. In those languages it is often
> so that the same thing can be expressed in a much simpler and more
> brief manner, and the result is much "leaner and cleaner" code than
> in overly complicated languages. (For example the language specification
> of Lisp is relatively short, yet the language itself is incredibly
> expressive and powerful.)
>
> In other words, a simple language helps writing simple programs (that
> are nevertheless very expressive.)
>

No, the thing about lisp is that it is *interpretive*.

> However, in the case of C the "simplicity" is not actually a factor
> that helps writing simple programs. On the contrary, the "simplicity"
> of the language is actually a limiting factor. Rather than help, it
> impedes the writing of simple programs, requiring many of even the
> simplest tasks to have complex and error-prone implementations. It
> often requires following strict coding conventions to avoid mistakes,
> coding conventions that are completely unnecessary in truly simple
> languages. Truly simple languages allow the programmer to concentrate
> purely on the task at hand, without having to pay any attention to such
> trivial and inconsequential matters as memory management and such.

C++ is much *worse* for memory management than is 'C' - in that
the possibility of memory leaks goes up. Absent writing GUI code,
it's entirely possible to write entire deployable systems that use no 
dynamic memory at all in 'C'. indeed, that's been the shop
standard most places I have worked.

> C isn't that kind of language. In C the "simplicity" forces the
> programmer to write complex programs that need to constantly be careful
> about things that should normally be non-issues.
>
> This doesn't mean that C++ is a simple language in this regard.
> However, C++ is a lot *better* in this regard than C. Yes, there are
> coding conventions that need to be followed eg. because of memory
> management reasons, but those conventions are simpler and easier to
> follow, and much of the work is done automatically by the compiler.

Not... really. Let's not confuse our preferences for facts, shall we?
The subject is sufficiently complex that you have to figure out how to
measure the thing being discussed - you can't constructively assert
superiority with out doing a lot of work, and that's pretty boring
work. It's actually both boring and terrifying.

> C++ also offers many tools (in both native syntax and in the form of
> the standard library) that makes many, many tasks a lot easier and
> simpler than in C.
>

To my eye, the solutions  there are uglier, and a choice like Tcl
or Python makes C++ less interesting. Because interpreters provide
a much better suite of "furniture".

> The typical arguments that C++ is so much larger and more complex
> than C, and that it requires significantly more learning, ring quite
> hollow to the experienced C++ programmer.

Because experienced programmer is experienced. The very basis for
determining whether the language features are improvements is
really complex and usually such discussions are simply people
exposing biases.

> Why would it matter to me
> in the least bit if the language is large and requires a lot of
> learning? That's completely inconsequential to me.

Just... wow. It's a *huge* problem. I'm not "into languages"
to be into languages, I am into them to be able to operate on teams
that produce deployable systems that work without causing anybody
any problems.

A novice can really get 95% of everything they need to know
about 'C' in a matter of months, while being productive
under supervision. I am not sure there is a collection
of ten people on the planet who , between them , know everything
there is to know about C++.

> It may be relevant
> if we were talking about what a newbie programmer should learn, but
> it's completely irrelevant to me. I know how to use the language
> efficiently, and when given the choice between C or C++, there's just
> no choice to make, because it's obvious. I choose the one that allows
> me to implement the task at hand more easily, ie. C++.
>

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#19136

On 10/21/12 07:44, Les Cargill wrote:
> Juha Nieminen wrote:
>
>> However, in the case of C the "simplicity" is not actually a factor
>> that helps writing simple programs. On the contrary, the "simplicity"
>> of the language is actually a limiting factor. Rather than help, it
>> impedes the writing of simple programs, requiring many of even the
>> simplest tasks to have complex and error-prone implementations. It
>> often requires following strict coding conventions to avoid mistakes,
>> coding conventions that are completely unnecessary in truly simple
>> languages. Truly simple languages allow the programmer to concentrate
>> purely on the task at hand, without having to pay any attention to such
>> trivial and inconsequential matters as memory management and such.
>
> C++ is much *worse* for memory management than is 'C' - in that
> the possibility of memory leaks goes up. Absent writing GUI code,
> it's entirely possible to write entire deployable systems that use no
> dynamic memory at all in 'C'. indeed, that's been the shop
> standard most places I have worked.

You can do and some embedded code I've worked on does the same in C++. 
C simply can't do RAII, so C++ has a built in advantage when it comes to 
memory (or any other resource) management.  The ability to automatically 
manage resources also removes the last excuse to use goto, but that's 
another story!

>> C isn't that kind of language. In C the "simplicity" forces the
>> programmer to write complex programs that need to constantly be careful
>> about things that should normally be non-issues.
>>
>> This doesn't mean that C++ is a simple language in this regard.
>> However, C++ is a lot *better* in this regard than C. Yes, there are
>> coding conventions that need to be followed eg. because of memory
>> management reasons, but those conventions are simpler and easier to
>> follow, and much of the work is done automatically by the compiler.
>
> Not... really. Let's not confuse our preferences for facts, shall we?

Just compare code using automatic resource management with code that 
does it by hand.  Pay particular attention to the clean up code if the 
nth allocation in a function fails....

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#19139

Op 20-Oct-12 22:09, Ian Collins schreef:
> On 10/21/12 07:44, Les Cargill wrote:
>> Juha Nieminen wrote:
>>
>>> However, in the case of C the "simplicity" is not actually a factor
>>> that helps writing simple programs. On the contrary, the "simplicity"
>>> of the language is actually a limiting factor. Rather than help, it
>>> impedes the writing of simple programs, requiring many of even the
>>> simplest tasks to have complex and error-prone implementations. It
>>> often requires following strict coding conventions to avoid mistakes,
>>> coding conventions that are completely unnecessary in truly simple
>>> languages. Truly simple languages allow the programmer to concentrate
>>> purely on the task at hand, without having to pay any attention to such
>>> trivial and inconsequential matters as memory management and such.
>>
>> C++ is much *worse* for memory management than is 'C' - in that
>> the possibility of memory leaks goes up. Absent writing GUI code,
>> it's entirely possible to write entire deployable systems that use no
>> dynamic memory at all in 'C'. indeed, that's been the shop
>> standard most places I have worked.
>
> You can do and some embedded code I've worked on does the same in C++. C
> simply can't do RAII, so C++ has a built in advantage when it comes to
> memory (or any other resource) management.  The ability to automatically
> manage resources also removes the last excuse to use goto, but that's
> another story!
>
>>> C isn't that kind of language. In C the "simplicity" forces the
>>> programmer to write complex programs that need to constantly be careful
>>> about things that should normally be non-issues.
>>>
>>> This doesn't mean that C++ is a simple language in this regard.
>>> However, C++ is a lot *better* in this regard than C. Yes, there are
>>> coding conventions that need to be followed eg. because of memory
>>> management reasons, but those conventions are simpler and easier to
>>> follow, and much of the work is done automatically by the compiler.
>>
>> Not... really. Let's not confuse our preferences for facts, shall we?
>
> Just compare code using automatic resource management with code that
> does it by hand.  Pay particular attention to the clean up code if the
> nth allocation in a function fails....

...and other alternate/exceptional execution flows.

[toc] | [prev] | [next] | [standalone]

#19148

Ian Collins wrote:
> On 10/21/12 07:44, Les Cargill wrote:
>> Juha Nieminen wrote:
>>
>>> However, in the case of C the "simplicity" is not actually a factor
>>> that helps writing simple programs. On the contrary, the "simplicity"
>>> of the language is actually a limiting factor. Rather than help, it
>>> impedes the writing of simple programs, requiring many of even the
>>> simplest tasks to have complex and error-prone implementations. It
>>> often requires following strict coding conventions to avoid mistakes,
>>> coding conventions that are completely unnecessary in truly simple
>>> languages. Truly simple languages allow the programmer to concentrate
>>> purely on the task at hand, without having to pay any attention to such
>>> trivial and inconsequential matters as memory management and such.
>>
>> C++ is much *worse* for memory management than is 'C' - in that
>> the possibility of memory leaks goes up. Absent writing GUI code,
>> it's entirely possible to write entire deployable systems that use no
>> dynamic memory at all in 'C'. indeed, that's been the shop
>> standard most places I have worked.
>
> You can do and some embedded code I've worked on does the same in C++. C
> simply can't do RAII,

Not in the specific manner Stoustrup used it, but it's
perfectly easy to achieve the same goal. But RAII is
much less a concern when you don't have exceptions... although
I have seen people do things with setjmp()/longjmp() that
were very very clever - including hooking hardware exceptions and
hitting longjmp() with it.

> so C++ has a built in advantage when it comes to
> memory (or any other resource) management.  The ability to automatically
> manage resources also removes the last excuse to use goto, but that's
> another story!
>
>>> C isn't that kind of language. In C the "simplicity" forces the
>>> programmer to write complex programs that need to constantly be careful
>>> about things that should normally be non-issues.
>>>
>>> This doesn't mean that C++ is a simple language in this regard.
>>> However, C++ is a lot *better* in this regard than C. Yes, there are
>>> coding conventions that need to be followed eg. because of memory
>>> management reasons, but those conventions are simpler and easier to
>>> follow, and much of the work is done automatically by the compiler.
>>
>> Not... really. Let's not confuse our preferences for facts, shall we?
>
> Just compare code using automatic resource management with code that
> does it by hand.  Pay particular attention to the clean up code if the
> nth allocation in a function fails....
>

Sorry, this really doesn't apply to any cases I've seen in a long
time that were not GUI programs - and I believe I stipulated to
"use something besides C++ for GUIs, please" upthread.

'Course, I'm the sort who would use a state machine to manage an
overly onerous memory allocation problem - and in C++ -  so...

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#19154

On 10/21/12 20:11, Les Cargill wrote:
> Ian Collins wrote:
>> On 10/21/12 07:44, Les Cargill wrote:
>>> Juha Nieminen wrote:
>>>
>>>> However, in the case of C the "simplicity" is not actually a factor
>>>> that helps writing simple programs. On the contrary, the "simplicity"
>>>> of the language is actually a limiting factor. Rather than help, it
>>>> impedes the writing of simple programs, requiring many of even the
>>>> simplest tasks to have complex and error-prone implementations. It
>>>> often requires following strict coding conventions to avoid mistakes,
>>>> coding conventions that are completely unnecessary in truly simple
>>>> languages. Truly simple languages allow the programmer to concentrate
>>>> purely on the task at hand, without having to pay any attention to such
>>>> trivial and inconsequential matters as memory management and such.
>>>
>>> C++ is much *worse* for memory management than is 'C' - in that
>>> the possibility of memory leaks goes up. Absent writing GUI code,
>>> it's entirely possible to write entire deployable systems that use no
>>> dynamic memory at all in 'C'. indeed, that's been the shop
>>> standard most places I have worked.
>>
>> You can do and some embedded code I've worked on does the same in C++. C
>> simply can't do RAII,
>
> Not in the specific manner Stoustrup used it, but it's
> perfectly easy to achieve the same goal.

I'm sorry, but it isn't. RAII is one C++ feature that C can't do.

> But RAII is
> much less a concern when you don't have exceptions...

Not at all.  It can be used anywhere a resource has to be managed.  It 
avoids the goto spaghetti often seen in C code to handle an allocation 
failure in a block of allocations.

>> so C++ has a built in advantage when it comes to
>> memory (or any other resource) management.  The ability to automatically
>> manage resources also removes the last excuse to use goto, but that's
>> another story!
>>
>>>> C isn't that kind of language. In C the "simplicity" forces the
>>>> programmer to write complex programs that need to constantly be careful
>>>> about things that should normally be non-issues.
>>>>
>>>> This doesn't mean that C++ is a simple language in this regard.
>>>> However, C++ is a lot *better* in this regard than C. Yes, there are
>>>> coding conventions that need to be followed eg. because of memory
>>>> management reasons, but those conventions are simpler and easier to
>>>> follow, and much of the work is done automatically by the compiler.
>>>
>>> Not... really. Let's not confuse our preferences for facts, shall we?
>>
>> Just compare code using automatic resource management with code that
>> does it by hand.  Pay particular attention to the clean up code if the
>> nth allocation in a function fails....
>>
>
> Sorry, this really doesn't apply to any cases I've seen in a long
> time that were not GUI programs

You obviously haven't looked at kernel and library code!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#19156

In comp.lang.c++ Ian Collins <ian-news@hotmail.com> wrote:
>> But RAII is
>> much less a concern when you don't have exceptions...
> 
> Not at all.  It can be used anywhere a resource has to be managed.  It 
> avoids the goto spaghetti often seen in C code to handle an allocation 
> failure in a block of allocations.

I have seen the exception-safety argument (ie. "RAII is mostly useful to
make code exception-safe, but without support for exceptions they are
not all that useful") quite many times, and I have always wondered where
it comes from.

RAII is most certainly very useful even if you didn't have exceptions.
It makes code much safer and simpler at the same time. The more complicated
the interactions between different modules and data containers, the more
that stuff is passed around, the more useful RAII becomes in order to keep
the program simple and safe.

[toc] | [prev] | [next] | [standalone]

#19171

Ian Collins wrote:
> On 10/21/12 20:11, Les Cargill wrote:
>> Ian Collins wrote:
>>> On 10/21/12 07:44, Les Cargill wrote:
>>>> Juha Nieminen wrote:
>>>>
>>>>> However, in the case of C the "simplicity" is not actually a factor
>>>>> that helps writing simple programs. On the contrary, the "simplicity"
>>>>> of the language is actually a limiting factor. Rather than help, it
>>>>> impedes the writing of simple programs, requiring many of even the
>>>>> simplest tasks to have complex and error-prone implementations. It
>>>>> often requires following strict coding conventions to avoid mistakes,
>>>>> coding conventions that are completely unnecessary in truly simple
>>>>> languages. Truly simple languages allow the programmer to concentrate
>>>>> purely on the task at hand, without having to pay any attention to
>>>>> such
>>>>> trivial and inconsequential matters as memory management and such.
>>>>
>>>> C++ is much *worse* for memory management than is 'C' - in that
>>>> the possibility of memory leaks goes up. Absent writing GUI code,
>>>> it's entirely possible to write entire deployable systems that use no
>>>> dynamic memory at all in 'C'. indeed, that's been the shop
>>>> standard most places I have worked.
>>>
>>> You can do and some embedded code I've worked on does the same in C++. C
>>> simply can't do RAII,
>>
>> Not in the specific manner Stoustrup used it, but it's
>> perfectly easy to achieve the same goal.
>
> I'm sorry, but it isn't. RAII is one C++ feature that C can't do.
>

I respectfully submit that you haven't thought
that though. I won't bore you with the sea stories...
but it's been done...

What Stoustroup provided was an artifact that created a culture
that tried to solve these problems. He did a great job.

>> But RAII is
>> much less a concern when you don't have exceptions...
>
> Not at all.

Ah! You're avoiding my carefully chosen weasel - "much less than". :)

>  It can be used anywhere a resource has to be managed.  It
> avoids the goto spaghetti often seen in C code to handle an allocation
> failure in a block of allocations.
>

People were successfully avoiding that spaghetti decades ago
with much less powerful tools.

So write a state machine, with one allocation per state and  do
*absolutely nothing else* until it terminates. It's the software 
equivalent of "get the money up front." If you have
additional allocations later, just add states. Push successful states on 
a stack, and unwind on failure.  Bada boom, bada bing.

for extra credit, have the allocation requester extend the state
machine in an abstract way. Use the __FILE__ and __LINE__ macros
also in this stack, and write a dump routine. Presto! Asymptotically
full memory leak disclosure.

And then, to be a total creep, use a 'C' macro
to substitute your scheme for malloc()/free()....

I'd allocate the stack thingy very, very statically....

"But I don't want to write a state machine!" Well,
you're not all that concerned about managing complexity
then, are you? :)

And I want a pony, too.

I mean absolutely no offense, but comments like yours sound like
learned helplessness to me. Break those chains! Take control
of your destiny! Power to the proletariat!

Strike that last one. But really, the project I first
did that on was out of control and this helped stabilize things
*immensely*. Operation without instrumentation is like using
a credit card without reading the billing statements.

>>> so C++ has a built in advantage when it comes to
>>> memory (or any other resource) management.  The ability to automatically
>>> manage resources also removes the last excuse to use goto, but that's
>>> another story!
>>>
>>>>> C isn't that kind of language. In C the "simplicity" forces the
>>>>> programmer to write complex programs that need to constantly be
>>>>> careful
>>>>> about things that should normally be non-issues.
>>>>>
>>>>> This doesn't mean that C++ is a simple language in this regard.
>>>>> However, C++ is a lot *better* in this regard than C. Yes, there are
>>>>> coding conventions that need to be followed eg. because of memory
>>>>> management reasons, but those conventions are simpler and easier to
>>>>> follow, and much of the work is done automatically by the compiler.
>>>>
>>>> Not... really. Let's not confuse our preferences for facts, shall we?
>>>
>>> Just compare code using automatic resource management with code that
>>> does it by hand.  Pay particular attention to the clean up code if the
>>> nth allocation in a function fails....
>>>
>>
>> Sorry, this really doesn't apply to any cases I've seen in a long
>> time that were not GUI programs
>
> You obviously haven't looked at kernel and library code!
>

Heh. The One True Kernel, and Linus is its prophet? :)

Oh, I have. it's *a* way.  May you never hear the words "We
want you to write a patch against the bridge code..." :) It's
good code, but very branchey - you end up following lots of chains.
*Generally*, that sort of activity is unnecessary.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8  Next page →

Back to top | Article view | comp.lang.c++

csiph-web