www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C compatibility

reply Jacob Carlborg <doob me.com> writes:
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 but still allow 
the C compatibility in extern (C) blocks?

/Jacob Carlborg
Jul 14 2009
parent reply BCS <ao pathlink.com> writes:
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 still allow
 the C compatibility in extern (C) blocks?
 

Yuck, that would make the parser much more... interesting. ;)
Jul 14 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
BCS wrote:
 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.

It's useful if you have a .h that you both include in a C/C++ file and run through a preprocessor to output a .d file.
Jul 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 BCS wrote:
 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.

It's useful if you have a .h that you both include in a C/C++ file and run through a preprocessor to output a .d file.

I agree: http://www.digitalmars.com/d/2.0/htod.html
Jul 14 2009
parent Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
Walter Bright wrote:
 Robert Fraser wrote:
 BCS wrote:
 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.

It's useful if you have a .h that you both include in a C/C++ file and run through a preprocessor to output a .d file.

I agree: http://www.digitalmars.com/d/2.0/htod.html

From DMD's source (parse.c, Parser::isDeclarator): /* Regard ( identifier ) as not a declarator * BUG: what about ( *identifier ) in * f(*p)(x); * where f is a class instance with overloaded () ? * Should we just disallow C-style function pointer declarations? */ I guess the answer to that question would be no.
Jul 14 2009
prev sibling parent reply grauzone <none example.net> writes:
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. - 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? - There's already code, that compiles with in D1 and D2, but has slightly different semantics. (Um, don't ask me for examples.) Why is compatibility to C more important than compatibility within the same language?
Jul 15 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
grauzone:
 And who ports large portions of code from C to D anyway?<

Are routines ~300 lines long "large portions"? :-)
Why is compatibility to C more important than compatibility within the same
language?<

Because compared to the number of people that today use C, the number of people that today use D1 can be ignored. Bye, bearophile
Jul 15 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
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
 

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.

- 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.
Jul 15 2009
parent "Nick Sabalausky" <a a.a> writes:
"BCS" <none anon.com> wrote in message 
news:a6268ff81df8cbd3406e78dc0e news.digitalmars.com...
 Hello grauzone,

 - 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, if I had some C codebase I was actively maintaining, I'd rather switch to D than continue working in C. Yea, I'm that tired of C ;) But FWIW, I do agree that sometimes certain things that are done for the sake of C compatibility seem to be...well, taking things a bit further than they really need to be at too high of a cost to regular D code.
Jul 15 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Wed, Jul 15, 2009 at 8:50 AM, BCS<none 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

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.

- 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
Jul 15 2009