Good compiler for windows

This is a discussion on Good compiler for windows within the C Programming forums, part of the General Programming Boards category; Originally Posted by 39ster Im talking about statically linking the runtime libraries. And I also don't understand why people like ...

  1. #16
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,545
    Quote Originally Posted by 39ster View Post
    Im talking about statically linking the runtime libraries.
    And I also don't understand why people like static linking, because obviously, to me, it's useless. Install runtimes on target machine and never bother with static linking ever. Saves file size and a lot of downloading in the end.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by 39ster View Post
    What annoys me about the microsoft compiler is that it ALWAYS links the standard C++ libraries, even when im not using any of the standard C++ functions. Mingw only links them if you use them, so if i only use the string library, then it will only link the string library, instead of the both the string library and the big iostream library. You can dynamically link them, but then the program wont work on alot of computers.
    I find that strange, since the linking process in both cases should only include library functions that are ACTUALLY being used - either explicitly by your code, or by other functions that your code calls. Of course, the implementation of string may well drag in iostream functions that drag in other functionality, ad infinitum. But since the C runtime library used by mingw is the same one that MS uses [albeit possibly different versions/generations], it should make little difference which one you use.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #18
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    And I also don't understand why people like static linking, because obviously, to me, it's useless. Install runtimes on target machine and never bother with static linking ever. Saves file size and a lot of downloading in the end.
    As discussed previously, there is only a saving if the end user is upgrading the application and/or (parts of) the runtime.


    Also, the statically linked executable is most likely a fair bit smaller than the entire runtime - because an arbitrary application will use only parts of the runtime, and those are the only components that need to be included in the statically linked executable, whilst the entire DLL(s) of the relevant components will be needed when distributing the runtime as a separate component.

    It also avoids the need for an installer - so a standalone application can be one executable file inside a zip file, and that's it. Of course, if you already use an installer for other reasons, then adding the runtime library as an installation item is a small step.

    It's a case of "right tool for the job" and "one size doesn't fit all".

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #19
    Registered User
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    217
    Quote Originally Posted by Elysia View Post
    And I also don't understand why people like static linking, because obviously, to me, it's useless. Install runtimes on target machine and never bother with static linking ever. Saves file size and a lot of downloading in the end.
    Well if i want to make a simple program, or dll, without any installers i dont want them to HAVE to have the runtime and i dont want to have to distribute the runtime dll. I once released a DLL that was made in Visual C and half the people couldnt use it because i didnt realise the runtime thing. I then chose to statically link it, and the file size went up about 400kB EVEN though there is no use of the iostream library in the dll.

    It's like this:

    MINGW (always uses static linking):
    -use iostream stuff -Add 400kB to file size
    -use string class -add about 20-30kB to file size
    -use STL stuff -varies

    Visual C (with static linking):
    -Doesnt matter if i use them or not, always adds 400+ kB to file size


    There is no problem with statically linking, in fact in mingw that is the only option.
    Last edited by 39ster; 06-17-2008 at 06:52 AM.

  5. #20
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,545
    Quote Originally Posted by matsp View Post
    As discussed previously, there is only a saving if the end user is upgrading the application and/or (parts of) the runtime.

    Also, the statically linked executable is most likely a fair bit smaller than the entire runtime - because an arbitrary application will use only parts of the runtime, and those are the only components that need to be included in the statically linked executable, whilst the entire DLL(s) of the relevant components will be needed when distributing the runtime as a separate component.
    However, it all adds up. When downloading the next application or version of the program, you need to download that excess code again. IF you already if it installed, you don't, and save space.

    It also avoids the need for an installer - so a standalone application can be one executable file inside a zip file, and that's it. Of course, if you already use an installer for other reasons, then adding the runtime library as an installation item is a small step.
    You don't need an installer anyway.
    Just download the runtime if you haven't previously and all applications will work. No need for an installer.
    If they get an error running the program, download the runtime!

    Quote Originally Posted by 39ster View Post
    Well if i want to make a simple program, or dll, without any installers i dont want them to HAVE to have the runtime and i dont want to have to distribute the runtime dll. I once released a DLL that was made in Visual C and half the people couldnt use it because i didnt realise the runtime thing. I then chose to statically link it, and the file size went up about 400kB EVEN though there is no use of the iostream library in the dll.
    Installers are not necessary. Make sure the target machine has the runtime. Everyone should have it.
    Then they don't need to download excess code in other applications or in future versions of YOUR applications.
    In short: they benefit from it, and your static linking destroys that advantage.

    MINGW (always uses static linking):
    -use iostream stuff -Add 400kB to file size
    -use string class -add about 20-30kB to file size
    -use STL stuff -varies

    Visual C (with static linking):
    -Doesnt matter if i use them or not, always adds 400+ kB to file size
    That's the price you pay for static linking.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    I'm not saying you are wrong in your size analyzis - but I suspect you'll find SOMETHING is actually using iostream when you get that sort of file-size. It may well be that your code in itself isn't, but I bet something like the C startup code, or some such does.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  7. #22
    Registered User
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    217
    Well after some tests i think i may retract my comments about Visual C always linking the iostream library. I can't remember what project made me think it did this, but when i just tested it now, the file size only increases about 50kB when i choose static linking on an almost blank project (which i think is because it uses a newer C library, instead of using the C library that comes with the windows installation). In fact, when testing mingw and Visual C on a larger project (the AngelScript Library) and both of them using static linking for the C++ libraries, the file size is smaller on the Visual C output.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Whats A Good Compiler?
    By katocan in forum C++ Programming
    Replies: 14
    Last Post: 06-28-2005, 11:00 AM
  2. Which Compiler should I use?
    By jjj93421 in forum Game Programming
    Replies: 17
    Last Post: 03-29-2004, 12:21 PM
  3. How good is the compiler of VS .NET Pro, really?
    By lightatdawn in forum Windows Programming
    Replies: 5
    Last Post: 03-23-2004, 01:58 PM
  4. Where can I get a good old Turbo C compiler?
    By sundeeptuteja in forum C Programming
    Replies: 2
    Last Post: 09-15-2002, 07:40 AM
  5. Good compiler for OpenGL (besides MS Visuial c++)
    By Crossbow in forum Game Programming
    Replies: 1
    Last Post: 12-20-2001, 03:44 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21