| Lynn McGuire <lynnmcguire5@gmail.com>: Sep 13 05:33PM -0500 "C++20 Modules — Complete Guide" by Šimon Tóth https://itnext.io/c-20-modules-complete-guide-ae741ddbae3d "Compilers and build systems are slowly starting to support C++20 modules. Perfect time for you to read this guide and benefit from the massive compilation speedups. This article reflects the state as of September 2021." Lynn |
| Vir Campestris <vir.campestris@invalid.invalid>: Sep 13 10:00PM +0100 On 13/09/2021 04:12, James Kuyper wrote: <snip> > files in git? How about executables? You don't need to update them > manually; if you set up your build system properly, they get updated > automatically when needed. </snip> We absolutely keep executables in a controlled archive. The build system produces a system image; this is in turn made from various files, some of which are executable; we store the image, the executables, the symbol files that go with them, and put a label in the source control system to show where it was build from. The executables and symbols can save a _lot_ of time when looking at dumps. Andy |
| Ian Collins <ian-news@hotmail.com>: Sep 14 09:24AM +1200 On 14/09/2021 09:00, Vir Campestris wrote: > executables, the symbol files that go with them, and put a label in the > source control system to show where it was build from. > The executables and symbols can save a _lot_ of time when looking at dumps. But they can be recreated from the source and a given source control hash or tag? -- Ian |
| scott@slp53.sl.home (Scott Lurndal): Sep 13 09:42PM >> The executables and symbols can save a _lot_ of time when looking at dumps. >But they can be recreated from the source and a given source control >hash or tag? Maybe. If you have the exact same compiler, assembler and linker. Maybe. And not if the linker uses any form of address space randomization. |
| Ian Collins <ian-news@hotmail.com>: Sep 14 10:15AM +1200 On 14/09/2021 09:42, Scott Lurndal wrote: >> But they can be recreated from the source and a given source control >> hash or tag? > Maybe. If you have the exact same compiler, assembler and linker. Maybe. We build everything in virtual machines or docker, so the build environment for any build can be recovered. Our CI system generates ~500GB of built artifacts per day, which doesn't include intermediate items such as object files. Not something we'd want to keep around forever! > And not if the linker uses any form of address space randomization. This hasn't bitten us. Our target is (literally!) a closed black box. -- Ian |
| red floyd <no.spam.here@its.invalid>: Sep 13 01:21PM -0700 On 9/11/2021 3:35 AM, Bonita Montero wrote: > to a C++-function an extern "C" function and this function is > called through its pointer by the extern "C" function it might > throw an exception. I can see how the following case might throw.... Disclaimer: I have no idea what the Standard says about it. class C { public: static void i_throw() { throw 1; } }; extern "C" throwing_c_func() { C::i_throw(); } |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment