From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13703 invoked by alias); 28 Nov 2007 12:12:40 -0000 Received: (qmail 13694 invoked by uid 22791); 28 Nov 2007 12:12:39 -0000 X-Spam-Check-By: sourceware.org Received: from mail5.primus.ca (HELO mail-08.primus.ca) (216.254.141.172) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Nov 2007 12:12:29 +0000 Received: from ottawa-hs-209-217-122-41.s-ip.magma.ca ([209.217.122.41] helo=[192.168.8.125]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IxLmA-0000Ba-1q; Wed, 28 Nov 2007 07:12:22 -0500 Message-ID: <474D5B53.60009@ellipticsemi.com> Date: Wed, 28 Nov 2007 12:18:00 -0000 From: Tom St Denis User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Duft Markus CC: NightStrike , "J.C. Pizarro" , Galloth , gcc-help@gcc.gnu.org Subject: Re: reduce compilation times? References: <18597F2B47F1394A9B309945EC72411201344B58@servex01.wamas.com> In-Reply-To: <18597F2B47F1394A9B309945EC72411201344B58@servex01.wamas.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: elp125 - ottawa-hs-209-217-122-41.s-ip.magma.ca ([192.168.8.125]) [209.217.122.41] X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg00347.txt.bz2 Duft Markus wrote: > Hi! > > I assume, that all strategies discussed here are targeted at C. now what > about C++, how do things behave there? As far as i know C++ is much > different, and requires completely different thinking with regards to > splitting source in more files, etc. > I don't know enough about C++ linking but there is no reason you can't put methods in seperate .C files. The problem is most C++ developers want to inline all of their methods and put quite a bit of actual code in their .H files instead, which is just a maintenance nightmare. The benefits of code factoring are hardly limited to C or C++. They equally apply to Java applications (with the sad exception, hehehe, that your class has to be in one file, but you can refactor into smaller classes, etc), pascal, assembler, etc. Even if you're a one person shop. It helps, especially if you use some form of revision control. For example, if you've messed up a function, and changed over functions (and want to keep them), it's easier to restore one file from the last sane revision, then to patch one huge file with mix of current, unstable, old, code. I've done that myself a few times. I would be working on one of my libraries, and amongst say 5-6 changes I'm making one of them doesn't pan out. So I just nuke the file and cvs update it. Boom, the last stable copy is back. Anyways... despite what others are saying, putting all of your eggs in one basket won't magically make the compiler be able to optimize the code significantly differently than what you could have with well factored code, and ideally created static inlines/macros. All doing what they're saying gets you is a hard to maintain project.