Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #9589 > unrolled thread
| Started by | KaiWen <wenkai1987@gmail.com> |
|---|---|
| First post | 2011-09-01 01:41 -0700 |
| Last post | 2011-09-03 15:11 -0700 |
| Articles | 20 on this page of 114 — 22 participants |
Back to article view | Back to comp.lang.c++
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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-08 15:56 -0700 |
| Message-ID | <j4bh7d$2lm$1@news.albasani.net> |
| In reply to | #9913 |
On 9/7/2011 6:45 PM, Noah Roberts wrote:
> 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/
fair enough, will have to look at it...
(not at the moment though, as I don't have a lot of time at the moment...).
granted, I am not likely to switch to Python either, as:
this would be too much effort;
Python does not rank very highly on my list of "languages I am likely to
willingly use" (bleh, seems crufty and with a funky syntax...).
nevermind the drawbacks in my system, for the most part, its interface
(with C) is reasonably transparent and not too painful to use (it allows
bidirectional calls, automatic type conversion in most cases, and
generally allows cross-language sharing of data structures, ...).
most of the cross-language semantic limitations follow fairly directly
from the semantics of either one language or the other:
one language allows adding fields per-instance for any object;
for obvious enough reasons, this wont work with C.
also, my languages' struct semantics were mostly derived from C#, hence
why it has funky interpretation of "new struct()", because it
handles/understands structs it in a C#-like way (I may later either make
a special exception for C-structs, or use a declaration modifier).
say:
struct Foo_s dytname("mylib_foo_t") dytnewref
{
};
with "dytnewref" meaning to create a new instance as a reference type.
or such...
[toc] | [prev] | [next] | [standalone]
| From | James Kanze <james.kanze@gmail.com> |
|---|---|
| Date | 2011-09-03 15:32 -0700 |
| Message-ID | <fd2311d2-8dac-4c75-bb77-917c5aebd057@o26g2000vbi.googlegroups.com> |
| In reply to | #9687 |
On Sep 3, 9:45 am, BGB <cr88...@hotmail.com> wrote:
> On 9/2/2011 10:51 PM, Juha Nieminen wrote:
[...]
> also, just how many people really use "qsort()" anyways?...
Not very many, because not very many people write applications
which might need it in C.
In earlier days, it was widely used.
> 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).
That is, of course, complete bullshit. Any competent C
programmer will use it if he has to sort something.
> (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).
Only among incompetent C programmers.
> 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.
> from what I can gather from checking online (via Google), it seems where
> people have tried testing, the performance differences have tended to be
> negligible.
From my concrete experience, in several different applications
(including one where two separate teams implemented the same
thing, one in C and one in C++), when performance matters, C++
is usually a magnitude faster than C, if not more.
> some other tests have apparently shown std::string operations to be
> about 4x slower than C-style strings.
Never trust a benchmark you haven't rigged yourself. I would
have no problem writing a benchmark to prove whichever side I
wished.
In real applications, where performance matters, C++ is
significantly faster than C.
--
James Kanze
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-03 19:16 -0700 |
| Message-ID | <j3un1g$g4k$1@news.albasani.net> |
| In reply to | #9708 |
On 9/3/2011 3:32 PM, James Kanze wrote: > On Sep 3, 9:45 am, BGB<cr88...@hotmail.com> wrote: >> On 9/2/2011 10:51 PM, Juha Nieminen wrote: > > [...] >> also, just how many people really use "qsort()" anyways?... > > Not very many, because not very many people write applications > which might need it in C. > > In earlier days, it was widely used. > possibly... >> 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). > > That is, of course, complete bullshit. Any competent C > programmer will use it if he has to sort something. > not from what I have seen. >> (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). > > Only among incompetent C programmers. > value judgements aside, it is a question of which is more common, not which is more "competent". most of the code I have seen has generally been in things like game-engines and VMs, which are generally my main interest areas. common in game engines (especially the Quake series and most similar or derived engines) is in-fact to wrap much of the OS (for example, everything from the filesystem to memory management to networking to ... is generally somewhat wrapped, or implemented clean). if one goes and looks at other things, such as GTK+, one finds yet more wrapping and custom-written logic. and, if one goes and looks into the core of Mono... well, then one just finds terror... also, many projects end up largely not using "malloc()"/"free()" either, and instead use garbage collectors such as Boehm, or other custom memory managers. so, from what all I have seen, wrapping and reimplementation seems to be common practice, with the standard library usually being used in a "pick and choose" manner, often with many parts of it, or much of it, being ignored. >> 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. > >> from what I can gather from checking online (via Google), it seems where >> people have tried testing, the performance differences have tended to be >> negligible. > > From my concrete experience, in several different applications > (including one where two separate teams implemented the same > thing, one in C and one in C++), when performance matters, C++ > is usually a magnitude faster than C, if not more. > from what all I have seen, in personal experience and in common benchmarks, they usually come out more or less about the same. granted, a lot likely comes down to coding practices, and one can write faster or slower code in either language. >> some other tests have apparently shown std::string operations to be >> about 4x slower than C-style strings. > > Never trust a benchmark you haven't rigged yourself. I would > have no problem writing a benchmark to prove whichever side I > wished. > > In real applications, where performance matters, C++ is > significantly faster than C. > depends on what one means exactly by a "real application". granted, it would be hard to really test this one way or another, as one would need otherwise equivalent apps written in each language, and not (as is far more common IME) an ad-hoc mix of both languages (and absent external factors, such as potentially notable implementation differences). for example, my own project would be excluded because it is, in fact, written with parts in C, parts in C++, parts in ASM, and parts in other languages (namely some Java, and some parts in a custom language). project size is maybe "medium" at about 815 kloc (a "large" project would be something more like GCC, FireFox, or the Linux kernel, each of which is solidly in the Mloc range). by this scale though, Quake would be a "small" project, being approx 30 kloc IIRC, and was itself written primarily in C (other parts were ASM and QuakeC), much as were Quake2 and Quake3 (ASM and C). so, one can debate: would Quake 1 or 2 have gotten faster framerates had they been instead written in C++?... or, for that matter, would the Linux kernel likely go faster?... or, maybe, would GCC itself compile code faster?... or such...
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-05 00:28 -0700 |
| Message-ID | <875f9e1f-79f1-49fa-8667-f440e8cc4c69@fd21g2000vbb.googlegroups.com> |
| In reply to | #9687 |
On Sep 3, 9:45 am, BGB <cr88...@hotmail.com> wrote: > On 9/2/2011 10:51 PM, Juha Nieminen wrote > > KaiWen<wenkai1...@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?... If I'm coding in C and I want to sort something. My first thought would be qsort()! If it was too slow only then would I consider hand coding it. Surely any constructively lazy person would use an existing facility rather hand-roll their own! > 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). why?! There must be nearly as many badly written sort routines as there are badly implemented linked lists! > (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). not in my part of C land. I use the available libraries and encourage other's to do the same. Yes the C libraries are far less rich than the C++ libraries but they're still there and provide some basic fucntionality. > 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. are they? > not that > worrying about micro-optimizing string operations is usually all that > relevant though anyways. > > from what I can gather from checking online (via Google), it seems where > people have tried testing, the performance differences have tended to be > negligible. > > some other tests have apparently shown std::string operations to be > about 4x slower than C-style strings.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-05 12:34 -0700 |
| Message-ID | <j43884$faj$1@news.albasani.net> |
| In reply to | #9747 |
On 9/5/2011 12:28 AM, Nick Keighley wrote: > On Sep 3, 9:45 am, BGB<cr88...@hotmail.com> wrote: >> On 9/2/2011 10:51 PM, Juha Nieminen wrote >>> KaiWen<wenkai1...@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?... > > If I'm coding in C and I want to sort something. My first thought > would be qsort()! If it was too slow only then would I consider hand > coding it. Surely any constructively lazy person would use an existing > facility rather hand-roll their own! > different styles for different sorts... actually, in my case I would probably far more likely copy-paste it and then edit it to the new use. copy-paste is a powerful tool which is often disparaged and overlooked. but, one would typically write it themselves initially (before subjecting it to endless copy-paste). >> 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). > > why?! There must be nearly as many badly written sort routines as > there are badly implemented linked lists! > if people were not doing it, then one would not be encountering them. that one is encountering so many "badly written sort functions" means that there are equally many (probably actually, far more) people off writing them. hence, the case stands... >> (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). > > not in my part of C land. I use the available libraries and encourage > other's to do the same. > > Yes the C libraries are far less rich than the C++ libraries but > they're still there and provide some basic fucntionality. > it is the case though in many parts of C land I have seen though (mostly GPL/FOSS/... style projects, FWIW commercial C code could look very different, but I wouldn't know because much more of it is kept behind locked doors). but, if initially commercial projects count, such as Quake 1/2/3, it appears to be not that much different (apparently for Doom3 John Carmack used C++ though, but why would be a subject of further investigation). actually, to some extent a lot of my "initially learning programming" stuff came from looking at things like a lot of Carmack's code and the Linux kernel and similar (and hacking on the Quake engine and similar). but, yes, all of this was a great many years ago... interestingly, I remember in the past at one point where a person had commented that my coding style somewhat resembled Carmack's, which I guess stands to reason... >> 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. > > are they? > from what I have seen, people tend to pass them around by-value. apparently, the by-value vs by-reference thing makes a bit of a difference WRT performance. apparently, their performance characteristics also differ some between GCC and MSVC, with the ones in MSVC apparently tending to be more expensive. granted, I haven't personally looked into all of this in-depth though. there are also plenty of things often done with C strings as well that can make them faster, such as interning them so that one can check string equality using '==' on the pointers, rather than using "!strcmp()", ... in my case, I tend to avoid "stdrup()" as well, as generally "strdup()" is a good way to "make bad things happen" (slow, tears through huge amounts of memory, leaves the program responsible to free them, ...), so preferable IMO is interning them into string-tables (a big glob of memory where they are packed end-to-end). then one can free the whole string table as part of a "teardown" process. another strategy (used elsewhere) is to allocate the strings in the garbage-collected heap (I use GC), and then manage them using a weak hash (entries will be reset to NULL whenever any are reclaimed by the GC). also, == and != work provided both strings are in the same string-table. but, then, this is turning more into details of "how does one use them?" than "which is faster?"...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-09-06 07:51 +1200 |
| Subject | Re: Generally, are the programs written by C++ slower than written by C 10% ? |
| Message-ID | <9cknhoF72aU1@mid.individual.net> |
| In reply to | #9764 |
On 09/ 6/11 07:34 AM, BGB wrote: > On 9/5/2011 12:28 AM, Nick Keighley wrote: >> On Sep 3, 9:45 am, BGB<cr88...@hotmail.com> wrote: >> >> If I'm coding in C and I want to sort something. My first thought >> would be qsort()! If it was too slow only then would I consider hand >> coding it. Surely any constructively lazy person would use an existing >> facility rather hand-roll their own! >> > > different styles for different sorts... > > > actually, in my case I would probably far more likely copy-paste it and > then edit it to the new use. > > copy-paste is a powerful tool which is often disparaged and overlooked. Rightly so. C has things call functions that enable code to be reused and C++ has function templates that remove the last excuse for copy and paste. > but, one would typically write it themselves initially (before > subjecting it to endless copy-paste). Not if they were being paid to deliver software. >>> 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. >> >> are they? >> > > from what I have seen, people tend to pass them around by-value. Most C++ code passes strings by const reference. > apparently, the by-value vs by-reference thing makes a bit of a > difference WRT performance. > > apparently, their performance characteristics also differ some between > GCC and MSVC, with the ones in MSVC apparently tending to be more expensive. > > granted, I haven't personally looked into all of this in-depth though. With some compilers in some modes, passing a string by value will be quicker if the string object (typically a pair of pointers) is small enough to pass in registers. > there are also plenty of things often done with C strings as well that > can make them faster, such as interning them so that one can check > string equality using '==' on the pointers, rather than using > "!strcmp()", ... In other words, wrapping them like std::string... > in my case, I tend to avoid "stdrup()" as well, as generally "strdup()" > is a good way to "make bad things happen" (slow, tears through huge > amounts of memory, leaves the program responsible to free them, ...), so > preferable IMO is interning them into string-tables (a big glob of > memory where they are packed end-to-end). > > then one can free the whole string table as part of a "teardown" process. > > another strategy (used elsewhere) is to allocate the strings in the > garbage-collected heap (I use GC), and then manage them using a weak > hash (entries will be reset to NULL whenever any are reclaimed by the GC). > > > also, == and != work provided both strings are in the same string-table. Or save a whole lot of pain and use std::string. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-05 14:06 -0700 |
| Subject | Re: Generally, are the programs written by C++ slower than written by C 10% ? |
| Message-ID | <j43dk2$5ap$1@news.albasani.net> |
| In reply to | #9765 |
On 9/5/2011 12:51 PM, Ian Collins wrote:
> On 09/ 6/11 07:34 AM, BGB wrote:
>> On 9/5/2011 12:28 AM, Nick Keighley wrote:
>>> On Sep 3, 9:45 am, BGB<cr88...@hotmail.com> wrote:
>>>
>>> If I'm coding in C and I want to sort something. My first thought
>>> would be qsort()! If it was too slow only then would I consider hand
>>> coding it. Surely any constructively lazy person would use an existing
>>> facility rather hand-roll their own!
>>>
>>
>> different styles for different sorts...
>>
>>
>> actually, in my case I would probably far more likely copy-paste it and
>> then edit it to the new use.
>>
>> copy-paste is a powerful tool which is often disparaged and overlooked.
>
> Rightly so. C has things call functions that enable code to be reused
> and C++ has function templates that remove the last excuse for copy and
> paste.
>
>> but, one would typically write it themselves initially (before
>> subjecting it to endless copy-paste).
>
> Not if they were being paid to deliver software.
>
well, if they just copy/paste it from existing sources, they may be
stuck with GPL nastiness or similar (since, annoyingly, the majority of
existing/FOSS source is GPL), so writing it initially will give them a
version for which they control the license (while still being legal, and
not simply "forgetting" the per-existing license terms).
for example, I have ended up having to write pretty much a whole damn 3D
engine to get away from the GPL and stay reasonably close to familiar
territory (my plans are to use the MIT license for most of the core).
recently I have (at least experimentally) loaded up Doom3 maps in my own
engine, however for the most part I have previously been using
Quake-style maps (mostly from Quake 1). I had also loaded up maps from
Xonotic (sort of like a Quake-3 Arena clone based on a heavily modified
Quake-1 engine, namely DarkPlaces).
>>>> 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.
>>>
>>> are they?
>>>
>>
>> from what I have seen, people tend to pass them around by-value.
>
> Most C++ code passes strings by const reference.
>
I guess people do both.
I had seen references to it apparently being a style debate between
using references and passing them by value, with different performance
tradeoffs existing between compilers.
>> apparently, the by-value vs by-reference thing makes a bit of a
>> difference WRT performance.
>>
>> apparently, their performance characteristics also differ some between
>> GCC and MSVC, with the ones in MSVC apparently tending to be more
>> expensive.
>>
>> granted, I haven't personally looked into all of this in-depth though.
>
> With some compilers in some modes, passing a string by value will be
> quicker if the string object (typically a pair of pointers) is small
> enough to pass in registers.
>
dunno, it depends on the compiler.
the version of the object I am familiar with happens to contain (IIRC) a
reference count, a maximum size (capacity), a length field, and a
character array aliased against a pointer.
>> there are also plenty of things often done with C strings as well that
>> can make them faster, such as interning them so that one can check
>> string equality using '==' on the pointers, rather than using
>> "!strcmp()", ...
>
> In other words, wrapping them like std::string...
>
yep, except that this also works with plain C (relevant since the
project is largely mixed-language, and C-style is the only thing
"everyone" understands).
actually, it is more restricted than this, typically not only do they
have to be plain C types but also visible to the garbage collector and
to the VM type-system.
technically, the pointer values are equivalent, but different functions
are used to return either "char *" or "dyt" (a magic type used for
dynamically typed objects), mostly to avoid the need for manual casting
or the compiler throwing a fit due to implicit pointer-type conversions.
trivia:
there are overloaded operators so that "dyt" behaves more like a
built-in type in C++, whereas one needs things like "dyadd(a, b)" in C.
for many shared-language constructs, it is usually least effort to make
them behave C-like internally, and give optional overloaded operators or
wrapper classes for the C++ case.
in a few cases, the methods actually just redirect, either to calling
through a function-pointer (for C and C++ code to implement the real
logic), or redirecting the call into the scripting VM (such as if a
VM-managed object is placed into a field, such as "dy_this").
say, for example:
void FooObject::fooMethod()
{
if(dy_this)
{
dyCallSigv(dy_this, "fooMethod", "()v");
return;
}
if(vtable->fooMethof_f)
vtable->fooMethof_f();
}
it can all get kind of hairy at times, but it works...
>> in my case, I tend to avoid "stdrup()" as well, as generally "strdup()"
>> is a good way to "make bad things happen" (slow, tears through huge
>> amounts of memory, leaves the program responsible to free them, ...), so
>> preferable IMO is interning them into string-tables (a big glob of
>> memory where they are packed end-to-end).
>>
>> then one can free the whole string table as part of a "teardown" process.
>>
>> another strategy (used elsewhere) is to allocate the strings in the
>> garbage-collected heap (I use GC), and then manage them using a weak
>> hash (entries will be reset to NULL whenever any are reclaimed by the
>> GC).
>>
>>
>> also, == and != work provided both strings are in the same string-table.
>
> Or save a whole lot of pain and use std::string.
>
except, as noted above, I can't do this generally, as C++ is only used
in parts of the project.
granted, std::string makes a lot more sense for a pure-C++ project (or
at least a "strongly dominantly C++" project).
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-06 00:32 -0700 |
| Message-ID | <c5d952c4-d286-46b5-a589-7a29fa0b2caf@z7g2000vbp.googlegroups.com> |
| In reply to | #9766 |
On Sep 5, 10:06 pm, BGB <cr88...@hotmail.com> wrote: > On 9/5/2011 12:51 PM, Ian Collins wrote: > > On 09/ 6/11 07:34 AM, BGB wrote: <snip> > >> copy-paste is a powerful tool which is often disparaged and overlooked. > > > Rightly so. C has things call functions that enable code to be reused > > and C++ has function templates that remove the last excuse for copy and > > paste. > > >> but, one would typically write it themselves initially (before > >> subjecting it to endless copy-paste). > > > Not if they were being paid to deliver software. > > well, if they just copy/paste it from existing sources, they may be > stuck with GPL nastiness or similar (since, annoyingly, the majority of > existing/FOSS source is GPL), so writing it initially will give them a > version for which they control the license (while still being legal, and > not simply "forgetting" the per-existing license terms). I don't get this. How does copy-paste save you from licence problems? If you've incorporated GPL code into your code base then surely any GPL restrictions that apply already apply! I think the people who think they're avoiding GPL problems[1] by copy-pasteing are fooling themselves. [note 1] I'm not going to get into a debate about the meaning of the word "problem" > for example, I have ended up having to write pretty much a whole damn 3D > engine to get away from the GPL and stay reasonably close to familiar > territory (my plans are to use the MIT license for most of the core). and what has that got to do with copy-paste? <snip>
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-06 07:33 -0700 |
| Message-ID | <j45av3$5vp$1@news.albasani.net> |
| In reply to | #9784 |
On 9/6/2011 12:32 AM, Nick Keighley wrote:
> On Sep 5, 10:06 pm, BGB<cr88...@hotmail.com> wrote:
>> On 9/5/2011 12:51 PM, Ian Collins wrote:
>>> On 09/ 6/11 07:34 AM, BGB wrote:
>
> <snip>
>
>>>> copy-paste is a powerful tool which is often disparaged and overlooked.
>>
>>> Rightly so. C has things call functions that enable code to be reused
>>> and C++ has function templates that remove the last excuse for copy and
>>> paste.
>>
>>>> but, one would typically write it themselves initially (before
>>>> subjecting it to endless copy-paste).
>>
>>> Not if they were being paid to deliver software.
>>
>> well, if they just copy/paste it from existing sources, they may be
>> stuck with GPL nastiness or similar (since, annoyingly, the majority of
>> existing/FOSS source is GPL), so writing it initially will give them a
>> version for which they control the license (while still being legal, and
>> not simply "forgetting" the per-existing license terms).
>
> I don't get this. How does copy-paste save you from licence problems?
> If you've incorporated GPL code into your code base then surely any
> GPL restrictions that apply already apply! I think the people who
> think they're avoiding GPL problems[1] by copy-pasteing are fooling
> themselves.
>
no, this is why they write the code themselves:
if they write it themselves, they are free of GPL.
if they just go and either use GPL code, or copy-paste from GPL sources,
then they are stuck with GPL.
hence, why one needs to write their own code themselves (then they can
use it however without any legal restriction).
> [note 1] I'm not going to get into a debate about the meaning of the
> word "problem"
>
>> for example, I have ended up having to write pretty much a whole damn 3D
>> engine to get away from the GPL and stay reasonably close to familiar
>> territory (my plans are to use the MIT license for most of the core).
>
> and what has that got to do with copy-paste?
>
one of the major "world players" in the FOSS 3D engine space is various
modified versions of the Quake-series engines ("Quake engine" in the
generic sense).
however, *all* of these engine variants are GPL, because id Software
originally released their source under the GPL.
hence, why one would need to write their own engine from the ground up
to be free of the GPL.
one can't just "copy-paste" the 3D engine, or parts of it, without being
stuck with the GPL.
now, extend this generally, and note that most freely-available code is
either proprietary (can't be reused safely at all) or GPL, and hence one
starts to see the problem, namely: why it is necessary for people to
write their own code to keep everything legal.
yes, there are MIT / BSD / ... projects, which allow more freely reusing
code without overbearing legal issues, but these projects are a relative
minority in FOSS land.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-07 02:52 -0700 |
| Message-ID | <334d2599-e6f4-4037-937b-e918bdccff70@y4g2000vbx.googlegroups.com> |
| In reply to | #9803 |
On Sep 6, 3:33 pm, BGB <cr88...@hotmail.com> wrote: > On 9/6/2011 12:32 AM, Nick Keighley wrote: > > > > > > > On Sep 5, 10:06 pm, BGB<cr88...@hotmail.com> wrote: > >> On 9/5/2011 12:51 PM, Ian Collins wrote: > >>> On 09/ 6/11 07:34 AM, BGB wrote: > > > <snip> > > >>>> copy-paste is a powerful tool which is often disparaged and overlooked. > > >>> Rightly so. C has things call functions that enable code to be reused > >>> and C++ has function templates that remove the last excuse for copy and > >>> paste. > > >>>> but, one would typically write it themselves initially (before > >>>> subjecting it to endless copy-paste). you appear to be trying to justify copy-paste > >>> Not if they were being paid to deliver software. > > >> well, if they just copy/paste it from existing sources, they may be > >> stuck with GPL nastiness or similar (since, annoyingly, the majority of > >> existing/FOSS source is GPL), so writing it initially will give them a > >> version for which they control the license (while still being legal, and > >> not simply "forgetting" the per-existing license terms). this is a reason for writing stuff yourself. it is /not/ a reason for copy-paste. If you've written the code yourself why not package it in reusable form? > > I don't get this. How does copy-paste save you from licence problems? I possibly misunderstood what you were saying. <snip> > now, extend this generally, and note that most freely-available code is > either proprietary (can't be reused safely at all) or GPL, but not the standard libraries of either C or C++. There's also quite a bit of BSD licensed code about. > and hence one > starts to see the problem, namely: why it is necessary for people to > write their own code to keep everything legal. > > yes, there are MIT / BSD / ... projects, which allow more freely reusing > code without overbearing legal issues, but these projects are a relative > minority in FOSS land. we seem to be confusing different things (you seem to move the goal- posts) 1. I asked why you would write your own sort rather than use qsort() as a first pass. 2. you recomended copy-paste as a devlopment methodolgy. I think it's hardly ever a reasonable thing to do. And is responsible for much "software rot". 3. you (reasonably) use license problems as a reason to reinvent the wheel. 3 is not a justification for either 1 or 2
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-08 16:24 -0700 |
| Message-ID | <j4bir0$5nn$1@news.albasani.net> |
| In reply to | #9882 |
On 9/7/2011 2:52 AM, Nick Keighley wrote: > On Sep 6, 3:33 pm, BGB<cr88...@hotmail.com> wrote: >> On 9/6/2011 12:32 AM, Nick Keighley wrote: >> >> >> >> >> >>> On Sep 5, 10:06 pm, BGB<cr88...@hotmail.com> wrote: >>>> On 9/5/2011 12:51 PM, Ian Collins wrote: >>>>> On 09/ 6/11 07:34 AM, BGB wrote: >> >>> <snip> >> >>>>>> copy-paste is a powerful tool which is often disparaged and overlooked. >> >>>>> Rightly so. C has things call functions that enable code to be reused >>>>> and C++ has function templates that remove the last excuse for copy and >>>>> paste. >> >>>>>> but, one would typically write it themselves initially (before >>>>>> subjecting it to endless copy-paste). > > you appear to be trying to justify copy-paste > of ones' own code... copy/paste may well be justified in some cases, such as to avoid creating a physical dependency between unrelated components, whereas traditional code-reuse creates dependencies by extension. however, copy-paste from others' code is plagiarism and may also be illegal. > >>>>> Not if they were being paid to deliver software. >> >>>> well, if they just copy/paste it from existing sources, they may be >>>> stuck with GPL nastiness or similar (since, annoyingly, the majority of >>>> existing/FOSS source is GPL), so writing it initially will give them a >>>> version for which they control the license (while still being legal, and >>>> not simply "forgetting" the per-existing license terms). > > this is a reason for writing stuff yourself. it is /not/ a reason for > copy-paste. If you've written the code yourself why not package it in > reusable form? > typically because this creates dependencies between ones' components. factoring things out to eliminate dependencies while still having code-reuse may often introduce a fair amount of additional architectural complexity (reuse via "mutual 3rd parties", ...). copy-paste allows physical decoupling without the need to create "3rd parties". a problem though is when copy-paste introduces "synchronization issues", which yes, can be a nasty problem. ideally code should not be copy-pasted in this case, or any such synchronization should be defined as part of the "formal model" of whatever code or data is in question (an example is things like codecs, where it is assumed that whatever comes back out is whatever the encoder intended to come out, ...). >>> I don't get this. How does copy-paste save you from licence problems? > > I possibly misunderstood what you were saying. > > <snip> > >> now, extend this generally, and note that most freely-available code is >> either proprietary (can't be reused safely at all) or GPL, > > but not the standard libraries of either C or C++. There's also quite > a bit of BSD licensed code about. > actually, several major implementations (glib, newlib, ...), are "GPL with linking exception" and similar. others, such as MSVCRT, are closed-source AFAIK. if one were to copy-paste from glib or similar, they would still likely be stuck with GPL, but the library itself can be linked to without issue. >> and hence one >> starts to see the problem, namely: why it is necessary for people to >> write their own code to keep everything legal. >> >> yes, there are MIT / BSD / ... projects, which allow more freely reusing >> code without overbearing legal issues, but these projects are a relative >> minority in FOSS land. > > we seem to be confusing different things (you seem to move the goal- > posts) > > 1. I asked why you would write your own sort rather than use qsort() > as a first pass. > > 2. you recomended copy-paste as a devlopment methodolgy. I think > it's hardly ever a reasonable thing to do. And is responsible for much > "software rot". > > 3. you (reasonably) use license problems as a reason to reinvent the > wheel. > > 3 is not a justification for either 1 or 2 > hell, who knows, I go wherever the topic takes me, and have never really been so good with keeping on-topic anyways... or such...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-09-09 11:38 +1200 |
| Subject | Re: Generally, are the programs written by C++ slower than written by C 10% ? |
| Message-ID | <9ct1v3Fn7mU2@mid.individual.net> |
| In reply to | #9945 |
On 09/ 9/11 11:24 AM, BGB wrote: > On 9/7/2011 2:52 AM, Nick Keighley wrote: >> On Sep 6, 3:33 pm, BGB<cr88...@hotmail.com> wrote: >>> On 9/6/2011 12:32 AM, Nick Keighley wrote: >>> >>> >>> >>> >>> >>>> On Sep 5, 10:06 pm, BGB<cr88...@hotmail.com> wrote: >>>>> On 9/5/2011 12:51 PM, Ian Collins wrote: >>>>>> On 09/ 6/11 07:34 AM, BGB wrote: >>> >>>> <snip> >>> >>>>>>> copy-paste is a powerful tool which is often disparaged and overlooked. >>> >>>>>> Rightly so. C has things call functions that enable code to be reused >>>>>> and C++ has function templates that remove the last excuse for copy and >>>>>> paste. >>> >>>>>>> but, one would typically write it themselves initially (before >>>>>>> subjecting it to endless copy-paste). >> >> you appear to be trying to justify copy-paste >> > > of ones' own code... > > copy/paste may well be justified in some cases, such as to avoid > creating a physical dependency between unrelated components, whereas > traditional code-reuse creates dependencies by extension. What? By that logic, all libraries should be removed and their source code copied instead. Lunacy. If you are that paranoid about dependencies, put each function in a header and include that... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-08 21:39 -0700 |
| Subject | Re: Generally, are the programs written by C++ slower than written by C 10% ? |
| Message-ID | <j4c5a0$lpo$1@news.albasani.net> |
| In reply to | #9947 |
On 9/8/2011 4:38 PM, Ian Collins wrote: > On 09/ 9/11 11:24 AM, BGB wrote: >> On 9/7/2011 2:52 AM, Nick Keighley wrote: >>> On Sep 6, 3:33 pm, BGB<cr88...@hotmail.com> wrote: >>>> On 9/6/2011 12:32 AM, Nick Keighley wrote: >>>> >>>> >>>> >>>> >>>> >>>>> On Sep 5, 10:06 pm, BGB<cr88...@hotmail.com> wrote: >>>>>> On 9/5/2011 12:51 PM, Ian Collins wrote: >>>>>>> On 09/ 6/11 07:34 AM, BGB wrote: >>>> >>>>> <snip> >>>> >>>>>>>> copy-paste is a powerful tool which is often disparaged and >>>>>>>> overlooked. >>>> >>>>>>> Rightly so. C has things call functions that enable code to be >>>>>>> reused >>>>>>> and C++ has function templates that remove the last excuse for >>>>>>> copy and >>>>>>> paste. >>>> >>>>>>>> but, one would typically write it themselves initially (before >>>>>>>> subjecting it to endless copy-paste). >>> >>> you appear to be trying to justify copy-paste >>> >> >> of ones' own code... >> >> copy/paste may well be justified in some cases, such as to avoid >> creating a physical dependency between unrelated components, whereas >> traditional code-reuse creates dependencies by extension. > > What? By that logic, all libraries should be removed and their source > code copied instead. Lunacy. > it is a tradeoff: going this route (entirely) would tend to make many projects overly large. > If you are that paranoid about dependencies, put each function in a > header and include that... > but one still depends on the header, and depending on a header isn't necessarily all that much better (however, I have done similar for a few things, as the compiler tends to omit any static functions which are never called, ...). a partial advantage of headers is that they themselves can be more readily copy-pasted and need not create additional dependencies, however a partial disadvantage is that headers like this can potentially cause horrible compile-time performance and a lot of unnecessary bloat, so it is a tradeoff (it is bad enough when one already ends up with several MB of included code just including many basic OS headers). but, typically, one will copy/paste code, and use find/replace or sed to re-scope it (replacing library/component prefixes or similar), and then edit the code into the desired form for its use in a given component. but, otherwise, one ends up with lots of centralized code that ends up being depended on by lots of potentially unrelated things. however, code may be centralized if it makes sense, say if there is already a conceptually and mutually depended-on component, one may consider migrating shared code to this location, provided it can be sufficiently decoupled from its respective use-cases (does not have any dependencies on the code which uses it, ...). for example, memory management can be largely centralized (because most code does roughly the same sorts of things with a memory manager). likewise for things like filesystem interfacing, ... things like parser logic are typically copy-pasted all over and specialized for each use case, since it is far more difficult to separate a parser from its use-cases (a parser for XML, one for C, and one for ASM, and another for id/Valve/... style map files, ..., are each sufficiently different to make having common code problematic, but are sufficiently similar that it would be pointless to write the code entirely from-scratch each time). as well, things like variations in token rules and AST structure would likely be difficult to generalize without introducing a heavy overhead (such as doing tokenization via a regex-like system, ...). a partial edge case is something like a 3D renderer, which although having much variation between renderable objects, ... one gets a larger payoff by having a unified scene-graph and rendering architecture (for example, tasks like lighting and shadows can be kept more consistent, vs having each and every scene object try to implement its own lighting and shadowing algorithms). another reason for unifying a 3D renderer, and also things like a camera-control interface, ... is because a single user can only validly interact with a single renderer at a time, and so one may benefit some from scene-consolidation in this case (say, being able to have anything which may be rendered, be potentially usable in the same scene at the same time). granted, this says little regarding the need for several separate apps to have a shared 3D renderer, or potentially for a single 3D app to have only a single renderer (an example would be an app providing separate renderer implementations for OpenGL, DirectX, real-time software rendering, and high-quality offline batch rendering). in the above case, each may have sufficient differences between how they work, that addressing all of these cases via a single rendering backend may be unworkable (hence leading to separate implementations). similar may also apply to code which needs to be somewhat specialized for each OS, CPU architecture, ... or such...
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-09-09 19:01 +1200 |
| Subject | Re: Generally, are the programs written by C++ slower than written by C 10% ? |
| Message-ID | <9ctru0Fn7mU3@mid.individual.net> |
| In reply to | #9953 |
On 09/ 9/11 04:39 PM, BGB wrote: > On 9/8/2011 4:38 PM, Ian Collins wrote: >> On 09/ 9/11 11:24 AM, BGB wrote: >>> >>> copy/paste may well be justified in some cases, such as to avoid >>> creating a physical dependency between unrelated components, whereas >>> traditional code-reuse creates dependencies by extension. >> >> What? By that logic, all libraries should be removed and their source >> code copied instead. Lunacy. >> > > it is a tradeoff: > going this route (entirely) would tend to make many projects overly large. It also makes them exceedingly difficult to maintain. >> If you are that paranoid about dependencies, put each function in a >> header and include that... > > but one still depends on the header, and depending on a header isn't > necessarily all that much better (however, I have done similar for a few > things, as the compiler tends to omit any static functions which are > never called, ...). > > a partial advantage of headers is that they themselves can be more > readily copy-pasted and need not create additional dependencies, however > a partial disadvantage is that headers like this can potentially cause > horrible compile-time performance and a lot of unnecessary bloat, so it > is a tradeoff (it is bad enough when one already ends up with several MB > of included code just including many basic OS headers). Bollocks. If the code has to change, in my world the header changes and N source files that use it rebuild. In yours, you edit all N places you copied and pasted and N source files rebuild. I do 1/N times as much work and the compiler does the same in both cases. Now as for bloat, please explain how N function calls cause more bloat than N copy and pastes. > but, typically, one will copy/paste code, and use find/replace or sed to > re-scope it (replacing library/component prefixes or similar), and then > edit the code into the desired form for its use in a given component. Boy you sure like making work for your self, don't you? > but, otherwise, one ends up with lots of centralized code that ends up > being depended on by lots of potentially unrelated things. Just like the standard library! > however, code may be centralized if it makes sense, say if there is > already a conceptually and mutually depended-on component, one may > consider migrating shared code to this location, provided it can be > sufficiently decoupled from its respective use-cases (does not have any > dependencies on the code which uses it, ...). That's called a function template... > for example, memory management can be largely centralized (because most > code does roughly the same sorts of things with a memory manager). > likewise for things like filesystem interfacing, ... > > things like parser logic are typically copy-pasted all over and > specialized for each use case, since it is far more difficult to > separate a parser from its use-cases (a parser for XML, one for C, and > one for ASM, and another for id/Valve/... style map files, ..., are each > sufficiently different to make having common code problematic, but are > sufficiently similar that it would be pointless to write the code > entirely from-scratch each time). Those documents are all structured differently, so forcing the same parser logic on each would be folly. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-09 02:45 -0700 |
| Subject | Re: Generally, are the programs written by C++ slower than written by C 10% ? |
| Message-ID | <j4cn89$rv6$1@news.albasani.net> |
| In reply to | #9960 |
On 9/9/2011 12:01 AM, Ian Collins wrote: > On 09/ 9/11 04:39 PM, BGB wrote: >> On 9/8/2011 4:38 PM, Ian Collins wrote: >>> On 09/ 9/11 11:24 AM, BGB wrote: >>>> >>>> copy/paste may well be justified in some cases, such as to avoid >>>> creating a physical dependency between unrelated components, whereas >>>> traditional code-reuse creates dependencies by extension. >>> >>> What? By that logic, all libraries should be removed and their source >>> code copied instead. Lunacy. >>> >> >> it is a tradeoff: >> going this route (entirely) would tend to make many projects overly >> large. > > It also makes them exceedingly difficult to maintain. > >>> If you are that paranoid about dependencies, put each function in a >>> header and include that... >> >> but one still depends on the header, and depending on a header isn't >> necessarily all that much better (however, I have done similar for a few >> things, as the compiler tends to omit any static functions which are >> never called, ...). >> >> a partial advantage of headers is that they themselves can be more >> readily copy-pasted and need not create additional dependencies, however >> a partial disadvantage is that headers like this can potentially cause >> horrible compile-time performance and a lot of unnecessary bloat, so it >> is a tradeoff (it is bad enough when one already ends up with several MB >> of included code just including many basic OS headers). > > Bollocks. If the code has to change, in my world the header changes and > N source files that use it rebuild. In yours, you edit all N places you > copied and pasted and N source files rebuild. I do 1/N times as much > work and the compiler does the same in both cases. > this is the issue of "synchronization". if the code is such that a change would need to be propagated everywhere it is used, then it is not as good of a choice for copy/paste. most cases where copy/paste is sensibly used, are not cases where such synchronization is likely to be necessary. typically, each will drift apart, becoming functionally absorbed into whatever new use-case they are put into. > Now as for bloat, please explain how N function calls cause more bloat > than N copy and pastes. > if the functions are contained directly in the headers, the following happens: all of the code has to be included every time the header is included; one will often end up with a copy of any used function for *every* compilation unit which uses the header, which may well be far larger than the number of times it would have been sanely copy-pasted (probably once per library/component, which is really not as much of an issue if one breaks up their app into "libraries" of maybe 20-50 kloc...). say, a 1Mloc project is broken into 20 50 kloc components. now, if we copy-paste, maybe, 1 kloc of code to each, this only amounts to an additional 20 kloc over the entire project. now, if that 1 kloc is put in a header, and say, 100 loc worth of functions are used in each compilation unit, and each compilation unit is 1 kloc (so, 50 compilation units per library), this works out to around 100 kloc worth of overhead in the project. granted, IRL is is not likely to be so cleanly organized or predictable. >> but, typically, one will copy/paste code, and use find/replace or sed to >> re-scope it (replacing library/component prefixes or similar), and then >> edit the code into the desired form for its use in a given component. > > Boy you sure like making work for your self, don't you? > in practice, this has rarely been too big of an issue... after the copy/paste/edit process, most such code is entirely independent of its siblings/ancestors. it then gains a separate identity, and often its functional role may be notably altered in the process. >> but, otherwise, one ends up with lots of centralized code that ends up >> being depended on by lots of potentially unrelated things. > > Just like the standard library! > a project may end up looking much like a bunch of libraries. as-is, my project has 10MB worth of DLLs, spread over 22 libraries, and a codebase of ~ 820 kloc last I checked (it was around 1.25 Mloc, prior to the "great GPL purge" where I removed all code which was GPL, which at the time dropped the codebase to ~ 750 kloc). as for EXEs, there are 12MB spread over 50 files, many of these being "front ends" (which organize the libraries above into a particular "application" with a particular user interface). but, it is not like copy-paste is always the preferred option, and code may also be put into a shared location when: a good candidate for a shared location exists; the code is sufficiently independent of how it is being used (its functional behavior does not depend on external context, ...); doing this will not otherwise compromise the functional independence of the components involved; ... an example of compromising functional independence would be, for example, one suddenly finds that using the assembler also requires one to link against the C frontend, or the XML libraries, or the GUI subsystem, or the 3D renderer. so, the goal would be, say, that the assembler can be used independently, and doesn't require also using other components in order for it to be able to do its thing. likewise, the GUI widgets shouldn't require also linking against the assembler "just because...", even despite possibly some similar-looking code having been shared between them. sometimes, some basic level of, yes, copy-pasting crap, is necessary to help keep down such dependencies. another (macro-scale) example of such copy-pasting, are what are traditionally called "project forks". >> however, code may be centralized if it makes sense, say if there is >> already a conceptually and mutually depended-on component, one may >> consider migrating shared code to this location, provided it can be >> sufficiently decoupled from its respective use-cases (does not have any >> dependencies on the code which uses it, ...). > > That's called a function template... > or a library function in general... >> for example, memory management can be largely centralized (because most >> code does roughly the same sorts of things with a memory manager). >> likewise for things like filesystem interfacing, ... >> >> things like parser logic are typically copy-pasted all over and >> specialized for each use case, since it is far more difficult to >> separate a parser from its use-cases (a parser for XML, one for C, and >> one for ASM, and another for id/Valve/... style map files, ..., are each >> sufficiently different to make having common code problematic, but are >> sufficiently similar that it would be pointless to write the code >> entirely from-scratch each time). > > Those documents are all structured differently, so forcing the same > parser logic on each would be folly. > hence, why the logic is copy/pasted and edited to each particular use case... one doesn't have to write, say, a new fresh tokenizer each time, as an existing tokenizer may be "fairly close", and one can edit it for the particular types and rules of tokens one needs to parse (which types of tokens there are, which combinations of characters there are, ...). likewise goes for any particular logic related to the particular syntax. however, for sufficiently similar syntax, a shared parser may be used. for example, my C, Java, C#, and BGBScript2 compiler frontends all shared the same core parser and compiler logic, mostly using conditional logic to gloss over most language specific issues (enabling and disabling features, using alternate declaration-handling logic, ...). nevermind that my C compiler was itself mostly a fork of my BGBScript VM (which discarded the bytecode interpreter, and focused solely on the JIT), although each has developed independently (the idea with my now dead "BGBScript2" effort was to essentially try to re-unify my compiler and VM technology, leading to a single unified VM core which could handle languages ranging between plain C and a highly-dynamic JavaScript-like language, meanwhile, incorporating some amount of architecture similar to the JVM and .NET). however, this effort had design complexity issues which quickly ran out of control at the time, and effort was shifted to a far more conservative strategy: work on beating a lot of the new planned features onto the pre-existing BGBScript VM core (rather than invest all the time and effort in what was essentially a ground-up reimplementation of many core parts of the VM). for this more conservative effort, I ended up calling it "BGBScript 1.5", and it has implemented many of the planned language features for BS2 (although with me eventually opting with a more ActionScript3-like syntax, rather than the more Java+C# like syntax planned for BS2). or such...
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-09 03:23 -0700 |
| Message-ID | <26d8d585-f50f-4757-b1bf-e7112f69b6c3@bi2g2000vbb.googlegroups.com> |
| In reply to | #9960 |
On Sep 9, 8:01 am, Ian Collins <ian-n...@hotmail.com> wrote: > On 09/ 9/11 04:39 PM, BGB wrote: > > On 9/8/2011 4:38 PM, Ian Collins wrote: > >> On 09/ 9/11 11:24 AM, BGB wrote: > >>> copy/paste may well be justified in some cases, such as to avoid > >>> creating a physical dependency between unrelated components, whereas > >>> traditional code-reuse creates dependencies by extension. > > >> What? By that logic, all libraries should be removed and their source > >> code copied instead. Lunacy. > > > it is a tradeoff: > > going this route (entirely) would tend to make many projects overly > > large. <sarcasm> which copy-paste doesn't do at all... </sarcasm> > It also makes them exceedingly difficult to maintain. the first duty of the software engineer is to maintain the maintainability of the source base > >> If you are that paranoid about dependencies, put each function in a > >> header and include that... > > > but one still depends on the header, and depending on a header isn't > > necessarily all that much better why not? > > (however, I have done similar for a few > > things, as the compiler tends to omit any static functions which are > > never called, ...). > > > a partial advantage of headers is that they themselves can be more > > readily copy-pasted <bletch> > > and need not create additional dependencies, however > > a partial disadvantage is that headers like this can potentially cause > > horrible compile-time performance and a lot of unnecessary bloat, as does copy-paste. copy-paste is the ultimate bloat. > > so it > > is a tradeoff (it is bad enough when one already ends up with several MB > > of included code just including many basic OS headers). > > Bollocks. quite. > If the code has to change, in my world the header changes and > N source files that use it rebuild. In yours, you edit all N places you > copied and pasted and N source files rebuild. I do 1/N times as much > work and the compiler does the same in both cases. plus he has to get all those edits correct. His code must be a nightmare to work with > Now as for bloat, please explain how N function calls cause more bloat > than N copy and pastes. > > > but, typically, one will copy/paste code, and use find/replace or sed to > > re-scope it (replacing library/component prefixes or similar), and then > > edit the code into the desired form for its use in a given component. <bletch!> (that's factorial bletch) > Boy you sure like making work for your self, don't you? > > > but, otherwise, one ends up with lots of centralized code that ends up > > being depended on by lots of potentially unrelated things. you say this like its a bad thing... <snip>
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-09-14 23:12 +0000 |
| Subject | Re: Generally, are the programs written by C++ slower than written by C 10% ? |
| Message-ID | <slrnj72d7o.gtj.grahn+nntp@frailea.sa.invalid> |
| In reply to | #9960 |
On Fri, 2011-09-09, Ian Collins wrote: > On 09/ 9/11 04:39 PM, BGB wrote: ... [copy & paste programming] >> but, otherwise, one ends up with lots of centralized code that ends up >> being depended on by lots of potentially unrelated things. > > Just like the standard library! I mostly disagree with "BGB", but there *is* an additional cost in making some piece of code reusable and making a library out of it. (The cost of doing it well, or the cost of doing it badly.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-09-09 02:40 -0700 |
| Message-ID | <1fbcf3b9-4cfd-496a-b7c9-1f61016ec09f@y21g2000yqk.googlegroups.com> |
| In reply to | #9945 |
On Sep 9, 12:24 am, BGB <cr88...@hotmail.com> wrote: > On 9/7/2011 2:52 AM, Nick Keighley wrote: > > On Sep 6, 3:33 pm, BGB<cr88...@hotmail.com> wrote: > >> On 9/6/2011 12:32 AM, Nick Keighley wrote: > >>> On Sep 5, 10:06 pm, BGB<cr88...@hotmail.com> wrote: > >>>> On 9/5/2011 12:51 PM, Ian Collins wrote: > >>>>> On 09/ 6/11 07:34 AM, BGB wrote: <snip> > >>>>>> but, one would typically write it themselves initially (before > >>>>>> subjecting it to endless copy-paste). > > > you appear to be trying to justify copy-paste > > of ones' own code... I don't really care whose code. It was copy-paste /itself/ I was railing against. > copy/paste may well be justified in some cases, such as to avoid > creating a physical dependency between unrelated components, but creating a copy-paste coupling. What you call the "synchronisation problem". I'd have thought the avoidance of physical coupling was quite rare but you use the phrase "subjecting it to endless copy- paste" implying copy-paste is pretty widespread in your world. > whereas > traditional code-reuse creates dependencies by extension. what? > however, copy-paste from others' code is plagiarism and may also be > illegal. quite. But it wasn't what i talkign about. > >>>>> Not if they were being paid to deliver software. > > >>>> well, if they just copy/paste it from existing sources, they may be > >>>> stuck with GPL nastiness or similar (since, annoyingly, the majority of > >>>> existing/FOSS source is GPL), so writing it initially will give them a > >>>> version for which they control the license (while still being legal, and > >>>> not simply "forgetting" the per-existing license terms). > > > this is a reason for writing stuff yourself. it is /not/ a reason for > > copy-paste. If you've written the code yourself why not package it in > > reusable form? > > typically because this creates dependencies between ones' components. bung it in a shared library. Didn't they invent this concept in about 1955? > factoring things out to eliminate dependencies while still having > code-reuse may often introduce a fair amount of additional architectural > complexity (reuse via "mutual 3rd parties", ...). I don't understand why it's *that* hard. > copy-paste allows physical decoupling without the need to create "3rd > parties". > > a problem though is when copy-paste introduces "synchronization issues", > which yes, can be a nasty problem. indeed. I thinks it's a major malaise. > ideally code should not be > copy-pasted in this case, or any such synchronization should be defined > as part of the "formal model" of whatever code or data is in question > (an example is things like codecs, where it is assumed that whatever > comes back out is whatever the encoder intended to come out, ...). lost me. Are you saying the encode side shares code with the decode side? <snip> > >> now, extend this generally, and note that most freely-available code is > >> either proprietary (can't be reused safely at all) or GPL, > > > but not the standard libraries of either C or C++. There's also quite > > a bit of BSD licensed code about. > > actually, several major implementations (glib, newlib, ...), are "GPL > with linking exception" and similar. so you *can* use qsort() <snip> > > we seem to be confusing different things (you seem to move the goal- > > posts) > > > 1. I asked why you would write your own sort rather than use qsort() > > as a first pass. > > > 2. you recomended copy-paste as a devlopment methodolgy. I think > > it's hardly ever a reasonable thing to do. And is responsible for much > > "software rot". > > > 3. you (reasonably) use license problems as a reason to reinvent the > > wheel. > > > 3 is not a justification for either 1 or 2 > > hell, who knows, I go wherever the topic takes me, and have never really > been so good with keeping on-topic anyways... > > or such... I wasn't complaining about topicality. Just that your frequent segways make it very difficult to work out what you are trying to say. I almost get the idea you use copy-paste a lot and are now making up reasons for it. The REAL reason people use copy-paste is because it's expedient. It's quicker (right now) to CP and hang the longer term consequences. In the long run we're all dead anyway.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@hotmail.com> |
|---|---|
| Date | 2011-09-09 11:19 -0700 |
| Message-ID | <j4dlbj$7am$1@news.albasani.net> |
| In reply to | #9963 |
On 9/9/2011 2:40 AM, Nick Keighley wrote:
> On Sep 9, 12:24 am, BGB<cr88...@hotmail.com> wrote:
>> On 9/7/2011 2:52 AM, Nick Keighley wrote:
>>> On Sep 6, 3:33 pm, BGB<cr88...@hotmail.com> wrote:
>>>> On 9/6/2011 12:32 AM, Nick Keighley wrote:
>>>>> On Sep 5, 10:06 pm, BGB<cr88...@hotmail.com> wrote:
>>>>>> On 9/5/2011 12:51 PM, Ian Collins wrote:
>>>>>>> On 09/ 6/11 07:34 AM, BGB wrote:
>
> <snip>
>
>>>>>>>> but, one would typically write it themselves initially (before
>>>>>>>> subjecting it to endless copy-paste).
>>
>>> you appear to be trying to justify copy-paste
>>
>> of ones' own code...
>
> I don't really care whose code. It was copy-paste /itself/ I was
> railing against.
>
>> copy/paste may well be justified in some cases, such as to avoid
>> creating a physical dependency between unrelated components,
>
> but creating a copy-paste coupling. What you call the "synchronisation
> problem". I'd have thought the avoidance of physical coupling was
> quite rare but you use the phrase "subjecting it to endless copy-
> paste" implying copy-paste is pretty widespread in your world.
>
well, it is not exactly unheard of...
for example, reasonably recently I was working on making my 3D engine
have a "server end" (in the Quake sense, where the "client" manages 3D
rendering and user input, and the "server" manages all of the world
physics, AIs, ...).
so, one has an issue:
both the 3D renderer, and server, have a need for things like
map-loading/BSPs/...
one option would have been to split the BSP code off from the rendering
code, leaving both the renderer and server depending on it.
however, these was no good choice of a library shared directly between
them, so one would have to be created.
also, one didn't want a direct dependency (say, server needs 3D renderer
to work), because they may be used independently (and "dedicated server
needs OpenGL window" would be silly).
great solution:
copy-paste this whole region of the 3D renderer into the server, and
then remove any 3D rendering stuff from the server copy.
in all, it has worked out fairly well.
but, there are other examples (parsers, codegen logic, ...).
one annoyance that has popped up a few times is that the code often
looks similar enough that when working on both at the same time, one may
end up applying edits to one meant for the other. but, this is a minor
issue.
this was partly because, annoyingly, adding support for bezier patches
and Doom3 map files did imply applying edits to both.
however, this case is fairly rare, as usually the versions are
independent (one does not synchronize changes, but only
modifies/fixes/... the version one is dealing with at the moment).
>
>> whereas
>> traditional code-reuse creates dependencies by extension.
>
> what?
>
everyone who uses the code has to also link against it.
if a project gets largish, then this becomes a much bigger issue, like
which library depends on which, ...
these issues become far more apparent when building for Linux, as every
library dependency needs an "-l/name/" option, which may need to be
added to every Makefile which uses said library, ...
so, one could almost make a big flowchart of which libraries may depend
on which other libraries, ... (if one is into flowcharts and so on).
>> however, copy-paste from others' code is plagiarism and may also be
>> illegal.
>
> quite. But it wasn't what i talkign about.
>
fair enough, but someone mentioned copy-pasting others' code.
>>>>>>> Not if they were being paid to deliver software.
>>
>>>>>> well, if they just copy/paste it from existing sources, they may be
>>>>>> stuck with GPL nastiness or similar (since, annoyingly, the majority of
>>>>>> existing/FOSS source is GPL), so writing it initially will give them a
>>>>>> version for which they control the license (while still being legal, and
>>>>>> not simply "forgetting" the per-existing license terms).
>>
>>> this is a reason for writing stuff yourself. it is /not/ a reason for
>>> copy-paste. If you've written the code yourself why not package it in
>>> reusable form?
>>
>> typically because this creates dependencies between ones' components.
>
> bung it in a shared library. Didn't they invent this concept in about
> 1955?
>
shared libraries and DLLs have their own drawbacks, and managing them
gets more complex into the double-digits of libraries, so it is
preferable to avoid creating new ones when possible.
>
>> factoring things out to eliminate dependencies while still having
>> code-reuse may often introduce a fair amount of additional architectural
>> complexity (reuse via "mutual 3rd parties", ...).
>
> I don't understand why it's *that* hard.
>
adding a new library (3rd party) may often involve much editing of
Makefile's.
when using the traditional "parallel trees of per-target Makefile's"
strategy, one generally wants to avoid any non-trivial changes to the
build-tree when possible, because it is a hassle.
granted, I guess some projects also end up tooling up their Makefile
tree as well, or switching to non-Makefile alternatives (such as "GNU
autoconf", "CMake", ...).
>> copy-paste allows physical decoupling without the need to create "3rd
>> parties".
>>
>> a problem though is when copy-paste introduces "synchronization issues",
>> which yes, can be a nasty problem.
>
> indeed. I thinks it's a major malaise.
>
not as big of an issue though, if following the copy, the code is
treated independently.
>
>> ideally code should not be
>> copy-pasted in this case, or any such synchronization should be defined
>> as part of the "formal model" of whatever code or data is in question
>> (an example is things like codecs, where it is assumed that whatever
>> comes back out is whatever the encoder intended to come out, ...).
>
> lost me. Are you saying the encode side shares code with the decode
> side?
>
nope, typically, the specification for the codec will specify things
like rounding behavior and many other subtle details.
another example would be, say, two pieces of code assume that given
entities will be numbered according to a certain algorithm, so, for sake
of interaction one writes it up in the spec what is the algorithm for
numbering things, ...
some algorithms may also depend on the hash function as well, so the
hash function is also a part of the spec.
...
> <snip>
>
>>>> now, extend this generally, and note that most freely-available code is
>>>> either proprietary (can't be reused safely at all) or GPL,
>>
>>> but not the standard libraries of either C or C++. There's also quite
>>> a bit of BSD licensed code about.
>>
>> actually, several major implementations (glib, newlib, ...), are "GPL
>> with linking exception" and similar.
>
> so you *can* use qsort()
>
yes, but it doesn't mean qsort is *good*...
> <snip>
>
>>> we seem to be confusing different things (you seem to move the goal-
>>> posts)
>>
>>> 1. I asked why you would write your own sort rather than use qsort()
>>> as a first pass.
>>
>>> 2. you recomended copy-paste as a devlopment methodolgy. I think
>>> it's hardly ever a reasonable thing to do. And is responsible for much
>>> "software rot".
>>
>>> 3. you (reasonably) use license problems as a reason to reinvent the
>>> wheel.
>>
>>> 3 is not a justification for either 1 or 2
>>
>> hell, who knows, I go wherever the topic takes me, and have never really
>> been so good with keeping on-topic anyways...
>>
>> or such...
>
> I wasn't complaining about topicality. Just that your frequent segways
> make it very difficult to work out what you are trying to say.
>
> I almost get the idea you use copy-paste a lot and are now making up
> reasons for it.
>
> The REAL reason people use copy-paste is because it's expedient. It's
> quicker (right now) to CP and hang the longer term consequences. In
> the long run we're all dead anyway.
>
why not do whatever is more expedient?...
it is more a big question of time-saving option A vs time-saving option
B, and how each will impact the codebase, and also, which will be faster
and less effort.
but, anyways, why should one care about distant future stuff, when they
have all the stuff going on now to worry about?...
like, tomorrow creates its own worries, and one can deal with today's
worries today.
years from now?... who knows, who cares... maybe all the code will be
dead, or maybe its problems will have been fixed, but really it doesn't
matter because it is a long ways off, and one gains little by sitting
around and twiddling their thumbs worrying about the distant future.
granted, yes, it is pointless worrying about the past as well ("glory
days", "lost loves", ... bleh...).
or such...
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2011-09-09 15:42 -0500 |
| Message-ID | <Xns9F5BF1263CA99myfirstnameosapriee@216.196.109.131> |
| In reply to | #9995 |
BGB <cr88192@hotmail.com> wrote in news:j4dlbj$7am$1@news.albasani.net: > if a project gets largish, then this becomes a much bigger issue, like > which library depends on which, ... > > these issues become far more apparent when building for Linux, as > every library dependency needs an "-l/name/" option, which may need to > be added to every Makefile which uses said library, ... Let's see: adding -l/name/ in a Makefile: 30 seconds; copy-pasting source code from other project, adding new files to the project, adding new files to the version control system: 15 minutes; fixing M bugs in N-1 diverged copies of source code and testing that the fix worked: M*(N-1) hours or more... I think I stick with the 30 seconds option! > > so, one could almost make a big flowchart of which libraries may > depend on which other libraries, ... (if one is into flowcharts and so > on). Of course the build system must know the dependencies of the libraries, otherwise it could not build them in the right order. BTW, the Makefile format is a convenient way to mark these dependencies. About flowcharts - I'm pretty sure the flowchart of our nightly build would not fit any printable sheet of paper, but fortunately no one has ever needed such a thing. Cheers Paavo
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web