On Thursday, 30 October 2014 at 10:24:19 UTC, Paulo  Pinto wrote:
> On Thursday, 30 October 2014 at 09:39:42 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 30 October 2014 at 08:02:49 UTC, Paulo  Pinto wrote:

> In 30 years of coding I never found this to be a problem and it saved a lot of bad pointers being passed on to functions.

For the record, the interview is fake (albeit quite realistic sometimes...).

> Again, I am spoiled by better languages for systems programming

Of course. We are all here exactly because of that. I am quite very much afraid sometimes that D will end up by losing the "systems" in its definition but I hope my fears have no ground.

On Thursday, 30 October 2014 at 11:03:08 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 30 October 2014 at 10:24:19 UTC, Paulo  Pinto wrote:
>> In 30 years of coding I never found this to be a problem and it saved a lot of bad pointers being passed on to functions.
>
> Why bad pointers, they are typesafe?
>
> What I dislike the most about C ptrs is this:  "ptr->field" vs "object.field"

void mightCrash (int *value)
{
   // Is value pointing to somewhere sane? How do you validate it?
   *value =  23;
}

What's really desireable is to never ever use output parameters.

Atila


On Thursday, 30 October 2014 at 09:39:42 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 30 October 2014 at 08:02:49 UTC, Paulo  Pinto wrote:
>>> 3. No non-const ref parameters to functions, use pointers. They want a visible "&" at call site for output parameters. e.g. "read(&var)" so that you don't have to look the function up in the docs.
>>>
>>
>> Coming from a Quick/Turbo Basic/Turbo Pascal background, I never understood the C culture about function parameters.
>>
>> Just another example of C being unsafe.
>
> C is unsafe, but it is desirable to make it visible at the call site that you are returning a value through a parameter. I think it is a good idea to create a special "zero-cost" wrapper type so that you write:
>
> copy_from_to( input, returns(output) )
>
> I noticed that c++11 has a ref() function:
>
> http://en.cppreference.com/w/cpp/utility/functional/ref

On Thu, Oct 30, 2014 at 07:25:42AM +0200, ketmar via Digitalmars-d wrote:
> On Wed, 29 Oct 2014 21:59:25 -0700
> "H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
> 
> > Nowadays, it's all mostly muscle memory for me -- I don't even think about how to use it anymore, my fingers just "know" what to do to make a certain edit.
>
> yeah, that is what i missing for now. i have to force myself to use vim like i forced myself to use D some time ago. i was trying to drop D each time i need to do something more complicated than `writeln("hello world!")`, but resisting that desire. and now i have the reverse effect: i want to drop C each time i must write something with it. ;-) where is all my joy? where are my strings, slices, templates, metaprogramming? and don't even show me that C macros anymore! ;-)

Yeah, D has officially ruined my life. Now I cringe every time I look at C/C++ code. :-P


[...]
> > And once I get some free time, I'm gonna take a shot at implementing compile-time checked format strings, which Andrei has already preapproved. D totally blows C++ out of the water with taking metaprogramming to whole new heights of cool, I tell ya.
>
> i recently wrote a very simple static 'writef', which genertes mixin with calls to posix `write()` and i really like it. nothing serious, though, and not very clear code, but it was fun to do a bit of functional programming again. ;-)

I saw that. Do you think it might be extendible enough to replace std.stdio.writef?


T

-- 
Do not reason with the unreasonable; you lose by definition.

On Thu, 30 Oct 2014 09:46:48 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> > i recently wrote a very simple static 'writef', which genertes mixin with calls to posix `write()` and i really like it. nothing serious, though, and not very clear code, but it was fun to do a bit of functional programming again. ;-)
> I saw that. Do you think it might be extendible enough to replace std.stdio.writef?
hm... with some work i'm pretty sure it will do. i added only the things i need, but it is generic enough to process anything you want. it can be simplified a little, but the basic mechanics are ok, i think. it is basically state machine which parses all necessary modifier arguments and then just going to "write-argument" state. i even passing the modifier there, so "write-argument" can do any magic you want.

sure, it needs alot of work to fully replace current writef, but it's mostly writing missing formatters. i even think that with some little change user will be able to supply his own formating templates, so it can be extended almost like `format()`. i.e. user will be able to define states like "write-spec-x", "write-spec-d" and so on. and with another little change it can be made to use user-specified state to generate mixin code for writing arguments, so it can call any function user wants in the end. this is the beauty of state machine approach. ;-)

On Thu, 30 Oct 2014 09:46:48 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> I saw that. Do you think it might be extendible enough to replace std.stdio.writef?
p.s. i'm actually planning to add the things like "%?s", where "?"
means "take width from the writef!() argument". i.e. this will be
possible: `writef!"%?s"(8, "abc")`, and it will work like
`writef!"%8s"("abc");`. that's why i'm using that ugly `wrWriteWidth()`
function to do formatted write.

it also can analyze argument types to avoid "to!string" conversions and use it's own nuber printing function which not allocates, for example.

the only thing that stops me from extending it now is that GDC is not able to compile it. being 2.065 GDC is not allowing to pass structures as template arguments.

On Thu, Oct 30, 2014 at 10:03:32PM +0200, ketmar via Digitalmars-d wrote:
> On Thu, 30 Oct 2014 09:46:48 -0700
> "H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
> 
> > I saw that. Do you think it might be extendible enough to replace std.stdio.writef?
>
> p.s. i'm actually planning to add the things like "%?s", where "?"
> means "take width from the writef!() argument". i.e. this will be
> possible: `writef!"%?s"(8, "abc")`, and it will work like
> `writef!"%8s"("abc");`. that's why i'm using that ugly
> `wrWriteWidth()` function to do formatted write.

std.format already supports passing the width argument as a parameter. In fact, both the precision and the width can be used:

	size_t prec = 3, width = 5;
	writefln("%*f", width, 1.0); // same as "%5f"
	writefln("%.*f", prec, 1.0); // same as "%.3f"
	writefln("%*.*f", prec, width, 1.0); // same as "%5.3f"


> it also can analyze argument types to avoid "to!string" conversions and use it's own nuber printing function which not allocates, for example.
[...]

Actually, to!string doesn't always allocate, for example, if the target
type supports the toString(scope void delegate(const(char)[])) overload.
There are a few places where it still allocates, but I'm hoping one of
these days to track them all down and eliminate them (where possible).

One of my goals for the CT format string project is to modularize format string processing, so that it actually will not reference any conversion code that it doesn't actually use. So if you only use format strings that don't need allocation, the resulting function should be inferrable as @nogc. Ditto for pure, nothrow, etc.. Obviously this is impossible for runtime format strings, since you don't know what formatting the format string might ask for at runtime, but with compile-time known format strings, you can easily omit all the unnecessary cases that you know will never actually get called.


T

-- 
Just because you can, doesn't mean you should.

On Thu, 30 Oct 2014 13:12:43 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:

> On Thu, Oct 30, 2014 at 10:03:32PM +0200, ketmar via Digitalmars-d wrote:
> > On Thu, 30 Oct 2014 09:46:48 -0700
> > "H. S. Teoh via Digitalmars-d" <digitalmars-d@puremagic.com> wrote:
> > 
> > > I saw that. Do you think it might be extendible enough to replace std.stdio.writef?
> >
> > p.s. i'm actually planning to add the things like "%?s", where "?"
> > means "take width from the writef!() argument". i.e. this will be
> > possible: `writef!"%?s"(8, "abc")`, and it will work like
> > `writef!"%8s"("abc");`. that's why i'm using that ugly
> > `wrWriteWidth()` function to do formatted write.
> 
> std.format already supports passing the width argument as a parameter. In fact, both the precision and the width can be used:
yes, i know. but my library is not supporting that yet. and i
already used "%*" as "print all unprocessed arguments", so i'm planning
to utilize '?' instead of '*' (which, i believe, has it's roots in C
pointer notation).

> Actually, to!string doesn't always allocate, for example, if the target
> type supports the toString(scope void delegate(const(char)[])) overload.
yes, i know that. it was just an example. ;-)

> One of my goals for the CT format string project is to modularize format string processing, so that it actually will not reference any conversion code that it doesn't actually use. So if you only use format strings that don't need allocation, the resulting function should be inferrable as @nogc. Ditto for pure, nothrow, etc.. Obviously this is impossible for runtime format strings, since you don't know what formatting the format string might ask for at runtime, but with compile-time known format strings, you can easily omit all the unnecessary cases that you know will never actually get called.
yes, this will be very valuable. impossibility of using writef in @nogc functions was my motivation to create my version too. i'm not there yet, but it's slowly moving on. but i'm planning to change/extend formatting syntax too (what i have now is just a draft), that's why i don't even trying to write 'iv.writer' as possible part of Phobos. i'm fully understand that breaking formatting syntax is no-no for "std.".