Re: Duration to Decimal Total
On Wednesday, 6 November 2019 at 19:13:46 UTC, Jonathan Levi wrote: I would think a function that this would be appropriate to belong in the module. Am I missing it? Or, how would you recommend calculating it? The author of the module has explained before that this is very intentional: https://forum.dlang.org/post/mailman.3711.1453121204.22025.digitalmars-d-le...@puremagic.com
Duration to Decimal Total
`core.time.Duration` has a `total` function for extracting the value withing the Duration. `total` returns a whole number (`long`). Is there a function that returns a decimal (`double` or `float`)? I cannot find one in `core.time`. How would I do it then? I know I can get finer precision (say msecs) and then divide it to get a courser precision (say secs) but then I might loose some potential accuracy. I could do nsecs but that could be finer than than the actual internal number and therefore cause extra calculation or end up truncating really large numbers. I would think a function that this would be appropriate to belong in the module. Am I missing it? Or, how would you recommend calculating it? tldr: I am looking for a function like `double as(string units)(Duration)`.
Re: How polymorphism work in D?
On Wednesday, 6 November 2019 at 06:27:32 UTC, OiseuKodeur wrote:
On Wednesday, 6 November 2019 at 06:05:25 UTC, rikki cattermole
wrote:
On 06/11/2019 6:43 PM, OiseuKodeur wrote:
I have this
[snip]
Rikki's answer is the direct answer to your question since you
already had the if(..) statements coded in your main function,
but your code does not really exploit the main abstraction
advantage that polymorphism offers.
The typical use of polymorphism in terms of your example would be
where you don't want to mess with the interior details of derived
classes in your main function - you want to code your logic in
your main function just keeping the 'interface' as defined by Foo
in your head. Something like this:
abstract class Foo {
void writeProp();
}
class Bar : Foo
{
float value;
this(float t_value) { value = t_value; }
override void writeProp() {value.writeln;}
}
class Baz : Foo
{
string name;
this(string t_name) { name = t_name; }
override void writeProp() {name.writeln;}
}
void main()
{
Foo foo = new Bar(10);
foo.writeProp;
foo.writeln;
}
The idea is that you can separate Baz and Bar "out of sight" (in
a library for example) and write your main logic i.t.o. only
Foo's.
The advantage will become apparent if you want to add another
class, say Boo : Foo. In your case you would need to add another
else if(..) clause to your main function in addition to adding
the class itself. In the above case you only need to add the
class - you don't need to touch the main function.
Re: Blog Post #74: Cairo IX - Doodle a Noodle
On Friday, 27 September 2019 at 13:44:54 UTC, Ron Tarrant wrote: You can find part one here: https://gtkdcoding.com/2019/09/27/0074-cairo-doodle-a-noodle.html Due to code reorganization, the above link is now: https://gtkdcoding.com/2019/09/27/0074-nodes-i-doodle-a-noodle.html
Re: Blog Post #75: Cairo X - Noodling with the Mouse
On Tuesday, 1 October 2019 at 09:58:42 UTC, Ron Tarrant wrote: Here's the second installment of the Nodes-n-noodles coverage in which we get the mouse involved: https://gtkdcoding.com/2019/10/01/0075-cairo-x-mouse-noodle.html Because of code reorganization, the above link is now: https://gtkdcoding.com/2019/10/01/0075-nodes-ii-mouse-noodle.html
Re: Blog Post #76: Nodes and Noodles, Part II
On Sunday, 6 October 2019 at 23:15:43 UTC, Ron Tarrant wrote: On Sunday, 6 October 2019 at 23:00:51 UTC, Zekereth wrote: Here's the correct URL https://gtkdcoding.com/2019/10/04/0076-app-01-iii-noodles-and-mouse-clicks.html Great tutorial(s)! Thanks! LOL! Thanks, Zekereth. Because of code reorganization, the above link should now be: https://gtkdcoding.com/2019/10/04/0076-nodes-iii-noodles-and-mouse-clicks.html
Re: Dub and gitsubmodules
Thanks for the replies!
Re: A question about postblit constructor
On Wednesday, 6 November 2019 at 09:19:04 UTC, Jonathan M Davis
wrote:
DIP:
https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md
It looks like the release that added copy constructors to the
compiler was 2.086 back in May:
https://dlang.org/changelog/2.086.0.html
https://dlang.org/changelog/2.086.0.html#copy_constructor
I've been playing around with d for less than a year. I didn't
know that copy ctors were included in the language until checking
the docs for postblit ctors (It is a relatively new thing, so I
just missed it). Sorry, I keep picking my words wrongly. By
saying "less confusing" for copy ctors, I meant more readable
code for me (a newbie) in terms of syntax. This piece of code was
confusing for me (from Ali's book: this(this){grades =
grades.dup;}). Postblit ctor has a special scope. With the help
of this thread, I understood postblit ctors. Thank you.
Blog Post #85: Nodes-n-noodles, Part IV - A Node from a DrawingArea
A day late, but here we are... Diving back into the Nodes-n-noodles series, we look at how to build a moveable node from a DrawingArea. You can find it here: https://gtkdcoding.com/2019/11/05/0085-nodes-iv-node-drawing.html
Re: A question about postblit constructor
On Tuesday, November 5, 2019 5:09:15 AM MST Ferhat Kurtulmuş via Digitalmars-d-learn wrote: > On Tuesday, 5 November 2019 at 12:06:44 UTC, Ferhat Kurtulmuş > > wrote: > > On Tuesday, 5 November 2019 at 11:20:47 UTC, Mike Parker wrote: > >> On Tuesday, 5 November 2019 at 10:32:03 UTC, Ferhat Kurtulmuş > >> > >> wrote: > [...] > >> > >> I meant the example as an answer to your statement, "I wonder > >> how new memory is allocated without an explicit malloc here". > >> The postblit was intended as a chance to "fixup" everything > >> when you needed a deep copy. The new struct is initialized as > >> a shallow copy, so when you enter into the postblit, the > >> pointer is already pointing at the original location. Without > >> assigning it a new malloc'ed address, your memcpy was > >> essentially overwriting the original location with its own > >> data. > > > > What I need was a deep copy, and I thought I could have done it > > using postblit constructor. Thanks for clarification. > > I think copy constructor is less confusing though. It's pretty simple really. The compiler takes care of copying everything and then the postblit constructor only has to worry about stuff where a deep copy is needed. It's called a postblit, because it's run after the bit blitting that's used to do a shallow copy. If an object has no postblit constructor and has no member variables with postblit constructors, then all a copy does is blit. When a D object with a postblit constructor is run, you get three steps: 1. A shallow copy of the object is made by bit blitting it. 2. Then the postblit constructors (if any) of the member variables are run. 3. Then the postblit constructor for the object is run. The result is that in your average postblit constructor, you only have to deal with a portion of the member variables, whereas for a copy constructor, you're forced to deal with _every_ member. In principle, postblit constructors are actually a great idea, because they make it so that you only have to worry about the members that actually need deep copies. Where they fall apart is with modifiers like const. Because a postblit constructor does a shallow copy and then you modify it, it requires modification, which just doesn't work with const. So, while postblit constructors were a good idea with D1 (which was a much simpler language), with D2 (which added const as we know it), they've been far more of a problem, which is why there was a DIP not long ago to add copy constructors to D to replace postblit constructors. Because of how long postblit constructors have been around, they may never actually be deprecated, but ideally, newer code would use copy constructors, and over time, postblit constructors wouldn't be used anymore. Fortunately, D2 has fantastic metaprogramming, so it's actually possible to write copy constructors that copy all of the members without having to explicitly copy all of them by name. So, the main benefit of the postblit constructor (not needing to explicitly copy everything) isn't as much of an improvement as it originally was. DIP: https://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1018.md It looks like the release that added copy constructors to the compiler was 2.086 back in May: https://dlang.org/changelog/2.086.0.html https://dlang.org/changelog/2.086.0.html#copy_constructor So, while it's definitely useful for you to understand postblit constructors, any code you're writing now should probably use copy constructors. So, if you have a good understanding of copy constructors and are having trouble with postblit constructors, presumably, that's an improvement for you, though you may still need to deal with postblit constructors in existing code that other people have written. - Jonathan M Davis
