www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "C Craft" notes

I am having some troubles with D newsgroups.
Through Reddit I've found a kind of little online book, 13 HTML pages, about C
and other languages:

Instead, I was enchanted by Eiffel, a language so clean that itís sterile. I
became a rabid Eiffel zealot, even trying to prove its superiority in a
programming contest. Long time no C. Then during grad school, I ported one of
my pet projects from Eiffel to C. I forget why. Normally I'd mix C and Eiffel
to talk to the graphics library, but perhaps I had tired of writing glue code.
I slowly awoke from a dream, or more accurately, a mild nightmare. My C code
also worked, except it was faster. It was more concise, which in turn made it
easier to maintain. It was... better.<
I think that using higher level languages has trained him to understand and use some abstractions. Later he's able to implement them in C too. The pages also link a short article about Fortran, that says: http://www.ibiblio.org/pub/languages/fortran/ch1-2.html
Fortran 90 allows explicit pointers restricted to point only to variables
declared with the "target" attribute, thus facilitating automatic
Fortran disallows aliasing of arguments in procedure-call statements (CALL
statements and FUNCTION references), all passed argument lists must have
distinct entries. Fortran disallows also aliasing between COMMON (global)
variables and dummy arguments. These restrictions allows better compiler
The pages explain why Haskell lazy lists are a very good idea, useful and handy for many situations. I agree with the author, they are very different from D/Python lazy ranges. ------------ Some of the things the author desires in an improved C language (I have omitted several already present in D):
- Multiple return values: After writing the first version of a function, often
I want to have the function return more data, such as an error code or
diagnostic data. Iím forced to add an extra pointer parameter, somehow encode
it into the return value, or define a one-off tuple struct. Multiple return
values would be much simpler.
- Flexible array ranges: Arrays indexed from ranges other than [0..N-1] sometimes better fit the problem at hand, for example, an array of triangular numbers. The venerable "Numerical Recipes in C" advocates this hack: float b[4], *bb = b - 1; The elements of b can supposedly be referred to as bb[1] through bb[4]. Unfortunately, section 6.5.6 of the C99 standard appears to state the results are undefined, though it may work for many compilers. - Reflection: The previous wish is a form of reflection. Full reflection may be difficult to add to C, but I wonder how far one can go. - Overflow: I sometimes wish there were a way to detect overflow from basic arithmetic operations. - The conventions for symbol visibility should be reversed, that is, public exposure should be opt-in, not opt-out. Similarly for static versus extern functions. Bitwise AND and OR should have higher precedence.< Flexible array ranges: they introduce some extra complexity (when you read some code you can't just assume an array starts from zero, you have to take a look at the array type definition or declaration), but in some cases they simplify the code and maybe make it less bug-prone. You write: int['a' ... 'z'] arr; arr['f']++; Instead of something like: int[cast(int)'z' - 'a' + 1] arr; arr['f' - 'a']++; This feature seems less useful if you are using larger Unicode characters. Converting to D routines written in older 1-based languages is another usage, but probably not important enough. Module symbols visibility: in D with "private" you are to turn module names (gloabal alias, global variable, global function, global class, template, ecc) private when you import the module from another one. But indeed it's easy to forget to add "private" to things you don't want to get imported. Reversing the situation (and requiring "public" for the names you want to let other modules see) seems a safer default. -------------- The last page is about Go language, and it links to a document of comments about Go (November 2009, not up to date): http://www.math.bas.bg/bantchev/misc/on-go.html Some of the things this "on-go" article says about Go, that I partially like:
 i++ is allowed, and ++i is not. Pike says 'the postfix version is more
 Assignments of all kinds, including ++ and --, are statements, not expressions.
 There is no , (comma) operator. (The need for it has been to a great extent
obviated by multiple assignment, but still.)
 Bitwise operator &^, 'bit clear': like & with a (bitwise) negated argument.
Bitwise negation itself is absent
Bye, bearophile
Apr 17 2011