tag:blogger.com,1999:blog-1994130783874175266.post1719661096412519879..comments2024-03-29T08:23:52.087+01:00Comments on bitsquid: development blog: A new way of organizing header filesNiklashttp://www.blogger.com/profile/10055379994557504977noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-1994130783874175266.post-75911081827702239572024-03-15T21:56:39.146+01:002024-03-15T21:56:39.146+01:00The cost of a smart tv price in pakistan might va...The cost of a <a href="https://www.vividshop.pk/product-category/television/smart-led-tvs/" rel="nofollow">smart tv price in pakistan</a> might vary significantly in Pakistan, depending on the budget and tastes. Screen size, resolution quality (HD, Full HD, 4K), intelligent features (such as built-in WiFi and streaming app compatibility), and other technical improvements (like HDR and Quantum Dot display) all have an impact on the price. amnaimranhttps://www.blogger.com/profile/08669535265997771923noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-38144882785640918522022-11-17T13:46:10.068+01:002022-11-17T13:46:10.068+01:00Hello! Semantic segmentation annotation outsourcin...Hello! Semantic <a href="https://mobilunity-bpo.com/outsource-semantic-segmentation-for-deep-learning/" rel="nofollow">segmentation annotation outsourcing</a> is very popular in today's world, but how do you find the best service provider on the market? I advise you to pay attention to our company Mobilunity-BPO! We have access to the best specialists and have been helping companies around the world for many years!NathanPasshttps://www.blogger.com/profile/11522768748336158083noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-69279345585608365882012-10-05T15:32:59.094+02:002012-10-05T15:32:59.094+02:00I don't think that's exactly the same thin...I don't think that's exactly the same thing.<br /><br />With the .inl approach you would still typically have the function declarations in the .h file. What I'm proposing is to move the function declarations as well to a separate file, and just have the minimal raw data definitions in the _types.h file.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-30962104917764294772012-10-01T08:03:20.458+02:002012-10-01T08:03:20.458+02:00The idea's actually not that uncommon. Most p...The idea's actually not that uncommon. Most people who have deployed it actually reorganize their classes as follows:<br />1) Pure type declaration (.h file)<br />2) Inline definitions (.inl file)<br />3) Non-inline definitions (.cpp file)<br /><br />There's a brief discussion here on StackOverflow: http://stackoverflow.com/questions/1208028/significance-of-a-inl-file-in-c<br /><br />The only downside I've seen to this approach is extra burden on any client .cpp file to always include the .inl. You can get into a state where missing includes may not be detected until link time and be entirely dependent on your compiler options. Example:<br />1) ClientOne.cpp needs ClassA's inline functions so includes ClassA.inl.<br />2) ClientTwo.cpp also needs those but forgets to include ClassA.inl.<br /><br />If ClientOne.o and ClientTwo.o are linked into the same executable you may get undefined references from ClientTwo.o:<br />1) If the inline functions were able to be inlined then ClientOne has the code but ClientTwo does not.<br />2) If the inline functions were too big to be inlined then ClientTwo accidentally gets access to ClientOne's weak-reference copies and linking succeeds.Unknownhttps://www.blogger.com/profile/01060334244869056954noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-90101618628988533932012-09-25T06:34:15.369+02:002012-09-25T06:34:15.369+02:00Violation of the Once And Only Once principle. Du...Violation of the Once And Only Once principle. Duplication of function prototypes.Rev. Chiphttps://www.blogger.com/profile/08994814183955727759noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-15750558324807751382012-09-17T08:57:35.897+02:002012-09-17T08:57:35.897+02:00I have only done some very small baby steps for th...I have only done some very small baby steps for the Bitsquid code base, which haven't really affected the compile time. (It's a production code base, so I don't want to make drastic changes.)<br /><br />We have ~1 minute compile times ATM. We do multithreaded builds and use SSDs. We don't do distributed builds.<br /><br />I don't think types.h will change *that* much. It is usually quite rare that you change the fundamental data types (at least if you have thought things through). I think overall there might be *less* recompiling... because currently a lot of recompiling happens because I add a private helper member function -- that would disappear.<br /><br />And of course the goal of this is to reduce our build times... once a full rebuild is down at 30 s -- we don't even have to care that much if it happens once in a while.<br /><br />But I agree that if you are at 20 minute distributed builds there might be other reorganization that you need to do before you go all out with this approach.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-41801962404875931822012-09-15T20:50:56.774+02:002012-09-15T20:50:56.774+02:00Niklas, can you give us roughly:
* the number of #...Niklas, can you give us roughly:<br />* the number of #include's you were able to eliminate by nudging the Bitsquid codebase toward a "types.h" approach<br />* the compile-time speedup you attained<br />* what build environment you use (distributed compilation? CPU speeds? HDDs or SSDs?)<br /><br />I'm curious to know how big the win has been for you.<br /><br />I think the only significant downside to a "types.h" approach is, as Ryan pointed out, a near-full rebuild upon any change of types.h. This sounds fine for a 1-2 minute Bitsquid build, but would be catastrophic (at least at first) for some of the commercial game engines I've worked with (where full builds routinely exceeded 20 minutes with compilation distributed over 10 decent PCs).<br /><br />Thanks for the articles, Niklas -- they're always good reading.Nathan Frosthttps://www.blogger.com/profile/03019576976255976341noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-25763912193688280752012-09-13T00:52:32.235+02:002012-09-13T00:52:32.235+02:00Material for ideas...
Experiments With Includes
h...Material for ideas...<br /><br />Experiments With Includes<br />http://gamearchitect.net/Articles/ExperimentsWithIncludes.html<br /><br />Even More Experiments with Includes<br />http://gamesfromwithin.com/even-more-experiments-with-includes<br />Andrei Milyukovhttps://www.blogger.com/profile/03173987903028301609noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-37691157744544295052012-09-06T09:25:09.118+02:002012-09-06T09:25:09.118+02:00Yes, but in my experience, core data types don'...Yes, but in my experience, core data types don't change *that* often. (When headers change it is usually because you add new methods.) Second, a change in the fundamental data types is likely to trigger a recompile of a large part of the code anyway. And third, with this approach a full recompile should take less than a minute, so it is not a catastrophe.<br /><br />Still for a large system I would probably do some partitioning of types.h (maybe having things like math_types.h, collection_types.h, etc). But having a *_types.h file for every .h file leads to too much file juggling for my taste.Niklashttps://www.blogger.com/profile/10055379994557504977noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-80718981935593403012012-09-05T18:51:27.715+02:002012-09-05T18:51:27.715+02:00Breaking out the state and functionality has been ...Breaking out the state and functionality has been something I've been doing lately and it's really, really nice. Knowing that all state is, inherently, represented in a single structure is pretty incredible when it comes to managing memory and serialization.<br /><br />Having a central types.h file create something of a nasty hotspot for recompilation. Wouldn't any trivial change to any data structure result in a recompile of any file using the types (which is probably everything)?<br /><br />Breaking out the class/struct definitions into separate files would still provide most of the benefits as far as I can see, but is there a reason aside from ease use to have everything in that single header?Ryan C. Scotthttps://www.blogger.com/profile/10070810469767856313noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-84042801387727294482012-09-05T13:54:40.270+02:002012-09-05T13:54:40.270+02:00The idea of using a types.h with class/struct usin...The idea of using a types.h with class/struct using "_" prefix as naming convention,<br />and then having functions operating on these types, <br />is just like the Go programming language.<br />Nice to see it adapted in C++.<br />datgamehttps://www.blogger.com/profile/01223684777860896451noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-55938156609822782862012-09-04T04:33:51.666+02:002012-09-04T04:33:51.666+02:00It's a pain that object implementation is link...It's a pain that object implementation is linked to heap and stack allocation, it would be cool to be able to declare a type interface in a header, with all the methods, and the object storage into another header. If you include only the interface, you can only work with said object via pointers or references, and create it on the heap.<br /><br />It would be possible to hack this I guess having a class with no member variables and hacking new to allocate the needed space for the private data structure, but then you would not be able to work with said class on the heap at all, you would break the debugger and so on...<br /><br />So nothing, your approach is nice, I was wondering if it could be worth to have private members and all your external functions as static in a friend class instead. That could give you still the separation between public and private members. It would not work with operators though and it's probably not a bright idea. As you say, naming conventions are enough and if programmers want to hack around them, they can hack around anything.DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-1994130783874175266.post-51561601659259798812012-09-03T22:37:05.921+02:002012-09-03T22:37:05.921+02:00Cool stuff man. The more I use c++, the more I sta...Cool stuff man. The more I use c++, the more I start to hate all its fancy features and start leaning towards traditional c-style (structs and functions), wrapped up in namespaces. Seems like what your explaining is similar to what im doing! Except you go one step further to group by functionality instead of type.<br /><br />I would like to see how types.h ends up on any large scale project if _all_ your types are literally in thereMashhttps://www.blogger.com/profile/07973838352357167231noreply@blogger.com