On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:
> Can we also get a build tool that produces all combinations for libraries distributed in binary form?

distributing binary libraries for barebone? that sounds unusual.

Am 13.02.2014 20:51, schrieb Dicebot:
> On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:
>> Can we also get a build tool that produces all combinations for
>> libraries distributed in binary form?
>
> distributing binary libraries for barebone? that sounds unusual.

Why so?

On Thursday, 13 February 2014 at 20:12:36 UTC, Paulo Pinto wrote:
>> distributing binary libraries for barebone? that sounds unusual.
>
> Why so?

untypical hardware + desire to get most of it makes hard to provide binary distributions that can be simply linked to. Only platform SDK's come to my mind but those don't need to support all possible options - instead they define only "right" ones to use. Well, at least that was small observation of C barebone world I have managed to tackle.

On Thursday, 13 February 2014 at 20:34:50 UTC, Dicebot wrote:
> On Thursday, 13 February 2014 at 20:12:36 UTC, Paulo Pinto wrote:
>>> distributing binary libraries for barebone? that sounds unusual.
>>
>> Why so?
>
> untypical hardware + desire to get most of it makes hard to provide binary distributions that can be simply linked to. Only platform SDK's come to my mind but those don't need to support all possible options - instead they define only "right" ones to use. Well, at least that was small observation of C barebone world I have managed to tackle.

SDKs and BSPs are the norm in my industry, but some libraries are out there (http://www.segger.com/pricing.html)... and they are expensive.  But I think they are usually source releases.

Manu <turkeyman@gmail.com> writes:

> I don't actually think this is what the 'no GC' crowd want. C++ programmers will not be satisfied with this. They'll see it as a step backwards towards C, not forwards.

I have to agree with this.  I was attracted to D by the better C++ possibilities.  I still want that.  And I would like to see the gc be as performant as possible, and be relatively easy to avoid in bottlenecks.

I don't work on real time systems, but throughput and not hammering the memory bus matters a lot.

Jerry

On Thursday, 13 February 2014 at 19:47:33 UTC, Paulo Pinto wrote:
> Am 13.02.2014 19:06, schrieb inout:
>> On Tuesday, 11 February 2014 at 19:43:00 UTC, Walter Bright wrote:
>>> I've toyed with this idea for a while, and wondered what the interest
>>> there is in something like this.
>>>
>>> The idea is to be able to use a subset of D that does not require any
>>> of druntime or phobos - it can be linked merely with the C standard
>>> library. To that end, there'd be a compiler switch (-betterC) which
>>> would enforce the subset.
>>>
>>> (First off, I hate the name "better C", any suggestions?)
>>>
>>> The subset would disallow use of any features that rely on:
>>>
>>> 1. moduleinfo
>>> 2. exception handling
>>> 3. gc
>>> 4. Object
>>>
>>> I've used such a subset before when bringing D up on a new platform,
>>> as the new platform didn't have a working phobos.
>>>
>>> What do you think?
>>
>> -no-moduleinfo
>> -no-exceptions
>> -no-gc
>> -no-object
>>
>> There is absolutely NO need to give any name to that beast.
>> Otherwise, it's an excellent idea!
>> You could still use classes e.g. with C++ linkage.
>
> Can we also get a build tool that produces all combinations for libraries distributed in binary form?
>
> --
> Paulo

These could be linker flags. If you distribute your library as a
.lib, all of those could be present (and only stripped at
link-time).

On 2/13/14, 11:21, Steven Schveighoffer wrote:
> On Wed, 12 Feb 2014 11:30:30 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 2/12/14, 7:40 AM, Sean Kelly wrote:
>>> This would certainly be a useful feature to have when porting, and
>>> Walter clearly uses it himself.  Assuming this can be done with minimal
>>> work, I'd say make it a DMD thing rather than a D thing in general.
>>> Like -profile.  And add a switch to enable it in the front-end if
>>> possible.  Then DMD (and potentially the other compilers) will have the
>>> feature in case anyone finds it useful and we can move on.  Call it
>>> -minimal.
>>>
>>> I have a feeling we've already spent more time talking about this than
>>> Walter would have spent implementing it anyway, so it's already taking
>>> time away from other things.  Let's just give it a nod and move on.
>>
>> I convinced Walter of my view on this, so he won't work on it. I trust
>> that at least between the two of us we can focus on working on what
>> matters most first.
>
> Anyone else wish to take this up? I think pull requests would be welcome.
>
> -Steve

I'm putting a $50 dollar bounty on it.  Gotta work out the details, but there it is.  It's on the announcements forum.

Anyone wanna chip in?  I really want something like this to be implemented.

On Thursday, 13 February 2014 at 19:09:21 UTC, Adam D. Ruppe wrote:
> On Thursday, 13 February 2014 at 18:38:20 UTC, Kagamin wrote:
>> I use bounds checks, and they call _d_array_bounds, which takes ModuleInfo as a parameter. How it would work?
>
> I think it is a mistake for it to take ModuleInfo at all. Those arguments should be removed entirely.

_d_array_bounds must report the location of error, so it should take ModuleInfo and line number to report, where it happened.

On Friday, 14 February 2014 at 17:21:09 UTC, Kagamin wrote:
> _d_array_bounds must report the location of error, so it should take ModuleInfo and line number to report, where it happened.

It could simply take a string. That's all druntime does anyway: fetch m.name from moduleinfo then proceed normally.

On Friday, 14 February 2014 at 17:37:20 UTC, Adam D. Ruppe wrote:
> On Friday, 14 February 2014 at 17:21:09 UTC, Kagamin wrote:
>> _d_array_bounds must report the location of error, so it should take ModuleInfo and line number to report, where it happened.
>
> It could simply take a string. That's all druntime does anyway: fetch m.name from moduleinfo then proceed normally.

With single pointer the calling code is more minimal. Also it's more conceptual: D is module-oriented and with module name you don't need file name. What's problem with moduleinfo? It's only 8 bytes + module name.