4 ms·

There's also some really terrible advice in here. Not using the STL is really, really bad advice for most. Same with fast-math. Same with "just write C instead

• coliveira 3y ago
  The stated goal of the article is to reduce binary size. If you want to use C++ and STL you already have decided that binary size is secondary. By the way, the article even mentions rewriting some routines in assembly.
  • lozenge 3y ago
    This is like saying "how to reduce the load time of your web app - remove all CSS". Technically true, but not useful for most web apps. People can want faster loading without removing all styling.
    • ipaddr 3y ago
      It's more like saying remove react and use pure javascript.
    • Kranar 3y ago
      I don't see how your claim follows or would be true. Replacing CSS with the equivalent JavaScript would most certainly not reduce load times. In fact you should use CSS as a means of reducing load times.
      • wtetzner 3y ago
        They didn't suggest replacing it with JavaScript.
        • Kranar 3y ago
          They didn't really suggest anything. Feel free to propose a way of replacing CSS functionality that results in faster load times.
          • dgfitz 3y ago
            I'd say the obvious answer in this case would be: replace it with nothing. The web would be a touch uglier, but it sure would be faster.
            • Kranar 3y ago
              That's a different discussion and frankly not something for developers to decide. If a product is designed to behave and look a certain way, then as an engineer you have the job of determining the best way to accomplish that objective. If your decision is to forgo using CSS for an alternative, fine but no one has provided what that alternative is. I'd much rather use CSS instead of Javascript or going back to the days of hacking <table> to get a certain layout.
    • colonwqbang 3y ago
      I think that's quite unfair. The article contains many different tips on how to reduce size. Rewriting in a different language was just one of them, pretty far down on the list. "Write in C instead of C++" is also clearly not the same as "remove all your code"...
• kevin_thibedeau 3y ago
  He also recommends disabling exceptions which is a valid approach for size constrained applications. STL throws, so it can never be used safely with exceptions disabled. When you do this you're committing to writing C-with-classes rather than modern C++.
  • galangalalgol 3y ago
    There have been implementations of most of the stl without exceptions here and there for embedded stuff. You can do modernish c++ without rtti or the stl, you will just have to do some extra work.
  • flafla2 3y ago
    I agree with the sentiment but in practice I’ve found that most C++ STL exceptions throw in a “fatal error” type of scenario like a bad allocation and generally not an “expected error”. For example, basic_ifstream::open() sets a fail bit on error, and doesn’t throw an exception. This is in contrast to python or Swift for example, their standard libraries are more “throw-prone”. Building off the previous example Swift’s String.init(contentsOf:encoding:) throws on error on failure. So in practice, IMO it is usually safe to disable exceptions in C++. Though, I have run into tricky ABI breaks when you link multiple libraries in a chain of exceptions->noexcept->exceptions and so on! You’re of course at the mercy of nonstandard behavior so buyer-beware. I definitely wouldn’t advocate for turning them off -just- for a binary size reduction.
    • kevin_thibedeau 3y ago
      You can recover from failed allocations without catastrophic failure. It is a fundamentally lazy programming practice to pretend that error handling has to be an out of band operation that can't be dealt with locally and bubble up progressively.
      • Chaosvex 3y ago
        You can try but realistically, you shouldn't bother in the overwhelming majority of software. Depending on whether you're on a platform that allows for overcommit, you won't necessarily know that an allocation has failed until you attempt to make use of it and the OS tries to back the pages, by which point, you could be far from the source of the allocation. You're just going to end up with an insane amount of error handling only to discover that in the real world, there's likely nothing you can really do anyway.
• IChooseY0u 3y ago
  Why is avoiding STL bad advice? Lack of problem solving skills? You could survive with LIST_ENTRY and UNICODE_STRING-type structures.
• Kranar 3y ago
  Not using the STL in and of itself is not terrible advice, it's a trade-off. For example, I tend to avoid the STL because of how inconsistent it is across the various compilers in terms of performance, bugs, and behavior. The standard leaves a great deal of ambiguity in how the STL behaves and those inconsistencies can be frustrating to deal with when you're writing cross platform software. Furthermore plenty of embedded systems also cut out the STL entirely due to disabling exceptions. Using fast-math is also a perfectly acceptable option for numerous domains that do not need strict IEEE conformance, such as graphics programming or training neural networks. If people were to listen to your advice, no one would ever post any kind of article on how to achieve certain specific goals, all we'd ever discuss are very generic topics and constantly rehash the same content over and over again. It's good to be able to learn how certain developers manage to accomplish various goals without having someone come along and call that advice terrible.
  • maccard 3y ago
    > For example, I tend to avoid the STL because of how inconsistent it is across the various compilers in terms of performance and behavior. What are your targets? This was my experience 10 years ago, but today with modern (last 5-6 years) MSVC, GCC and Clang (and even on modern Xbox and Playstation toolchains) my experience has been that it's close enough.
    • kwant_kiddo 3y ago
      Even just between x86 and ARM there can be a big enough difference in performance s.t your product straight up does not work on one platform, and that is with the current gcc toolchain. I have been working with small embedded devices so this may be an outlier here compared to the rest of the C/C++ world.
      • maccard 3y ago
        We target both x64 and arm, and I'm not aware of any restrictions we place on STL usage. That said, we don't target embedded devices, so your world is _definitely_ different to mine!
• mkoubaa 3y ago
  The title of the article is literally "How to make smaller C and C++ binaries"
• bee_rider 3y ago
  The advice for fast math is kinda funny. > If you don't need IEEE-conformat floating point calculations, use -ffast-math . I mean… if you know enough to know whether you need standard floating-point calculations, you probably know about the -ffast-math flag. Someone who is more into system specific stuff might correct me, but I believe fast math produces a binary which can flip bits in the MXCSR if it wants. So, you’ll have to make sure that none of your libraries make any assumptions about floating point behavior, not just your code…
  • mananaysiempre 3y ago
    > if you know enough to know whether you need standard floating-point calculations, you probably know about the -ffast-math flag. If you just want physics engine go brr and a small binary, though, maybe you don’t. I find the FP advice suspect for a different reason: I’ve seen some no good, very bad, seriously terrible, really horrifyingly awful codegen from Clang for x86-64 things involving `long double`, and without checking first I wouldn’t assume that it doesn’t extend to all x87 stuff in general. (Clang’s preferred optimized way to copy a naturally-aligned 16-byte union with a `long double` being the longest member is... to copy the first ten bytes with FLD/FSTP, then the following two bytes of padding by a word-sized MOV, then the final four bytes, also of padding, by a doubleword-sized MOV. Apparently it forgot its MOVAPS at home. When it spills onto the stack a `long double` temporary it itself invented to implement an atomic operation’s inner loop, though, it first clears the padding using a bleeding XORPS+MOVAPS pair before FSTPing it there—inside the loop, twice, to two identical temporaries, because apparently it belongs to the offshore oil rig school of register spilling. And so on. I lack the words to describe how bad Clang’s codegen is for anything that might have ever briefly brushed against a `long double`.) Also take care with -Os; while clang’s -Os is generally sane, gcc -Os will e.g. implement division by a constant with IDIV instead of magic multiplication, giving you code that’s maybe three times shorter and easily a dozen or two dozen times slower. (I think I remember Torvalds saying years ago that he gave up on gcc -Os.)
    • josephg 3y ago
      > (Clang’s preferred optimized way to copy a naturally-aligned 16-byte union with a `long double` being the longest member is... to copy the first ten bytes with FLD/FSTP, then the following two bytes of padding by a word-sized MOV, then the final four bytes, also of padding, by a doubleword-sized MOV. Apparently it forgot its MOVAPS at home. Is that still true? Might warrant a bug filed on clang/llvm.
• stephc_int13 3y ago
  Are you aware that STL, exceptions and RTTI are verboten by most game studios? Templates and operators overloading are also quite often frowned up. https://gist.github.com/raizr/c08922b11b33477a1157156e424342dc https://gist.github.com/raizr/c08922b11b33477a1157156e424342...
  • lifthrasiir 3y ago
    Are you aware that "most" game studios nowadays do not use C++ as a primary language anyway? AAA games are really a small portion of all gamedevs anyway, and the stance against modern C++ is not universal even in the gamedev community. Even the linked article states that C++17 is probably fine now, and that's cleanly modern.
• mastax 3y ago
  It's a list of things you can choose to do, and it discusses the trade-offs in most cases. It would be terrible advice if it were framed as "do all these things."
• crest 3y ago
  So is using binary packers like UPX. Not just will they sound the alarm in a lot of so called security products, but they'll also prevent the operating system from sharing the RAM used to mmap() read-only and read-execute pages from the executable while increasing startup times. Removing random sections will also cause headaches when it comes to tracing and debugging in production. Just accept that those sections fulfil real world requirements and aren't just shiny nerd knobs for knobs to mess with. If your code isn't worth being traceable/debuggable in production it's not worth having it installed on production servers. Also don't go too far with the build flags or you risk waking the sleeping horrors lurking in the seldom tested dark corners of the compilers and linkers we all rely on e.g. accidentally changing the effective ABI through tricks like smaller enums. Some of those bugs may only trigger on certain architectures e.g. exception handling works differently on amd64 and aarch64. On one of the two uses special an extra section to locate the unwind helpers. Do you know the all implications of removing a section from an executable? sigh Please keep bloat down, but eager developers shouldn't too far beyond the point of quickly diminishing returns within a given ecosystem they're targeting.
• NL807 3y ago
  Some of the advice listed on here is quite outdated by today's standards.
• flohofwoe 3y ago
  > Not using the STL is really, really bad advice for most. Not really, the STL is an accumulation of mediocre design decisions (mostly because it needs to be "everything to everybody"), which can't be fixed because of backward compatibility requirements. In many situations it's actually better to write your own specialized helper classes.
• maldev 3y ago
  I don't think many actually use the STL besides app dev's. Most systems dev's are targeting WIN32, RTL, UEFI, POSIX, BOOST, UNREAL, or something else. Not only this, but STL also breaks alot of things by what it puts in, Kernel, Unreal, and results in alot of usecases to not use the STL. The only time in my entire career i've ever used the STL was in college. Since most C++ jobs are not Appdevs. All those have moved to C#, Go, or some other higher level language. Or again, just rely on the built in suite like RTL, Posix, Unreal