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

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

Generally, are the programs written by C++ slower than written by C 10% ?

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

Contents

  Generally, are the programs written by C++ slower than written by C 10% ? KaiWen <wenkai1987@gmail.com> - 2011-09-01 01:41 -0700
    Re: Generally, are the programs written by C++ slower than written by C   10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-01 21:15 +1200
    Re: Generally, are the programs written by C++ slower than written by C 10% ? "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-09-01 11:48 +0200
      Re: Generally, are the programs written by C++ slower than written by C 10% ? Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-01 15:34 -0700
        Re: Generally, are the programs written by C++ slower than written by C 10% ? KaiWen <wenkai1987@gmail.com> - 2011-09-01 19:09 -0700
          Re: Generally, are the programs written by C++ slower than written by   C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-02 14:39 +1200
          Re: Generally, are the programs written by C++ slower than written by C 10% ? Krice <paulkp@mbnet.fi> - 2011-09-01 22:33 -0700
          Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-02 01:12 -0500
            Re: Generally, are the programs written by C++ slower than written by C 10% ? James Kanze <james.kanze@gmail.com> - 2011-09-03 15:25 -0700
              Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-04 01:34 -0500
                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-04 02:33 -0700
                Re: Generally, are the programs written by C++ slower than written by C 10% ? James Kanze <james.kanze@gmail.com> - 2011-09-04 11:00 -0700
          Re: Generally, are the programs written by C++ slower than written by C 10% ? Goran <goran.pusic@gmail.com> - 2011-09-01 23:23 -0700
            Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-02 03:00 -0700
              Re: Generally, are the programs written by C++ slower than written by C 10% ? Goran <goran.pusic@gmail.com> - 2011-09-02 09:39 -0700
            Re: Generally, are the programs written by C++ slower than written by C 10% ? Rui Maciel <rui.maciel@gmail.com> - 2011-09-02 12:44 +0100
          Re: Generally, are the programs written by C++ slower than written by C 10% ? Rui Maciel <rui.maciel@gmail.com> - 2011-09-02 09:59 +0100
            Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-02 11:25 -0700
          Re: Generally, are the programs written by C++ slower than written by C 10% ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-03 05:51 +0000
            Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-03 01:45 -0700
              Re: Generally, are the programs written by C++ slower than written   by C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-03 20:53 +1200
                Re: Generally, are the programs written by C++ slower than written   by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-03 10:49 -0700
                  Re: Generally, are the programs written by C++ slower than written     by C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-04 08:15 +1200
                    Re: Generally, are the programs written by C++ slower than written     by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-03 17:50 -0700
              Re: Generally, are the programs written by C++ slower than written by C 10% ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-03 16:28 +0000
                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-03 10:42 -0700
                  Re: Generally, are the programs written by C++ slower than written by C 10% ? "Bo Persson" <bop@gmb.dk> - 2011-09-04 11:34 +0200
                    Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-04 09:04 -0700
                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-04 18:04 +0000
                    Re: Generally, are the programs written by C++ slower than written by C 10% ? Keith H Duggar <duggar@alum.mit.edu> - 2011-09-04 18:44 -0700
                    Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-04 23:26 -0700
                      Re: Generally, are the programs written by C++ slower than written by C 10% ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-05 08:01 +0000
                        Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-05 11:45 -0700
                          Re: Generally, are the programs written by C++ slower than written by C 10% ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-06 06:30 +0000
                            Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-06 07:22 -0700
                          Re: Generally, are the programs written by C++ slower than written by C 10% ? Miles Bader <miles@gnu.org> - 2011-09-06 16:25 +0900
                            Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-06 07:14 -0700
                              Re: Generally, are the programs written by C++ slower than written by C 10% ? Miles Bader <miles@gnu.org> - 2011-09-07 12:28 +0900
                                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-07 16:49 -0700
                                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Noah Roberts <roberts.noah@gmail.com> - 2011-09-07 18:45 -0700
                                    Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-08 15:56 -0700
              Re: Generally, are the programs written by C++ slower than written by C 10% ? James Kanze <james.kanze@gmail.com> - 2011-09-03 15:32 -0700
                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-03 19:16 -0700
              Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-05 00:28 -0700
                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-05 12:34 -0700
                  Re: Generally, are the programs written by C++ slower than written   by C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-06 07:51 +1200
                    Re: Generally, are the programs written by C++ slower than written   by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-05 14:06 -0700
                      Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-06 00:32 -0700
                        Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-06 07:33 -0700
                          Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-07 02:52 -0700
                            Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-08 16:24 -0700
                              Re: Generally, are the programs written by C++ slower than written   by C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-09 11:38 +1200
                                Re: Generally, are the programs written by C++ slower than written   by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-08 21:39 -0700
                                  Re: Generally, are the programs written by C++ slower than written     by C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-09 19:01 +1200
                                    Re: Generally, are the programs written by C++ slower than written     by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-09 02:45 -0700
                                    Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-09 03:23 -0700
                                    Re: Generally, are the programs written by C++ slower than written     by C 10% ? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-14 23:12 +0000
                              Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-09 02:40 -0700
                                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-09 11:19 -0700
                                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-09 15:42 -0500
                                    Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-09 14:24 -0700
                                      Re: Generally, are the programs written by C++ slower than written by C 10% ? Noah Roberts <roberts.noah@gmail.com> - 2011-09-09 18:22 -0700
                                        Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-10 10:11 -0700
                                          Re: Generally, are the programs written by C++ slower than written by C 10% ? Noah Roberts <roberts.noah@gmail.com> - 2011-09-10 10:54 -0700
                                            Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-10 14:28 -0700
                                              Re: Generally, are the programs written by C++ slower than written by C 10% ? Miles Bader <miles@gnu.org> - 2011-09-11 12:29 +0900
                                                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-11 00:45 -0700
                                                Re: Generally, are the programs written by C++ slower than written by C 10% ? Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-12 00:39 -0700
                                                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Miles Bader <miles@gnu.org> - 2011-09-12 18:06 +0900
                                                    Re: Generally, are the programs written by C++ slower than written by C 10% ? Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-12 16:46 -0700
                                                      Re: Generally, are the programs written by C++ slower than written by C 10% ? Miles Bader <miles@gnu.org> - 2011-09-13 10:20 +0900
                                                        Re: Generally, are the programs written by C++ slower than written by C 10% ? Joshua Maurice <joshuamaurice@gmail.com> - 2011-09-13 13:16 -0700
                                              Re: Generally, are the programs written by C++ slower than written by C 10% ? Nobody <nobody@nowhere.com> - 2011-09-11 04:53 +0100
                                                Re: Generally, are the programs written by C++ slower than written by C 10% ? Miles Bader <miles@gnu.org> - 2011-09-11 14:51 +0900
                                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-10 07:46 -0700
                    Re: Generally, are the programs written by C++ slower than written by C 10% ? KaiWen <wenkai1987@gmail.com> - 2011-09-06 03:10 -0700
                      Re: Generally, are the programs written by C++ slower than written by   C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-06 22:50 +1200
                        Re: Generally, are the programs written by C++ slower than written by C 10% ? KaiWen <wenkai1987@gmail.com> - 2011-09-06 04:48 -0700
                          Re: Generally, are the programs written by C++ slower than written by C 10% ? yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-07 09:45 +0000
                            Re: Generally, are the programs written by C++ slower than written by   C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-07 21:51 +1200
                            Re: Generally, are the programs written by C++ slower than written by C 10% ? KaiWen <wenkai1987@gmail.com> - 2011-09-08 00:15 -0700
                              Re: Generally, are the programs written by C++ slower than written by C 10% ? yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-08 12:14 +0000
                                Re: Generally, are the programs written by C++ slower than written by C 10% ? KaiWen <wenkai1987@gmail.com> - 2011-09-08 07:14 -0700
                        Re: Generally, are the programs written by C++ slower than written by C 10% ? Asger-P <junk@asger-p.dk> - 2011-09-06 13:52 +0200
                      Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-06 11:47 -0500
                        Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-06 11:50 -0500
                        Re: Generally, are the programs written by C++ slower than written by C 10% ? Asger-P <junk@asger-p.dk> - 2011-09-06 21:04 +0200
                          Re: Generally, are the programs written by C++ slower than written by C 10% ? Leigh Johnston <leigh@i42.co.uk> - 2011-09-06 20:37 +0100
                            Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-06 15:10 -0500
                              Re: Generally, are the programs written by C++ slower than written by C 10% ? Leigh Johnston <leigh@i42.co.uk> - 2011-09-06 21:14 +0100
                              Re: Generally, are the programs written by C++ slower than written by C 10% ? Asger-P <junk@asger-p.dk> - 2011-09-07 00:40 +0200
                                Re: Generally, are the programs written by C++ slower than written by C 10% ? Leigh Johnston <leigh@i42.co.uk> - 2011-09-06 23:59 +0100
                                Re: Generally, are the programs written by C++ slower than written by C 10% ? Noah Roberts <roberts.noah@gmail.com> - 2011-09-06 16:26 -0700
                          Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-06 14:55 -0500
                            Re: Generally, are the programs written by C++ slower than written by C 10% ? Asger-P <junk@asger-p.dk> - 2011-09-07 00:51 +0200
                              Re: Generally, are the programs written by C++ slower than written by C 10% ? Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-06 23:29 -0500
                                Re: Generally, are the programs written by C++ slower than written by C 10% ? Asger-P <junk@asger-p.dk> - 2011-09-07 09:06 +0200
                                  Re: Generally, are the programs written by C++ slower than written by   C 10% ? Ian Collins <ian-news@hotmail.com> - 2011-09-07 19:09 +1200
                                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Nobody <nobody@nowhere.com> - 2011-09-07 13:19 +0100
                                    Re: Generally, are the programs written by C++ slower than written by C 10% ? Juha Nieminen <nospam@thanks.invalid> - 2011-09-07 13:01 +0000
                                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Rui Maciel <rui.maciel@gmail.com> - 2011-09-07 14:26 +0100
                                    Re: Generally, are the programs written by C++ slower than written by C 10% ? Asger-P <junk@asger-p.dk> - 2011-09-07 15:49 +0200
                                  Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-08 22:49 -0700
                                    Re: Generally, are the programs written by C++ slower than written by C 10% ? Miles Bader <miles@gnu.org> - 2011-09-09 15:25 +0900
                                      Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-09 02:50 -0700
                                        Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-09 03:26 -0700
                                      Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-09 03:25 -0700
                  Re: Generally, are the programs written by C++ slower than written by C 10% ? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-06 00:24 -0700
              Re: Generally, are the programs written by C++ slower than written by C 10% ? yatremblay@bel1lin202.(none) (Yannick Tremblay) - 2011-09-06 13:57 +0000
                Re: Generally, are the programs written by C++ slower than written by C 10% ? BGB <cr88192@hotmail.com> - 2011-09-06 08:18 -0700
          Re: Generally, are the programs written by C++ slower than written by C 10% ? Nobody <nobody@nowhere.com> - 2011-09-03 08:34 +0100
    Re: Generally, are the programs written by C++ slower than written by C 10% ? "A" <a@a.a> - 2011-09-01 11:50 +0200
    Re: Generally, are the programs written by C++ slower than written by C 10% ? Rui Maciel <rui.maciel@gmail.com> - 2011-09-01 10:53 +0100
    Re: Generally, are the programs written by C++ slower than written by C 10% ? James Kanze <james.kanze@gmail.com> - 2011-09-03 15:11 -0700

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

#9688 — Re: Generally, are the programs written by C++ slower than written by C 10% ?

On 09/ 3/11 08:45 PM, BGB wrote:
> On 9/2/2011 10:51 PM, Juha Nieminen wrote:
>> KaiWen<wenkai1987@gmail.com>   wrote:
>>> 2. In runtime, the speed of the program written by C++ is<= the same
>>>     program written by C
>>
>>     Actually many equivalent constructs in C and C++ are such that it's
>> the exact opposite: C++ is significantly faster than C.
>>
>>     Just two simple examples are qsort() vs. std::sort() , and strlen()
>> vs std::string::length(). Especially in the first case it's precisely
>> the language features that help the compiler make a faster executable.
>
> this again, comes down to coding practices...
>
>
> also, just how many people really use "qsort()" anyways?...
> IME, it is more often one of those largely forgotten functions (it is
> there, but more often people write out their own sort logic manually).
>
> (actually, it seems to be fairly common practice in C land for people to
> largely ignore much of the standard library, and to write their own
> logic for doing things).

That says it all really, C++ programmers don't have to.

-- 
Ian Collins

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

#9698 — Re: Generally, are the programs written by C++ slower than written by C 10% ?

On 9/3/2011 1:53 AM, Ian Collins wrote:
> On 09/ 3/11 08:45 PM, BGB wrote:
>> On 9/2/2011 10:51 PM, Juha Nieminen wrote:
>>> KaiWen<wenkai1987@gmail.com> wrote:
>>>> 2. In runtime, the speed of the program written by C++ is<= the same
>>>> program written by C
>>>
>>> Actually many equivalent constructs in C and C++ are such that it's
>>> the exact opposite: C++ is significantly faster than C.
>>>
>>> Just two simple examples are qsort() vs. std::sort() , and strlen()
>>> vs std::string::length(). Especially in the first case it's precisely
>>> the language features that help the compiler make a faster executable.
>>
>> this again, comes down to coding practices...
>>
>>
>> also, just how many people really use "qsort()" anyways?...
>> IME, it is more often one of those largely forgotten functions (it is
>> there, but more often people write out their own sort logic manually).
>>
>> (actually, it seems to be fairly common practice in C land for people to
>> largely ignore much of the standard library, and to write their own
>> logic for doing things).
>
> That says it all really, C++ programmers don't have to.
>

it is a choice though, and probably most C programmers don't mind so 
much, which is why they do it.

it is possible it may be as much a stylistic/idiomatic/... conflict as a 
language one.


for example, I use C a lot mostly because I have concerns like:
being able to parse and analyze the source code with custom written tools;
being able to have a reasonably consistent ABI (for all my ASM/... to 
interface with);
being able to interface easily between my native code and my scripting 
language;
...


if another person doesn't have these concerns, and may well be more 
motivated by saving a little effort or being able to more readily use 
higher-level abstractions, then using C++ may make a lot more sense for 
them.

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

#9699 — Re: Generally, are the programs written by C++ slower than written by C 10% ?

On 09/ 4/11 05:49 AM, BGB wrote:
> On 9/3/2011 1:53 AM, Ian Collins wrote:
>> On 09/ 3/11 08:45 PM, BGB wrote:
>>>
>>> also, just how many people really use "qsort()" anyways?...
>>> IME, it is more often one of those largely forgotten functions (it is
>>> there, but more often people write out their own sort logic manually).
>>>
>>> (actually, it seems to be fairly common practice in C land for people to
>>> largely ignore much of the standard library, and to write their own
>>> logic for doing things).
>>
>> That says it all really, C++ programmers don't have to.
>>
>
> it is a choice though, and probably most C programmers don't mind so
> much, which is why they do it.

Or they are forced to in order to get decent performance.

> it is possible it may be as much a stylistic/idiomatic/... conflict as a
> language one.
>
> for example, I use C a lot mostly because I have concerns like:
> being able to parse and analyze the source code with custom written tools;
> being able to have a reasonably consistent ABI (for all my ASM/... to
> interface with);
> being able to interface easily between my native code and my scripting
> language;
> ....

That's what C++ has extern "C" for.  I've written PHP extensions in C++.

-- 
Ian Collins

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

#9719 — Re: Generally, are the programs written by C++ slower than written by C 10% ?

On 9/3/2011 1:15 PM, Ian Collins wrote:
> On 09/ 4/11 05:49 AM, BGB wrote:
>> On 9/3/2011 1:53 AM, Ian Collins wrote:
>>> On 09/ 3/11 08:45 PM, BGB wrote:
>>>>
>>>> also, just how many people really use "qsort()" anyways?...
>>>> IME, it is more often one of those largely forgotten functions (it is
>>>> there, but more often people write out their own sort logic manually).
>>>>
>>>> (actually, it seems to be fairly common practice in C land for
>>>> people to
>>>> largely ignore much of the standard library, and to write their own
>>>> logic for doing things).
>>>
>>> That says it all really, C++ programmers don't have to.
>>>
>>
>> it is a choice though, and probably most C programmers don't mind so
>> much, which is why they do it.
>
> Or they are forced to in order to get decent performance.
>
>> it is possible it may be as much a stylistic/idiomatic/... conflict as a
>> language one.
>>
>> for example, I use C a lot mostly because I have concerns like:
>> being able to parse and analyze the source code with custom written
>> tools;
>> being able to have a reasonably consistent ABI (for all my ASM/... to
>> interface with);
>> being able to interface easily between my native code and my scripting
>> language;
>> ....
>
> That's what C++ has extern "C" for. I've written PHP extensions in C++.
>

yes, but this is only really more convenient (than just using C) if one 
is doing a decent amount of logic code in C++, rather than the fairly 
common case where the library is often mostly thin wrapper functionality 
passing control off somewhere else (to other library code, to another 
library, or to the OS), or performing at most trivial operations (the 
gains in language usability in this case may not necessarily outweigh 
some of the added inconveniences).


granted, yes, I have used 'extern "C"' in a few places, but typically it 
is a minority of the code as a whole.

for example, for my physics library I did use C++ and 'extern "C"', but 
a physics library is a special case in that it has lots of very 
dense/involved logic code, and a reasonably "low surface area" API (as 
in, most of the complexity of the library is in its internal logic, 
rather than the number and variety of API functions one is providing).

in this sort of case, C++ makes a lot more sense.

where it makes not as much sense though is the far more typical:
void FOO_FooFunc(int x)
     { BAR_BarFunc(x, 0); }
style of code...


however, if the internal logic code is in C++ and uses OOP, then one may 
end up with a lot of:
void FOO_Func(fooObject obj, int x)
     { ((FooObject *)obj)->func(x); }

granted, it is roughly a similar case for providing wrapper classes so 
that C++ code can have a class-based interface to some pieces of library 
functionality (even if, albeit, the abstraction will start to fall apart 
about as soon as one wants to overload the class and wonders why their 
new fields/methods/... don't work as expected).


or such...

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

#9695

BGB <cr88192@hotmail.com> wrote:
> also, just how many people really use "qsort()" anyways?...
> IME, it is more often one of those largely forgotten functions (it is 
> there, but more often people write out their own sort logic manually).
> 
> (actually, it seems to be fairly common practice in C land for people to 
> largely ignore much of the standard library, and to write their own 
> logic for doing things).

  This is exactly one of the reasons why I dislike the language so much.
The C standard library does not offer many useful tools, and the reason
for this is that the language doesn't lend itself for this. It's very
hard to implement any generic data containers or algorithms which would
be efficient, and because they will always have some compromises,
inefficiencies or other defects, most C programmers end up not using
them anyways.

  "Nobody uses qsort() anyways" is just the epitome of this. Contrast it
with std::sort(), which is actually a really decent general use sorting
function, and in the vast majority of cases it's pretty useful, and it's
very commonly used in C++ in most situations where sorting is needed.
Moreover, it's very easy to use (much easier than qsort()).

> it is also not clear that std::string would be, in general, faster, and 
> having an O(1) ability to fetch the length may turn out to be moot if 
> most other operations tend towards being more expensive. not that 
> worrying about micro-optimizing string operations is usually all that 
> relevant though anyways.

  Optimizing from O(n) to O(1) is far from "micro-optimizing". (And it's
not like you have to do anything in your code to achieve this.)

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

#9697

On 9/3/2011 9:28 AM, Juha Nieminen wrote:
> BGB<cr88192@hotmail.com>  wrote:
>> also, just how many people really use "qsort()" anyways?...
>> IME, it is more often one of those largely forgotten functions (it is
>> there, but more often people write out their own sort logic manually).
>>
>> (actually, it seems to be fairly common practice in C land for people to
>> largely ignore much of the standard library, and to write their own
>> logic for doing things).
>
>    This is exactly one of the reasons why I dislike the language so much.
> The C standard library does not offer many useful tools, and the reason
> for this is that the language doesn't lend itself for this. It's very
> hard to implement any generic data containers or algorithms which would
> be efficient, and because they will always have some compromises,
> inefficiencies or other defects, most C programmers end up not using
> them anyways.
>
>    "Nobody uses qsort() anyways" is just the epitome of this. Contrast it
> with std::sort(), which is actually a really decent general use sorting
> function, and in the vast majority of cases it's pretty useful, and it's
> very commonly used in C++ in most situations where sorting is needed.
> Moreover, it's very easy to use (much easier than qsort()).
>

however, avoiding writing little bits of code is not nearly so high on 
many peoples' priority list.


>> it is also not clear that std::string would be, in general, faster, and
>> having an O(1) ability to fetch the length may turn out to be moot if
>> most other operations tend towards being more expensive. not that
>> worrying about micro-optimizing string operations is usually all that
>> relevant though anyways.
>
>    Optimizing from O(n) to O(1) is far from "micro-optimizing". (And it's
> not like you have to do anything in your code to achieve this.)

except when n is usually sufficiently small as to be ignorable...

how long is a typical string on which one may use strlen?...
maybe 3-20 characters...

given the compiler will typically replace it with something like "repnz 
scasb" anyways, it is not usually a big deal.

long strings tend to be fairly rare in practice, and are usually the 
result of something like reading in a text file as a single large string 
(but, in this case, it is typically processed by being broken down into 
lines or tokens, each of which tends to be much shorter).


more commonly though, string code does not use strlen, but is often 
implemented more directly via good old while loops and character 
operations, and one knows when the string is used up by having run into 
the terminator:
s=str;
while(*s)
{
     ...
}


another fairly common idiom(for character-driven logic) is:
while(*s)
{
     switch(*s++)
     {
     ...
     }
}

and so on...

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

#9726

BGB wrote:
> On 9/3/2011 9:28 AM, Juha Nieminen wrote:
>> BGB<cr88192@hotmail.com>  wrote:
>>> also, just how many people really use "qsort()" anyways?...
>>> IME, it is more often one of those largely forgotten functions
>>> (it is there, but more often people write out their own sort
>>> logic manually). (actually, it seems to be fairly common practice 
>>> in C land for
>>> people to largely ignore much of the standard library, and to
>>> write their own logic for doing things).
>>
>>    This is exactly one of the reasons why I dislike the language
>> so much. The C standard library does not offer many useful tools,
>> and the reason for this is that the language doesn't lend itself
>> for this. It's very hard to implement any generic data containers
>> or algorithms which would be efficient, and because they will
>> always have some compromises, inefficiencies or other defects,
>> most C programmers end up not using them anyways.
>>
>>    "Nobody uses qsort() anyways" is just the epitome of this.
>> Contrast it with std::sort(), which is actually a really decent
>> general use sorting function, and in the vast majority of cases
>> it's pretty useful, and it's very commonly used in C++ in most
>> situations where sorting is needed. Moreover, it's very easy to
>> use (much easier than qsort()).
>
> however, avoiding writing little bits of code is not nearly so high
> on many peoples' priority list.
>
>
>>> it is also not clear that std::string would be, in general,
>>> faster, and having an O(1) ability to fetch the length may turn
>>> out to be moot if most other operations tend towards being more
>>> expensive. not that worrying about micro-optimizing string
>>> operations is usually all that relevant though anyways.
>>
>>    Optimizing from O(n) to O(1) is far from "micro-optimizing".
>> (And it's not like you have to do anything in your code to achieve
>> this.)
>
> except when n is usually sufficiently small as to be ignorable...
>
> how long is a typical string on which one may use strlen?...
> maybe 3-20 characters...
>
> given the compiler will typically replace it with something like
> "repnz scasb" anyways, it is not usually a big deal.
>

Ok, so being 10% slower or faster isn't that important after all?


Bo Persson

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

#9736

On 9/4/2011 2:34 AM, Bo Persson wrote:
> BGB wrote:
>> On 9/3/2011 9:28 AM, Juha Nieminen wrote:
>>> BGB<cr88192@hotmail.com>   wrote:
>>>> also, just how many people really use "qsort()" anyways?...
>>>> IME, it is more often one of those largely forgotten functions
>>>> (it is there, but more often people write out their own sort
>>>> logic manually). (actually, it seems to be fairly common practice
>>>> in C land for
>>>> people to largely ignore much of the standard library, and to
>>>> write their own logic for doing things).
>>>
>>>     This is exactly one of the reasons why I dislike the language
>>> so much. The C standard library does not offer many useful tools,
>>> and the reason for this is that the language doesn't lend itself
>>> for this. It's very hard to implement any generic data containers
>>> or algorithms which would be efficient, and because they will
>>> always have some compromises, inefficiencies or other defects,
>>> most C programmers end up not using them anyways.
>>>
>>>     "Nobody uses qsort() anyways" is just the epitome of this.
>>> Contrast it with std::sort(), which is actually a really decent
>>> general use sorting function, and in the vast majority of cases
>>> it's pretty useful, and it's very commonly used in C++ in most
>>> situations where sorting is needed. Moreover, it's very easy to
>>> use (much easier than qsort()).
>>
>> however, avoiding writing little bits of code is not nearly so high
>> on many peoples' priority list.
>>
>>
>>>> it is also not clear that std::string would be, in general,
>>>> faster, and having an O(1) ability to fetch the length may turn
>>>> out to be moot if most other operations tend towards being more
>>>> expensive. not that worrying about micro-optimizing string
>>>> operations is usually all that relevant though anyways.
>>>
>>>     Optimizing from O(n) to O(1) is far from "micro-optimizing".
>>> (And it's not like you have to do anything in your code to achieve
>>> this.)
>>
>> except when n is usually sufficiently small as to be ignorable...
>>
>> how long is a typical string on which one may use strlen?...
>> maybe 3-20 characters...
>>
>> given the compiler will typically replace it with something like
>> "repnz scasb" anyways, it is not usually a big deal.
>>
>
> Ok, so being 10% slower or faster isn't that important after all?
>

not usually.


sometimes, it may well also be preferable to intern all of ones strings 
into a strings table, which is one case where null terminated strings 
work fairly well (the strings may be packed end-to-end in a reasonably 
memory-compact manner).

interned string types may be itself a significant use-case FWIW (along 
with UTF-8).


it is also fairly common, OTOH, for people so pass std::string objects 
by-value, which may in turn eat a lot of cycles simply copying the 
things around.


so, it can probably go either way.


probably far more significant may well be ones' choice of compiler and 
compiler settings, say code compiled with "/O2 /Oi /Oy" is different 
than "/Z7 /ZI /Ge"

nevermind if someone throws a "/clr:pure" or similar in the mix...

or, in GCC terms: "-O3" vs "-g -pg" or similar.


these types of options often have a more notable effect on overall 
performance.

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

#9739

BGB <cr88192@hotmail.com> wrote:
>>    "Nobody uses qsort() anyways" is just the epitome of this. Contrast it
>> with std::sort(), which is actually a really decent general use sorting
>> function, and in the vast majority of cases it's pretty useful, and it's
>> very commonly used in C++ in most situations where sorting is needed.
>> Moreover, it's very easy to use (much easier than qsort()).
>>
> 
> however, avoiding writing little bits of code is not nearly so high on 
> many peoples' priority list.

  Implementing a fast comparison-based sort function which is efficient
with all possible inputs isn't just a "little bit of code". It's actually
pretty complicated. (Quicksort is a relatively short algorithm, although
not many people can implement correctly it on the spot, without looking
somewhere the details. However, quicksort has worst-case scenarios that
make it extremely inefficient. To make it efficient in all cases you need
to use optimizations which are much more laborious to implement. Or use
some other sorting algorithm, which will either be slower than quicksort
(such as heap sort) or consume a lot more memory (such as merge sort).)

  Doing a binary search on a sorted array, while extremely small piece
of code, is surprisingly hard to get correct on-the-spot. I remember a
study that showed that something like over half of experienced professional
programmers implemented it incorrectly when they couldn't look for a
reference. (Off-by-one errors can be pretty annoying.)

  When you need a more complex algorithm or data container, the amount
of work can be daunting. For example implementing a balanced binary tree
is far from trivial.

  Anyways, why should one have to write algorithms always from scratch?
If I want to sort an array, I don't want to write a sorting algorithm each
time, no matter if it takes just three lines of code. There's no need.
There *shouldn't* be no need.

  In fact, it's not just a question of convenience. It's a question of
code correctness. When the algorithm implementation has been tested for
years by millions of people, you can be pretty certain that it's correct.
If you implement it yourself, there's a good chance that there will be a
bug that might not be immediately apparent, and might kick in unexpectedly.

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

#9745

On Sep 4, 2:04 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> BGB <cr88...@hotmail.com> wrote:
> >>    "Nobody uses qsort() anyways" is just the epitome of this. Contrast it
> >> with std::sort(), which is actually a really decent general use sorting
> >> function, and in the vast majority of cases it's pretty useful, and it's
> >> very commonly used in C++ in most situations where sorting is needed.
> >> Moreover, it's very easy to use (much easier than qsort()).
>
> > however, avoiding writing little bits of code is not nearly so high on
> > many peoples' priority list.
>
>   Implementing a fast comparison-based sort function which is efficient
> with all possible inputs isn't just a "little bit of code". It's actually
> pretty complicated.
>
> [snip sort details]
>
>   Anyways, why should one have to write algorithms always from scratch?
> If I want to sort an array, I don't want to write a sorting algorithm each
> time, no matter if it takes just three lines of code. There's no need.
> There *shouldn't* be no need.
>
>   In fact, it's not just a question of convenience. It's a question of
> code correctness. When the algorithm implementation has been tested for
> years by millions of people, you can be pretty certain that it's correct.
> If you implement it yourself, there's a good chance that there will be a
> bug that might not be immediately apparent, and might kick in unexpectedly.

Furthermore code reuse is the only remaining practical way to
dramatically increase programmer productivity beyond what has
already been achieved with language improvement. The language
that will win the future is the one that best supports coding
modular easily reusable /high performance/ libraries. The C++
template based generic programming model, as ugly as it might
be, has hybridized with other C++ features to yield a strange
crossbreed that is proving revolutionary is this regard.

KHD

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

#9746

On 9/4/2011 11:04 AM, Juha Nieminen wrote:
> BGB<cr88192@hotmail.com>  wrote:
>>>     "Nobody uses qsort() anyways" is just the epitome of this. Contrast it
>>> with std::sort(), which is actually a really decent general use sorting
>>> function, and in the vast majority of cases it's pretty useful, and it's
>>> very commonly used in C++ in most situations where sorting is needed.
>>> Moreover, it's very easy to use (much easier than qsort()).
>>>
>>
>> however, avoiding writing little bits of code is not nearly so high on
>> many peoples' priority list.
>
>    Implementing a fast comparison-based sort function which is efficient
> with all possible inputs isn't just a "little bit of code". It's actually
> pretty complicated. (Quicksort is a relatively short algorithm, although
> not many people can implement correctly it on the spot, without looking
> somewhere the details. However, quicksort has worst-case scenarios that
> make it extremely inefficient. To make it efficient in all cases you need
> to use optimizations which are much more laborious to implement. Or use
> some other sorting algorithm, which will either be slower than quicksort
> (such as heap sort) or consume a lot more memory (such as merge sort).)
>
>    Doing a binary search on a sorted array, while extremely small piece
> of code, is surprisingly hard to get correct on-the-spot. I remember a
> study that showed that something like over half of experienced professional
> programmers implemented it incorrectly when they couldn't look for a
> reference. (Off-by-one errors can be pretty annoying.)
>

typically, this is where one uses their memory.

it is not about having to re-design it every time, but one has seen or 
written it previously, so it is kept in memory until it is needed again.


granted, I guess there are variations in memory abilities, much like how 
sometimes it can be bewildering just trying to remember what was going 
on the previous day. I guess it is conceivable that a person could 
remember the previous day better than they can keep a pile of 
source-code in memory for an extended period of time.


>    When you need a more complex algorithm or data container, the amount
> of work can be daunting. For example implementing a balanced binary tree
> is far from trivial.
>

things like AVL trees, ... are not all that complicated.


there are much worse things to implement by hand, such as the code to 
build a BSP tree or perform rigid-body physics type stuff. but, then, 
once one has done it once, they then have a much better understanding of 
the algorithms, and is much more likely to be able to do similar again 
later, or experiment with variations on the algorithms, ...


but, if they don't learn the algorithm in the first place (by 
implementing it themselves), how can they really hope to fully 
understand it?

it is like, an algorithm is often never really fully understood until 
one writes it for themselves.

also, reusing code written by others' may deprive one of the experience 
of having done it themselves (and beating on and debugging code can be 
an otherwise fairly enjoyable experience, sort of like a puzzle of sorts 
or similar), ...

like "why does this not work?", so one grabs their hat and their net and 
goes hunting for bugs (or clues as to the nature of said bugs, as one 
tracks them down and fixes them...).


>    Anyways, why should one have to write algorithms always from scratch?
> If I want to sort an array, I don't want to write a sorting algorithm each
> time, no matter if it takes just three lines of code. There's no need.
> There *shouldn't* be no need.
>

usually one does it this way because "this is how it is done".

depending on specifics though, it is usually more about 50 to 100 lines 
(both for the basic quicksort, and for the fallback sort for the n^2 case).


>    In fact, it's not just a question of convenience. It's a question of
> code correctness. When the algorithm implementation has been tested for
> years by millions of people, you can be pretty certain that it's correct.
> If you implement it yourself, there's a good chance that there will be a
> bug that might not be immediately apparent, and might kick in unexpectedly.

this may or may not matter.
for many apps, if it breaks, one goes and debugs it.

granted, yes, sometimes there are subtle bugs here and there that are 
difficult to track down, like one wondering why every once in a great 
while their custom implementation of deflate or JPEG will randomly fail 
(producing garbage output, or the Huffman decoder randomly going berserk).

but, with enough use, typically bugs will get beaten out, or one is 
eventually forced to give in and resort to living with a library 
dependency (a very sad day these can be, as on is defeated and shown a 
task beyond their' abilities).

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

#9748

BGB <cr88192@hotmail.com> wrote:
> but, if they don't learn the algorithm in the first place (by 
> implementing it themselves), how can they really hope to fully 
> understand it?

  I have never implemented a balanced binary tree myself, but I know
pretty well how a red-black tree works (which is the most common way of
implementing std::set and std::map), how fast it is, and what kind of
advantages and disadvantages it has (in terms of speed and memory usage).
I have a good grasp of asymptotical behavior, as well as an understanding
of the major constant factor bottlenecks of such a tree (the largest one
by far being the memory allocation done to each individual node).

  Also, I have never implemented a full introspective sort (which is the
most typical implementation of std::sort) myself, but I know what it's
composed of (quicksort, insertion sort and heap sort) and I have actually
measured its speed against typical "vanilla" sorting algorithms. (std::sort
is really hard to beat.)

  I don't need to implement these things myself to know how they work,
how fast they are and what their strenghs and weaknesses are.

> usually one does it this way because "this is how it is done".

  Please don't take this the wrong way, but can't you see that you are
making excuses to defend the language for no other reason that the language
is lacking, yet nevertheless very popular?

  (And I'm not saying that C++ is not lacking. It certainly is. However,
it's much less so than C.)

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

#9762

On 9/5/2011 1:01 AM, Juha Nieminen wrote:
> BGB<cr88192@hotmail.com>  wrote:
>> but, if they don't learn the algorithm in the first place (by
>> implementing it themselves), how can they really hope to fully
>> understand it?
>
>    I have never implemented a balanced binary tree myself, but I know
> pretty well how a red-black tree works (which is the most common way of
> implementing std::set and std::map), how fast it is, and what kind of
> advantages and disadvantages it has (in terms of speed and memory usage).
> I have a good grasp of asymptotical behavior, as well as an understanding
> of the major constant factor bottlenecks of such a tree (the largest one
> by far being the memory allocation done to each individual node).
>
>    Also, I have never implemented a full introspective sort (which is the
> most typical implementation of std::sort) myself, but I know what it's
> composed of (quicksort, insertion sort and heap sort) and I have actually
> measured its speed against typical "vanilla" sorting algorithms. (std::sort
> is really hard to beat.)
>
>    I don't need to implement these things myself to know how they work,
> how fast they are and what their strenghs and weaknesses are.
>


but, this is only understanding their surface behavior, but there are 
likely many subtleties in the algorithms which may be missed this way.

it is like, a person who simply uses a compiler, but never writes one, 
may be stuck perpetually in a world of "well, it takes source code, and 
gives me EXE files".

but, in implementing it themselves, one can understand the various 
tradeoffs made, possible nifty variations and alternate possibilities, ...


for example, after I learned the Qucksort algo, I realized I could 
combine it with a BSP building algo (replacing my prior set of O(n^2) 
BSP algos), the result being able to rebuild a BSP tree in O(n log2 n) 
time, or essentially, in realtime.

(nevermind that my 3D engine later ended up using a Doom3-like lighting 
strategy, which has some of its own drawbacks...).

but, anyways, if one does not know the algorithms, they can't make use 
of them in new ways.


granted, there is some possible overlap with psychology here, like SP 
(Sensing Perciever) vs NT (Intuituve Thinker) or similar.

or "learn by doing" vs "learn by reading lots of crap and pondering" or 
similar.


>> usually one does it this way because "this is how it is done".
>
>    Please don't take this the wrong way, but can't you see that you are
> making excuses to defend the language for no other reason that the language
> is lacking, yet nevertheless very popular?
>

as I see it, it is likely a statement of fact, much as how there are 
still plenty of people who use C.

lots of people use C;
lots of people who use C do so by reimplementing things.


>    (And I'm not saying that C++ is not lacking. It certainly is. However,
> it's much less so than C.)

in terms of usability, maybe.
there is more to the world than usability though.


this is, FWIW, why many projects make use of scripting languages as well.

then one has a lower-level language (such as C) for most of the 
down-to-the-metal parts of the project, and resorts to the scripting 
language for higher-level parts of the project (say: user interface, 
application logic / behavior, ...).

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

#9777

BGB <cr88192@hotmail.com> wrote:
>>    (And I'm not saying that C++ is not lacking. It certainly is. However,
>> it's much less so than C.)
> 
> in terms of usability, maybe.
> there is more to the world than usability though.

  I don't understand. Your argument seems to be: "There are other things
besides usability that a programmer has to take into account. Hence
usability is not important and can be dropped." That argument makes no
sense to me.

  It sounds like: "There are other things besides the driving wheel that
need to be used in order to drive a car. Hence we can drop the driving
wheel completely." Makes no sense.

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

#9802

On 9/5/2011 11:30 PM, Juha Nieminen wrote:
> BGB<cr88192@hotmail.com>  wrote:
>>>     (And I'm not saying that C++ is not lacking. It certainly is. However,
>>> it's much less so than C.)
>>
>> in terms of usability, maybe.
>> there is more to the world than usability though.
>
>    I don't understand. Your argument seems to be: "There are other things
> besides usability that a programmer has to take into account. Hence
> usability is not important and can be dropped." That argument makes no
> sense to me.
>
>    It sounds like: "There are other things besides the driving wheel that
> need to be used in order to drive a car. Hence we can drop the driving
> wheel completely." Makes no sense.

as noted a number of times:
I do use C++;
I just don't use it everywhere (and the places where I don't use it may 
also influence what is done in the places where I do use it).

it can't be used in places where I need to be able to parse the code by 
tools (or be able to run the code through my own compiler, ...);
it can't be used in places where I need to have the functionality shared 
with my scripting language;
...

being able to automatically-interface the code between languages, ... is 
a lot more valuable than using a slightly more programmer-friendly 
language, but then having to write a mountain of boilerplate because it 
is no longer possible to auto-generate much of the cross-language glue.

...

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

#9783

BGB <cr88192@hotmail.com> writes:
>>    (And I'm not saying that C++ is not lacking. It certainly is. However,
>> it's much less so than C.)
>
> in terms of usability, maybe.
> there is more to the world than usability though.

Sure... but C++ is more usable, tends to result in faster (in
execution) programs, yields more maintainable, easier to read code,
and makes it much easier to write more robust programs, more quickly,
than C...

The downside is that it is more complex ("more rope") and so requires
somewhat more learning (tho not nearly as much as many seem to think
-- much of the complexity in C++ doesn't really manifest unless you're
doing advanced things).

Not a bad set of tradeoffs to be honest....

-Miles

-- 
Road, n. A strip of land along which one may pass from where it is too
tiresome to be to where it is futile to go.

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

#9801

On 9/6/2011 12:25 AM, Miles Bader wrote:
> BGB<cr88192@hotmail.com>  writes:
>>>     (And I'm not saying that C++ is not lacking. It certainly is. However,
>>> it's much less so than C.)
>>
>> in terms of usability, maybe.
>> there is more to the world than usability though.
>
> Sure... but C++ is more usable, tends to result in faster (in
> execution) programs, yields more maintainable, easier to read code,
> and makes it much easier to write more robust programs, more quickly,
> than C...
>
> The downside is that it is more complex ("more rope") and so requires
> somewhat more learning (tho not nearly as much as many seem to think
> -- much of the complexity in C++ doesn't really manifest unless you're
> doing advanced things).
>
> Not a bad set of tradeoffs to be honest....
>

but, it is harder to write parsers and custom analysis tools for, and 
has a more complex and less standardized ABI.

hence, it is more difficult to implement things like reflection, ... for 
it (very useful for automated cross language interfacing).

writing a C++ compiler is likely also to be a non-trivial task (vs a C 
compiler, which is already a bit painful).

...

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

#9860

BGB <cr88192@hotmail.com> writes:
>> Sure... but C++ is more usable, tends to result in faster (in
>> execution) programs, yields more maintainable, easier to read code,
>> and makes it much easier to write more robust programs, more quickly,
>> than C...
>>
>> The downside is that it is more complex ("more rope") and so requires
>> somewhat more learning (tho not nearly as much as many seem to think
>> -- much of the complexity in C++ doesn't really manifest unless you're
>> doing advanced things).
>>
>> Not a bad set of tradeoffs to be honest....
>
> but, it is harder to write parsers and custom analysis tools for, and
> has a more complex and less standardized ABI.
>
> hence, it is more difficult to implement things like reflection,
> ... for it (very useful for automated cross language interfacing).
>
> writing a C++ compiler is likely also to be a non-trivial task (vs a C
> compiler, which is already a bit painful).

Those are true (I know this because I have done a lot of C++ compiler
work), but frankly, people writing C++ parsers / compilers / etc, are
a miniscule fraction of the people using C++ for other tasks.

So what you have, basically, is harder work for a few, to make things
easier/better/safer for many.

Again, a  pretty decent tradeoff.

[and given that I'm part of "the few", as well as part of the "many"
(I use C++ for many tasks), I think I have a pretty reasonable view of
this tradeoff.  Indeed, for compiler writers, the additional
complexity isn't some sort of pure annoyance -- it's also in many ways
more interesting to work on (and for those writing their compiler in
C++, of course, a benefit)... :]

-Miles

-- 
Back, n. That part of your friend which it is your privilege to contemplate in
your adversity.

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

#9911

On 9/6/2011 8:28 PM, Miles Bader wrote:
> BGB<cr88192@hotmail.com>  writes:
>>> Sure... but C++ is more usable, tends to result in faster (in
>>> execution) programs, yields more maintainable, easier to read code,
>>> and makes it much easier to write more robust programs, more quickly,
>>> than C...
>>>
>>> The downside is that it is more complex ("more rope") and so requires
>>> somewhat more learning (tho not nearly as much as many seem to think
>>> -- much of the complexity in C++ doesn't really manifest unless you're
>>> doing advanced things).
>>>
>>> Not a bad set of tradeoffs to be honest....
>>
>> but, it is harder to write parsers and custom analysis tools for, and
>> has a more complex and less standardized ABI.
>>
>> hence, it is more difficult to implement things like reflection,
>> ... for it (very useful for automated cross language interfacing).
>>
>> writing a C++ compiler is likely also to be a non-trivial task (vs a C
>> compiler, which is already a bit painful).
>
> Those are true (I know this because I have done a lot of C++ compiler
> work), but frankly, people writing C++ parsers / compilers / etc, are
> a miniscule fraction of the people using C++ for other tasks.
>
> So what you have, basically, is harder work for a few, to make things
> easier/better/safer for many.
>
> Again, a  pretty decent tradeoff.
>

fair enough.
the problem is that I don't really have enough time/energy/... to 
personally justify going through the work (all at once), though I may 
eventually have it in a "one piece at a time" sense.


for interfacing between a script language and C++ at the C++ level, one 
would probably need (in a basic sense):
ability to share classes (at least import them, to use C++ APIs directly 
from the HLL, much harder is exporting classes to C++, and harder still 
would be to allow mutual inheritance/overloading);
...


or, say for example, transparently interfacing C++ and an ECMAScript 
variant (similar to JavaScript or ActionScript), ideally without making 
awkward/arbitrary restrictions for one or the other (including semantic 
mismatches).


as-is, C structs can be shared, but my scripting VM has several notable 
restrictions WRT shared structs (ones shared between C code and the 
scripting VM):
minor "construction" issues ("new structname();" will create a struct, 
but not necessarily in the "correct" way for a given use-case);
currently, the struct needs to be a type known to the GC/... (needs to 
be allocated in "managed" memory, or the memory-region needs to be 
registered with the GC with the appropriate handlers set up, also the 
declaration needs to be visible-to/processed-by the metadata tool);
currently, structs may not be directly/physically nested (except in 
certain special cases, but may be linked freely via pointers);
arrays-of-structs don't currently work (one needs arrays of pointers to 
structs instead);
shared function pointers are very much a "use with caution" feature 
(function pointers work both-ways, but have not been well tested 
extensively, and I don't much "trust" the feature, as well as it 
introducing additional restrictions);
...


a lot of the reason for these issues is that the VM/language is 
internally "soft typed" (sort of a mix of static and dynamic typing). 
WRT handling complex data types, it currently uses dynamic 
type-checking, and if the VM can't determine the type of the object a 
pointer refers to, it will simply treat it as a no-op opaque value 
(often happens, say, will malloc'ed memory, ...).

in a few cases, the VM uses "boxed pointer values" (basically where the 
pointer is boxed in a heap-based object which also tracks its type, 
usually done if the static type is known but a dynamic type is not 
visible with the pointer), but this is expensive (when loading a 
pointer, the VM may examine it and determine if it needs to box it, 
avoiding doing so if possible).

as can be noted, "new structname();" will generally create the struct as 
a "pass-by-value" boxed type (rather than currently as its assigned 
dynamic type name, note example below). however, semantics/... get hairy 
here (and, typically, explicit constructor functions are used for most 
cases where this would matter).


so, as-is, not even C is perfectly handled at its own level (but, the 
subset is "generally good enough" for most tasks).


so, in a basic sense, C++ struct-based objects could be shared in a 
limited sense:

typdef struct Foo_s Foo;
struct Foo_s dytname("myapp_foo_t") //dytname==dynamic type name
{
fields...

#ifdef __cplusplus
... non-virtual methods ...
#endif
};


the trivial extension would be to have the metadata tool be able to 
accept the class keyword, and be able to parse non-virtual methods.


the biggie issue though:
about as soon as one defines "__cplusplus" in the preprocessor, then 
usually one also gets a mountain of template definitions and other 
things (even from otherwise theoretically plain C headers), meaning that 
the parser/tools/... have to be prepared to deal with all this.

there is no real option for a tool to be like (to the system headers) 
"only give me those pieces of code I can deal with". actually... one 
often even has to emulate certain compilers just to make the headers 
happy, as many headers will themselves refuse to work correctly if one 
doesn't define, say:
__GNUC__
__GCC_VERSION__
...

which means that my tools have ended up supporting many GCC and MSVC 
extensions (and partial compiler emulation) simply trying to get the 
headers parsed.

as-is, I am partly left scared of the C++ case.

otherwise, one would need a lot of special case stuff, essentially 
making the "tools" case separate from either the C or C++ cases.

#if defined(__cplusplus) || defined(_BGBMETA)
...
#endif

or, creating a new PP define to reflect a common sub-case (a C++ subset 
understandable to the tools).


my preference thus far had been for types/magic-modifiers/... which 
could be made special for the tool, but otherwise invisible to plain C 
or C++ compilers (or will expand to something more generic).

"dytname()" is such an example, where in the tool it will expand to a 
special attribute, and in plain C or C++ (native compiler) it will 
expand to nothing.


technically, the main metadata tool should be able to at least parse 
basic C++ style syntax (class definitions, ...), but lacks many other 
less trivial matters.

namespaces may pose additional difficulties (they are partially 
supported, but very hackish, and concepts like scoped-typedefs, ... are 
not currently handled).

IMO, templates also look like a big ugly issue.


currently, there is no support for the C++ ABI (and my own object system 
works a bit differently, meaning a 1:1 mapping with C++ ABI classes 
could be itself difficult).

also, classes would either need to overload "new" to use the GC for 
allocation, or the VM/GC will have to be aware of and able to deal with 
RTTI (has its own sets of worries).

...


I guess one can ask though how easy it can really be to interface 
several not-exactly-similar languages (such as C and ECMAScript), and 
avoid creating any ugly seams in the process.

it is also a question of how much can be readily done in a single person 
project as well.


> [and given that I'm part of "the few", as well as part of the "many"
> (I use C++ for many tasks), I think I have a pretty reasonable view of
> this tradeoff.  Indeed, for compiler writers, the additional
> complexity isn't some sort of pure annoyance -- it's also in many ways
> more interesting to work on (and for those writing their compiler in
> C++, of course, a benefit)... :]
>

fair enough...

actually, my compiler and VM stuff is itself mostly written in C, mostly 
because I figure it would be useful for the VM to be able to access its 
own functionality.

similarly, most VM functionality is also exposed to C and C++ code, 
albeit with the existing restrictions (typically, a minimally-adorned 
C-like interface is provided, as going and writing a mountain of 
cosmetic wrappers would be much added effort).


a few parts of my 3D engine, however, are C++, but admittedly it is 
typically a fairly minimalist form (C-like with a few classes, and 
generally no real use of templates or namespaces).

a partial reason for lack of namespaces:
because I am lazy and generate many of my headers with tools, and this 
particular tool is fairly naive/simplistic (also under 1 kloc), neither 
understanding namespaces nor preprocessor directives, and has some of 
its own special command-language embedded in comments (or occasionally 
in special preprocessor directives, which are treated as literal tokens).

this tool doesn't care about "using" and namespaces, or "::", but does 
care about declaring code in namespaces, which it will screw up with, 
and would have to be told to ignore the whole region.

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

#9913

On Sep 7, 4:49 pm, BGB <cr88...@hotmail.com> wrote:
> On 9/6/2011 8:28 PM, Miles Bader wrote:
>
>
>
>
>
>
>
>
>
> > BGB<cr88...@hotmail.com>  writes:
> >>> Sure... but C++ is more usable, tends to result in faster (in
> >>> execution) programs, yields more maintainable, easier to read code,
> >>> and makes it much easier to write more robust programs, more quickly,
> >>> than C...
>
> >>> The downside is that it is more complex ("more rope") and so requires
> >>> somewhat more learning (tho not nearly as much as many seem to think
> >>> -- much of the complexity in C++ doesn't really manifest unless you're
> >>> doing advanced things).
>
> >>> Not a bad set of tradeoffs to be honest....
>
> >> but, it is harder to write parsers and custom analysis tools for, and
> >> has a more complex and less standardized ABI.
>
> >> hence, it is more difficult to implement things like reflection,
> >> ... for it (very useful for automated cross language interfacing).
>
> >> writing a C++ compiler is likely also to be a non-trivial task (vs a C
> >> compiler, which is already a bit painful).
>
> > Those are true (I know this because I have done a lot of C++ compiler
> > work), but frankly, people writing C++ parsers / compilers / etc, are
> > a miniscule fraction of the people using C++ for other tasks.
>
> > So what you have, basically, is harder work for a few, to make things
> > easier/better/safer for many.
>
> > Again, a  pretty decent tradeoff.
>
> fair enough.
> the problem is that I don't really have enough time/energy/... to
> personally justify going through the work (all at once), though I may
> eventually have it in a "one piece at a time" sense.
>
> for interfacing between a script language and C++ at the C++ level, one
> would probably need (in a basic sense):
> ability to share classes (at least import them, to use C++ APIs directly
> from the HLL, much harder is exporting classes to C++, and harder still
> would be to allow mutual inheritance/overloading);
> ...
>
> or, say for example, transparently interfacing C++ and an ECMAScript
> variant (similar to JavaScript or ActionScript), ideally without making
> awkward/arbitrary restrictions for one or the other (including semantic
> mismatches).

http://www.boost.org/doc/libs/1_47_0/libs/python/doc/

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

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

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

csiph-web