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

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

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

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

Contents

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

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

#10001

On 9/9/2011 1:42 PM, Paavo Helde wrote:
> 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!
>

unless if applies to roughly 150 Makefiles, which is where the issue 
comes in (then one has to go through a cycle of adding "-l/name/" to 
each of them).

adding a few source files into a Makefile is also a lot easier than 
adding a new library to the project, since the source files may often 
only effect a single Makefile, whereas the addition of a library or 
moving some code from one library to another, may potentially effect 
*many* Makefiles.

in a few cases, I ended up putting several conceptually disjoint 
"libraries" into a single DLL/SO, mostly as to avoid the problem of 
having to go and update all of the Makefiles which depended on it.


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

typically, in my case, it is done recursively as several stages:
"includes", which rebuilds headers;
"libs", which rebuilds any libraries;
"apps", which rebuilds any binaries;
"meta", which rebuilds any metadata databases.

currently, source-processing/generating tools building is handled in the 
"includes" stage, meaning that any such tools can't depend on external 
headers or libraries (they need to be entirely self-contained, and are 
often implemented as single large source files and may be scattered 
throughout the project).

trying to address the tools issue would likely end up introducing 
additional stages, which would again, require going and making a bunch 
of edits to the Makefile tree.

at each level, one may have a command like "all: includes libs apps 
meta", to allow invoking make from various locations (rebuilding this 
particular branch of the toplevel).

also, in some cases, special build targets exist generally to allow 
omitting rebuilding parts of the project tree (mostly to save time, say, 
if I am only working on the 3D engine, I don't want to also be 
rebuilding all of the compiler and script-VM stuff...).


typically, each library also has its own little source tree, with a set 
of directory organization rules:
"base" generally for source code (others may be used);
"include" for headers;
"docs" for any library-specific documentation;
...


the overall build process is generally a big recursive make with each 
project directory level having its own set of Makefiles (sort of like in 
the Linux kernel or similar, or at least that is how it was back when I 
was messing with it, dunno if it is still this way now).


running a line counter for Makefiles:
10.84 kloc in 153 files.

yep...

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

#10006

On Sep 9, 2:24 pm, BGB <cr88...@hotmail.com> wrote:
> On 9/9/2011 1:42 PM, Paavo Helde wrote:
>
> > BGB<cr88...@hotmail.com>  wrote innews: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!
>
> unless if applies to roughly 150 Makefiles, which is where the issue
> comes in (then one has to go through a cycle of adding "-l/name/" to
> each of them).
>
> adding a few source files into a Makefile is also a lot easier than
> adding a new library to the project, since the source files may often
> only effect a single Makefile, whereas the addition of a library or
> moving some code from one library to another, may potentially effect
> *many* Makefiles.

This sounds to be like a rather absurd response.  Certainly at a point
at which one is tempted to copy/paste and is evaluating the cost of
maintaining that copy/pasted code vs. refactoring into a new source
file, the risk of cascading dependencies is limited.  Certainly also
when one is tempted to copy paste large sections of code and
evaluating the cost of maintaining that disaster vs. refactoring into
a library, a limited number of dependencies upon that library exist.
Thus claiming that you'd have to then modify an inordinately large
amount of Makefiles to satisfy the refactor seems to me to be nothing
but a bunch of hand waving and panic.

Clearly if refactoring one source file out of one library into another
causes you to have to edit ALL the Makefiles in your project your
project's build system is configured quite poorly.

On the other hand, once the decision to copy/paste rather than
refactor has been made, and the rot has permeated the entire source
tree, it becomes a much larger project to refactor that mess away.
That of course must be granted but I think its a red herring here
since the crux of the argument is that you don't succumb to these
temptations and thus don't pay these extraordinary costs.

The standard approach is to recognize that you are tempted to use copy/
paste coding, recognize that succumbing to that temptation can come at
a very high maintenance cost, and instead factor the code you want to
reuse into a library as a FIRST step.  At that point there's only one
dependency on the new library and the effort to add it to the build
system should be quite minimal.  Compile, test...pass...use the new
library at the new location where you're adding a single, new
dependency and again the impact on the build system should be
negligible.

I might also suggest that if you're actually coding in Make by
hand...you're living in the dark ages.  But then one who sees C++ as
nothing but "convenient" extensions to C is probably quite comfortable
there.

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

#10036

On 9/9/2011 6:22 PM, Noah Roberts wrote:
> On Sep 9, 2:24 pm, BGB<cr88...@hotmail.com>  wrote:
>> On 9/9/2011 1:42 PM, Paavo Helde wrote:
>>
>>> BGB<cr88...@hotmail.com>    wrote innews: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!
>>
>> unless if applies to roughly 150 Makefiles, which is where the issue
>> comes in (then one has to go through a cycle of adding "-l/name/" to
>> each of them).
>>
>> adding a few source files into a Makefile is also a lot easier than
>> adding a new library to the project, since the source files may often
>> only effect a single Makefile, whereas the addition of a library or
>> moving some code from one library to another, may potentially effect
>> *many* Makefiles.
>
> This sounds to be like a rather absurd response.  Certainly at a point
> at which one is tempted to copy/paste and is evaluating the cost of
> maintaining that copy/pasted code vs. refactoring into a new source
> file, the risk of cascading dependencies is limited.  Certainly also
> when one is tempted to copy paste large sections of code and
> evaluating the cost of maintaining that disaster vs. refactoring into
> a library, a limited number of dependencies upon that library exist.
> Thus claiming that you'd have to then modify an inordinately large
> amount of Makefiles to satisfy the refactor seems to me to be nothing
> but a bunch of hand waving and panic.
>
> Clearly if refactoring one source file out of one library into another
> causes you to have to edit ALL the Makefiles in your project your
> project's build system is configured quite poorly.
>

well, the great issue is that one can't just be like (to make) "hey, 
this code moved from over here to over there and now anything which 
depends on X also needs to depend on Y".

hence, why one does need to edit the makefiles, especially for changes 
near the project core (which may effect many potential clients of the 
library).


> On the other hand, once the decision to copy/paste rather than
> refactor has been made, and the rot has permeated the entire source
> tree, it becomes a much larger project to refactor that mess away.
> That of course must be granted but I think its a red herring here
> since the crux of the argument is that you don't succumb to these
> temptations and thus don't pay these extraordinary costs.
>
> The standard approach is to recognize that you are tempted to use copy/
> paste coding, recognize that succumbing to that temptation can come at
> a very high maintenance cost, and instead factor the code you want to
> reuse into a library as a FIRST step.  At that point there's only one
> dependency on the new library and the effort to add it to the build
> system should be quite minimal.  Compile, test...pass...use the new
> library at the new location where you're adding a single, new
> dependency and again the impact on the build system should be
> negligible.
>

for a codebase written by myself and having been maintained since around 
the late 90s, it has probably achieved roughly a state of equilibrium...


> I might also suggest that if you're actually coding in Make by
> hand...you're living in the dark ages.  But then one who sees C++ as
> nothing but "convenient" extensions to C is probably quite comfortable
> there.

it is hand-written Makefiles, and actually parallel Makefile trees for 
each build target. I think originally I got the idea from NASM or 
something, and used it more generally.

hence, a "Makefile.msvc" and "Makefile.lnx" build tree (Windows/MSVC and 
Linux).
others, like "Makefile.cyg" and "Makefile.mingw" were past, but no 
longer maintained, trees (for cygwin and mingw).

there is also "Makefile.lnxcc" which was for Linux cross-compiling to 
ARM (because rebuilding the project inside an ARM emulator was very slow).


generally, it is less effort to do things in source than in Makefiles, 
so due to the way my system works, I usually include all of the 
target-specific source-files in every build target (then one can have 
the list of source files be equivalent between all targets), but use 
'#ifdef' to exclude the contents of files which are not needed.


in general though, it all works fairly well...

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

#10037

On Sep 10, 10:11 am, BGB <cr88...@hotmail.com> wrote:
> On 9/9/2011 6:22 PM, Noah Roberts wrote:
>
>
>
>
>
>
>
>
>
> > On Sep 9, 2:24 pm, BGB<cr88...@hotmail.com>  wrote:
> >> On 9/9/2011 1:42 PM, Paavo Helde wrote:
>
> >>> BGB<cr88...@hotmail.com>    wrote innews: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!
>
> >> unless if applies to roughly 150 Makefiles, which is where the issue
> >> comes in (then one has to go through a cycle of adding "-l/name/" to
> >> each of them).
>
> >> adding a few source files into a Makefile is also a lot easier than
> >> adding a new library to the project, since the source files may often
> >> only effect a single Makefile, whereas the addition of a library or
> >> moving some code from one library to another, may potentially effect
> >> *many* Makefiles.
>
> > This sounds to be like a rather absurd response.  Certainly at a point
> > at which one is tempted to copy/paste and is evaluating the cost of
> > maintaining that copy/pasted code vs. refactoring into a new source
> > file, the risk of cascading dependencies is limited.  Certainly also
> > when one is tempted to copy paste large sections of code and
> > evaluating the cost of maintaining that disaster vs. refactoring into
> > a library, a limited number of dependencies upon that library exist.
> > Thus claiming that you'd have to then modify an inordinately large
> > amount of Makefiles to satisfy the refactor seems to me to be nothing
> > but a bunch of hand waving and panic.
>
> > Clearly if refactoring one source file out of one library into another
> > causes you to have to edit ALL the Makefiles in your project your
> > project's build system is configured quite poorly.
>
> well, the great issue is that one can't just be like (to make) "hey,
> this code moved from over here to over there and now anything which
> depends on X also needs to depend on Y".

Except that this is not how things work on any platform I know of.
Clients of a library only need to link to the dependencies of that
library if it uses them.  The library links to those parts that it
needs already.

In other words, you have component A, which depends on component B.
You pull some internal parts out from component B into component C so
that they can also be used by component D (they are internal because
if they were public you could just link to component B itself).  The
changed component B links to the new component C and those parts that
are used by it are included in the library.  The original component A
dependencies do not change.

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

#10038

On 9/10/2011 10:54 AM, Noah Roberts wrote:
> On Sep 10, 10:11 am, BGB<cr88...@hotmail.com>  wrote:
>> On 9/9/2011 6:22 PM, Noah Roberts wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> On Sep 9, 2:24 pm, BGB<cr88...@hotmail.com>    wrote:
>>>> On 9/9/2011 1:42 PM, Paavo Helde wrote:
>>
>>>>> BGB<cr88...@hotmail.com>      wrote innews: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!
>>
>>>> unless if applies to roughly 150 Makefiles, which is where the issue
>>>> comes in (then one has to go through a cycle of adding "-l/name/" to
>>>> each of them).
>>
>>>> adding a few source files into a Makefile is also a lot easier than
>>>> adding a new library to the project, since the source files may often
>>>> only effect a single Makefile, whereas the addition of a library or
>>>> moving some code from one library to another, may potentially effect
>>>> *many* Makefiles.
>>
>>> This sounds to be like a rather absurd response.  Certainly at a point
>>> at which one is tempted to copy/paste and is evaluating the cost of
>>> maintaining that copy/pasted code vs. refactoring into a new source
>>> file, the risk of cascading dependencies is limited.  Certainly also
>>> when one is tempted to copy paste large sections of code and
>>> evaluating the cost of maintaining that disaster vs. refactoring into
>>> a library, a limited number of dependencies upon that library exist.
>>> Thus claiming that you'd have to then modify an inordinately large
>>> amount of Makefiles to satisfy the refactor seems to me to be nothing
>>> but a bunch of hand waving and panic.
>>
>>> Clearly if refactoring one source file out of one library into another
>>> causes you to have to edit ALL the Makefiles in your project your
>>> project's build system is configured quite poorly.
>>
>> well, the great issue is that one can't just be like (to make) "hey,
>> this code moved from over here to over there and now anything which
>> depends on X also needs to depend on Y".
>
> Except that this is not how things work on any platform I know of.
> Clients of a library only need to link to the dependencies of that
> library if it uses them.  The library links to those parts that it
> needs already.
>

on some platforms, this is how it works, but not on all of them.


> In other words, you have component A, which depends on component B.
> You pull some internal parts out from component B into component C so
> that they can also be used by component D (they are internal because
> if they were public you could just link to component B itself).  The
> changed component B links to the new component C and those parts that
> are used by it are included in the library.  The original component A
> dependencies do not change.

Windows does this with DLLs...
in this way, everything "just works" on Windows.


but, for whatever reason, on Linux with shared-objects, one seems to 
have to link against *every* dependency when linking the final binary, 
otherwise apparently "ld.so" or similar will throw a fit that it 
couldn't find a bunch of functions when trying to load the program.


this means, say, if they give "-lm" or "-ldl" to one of the libraries, 
they may also have to be sure to supply "-lm" or "-ldl" with the main 
binary (even if the main binary itself does not directly use the math 
functions or dlopen or similar, ...).

everything will link, so the linker seems to be happy, but it will barf 
once one tries to load/run the program.


why?... who knows, it just seems to work this way, unless there is a bug 
somewhere?... (but, all of the other programs work, so this is likely 
the intended design). for all I know it could also have something to do 
with "-Wl,-rpath,..." as well (needed as I tend not to install my apps 
into "/usr/bin" and "/usr/lib64" or similar, which is generally assumed 
by the OS, rather than, say, Windows, which will check the current 
directory followed by everything in the PATH variable).


similar applies to the case where one is using static libraries, except 
in this case "ld" will generally barf ("undefined symbol ..."), rather 
than the program failing to load.

the eventual result generally being that adding a dependency "somewhere 
down the line" may require propagating the dependency up-the-tree.


granted, I guess most people seem to use autoconf on Linux, which seems 
to do this by itself (but I never really liked autoconf personally, and 
it tends not really to work well on Windows anyways...).

I had looked at CMake and scons, and had partly considered the former, 
but haven't done much with it yet due to the effort which would be 
required to replace all the Makefiles with CMake scripts.


and, meanwhile, IRL just went was faced with the issue of a bunch of 
dirt needing to be dug to reconnect ones' driveway with the road, 
following some rain, and some people having torn up the road fairly bad 
trying to get their car unstuck (them having just using the "use lots of 
gas, dig a big hole" strategy) during said rain...


or such...

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

#10040

BGB <cr88192@hotmail.com> writes:
> but, for whatever reason, on Linux with shared-objects, one seems to
> have to link against *every* dependency when linking the final binary,
> otherwise apparently "ld.so" or similar will throw a fit that it
> couldn't find a bunch of functions when trying to load the program.

What?  That sounds completely wrong (so if you think it isn't, please
give more detail).

Shared libraries in linux have dependencies, just like programs, so
the end program only needs to link with the libraries it uses
directly; any "transitive" dependencies are pulled in automatically.

-Miles

-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

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

#10045

On 9/10/2011 8:29 PM, Miles Bader wrote:
> BGB<cr88192@hotmail.com>  writes:
>> but, for whatever reason, on Linux with shared-objects, one seems to
>> have to link against *every* dependency when linking the final binary,
>> otherwise apparently "ld.so" or similar will throw a fit that it
>> couldn't find a bunch of functions when trying to load the program.
>
> What?  That sounds completely wrong (so if you think it isn't, please
> give more detail).
>
> Shared libraries in linux have dependencies, just like programs, so
> the end program only needs to link with the libraries it uses
> directly; any "transitive" dependencies are pulled in automatically.
>

well, that is what one would think, and what would seem sane (for a 
sanely written loader), but for whatever reason (funky settings? bug? 
...) it wasn't really working last I tried dealing with the issue.

this was on Fedora 13 x86-64, FWIW, and I doubt there was anything 
seriously wrong with the install/..., or else, the thing probably 
wouldn't boot up correctly.


may well happen to deal with the fact that I use RPATH so that the PWD 
is checked for dependencies, although I have little idea why that might 
effect much, except that this is the only thing really "unusual" I think 
is being done here.


FWIW, below is the Linux-specific portion of one of the Makefiles (for 
one of the core libraries):
<--
BUILD=.
MKSUF=.lnx
LIBSUF=.a
DLLSUF=.so
EXESUF=.elf
OBJSUF=.o
DLLPF=lib

CC_OUTEXE=gcc -o
CC_OUTDLL=gcc -shared -o
CC_OUTOBJ=gcc -c -o
CC_OUTTOOL=gcc -o

EXE = .elf
BIN = .bin
O = .o
A = .a

CFLAGS=-Iinclude -I../include -g -pg
DLL_CFLAGS=$(CFLAGS) -DBGBDY_DLL
LDFLAGS=-g -pg -L. -lbgbdy -L.. -lbgbgc -lbgbdy -lbgbasm -lzpack -lm \
	-Wl,-rpath,"$$ORIGIN"
DLL_LDFLAGS=-L.. -lbgbgc -lbgbasm -lzpack -lm -fPIC \
	-Wl,-rpath,"$$ORIGIN"

include Makefile.inc
-->

and, for reference, the shared portion (the 'inc' file):
<--
#	base/memory2_2$(OBJSUF) \
#	base/int128$(OBJSUF) \

#	base/dyll_frame$(OBJSUF) \
#	base/dyll_frame_x86$(OBJSUF) \
#	base/dyll_frame_x64$(OBJSUF) \
#	base/dyc_rcit$(OBJSUF) \

OBJS=\
	base/prng$(OBJSUF) \
	base/int128$(OBJSUF) \
	base/float128$(OBJSUF) \
	\
	base/vfile2$(OBJSUF) \
	base/vfile2_dir$(OBJSUF) \
	base/vfile2_zip$(OBJSUF) \
	base/vfile2_zpak$(OBJSUF) \
	base/inflate$(OBJSUF) \
	base/deflate$(OBJSUF) \
	\
	base/netval$(OBJSUF) \
	\
	base/dyll_func$(OBJSUF) \
	base/dyll_func2$(OBJSUF) \
	base/dyll_func2_auto$(OBJSUF) \
	base/dyll_sig$(OBJSUF) \
	base/dyll_sig_arg$(OBJSUF) \
	base/dyll_sig_flags$(OBJSUF) \
	base/dyll_addr$(OBJSUF) \
	base/dyll_sigcache$(OBJSUF) \
	base/dyll_metapath$(OBJSUF) \
	base/dyll_catch$(OBJSUF) \
	base/dyll_thunk$(OBJSUF) \
	base/dyll_typebox$(OBJSUF) \
	base/dyll_mrbc2$(OBJSUF) \
	base/dyll_iface$(OBJSUF) \
	base/dyll_struct$(OBJSUF) \
	\
	base/sqlite3.c \
	base/dyll_sql$(OBJSUF) \
	\
	base/ty_complex$(OBJSUF) \
	base/ty_quat$(OBJSUF) \
	base/ty_matrix$(OBJSUF) \
	\
	base/dy_wref$(OBJSUF) \
	base/dy_strarith$(OBJSUF) \
	base/dy_chan$(OBJSUF) \
	base/dy_dytf$(OBJSUF) \
	\
	base/dy_method$(OBJSUF) \
	base/dy_oo$(OBJSUF) \
	base/dy_dyo$(OBJSUF) \
	base/dy_access$(OBJSUF) \
	\
	base/dyc_class$(OBJSUF) \
	base/dyc_lookup$(OBJSUF) \
	base/dyc_hash$(OBJSUF) \
	base/dyc_proto$(OBJSUF) \
	base/dyc_struct$(OBJSUF) \
	base/dyc_ns$(OBJSUF) \
	base/dyc_array$(OBJSUF) \
	base/dyc_api$(OBJSUF) \
	base/dyc_dyii$(OBJSUF) \
	\
	base/dyc_jni_fcn$(OBJSUF) \
	base/dyc_jni_iface$(OBJSUF) \
	base/dyc_jvmti_fcn$(OBJSUF) \
	base/dyc_jvmti_iface$(OBJSUF) \
	\
	base/dy_opr$(OBJSUF) \
	base/dy_cons$(OBJSUF) \
	base/dy_sparse$(OBJSUF) \
	base/dy_smxl$(OBJSUF) \
	base/dy_array$(OBJSUF) \
	base/dy_string$(OBJSUF) \
	\
	base/dy_xml$(OBJSUF) \
	base/dy_print$(OBJSUF) \
	base/dy_vli$(OBJSUF) \
	base/dys_binenc$(OBJSUF) \
	base/dys_bindec$(OBJSUF) \
	base/dys_parse$(OBJSUF) \
	base/dys_print$(OBJSUF) \
	base/dyx_parse$(OBJSUF) \
	base/dyx_print$(OBJSUF) \
	base/dyx_sbxe$(OBJSUF) \
	\
	base/dysh_console$(OBJSUF) \
	base/dysh_shell$(OBJSUF) \
	\
	base/bgbdy_api$(OBJSUF) \
	\
	bgal/bgal_main$(OBJSUF) \
	bgal/bgal_interp$(OBJSUF) \
	bgal/bgal_neuron$(OBJSUF)

SRCS=$(OBJS:$(OBJSUF)=.c)

DEP_HDRS = \
	include/bgbdy_auto.h \
	include/bgbdy_autoi.h \
	include/dyc_auto.h

all: libs apps

FORCE:

libs: $(DLLPF)bgbdy$(DLLSUF)
apps: dytst0$(EXESUF) tst_class0$(EXESUF) gatst0$(EXESUF)

includes: $(DEP_HDRS)

include/bgbdy_auto.h: autohead$(EXESUF) $(SRCS)
	./autohead$(EXESUF) -apionly BGBDY_API $(SRCS) > include/bgbdy_auto.h
include/bgbdy_autoi.h: autohead$(EXESUF) $(SRCS)
	./autohead$(EXESUF) -noapi BGBDY_API $(SRCS) > include/bgbdy_autoi.h

include/dyc_auto.h: autohead$(EXESUF) base/dyc_api.c base/dyc_array.c
	./autohead$(EXESUF) -api BGBDY_API base/dyc_api.c \
		base/dyc_array.c > include/dyc_auto.h

%$(OBJSUF): %.c
	$(CC_OUTOBJ)$@ $< $(CFLAGS)

# bgbdy.lib: $(DEP_HDRS) $(OBJS)
#	lib /out:bgbdy.lib $(OBJS)

$(DLLPF)bgbdy$(DLLSUF): $(DEP_HDRS) $(SRCS)
	$(CC_OUTDLL)$(DLLPF)bgbdy$(DLLSUF) $(SRCS) $(DLL_CFLAGS) $(DLL_LDFLAGS)

autohead$(EXESUF): autohead.c
	$(CC_OUTTOOL)autohead$(EXESUF) autohead.c

dytst0$(EXESUF): dytst0.c $(DEP_HDRS) libs
	$(CC_OUTEXE)dytst0$(EXESUF) dytst0.c $(CFLAGS) $(LDFLAGS)

tst_class0$(EXESUF): tst_class0.c $(DEP_HDRS) libs
	$(CC_OUTEXE)tst_class0$(EXESUF) tst_class0.c $(CFLAGS) $(LDFLAGS)

gatst0$(EXESUF): gatst0.c $(DEP_HDRS) libs
	$(CC_OUTEXE)gatst0$(EXESUF) gatst0.c $(CFLAGS) $(LDFLAGS)

clean:
-->

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

#10054

On Sep 10, 8:29 pm, Miles Bader <mi...@gnu.org> wrote:
> BGB <cr88...@hotmail.com> writes:
> > but, for whatever reason, on Linux with shared-objects, one seems to
> > have to link against *every* dependency when linking the final binary,
> > otherwise apparently "ld.so" or similar will throw a fit that it
> > couldn't find a bunch of functions when trying to load the program.
>
> What?  That sounds completely wrong (so if you think it isn't, please
> give more detail).
>
> Shared libraries in linux have dependencies, just like programs, so
> the end program only needs to link with the libraries it uses
> directly; any "transitive" dependencies are pulled in automatically.

This isn't true for my experience of Linux with gcc. However, I have
seen this on one other platform where the linker would complain if you
didn't give it all transitive shared-obj (aka shared-lib aka dlls) on
the command line for some cases. HP-UX maybe?

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

#10055

Joshua Maurice <joshuamaurice@gmail.com> writes:
>> Shared libraries in linux have dependencies, just like programs, so
>> the end program only needs to link with the libraries it uses
>> directly; any "transitive" dependencies are pulled in automatically.
>
> This isn't true for my experience of Linux with gcc. However, I have
> seen this on one other platform where the linker would complain if you
> didn't give it all transitive shared-obj (aka shared-lib aka dlls) on
> the command line for some cases. HP-UX maybe?

Here's an example:

# A very silly program (on Debian):

   $ cat > lt.cc <<EOF
   #include <ImfRgbaFile.h>
   int main () { Imf::RgbaInputFile inf ("oink", Imf::WRITE_RGBA); }
   EOF

# We only specify a single library at link-time, "libIlmImf":

   $ g++ -o lt -I/usr/include/OpenEXR lt.cc -lIlmImf

# Here's the dependencies in the resulting ELF file:

   $ readelf --dynamic lt | grep NEEDED
    0x0000000000000001 (NEEDED)             Shared library: [libIlmImf.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
    0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

# But if we look at the actual libraries actualy _used_ at runtime:

   $ ldd lt
	linux-vdso.so.1 =>  (0x00007fff66a8d000)
	libIlmImf.so.6 => /usr/lib/libIlmImf.so.6 (0x00007f063b738000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f063b42e000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f063b1ab000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f063af95000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f063ac11000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f063a9f8000)
	libImath.so.6 => /usr/lib/libImath.so.6 (0x00007f063a7f3000)
	libHalf.so.6 => /usr/lib/libHalf.so.6 (0x00007f063a5b1000)
	libIex.so.6 => /usr/lib/libIex.so.6 (0x00007f063a392000)
	libIlmThread.so.6 => /usr/lib/libIlmThread.so.6 (0x00007f063a18b000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0639f6f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f063ba20000)

# ... note there are a bunch of additional libraries!
#
# They are transitive dependencies, which came from the dependencies
# of "libIlmImf", the single library we linked with:

   $ readelf --dynamic /usr/lib/libIlmImf.so | grep NEEDED
    0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
    0x0000000000000001 (NEEDED)             Shared library: [libImath.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libHalf.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libIex.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libIlmThread.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
    0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
    0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]

-Miles

-- 
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

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

#10060

On Sep 12, 2:06 am, Miles Bader <mi...@gnu.org> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> >> Shared libraries in linux have dependencies, just like programs, so
> >> the end program only needs to link with the libraries it uses
> >> directly; any "transitive" dependencies are pulled in automatically.
>
> > This isn't true for my experience of Linux with gcc. However, I have
> > seen this on one other platform where the linker would complain if you
> > didn't give it all transitive shared-obj (aka shared-lib aka dlls) on
> > the command line for some cases. HP-UX maybe?
>
> Here's an example:
>
> # A very silly program (on Debian):

[snip]

Indeed. As I said, that's how things work on Linux. However, I'm
pretty sure the situation is different for at least 1 other unix-like
variant. It's annoying when I add a new dependency and forget to
update the makefiles to add the transitive dependency to all places
where it's needed. I haven't really looked at why it is, just
begrudgingly accepted it and moved on. (I have made somewhat of a fuss
over broken build practices, but they tell me to ignore it and move
on, so meh.)

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

#10066

Joshua Maurice <joshuamaurice@gmail.com> writes:
>> >> Shared libraries in linux have dependencies, just like programs, so
>> >> the end program only needs to link with the libraries it uses
>> >> directly; any "transitive" dependencies are pulled in automatically.
>>
>> > This isn't true for my experience of Linux with gcc.
>>
>> Here's an example:
>
> Indeed. As I said, that's how things work on Linux. 

Ah, ok; I thought when you said "this isn't true for my experience of
Linux with gcc", you were _disagreeing_ with what I said...

-Miles

-- 
"An atheist doesn't have to be someone who thinks he has a proof that
there can't be a god.  He only has to be someone who believes that the
evidence on the God question is at a similar level to the evidence on
the werewolf question."  [John McCarthy]

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

#10085

On Sep 12, 6:20 pm, Miles Bader <mi...@gnu.org> wrote:
> Joshua Maurice <joshuamaur...@gmail.com> writes:
> >> >> Shared libraries in linux have dependencies, just like programs, so
> >> >> the end program only needs to link with the libraries it uses
> >> >> directly; any "transitive" dependencies are pulled in automatically.
>
> >> > This isn't true for my experience of Linux with gcc.
>
> >> Here's an example:
>
> > Indeed. As I said, that's how things work on Linux.
>
> Ah, ok; I thought when you said "this isn't true for my experience of
> Linux with gcc", you were _disagreeing_ with what I said...
>
> -Miles
>
> --
> "An atheist doesn't have to be someone who thinks he has a proof that
> there can't be a god.  He only has to be someone who believes that the
> evidence on the God question is at a similar level to the evidence on
> the werewolf question."  [John McCarthy]

Ah, my mistake. I totally wrote that in a way that the wrong thing was
said. My apologies.

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

#10041

On Sat, 10 Sep 2011 14:28:45 -0700, BGB wrote:

> but, for whatever reason, on Linux with shared-objects, one seems to 
> have to link against *every* dependency when linking the final binary, 
> otherwise apparently "ld.so" or similar will throw a fit that it 
> couldn't find a bunch of functions when trying to load the program.

This shouldn't happen for correctly-built shared libraries (i.e. those
which have dependency information).

OTOH, static libraries don't have dependency information, so you need to
include indirect dependencies if you want to be able to build
statically-linked binaries for whatever reason.

> why?... who knows, it just seems to work this way, unless there is a bug 
> somewhere?... (but, all of the other programs work, so this is likely 
> the intended design). for all I know it could also have something to do 
> with "-Wl,-rpath,..." as well (needed as I tend not to install my apps 
> into "/usr/bin" and "/usr/lib64" or similar, which is generally assumed 
> by the OS, rather than, say, Windows, which will check the current 
> directory followed by everything in the PATH variable).

The loader needs to be able to find the libraries. Apart from any
directories embedded in the binary via -rpath, it uses /etc/ld.so.cache
(generated by ldconfig based upon the contents of /etc/ld.so.conf) and the
LD_LIBRARY_PATH environment variable.

If you use non-standard locations, you may need to add those to
/etc/ld.so.conf. You also need to run ldconfig when adding new libraries.

But this is unrelated to whether you add -l switches for indirect
dependencies.

> granted, I guess most people seem to use autoconf on Linux, which seems 
> to do this by itself (but I never really liked autoconf personally, and 
> it tends not really to work well on Windows anyways...).

autoconf is okay at what it does, but I draw the line there. I won't use
automake or libtool, as those tend to render the entire build process
unintelligible to anyone who isn't an automake/libtool guru. I expect
Makefiles to be human-readable.

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

#10044

Nobody <nobody@nowhere.com> writes:
> autoconf is okay at what it does, but I draw the line there. I won't use
> automake or libtool, as those tend to render the entire build process
> unintelligible to anyone who isn't an automake/libtool guru. I expect
> Makefiles to be human-readable.

I beg to differ.  The human-readable file when using automake is
"Makefile.am", which is far, far, nicer (readable, maintainable, etc)
than a hand-written Makefile for anything but the most utterly trivial
cases.  The language used by automake in Makefile.am is very nice.

As the process for generating Makefiles from Makefile.am is completely
automated and hands-free, there's no reason for users to ever look at
it.

_Very simple_ makefiles are generally pretty readable, but they very
quickly become a big mess of boilerplate.  Automake solves this
problem by generating the boilerplate automatically, so that humans
never have to look at it.

[my general habit is to write straight Makefiles at the beginning, and
eventually when the complexity exceeds some threshold, change to
automake -- which is accompanied by a huge reduction in complexity and
size, but a big increase in functionality .... win win all 'round basically...]

-Miles

-- 
Circus, n. A place where horses, ponies and elephants are permitted to see
men, women and children acting the fool.

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

#10030

On Sep 9, 7:19 pm, BGB <cr88...@hotmail.com> wrote:
> 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:

I'll probably give up. What you think is important is different from
what I think is important. And just bangin on about it isn't going to
change anyone's mind. I just thought people stopped writing code the
way you do sometime last century! I hope we never share a code base.


> >>>>>>>> but, one would typically write it themselves initially (before
> >>>>>>>> subjecting it to endless copy-paste).

<snip>

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

but is it incredible common ("yes" appears to be the answer)


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

sounds a reasonable architecture

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

yes. This is exactly what I would have done. It sounds likean
invoction of both the Single Responsibility Principle (SRP) *and*
Factor Mercilessly

> however, these was no good choice of a library shared directly between
> them, so one would have to be created.

and so? You make it sound like creating a library is some sort of big
deal! In full coding frenzy I must do it several times a day!

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

yes. Bonkers solution.

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

crap solution. You've bloated your code with two copies of the same
code. You've violated SRP and DRY (Don't repeat Yourself) and you now
have to debug the code twice. A maintenance nightmare. Go and read a
book on structured programming (I like Constantine and Yourdon)

> in all, it has worked out fairly well.
>
> but, there are other examples (parsers, codegen logic, ...).

and all have the same simple obvious answer. If you needd the same
thing in more than one place then package it up in re-usable form and
reuse it. Simple maintenance. Reduced bloat. Reduced debugging time.

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

well woop-y-doop. Who would have guessed *that* might happen. The
Database people talk about Normalised Form for damn good reasons. Just
as your data shouldn't be stored more than once (except for backup
purposes) so your code should not be in more than one place.

<snip>

> >>> [licenses] 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,

their drawbacks pale into insignificance compared with copy-paste-edit-
oops drawbacks

> and managing them
> gets more complex into the double-digits of libraries, so it is
> preferable to avoid creating new ones when possible.

I think you're fooling yourself if you think you've avoided these
problems

> >> 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", ...).

I've used makefiles in the past and I don't recall them being that
much of a pain. maybe you need to refactor your build system. Oh wait
do you copy-paste makefiles as well...

These days I use studio and adding anew project is a piece of piss.
And yes there are at least double digit number of libraries on the
software i usually work on

<snip>

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

all these decisions should be represented in code (or config files)
and should be shared between the two halves of the codec.


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

how do know its *bad*. I'm arguing you use qsort as your first choice
and IFF its shown to inadequate then you use something else. If I'm
sorting 20 items it probably doesn't matter what I use to sort things.

"Premature Optimisation is the root of all evil"

Probably applies more widely than software.

<snip>

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

because it bites you in the bum later when your code base decays into
an unmaintanable morass. I've seen a large program (all in one file!)
where the same thing was done in at least three different ways. As the
code grew larger (as copy-paste made inevitable) it grewer harder to
understand so more copy-pasting ensued. The compiler began to generate
bad code (the compiler writers used "short jumps" and the code was
just too big for this to work). There was a horrid positive feedback
causeing the program to grow like topsey. Many "happy" hours spent
debugging it.

> 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

when you've spent some time debugging someone elses code maybe you'll
chnage your mind.

Anyone remember "The Software Crisis". Is it back?

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

#9790

On Sep 6, 3:51 am, Ian Collins <ian-n...@hotmail.com> 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.
>
> >>> 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


My test code:

#include <iostream>
#include <string>
#include <cstring>

int main() {
        clock_t tbeg;

        {
                tbeg = clock();
                for (int i = 0; i < 10000000; i++)
                        std::string("hello, world!");

                std::cout << "test 1 use " << clock() - tbeg <<
std::endl;
        }

        {
                tbeg = clock();
                for (int i = 0; i < 10000000; i++) {
                        char* str = new char[20];
                        strcpy(str, "hello, world!");
                        delete [] str;
                }

                std::cout << "test 2 use " << clock() - tbeg <<
std::endl;
        }

        {
                tbeg = clock();
                for (int i = 0; i < 10000000; i++) {
                        char* str = (char*)malloc(20);
                        strcpy(str, "hello, world!");
                        free(str);
                }

                std::cout << "test 3 use " << clock() - tbeg <<
std::endl;
        }

        {
                tbeg = clock();
                for (int i = 0; i < 10000000; i++) {
                        char str[20];
                        strcpy(str, "hello, world!");
                }

                std::cout << "test 4 use " << clock() - tbeg <<
std::endl;
        }

        return 0;
}

output:
----------------------------
test 1 use 1260000
test 2 use 850000
test 3 use 610000
test 4 use 20000

So, could I think that if an object is constructed and destructed
frequently, I should make its member data are POD (not std::string or
some other expensive thing) ? Like this:

class temp_cache1 {
private:
        std::string s;
        std::vector<int> v;
};

class temp_cache2 {
private:
        char s[SIZE];
        int v[SIZE];
};

Here, is temp_cache2 better than temp_cache1?

I use valgrind trace the test program, found that the std::string
will allocation memory from heap even if the string is very short,
like std::string("abc"), it will allocation memory from heap.

So, either use temp_cache2 or use temp_cache1 and don't let it
destructed,
reuse its s and v. Am I right?

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

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

On 09/ 6/11 10:10 PM, KaiWen wrote:

>
> My test code:
>
> #include<iostream>
> #include<string>
> #include<cstring>
>
> int main() {
>          clock_t tbeg;
>
>          {
>                  tbeg = clock();
>                  for (int i = 0; i<  10000000; i++)
>                          std::string("hello, world!");
>
>                  std::cout<<  "test 1 use "<<  clock() - tbeg<<
> std::endl;
>          }
>
>          {
>                  tbeg = clock();
>                  for (int i = 0; i<  10000000; i++) {
>                          char* str = new char[20];
>                          strcpy(str, "hello, world!");
>                          delete [] str;
>                  }
>
>                  std::cout<<  "test 2 use "<<  clock() - tbeg<<
> std::endl;
>          }
>
>          {
>                  tbeg = clock();
>                  for (int i = 0; i<  10000000; i++) {
>                          char* str = (char*)malloc(20);
>                          strcpy(str, "hello, world!");
>                          free(str);
>                  }
>
>                  std::cout<<  "test 3 use "<<  clock() - tbeg<<
> std::endl;
>          }
>
>          {
>                  tbeg = clock();
>                  for (int i = 0; i<  10000000; i++) {
>                          char str[20];
>                          strcpy(str, "hello, world!");
>                  }
>
>                  std::cout<<  "test 4 use "<<  clock() - tbeg<<
> std::endl;
>          }
>
>          return 0;
> }
>
> output:
> ----------------------------
> test 1 use 1260000
> test 2 use 850000
> test 3 use 610000
> test 4 use 20000
>
> So, could I think that if an object is constructed and destructed
> frequently, I should make its member data are POD (not std::string or
> some other expensive thing) ? Like this:

Why do you think std::string is necessary expensive?  When I tried you 
code, I got

test 1 use 650000
test 2 use 660000
test 3 use 570000
test 4 use 0

> class temp_cache1 {
> private:
>          std::string s;
>          std::vector<int>  v;
> };
>
> class temp_cache2 {
> private:
>          char s[SIZE];
>          int v[SIZE];
> };
>
> Here, is temp_cache2 better than temp_cache1?
>
> I use valgrind trace the test program, found that the std::string
> will allocation memory from heap even if the string is very short,
> like std::string("abc"), it will allocation memory from heap.
>
> So, either use temp_cache2 or use temp_cache1 and don't let it
> destructed,
> reuse its s and v. Am I right?

If you want to avoid heap allocations and know your size requirements up 
front, then obviously a static solution will be faster.  Until you 
actually want to manipulate the strings....

-- 
Ian Collins

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

#9793

On 9月6日, 下午6时50分, Ian Collins <ian-n...@hotmail.com> wrote:

> Why do you think std::string is necessary expensive?  When I tried you
> code, I got
>
> test 1 use 650000
> test 2 use 660000
> test 3 use 570000
> test 4 use 0
>

I test the code in a virtual machine, Fedora 15 witch in the Virtual
Box.
756M memory, 2G HZ.

It is slower than malloc, it's true. Unless reuse it.

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

#9880

In article <08475db4-81c0-4e57-bddd-0c56107b6aed@n19g2000prh.googlegroups.com>,
KaiWen  <wenkai1987@gmail.com> wrote:
>On 9月6日, 下午6时50分, Ian Collins <ian-n...@hotmail.com> wrote:
>
>> Why do you think std::string is necessary expensive?  When I tried you
>> code, I got
>>
>> test 1 use 650000
>> test 2 use 660000
>> test 3 use 570000
>> test 4 use 0
>>
>
>I test the code in a virtual machine, Fedora 15 witch in the Virtual
>Box.
>756M memory, 2G HZ.

And what compiler did you use and what compilation options did you
use? 

We see that so often here, peoples that come up with an artificial
micro-benchmark to prove that their complex manual optimisation is
worthwhile but do not let the compiler do its job of optimising.

>It is slower than malloc, it's true. Unless reuse it.

Logically, std::string allocating a buffer is unlikely to be faster
than malloc for allocating memory.  However, micro-benchmark tend to
by pretty irrelevant in real programs.  They typically concentrate on
one single area while ignoring other potentially much more important
areas.   

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

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

On 09/ 7/11 09:45 PM, none Yannick Tremblay wrote:
> KaiWen<wenkai1987@gmail.com>  wrote:
>
>> It is slower than malloc, it's true. Unless reuse it.
>
> Logically, std::string allocating a buffer is unlikely to be faster
> than malloc for allocating memory.  However, micro-benchmark tend to
> by pretty irrelevant in real programs.  They typically concentrate on
> one single area while ignoring other potentially much more important
> areas.

Very true.  I have a conversion application that spends nearly all of 
its run time searching and modifying tens of thousands of strings. 
Allocation times are way way down the profiler's output.

-- 
Ian Collins

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

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

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

csiph-web