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

#19182

On 10/22/12 09:07, 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++.

You shouldn't have to.

> The complexity of C++ makes it more difficult to agree on a common subset
> of features, because the level of knowledge may vary more.

That is why a new team should discuss and agree which aspects of the 
language they will use before starting a project.  If the team is are 
new to C++, they should get some outside help early on.  One team I 
managed made the call after they had completed a training course, 
another after we discussed the benefits of various features to their 
project.

-- 
Ian Collins

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

#19188

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 point I made with the reference to C++'s C subset was that:
- If C is considered good for memory management, then C++, as it includes a 
subset of C, is also good for memory management when limited to that subset.
- If we add the remaining C++ features to C++'s C subset, the C++ 
programming language doesn't become worse for memory management.  It 
actually improves significantly, considering the addition of RAII.

Therefore, C++ is patently not worse than C with regards to memory 
management.


> The complexity of C++ makes it more difficult to agree on a common subset
> of features, because the level of knowledge may vary more.

It isn't that complex as you make it out to be.  I know of a company in the 
telecom industry which explicitly banned the use of exceptions and the STL 
in one of their C++ projects, the later in favour of a set of custom memory 
pools.  That policy was in the project's coding guidelines, and everyone who 
was added to the project was briefed about what was kosher and what was 
taboo.  There was nothing difficult about that.


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

You won't be reading idioms which were explicitly banned from a project.


Rui Maciel

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

#19191

Rui Maciel <rui.maciel@gmail.com> wrote:
> 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 point I made with the reference to C++'s C subset was that:
> - If C is considered good for memory management, then C++, as it includes a 
> subset of C, is also good for memory management when limited to that subset.
> - If we add the remaining C++ features to C++'s C subset, the C++ 
> programming language doesn't become worse for memory management.  It 
> actually improves significantly, considering the addition of RAII.
> 
> Therefore, C++ is patently not worse than C with regards to memory 
> management.

I was actually referring to the following (sorry for the bad quoting):
Rui Maciel <rui.maciel@gmail.com> wrote:
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++.  

>> The complexity of C++ makes it more difficult to agree on a common subset
>> of features, because the level of knowledge may vary more.
> 
> It isn't that complex as you make it out to be.  I know of a company in the 
> telecom industry which explicitly banned the use of exceptions and the STL 
> in one of their C++ projects, the later in favour of a set of custom memory 
> pools.  That policy was in the project's coding guidelines, and everyone who 
> was added to the project was briefed about what was kosher and what was 
> taboo.  There was nothing difficult about that.

We do something similar at work. I can live with it, but I still think we
would do better if we would just use what's already there.

If I could, I would use every single feature of C++ in my code, but I can
also see the downside of that

Tobi

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

#19203

On Mon, 2012-10-22, Rui Maciel wrote:
> 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 point I made with the reference to C++'s C subset was that:
> - If C is considered good for memory management, then C++, as it includes a 
> subset of C, is also good for memory management when limited to that subset.
> - If we add the remaining C++ features to C++'s C subset, the C++ 
> programming language doesn't become worse for memory management.  It 
> actually improves significantly, considering the addition of RAII.
>
> Therefore, C++ is patently not worse than C with regards to memory 
> management.
>
>> The complexity of C++ makes it more difficult to agree on a common subset
>> of features, because the level of knowledge may vary more.
>
> It isn't that complex as you make it out to be.  I know of a company in the 
> telecom industry which explicitly banned the use of exceptions and the STL 
> in one of their C++ projects, the later in favour of a set of custom memory 
> pools.  That policy was in the project's coding guidelines, and everyone who 
> was added to the project was briefed about what was kosher and what was 
> taboo.  There was nothing difficult about that.

Well ... I think I might prefer using C to working in C++ without the
standard library.  Unless its replacement was *really* good and
included drop-in replacements for things like iterators and algorithms.
And containers.

Weird guidelines aside, I have to partly agree with T.M. above -- it
/is/ harder to agree about C++.  One guy wants it to be C, another
wants it to be Smalltalk, a third wants it to be 1980s C++, I want it
to be modern C++ ...

It's worth the effort, though.

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

What's so bad about not understanding everything?  You go to the guy
who wrote it and ask him to explain.  If he can't, you might want to
rewrite it. Not any different from not immediately understanding other
things in the project, like an interface, an algorithm, or a
requirement.

> You won't be reading idioms which were explicitly banned from a project.

And you won't be reading many things which were not.  I've never seen
multiple inheritance -- not because it has been banned, but because
it's so rarely useful!  I've never seen deep template meta-
programming, because I don't work with people who are into that stuff.
And so on.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#19204

On Monday, 22 October 2012 23:52:35 UTC+3, Jorgen Grahn  wrote:
> On Mon, 2012-10-22, Rui Maciel wrote:
> > Tobias M�ller wrote:
> >> The complexity of C++ makes it more difficult to agree on a common subset
> >> of features, because the level of knowledge may vary more.
> >
> > It isn't that complex as you make it out to be.  I know of a company in the 
> > telecom industry which explicitly banned the use of exceptions and the STL 
> > in one of their C++ projects, the later in favour of a set of custom memory 
> > pools.  That policy was in the project's coding guidelines, and everyone who 
> > was added to the project was briefed about what was kosher and what was 
> > taboo.  There was nothing difficult about that.
> 
> Well ... I think I might prefer using C to working in C++ without the
> standard library.  Unless its replacement was *really* good and
> included drop-in replacements for things like iterators and algorithms.
> And containers.

You should try QT then. That framework really has choosen to have everything
of its own. Only thing that I do not see as very reasonable is that QString
is internally UTF-16 not UTF-8. Perhaps it is because Symbian and Windows (favorite OSs of Nokia) also favor UTF-16. Rest of it is quite well made and
also the development tools are quite nice.

> Weird guidelines aside, I have to partly agree with T.M. above -- it
> /is/ harder to agree about C++.  One guy wants it to be C, another
> wants it to be Smalltalk, a third wants it to be 1980s C++, I want it
> to be modern C++ ...
> 
> It's worth the effort, though.

That is anyway difficult but must be done when specialists of so very 
different background have to coooperate. Usually there should be one
lead developer - architect type per team and others should be supporting
and assisting members. Several disagreeing leaders has disasterous result
independent of goal and tools.

> > You won't be reading idioms which were explicitly banned from a project.
> 
> And you won't be reading many things which were not.  I've never seen
> multiple inheritance -- not because it has been banned, but because
> it's so rarely useful!  I've never seen deep template meta-
> programming, because I don't work with people who are into that stuff.
> And so on.

Every week I find something that i have never seen before. Past week example:

  class Power
  {
  private:
      // construct with factory methods
      Power( std::string const& typeCode );
  public:
      // factory method
      static Power fromValueAndUnitText( std::string const& text )
      {
          if ( text.size() < 2 )
          {
              // both value and unit can't fit
              return false; //<--- i was here like WTF WTF WTF  
          }
          // ...
          // etc.
      }
      // ...
      // etc.
  };

Compiled without any warnings. I did not even know before that 'false' 
converts so silently to 'std::string const&' on the compiler used in
that project.

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

#19208

On 10/23/12 Öö Tiib wrote:
[snip]
> Every week I find something that i have never seen before. Past week example:
>
>    class Power
>    {
>    private:
>        // construct with factory methods
>        Power( std::string const& typeCode );
>    public:
>        // factory method
>        static Power fromValueAndUnitText( std::string const& text )
>        {
>            if ( text.size() < 2 )
>            {
>                // both value and unit can't fit
>                return false; //<--- i was here like WTF WTF WTF
>            }
>            // ...
>            // etc.
>        }
>        // ...
>        // etc.
>    };
>
> Compiled without any warnings. I did not even know before that 'false'
> converts so silently to 'std::string const&' on the compiler used in
> that project.

That's what I hate about C++, too. My favourite programming language, 
Ada, would never allow such a thing to happen. It's a pity that implicit 
conversions cannot be turned off using a pragma/compiler switch.

Regards,
Stuart

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

#19216

On Tue, 2012-10-23, Stuart wrote:
> On 10/23/12 Öö Tiib wrote:
> [snip]
>> Every week I find something that i have never seen before. Past
>> week example:
>>
>>    class Power
>>    {
>>    private:
>>        // construct with factory methods
>>        Power( std::string const& typeCode );
>>    public:
>>        // factory method
>>        static Power fromValueAndUnitText( std::string const& text )
>>        {
>>            if ( text.size() < 2 )
>>            {
>>                // both value and unit can't fit
>>                return false; //<--- i was here like WTF WTF WTF
>>            }
>>            // ...
>>            // etc.
>>        }
>>        // ...
>>        // etc.
>>    };
>>
>> Compiled without any warnings. I did not even know before that 'false'
>> converts so silently to 'std::string const&' on the compiler used in
>> that project.

Ugh. And I can't even get gcc to warn about it, when I apply all my
favorite warning options.  I didn't expect that!

> That's what I hate about C++, too. My favourite programming language, 
> Ada, would never allow such a thing to happen. It's a pity that implicit 
> conversions cannot be turned off using a pragma/compiler switch.

It's not something you come across very often. Or at least I don't ...
In this case the first error is not to make Power::Power(const string&)
'explicit' -- so the "conversion" is a two step one.

I wouldn't mind a flag to warn about non-'explicit' constructors, and
like others have pointed out in the past, it would have been better if
the keyword had been 'implicit' instead and done the reverse job.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#19187

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 as a team and the team is told not to use feature X or Y, you, 
as a member of the team, don't use feature X or Y.  At least at work.  That 
was precisely my point.


Rui Maciel

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

#19268

On Oct 20, 7:45 pm, Les Cargill <lcargil...@comcast.com> wrote:
> Juha Nieminen wrote:
> > In comp.lang.c++ Ian Collins <ian-n...@hotmail.com> wrote:

<snip>

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

"category error" appear to cover what I'd been calling "type error".
"you're comparing oranges with orchards!" "C++ is a superset of C
because it's implemented in C"

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

no. Not since 1962. Common Lisp is required to be compiled. Stalin an
implementation of scheme (which is a Lisp) is one of the most
aggressive whole program optimising compilers known.

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

use RAII.

> Absent writing GUI code,
> it's entirely possible to write entire deployable systems that use no
> dynamic memory at all in 'C'. indeed, that's been the shop
> standard most places I have worked.

you can do this in C++ as well

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

really. RAII isn't hard. My problem is large C++ programs written by
people who've never heard of it...

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

I find writing the exception handling stuff in C hard work. And so do
other people. Which is why they often don't write it. If I'm using
Win32 (yes its old- I know, sue me) I check the return of every
function call. Tedious.

> > C++ also offers many tools (in both native syntax and in the form of
> > the standard library) that makes many, many tasks a lot easier and
> > simpler than in C.
>
> To my eye, the solutions  there are uglier, and a choice like Tcl
> or Python makes C++ less interesting. Because interpreters provide
> a much better suite of "furniture".
>
> > The typical arguments that C++ is so much larger and more complex
> > than C, and that it requires significantly more learning, ring quite
> > hollow to the experienced C++ programmer.

not to this one. Or maybe I'm not experienced enough.

> Because experienced programmer is experienced. The very basis for
> determining whether the language features are improvements is
> really complex and usually such discussions are simply people
> exposing biases.
>
> > Why would it matter to me
> > in the least bit if the language is large and requires a lot of
> > learning? That's completely inconsequential to me.
>
> Just... wow. It's a *huge* problem. I'm not "into languages"
> to be into languages, I am into them to be able to operate on teams
> that produce deployable systems that work without causing anybody
> any problems.
>
> A novice can really get 95% of everything they need to know
> about 'C' in a matter of months, while being productive
> under supervision. I am not sure there is a collection
> of ten people on the planet who , between them , know everything
> there is to know about C++.

just learning C's syntax and a few library calls still leaves you with
plenty of pifalls to fall into. People do actually manage to write
large complex systems in C++. And they work.

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

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

#19124

On 10/19/2012 07:13 PM, Ian Collins wrote:
...
> A one who works with and enjoys both languages, the statement "choose 
> the simplicity of C over the complexity of C++" is one I have trouble 
> with.  C is undoubtedly a simpler language, but the the solutions to 
> many day to day problems are undoubtedly simpler in C++.
> 
> So the choice is often "do I want the simple solution in a more complex 
> language, or the more complex solution in a simple language?".

I've seen C++ used to create complex solutions to simple problems. My
favorite example is use of the Singleton pattern to produce code with
precisely the same potential dangers as would occur if a global variable
was used, and much greater complexity. Because of course, global
variables are "evil", and use of a named "pattern" is "good".

Of course, overly complex solutions can also be created in C, and good
programmers will produce better solutions, regardless of the language
they use. However, I think the larger feature set of C++ does more to
encourage this particular type of bad programming than C does.
-- 
James Kuyper

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

#19128

On Saturday, 20 October 2012 16:06:03 UTC+3, James Kuyper  wrote:
> On 10/19/2012 07:13 PM, Ian Collins wrote:
> ...
> > A one who works with and enjoys both languages, the statement "choose 
> > the simplicity of C over the complexity of C++" is one I have trouble 
> > with.  C is undoubtedly a simpler language, but the the solutions to 
> > many day to day problems are undoubtedly simpler in C++.
> > 
> > So the choice is often "do I want the simple solution in a more complex 
> > language, or the more complex solution in a simple language?".
> 
> I've seen C++ used to create complex solutions to simple problems. My
> favorite example is use of the Singleton pattern to produce code with
> precisely the same potential dangers as would occur if a global variable
> was used, and much greater complexity. Because of course, global
> variables are "evil", and use of a named "pattern" is "good".

I think that Singleton design pattern is as terribly out of fashion as Waterfall
process pattern. I see more often stateless objects enwrapping access to common
state instead of Singletons or global state in C++.

> Of course, overly complex solutions can also be created in C, and good
> programmers will produce better solutions, regardless of the language
> they use. However, I think the larger feature set of C++ does more to
> encourage this particular type of bad programming than C does.

Trouble with C++ is cheapness to perceptually hide the costs of such bloat that you
describe. Expensive implicit conversion constructors, expensive overloaded operators and 
such. Nothing to do ... we just teach novices how not to ... and they learn.

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

#19149

In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote:
> I've seen C++ used to create complex solutions to simple problems.

And I have seen C++ used to create simple solutions to complex problems.
So what?

Just because a language *can* be used in a very sub-optimal manner, does
that mean the language is bad? C can certainly be used in a horribly
sub-optimal manner. Any language can.

The argument that there exist incompetent programmers is quite silly.

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

#19162

Juha Nieminen wrote:

> And I have seen C++ used to create simple solutions to complex problems.
> So what?
> 
> Just because a language *can* be used in a very sub-optimal manner, does
> that mean the language is bad? C can certainly be used in a horribly
> sub-optimal manner. Any language can.
> 
> The argument that there exist incompetent programmers is quite silly.

In addition, in some cases the incompetence lies in the people reading the 
code and criticizing it for some reason.  Design patterns sometimes appear 
to be needlessly complicated solutions to simple problems because the people 
reading the code don't understand what the real problems are and therefore 
are not in a position to understand what represents an adequate solution.  

More specifically, design patterns tend to be used to write code that may 
sacrifice the appearance of simplicity with simplicity with regards to other 
criteria, such as refactoring and extending.  Take, for example, the visitor 
pattern.  It may appear completely nonsensical to essentially implement 
member functions in separate classes.  If someone who is clueless looks at 
an implementation of a visitor pattern then they may criticize it for being 
a complex solution to a simple problem, because if someone needs to 
implement a new member function then all a person should do is implement a 
new member function.  Yet, the visitor pattern provides a way to add a new 
operation to a class without having to modify the class itself, along with a 
few other significant advantages such as handling these operations as 
operators.  To someone with a C backround, where functions are completely 
decoupled from objects, this advantage might not be exactly obvious, but 
just because someone isn't able to understand its purpose it doesn't mean it 
is needlessly complex; it just means that they faile to see the point.


Rui Maciel

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

#19166

On 10/21/2012 03:11 AM, Juha Nieminen wrote:
> In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote:
>> I've seen C++ used to create complex solutions to simple problems.
> 
> And I have seen C++ used to create simple solutions to complex problems.
> So what?
> 
> Just because a language *can* be used in a very sub-optimal manner, does
> that mean the language is bad? C can certainly be used in a horribly
> sub-optimal manner. Any language can.
> 
> The argument that there exist incompetent programmers is quite silly.

Why? They do exist, and appear to have generated a large fraction of all
of the code that gets written.
In any event, your summary of my argument dropped the key point - that
the greater complexity of C++ provides more temptations for incompetent
programmers to generate overly complex code than C does. Of course, that
doesn't prevent them from producing bad C code, but the bad C++ code
that I've seen has been much more complex to untangle than the bad C
code I've fixed.
-- 
James Kuyper

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

#19169

On Sunday, 21 October 2012 14:43:53 UTC+3, James Kuyper  wrote:
> On 10/21/2012 03:11 AM, Juha Nieminen wrote:
> > In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote:
> >> I've seen C++ used to create complex solutions to simple problems.
> > 
> > And I have seen C++ used to create simple solutions to complex problems.
> > So what?
> > 
> > Just because a language *can* be used in a very sub-optimal manner, does
> > that mean the language is bad? C can certainly be used in a horribly
> > sub-optimal manner. Any language can.
> > 
> > The argument that there exist incompetent programmers is quite silly.
> 
> Why? They do exist, and appear to have generated a large fraction of all
> of the code that gets written.

Incompetent programmers tend to produce negative results. Fixing their work
would take more hours of competent programmers than undoing and rewriting it
from scratch; it is "negative result". Same happens in C, C++, Java or PHP. So
the argument *is* silly. Competent specialists of C are no way happier about
incompetent programmers in their team than others. 

> In any event, your summary of my argument dropped the key point - that
> the greater complexity of C++ provides more temptations for incompetent
> programmers to generate overly complex code than C does. Of course, that
> doesn't prevent them from producing bad C code, but the bad C++ code
> that I've seen has been much more complex to untangle than the bad C
> code I've fixed.

If you take incompetent into team then that is future investment anyway. You
knowingly invest competent specialists time now in hope that after some months
he will gain competence and produce positive results.
 
The creater amount of features in C++ indeed gives more ways to do things
inefficiently and uglily but it also does provide more ways to do it simply,
efficiently and elegantly. C++ has more ways to separate modules. Not at
language level as yet but by availability of various open source C++ libraries.
Team of competent C++ programmers is therefore better armed to cooperate with
incompetent person, incompetent subcontractor or module provider.

If to come back to your initial global state versus global singleton argument
then competent have neither available. Incompetent can not therefore come and 
screw someting up globally by messing up that global state. 

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

#19195

In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote:
> In any event, your summary of my argument dropped the key point - that
> the greater complexity of C++ provides more temptations for incompetent
> programmers to generate overly complex code than C does.

My experience makes me disagree with the the last part. I would say that
the limiting "simplicity" of C causes many incompetent programmers to
create horrible code (much of which is caused *because* C is so archaic.)

Many C advocates argue that the "simplicity" of the language somehow
induces people to make straightforward, clear, simple and efficient
implementations. That's not what I see at all. Instead, what I see
quite often is really complicated code with tons of implied coding
conventions (that exist solely to address things like memory management
issues), and which is quite frankly horribly designed. Just take almost
any C project out there and study its source code. You'll easily find
400+ LOC functions (with little to no comments), that use lots of
repetition and/or are really obfuscated, oftentimes riddled with gotos,
and so on and so forth. They often also suffer from inefficiency because
the programmer did a "straightforward" job at implementing the task at
hand.

I'm not saying that *every* C program out there is like that. I'm saying
that quite a significant portion of them are. There's nothing in C that
would somehow induce or encourage people to make good code.

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

#19199

On Mon, Oct 22, 2012 at 08:13:31AM +0000, Juha Nieminen wrote:
> In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote:
> > In any event, your summary of my argument dropped the key point - that
> > the greater complexity of C++ provides more temptations for incompetent
> > programmers to generate overly complex code than C does.
> 
> My experience makes me disagree with the the last part. I would say that
> the limiting "simplicity" of C causes many incompetent programmers to
> create horrible code (much of which is caused *because* C is so archaic.)

C maps relatively cleanly to the architecture of the stored program
computer, at least for a non-SMP design.  The language doesn't try
to do a whole lot behind the scenes in making the language primitives
work, except in cases where native types are too small for the
language types, and then the math has to be simulated with those
narrower instructions.  In this sense it is conceptually minimalistic.
 
> Many C advocates argue that the "simplicity" of the language somehow
> induces people to make straightforward, clear, simple and efficient
> implementations. That's not what I see at all. Instead, what I see
> quite often is really complicated code with tons of implied coding
> conventions (that exist solely to address things like memory management
> issues), and which is quite frankly horribly designed. Just take almost
> any C project out there and study its source code. You'll easily find
> 400+ LOC functions (with little to no comments), that use lots of
> repetition and/or are really obfuscated, oftentimes riddled with gotos,

I like gotos.  They make the recovery from an error conditions much
easier to handle.  Some of the code I have written would suck utterly
if it were translated to a C that lacks the goto construct.  I was
once caught up in the "GOTO Considered Harmful" theology, and my code
suffered accordingly.  Judicious use of the statement is entirely
reasonable in C.

> and so on and so forth. They often also suffer from inefficiency because
> the programmer did a "straightforward" job at implementing the task at
> hand.

Coding is not a science and nor is it a serious engineering discipline
for the vast majority of programmers.  Most of the time, a programmer
of average skill will write something that works well enough for the
problem at hand.  Adding functionality or capabilities to such code
later may be difficult or a practical impossibility, but it may be
that the original writer was not given enough time, or expertise was
not available in the design phase, to build something extensible.

Part of the problem is the tool set.  C comes with a standard library
that encourages a certain style of coding.  If you want an event-
driven architecture, a different language is probably going to be a
better choice.

The language provides tools to make calculations with numbers,
control-flow constructs to make decisions based on the value of the
numbers, constructs to encourage a modular program design, and an
interface to the operating system for input/output, etc.  Everything
else is up to the programmer.

> I'm not saying that *every* C program out there is like that. I'm saying
> that quite a significant portion of them are. There's nothing in C that
> would somehow induce or encourage people to make good code.

It's not the job of the language to "induce" good code.  What is "good
code" anyhow?  Is good code easy to read and understand?  Is good code
merely correct?  Is good code elegant and pretty?

At any rate, good is a subjective quality.  What may be good to a
five-year old will be different from what an adult will consider as
good.  You seem to be saying that you know what good is when you see
it, but I doubt you can define what you mean in terms that everyone
will understand.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

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

#19201

On 10/22/2012 04:13 AM, Juha Nieminen wrote:
> In comp.lang.c++ James Kuyper <jameskuyper@verizon.net> wrote:
>> In any event, your summary of my argument dropped the key point - that
>> the greater complexity of C++ provides more temptations for incompetent
>> programmers to generate overly complex code than C does.
> 
> My experience makes me disagree with the the last part. I would say that
> the limiting "simplicity" of C causes many incompetent programmers to
> create horrible code (much of which is caused *because* C is so archaic.

I've seen incompetent C programmers produce horrible code, and I've seen
incompetent C++ programmers produce horrible code; except for the
comments I've already made about the matter (see below), I haven't
notice much difference between the two different types of horribleness.

From my previous message:
>> Of course, that
>> doesn't prevent them from producing bad C code, but the bad C++ code
>> that I've seen has been much more complex to untangle than the bad C
>> code I've fixed.

So our experiences have been quit different. There's not much more
useful that can be said about that.

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

#19160

James Kuyper wrote:

> I've seen C++ used to create complex solutions to simple problems. My
> favorite example is use of the Singleton pattern to produce code with
> precisely the same potential dangers as would occur if a global variable
> was used, and much greater complexity. Because of course, global
> variables are "evil", and use of a named "pattern" is "good".

I don't understand what you meant by that.  The singleton design pattern and 
global variables are two entirely different things.  It is not uncommon o 
declare singletons as global objects, and you cannot guarantee that an 
object type has a single object declared throughout the entire project just 
by declaring it a global object.


Rui Maciel

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

#19132

Juha Nieminen wrote:
> In comp.lang.c++ William Ahern <william@wilbur.25thandclement.com> wrote:
>> Reasonable people can disagree about the merits of C viz-a-viz C++. But
>> reasonable people cannot disagree that C is still very much in use in all
>> the same places that C++ is used, for both new and old code. It's not
>> relegated to device drivers and embedded work, by any stretch of the
>> imagination.
>
> It's just that in an environment where both C and C++ are equally
> viable options (which is most of the environments where you would
> want to use either one), most experienced C++ programmers can't think
> of any reason why they should limit themselves to C. Because, to be
> frank, that would be quite a serious limitation.
>

Unless you put some serious time on on non-C++ 'C', you will
think rather differently than someone who has. Path dependence
is path dependent.

> C++ might be big and have tons and tons of features, but once you become
> really experienced with it, it just becomes so much *esier* to do things
> with it than with C.

I really do not know about that. Just the general schism over string
types alone makes life much more difficult. The whole subject is
fraught with massive observer bias.

> Just the standard library alone makes life so much
> easier (no matter if you are just making a quick 50-line test program
> or a large 50k-line serious project.)
>


Or you get an old version of STL that's buggy and there's an observed 
problem that takes up to a *year* ( off and on - not continuous
pushing ) to resolve. Which you do by replacing an stl::map() with
a bleeding-edge string table in a 'C' fashion :)

Also, I once had a ... data structure that I built with a need
for associativity ( think arrays indexed by strings ) where it
was twice the code* and half the performance to use STL than
bash something out in 'C'. Oh, if STL had only had "foreach"
from the start....

*no, I am not going to specify how that figure was arrived at...

What we do is settle on classes of solutions, and stay there.

--
Les Cargill

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

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

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

csiph-web