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

#19271

On Oct 26, 1:53 pm, Les Cargill <lcargil...@comcast.com> wrote:
> gwowen wrote:
> > On Oct 22, 8:02 pm, Les Cargill <lcargil...@comcast.com> wrote:


> >> Fair enough; I'm not sure what you were driving at then. It's fully
> >> possible for 'C' programs to leave no widowed
> >> resources, memory or otherwise.

do you assume memory is allocated in a stack-like manner? Because that
simply wouldn't work on the systems I'm thinking about. Mobile radio
calls don't appear and disappear in a stack-like manner.

> > No-one has suggested otherwise.  But that's not what RAII is.  RAII is
> > mapping resource acquisition/release to object lifetime, and thus
> > using the *automatic* object construction/destruction semantics of the
> > language to ensure correct resource management.
>
> Ach! Burry McDonald is nae true Scotsman :)
>
> I still suspect that some of that contains distinctions  without
> differences. But I like the working definition you gave - "mapping
> construction/deconstruction to object lifetimes." That's
> clearer than what I'd seen before.
>
> maybe I'll get the privilege of actually *learning* RAII ( through
> doing a project with it ) rather than  reading about it. Otherwise,
> it's like pronouncing a word you've only read...
>
> > C doesn't have meaningful automatic, deterministic construction/
> > destruction of non-trivial objects, so you can't do RAII (as it is
> > understood) in pure C.
>
> >> It's not even that difficult.
>
> > Well, there we'll have to differ.
>
> Well, you have to *cheat* :) ( Ever use "atexit()"?).

way too late in most of the programs I've encountered. These systems
are supposed to run "forever". Cleaning up all the crap on exit is no
good in a program that isn't supposed to exit!

> The thing I was talking about really isn't GC, and it really
> isn't ( apparently ) RAII. Got the thing(s) shipped, though.
>
> It's probably closer to mark()/release().

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

#19280

Nick Keighley wrote:
> On Oct 26, 1:53 pm, Les Cargill <lcargil...@comcast.com> wrote:
>> gwowen wrote:
>>> On Oct 22, 8:02 pm, Les Cargill <lcargil...@comcast.com> wrote:
>
>
>>>> Fair enough; I'm not sure what you were driving at then. It's fully
>>>> possible for 'C' programs to leave no widowed
>>>> resources, memory or otherwise.
>
> do you assume memory is allocated in a stack-like manner? Because that
> simply wouldn't work on the systems I'm thinking about. Mobile radio
> calls don't appear and disappear in a stack-like manner.
>

No, I don't assume that. Dynamic circuit creation/deletion usually
means you have state per circuit. It's possible to have a "global"
list of this state with instrumentation against that list
to track whether or not widowed circuits exist.

RAII would also solve this in a less "global" manner.

>>> No-one has suggested otherwise.  But that's not what RAII is.  RAII is
>>> mapping resource acquisition/release to object lifetime, and thus
>>> using the *automatic* object construction/destruction semantics of the
>>> language to ensure correct resource management.
>>
>> Ach! Burry McDonald is nae true Scotsman :)
>>
>> I still suspect that some of that contains distinctions  without
>> differences. But I like the working definition you gave - "mapping
>> construction/deconstruction to object lifetimes." That's
>> clearer than what I'd seen before.
>>
>> maybe I'll get the privilege of actually *learning* RAII ( through
>> doing a project with it ) rather than  reading about it. Otherwise,
>> it's like pronouncing a word you've only read...
>>
>>> C doesn't have meaningful automatic, deterministic construction/
>>> destruction of non-trivial objects, so you can't do RAII (as it is
>>> understood) in pure C.
>>
>>>> It's not even that difficult.
>>
>>> Well, there we'll have to differ.
>>
>> Well, you have to *cheat* :) ( Ever use "atexit()"?).
>
> way too late in most of the programs I've encountered. These systems
> are supposed to run "forever". Cleaning up all the crap on exit is no
> good in a program that isn't supposed to exit!
>

I am using "atexit()" metaphorically. There exist frames of context,
and at the bottom of each frame ( when the frame goes away ), it
cleans up all the things it allocated.

This is still not "stack" stuff, because it's not LIFO.

>> The thing I was talking about really isn't GC, and it really
>> isn't ( apparently ) RAII. Got the thing(s) shipped, though.
>>
>> It's probably closer to mark()/release().

--
Les Cargill

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

#19284

Nick Keighley wrote:
> On Oct 26, 1:53 pm, Les Cargill <lcargil...@comcast.com> wrote:
>> gwowen wrote:
>>> On Oct 22, 8:02 pm, Les Cargill <lcargil...@comcast.com> wrote:
>
>
>>>> Fair enough; I'm not sure what you were driving at then. It's fully
>>>> possible for 'C' programs to leave no widowed
>>>> resources, memory or otherwise.
>
> do you assume memory is allocated in a stack-like manner? Because that
> simply wouldn't work on the systems I'm thinking about. Mobile radio
> calls don't appear and disappear in a stack-like manner.
>

No, something else. More an.... accounting system that's relatively
transparent that allows you to more easily estimate the state of the heap.

>>> No-one has suggested otherwise.  But that's not what RAII is.  RAII is
>>> mapping resource acquisition/release to object lifetime, and thus
>>> using the *automatic* object construction/destruction semantics of the
>>> language to ensure correct resource management.
>>
>> Ach! Burry McDonald is nae true Scotsman :)
>>
>> I still suspect that some of that contains distinctions  without
>> differences. But I like the working definition you gave - "mapping
>> construction/deconstruction to object lifetimes." That's
>> clearer than what I'd seen before.
>>
>> maybe I'll get the privilege of actually *learning* RAII ( through
>> doing a project with it ) rather than  reading about it. Otherwise,
>> it's like pronouncing a word you've only read...
>>
>>> C doesn't have meaningful automatic, deterministic construction/
>>> destruction of non-trivial objects, so you can't do RAII (as it is
>>> understood) in pure C.
>>
>>>> It's not even that difficult.
>>
>>> Well, there we'll have to differ.
>>
>> Well, you have to *cheat* :) ( Ever use "atexit()"?).
>
> way too late in most of the programs I've encountered. These systems
> are supposed to run "forever". Cleaning up all the crap on exit is no
> good in a program that isn't supposed to exit!
>

So make your own "exit()" equivalent...

This being said, *culturally*, RAII is probably a better solution
because it's better known.

>> The thing I was talking about really isn't GC, and it really
>> isn't ( apparently ) RAII. Got the thing(s) shipped, though.
>>
>> It's probably closer to mark()/release().

--
Les Cargill

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

#19218

On Monday, 22 October 2012 10:25:11 UTC+13, Les Cargill  wrote:
> Ian Collins wrote:
>> On 10/22/12 07:31, Les Cargill wrote:
>>> Ian Collins wrote:
>>>> On 10/21/12 20:11, Les Cargill wrote:
>>>>> Ian Collins wrote:
> 
> >>>>> C simply can't do RAII,
> >>>>
> >>>> Not in the specific manner Stoustrup used it, but it's
> >>>> perfectly easy to achieve the same goal.
> >>>
> >>> I'm sorry, but it isn't. RAII is one C++ feature that C can't do.
> >>>
> >>
> >> I respectfully submit that you haven't thought
> >> that though. I won't bore you with the sea stories...
> >> but it's been done...
> >
> > I certainly have thought it through.  Please provide an example of RAII
> > in C.
> 
> So we're talking RAII as modulo exceptions - unless longjmp() is alos an 
> exception...
> 
> So you *haven't* thought about it, then? It's not exactly rocket
> surgery. I am just enumerating my assumptions in responding to your 
> post, not *accusing* you of anything.
> 
> Essentially replace malloc()/free() with something that tracks 
> allocation and provides instrumentation about the state of the heap.
> This is much simpler than it sounds...

So provide an example in standard C.  It looks like all your piss and wind
is an attempt to cover up the fact that you can't.

RAII can be used in the context of any resource (hence its name!), not just 
memory.

> Given all the rash about it, I am surprised 'C' doesn't offer this 
> natively, and that there were never commercial products of the same
> stripe.

Which was my original point, thank you.

-- 
Ian.

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

#19269

On Oct 21, 8:11 am, Les Cargill <lcargil...@comcast.com> 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. 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...

in the systems I've used there all sorts of things that are
dynamically allocated- there are "events" (internal messages), TCP/IP
packets, timers and all sorts of application specific thingies (calls,
targets, alarms, equipment allocations, maps etc. etc.). I hard to see
how you can avoid dynamically allocating things except in the most
hard real time systems.

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

#19283

Nick Keighley wrote:
> On Oct 21, 8:11 am, Les Cargill <lcargil...@comcast.com> wrote:
>> Ian Collins wrote:
<snip>
>>
>> 'Course, I'm the sort who would use a state machine to manage an
>> overly onerous memory allocation problem - and in C++ -  so...
>
> in the systems I've used there all sorts of things that are
> dynamically allocated- there are "events" (internal messages), TCP/IP
> packets, timers and all sorts of application specific thingies (calls,
> targets, alarms, equipment allocations, maps etc. etc.). I hard to see
> how you can avoid dynamically allocating things except in the most
> hard real time systems.
>

TCP/IP is inherently dynamic, but it's a well trod service.

The rest? You simply have an "auction" with yourself - "I will
allow no more than 50 simultaneous events, 20 targets, 100
mappings", then you get the worst-case numbers and test it.
This includes developing ... generators that prove
all the constraints and will make you a script which you
can use to convince yourself you've exhaustively tested it.

State machines seem to be relegated to FPGA development
and the hardest of hard real-time but IMO, they're especially
useful in applications development.

--
Les Cargill

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

#19270

On Oct 21, 8:11 am, Les Cargill <lcargil...@comcast.com> 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. 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...

oh yes- and all the non-memory stuff. Files, database handles, pens
yadda yadda

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

#19147

In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote:
>> When talking about C, making the simplicity argument is basically a
>> category error.
> 
> Almost all arguments from "category error" are themselves category 
> errors. So "mu". I've seen Oxford dons make massive piles of steaming
> nonsense out of "category error".

And I have noticed that often when someone doesn't have any *actual*
good arguments, they instead go meta, criticizing someone for the
concepts or terminology they are using, rather than their actual
arguments.

> C++ is much *worse* for memory management than is 'C'

Ok, you lost all credibility. I don't think it's necessary to go further.

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

#19157

Juha Nieminen wrote:
> In comp.lang.c++ Les Cargill <lcargill99@comcast.com> wrote:
>>> When talking about C, making the simplicity argument is basically a
>>> category error.
>>
>> Almost all arguments from "category error" are themselves category
>> errors. So "mu". I've seen Oxford dons make massive piles of steaming
>> nonsense out of "category error".
>
> And I have noticed that often when someone doesn't have any *actual*
> good arguments, they instead go meta, criticizing someone for the
> concepts or terminology they are using, rather than their actual
> arguments.
>

Yeah, that was a bit snarkier than it perhaps should have been.

I don't think the invocation of category errors in this sort of
discussion is likely to be productive. Different languages live in
semi-orthogonal domains, so there tends not to be a lot of
synergy. Good language systems allow for interfacing to
other language systems with a minimum of fuss.

>> C++ is much *worse* for memory management than is 'C'
>
> Ok, you lost all credibility. I don't think it's necessary to go further.
>

I've built significant, non-embedded,  production systems using only
'C' that used no dynamic allocation at all. It doesn't get any less 
worse than that. It wasn't difficult. You can do that in C++ too, but
it's a lot less ... sensible.

It is possible that there is a bias error I missed, but memory leaks
were much less a problem when the state of the art was 'C', at
least within the things I saw. As a *cultural* artifact, C++
made things worse for a while. This being said, newer
languages are beginning to improve on that significantly.

it well could be that 'C' simply kept otherwise sensible people
from *doing* programming through barrier to entry. Ironic,
since it was shrinkwrap 'C' compilers that helped popularize it...

I have never understood why managing memory allocation manually was 
considered to be so onerous. Perhaps it's a personal failing. And
limitation can be extremely important to the general creative process.

I suppose my main gripe about C++ is just how much harder it made it
to dynamically configure a running system. If all the cardinalities and
sizes have to be declared at instantiation of all the objects, you
have then to tear them all down and rebuild them when a message to
reconfigure comes through. This can be a serious liability.

--
Les Cargill

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

#19158

On 10/21/12 20:51, Les Cargill wrote:
> Juha Nieminen wrote:
>> In comp.lang.c++ Les Cargill<lcargill99@comcast.com>  wrote:
>
>>> C++ is much *worse* for memory management than is 'C'
>>
>> Ok, you lost all credibility. I don't think it's necessary to go further.
>>
>
> I've built significant, non-embedded,  production systems using only
> 'C' that used no dynamic allocation at all. It doesn't get any less
> worse than that. It wasn't difficult. You can do that in C++ too, but
> it's a lot less ... sensible.

Why?  It's not uncommon to have static embedded C++ applications.

> I have never understood why managing memory allocation manually was
> considered to be so onerous. Perhaps it's a personal failing. And
> limitation can be extremely important to the general creative process.

It is also the cause of an awful lot of bugs....

> I suppose my main gripe about C++ is just how much harder it made it
> to dynamically configure a running system. If all the cardinalities and
> sizes have to be declared at instantiation of all the objects, you
> have then to tear them all down and rebuild them when a message to
> reconfigure comes through. This can be a serious liability.

The difference to C here is?

-- 
Ian Collins

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

#19164

Les Cargill wrote:

>>> C++ is much *worse* for memory management than is 'C'
>>
>> Ok, you lost all credibility. I don't think it's necessary to go further.
>>
> 
> I've built significant, non-embedded,  production systems using only
> 'C' that used no dynamic allocation at all. It doesn't get any less
> worse than that. It wasn't difficult. You can do that in C++ too, but
> it's a lot less ... sensible.

Just because you were able to use a language without allocating any memory, 
it doesn't mean that some other language is suddenly plagued with memory 
allocation problems.  Your argument becomes even sillier when considering 
that you are referring to a language which is an improper superset of the 
language you used to pull that stunt, which means that you can also pull 
that off with the language you tried to criticize. 


> It is possible that there is a bias error I missed, but memory leaks
> were much less a problem when the state of the art was 'C', at
> least within the things I saw. 

Again, that is a silly thing to say.  Programmers cause memory leaks, not 
the language.  In addition, with C++'s RAII it is considerably easier to 
take care of any memory allocation issue, while with C it is necessary to 
explicitly track every allocation/deallocation to be able to avoid memory 
leaks.


> As a *cultural* artifact, C++
> made things worse for a while. 

Obviously, it hasn't.  You may argue that programmers using the language may 
have misused it, but blaming the tools while leaving out the workman is a 
silly thing to do.


<snip/>
> I suppose my main gripe about C++ is just how much harder it made it
> to dynamically configure a running system. 

You can't blame a language for any hypothetical problem caused by the way a 
system was designed.


Rui Maciel

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

#19161

Les Cargill wrote:

> Juha Nieminen wrote:
>> In comp.lang.c++ Ian Collins <ian-news@hotmail.com> wrote:
>>>> I'm sure that's quite normal thinking for anyone who would label
>>>> themselves a "C++ programmer". However, you should not be surprised to
>>>> find very different thinking among the people frequenting comp.lang.c,
>>>> where this message is also cross-posted. Anyone bothering to monitor
>>>> comp.lang.c (and there's a fair number of us) can reasonably be
>>>> expected to choose the simplicity of C over the complexity of C++ in at
>>>> least some circumstances. You might question the validity of that
>>>> choice, but you can't expect such questions to go over very well in
>>>> that newsgroup.
>>>
>>> A one who works with and enjoys both languages, the statement "choose
>>> the simplicity of C over the complexity of C++" is one I have trouble
>>> with.  C is undoubtedly a simpler language, but the the solutions to
>>> many day to day problems are undoubtedly simpler in C++.
>>>
>>> So the choice is often "do I want the simple solution in a more complex
>>> language, or the more complex solution in a simple language?".
>>
>> That's also the problem I find with the "argument from simplicity",
>> as one could call it.
>>
>> When talking about C, making the simplicity argument is basically a
>> category error.
> 
> Almost all arguments from "category error" are themselves category
> errors. So "mu". I've seen Oxford dons make massive piles of steaming
> nonsense out of "category error".
> 
>> The argument is trying to appeal to the notion that
>> simpler higher-level languages (such as Lisp) are generally considered
>> better than overly complex languages. In those languages it is often
>> so that the same thing can be expressed in a much simpler and more
>> brief manner, and the result is much "leaner and cleaner" code than
>> in overly complicated languages. (For example the language specification
>> of Lisp is relatively short, yet the language itself is incredibly
>> expressive and powerful.)
>>
>> In other words, a simple language helps writing simple programs (that
>> are nevertheless very expressive.)
>>
> 
> No, the thing about lisp is that it is *interpretive*.
> 
>> However, in the case of C the "simplicity" is not actually a factor
>> that helps writing simple programs. On the contrary, the "simplicity"
>> of the language is actually a limiting factor. Rather than help, it
>> impedes the writing of simple programs, requiring many of even the
>> simplest tasks to have complex and error-prone implementations. It
>> often requires following strict coding conventions to avoid mistakes,
>> coding conventions that are completely unnecessary in truly simple
>> languages. Truly simple languages allow the programmer to concentrate
>> purely on the task at hand, without having to pay any attention to such
>> trivial and inconsequential matters as memory management and such.
> 
> C++ is much *worse* for memory management than is 'C' - in that
> the possibility of memory leaks goes up. Absent writing GUI code,
> it's entirely possible to write entire deployable systems that use no
> dynamic memory at all in 'C'. indeed, that's been the shop
> standard most places I have worked.

That assertion is questionable, if not completely nonsense.  After all, with 
C++ it is quite possible to write code without a single explicit call to 
new/delete, but it won't be simple to write equivalent C code without a 
single call to malloc/free.  And that's without even considering RAII.


<snip/>
>> C++ also offers many tools (in both native syntax and in the form of
>> the standard library) that makes many, many tasks a lot easier and
>> simpler than in C.
>>
> 
> To my eye, the solutions  there are uglier, and a choice like Tcl
> or Python makes C++ less interesting. Because interpreters provide
> a much better suite of "furniture".

You are free to implement any solution which is, to your eye, prettier.  The 
main point is that with C++ you already have a set of standard solutions at 
your disposal, which were already extensively tested and debugged.


<snip/>
>> Why would it matter to me
>> in the least bit if the language is large and requires a lot of
>> learning? That's completely inconsequential to me.
> 
> Just... wow. It's a *huge* problem. I'm not "into languages"
> to be into languages, I am into them to be able to operate on teams
> that produce deployable systems that work without causing anybody
> any problems.
> 
> A novice can really get 95% of everything they need to know
> about 'C' in a matter of months, while being productive
> under supervision. 

The problem with that assertion is that you are misrepresenting C and C++.  
While with C you are referring to essentially being exposed to the core 
language, as C's standard library is pretty limited, with C++ you are 
including everything plus the kitchen sink.  Meanwhile, you failed to take 
into account that C++ can be presented as an improper superset of C, which 
means that if you are able to get a newbie to know 95% of everything they 
need to know about C to be productive in a matter of months, then you can 
also achieve the exact same thing with C++.  Sure, some features won't be 
covered, but you don't need to use every bell and whistle provided by C++ to 
actually be productive.


> I am not sure there is a collection
> of ten people on the planet who , between them , know everything
> there is to know about C++.

That is completely irrelevant.  Who said you had to use every trick in the 
book to be able to do anything with C++?   It's quite possible to develop 
software with C++ while completely avoiding any number of features.



Rui Maciel

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

#19172

Rui Maciel wrote:
> Les Cargill wrote:
>
>> Juha Nieminen wrote:
>>> In comp.lang.c++ Ian Collins <ian-news@hotmail.com> wrote:
>>>>> I'm sure that's quite normal thinking for anyone who would label
>>>>> themselves a "C++ programmer". However, you should not be surprised to
>>>>> find very different thinking among the people frequenting comp.lang.c,
>>>>> where this message is also cross-posted. Anyone bothering to monitor
>>>>> comp.lang.c (and there's a fair number of us) can reasonably be
>>>>> expected to choose the simplicity of C over the complexity of C++ in at
>>>>> least some circumstances. You might question the validity of that
>>>>> choice, but you can't expect such questions to go over very well in
>>>>> that newsgroup.
>>>>
>>>> A one who works with and enjoys both languages, the statement "choose
>>>> the simplicity of C over the complexity of C++" is one I have trouble
>>>> with.  C is undoubtedly a simpler language, but the the solutions to
>>>> many day to day problems are undoubtedly simpler in C++.
>>>>
>>>> So the choice is often "do I want the simple solution in a more complex
>>>> language, or the more complex solution in a simple language?".
>>>
>>> That's also the problem I find with the "argument from simplicity",
>>> as one could call it.
>>>
>>> When talking about C, making the simplicity argument is basically a
>>> category error.
>>
>> Almost all arguments from "category error" are themselves category
>> errors. So "mu". I've seen Oxford dons make massive piles of steaming
>> nonsense out of "category error".
>>
>>> The argument is trying to appeal to the notion that
>>> simpler higher-level languages (such as Lisp) are generally considered
>>> better than overly complex languages. In those languages it is often
>>> so that the same thing can be expressed in a much simpler and more
>>> brief manner, and the result is much "leaner and cleaner" code than
>>> in overly complicated languages. (For example the language specification
>>> of Lisp is relatively short, yet the language itself is incredibly
>>> expressive and powerful.)
>>>
>>> In other words, a simple language helps writing simple programs (that
>>> are nevertheless very expressive.)
>>>
>>
>> No, the thing about lisp is that it is *interpretive*.
>>
>>> However, in the case of C the "simplicity" is not actually a factor
>>> that helps writing simple programs. On the contrary, the "simplicity"
>>> of the language is actually a limiting factor. Rather than help, it
>>> impedes the writing of simple programs, requiring many of even the
>>> simplest tasks to have complex and error-prone implementations. It
>>> often requires following strict coding conventions to avoid mistakes,
>>> coding conventions that are completely unnecessary in truly simple
>>> languages. Truly simple languages allow the programmer to concentrate
>>> purely on the task at hand, without having to pay any attention to such
>>> trivial and inconsequential matters as memory management and such.
>>
>> C++ is much *worse* for memory management than is 'C' - in that
>> the possibility of memory leaks goes up. Absent writing GUI code,
>> it's entirely possible to write entire deployable systems that use no
>> dynamic memory at all in 'C'. indeed, that's been the shop
>> standard most places I have worked.
>
> That assertion is questionable, if not completely nonsense.  After all, with
> C++ it is quite possible to write code without a single explicit call to
> new/delete, but it won't be simple to write equivalent C code without a
> single call to malloc/free.  And that's without even considering RAII.
>
>

Not *really*. See also ctors/dtors.

> <snip/>
>>> C++ also offers many tools (in both native syntax and in the form of
>>> the standard library) that makes many, many tasks a lot easier and
>>> simpler than in C.
>>>
>>
>> To my eye, the solutions  there are uglier, and a choice like Tcl
>> or Python makes C++ less interesting. Because interpreters provide
>> a much better suite of "furniture".
>
> You are free to implement any solution which is, to your eye, prettier.  The
> main point is that with C++ you already have a set of standard solutions at
> your disposal, which were already extensively tested and debugged.
>
>

C++ represents a middle ground, a suite of compromises. What I find
is that when you really do need a dynamic language, interpreters 
generally create less rash than compiled languages. When you
don't need a lot of dynamic behavior, something like 'C' seems
to fit better.

> <snip/>
>>> Why would it matter to me
>>> in the least bit if the language is large and requires a lot of
>>> learning? That's completely inconsequential to me.
>>
>> Just... wow. It's a *huge* problem. I'm not "into languages"
>> to be into languages, I am into them to be able to operate on teams
>> that produce deployable systems that work without causing anybody
>> any problems.
>>
>> A novice can really get 95% of everything they need to know
>> about 'C' in a matter of months, while being productive
>> under supervision.
>
> The problem with that assertion is that you are misrepresenting C and C++.
> While with C you are referring to essentially being exposed to the core
> language, as C's standard library is pretty limited,

A questionable argument at best... can't describe the weariness
caused by having to trot "sprintf()" out in the middle
of a large C++ project...

> with C++ you are
> including everything plus the kitchen sink.

That's exactly my point. <insert Stimpy and the shiny red button here>

>  Meanwhile, you failed to take
> into account that C++ can be presented as an improper superset of C, which
> means that if you are able to get a newbie to know 95% of everything they
> need to know about C to be productive in a matter of months, then you can
> also achieve the exact same thing with C++.

That's not consistent with direct observation, I fear.

> Sure, some features won't be
> covered, but you don't need to use every bell and whistle provided by C++ to
> actually be productive.
>
>

That doesn't keep people from going to every bell and whistle
because they can, and dragging others into the muck with them :)


>> I am not sure there is a collection
>> of ten people on the planet who , between them , know everything
>> there is to know about C++.
>
> That is completely irrelevant.

Whu? Really? Okay then.

>  Who said you had to use every trick in the
> book to be able to do anything with C++?   It's quite possible to develop
> software with C++ while completely avoiding any number of features.
>
>
>
> Rui Maciel
>

--
Les Cargill

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

#19177

On 10/22/12 07:47, Les Cargill wrote:
> Rui Maciel wrote:
>> Les Cargill wrote:
>>>
>>> C++ is much *worse* for memory management than is 'C' - in that
>>> the possibility of memory leaks goes up. Absent writing GUI code,
>>> it's entirely possible to write entire deployable systems that use no
>>> dynamic memory at all in 'C'. indeed, that's been the shop
>>> standard most places I have worked.
>>
>> That assertion is questionable, if not completely nonsense.  After all, with
>> C++ it is quite possible to write code without a single explicit call to
>> new/delete, but it won't be simple to write equivalent C code without a
>> single call to malloc/free.  And that's without even considering RAII.
>>
>
> Not *really*. See also ctors/dtors.

What have they got to do with C++ being worse than C for memory 
management?  Come on, no more sideshows, provide a real example.

-- 
Ian Collins

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

#19189

Les Cargill wrote:

> Rui Maciel wrote:
>> Les Cargill wrote:
>>
>>> Juha Nieminen wrote:
>>>> In comp.lang.c++ Ian Collins <ian-news@hotmail.com> wrote:
>>>>>> I'm sure that's quite normal thinking for anyone who would label
>>>>>> themselves a "C++ programmer". However, you should not be surprised
>>>>>> to find very different thinking among the people frequenting
>>>>>> comp.lang.c, where this message is also cross-posted. Anyone
>>>>>> bothering to monitor comp.lang.c (and there's a fair number of us)
>>>>>> can reasonably be expected to choose the simplicity of C over the
>>>>>> complexity of C++ in at least some circumstances. You might question
>>>>>> the validity of that choice, but you can't expect such questions to
>>>>>> go over very well in that newsgroup.
>>>>>
>>>>> A one who works with and enjoys both languages, the statement "choose
>>>>> the simplicity of C over the complexity of C++" is one I have trouble
>>>>> with.  C is undoubtedly a simpler language, but the the solutions to
>>>>> many day to day problems are undoubtedly simpler in C++.
>>>>>
>>>>> So the choice is often "do I want the simple solution in a more
>>>>> complex language, or the more complex solution in a simple language?".
>>>>
>>>> That's also the problem I find with the "argument from simplicity",
>>>> as one could call it.
>>>>
>>>> When talking about C, making the simplicity argument is basically a
>>>> category error.
>>>
>>> Almost all arguments from "category error" are themselves category
>>> errors. So "mu". I've seen Oxford dons make massive piles of steaming
>>> nonsense out of "category error".
>>>
>>>> The argument is trying to appeal to the notion that
>>>> simpler higher-level languages (such as Lisp) are generally considered
>>>> better than overly complex languages. In those languages it is often
>>>> so that the same thing can be expressed in a much simpler and more
>>>> brief manner, and the result is much "leaner and cleaner" code than
>>>> in overly complicated languages. (For example the language
>>>> specification of Lisp is relatively short, yet the language itself is
>>>> incredibly expressive and powerful.)
>>>>
>>>> In other words, a simple language helps writing simple programs (that
>>>> are nevertheless very expressive.)
>>>>
>>>
>>> No, the thing about lisp is that it is *interpretive*.
>>>
>>>> However, in the case of C the "simplicity" is not actually a factor
>>>> that helps writing simple programs. On the contrary, the "simplicity"
>>>> of the language is actually a limiting factor. Rather than help, it
>>>> impedes the writing of simple programs, requiring many of even the
>>>> simplest tasks to have complex and error-prone implementations. It
>>>> often requires following strict coding conventions to avoid mistakes,
>>>> coding conventions that are completely unnecessary in truly simple
>>>> languages. Truly simple languages allow the programmer to concentrate
>>>> purely on the task at hand, without having to pay any attention to such
>>>> trivial and inconsequential matters as memory management and such.
>>>
>>> C++ is much *worse* for memory management than is 'C' - in that
>>> the possibility of memory leaks goes up. Absent writing GUI code,
>>> it's entirely possible to write entire deployable systems that use no
>>> dynamic memory at all in 'C'. indeed, that's been the shop
>>> standard most places I have worked.
>>
>> That assertion is questionable, if not completely nonsense.  After all,
>> with C++ it is quite possible to write code without a single explicit
>> call to new/delete, but it won't be simple to write equivalent C code
>> without a
>> single call to malloc/free.  And that's without even considering RAII.
>>
>>
> 
> Not *really*. See also ctors/dtors.

I don't understand what you were trying to say.  Are you saying that the use 
of constructors and destructors forces someone to explicitly call 
new/delete?


<snip/>
>> with C++ you are
>> including everything plus the kitchen sink.
> 
> That's exactly my point. <insert Stimpy and the shiny red button here>
> 
>>  Meanwhile, you failed to take
>> into account that C++ can be presented as an improper superset of C,
>> which means that if you are able to get a newbie to know 95% of
>> everything they need to know about C to be productive in a matter of
>> months, then you can also achieve the exact same thing with C++.
> 
> That's not consistent with direct observation, I fear.

Your direct observations lead you to believe that it is impossible to write 
C++ code which is also C?


>> Sure, some features won't be
>> covered, but you don't need to use every bell and whistle provided by C++
>> to actually be productive.
>>
>>
> 
> That doesn't keep people from going to every bell and whistle
> because they can, and dragging others into the muck with them :)

That's not the programming language's fault.


>>> I am not sure there is a collection
>>> of ten people on the planet who , between them , know everything
>>> there is to know about C++.
>>
>> That is completely irrelevant.
> 
> Whu? Really? Okay then.

Yes, really.  There is no magical proficiency barrier nor any legal 
impediment that bars programmers from developing applications if their 
expertise level is below a certain level.  As it's the case with any 
technical field, excellent is nice to have, good is great, but good enough 
is nevertheless good.


Rui Maciel

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

#19194

Les Cargill <lcargill99@comcast.com> wrote:
> When you
> don't need a lot of dynamic behavior, something like 'C' seems
> to fit better.

There seems to be a really common misconception among many C advocates
that the only thing that the additional features offered by C++ are good
for is for managing dynamically allocated memory. This couldn't be farther
from the truth.

RAII is useful for things other than managing memory. For example, it can
be used to more easily close file handles and release mutex locks, making
the code simpler, safer and less error-prone, requiring less coding
conventions that exist solely to avoid those errors.

The very support for classes is in itself a big advantage over the raw
structs of C, even if you don't make any dynamic memory allocation at all.
It makes it easier to design your program modularly, to have compile-time
checks, and to make syntax simpler. Inheritance can also be useful even
when you don't need dynamic memory allocation.

Templates are a big one. Not only do they make many things simpler, they
can also make them more efficient. (For example, just compare the speed
of std::sort() compared to qsort(). The speed advantage of the former
comes thanks to the fact that it's a template function. Also, the former
is much easier to use than the latter.) And that's only scratching the
surface.

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

#19173

Rui Maciel <rui.maciel@gmail.com> wrote:.
[...]
> That is completely irrelevant.  Who said you had to use every trick in the 
> book to be able to do anything with C++?   It's quite possible to develop 
> software with C++ while completely avoiding any number of features.

Not if you have to work with existing code or in a team. And who does not?

Tobi

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

#19178

On 10/22/12 07:54, Tobias Müller wrote:
> Rui Maciel<rui.maciel@gmail.com>  wrote:.
> [...]
>> That is completely irrelevant.  Who said you had to use every trick in the
>> book to be able to do anything with C++?   It's quite possible to develop
>> software with C++ while completely avoiding any number of features.
>
> Not if you have to work with existing code or in a team. And who does not?

If you work in a team on a new project, the team agrees which features 
to use.  If you work on existing code, you get a free education...

-- 
Ian Collins

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

#19179

Ian Collins <ian-news@hotmail.com> wrote:
> If you work in a team on a new project, the team agrees which features to use.

But as a C++ programmer I would never agree on using only the C subset of
C++.
The complexity of C++ makes it more difficult to agree on a common subset
of features, because the level of knowledge may vary more.

> If you work on existing code, you get a free education...

And it raises the possibility to make things even worse because you're not
understanding what you're reading.

Tobi

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

#19181

On Sunday, 21 October 2012 23:07:49 UTC+3, Tobias Müller  wrote:
> Ian Collins <ian-news@hotmail.com> wrote:
> > If you work in a team on a new project, the team agrees which features to use.
> 
> But as a C++ programmer I would never agree on using only the C subset of
> C++.
> The complexity of C++ makes it more difficult to agree on a common subset
> of features, because the level of knowledge may vary more.

Lets look on meta-information that novice has to study to participate in team?
C++ coding standard is relatively long document. Everything else however
is several times as long and as crucial. How to set up working environment, what tools and frameworks and exactly what versions are used, where and how to put unit tests, how to use repositories, how to Doxygen-document the work, how
to use review boards and what and how to tell or not to tell in issue 
trackers etc. IOW defining the development process is lot more complex problem 
than specifying subset of C++ language used.

That information is what a team has to agree up for new project too. 
Lot of it is just loaned with small adjustments from other projects where
team members previously participated. The small fraction about what they
disagree they just vote on and done.  

> > If you work on existing code, you get a free education...
> 
> And it raises the possibility to make things even worse because you're not
> understanding what you're reading.

Modern software development can not be overly simple. What difference it 
does make if there is 200 000 lines of C code or 100 000 lines of C++ code?
It takes time to learn it. Same is with that little pile of wiki pages and
other documentation. Did not understand? Then your submission will not pass 
the review and on worst case it will be removed from repository. 

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

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

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

csiph-web