4

As stated in this answer, when including iostream library the binary size gets much larger because the std::cin, std::cout, std::cerr (and maybe more) objects are created thus occupying a lot of memory.

I often compile code for embedded platforms which have strict constraints on memory. After including the iostream library the binary gets so big that it won't fit into the internal flash memory. That in turn affects the libraries which can be included, because a lot of them include <iostream>. One of example can be Protobuf library which I can't use across multiple projects as it includes iostream.

For those targets, which are run on an embedded platform, I don't need the objects to be created because I won't never use it. The question is: can I somehow prevent from creation of those objects? Is there maybe some other workaround which allows to include libraries which use iostream and to not increase the binary size so much?

K. Koovalsky
  • 596
  • 4
  • 17
  • 3
    Don't include `iostream`. – Ron Aug 20 '19 at 11:25
  • 4
    For smaller embedded targets (where memory is a concern) one usually have better control over the startup and initialization code that runs before `main` is called. Often one also have special purpose-built libraries which disables such sub-systems as `std::cout` etc. (or at least makes such objects small and "empty"). – Some programmer dude Aug 20 '19 at 11:28
  • @Someprogrammerdude Can you elaborate about the solution which controls the startup and initialization code run before `main`? The libraries, you mention, are alternatives to standard library or smthng? – K. Koovalsky Aug 20 '19 at 11:34
  • 1
    @MaxLanghof No, the question does *not* ask that. Your “quote” appears nowhere inside the question. While *similar* text does appear, it’s not the only question OP is asking (there are multiple questions in fact), and Ron’s comment perfectly answers the main question. Making up fake quotes to support your point is disingenuous. – Konrad Rudolph Aug 20 '19 at 11:36
  • 1
    Depending on your platform you could add e.g. `#define _GLIBCXX_IOSTREAM 1` before you include any of the headers that depend on it iostream (so it won't satisfy the `#ifndef` at the beginning of the iostream header). You'd need to define your own dummy versions of anything referenced by these libraries though. – ChrisD Aug 20 '19 at 11:38
  • 2
    @KonradRudolph The advice is on the same level as "my program crashes when I run it" -> "don't run your program" - that also "answers the main question" while being devoid of information. And the point of my quote was "include libraries which use `iostream`", not the (to me immaterial) distinction between "is there maybe some other workaround" or the condensed "is there a way". There is absolutely nothing disingenuous about that quote, only a lack of quotation formalities (missing [] for the paraphrased part). – Max Langhof Aug 20 '19 at 11:38
  • @MaxLanghof No, they’re fundamentally different. Because Ron is right: this is the *only* standards compliant (and productive!) way of preventing the instantiation of these variables. Whereas there are tons of productive ways of preventing a program crash, and not running it isn’t one of them. Frankly, how did your comment two upvotes?! As for why your pretend quote was disingenuous: not because it violated formalities but because it implied (in context) that Ron’s comment didn’t answer OP’s question. Yet this is false. It’s not a *great* answer since it lacks explanation. But it’s correct. – Konrad Rudolph Aug 20 '19 at 12:42
  • @KonradRudolph If your goal is to use a library that includes `iostream` (which is what this question is unambiguously about) then not including iostream is _not_ a "productive" way to prevent the instantiation of `cin` and friends. In fact, there is _no_ standard-compliant productive way to answer this question, and I'm sure all three of us know this. Stating the obvious (and clearly known-to-the-asker) but entirely unproductive solution then just comes across as snide. The votes on my now removed comment showed that I was not the only one to read it that way. It was never about correctness. – Max Langhof Aug 20 '19 at 13:16
  • @MaxLanghof What does it mean that solution is no standard-compliant? – K. Koovalsky Aug 20 '19 at 13:37
  • @K.Koovalsky It means that it is not a solution according to the C++ standard. If a compiler offers an "unofficial" way to do it (such as ChrisD's suggestion) then this is not portable (might not work on other compilers, or other environments) because the C++ standard does not require other compilers to do the same. I have the impression that this would be totally fine for your use case though. – Max Langhof Aug 20 '19 at 13:52
  • @MaxLanghof Ok, I think so. Could you write some more details about such a solution? I can see that we are flying around some general statements like "not standard solution", but it has not been written what does it really mean. – K. Koovalsky Aug 20 '19 at 13:58

1 Answers1

2

You cannot in standard ways, because <iostream> is required to define these variables. If you do not want the variables then you have to include directly the headers (like <ios>, <streambuf>, <istream>, <ostream> and/or <iosfwd>). I assume you want to include <iostream> for classes defined in those headers. If some third party library that you use includes things that you do not want then you have to consult with authors of such library, there are no generic answers.

Öö Tiib
  • 10,809
  • 25
  • 44