• Jacob Carlborg (8/8) Jul 14 2009 I've read posts in several threads complaining about the C
• BCS (5/15) Jul 14 2009 One thing Walter is adement about is that copy-n-paste C code must run c...
• Robert Fraser (3/6) Jul 14 2009 It's useful if you have a .h that you both include in a C/C++ file and
• Walter Bright (3/10) Jul 14 2009 I agree:
• Ellery Newcomer (9/21) Jul 14 2009 From DMD's source (parse.c, Parser::isDeclarator):
• grauzone (12/25) Jul 15 2009 But what for?
• bearophile (5/7) Jul 15 2009 Because compared to the number of people that today use C, the number of...
• BCS (7/30) Jul 15 2009 Linking C code can get a bit cludgy when you actually go to use it becau...
• Bill Baxter (7/37) Jul 15 2009 Also the pain of multi-language debugging and managing a
• Nick Sabalausky (7/16) Jul 15 2009 Also, if I had some C codebase I was actively maintaining, I'd rather sw...

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

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. ;)

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.

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

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.

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?

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

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
 

 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.  

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

 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

"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.