On Tuesday, 14 October 2014 at 16:09:31 UTC, Dan Olson wrote:
> "Chris" <wendlec@tcd.ie> writes:
>>
>> iOS/ARM are very important. What's the latest state of affairs? I know
>> some progress has been made but it has been off my radar for a month
>> or two now.
>
> The iOS project with LDC has been idle during the windsurfing season
> :-).  Days are geting shorter so I plan to  resume work on it.
>
> For a start, it needs to be updated to latest LDC version.  About 10
> phobos unit tests were not passing back in April and most of these were
> due to floating pointing differences between host (x64) and target
> (arm).

That is good to hear indeed. In your estimate: how much longer until D is usable on iOS?

On Tuesday, 14 October 2014 at 20:41:25 UTC, Nick Sabalausky wrote:
> On 09/30/2014 04:48 AM, Szymon Gatner wrote:
>> On Monday, 29 September 2014 at 20:15:06 UTC, bachmeier wrote:
>>> On Monday, 29 September 2014 at 10:00:27 UTC, Szymon Gatner wrote:
>>>
>>>
>>> Is that all it would take? Do you also need a GC-free standard
>>> library, which seems to be the need of all the others saying "do this
>>> and I'll switch from C++"? Are the tools good enough?
>>
>> Considered how many games (and I don't mean indie anymore, but for
>> example Blizzard's Heartstone) are now created in Unity which uses not
>> only GC but runs in Mono I am very skeptical of anybody claiming GC is a
>> no-go for games.
>
> The whole "Unity3D == Mono" thing is a somewhat inaccurate misconception.
>
> Unity3D's engine (ie, the real workhorse of any Unity3D game) is written in plain old native C++. So not *necessarily* GC (though they might still use one internally, I wouldn't know).
>
> Only the game-specific scripts (and I *think* the Unity3D Editor) actually run on Mono. And even then, the game scripts *are* able to call into C-linkage stuff, which *is* occasionally done to work around performance issues within game scripts.
>
> Also, I imagine Mono's GC is probably quite a bit better than D's currently is.


All good points. Still, my point was that GC does not mean language is automatically excluded from gamedev.

On 9/29/2014 3:00 AM, Szymon Gatner wrote:
> Hi,
>
> recently there is much talk about extending C++ interop in D but it is unclear
> to me what that means. Functions and virtual class methods are already callable.
> What else is planned in the near future? Exceptions? Support for C++ templates?
> (that seems difficult no?).

Currently, D supports C++:

* function calling
* name mangling
* namespaces
* templates
* member functions
* single inheritance
* basic types that exist in C++ but not D (like 'long')

Note that there are no plans to support C++ semantics - the D side will support only D semantic rules. SFINAE, Koenig lookup, etc., have no place in D.

C++ interop will require the user to be flexible on both the C++ and D side, and bluntly will require strong knowledge of D and C++ and how they work under the hood to be successful with it.

Probably the most tricky thing we're working on is interop with C++ exceptions.

Essentially, we're going to see how far we can push interop.

On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:
> Currently, D supports C++:
>
> * function calling
> * name mangling
> * namespaces
> * templates
> * member functions
> * single inheritance
> * basic types that exist in C++ but not D (like 'long')
>
> Note that there are no plans to support C++ semantics - the D side will support only D semantic rules. SFINAE, Koenig lookup, etc., have no place in D.
>
> C++ interop will require the user to be flexible on both the C++ and D side, and bluntly will require strong knowledge of D and C++ and how they work under the hood to be successful with it.
>
> Probably the most tricky thing we're working on is interop with C++ exceptions.
>
> Essentially, we're going to see how far we can push interop.

To clarify, templates have to be instantiated on the C++ side before being passed to D, right? Is it correct that D can't instantiate a C++ template?

On 10/14/14, 3:53 PM, Meta wrote:
> On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:
>> Currently, D supports C++:
>>
>> * function calling
>> * name mangling
>> * namespaces
>> * templates
>> * member functions
>> * single inheritance
>> * basic types that exist in C++ but not D (like 'long')
>>
>> Note that there are no plans to support C++ semantics - the D side
>> will support only D semantic rules. SFINAE, Koenig lookup, etc., have
>> no place in D.
>>
>> C++ interop will require the user to be flexible on both the C++ and D
>> side, and bluntly will require strong knowledge of D and C++ and how
>> they work under the hood to be successful with it.
>>
>> Probably the most tricky thing we're working on is interop with C++
>> exceptions.
>>
>> Essentially, we're going to see how far we can push interop.
>
> To clarify, templates have to be instantiated on the C++ side before
> being passed to D, right? Is it correct that D can't instantiate a C++
> template?

Correct. Here's the syntax on the C++ side: http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:
> On 9/29/2014 3:00 AM, Szymon Gatner wrote:
>> Hi,
>>
>> recently there is much talk about extending C++ interop in D but it is unclear
>> to me what that means. Functions and virtual class methods are already callable.
>> What else is planned in the near future? Exceptions? Support for C++ templates?
>> (that seems difficult no?).
>
> Currently, D supports C++:
>
> * function calling
> * name mangling
> * namespaces
> * templates
> * member functions
> * single inheritance
> * basic types that exist in C++ but not D (like 'long')
>

I do understand current situation tho I admit I am not aware of the "single inheritance". Does it mean that one can derive in D from a C++ class (don't see it in the docs)?
>
> Essentially, we're going to see how far we can push interop.

I suppose that is the answer I was looking for, time will tell yes? :)

On Tuesday, 14 October 2014 at 23:01:49 UTC, Andrei Alexandrescu wrote:
> On 10/14/14, 3:53 PM, Meta wrote:
>> On Tuesday, 14 October 2014 at 22:27:35 UTC, Walter Bright wrote:
>>> Currently, D supports C++:
>>>
>>> * function calling
>>> * name mangling
>>> * namespaces
>>> * templates
>>> * member functions
>>> * single inheritance
>>> * basic types that exist in C++ but not D (like 'long')
>>>
>>> Note that there are no plans to support C++ semantics - the D side
>>> will support only D semantic rules. SFINAE, Koenig lookup, etc., have
>>> no place in D.
>>>
>>> C++ interop will require the user to be flexible on both the C++ and D
>>> side, and bluntly will require strong knowledge of D and C++ and how
>>> they work under the hood to be successful with it.
>>>
>>> Probably the most tricky thing we're working on is interop with C++
>>> exceptions.
>>>
>>> Essentially, we're going to see how far we can push interop.
>>
>> To clarify, templates have to be instantiated on the C++ side before
>> being passed to D, right? Is it correct that D can't instantiate a C++
>> template?
>
> Correct. Here's the syntax on the C++ side: http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

Understood, makes sense.

On 10/14/2014 5:40 PM, Szymon Gatner wrote:
> I do understand current situation tho I admit I am not aware of the "single
> inheritance". Does it mean that one can derive in D from a C++ class (don't see
> it in the docs)?

It's part of D's COM support.

On 2014-10-15 01:01, Andrei Alexandrescu wrote:

> Correct. Here's the syntax on the C++ side:
> http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei

"extern template class std::vector<MyClass>;

which tells the compiler NOT to instantiate the template in this translation unit."

That sounds like the complete opposite of what's needed.

-- 
/Jacob Carlborg

On Wednesday, 15 October 2014 at 06:18:48 UTC, Jacob Carlborg wrote:
> On 2014-10-15 01:01, Andrei Alexandrescu wrote:
>
>> Correct. Here's the syntax on the C++ side:
>> http://en.wikipedia.org/wiki/C++11#Extern_template -- Andrei
>
> "extern template class std::vector<MyClass>;
>
> which tells the compiler NOT to instantiate the template in this translation unit."
>
> That sounds like the complete opposite of what's needed.


"C++03 has this syntax to oblige the compiler to instantiate a template:

template class std::vector<MyClass>;"