size matters; and I want mine smaller 
Author Message
 size matters; and I want mine smaller

I am really learning here. I appreciate all the help. I come from a VB only
shop and am trying to learn C/C++ to be an expert. This list is my only real
source of help.

With that said (almost each time I write to this newsgroup):

I have created a small windows app and a small VB app. They do the same
thing but my VB app is 1/2 the size of my C app. How can I can my C program
to be smaller? I would naturally think that a C windows application would be
smaller than a VB app of the same code. Here is my code:

#include <windows.h>

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR
szCmdLine, int iCmdShow)
{
 MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
 return 0;

Quote:
}

Public Sub Main()
    MsgBox "Hello, Thomas"
End Sub

Thanks,
Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller

Your C app is already smaller, as it doesnt need VBRUNXXX.DLL as
the VB app does...

How big is the resulting exe ?

/johan


Quote:
> I am really learning here. I appreciate all the help. I come from a VB
only
> shop and am trying to learn C/C++ to be an expert. This list is my only
real
> source of help.

> With that said (almost each time I write to this newsgroup):

> I have created a small windows app and a small VB app. They do the same
> thing but my VB app is 1/2 the size of my C app. How can I can my C
program
> to be smaller? I would naturally think that a C windows application would
be
> smaller than a VB app of the same code. Here is my code:

> #include <windows.h>

> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR
> szCmdLine, int iCmdShow)
> {
>  MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
>  return 0;
> }

> Public Sub Main()
>     MsgBox "Hello, Thomas"
> End Sub

> Thanks,
> Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller

I have a 36k file for the C application and a 16k file for the VB
application. I would presume that if I have the runtime already on the
machine then this would be fine. As with MFC (because as I understand MFC
it's basically a dynamic library too) would these applications be smaller?
1st, I would presume that a C application would be just tiny tiny ... like
under 10k. 2nd, I am a "Senior Programmer/Analyst" but I only program in VB,
T-SQL ... I really want to get into C++ and visibly noticing that the file
sizes are smaller seems to me like some sort of measure (I'm not sure what
kind, but something). 3rd, if an MFC application is smaller because the
libraries are already on the host machine I would presume that a C
application with just windows calls would be even smaller because the
kernel, gdi and user exist on the OS as well.

I am just trying to get in there and get working on this C/C++ stuff and I
want to know it all. I'm behind most of the people on this group but I'm
learning. Some of my other issues are that I can't seem to find a way to
convert a numeric data type to a character array so I can output
calculations (I want to concantinate a string to a number to a string).

Some of these issues are small and some are more frustrating than others. I
have gotten to the point where I can somewhat read code in a magazine. I
have read several books and can't seem to find an explanation of what this
means:

(char*)&MyName

It seems to me that the * and & would cancel each other out.

Lastly, what's STL? Standard Template Library ... I know ... but what does
it do? Is it old? Does it do more than MFC or ATL?

Again, thank you for your time. I'm learning this and just have question
that I can't get answered.

Thomas



Quote:
> Your C app is already smaller, as it doesnt need VBRUNXXX.DLL as
> the VB app does...

> How big is the resulting exe ?

> /johan



> > I am really learning here. I appreciate all the help. I come from a VB
> only
> > shop and am trying to learn C/C++ to be an expert. This list is my only
> real
> > source of help.

> > With that said (almost each time I write to this newsgroup):

> > I have created a small windows app and a small VB app. They do the same
> > thing but my VB app is 1/2 the size of my C app. How can I can my C
> program
> > to be smaller? I would naturally think that a C windows application
would
> be
> > smaller than a VB app of the same code. Here is my code:

> > #include <windows.h>

> > int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR
> > szCmdLine, int iCmdShow)
> > {
> >  MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
> >  return 0;
> > }

> > Public Sub Main()
> >     MsgBox "Hello, Thomas"
> > End Sub

> > Thanks,
> > Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller
When you consider the size of an app, you need to consider *ALL* of it,
including any runtime DLL's.  An MFC program is probably not going to be
much smaller than a VB program if you do so, since MFC includes the kitchen
sink in applications.

If you use another library, like ATL or WTL, or even just code straight to
the SDK, then you will find the entire memory footprint to be much much
smaller than either VB or and MFC app that does the same thing.

Having said that, I think worrying about the size of your applications at
this stage of your education is a foolish thing to do.


Quote:
> I am really learning here. I appreciate all the help. I come from a VB
only
> shop and am trying to learn C/C++ to be an expert. This list is my only
real
> source of help.

> With that said (almost each time I write to this newsgroup):

> I have created a small windows app and a small VB app. They do the same
> thing but my VB app is 1/2 the size of my C app. How can I can my C
program
> to be smaller? I would naturally think that a C windows application would
be
> smaller than a VB app of the same code. Here is my code:

> #include <windows.h>

> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR
> szCmdLine, int iCmdShow)
> {
>  MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
>  return 0;
> }

> Public Sub Main()
>     MsgBox "Hello, Thomas"
> End Sub

> Thanks,
> Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller

Thank you. I do think that worrying about the size of my applications is not
important as getting them to run ... but I want to understand the process. I
really want to know that I'm doing the right thing and since it seems larger
than what I expect I would think that I did something wrong. It's clear that
my windows applications will always be a minimum of 36k. I did I search of
my hard drive for *.exe and sorted and noticed that there are lots of
windows apps that are under 20k.

I thought that ATL is for COM development and it's just a layer above the
API. I would think that these components would also have a base minimum of
50k or so but would also be small. I don't know anything about WTL besides
it's Windows Template Library. Is this a "better" way of creating Windows
applications over MFC?

Thanks for all your help and comments,
Thomas


Quote:
> When you consider the size of an app, you need to consider *ALL* of it,
> including any runtime DLL's.  An MFC program is probably not going to be
> much smaller than a VB program if you do so, since MFC includes the
kitchen
> sink in applications.

> If you use another library, like ATL or WTL, or even just code straight to
> the SDK, then you will find the entire memory footprint to be much much
> smaller than either VB or and MFC app that does the same thing.

> Having said that, I think worrying about the size of your applications at
> this stage of your education is a foolish thing to do.



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller

you can get down to 16Kb (with your exact code) by
checking "Ignore all default libraries" in the Link options and
then specify WinMain as Entry-Point symbol (also in Link settings,
category Output).

The problem with runtime libs is that you cannot rely on them always being
on the target system, as they tend to get updated with new functions,
and you'll want to be sure the app. will be able to execute...

as for the (char*)&MyName:

no, they would certainly not cancel each other out:
the expression casts the address of MyName to a char*.

Perhaps your thinking of (*)&MyName, in which case
they would (cancel each other out, that is).

STL is roughly the C++ equivalent of the C Runtime Library, and
it consists of a number of classes, where the container
classes are amongst the most useful IMO.

/johan


Quote:
> I have a 36k file for the C application and a 16k file for the VB
> application. I would presume that if I have the runtime already on the
> machine then this would be fine. As with MFC (because as I understand MFC
> it's basically a dynamic library too) would these applications be smaller?
> 1st, I would presume that a C application would be just tiny tiny ... like
> under 10k. 2nd, I am a "Senior Programmer/Analyst" but I only program in
VB,
> T-SQL ... I really want to get into C++ and visibly noticing that the file
> sizes are smaller seems to me like some sort of measure (I'm not sure what
> kind, but something). 3rd, if an MFC application is smaller because the
> libraries are already on the host machine I would presume that a C
> application with just windows calls would be even smaller because the
> kernel, gdi and user exist on the OS as well.

> I am just trying to get in there and get working on this C/C++ stuff and I
> want to know it all. I'm behind most of the people on this group but I'm
> learning. Some of my other issues are that I can't seem to find a way to
> convert a numeric data type to a character array so I can output
> calculations (I want to concantinate a string to a number to a string).

> Some of these issues are small and some are more frustrating than others.
I
> have gotten to the point where I can somewhat read code in a magazine. I
> have read several books and can't seem to find an explanation of what this
> means:

> (char*)&MyName

> It seems to me that the * and & would cancel each other out.

> Lastly, what's STL? Standard Template Library ... I know ... but what does
> it do? Is it old? Does it do more than MFC or ATL?

> Again, thank you for your time. I'm learning this and just have question
> that I can't get answered.

> Thomas



> > Your C app is already smaller, as it doesnt need VBRUNXXX.DLL as
> > the VB app does...

> > How big is the resulting exe ?

> > /johan



> > > I am really learning here. I appreciate all the help. I come from a VB
> > only
> > > shop and am trying to learn C/C++ to be an expert. This list is my
only
> > real
> > > source of help.

> > > With that said (almost each time I write to this newsgroup):

> > > I have created a small windows app and a small VB app. They do the
same
> > > thing but my VB app is 1/2 the size of my C app. How can I can my C
> > program
> > > to be smaller? I would naturally think that a C windows application
> would
> > be
> > > smaller than a VB app of the same code. Here is my code:

> > > #include <windows.h>

> > > int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR
> > > szCmdLine, int iCmdShow)
> > > {
> > >  MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
> > >  return 0;
> > > }

> > > Public Sub Main()
> > >     MsgBox "Hello, Thomas"
> > > End Sub

> > > Thanks,
> > > Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller
I see. So by including the runtime libs I am ensuring that my application
will run because I have included the actual library portions that I need.
I'm not sure about the Entry Point ... and think that I'll do more research
on the settings.

Thank you,
Thomas



Quote:
> you can get down to 16Kb (with your exact code) by
> checking "Ignore all default libraries" in the Link options and
> then specify WinMain as Entry-Point symbol (also in Link settings,
> category Output).

> The problem with runtime libs is that you cannot rely on them always being
> on the target system, as they tend to get updated with new functions,
> and you'll want to be sure the app. will be able to execute...

> as for the (char*)&MyName:

> no, they would certainly not cancel each other out:
> the expression casts the address of MyName to a char*.

> Perhaps your thinking of (*)&MyName, in which case
> they would (cancel each other out, that is).

> STL is roughly the C++ equivalent of the C Runtime Library, and
> it consists of a number of classes, where the container
> classes are amongst the most useful IMO.

> /johan



> > I have a 36k file for the C application and a 16k file for the VB
> > application. I would presume that if I have the runtime already on the
> > machine then this would be fine. As with MFC (because as I understand
MFC
> > it's basically a dynamic library too) would these applications be
smaller?
> > 1st, I would presume that a C application would be just tiny tiny ...
like
> > under 10k. 2nd, I am a "Senior Programmer/Analyst" but I only program in
> VB,
> > T-SQL ... I really want to get into C++ and visibly noticing that the
file
> > sizes are smaller seems to me like some sort of measure (I'm not sure
what
> > kind, but something). 3rd, if an MFC application is smaller because the
> > libraries are already on the host machine I would presume that a C
> > application with just windows calls would be even smaller because the
> > kernel, gdi and user exist on the OS as well.

> > I am just trying to get in there and get working on this C/C++ stuff and
I
> > want to know it all. I'm behind most of the people on this group but I'm
> > learning. Some of my other issues are that I can't seem to find a way to
> > convert a numeric data type to a character array so I can output
> > calculations (I want to concantinate a string to a number to a string).

> > Some of these issues are small and some are more frustrating than
others.
> I
> > have gotten to the point where I can somewhat read code in a magazine. I
> > have read several books and can't seem to find an explanation of what
this
> > means:

> > (char*)&MyName

> > It seems to me that the * and & would cancel each other out.

> > Lastly, what's STL? Standard Template Library ... I know ... but what
does
> > it do? Is it old? Does it do more than MFC or ATL?

> > Again, thank you for your time. I'm learning this and just have question
> > that I can't get answered.

> > Thomas



> > > Your C app is already smaller, as it doesnt need VBRUNXXX.DLL as
> > > the VB app does...

> > > How big is the resulting exe ?

> > > /johan



> > > > I am really learning here. I appreciate all the help. I come from a
VB
> > > only
> > > > shop and am trying to learn C/C++ to be an expert. This list is my
> only
> > > real
> > > > source of help.

> > > > With that said (almost each time I write to this newsgroup):

> > > > I have created a small windows app and a small VB app. They do the
> same
> > > > thing but my VB app is 1/2 the size of my C app. How can I can my C
> > > program
> > > > to be smaller? I would naturally think that a C windows application
> > would
> > > be
> > > > smaller than a VB app of the same code. Here is my code:

> > > > #include <windows.h>

> > > > int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR
> > > > szCmdLine, int iCmdShow)
> > > > {
> > > >  MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
> > > >  return 0;
> > > > }

> > > > Public Sub Main()
> > > >     MsgBox "Hello, Thomas"
> > > > End Sub

> > > > Thanks,
> > > > Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller
Is there a good FAQ out there on Settings and compile options?


Quote:
> I am really learning here. I appreciate all the help. I come from a VB
only
> shop and am trying to learn C/C++ to be an expert. This list is my only
real
> source of help.

> With that said (almost each time I write to this newsgroup):

> I have created a small windows app and a small VB app. They do the same
> thing but my VB app is 1/2 the size of my C app. How can I can my C
program
> to be smaller? I would naturally think that a C windows application would
be
> smaller than a VB app of the same code. Here is my code:

> #include <windows.h>

> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR
> szCmdLine, int iCmdShow)
> {
>  MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
>  return 0;
> }

> Public Sub Main()
>     MsgBox "Hello, Thomas"
> End Sub

> Thanks,
> Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller
A few options to minimize size

1. You can link to the DLL version of the CRT.
2. You can use user linker option /opt:nowin98 to shrink things down a
bit
3. You can optimize for size instead of speed (which you probably
ought to do anyway since VC speed optimization is notoriously buggy)
4. You can write it as an ATL app and use _ATL_MIN_CRT.  This cripples
most useful C++ functionality (no exceptions, no static constructors
are called, no CRT functions are available) but it will shrink your
size

Joe


Quote:

> I am really learning here. I appreciate all the help. I come from a
VB only
> shop and am trying to learn C/C++ to be an expert. This list is my
only real
> source of help.

> With that said (almost each time I write to this newsgroup):

> I have created a small windows app and a small VB app. They do the
same
> thing but my VB app is 1/2 the size of my C app. How can I can my C
program
> to be smaller? I would naturally think that a C windows application
would be
> smaller than a VB app of the same code. Here is my code:

> #include <windows.h>

> int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,
PSTR
> szCmdLine, int iCmdShow)
> {
>  MessageBox (NULL, TEXT("Hello, Thomas."), TEXT("Hello"), 0);
>  return 0;
> }

> Public Sub Main()
>     MsgBox "Hello, Thomas"
> End Sub

> Thanks,
> Thomas Remkus



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller

Quote:
> I thought that ATL is for COM development and it's just a layer above the
> API. I would think that these components would also have a base minimum of
> 50k or so but would also be small. I don't know anything about WTL besides
> it's Windows Template Library. Is this a "better" way of creating Windows
> applications over MFC?

Depends on what your definition of "better" is.

It's definitely smaller because the "T" in WTL stands for template and
templates tend to be smaller (though NOT always) than class
heirarchies/inheritance (which is what MFC is).

The main problem here is that there are a LOT of different options in terms
of "frameworks" to code in.  VB is straightforward...exactly one framework.
(In fact the framework and the language are indistinguishable.)

C/C++ unfortunately are not as straightforward because there are a lot of
frameworks (because there are a lot of different things you can do with
C++).

Here's, off the top of my head, some compare/contrast thoughts:

MFC:
Description:  C++ framework overlying C Win32 calls for creating GUI and COM
apps.  C++ is Inheritance based.
Pro:  Popular, lots of books on the topic, fairly to easy to use because of
wizard support, makes good desktop apps.
Con:  Really ONLY useful for desktop apps, does not make good COM objects or
NT services or drivers or... LARGE resulting executable with MFC included or
dependancies on (large) MFC runtime DLLs.  It can be difficult to bypass MFC
to work directly with the OS.  (Though it depends on what you're trying to
do...)

WTL:
Description:  C++ framework overlying C Win32 calls for creating GUI apps.
C++ is Template based.
Pro:  Produces very lightweight apps with little or no dependancies.  The
framework is very "light" and can be bypassed to direct Win32 if necessary
quite easily.
Con:  Very little support (not officially supported by MS), not very well
known, wizard support is very light.

ATL:
Description:  C++ framework overlying C Win32 calls for creating COM apps
including NT Service-based COM apps.  C++ is template based.
Pro:  Produces very lightweight COM objects with little or no dependancies.
The framework is very "light" and can be bypassed to direct Win32 if
necessary quite easily.  Very well known, very popular, lots of books on the
topic.
Con:  Wizards have annoying bugs in them which tend to lead the newbies down
the wrong path.  (The books, however, will steer you right.)  The NT Service
ATL wizard is the worst offender in this area.  (IMHO.)

Raw Win32:
Description:  Direct C (only) calls into the OS.
Pro:  Very small apps.  Direct access to the OS.  Any type of app (NT
Service, driver, GUI, whatever) can be produced.
Con:  VERY difficult to do anything large with, no (significant) wizard
support.

ISO C/ISO C++:
Description:  Console based applications which can be portable to other OSs.
Pro:  Portability.  C++ includes what was known as the "STL" which is a nice
framework of generic objects.
Con:  Least common denominator effect.  It's far too easy to step outside of
portability to accomplish something (which then only works on one platform.)

Also there is:

OWL:  A Borland C++ framework for generating gui apps.  Don't think this is
really supported anymore though...not sure.

C++ Builder:  A Borland language for generationg gui apps.  Very reminiscent
of VB and very similar to Delphi.  Haven't ever tried it but have heard good
things about it.

C#:  New language by MS which is similar to VB in its ability to generate
GUI apps.  Not complete yet.  (Beta/Alpha stage only).  Has a strong C++
(Java) flavor to it.

Hope this is of some use.

--
Reginald Blue                   | Opinions expressed here do not
Natural Language Understanding  | necessarily represent those of
Unisys Corporation              | my employer.
--------------------------------+-------------------------------

NL technology,speech application| My email address is wrong, you
development training, see:      | need to remove the obvious.
http://www.speechdepot.com/     +-------------------------------



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller


Quote:
> It's definitely smaller because the "T" in WTL stands for template and
> templates tend to be smaller (though NOT always) than class
> heirarchies/inheritance (which is what MFC is).

I would disagree with that. Templates can significantly reduce the amount of
code you have to write, but I don't see how they would descrease program
size. Try compiling an app the uses iostreams, first with the old
<iostream.h>, then with the newer template-based standard header <iostream>.
I think you'll find the latter results in bigger exe's.

 MFC is not bigger than WTL because WTL uses templates; MFC is bigger
because it provides a whole hell of a lot more functionality. Now if you
don't need all that functionality, WTL is great; but if you need it, it's
nice to know it's there.

I haven't used WTL, but I'm curious what the difference in size would be
between a statically-linked MFC app and a WTL app of similar functionality.
My guess is that the difference is fairly minimal.

Jeff



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller
As soon as you start adding lots of forms with controls to the VB project,
you'll see a reverse in that trend. I've even heard of VB projects as large
as 25MB because of all the forms and controls that bloat the EXE size. :)

Also consider that with C++ you can statically link, which results in an
larger executable but no runtime dependencies. With VB you're always going
to be dependent on the runtime DLL.

Jeff


Quote:
> I have a 36k file for the C application and a 16k file for the VB
> application. I would presume that if I have the runtime already on the
> machine then this would be fine. As with MFC (because as I understand MFC
> it's basically a dynamic library too) would these applications be smaller?
> 1st, I would presume that a C application would be just tiny tiny ... like
> under 10k. 2nd, I am a "Senior Programmer/Analyst" but I only program in
VB,
> T-SQL ... I really want to get into C++ and visibly noticing that the file
> sizes are smaller seems to me like some sort of measure (I'm not sure what
> kind, but something). 3rd, if an MFC application is smaller because the
> libraries are already on the host machine I would presume that a C
> application with just windows calls would be even smaller because the
> kernel, gdi and user exist on the OS as well.



Sun, 30 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller

Quote:



> > It's definitely smaller because the "T" in WTL stands for template and
> > templates tend to be smaller (though NOT always) than class
> > heirarchies/inheritance (which is what MFC is).

> I would disagree with that. Templates can significantly reduce the amount of
> code you have to write, but I don't see how they would descrease program
> size.

Easy - the code is only generated if it's used.  So if only a subset
of the functionality is used, a lot less code gets generated.  That's
how they -tend- to be smaller.  OTOH, how they're not always smaller
is that if you use several different instantiations and a substantial
portion of the functionality of each, you'll get several copies of
most of the code, yielding a larger image size.


Mon, 31 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller


Quote:



> > > It's definitely smaller because the "T" in WTL stands for template and
> > > templates tend to be smaller (though NOT always) than class
> > > heirarchies/inheritance (which is what MFC is).

> > I would disagree with that. Templates can significantly reduce the
amount of
> > code you have to write, but I don't see how they would descrease program
> > size.

> Easy - the code is only generated if it's used.  So if only a subset
> of the functionality is used, a lot less code gets generated.  That's
> how they -tend- to be smaller.  OTOH, how they're not always smaller
> is that if you use several different instantiations and a substantial
> portion of the functionality of each, you'll get several copies of
> most of the code, yielding a larger image size.

Yes, but if you're statically linking to a library, the linker can achieve
the same affect. My experience with templates is that they usually lead to
larger image sizes, not smaller. I still say the reason WTL is smaller than
MFC is because it doesn't do nearly as much.

Jeff



Mon, 31 Mar 2003 03:00:00 GMT  
 size matters; and I want mine smaller
On Wed, 11 Oct 2000 12:26:15 -0500, "Thomas Remkus"

Quote:

>I have a 36k file for the C application and a 16k file for the VB
>application. I would presume that if I have the runtime already on the
>machine then this would be fine. As with MFC (because as I understand MFC
>it's basically a dynamic library too) would these applications be smaller ?

As other people have said, it depends on how you build the app.  The
bare C-type program is bigger than the VB code as it carries most of
the code to make it work in the EXE instead of relying on dll's that
may or may not be on the host system.

<quick look for a link, can't find it>

There is a thread called "Smallest VC Ever" or "Smallest VC EXE Ever"
which goes on about getting an exe down the the minimum size without
needing to code any assembler.  Check out deja for that.

You can use the DLL version of the C-runtime library which will take
the staticly-linked (read, built into the exe) functions out and call
the dll versions.  This will make the exe smaller but your program
will depend on msvcrt.dll.  This may or may not be a problem, but this
sort of choice is available to you, if you need it.  Check out the
damn-useful tool "dependancy walker" (www.stevemiller.com) for seeing
what a dll or exe relies on.

There is a sort-of minimum overhead for straight C/C++ apps which
isn't really a problem.  You may also see the developing exe grow
slower than a developing VB exe, depending on what you are writing of
course.

P.S.  Welcome to the fray :-)

As for your other questions, other people in the thread are informing
you so I won't go on about that...

Quote:
>1st, I would presume that a C application would be just tiny tiny ... like
>under 10k.

If you need to, it can be achieved.

Quote:
> I really want to get into C++ and visibly noticing that the file
> sizes are smaller seems to me like some sort of measure (I'm not sure what
> kind, but something).

The light shines elsewhere :-)

Quote:
>Some of my other issues are that I can't seem to find a way to
>convert a numeric data type to a character array so I can output
>calculations (I want to concantinate a string to a number to a string).

Have a look at the functions "atol" and "ltoa" and follow the links to
"String conversion routines".  That should cover how to do it in C.
Using the C++ runtine classes is a different ball-game and requires
learning sometime extra. Again, it depends on how you want to do it.

Quote:
>Lastly, what's STL? Standard Template Library ... I know ... but what does
>it do? Is it old? Does it do more than MFC or ATL?

There is a C-runtime library that provides a whole heap of
ready-written functions to perform *many* of the more simple tasks.
There is also a C++ runtime library that compliments C++.  Think of
the STL as another C++ library but a template and class library
instead of a function library.

In C++, you can use templates to simplify code generation.  Here's a
very simple example:

Say you need a function to calculate the area of a rectangle.

long RectArea(long len1, long len2)
{
  return len1 * len 2;

Quote:
}

This will work when you pass it a couple of long's, but your app may
need to use fractions, so you need another function that takes 2
floats, or another to take two doubles.  This is essentially
cut/pasting code and modifying it.  Alright for simple stuff, but you
can imagine how careful you'll have to be for very complicated code.

Using templates, you need to only write the function once and that's
it, done...   As long as the data-types can be multiplied (i.e.  use
the * operator) the function will work.

(NB: there may be errors as I'm not compiling the code, but you get
the idea).

template <class T> T RectArea(T len1, T len2)
{
  return len1 * len2;

Quote:
}

The STL provides this sort-of library, but has been developed to
include arrays, lists, queues, streams, files etc...  A very useful
and flexible library.

Hope this helps somewhat, and good luck,

Jimbo



Wed, 02 Apr 2003 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Does the size of it matter?

2. how matters the size of the model installed...

3. Size does matter!

4. small-C for mac wanted

5. small-c/8086 code generator wanted

6. WANTED: Lost posting of small program for stuffing chars into int

7. Wanted: Small sample real-time code

8. Wanted: Small 8086 C with source?

9. WANTED: A small Dictionary file

10. "Small C compiler" book wanted

11. Wanted: Simple/small flat database engine for VC++ app

12. Wanted: Source for Small C Compiler for SPARC/SunOS

 

 
Powered by phpBB® Forum Software