On Wed, Jul 15, 2009 at 8:50 AM, BCS<n...@anon.com> wrote: > Hello grauzone, > >> BCS wrote: >> >>> Reply to Jacob, >>> >>>> I've read posts in several threads complaining about the C >>>> compatibility, the latest was the % operator. Other complains are >>>> that you can use the C syntax for pointers, arrays and function >>>> pointers. Also the "Case range statement" thread that complained >>>> (among other things) about fall through in switch statements. >>>> >>>> Why not the drop this C compatibility in general case >>>> >>> One thing Walter is adement about is that copy-n-paste C code must >>> run correctly (i.e the same) in D or not compile. As for the C style >>> type syntax, I'd be willing to see that go en-total. >>> >> But what for? >> - For headers, you can't include use the C source directly, because >> there are far too many preprocessor directives. Also, headers consist >> mostly of declarations, and not function bodies. > > granted > >> - Normal code you can simply compile in C and link to D. This works >> perfectly fine. There's no real reason to port it to D. And who ports >> large portions of code from C to D anyway? > > Linking C code can get a bit cludgy when you actually go to use it because > of type system miss matches (e.g. C's char* vs. D's char[]). Also cross > language inlining doesn't happen. If it's a small block of code, <~200 LOC, > I'd consider copying the code and pushing the types thought. If you can > count on the correct-or-error bit, this is a lot easier.
Also the pain of multi-language debugging and managing a multi-language build process is sometimes greater than the pain of just porting the darn thing. D is still mostly a superset of C, so I find porting to be kind of semi-mindless fun. Like solving crossword puzzles. There's a little bit of thinking involved but not too much. --bb