On 4/28/2014 1:31 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> So recompiling with updated libraries may cause failure?

No more than if you violate the ODR in C++, or if you do this entirely in D. Ambiguities for the latter will cause compile time errors (which is a feature, not a bug).

On Monday, 28 April 2014 at 14:00:58 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 28 April 2014 at 13:47:43 UTC, Steven Schveighoffer wrote:
>> Not ok. This is like having 2 definitions for the same function, linker will not accept that.
>
> No. It is like having 2 matching type declarations. The implementation is defined in the C++ source code and is represented as one C++ object/lib file to the linker. The linker will happily accept that.

Linker will yell at you in encrypted klingon, unless the function is weak. Multiple definitions won't work.

Also, if you try to call that function, D will probably yell at you as well as your call is ambiguous, and you'll have to specify the module.

Why is everybody yelling today ? Can't we have some calm around here ?

On 4/28/2014 12:18 AM, Sergei Nosov wrote:
> On Sunday, 27 April 2014 at 19:54:50 UTC, Walter Bright wrote:
>> http://wiki.dlang.org/DIP61
>
> Quote:
>
>> Unlike C++, namespaces in D will be 'closed' meaning that new declarations
>> cannot be inserted into a namespace after the closing }. C++ Argument
>> Dependent Lookup (aka "Koenig Lookup") will not be supported.
>
> Do I understand it correctly, that if I have namespace members defined in
> different files, like
>
> // a.cpp
> namespace ns { int foo(); }
> // b.cpp
> namespace ns { int bar(); }
>
> I have the only option to put those in a single D file, like
>
> // c.d
> extern (C++, ns) { int foo(); int bar(); }
>
> ?

That is incorrect. As far as D is concerned, a.ns and b.ns are separate and distinct declarations, even if C++ members of those scopes may mangle to the same name.


> And the only way it's more flexible than the hypothetical extern(C++) module ns;
> is that you can put several namespaces to a single file?

People who write namespaces in C++ do not pay much attention to what .h files they are in. People writing D imports for such C++ code should not have to re-engineer the layout of the files.

On 4/28/2014 6:55 AM, Byron wrote:
> With the current DIP you have to combine the d/di files to merge the
> extern namespaces.

No, you will not have to, for the same reason that all extern(C) declarations don't have to be in the same module.


> Also is there any plans on dealing with newing c++ memory?

AAAAAIIIIIEEEEEEEE!!!

On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
> Consider this code:
>
> module foo;
>
> void func() {}
>
> module bar;
>
> extern(C) func();
>
> module prog;
>
> import foo;
> import bar;
>
> void main()
> {
>     func(); // error
>     foo.func(); // ok
>     bar.func(); // ok, uses C binding (no name mangling)
> }
>
> In this case, even though the C function is not mangled or in any other
> namespace, the module can be used for unambiguous calling.

Right.


> module foo;
>
> void func() {}
>
> module bar;
>
> extern(C++, foo) void func(); // foo::func in C++ land
>
> module prog;
>
> import foo;
> import bar;
>
> void main()
> {
>     func(); // error
>     foo.func(); // ALSO error

No, not an error. Why would it be?

>     bar.func(); // Not error, BUT it's actually calling foo::func from C++ land!

That's right. Note that foo::func() is not the same as bar.foo.func().

> }

On 2014-04-28 20:50, Walter Bright via Digitalmars-d wrote:
> On 4/28/2014 7:27 AM, Steven Schveighoffer wrote:
>> Consider this code:
>>
>> module foo;
>>
>> void func() {}
>>
>> module bar;
>>
>> extern(C) func();
>>
>> module prog;
>>
>> import foo;
>> import bar;
>>
>> void main()
>> {
>>     func(); // error
>>     foo.func(); // ok
>>     bar.func(); // ok, uses C binding (no name mangling)
>> }
>>
>> In this case, even though the C function is not mangled or in any other
>> namespace, the module can be used for unambiguous calling.
>
> Right.
>
>
>> module foo;
>>
>> void func() {}
>>
>> module bar;
>>
>> extern(C++, foo) void func(); // foo::func in C++ land
>>
>> module prog;
>>
>> import foo;
>> import bar;
>>
>> void main()
>> {
>>     func(); // error
>>     foo.func(); // ALSO error
>
> No, not an error. Why would it be?

I believe Steven expects things to work this way:

module bar;

extern(C++, foo) void func();


module prog;

import bar;

void main()
{
   foo.func(); // Calls bar.func (or is that bar.foo.func?)
}

--
  Simen

On 4/28/2014 2:00 PM, Simen Kjærås via Digitalmars-d wrote:
> I believe Steven expects things to work this way:
>
> module bar;
>
> extern(C++, foo) void func();
>
>
> module prog;
>
> import bar;
>
> void main()
> {
>     foo.func(); // Calls bar.func (or is that bar.foo.func?)
> }

It would call bar.foo.func(). But your example is different from Steven's.

On Monday, 28 April 2014 at 19:32:10 UTC, Walter Bright wrote:
> On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> No. Even though they are the same function as far as the signatures are concerned, they are different functions as far as the D type system is concerned, and hence the call is ambiguous. You'll have to qualify by framework1.std.something() or framework2.std.something().

So you have to choose between framework1 and 2's version if std::string when building your own class, an then cast back and forth between the different framework bindings even though the actual type is the same? Isn't that tedious?

>> import.std();
>> … std.something(); // namespace encapsulation broken or fail?
>> … std.coolstuff();
>
> No problem, std.d overrides because it is imported directly and so std is in the current scope. The current scope overrides imported scopes.

But I think that it is a problem that std.something is silently rebound to a different function.

> Still no problem. Qualifying it with framework2 says which one you want.

The problem is that you are forced to qualify the D-binding rather than the path of the cpp function. This will only work out ok if different framework authors cooperate.

>> Right, but I want to be sure that the type-system sees all externs with the same
>> signature as the same type.
>
> Remember, a C++ signature is the same as its type in C++, but that is not true of D.

And that makes it tedious to interact with C++?
But for what gain?

On 4/28/2014 4:30 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Monday, 28 April 2014 at 19:32:10 UTC, Walter Bright wrote:
>> On 4/28/2014 4:29 AM, "Ola Fosheim Grøstad"
>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> No. Even though they are the same function as far as the signatures are
>> concerned, they are different functions as far as the D type system is
>> concerned, and hence the call is ambiguous. You'll have to qualify by
>> framework1.std.something() or framework2.std.something().
>
> So you have to choose between framework1 and 2's version if std::string when
> building your own class, an then cast back and forth between the different
> framework bindings even though the actual type is the same? Isn't that tedious?

First off, I expect "std" to be put in core.stdcpp.std, and then imported. So this issue would only happen if 3rd party A and 4th party B each imported 5th party C. Yeah, it'll happen, and it'll still work, as the import system regards the same file as being the same import regardless of the import path used to get to it.

The SAME issue exists with D imports. DIP61 does not change this.


> But I think that it is a problem that std.something is silently rebound to a
> different function.

It's no different than if you have:

   A::foo()

in one framework, and a different:

   A::foo()

in another framework. It won't work in C++, either.


> The problem is that you are forced to qualify the D-binding rather than the path
> of the cpp function. This will only work out ok if different framework authors
> cooperate.

Not correct. This is not a problem.


>> Remember, a C++ signature is the same as its type in C++, but that is not true
>> of D.
>
> And that makes it tedious to interact with C++?

I don't see how it makes it any more tedious than dealing with the ODR rule in C++ anyway.

On Monday, 28 April 2014 at 23:57:36 UTC, Walter Bright wrote:
> First off, I expect "std" to be put in core.stdcpp.std, and then imported. So this issue would only happen if 3rd party A and 4th party B each imported 5th party C. Yeah, it'll happen, and it'll still work, as the import system regards the same file as being the same import regardless of the import path used to get to it.

No, it'll happen if they use the same vector library an #include the same "vector3D" and independently specify their own binding? But if they cooperate and use the same binding, then you are ok? That makes no sense.

> It's no different than if you have:
>
>    A::foo()
>
> in one framework, and a different:
>
>    A::foo()
>
> in another framework. It won't work in C++, either.

That is only true if you mangle D modules and C++ namespaces the same way. You should be able to have A.foo and A::foo. It makes no sense to conflate the paths if they mangle differently.

>> The problem is that you are forced to qualify the D-binding rather than the path
>> of the cpp function. This will only work out ok if different framework authors
>> cooperate.
>
> Not correct. This is not a problem.

I can mix two independent cpp bindings without casting?

>>> Remember, a C++ signature is the same as its type in C++, but that is not true
>>> of D.
>>
>> And that makes it tedious to interact with C++?
>
> I don't see how it makes it any more tedious than dealing with the ODR rule in C++ anyway.

Why not? It only applies to the translation unit. I see no relationship.