Prev: Destructor called before startThread
Next: Initializing an object with auto pointers
From: Alex Blekhman on 9 Apr 2010 08:28
On 09-Apr-10 11:53, Martin B. wrote:
> Correct me if I'm wrong, but isn't statically vs. dynamically linking
> also a memory issue? (Not for the single tiny app, but for the overall
> system)

You're correct. Static linking is slightly wasteful, since otherwise
common library will be loaded time and again for every statically linked
application. This tradeoff is not new, however. Simplified delivery
versus small code bloat - you decide what is more important to you. With
today's personal computers another couple of KB's (or even MB's) for
executable image is negligible. For example, my home desktop box has 6GB
of RAM and my office machine brandishes mighty 12GB of RAM. Who cares
about another 30KB for an executable?

OTOH, handheld devices impose much more strict limitation for running
application. So, every saved KB of memory counts. As I said in the
beginning of this post, YMMV.

Alex
From: Dilip on 9 Apr 2010 11:35
On Apr 8, 9:03 pm, "Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp>
wrote:
> "Dilip" <rdil...(a)lycos.com> wrote in message
>
> news:844504f4-154f-4227-a0ad-d522df5d4f38(a)g10g2000yqh.googlegroups.com...
>
>
>
>
>
> >I am in the process of writing a tiny MFC application (developed on
> > Visual Studio 2008) that (for reasons that are too confusing to list)
> > cannot rely on the appropriate redistributables present on the target
> > machine.  I cannot do the obvious thing of shipping the
> > redistributables along with application.  Please lets not get into the
> > why of it because I am stuck in a weird situation.
>
> > As a result my only option is statically link against everything.  To
> > that end my application statically links against MFC.  So far so
> > good.  However, I also use a lot of standard C++ features (including
> > stuff from tr1).  I understand at run time my application is going to
> > go looking for msvcr90.dll and msvcp90.dll, correct? How do I
> > statically link against CRT and Std C++ libraries?  I gather their
> > static counterparts are libcmt.lib and libcpmt.lib, right?  Is it just
> > a question of putting these in the linker settings?
>
> > How can I achieve my objective?
>
> The setting to statically link to the runtime is in Project, Properties,
> C/C++, Code Generation, Runtime Library.

To my surprise I found that under Release setting, the libraries were
statically linked by *default* (it was set at /MT). I never knew
this. I thought the default was always dynamic linking and you had to
deliberately convert it to static?
From: David Lowndes on 9 Apr 2010 12:24
>To my surprise I found that under Release setting, the libraries were
>statically linked by *default* (it was set at /MT). I never knew
>this. I thought the default was always dynamic linking and you had to
>deliberately convert it to static?

You can choose static linking during the pages of the Wizard, but I'm
fairly sure the default is to dynamic link.

Dave
From: Dilip on 9 Apr 2010 12:34
On Apr 9, 11:24 am, David Lowndes <Dav...(a)example.invalid> wrote:
> >To my surprise I found that under Release setting, the libraries were
> >statically linked by *default* (it was set at /MT).  I never knew
> >this.  I thought the default was always dynamic linking and you had to
> >deliberately convert it to static?
>
> You can choose static linking during the pages of the Wizard, but I'm
> fairly sure the default is to dynamic link.
>
> Dave

Thats what I am confused about too. When I first created the project
the wizard pages allowed me an option to statically link *only* with
MFC -- I didn't encounter anything regarding CRT. Oh well.. at this
point its mostly a curiousity issue.

From: David Lowndes on 9 Apr 2010 15:11
>Thats what I am confused about too. When I first created the project
>the wizard pages allowed me an option to statically link *only* with
>MFC -- I didn't encounter anything regarding CRT.

I think the 2 things are combined at that stage.

Dave
First  |  Prev  | 
Pages: 1 2
Prev: Destructor called before startThread
Next: Initializing an object with auto pointers