tag:blogger.com,1999:blog-5246987755651065286.post408610860090274176..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 07-27-10 - 2d arrayscbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-5246987755651065286.post-3171043180354564402010-07-28T11:33:07.332-07:002010-07-28T11:33:07.332-07:00I also mean "worrying about the standard is p...I also mean "worrying about the standard is pointless" because there is no compiler that actually supports it right. Even pedantic GCC has bugs in its standard compliance, and god help me when I'm on MSVC or whatever other weird thing (and I often have to use GCC from many years ago on other platforms). (especially since I do templates)<br /><br />So I wind up having to compile & run on every platform anyway, even if I knew the standard perfectly in my head I would have to remember each case where there's a difference from it.<br /><br />But I'm just venting because I'm frustrated. You can ignore me now.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-68524109145304928192010-07-28T11:12:03.237-07:002010-07-28T11:12:03.237-07:00Better than
#if __has_sign_extend_rightshift__
w...Better than<br /><br />#if __has_sign_extend_rightshift__<br /><br />would be<br /><br />#requires(__has_sign_extend_rightshift__)<br /><br />and<br /><br />#requires(__float_is_ieee__)<br /><br />and then I can do things that assume those to be the way I know they are, and then if I ever try to compile on a platform that can't do it, it gives me a compile time warning.<br /><br />This is how good code is written, it is for example how the STL is designed.<br /><br />You use certain attributes of the architecture, and you clearly document what you need from the architecture so that you get a compile-time error if you try to use it without those requirements.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-84716343234364984922010-07-28T11:09:06.369-07:002010-07-28T11:09:06.369-07:00" Granted, with all the lock-free stuff you&#..." Granted, with all the lock-free stuff you're in implementation-defined territory, anyway."<br /><br />Actually all I have to do is work on signed integers and I'm in undefined behavior.<br /><br />Or do anything with floats and I'm in non-standard-defined behavior.<br /><br />Or worry about calling conventions, or alignment, or struct packing.<br /><br />Or alias types. Or take the address of a pointer and treat it as void **.<br /><br />Obviously having a standard is good. But it's annoying because on the one hand, it isn't nearly comprehensive enough to actually give me well defined cross platform behavior, and yet it is pedantic about shit that I know will never be a problem on any current platform.<br /><br />The most annoying things about GCC are not about standard compliance that in any way affects portability - they're just syntactic things that are actually completely pointless because it knows exactly what you're trying to write. One is the failure to inherit some typedefs from parent classes unless you "use" them; another is the need to stick "typename" in random odd places.<br /><br />It would be so much better if the C standard actually *did* give me portability, which would require exposing some information about the platform.<br /><br />It would be so awesome if C actually gave me standardized #ifdef things to check like<br /><br />#if __littleendian__<br /><br />or<br /><br />#if __has_sign_extend_rightshift__<br /><br />then I wouldn't have to make masses of my own #defines for that shit.<br /><br />Hell, the C standard should specify a standard syntax for things like "force inline" and calling conventions and so on - then leave it optional whether the compiler does it, but if it does then give me a standard syntax.<br /><br />The result right now is that I have fucking<br /><br />#if __PS2__<br /><br />and <br /><br />#if __GCC__<br /><br />all over my code, and then I am also fighting pedantic standards-compliance junk all the time which doesn't actually help my portability at all.<br /><br />It would also be nice if I could put in a flag somewhere that says "yes I know I am assuming that pointers are ints and I won't work on segmented architectures or anything weird like that so please don't give me any errors about that"cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-19326708833996997112010-07-28T09:36:46.211-07:002010-07-28T09:36:46.211-07:00It isn't pointless, and clearly you are doing ...It isn't pointless, and clearly you are doing it anyway because you are working on a cross-platform library. It is weird to me that you rail against this, since your job would be simpler if the de jure and de facto standards were aligned. Granted, with all the lock-free stuff you're in implementation-defined territory, anyway.<br /><br />And now for a tangent.<br /><br />Some of this shows through in your complaints about volatile, which MSVC interprets as something like volatile in Java, rather than the original C use (signal handling, memory-mapped hardware registers). No doubt, the Java-ish semantics are much more applicable for dealing with concurrency, but hopefully you're not deferring lots of pain for when you need to start supporting C++0x and atomic<> or whatever.<br /><br />Granted, C++0x might be ABI-breaking, so you'll have a fun time supporting that when it happens. Hey, maybe if you time it right it will be someone else's problem and you can take a baby step towards being one of the selfish assholes of the world you claim to despise but secretly envy. ;)won3dhttps://www.blogger.com/profile/09787472194187459747noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-54555471611218418092010-07-28T00:10:57.276-07:002010-07-28T00:10:57.276-07:00But worrying about the standard is pointless and a...But worrying about the standard is pointless and annoying and it angers me that GCC makes me do it so often these days.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-55555908111855311282010-07-28T00:10:24.902-07:002010-07-28T00:10:24.902-07:00"I thought that the C spec says that array el..."I thought that the C spec says that array elements can't be padded beyond struct padding. I'm guessing that this applies recursively, so arrays of arrays cannot contain padding."<br /><br />Yeah I dunno, maybe padding was a bad example.<br /><br />What I have gathered from some random web searching is that the sub-arrays of a 2d array are not gauranteed to be adjacent in memory. Maybe they are allowed to be in different segments or god knows what.<br /><br />In particular for<br /><br />int x[3][7]<br /><br />you would expect that<br /><br />&x[1][0] - &x[0][6] == 1<br /><br />but apparently that is not gauranteed, and furthermore<br /><br />x[0][7]<br /><br />is undefined.<br /><br />but in all real worlds it's fine.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-33916534583964048012010-07-27T15:39:50.841-07:002010-07-27T15:39:50.841-07:00I thought that the C spec says that array elements...I thought that the C spec says that array elements can't be padded beyond struct padding. I'm guessing that this applies recursively, so arrays of arrays cannot contain padding.won3dhttps://www.blogger.com/profile/09787472194187459747noreply@blogger.com