On 3 January 2016 at 14:54, Manu <turkeyman@gmail.com> wrote:

> [...]
>

In addition to that rant, extern(C++) seems to fail at forward referencing. Any time I have 2 modules that refer to eachother, suddenly the order of everything is critical. I can sometimes resolve these problems by moving imports out of the global scope, but often it's terminal, and I need to restructure everything in awkward and unnatural ways to break the stalemate.

I know I'll just get complaints from people to submit bugs; I have submit lots, and in many cases, I've tried to, but they're almost impossible to produce in isolation, only when a project gets 'real', ie, big enough that it's realistic in scope does it all start to break down. It's really hard to reduce a bug that I don't understand, somewhere among a program with 30-ish interconnected modules. It's worse when the structure of the project is unnatural, a requirement forced by the namespace issue, and everything is already really brittle as a result.

The thing is, it almost all comes back to the pseudo-namespaces (sprinkled with weird forward referencing issues). Maybe it sounded good at the time, but it doesn't work in practice. If that was fixed, then we'd stand on solid ground, and it might be possible to reduce bugs and move forward in that environment.

On 1/2/2016 9:19 PM, Manu via Digitalmars-d wrote:
> In addition to that rant, extern(C++) seems to fail at forward referencing. Any
> time I have 2 modules that refer to eachother, suddenly the order of everything
> is critical. I can sometimes resolve these problems by moving imports out of the
> global scope, but often it's terminal, and I need to restructure everything in
> awkward and unnatural ways to break the stalemate.
>
> I know I'll just get complaints from people to submit bugs; I have submit lots,
> and in many cases, I've tried to, but they're almost impossible to produce in
> isolation, only when a project gets 'real', ie, big enough that it's realistic
> in scope does it all start to break down. It's really hard to reduce a bug that
> I don't understand, somewhere among a program with 30-ish interconnected
> modules. It's worse when the structure of the project is unnatural, a
> requirement forced by the namespace issue, and everything is already really
> brittle as a result.
>
> The thing is, it almost all comes back to the pseudo-namespaces (sprinkled with
> weird forward referencing issues). Maybe it sounded good at the time, but it
> doesn't work in practice. If that was fixed, then we'd stand on solid ground,
> and it might be possible to reduce bugs and move forward in that environment.

They're not pseudo-namespaces. C++ namespaces in D are scoped namespaces and follow all the D scoping and name lookup rules. They are mangled, however, like C++ namespace scoped symbols are mangled.

I am not aware of any forward reference issues with C++ namespaces, so without an example, I cannot do anything.

On 3 January 2016 at 15:45, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 1/2/2016 9:19 PM, Manu via Digitalmars-d wrote:
>
>> In addition to that rant, extern(C++) seems to fail at forward
>> referencing. Any
>> time I have 2 modules that refer to eachother, suddenly the order of
>> everything
>> is critical. I can sometimes resolve these problems by moving imports out
>> of the
>> global scope, but often it's terminal, and I need to restructure
>> everything in
>> awkward and unnatural ways to break the stalemate.
>>
>> I know I'll just get complaints from people to submit bugs; I have submit
>> lots,
>> and in many cases, I've tried to, but they're almost impossible to
>> produce in
>> isolation, only when a project gets 'real', ie, big enough that it's
>> realistic
>> in scope does it all start to break down. It's really hard to reduce a
>> bug that
>> I don't understand, somewhere among a program with 30-ish interconnected
>> modules. It's worse when the structure of the project is unnatural, a
>> requirement forced by the namespace issue, and everything is already
>> really
>> brittle as a result.
>>
>> The thing is, it almost all comes back to the pseudo-namespaces
>> (sprinkled with
>> weird forward referencing issues). Maybe it sounded good at the time, but
>> it
>> doesn't work in practice. If that was fixed, then we'd stand on solid
>> ground,
>> and it might be possible to reduce bugs and move forward in that
>> environment.
>>
>
> They're not pseudo-namespaces. C++ namespaces in D are scoped namespaces and follow all the D scoping and name lookup rules. They are mangled, however, like C++ namespace scoped symbols are mangled.
>

I don't want that. That's what modules are for.
extern(C++) should only state where the external C++ function is to be
found. If the user wants the D symbol under a namespace to match C++, let
them do so explicitly. But they probably already are via the module scope.

Given a C++ symbol 'NS::CSymbol', the D symbol 'x.y.NS.CSymbol' bears no meaningful relation. D still prefixes the module scope.

The user will almost certainly instead do:

module NS; // a module for the C++ thing
extern(C++, NS) void func();

Which would give them the symbol 'NS.NS.func'. Surely what they intended was 'NS.func' to match the C++ symbol?


I am not aware of any forward reference issues with C++ namespaces, so
> without an example, I cannot do anything.
>

https://issues.dlang.org/show_bug.cgi?id=15389

Over a month ago, nearer to the start of my descent into madness. I suspect this had lead to some mis-diagnoses of issues.

On 1/2/2016 10:56 PM, Manu via Digitalmars-d wrote:
> I don't want that. That's what modules are for.

C++ namespaces are not modules, either in C++ or D. We investigated making them 'special' modules, and discarded that as unworkable.


> Given a C++ symbol 'NS::CSymbol', the D symbol 'x.y.NS.CSymbol' bears no
> meaningful relation. D still prefixes the module scope.

D will not prefix the module name to the mangled C++ namespace name.

> The user will almost certainly instead do:
>
> module NS; // a module for the C++ thing
> extern(C++, NS) void func();
>
> Which would give them the symbol 'NS.NS.func'.

That's correct, although I would not recommend that practice. Note that you can use alias to 'lift' a scope into the current scope.

> Surely what they intended was 'NS.func' to match the C++ symbol?

Then you'd need a global namespace, which D does not have.


>     I am not aware of any forward reference issues with C++ namespaces, so
>     without an example, I cannot do anything.
> https://issues.dlang.org/show_bug.cgi?id=15389

Thank you.

On 1/3/16 12:19 AM, Manu via Digitalmars-d wrote:
> I know I'll just get complaints from people to submit bugs; I have
> submit lots, and in many cases, I've tried to, but they're almost
> impossible to produce in isolation, only when a project gets 'real', ie,
> big enough that it's realistic in scope does it all start to break down.
> It's really hard to reduce a bug that I don't understand, somewhere
> among a program with 30-ish interconnected modules.

What I do is make a fresh copy of the project tree, and then start pruning (heh) that down. Prune, rebuild, prune, rebuild etc. Whatever makes the error go away put back in (editor "undo" is handy). It takes some getting used to but it's an effective tool for reducing a bug to its essentials. I suspect in your case e.g. no function definition is even necessary - only declarations. -- Andrei

On 4 January 2016 at 02:10, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 1/3/16 12:19 AM, Manu via Digitalmars-d wrote:
>>
>> I know I'll just get complaints from people to submit bugs; I have submit lots, and in many cases, I've tried to, but they're almost impossible to produce in isolation, only when a project gets 'real', ie, big enough that it's realistic in scope does it all start to break down. It's really hard to reduce a bug that I don't understand, somewhere among a program with 30-ish interconnected modules.
>
>
> What I do is make a fresh copy of the project tree, and then start pruning (heh) that down. Prune, rebuild, prune, rebuild etc. Whatever makes the error go away put back in (editor "undo" is handy). It takes some getting used to but it's an effective tool for reducing a bug to its essentials. I suspect in your case e.g. no function definition is even necessary - only declarations. -- Andrei

Yeah, I've used this process before. Last time I reported a raft of
LDC bugs I spent a few days doing this... but it's very laborious, and
I don't have time to do it. I'm doing this work on borrowed time as it
is.
I need to feel productive and like I'm making progress, otherwise it
fails to compete for timeshare with other high priority goals >_<
The thing is, it's wasted effort anyway, because it's almost all a
symptom of a bad design that should be changed for design reasons
alone, regardless of bugs.

Walter has already submit a patch for what I think is the key non-design-related bug causing me problems. I expect that'll lead to a lot less random errors and misdiagnoses when hacking at the main task of working-around the problems caused by broken design. I wonder if there's chance of getting the fix into 2.070? That would be really rocking.

On Monday, 4 January 2016 at 15:02:05 UTC, Manu wrote:
> Yeah, I've used this process before. Last time I reported a raft of
> LDC bugs I spent a few days doing this... but it's very laborious, and
> I don't have time to do it. I'm doing this work on borrowed time as it
> is.

Did you try dustmite? I usually set it up and let it run for a night on larger projects and it managed to reduce the bug every time so far.

> I need to feel productive and like I'm making progress, otherwise it
> fails to compete for timeshare with other high priority goals
> >_<

Thats the problem with D at the moment, if it works its great, but if it doesn't, especially if you are on untested terrain like extern(C++) you loose tons of time.