www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4580] New: Compiler option to port C code or disallow some duplicated C syntax

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4580

           Summary: Compiler option to port C code or disallow some
                    duplicated C syntax
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: bearophile_hugs eml.cc



D language is designed to act as (share the same semantics as) C when a syntax
valid in C is used, so you can avoid bad surprises when you port C code to D.

In some situations following this general principle is seen as too much costly,
so in few advantageous cases D doesn't follow it. Such cases have caused me
bugs when I have translated some C code to D. So I'd like something to avoid
similar bugs when I perform similar porting.

In other situations D keeps both the D-style syntax and C-style syntax to
perform something. This double syntax is surely handy when you convert C code
to D, but in normal D programming makes the D language more confusing (because
there is more than on obvious way to do something), more complex, and has other
disadvantages.

In the D.learn newsgroup Heywood Floyd has started a short thread about 2D
arrays definition, he finds them confusing, and he currently wants to use the
int marr[3][5]; syntax.

It's bad to have two different syntaxes to define arrays in a language. On the
other hand I have found the C-style syntax useful when I have translated some C
code to D (later once the code works correctly I have replaced the C
definitions with D ones).

To solve this problems I propose a new D compiler option, a possible name is
"-cstyle", but other shorter names are possible. This switch is designed to
help porting of C code to D that warns against:

- usage of global floating point variables/arrays that in some C programs are
used without initialization, assuming they are set to zero (while D initializes
them to NaN). This has caused a slow-to-find bug in one of my programs;
- "cstyle" switches on a compile-time warning against the usage of large
fixed-sized arrays, that are passed around by reference in C and recently by
value in D2. So if they are large the program can get slower in D. (I think D
already guards against some C-style arrays usages that exploit the reference
nature of array arguments).


The purpose of -cstyle is not to split D into two languages, it is to tell
apart two different purposes and allow at the same time a safer porting of C
code to D and give a chance to deprecate and later remove some "bad" C syntax
from normal D syntax.


One more possible purpose for -cstyle: to allow the C-style array definition
syntax. So unless -cstyle is used then:
int marr[3][5];
is a syntax error.
This allows to keep the purpose of C-style array definitions (for porting from
C code) while essentially making it deprecated for normal D programs.


Another possible purpose for -cstyle: to allow the C-style function pointer
syntax. This allows to disallow such syntax in normal D programs. This syntax
is confusing and unreadable and can generate bugs, on this see also bug 4530

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 03 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4580




Lars T. Kyllingstad has quickly suggested something that may help solve a
related problem:


 This can be amended by requiring that fixed-size array parameters to
 extern(C) functions be marked as 'ref'.


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 15 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4580




From Walter:

 Just disallowing the C declaration syntax in parameters isn't
 good enough, because the type may be specified by a typedef/alias.


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Sep 15 2010