Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/6/2018 8:14 PM, Nicholas Wilson wrote: Yes, but only for a single instance of the namespace. In the general case no, see the first reply in https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org The idea is to not have a namespace, I don't see what making an alias to a namespace has to do with it.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Tuesday, 7 August 2018 at 02:25:32 UTC, Walter Bright wrote: Let's see if we can find some common ground. The boilerplate I suggested seems to enable DPP to generate working code that behaves "as if" the namespace scope is not there, even for nested namespaces. Is this correct? Yes, but only for a single instance of the namespace. In the general case no, see the first reply in https://forum.dlang.org/post/xdaedmlbbqtztiqcw...@forum.dlang.org
Re: Is there any good reason why C++ namespaces are "closed" in D?
Let's see if we can find some common ground. The boilerplate I suggested seems to enable DPP to generate working code that behaves "as if" the namespace scope is not there, even for nested namespaces. Is this correct?
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/5/2018 9:53 PM, Manu wrote: If we produce a DIP to fix this, will you reject it in principle? Producing a DIP is a good idea, it provides an anchor point for any future discussion of the topic, rather than the tangle and noise that is this thread. It is an ample opportunity to put the best foot forward on your ideas. I'm not going to categorically say we'll reject it, but will say that you'll need to make a more compelling case, and a DIP is the right method for that. Please keep in mind that a good DIP will address the counterarguments and other methods of solving the issue. As this thread affirms, trying to design things in the forums doesn't work very well, and I should have asked for a DIP in the first place.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/6/2018 3:19 PM, tide wrote: That's just a deflection, 1. I'm only here to help, and am not interested in scoring debate points. 2. To bring up other topics, please start a new thread. Especially since this one is quite voluminous.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 20:35:37 UTC, Walter Bright wrote: On 8/6/2018 11:26 AM, tide wrote: What's your crossplatform workaround if I have a namespace named "version" or "package" ? See my reply to Rick Cattermole. https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_317277.html#N317507 But that's not currently implemented is it? Your proposed solution adds an exception to the rule that just increases complexity of the language. No where else does "__" remove itself from the name it is used with. With the syntax extern(C++, "...") it is more easily understood, no crazy exceptions need to be made. You also didn't mention your reasoning behind not including a way to use const pointers to mutable data. That's a longstanding issue and has nothing to do with namespaces. That's just a deflection, we are talking about C++ name mangling, not namespaces. How do you mangle const pointers to mutable data in D to be able to call C++ ? You don't need to implement the feature, you just need a way to create the C++ mangle, which there is none. The only way is to change C++ code, like you said, telling people to rewrite their code is never, ever going to work.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On 8/6/2018 11:26 AM, tide wrote: What's your crossplatform workaround if I have a namespace named "version" or "package" ? See my reply to Rick Cattermole. https://digitalmars.com/d/archives/digitalmars/D/Is_there_any_good_reason_why_C_namespaces_are_closed_in_D_317277.html#N317507 You also didn't mention your reasoning behind not including a way to use const pointers to mutable data. That's a longstanding issue and has nothing to do with namespaces. How can you suggest DPP then go on to say you've never even used it or know how it is even used? Because I have full confidence in Atila and Laeeth. I've also written such a translator myself (HTOD) so I know what they're capable of.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 3 August 2018 at 21:20:37 UTC, Walter Bright wrote:
Yes. But then you'll have the people who want a 1:1
correspondence with their C++ files and the corresponding D
files. I happen to be one of those people, for the ease of
maintaining a translation (and for comparing it with the
original C++ source code if it is not behaving correctly).
This would still be true if current behavior was kept and
extern(C++, "ns") or extern(C++, ns, noscope) or something was
added though no?
Though I do think the string is superior though because then this
would actually compile:
extern(C++, "shared") {
void f();
}
It feels the two preferences being mutually exclusive has somehow
occupied a lot of this discussion when they are not.
Cheers,
- Ali
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Sunday, 5 August 2018 at 23:28:06 UTC, Walter Bright wrote:
On 8/4/2018 12:45 AM, Manu wrote:
[...]
I get it, Manu, you don't find my arguments compelling. You've
put these forth before, and I could repeat myself rebutting
each. I expect we're at a dead end with that.
But the fact remains, I've shown both you and Atila how to make
things work for you, in a hygienic manner, with the language as
it is now. For you, it's adding an alias declaration. For
Atila, it's a couple lines of boilerplate dpp can add, without
disrupting dpp's internal design.
What's your crossplatform workaround if I have a namespace named
"version" or "package" ?
extern(C++, version) // error
{
void foo();
}
extern(C++, package) // error
{
void bar();
}
You also didn't mention your reasoning behind not including a way
to use const pointers to mutable data. The only workaround that
exists currently is to rewrite C++ code, which you stated wasn't
a valid solution you considered for extern(C++).
I understand you don't want to type in the alias declaration.
May I suggest using Atila's dpp? Then you won't have to even
look at the output. I also expect that your use cases can help
make dpp better, and that would be good for all of us.
---
P.S. I have no experience with dpp and how it is used. But my
experience with translators is that nobody expects to nor wants
to look at its output. They just want it to work. And it seems
a fact of life that the output of machine translation resists
being purty, because what's purty in A never looks purty in B.
How can you suggest DPP then go on to say you've never even used
it or know how it is even used?
Re: DMD installation prompts "Windows protected your PC"
On Monday, 6 August 2018 at 14:13:02 UTC, Timoses wrote: Thanks Windows, not! Since our department switched to Windows 10 I'm now unable to install DMD. To make it even worse, there's no way I see to install a virtual machine any more (VirtualBox or VMWare) since they collide with Hyper-V. I've disabled Hyper-V, but it seems there can be a lot of things using it around one's back anyway. So... No more D programming for me it seems. Very sad. Of course there might be ways around it such as including the IT department. However, I use D for such niche use cases that I believe its unlikely to succeed. Any bright minds have better ideas? You can upload the files that get installed somewhere, I don't think the installer does anything other than setup the sc.ini file which seems to have become rather basic.
Re: DMD installation prompts "Windows protected your PC"
On Mon, 06 Aug 2018 14:13:02 +, Timoses wrote: > Thanks Windows, not! > > Since our department switched to Windows 10 I'm now unable to install > DMD. > > To make it even worse, there's no way I see to install a virtual machine > any more (VirtualBox or VMWare) since they collide with Hyper-V. I've > disabled Hyper-V, but it seems there can be a lot of things using it > around one's back anyway. By "disable Hyper-V", do you mean uninstall via Add/Remove Windows Features? I've never had a problem with VirtualBox after that. Have you tried the DMD zip instead of installer? --Ryan
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 4 August 2018 at 12:18:21 UTC, tide wrote: On Saturday, 4 August 2018 at 01:45:44 UTC, Laeeth Isharc wrote: On Friday, 3 August 2018 at 22:55:51 UTC, Rubn wrote: The difference is they would have to rework their existing code. If you are writing D source code bindings for your code, then you are essentially writing new code. You don't have to worry about backwards compatibility. Why would you write bindings if the computer can do it for you, better, faster and consistently? With the current tools the ones that generate D files to be used aren't very good. They evaluate Macros based on the current implementation, so if there's a define MACHINE_X86 or MACHINE_x64, those macro and #if's will be evaluated based on the current system running the tool instead of generating equivalent version() statements. If the D files are to be checked in, then yes, that'd be a problem. If they're not, as is the case with dpp, then... that's actually what you want. dpp: I fought the preprocessor and the preprocessor won. It would be, but I don't think it'll ever be 100% and will require manual intervention. If manual intervention is required, dpp has failed. Some problems will be tricky, especially where the preprocessor is concerned. But a lot of real-life production code works.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Saturday, 4 August 2018 at 07:34:49 UTC, Manu wrote: On Fri, 3 Aug 2018 at 18:50, Laeeth Isharc via Digitalmars-d wrote: [...] Faster and consistently, sure. But I don't think 'better' is possible. [...] Bindings != wrappers. I agree that wrappers will nearly always need to be written, I'm trying to automate the writing of the declarations needed to link. It should be possible to automate translating everything, but some things will be tricky in C++. std::vector is quite clearly a value type, yet the GNU implementation declares it as a class with protected inheritance from _Vector_base. That's going to be fun...
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Friday, 3 August 2018 at 21:49:53 UTC, Walter Bright wrote:
On 8/3/2018 3:58 AM, Atila Neves wrote:
I would only be able to alias a nested namespace once, since
the code below obviously won't work:
mixin CppNamespace0!() x;
alias chrono = x.std.chrono;
mixin CppNamespace1!() y;
alias chrono = y.std.chrono;
Try this:
mixin template X() { // boilerplate prefix
extern (C++, std) extern(C++, chrono) int foo(); //
original line
} mixin X!() x; alias foo = x.std.chrono.foo; //
boilerplate suffix
That doesn't solve the problem at all. I was toying with being
able to have a nested namespace be an alias in a module. I can't
realias chrono after the first `alias chrono = `, nor can I alias
it to the different `chrono`s in all the different template
mixins.
I considered for a while whether or not this would be truly
bad, and the more I think about it the more convinced I am
that Manu is right and there should be _no_ scoping whatsoever
in D regarding C++ namespaces. We have packages and modules,
we can use those to put the C++ functions we declare in
whatever hierarchy we want.
I am puzzled. With:
namespace std {
namespace chrono {
void foo();
}
}
namespace std {
namespace chrono {
void bar();
}
}
you have stated that it is impractical for your translator to
rewrite this as:
namespace std {
namespace chrono {
void foo();
void bar();
}
}
Ok, I get that. But it is practical to rewrite it as:
module std.chrono;
void foo();
void bar();
?
I don't understand what your question has to do with what you
quoted. What I'm trying to say is that I think `extern(C++,
foo.bar)` should NOT introduce a scope in D in any way, shape, or
form. The D module/import/overload system should have no idea of
what `foo` or `foo.bar` are - they don't exist.
> I mean `std` should never be part of the fully qualified name
of, for
> instance, `core.stdcpp.exception.std.bad_exception`. It
should just
> be `core.stdcpp.exception.bad_exception` instead.
C++ recognizes that, too, which is why it has "using"
declarations. D has the equivalent thing, "alias".
You can do things like:
import std = core.stdcpp.exception;
and then refer to:
std.bad_exception
or:
import exception = core.stdcpp.exception;
exception.bad_exception;
or whatever works best for one's project. Aliasing and import
renaming (which are really just more aliasing) is very capable,
and was designed for just these sorts of issues.
I think we're talking past each other. I know how to alias in D,
and how to use `using` in C++. What I'm saying is that, with the
file we have now (core.stdcpp.exception):
extern(C++, std) {
class exception { /* ... */ }
}
Currently the fully qualified name of `exception` is
`core.stdcpp.exception.std.exception`. I'm arguing that this is a
mistake, and the the FQN should instead be
`core.stdcpp.exception.exception`.
Yes, namespaces introduce scope in C++. Yes, lookup rules in C++
are crazy. The main points I'm (and, I think, Manu) arguing are:
1. We already have D packages, modules, and overload rules. We
don't need to import any from C++
2. That namespaces introduce a scope in C++ does not mean that
`extern(C++, ns)` should introduce one in D
i.e. Keep everything about D as-is, _except_ for no scoping for
`extern(C++, ns)`.
Re: DMD installation prompts "Windows protected your PC"
On 07/08/2018 2:53 AM, Timoses wrote: On Monday, 6 August 2018 at 14:19:47 UTC, rikki cattermole wrote: dmd works fine on W10. So the question is, are you seeing AV or are you seeing some other thing that your IT put in place (e.g. require code signing). Well, there is Kaspersky installed and I know there's been a discussion about it here (https://forum.dlang.org/post/wjvfkteddmwhhiktv...@forum.dlang.org). However, it's not Kaspersky that is complaining. At least it doesn't look like it. Perhaps Windows wraps it somehow, idk. Windows prompt: http://oi68.tinypic.com/2eevoxt.jpg All I can do is "Don't run". It has to do with the Windows Defender settings, which I can't change. As of Win8, it definitely is code signing. https://answers.microsoft.com/en-us/windows/forum/windows_other-windows_install/windows-defender-smartscreen-prevented-an/0e5bf2b8-932f-4df0-a984-a70b2fd0cc7a
Re: DMD installation prompts "Windows protected your PC"
On Monday, 6 August 2018 at 14:19:47 UTC, rikki cattermole wrote: dmd works fine on W10. So the question is, are you seeing AV or are you seeing some other thing that your IT put in place (e.g. require code signing). Well, there is Kaspersky installed and I know there's been a discussion about it here (https://forum.dlang.org/post/wjvfkteddmwhhiktv...@forum.dlang.org). However, it's not Kaspersky that is complaining. At least it doesn't look like it. Perhaps Windows wraps it somehow, idk. Windows prompt: http://oi68.tinypic.com/2eevoxt.jpg All I can do is "Don't run". It has to do with the Windows Defender settings, which I can't change.
Re: DMD installation prompts "Windows protected your PC"
On Monday, 6 August 2018 at 14:19:47 UTC, rikki cattermole wrote: (e.g. require code signing). Why don't we just sign the code anyway? This shouldn't be a big deal and it has been a problem for many people for many years.
Re: DMD installation prompts "Windows protected your PC"
On 07/08/2018 2:13 AM, Timoses wrote: Thanks Windows, not! Since our department switched to Windows 10 I'm now unable to install DMD. To make it even worse, there's no way I see to install a virtual machine any more (VirtualBox or VMWare) since they collide with Hyper-V. I've disabled Hyper-V, but it seems there can be a lot of things using it around one's back anyway. So... No more D programming for me it seems. Very sad. Of course there might be ways around it such as including the IT department. However, I use D for such niche use cases that I believe its unlikely to succeed. Any bright minds have better ideas? dmd works fine on W10. So the question is, are you seeing AV or are you seeing some other thing that your IT put in place (e.g. require code signing).
DMD installation prompts "Windows protected your PC"
Thanks Windows, not! Since our department switched to Windows 10 I'm now unable to install DMD. To make it even worse, there's no way I see to install a virtual machine any more (VirtualBox or VMWare) since they collide with Hyper-V. I've disabled Hyper-V, but it seems there can be a lot of things using it around one's back anyway. So... No more D programming for me it seems. Very sad. Of course there might be ways around it such as including the IT department. However, I use D for such niche use cases that I believe its unlikely to succeed. Any bright minds have better ideas?
More fun with autodecoding
I wanted to share a story where I actually tried to add a new type with
autodecoding and failed.
I want to create a wrapper type that forwards an underlying range type
but adds one feature -- tracking in the original range where you were.
This is in a new library I'm writing for parsing.
So my first idea was I will just forward all methods from a given range
manually -- I need to override certain ones which affect the offset into
the original range.
However, typically parsing is done from text.
I realized, strings are a range of dchar, but I need the length and
other things forwarded so they can be drop-in replacements for strings
(I treat strings wstrings as character buffers in iopipe). However,
phobos will then assume length() as the number of dchar elements, and
assume it has indexing, etc.! Here is a case where I can't repeat the
mistakes of phobos of auto-decoding for my own type! I never thought I'd
have that problem...
So I thought, maybe I'll just alias this the underlying range and only
override the parts that are needed. I end up with a nice tiny
definition, and things are looking pretty good:
static struct Result
{
private size_t pos;
B _buffer;
alias _buffer this;
// implement the slice operations
size_t[2] opSlice(size_t dim)(int start, int end) if (dim == 0)
in
{ assert(start >= 0 && end <= _buffer.length); }
do
{
return [start, end];
}
Result opIndex(size_t[2] dims)
{
return Result(pos + dims[0], _buffer[dims[0] .. dims[1]]);
}
void popFront()
{
import std.traits : isNarrowString;
static if(isNarrowString!B)
{
auto prevLen = _buffer.length;
_buffer.popFront;
pos += prevLen - _buffer.length;
}
else
{
_buffer.popFront;
++pos;
}
}
// the specialized buffer reference accessor.
@property auto bufRef()
{
return BufRef(pos, _buffer.length);
}
}
Note already the sucky part in popFront.
But then I got a surprise when I went to use it:
import std.algorithm : splitter;
auto buf = "hi there this is a sentence";
auto split1 = buf.bwin.splitter; // specialized split range
auto split2 = buf.splitter; // normal split range
while(!split1.empty)
{
assert(split1.front == split2.front);
assert(split1.front.bufRef.concrete(buf) == split2.front); //
FAILS!
split1.popFront;
split2.popfront;
}
What happened? It turns out, the splitter looks for length and indexing
*OR* that it is a narrow string. Splitter is trying to ignore the fact
that Phobos forces autodecoding on char arrays to achieve performance.
With this taken into account, I think my type does not pass any of the
constraints for any of the overloads (not 100% sure on that), so it
devolves to just using the alias this'd element directly, completely
circumventing the point of my wrapper. The error I get is "no member
`bufRef` for type `string`".
My next attempt will be to use byCodeUnit when I detect a narrow string,
which hopefully will work OK. But I'm not sure if the performance is
going to be the same, since now it will likely FORCE autodecoding on the
algorithms that have specialized versions to AVOID autodecoding (I think).
I'm very tempted to start writing my own parsing utilities and avoid
using Phobos algorithms...
-Steve
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 09:48:30 UTC, Danni Coy wrote: Outside perspective here and possibly stupid question. Is there any way we could have our cake and eat it too? One of the thinks I like is that it tends to be much more readable than C++, more code than necessary hurts readability of that code. Can the compiler warn when a function is called that is shadowed by another function in a different namespace. This to me seems like the most sane solution, what am I missing? I haven't read all of the posts in this thread, but my understanding of Walter's argument is that he believes there is only one correct way to work with C++ code. If that's the case, there's no need for warnings, because the language should prevent you from doing it wrong in the first place. The first step will be to convince him that the "mangle only" approach is valid.
Re: Is there any good reason why C++ namespaces are "closed" in D?
On Monday, 6 August 2018 at 04:53:05 UTC, Manu wrote: If we produce a DIP to fix this, will you reject it in principle? I think you and Walter Bright made good points and I think a creation of a DIP that addresses his concerns would be a best course of action IMO. -Alexander
Re: Is there any good reason why C++ namespaces are "closed" in D?
Outside perspective here and possibly stupid question. Is there any way we could have our cake and eat it too? One of the thinks I like is that it tends to be much more readable than C++, more code than necessary hurts readability of that code. Can the compiler warn when a function is called that is shadowed by another function in a different namespace. This to me seems like the most sane solution, what am I missing? On Mon, Aug 6, 2018, 14:53 Manu via Digitalmars-d < digitalmars-d@puremagic.com> wrote: > On Sun, 5 Aug 2018 at 16:30, Walter Bright via Digitalmars-d > wrote: > > > > On 8/4/2018 12:45 AM, Manu wrote: > > > [...] > > I get it, Manu, you don't find my arguments compelling. You've put these > forth > > before, and I could repeat myself rebutting each. I expect we're at a > dead end > > with that. > > So, what you're saying is "I hear you, and I will never change it > because I subjectively prefer it the way it is in spite of every users > experience". > Will you commit to that position officially, so we can refer back to > it in future? > > Just support the string namespace? It won't hurt you, our code will be > better, and you'll make us all that actually link to C++ so much > happier for it. > > If we produce a DIP to fix this, will you reject it in principle? >
