Jonas:

> Could you please elaborate on this a bit more? What's the problem with helpful compiler messages?

Walter likes helpful error messages, but I think he doesn't want to:
1) Use too much time to improve them. There are usually more important problems to fix.
2) Slow down the compiler (or make it use more RAM) to generate better errors (this seems to happen if you want the column number too of the error).
3) Produce too much long error messages because he thinks most people are annoyed by a command line interface that gets too much scrolling caused by many long error messages (I think most people think this is a bit ridiculous justification).

But if you want to add/improve specific error messages, then ask for the specific improvements in D Bugzilla as enhancement request.


> That looks great, thanks, although it's a bit cluttered with all those languages ;-)

That 'clutter' is the real purpose of that site.

If you know language X, you don't know language Y but you want to learn language Y, often in that site you are able to find the same algorithm/code implemented in both X and Y. Comparing them you are able to learn some Y and  the best idioms of Y too. Just like the true Rosetta Stone did for Egyptian language :-)

That site has other secondary purposes:
- There you often find good computer science ideas or good programming ideas/tricks to learn from.
- Comparing the same algorithms in many very different languages you are sometimes able to catch better the essence of an algorithm, that is what's invariant of those implementations. A good book that introduces to algorithms is supposed to show this "essence" but often it doesn't, because a book on algorithms like the one by Robert Sedgewick is mostly procedural, even if he has written books for Java, C, C++. On that site you find wildly different implementations based on different programming paradigms, like templates, pure lazy functional, dynamic homoiconic functional, parallel, OOP, logic programming, concatenative programming, stack-based, even flow programming. All those programming paradigms are usually absent on books like Robert Sedgewick ones. And often the comparison teaches you something. Because sometimes an algorithm or data structure must be changed to fit (otherwise you get things like QuickSort or the Sieve of Eratosthenes implemented naively in Haskell, with so bad performance that they essentially have become a different algorithm).
- If you are interested not just in algorithms (or little programs) and their implementations, but also in programming languages themselves and their design, then that site helps you slowly gain a broader vision of what different languages offer to solve specific problems, what the "taste" of a language is, what languages are elegant or not, what languages seem an agglomeration of features, what languages are practical "engineering products" like D or not, what type systems seem intrusive and what are too much rigid, and so on and on. So if you want you are able to use that site to learn how to design languages too, a bit.
- That site has several other smaller purposes.

Bye,
bearophile

On 04/09/12 17:39, Andrej Mitrovic wrote:
> On 4/9/12, Jonas <jonas@lophus.org> wrote:
>> On Saturday, 7 April 2012 at 22:42:19 UTC, Stefan wrote:
>>> printf is a C function which expects 0-terminated strings. D's strings are variable-length arrays and not zero-terminated.
>>>
>>> Don't use printf. Try using writef instead. Same arguments.
>>
>> http://d.puremagic.com/issues/show_bug.cgi?id=7872
> 
> I don't think the compiler can warn about this. Isn't printf one of those unsafe C variadic functions? Someone correct me if I'm wrong.

It is, but arguably this is exactly why it should warn - it's unlikely that passing a D array to an extern(C) variadic function is really what the programmer intended. Except of course when he relies on the internal D array representation - and, as this hack is given as an example on dlang.org, issuing a warning is out of the question, w/o special-casing for printf and parsing the format string...

However, there's no reason why *std.stdio* should expose the raw printf
function - i didn't even realize it did until now...
It either shouldn't be available via std.stdio at all, or something
like this wrapper should be added there, to catch the inevitable mistakes:

int printf(string F=__FILE__, int L=__LINE__, A...)(A args) {
   import std.typetuple;
   import std.string;
   import std.c.stdio;
   alias ReplaceAll!(immutable(char)[], char*, A) CA;
   CA cargs;
   foreach (i, arg; args) {
      static if (is(typeof(arg):const(char)[])) {
         pragma(msg, F ~ ":" ~ L.stringof ~
           " Warning: C function printf expects zero-terminated (char*), not D array");
         cargs[i] = cast(char*)toStringz(arg);
      }
      else
         cargs[i] = arg;
   }
   return std.c.stdio.printf(cargs);
}

The raw printf can then still be used via std.c.stdio or core.stdc.stdio,
but a program using just std.stdio will print a warning instead of segfaulting.
Parsing the format string to avoid the warnings for the "%.*s" case could be
done too, i guess.


On 04/09/12 17:50, Jonas H. wrote:
> The GCC C compiler proves you wrong :) They have warnings. I guess it's a hack (because printf really doesn't belong into the compiler) but that doesn't matter.  What matters is user-friendliness.

D doesn't even need compiler support for this - it can be done completely inside the library.

artur

On 4/9/12, Artur Skawina <art.08.09@gmail.com> wrote:
> However, there's no reason why *std.stdio* should expose the raw printf
> function - i didn't even realize it did until now...
> It either shouldn't be available via std.stdio at all, or something
> like this wrapper should be added there, to catch the inevitable mistakes:

I think most mentions of printf should just be removed from the dpl docs except maybe a few special places. People (or rather C++ refugees) seem to expect D to be a syntax sugared version of C++, but this myth has to be busted.

On 04/09/2012 07:22 PM, Andrej Mitrovic wrote:
> I think most mentions of printf should just be removed from the dpl
> docs except maybe a few special places. People (or rather C++
> refugees) seem to expect D to be a syntax sugared version of C++, but
> this myth has to be busted.

I don't think that's true, or at least I didn't think of D like that. It becomes pretty clear after reading the introduction that D does not try to emulate C++, let alone be compatible to C(++).

Nevertheless, because the syntax and terminology are quite similar, people expect stuff to have the same names. That's why I expected the standard printing function to be named `printf` and this attempt failed miserably, without any guidance from the compiler/stdlib/whatever.

On 04/09/2012 08:50 AM, Jonas H. wrote:
> On 04/09/2012 05:39 PM, Andrej Mitrovic wrote:
>> I don't think the compiler can warn about this. Isn't printf one of
>> those unsafe C variadic functions? Someone correct me if I'm wrong.
>
> The GCC C compiler proves you wrong :) They have warnings. I guess it's
> a hack (because printf really doesn't belong into the compiler) but that
> doesn't matter. What matters is user-friendliness.

Indeed. dmd should warn about any incompatible data passed as variadic parameters. It's simple to decide: only fundamental types that correspond to C counterparts should be allowed. Hmmm... Even that's not that simple: int is 32 bits in D but unspecified in C.

Ali

On Monday, 9 April 2012 at 20:18:29 UTC, Ali Çehreli wrote:


>> The GCC C compiler proves you wrong :) They have warnings. I guess it's
>> a hack (because printf really doesn't belong into the compiler) but that
>> doesn't matter. What matters is user-friendliness.
>
> Indeed. dmd should warn about any incompatible data passed as variadic parameters. It's simple to decide: only fundamental types that correspond to C counterparts should be allowed. Hmmm... Even that's not that simple: int is 32 bits in D but unspecified in C.

Maybe printf should not be visible at all - or under a different name ("cprintf" or something similar). It's just too tempting...

C variadic arguments are one of the most unsafe features of the C language. A total mess.

Stefan