On Saturday, 26 December 2015 at 17:58:52 UTC, Guillaume Piolat wrote:
> On Tuesday, 1 December 2015 at 06:17:17 UTC, Mike Parker wrote:
>> [...]
>
>
> Got "Learning D" as a present, still reading.
>
> I must say I didn't expect to learn much after the D Cookbook or TDPL.
> Wrong!
>
> The content matches perfectly with the stuff I hadn't understood well enough.
>
> Just like D it has a lot of value in small details, like "this" template parameters, detailing opEquals, details on align, DVM introduction...
> The chapter on Ranges is extremely helpful and should help overcome my "range anxiety". Other chapter are similarly thorough on Voldemort types or slices.
>
> Really appreciate the attention to detail that went into it.

This is a fantastic book - thanks very much to Mike for all the effort and attention he put into the book :) - I have learned a lot from it.

On Saturday, 26 December 2015 at 19:09:22 UTC, Kingsley wrote:
> On Saturday, 26 December 2015 at 17:58:52 UTC, Guillaume Piolat wrote:
>>
>> Really appreciate the attention to detail that went into it.
>
> This is a fantastic book - thanks very much to Mike for all the effort and attention he put into the book :) - I have learned a lot from it.

Thanks guys! That kind of feedback is a good Christmas present :)

On Sunday, 27 December 2015 at 17:21:24 UTC, Mike Parker wrote:
>
> Thanks guys! That kind of feedback is a good Christmas present :)

I'm working through the book now. I'm liking it.

I'm on Chapter 9, which has the Connecting D with C material. At the beginning of the chapter you define some terms: dynamic vs. static linking, dynamic/static libraries, and dynamic/static binding. I think the way you explain these terms assumes that someone already has quite a bit of computing knowledge. I googled the dynamic/static library stuff and there are some simpler explanations online that I can understand. There's less material out there on dynamic/static bindings, the way you're talking about it. I think I get what you're saying about static bindings, but I'm not sure when you would want to use dynamic bindings.

On Tuesday, 12 January 2016 at 20:32:57 UTC, jmh530 wrote:
> I'm not sure when you would want to use dynamic bindings.

When you want to have control over the process of loading a library e.g. if you want it to be an optional dependency at runtime.

On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote:
>
> When you want to have control over the process of loading a library e.g. if you want it to be an optional dependency at runtime.

I've seen the example in the book. I'm just not sure why you would want an optional runtime dependency.

On Tuesday, 12 January 2016 at 22:00:32 UTC, jmh530 wrote:
> On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote:
>>
>> When you want to have control over the process of loading a library e.g. if you want it to be an optional dependency at runtime.
>
> I've seen the example in the book. I'm just not sure why you would want an optional runtime dependency.

Anything in your application / library that relies on resources that may or may not be available on the user's system. E.g. plugins the user wants to load.

On Tuesday, 12 January 2016 at 21:10:28 UTC, John Colvin wrote:
> On Tuesday, 12 January 2016 at 20:32:57 UTC, jmh530 wrote:
>> I'm not sure when you would want to use dynamic bindings.
>
> When you want to have control over the process of loading a library e.g. if you want it to be an optional dependency at runtime.

For me, the big benefit is that it eliminates the link-time dependency on the C library. I don't have to worry about whether the dev package is installed on Linux, or the COFF/OMF issues on Windows. Reducing dependencies like this makes avoids several potential build issues, something particularly good for open source projects. You can download the source for an SDL-based game, for example, and not worry about which version of the SDL development libraries you need to build it.

Another benefit is that the app doesn't need to fail if a particular version of a library is not available. For example, DerelictUtil, the library which provides the loader for all of the Derelict bindings, allows the ability to continue loading if certain functions are missing. You can choose to use those functions if present and fallback on something else if they aren't. If you've ever used OpenGL, you're probably already doing this. You can use version 4.x if it's available and fallback to 3.x if it isn't; extensions are loaded on an as-needed and as-available basis. A dynamic binding allows this sort of behavior with any library.

One of the entries in, IIRC, Game Programming Gems 2, talked about solving the DLL Hell problem with dynamic loading. For me, it really just boils down to more convenient builds. I tend to prefer it over static or dynamic linking. In fact, dynamic linking doesn't even enter the picture for me in D. If I need a shared library, I'll just load it myself.

On Wednesday, 13 January 2016 at 01:02:28 UTC, Mike Parker wrote:
>
> [snip]

Thanks for the reply.