3

I am writing a library that will be statically linked (to other libraries or to applications). I want to make my library as small as possible. My library needs to read a file; the name of the file will be known in advance and contains only ASCII characters. My library will have absolutely no user interface or GUI code; it's just functions to be called.

What function should I call to open my file, with the linker bringing in as little additional code as possible?

Presumably CreateFile() is a basic built-in Windows feature that lives in a shared library. So, should I just use CreateFileA() (to avoid a conversion to wide char)?

For CreateFileA() I will need to include Windows.h; will this increase the size of my library? If so, does defining WINDOWS_LEAN_AND_MEAN help?

Should I just use _open()? Or, I guess it should be _sopen_s() now?

codingfreak
  • 4,467
  • 11
  • 48
  • 60
steveha
  • 74,789
  • 21
  • 92
  • 117
  • Did you know all the functions that end with `A` are just wrappers for the `W` ones? – Jesse Good Jul 06 '12 at 03:00
  • Why not just ANSI C fiel functions?: `fopen`, `fread`, etc. – Linuxios Jul 06 '12 at 03:16
  • @JesseGood, I don't grasp the point behind your comment. Okay, functions that end in `A` are wrappers; and this affects my problem... how? – steveha Jul 06 '12 at 04:11
  • @Linuxios, I'm going for minimum size. If `fopen()` and friends would make my library just as small as `CreateFileA()` then I will cheerfully use them; I prefer the *NIX functions to the native Windows functions almost always. – steveha Jul 06 '12 at 04:13
  • @steveha: It's not directly related but since the `A` functions incur overhead(they convert from ASCII to Unicode and then call the `W` functions), it would be better to use the `W` functions to begin with. – Jesse Good Jul 06 '12 at 04:18
  • This is a C++ question, but I recommend reading [std::wstring VS std::string](http://stackoverflow.com/questions/402283/stdwstring-vs-stdstring) as it talks about windows. (Quote: `if you work on Windows, you badly want to use wchar_t`). – Jesse Good Jul 06 '12 at 04:22
  • @JesseGood, I don't think I care about the overhead of a single `char` string to `wchar_t` string conversion, for reading a single file. But you did push me into the realization that I can just declare the filename string with the `_T()` macro or even as an `L""` literal, so I don't need to do any runtime conversion from `char` to `wchar_t`. So perhaps I'll use `CreateFileW()` after all; why not? I guess if I was really obsessed with saving bytes, I'd object to the filename string using two bytes per character instead of one, but I think that should be okay! – steveha Jul 06 '12 at 04:59
  • @Joey, I'm afraid I don't follow you. I thought I had explained quite thoroughly in my question: my library needs to read one file with a known filename, that filename contains only basic ASCII characters, and the library should be as small as possible. It seems like a pretty specific problem domain. So I don't understand where "all users" come in, and I don't understand what it means to "sacrifice Unicode" in this context. – steveha Jul 06 '12 at 09:00
  • @JesseGood: For the OP's problem, "use W functions" really is not applicable, as it makes all strings twice as long as necessary. Besides, "you badly want to use wchar_t" is not generally true either. There are a some excellent reasons for not using wchar_t under Windows, doing so is just the easiest thing API-wise. That does not mean it's the best. – Damon Jul 06 '12 at 10:10
  • @Damon: Concerning your comment `There are a some excellent reasons for not using wchar_t under Windows`, do you have any information or examples backing this claim up? – Jesse Good Jul 06 '12 at 10:21
  • @JesseGood: Though I can see this going totally off-topic, one good reason is that UTF16 has all the disadvantages of UTF8 plus some others (e.g. not compatible with standard libc character functions) and uses ~2x the memory for non-Southeast-Asian languages. OTOH, if you _need_ non-BMP, it doesn't do it "properly" either. The often cited advantage of deterministic string length is a lie. Whether or not Windows internally converts one into the other is irrelevant. The conversion overhead is ridiculous compared to the overhead that most Win32 API funcs already have anyway. – Damon Jul 06 '12 at 11:09

1 Answers1

2

_open and it's derivatives use the standard c library, which will typical add size to your library. CreateFile is the way to go. A or W depends if you need to link in Unicode, which will depend on what you're linking with.

Joel Lucsy
  • 8,520
  • 1
  • 29
  • 35
  • +1. The C library is not "standard" on Windows, so you'd have to statically link it - = larger binary. If only concern is size, A or W won't make a difference, all functions will come from external DLLs. – vanza Jul 06 '12 at 04:18
  • @vanza -- Visual C does so much that is magical and automatic... how can I tell whether or not Visual C slurped in the standard C library? For example, if I `#include ` to get types like `size_t` will that make Visual C slurp in the library, or would I actually need to reference a library function so the linker would link in the library? Visual C doesn't even show me the actual output from the linker, just a sanitized status listing like this: `Foo.vcxproj -> C:\Users\steveha\Project\Debug\foo.lib` – steveha Jul 06 '12 at 05:34
  • 1
    @steveha: you need to reference a symbol from the library to need to link the library. Type definitions are just in header files, not the library. Since you're creating a static library, I don't think the linker will require you to link msvcrt right away - just when an application statically links your library and creates its own DLL or EXE. – vanza Jul 07 '12 at 00:43
  • @vanza -- Makes sense. I'm just suspicious of Visual C since it does so much automatically and hides so much! – steveha Jul 07 '12 at 04:19