Greetings:

D looks like a great language, better even than C#. Congratulations!

-----

Before I start listing what I feel are some shortcomings of the language let me first state that I have done very little C++ and C# programming; all my jobs have involved just plain C... VAX C and DECC at that. And that was with embeded SQL as well. So please bear that in mind.

Also, I just joined this list and have not read the previous messages, so please excuse me if I repeat any subjects that have been brought up and argued.

-----

I kinda like C#'s requirement that cases in switch statements not just fall through to the next case in the absence of a break statement.

-----

I don't see any reason to have the ability to insert D code in HTML as a feature of the language, that seems to make no sense. At most I see it as a feature of the compiler, not the language itself. Further, why even have it as a feature of the compiler? Why not simply have it as a standalone tool? Then the tool can be used with other languages; e.g. C.

My main reason for saying that it makes no sense is that generally documentation
doesn't contain the actual code of the application being documented. The only
people who need to see the code would be seeing the internal comments and such
anyway.
And library users only need to have the interfaces documented. In the case of
open source, the user has access to the actual code.

When I was creating HTML documentation for my C library the only bits of code I
included were done like:
<acronym title="typedef int MYTYPE">MYTYPE</acronym> myfunc ( ... ) { ... } ;

But a bigger concern about this feature of the compiler (other than that it's non-sensical) is that it causes trouble (see below and attached) which can only be solved by modifying the code so that it will work, and that's bad... and ugly.

In fact I suggest two standalone tools; one to HTMLify the code, and one to extract the code from the HTML. The user would write the code as usual and then HTMLify it to form the documentation, as silly as that documentation would be.

-----

Why continue the awful C format of the date as a string, why not elevate yourself above the muck and use ISO8601 format? And where does the date system get the timezone and DST information? Again, be better than C in this, include the time zone and DST settings in the basic time value object (d_time).

-----

In my C code I use __FILE__ and __LINE__ and also __FUNC__ when I'm writing
messages to a run log (I never heard of assert() until I read the D
specification). Assert() won't work for me because I need to include the date
and time (in ISO8601 format). So I suggest these be included in the language.

But of course I have also already proven to myself that I can pass the D code through a C preprocessor to take care of that (other than __FUNC__ which actually is not handled by the preprocessor), as well as the other C preprocessor directives like #define and #include. Ha ha! Take that!

-----

I prefer C's requirement that all declarations in a statement block appear before any executable code. Allowing the mixing of declarations and executable may make it difficult to find a declaration, which is poor programming style.

I do however like the ability to declare the iterator of a for statement within the statement (which C# does as well).

-----

Concerning modules...

In C I can put each function in its own file, compile them and put them in a
library, then link the library into the executable (after #including the header
file(s) of course).

This allows a team to work on the code more easily; Abe doesn't need to wait for Betty to finish her work on the code when each needs to modify different functions, as would be the case when both functions are in one file. Also, when using a version control system (SourceSafe, CMS, whatever) you would see that the file was changed, but you'd need to see the comments (provided they were updated) to know which function(s) was changed, having one function per file solves that. Plus, doing an incremental build is quicker if only the changed function is recompiled rather than everything in the file.

With D, each of those functions would be in its own module? Would they have
trouble referring to each other? Would there be trouble building them?
C can do it because code that calls a function in a different file only needs to
read the prototype in the header file, but D doesn't have prototypes and header
files so it needs to read the whole source file (yuck!).

With C++, separate files for the methods can still be done because of the class::func() { ... } syntax. This seems to be impossible with D (and C#); that the methods must be fully declared inside the class (yuck!). I can see why C# needs to do that, but why does D? Is it simply because you don't like prototypes?

Although I guess I can do something like:

class X
{
int y ;

#include "x_func.d" // Contains code for X::func()
}

But then I still need to recompile everything even though there may be only a
small change, probably a shortcoming of OOP.
Plus, the line numbers would be of no help in debugging.

-----

In the specification (I read the PDF version) it lists as a shortcoming of #define macroes that they can't declare variables... of course they can:

#define REPEAT(x,y) \\ Repeat statement x y times \
{ \
int i ; \
for ( i = 0 ; i < y ; i++ ) \
{ \
x \
} \
}

-----

Another benefit of #defined macroes is it allows things like:

#define abs(x) ((x)<0?(x)*-1:(x))

which doesn't care whether it's passed an int or a float and so you don't need to write a separate function for each type. And you don't need to change the call if you change the type.

As far as abs is concerned, perhaps it should be a method? And a method to change the sign?

-----

<html>
<head><title>Naughty D code in an HTML file</title></head>
<body>

<center><h1>Examples of D code in HTML that don't work correctly</h1></center>

And I realize that all or most of the problems are due to poor style, that there
<em>should</em> be spaces around the operators and such.
<hr>

<code>
import c.stdio;<br>
<br>
int<br>
main<br>
(<br>
char[][] args<br>
)<br>
{
<blockquote>
int nbsp=1;<br>
int quot=3;<br>
<br>
int test1=quot&nbsp;<br>
; // Added so the thing will compile<br>
int test2=quot&amp;nbsp;<br>
<br>
/+ Not fixable like the previous one<br>
int test3=nbsp&quot;<br>
+/<br>
int test4=nbsp&amp;quot;<br>
<br>
printf("test1==%d\ntest2==%d\ntest4==%d\n",test1,test2,test4);<br>
<br>
char[] test5="<H1>Whoops!</H1>";<br>
char[] test6="&lt;H1&gt;Ah, that's better.&lt;/H1&gt;";<br>
<br>
printf("test5==%.*s\ntest6==%.*s\n",test5,test6);<br>
<br>
return 1;
</blockquote>
}<br>
</code>

</body>
</html>
----------   

John
PIEBALDconsult@aol.com

  <PIEBALDconsult@aol.com> wrote in message news:bi669l$2b4e$1@digitaldaemon.com...
  Greetings:

  D looks like a great language, better even than C#. Congratulations!

  -----

  In fact I suggest two standalone tools; one to HTMLify the code, and one to
  extract the code from the HTML. The user would write the code as usual and then
  HTMLify it to form the documentation, as silly as that documentation would be.
  -----
I would agree that D code should be in D syntax, if you want html write a tool to either convert or strip.

  I prefer C's requirement that all declarations in a statement block appear
  before any executable code. Allowing the mixing of declarations and executable
  may make it difficult to find a declaration, which is poor programming style.

  I do however like the ability to declare the iterator of a for statement within
  the statement (which C# does as well).
  -----

C++, C# and Java allow you to declare a variable anywhere not just at the beging of a scope
in C it is valid to write
void func( int i ) {
    printf("i is %d\n", i);
    {
        int j = i+5;
        printf("j is %d\n", j);
    }
}

not too far removed from
void func( int i ) {
    printf("i is %d\n", i);
   int j = i+5;
    printf("j is %d\n", j);
}

With C++, separate files for the methods can still be done because of the class::func() { ... } syntax. This seems to be impossible with D (and C#); that the methods must be fully declared inside the class (yuck!). I can see why C# needs to do that, but why does D? Is it simply because you don't like prototypes?
-----

all I can say is how bigs you project and how much effort do you have to put in to keep the headers inline with the implementations (and why write them twice).
get an editor that does code folding,
the benifits of having implementation and interface defined together outweighs the slightly larger files (imho) ( yes I have been know to write 3 sub classes in 3 separate modules just to keep the code separated but still prefer it as it is).
I do prefer the Java one public class per file , and would like D to allow a class per file or a module per file.

> I prefer C's requirement that all declarations in a statement block appear before any executable code. Allowing the mixing of declarations and
executable
> may make it difficult to find a declaration, which is poor programming
style.

OTOH, if a variable isn't used until almost the end of the scope, you have go back to the beginning of the scope to figure out what it's type is, and (in D) this style will also incur some redundant initialization in many cases since (IIRC) all variables are default-initialized.  In any case, if finding the declaration is a problem, it's usually because the scope has gotten too large and should be broken up into multiple functions.

Incidentally, for these reasons and others, many C++ programmers consider this practice to be poor programming style.

> I do however like the ability to declare the iterator of a for statement
within
> the statement (which C# does as well).

Then it sounds as though you may already appreciate at least some of the value of not being forced to declare all variables at the start of the scope.

Scott McCaskill

<PIEBALDconsult@aol.com> wrote in message news:bi669l$2b4e$1@digitaldaemon.com...
> I prefer C's requirement that all declarations in a statement block appear before any executable code. Allowing the mixing of declarations and
executable
> may make it difficult to find a declaration, which is poor programming
style.

It's the worst style, except for all the others. In C,  you can open new scopes, but programmers rarely do because they find the nesting ugly. The other option, declaring variables long before use, makes it harder to determine the true lifetime of a variable, how it's being used, whether it has been initialized properly, etc. The declaration is just one piece of information, not everything you need to know.

Sam

"Go to declaration" is your friend.

Browse info generation gives you the power to instantly unravel arbitrarily complicated code a step at a time.  Do you need anything else?  You certainly can't hope to force all programmers to use single-page functions!

IDE's these days are Da Bomb.  Look at C# for an example of two-way instant compilation.  It underlines errors as you type, etc.  One of these days you probably won't need a "rebuild" button at all.

That said, I hate seeing functions with variable declarations all at the top because I have to jump back and forth across pages to see them.  Oftentimes I regret even having to specify a type.  I've witnessed many a bug that was a bug in a declaration that was hidden because the bug was far away from the declaration; your brain never sees them together at the same time.

Sean

"Samuel Barber" <opendtv@yahoo.com> wrote in message news:bielig$5gt$1@digitaldaemon.com...
> <PIEBALDconsult@aol.com> wrote in message news:bi669l$2b4e$1@digitaldaemon.com...
> > I prefer C's requirement that all declarations in a statement block
appear
> > before any executable code. Allowing the mixing of declarations and
> executable
> > may make it difficult to find a declaration, which is poor programming
> style.
>
> It's the worst style, except for all the others. In C,  you can open new scopes, but programmers rarely do because they find the nesting ugly. The other option, declaring variables long before use, makes it harder to determine the true lifetime of a variable, how it's being used, whether it has been initialized properly, etc. The declaration is just one piece of information, not everything you need to know.
>
> Sam