Skip to main content
13 events
when toggle format what by license comment
Jan 29, 2016 at 17:12 comment added supercat @Deduplicator: Consider also how one would write a function which, given two pointers to pointers of arbitrary type, will swap them (see above). Having to use malloc to create temporary storage seems absurd, but I don't think the Standard allows any alternative. [Note: rather than treating the pointers as void* the function should treat them as struct DUMMY_TYPE*, since structure pointers are allowed to have a different size from void*; violations of the type rules, however, result in UB even when all pointers are the same size].
Jan 29, 2016 at 17:08 history edited supercat CC BY-SA 3.0
added 1274 characters in body
Jan 29, 2016 at 16:54 comment added supercat @Deduplicator: Under a reasonable reading of the Standard, there would be no way to pass the code above two pointers to the same object without invoking Undefined Behavior, and consequently a compiler would be justified in doing whatever it likes. I think the C89 rules were badly written but the common interpretations of them allowed useful optimizations while allowing programmers to do anything that could be done in their absence. Modern philosophy, however, suggests that compiler writers should feel no obligation to go beyond what a compiler-friendly reading of the standard would require.
Jan 29, 2016 at 0:33 comment added Deduplicator I think that's simply a compiler-bug though. Will look at it a bit more tomorrow.
Jan 29, 2016 at 0:26 comment added Deduplicator ;-) Look where I just was: godbolt.org/g/WxKrZO -O2 or more seems to break it...
Jan 29, 2016 at 0:25 comment added supercat See godbolt.org/g/zV5FQw for an on-line compiler tester with the code pre-loaded. In case you don't understand assembly code, bx lr is the ARM equivalent of "return", so the compiler optimizes the function down to nothing.
Jan 29, 2016 at 0:20 comment added Deduplicator Which modern C compiler fails that example? Any interesting options needed?
Jan 29, 2016 at 0:18 comment added supercat @Deduplicator: See the indicated example. Field "i1" is a member of the common initial sequence of both structures, but modern compilers will fail if code tries to use a "struct pair*" to access the initial member of a "struct trio".
Jan 29, 2016 at 0:14 comment added amon OOP does not necessarily require inheritance, so compatibility between two structs isn't much of an issue in practice. I can get real OO by putting function pointers into a struct, and invoking those functions in a particular manner. Of course, this foo_function(foo*, ...) pseudo-OO in C is just a particular API style that happens to look like classes, but it should more properly be called modular programming with abstract data types.
Jan 29, 2016 at 0:11 history edited supercat CC BY-SA 3.0
added 1126 characters in body
Jan 29, 2016 at 0:00 comment added Deduplicator Hm... mind you show how the guarantees the standard gives don't allow you to cleanly access members of the common initial sub-sequence? Because I think that's what your rant about the evils of daring to optimize within the bounds of contractual behavior hinges on this time? (That's my guess what the two downvoters found objectionable.)
Jan 28, 2016 at 23:26 comment added supercat Downvoters: Care to comment? A key aspect of object-oriented programming is the ability to have multiple types share common aspects, and have a pointer to any such type be usable to access those common aspects. The OP's example doesn't do that, but it's barely scratching the surface of being "object-oriented". Historical C compilers would allow polymorphic code to be written in a much cleaner fashion than is possible in today's standard C. Designing object-oriented code in C thus requires that one determine what exact language one is targeting. With what aspect to people disagree?
Jan 28, 2016 at 20:06 history answered supercat CC BY-SA 3.0