Re: how to make private class member private
On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer wrote: If we could go back in time and talk with a young Walter about the consequences of choosing the scheme the way it is, maybe he might have made different choices, but at this point, it's hard to change it. I think this highlights the real problem with D. Power is too centralised, and kinda arbitrary. I'm going back to Java ;-)
Re: how to make private class member private
On Sunday, 18 March 2018 at 11:12:46 UTC, Alex wrote: ´´´ Are there any scenarios in which the person writing the class, would want to encapsulate their class, or some parts of it, from the rest of a module (while being forced to put the class in this module)? ´´´ The answer is no. As the person which is writing the class has always the power to decide which module to edit to put the class in. And due this fact, the statement The fact is, the creator of the class is also the creator of the module.. is the coolest semantic statement of the whole thread so far, I think :) Well, it seems to me, that the only real objection one can have to improving encapsulation within a module, is objecting to improving encapsulation within a module. The fact that the creator of a class, is also the creator of the module that contains that class, is not a valid reason for not seeking to improve encapsulation of that class.
Re: how to make private class member private
On Sunday, 18 March 2018 at 10:14:30 UTC, Alain Soap wrote: BTW i think adding this can be useful. The FreePascal language has `strict private` for example. " Private - All fields and methods that are in a private block, can only be accessed in the module (i.e. unit) that contains the class definition. They can be accessed from inside the classes’ methods or from outside them (e.g. from other classes’ methods)" " Strict Private - All fields and methods that are in a strict private block, can only be accessed from methods of the class itself. Other classes or descendent classes (even in the same unit) cannot access strict private members. " https://www.freepascal.org/docs-html/ref/refse34.html interesting...someone else clearly had the idea. hey..perhaps I'm not a moron after all.
Re: how to make private class member private
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote: The fact is, the creator of the class is also the creator of the module.. and preventing him from having full access to the class is ignorant. He doesn't need to encapsulate himself. Encapsulation is ONLY meant to reduce dependencies. If the programmer, probably someone like you, can't trust himself to understand his own code then he shouldn't be coding. btw. I am talking here about 'encapsulation' not 'information hiding' (although the two terms are often considered related). Clearly, there is no point in hiding information contained within the module, from the implementer of the module. That's just silly. However, are there no scenarios in which the person writing that module, would not want to encapsulate their class, or some parts of it, from the rest of the module (while not being forced to put the class in it's own file)? If the answer is certainly no, not under any circumstances, then fine, my idea is not worth any further consideration. And by no, I mean no for all, not just you.
Re: how to make private class member private
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote: Why do you insist that you know how everything works and you are the harbinger of truth. The fact is, you don't know squat about what you are talking about and you just want to conform D to your naive ignorant ...etc...etc..etc..etc..etc you're funny. and btw. My suggestion would not stop anyone from doing what they're currently doing within modules. It would just return class encapsulation, within a module, for when it was deemed worthwhile (as opposed to being forced to move the class out of the module). It's just an idea, not a request. One day I might do a data matching analysis of the dmail-archive, to find out who you really are.
Re: how to make private class member private
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote: On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote: maybe extend that to a list of types? this is basically what C++ friend does and D was trying to avoid the complexity of Really, the complexity of 'friend' comes from people abusing it. In D, I would prefer no breaking change here. Leave private as it is. Just a simple attribute that only applies within a class, and only to private members within that class. @strictly private string firstName_; Nothing outside of the class, not even the module, can access this now. It's all encapsulated. It breaks nothing (AFAIK). It's very clear what the intention is here. It's an easy attribute to remember. It restores the principle of class enscapsulation within a module, for when it's really needed. Now D programmers would have the best of both worlds.
Re: how to make private class member private
On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote: I don't like the name @deny . how about: @reallyis private string firstName_; mmm..perhaps not... then how about... @strictly private string firstName_;
Re: how to make private class member private
On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven wrote: It's a language design decision as to whether a particular feature is worth supporting. I would like this feature too though. I'm not sure how much compiler complexity would be added by having another visibility modifier. D could add an new attribute to class members: @deny A @deny attribute can come before a classes private member, to indicate that the private member is to remain private, even within the module. Cause sure, it nice to be among friends, but you don't want your friends knowing every thought that is going through your mind! Sometimes, somethings, just need to remain private. @deny private string _userName; now... _userName is no longer accessible at the module level, and class encapsulation is restored. If had I any clue about compilers, I'd think this through more ;-)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote: You are a moron...etc..etc..etc..etc. See. This is what happens when you have access to a keyboard while high on ice.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. Actually I wonder if it's the opposite of that, because now, if I have a bug in my class implementation, the code is no longer localised to the class, but to the module - this greatly increases the burden of program correctness and maintenance. It also means the author of the class is no longer free to make changes, because all the surrounding code in the module needs to be assessed for impact - this greatly increases the burden of program correctness and maintenance.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 12:10:07 UTC, rikki cattermole wrote: On 14/03/2018 1:02 AM, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote: Ah yes. You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation. A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up. My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together). This makes each file to be very right down to the point and do nothing else. You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either. Fair enough. I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-) The number of lines of code is more of a code smell which suggests that the module is going out of scope in size and functionality. I have to think more, about what a module is really trying to encapsulate. I'm sure there is a good blog that could come out of this conversation. (not by me though) While it is new to some people, we would only be rehashing existing ideas that have existed in the literature for 40+ years. Mmm...I think more than just 'some people' will be suprised when they come to D, and suddenly find that a private member may not be private at all. Particulary those C++/C#/Java programmers - who represent the vast majority of programmers on the planet. private string _Name; (oh..in D, this might be private..or it might not be..depends on what you mean by private)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote: Ah yes. You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation. A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up. My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together). This makes each file to be very right down to the point and do nothing else. You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either. Fair enough. I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-) I have to think more, about what a module is really trying to encapsulate. I'm sure there is a good blog that could come out of this conversation. (not by me though)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. But, a module can contain so many 'friends'. Q. How many 'friends' does it take, before you lose the capacity to reason about who really is a friend?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
System.out.println(c.myPrivateClassMember);
}
private static class myClass
{
private String myPrivateClassMember; // private does
not mean private anymore??
}
}
´´´
(may the forum forgive me :p )
But a class and its inner classes together, can be still be
reasoned about locally.
With 'modules', the boundaries of what 'local' means, becomes
more and more fuzzy, as the module gets longer and longer, and
more and more complex.
In those circumstances, it becomes much harder to reason locally
about the correctness of a class.
And a D module can go on..well...for ever.
I would still prefer that classes within a module, at least have
a capacity to specify access privileges to objects in the same
module, rather than just trusting everything in that module,
without exception.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 09:52:06 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote: That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are) Is there a practical difference between a) a module that contains a class with 20 member functions all accessing private members of the class and b) a module that contains a class with two member functions and 18 free functions all accessing private members of the class? Does it really make a difference that some functions are on one side of a closing brace and some on the other? The scenario you mentioned is fine, as long as I don't want to protect any of my class members from free functions within the module. When I do decide that something in my class really does need protection, I have to move the class outside of the module. This concept is new to me. I have to keep thinking about it. To lose control at the level of class encapsulation, and surrender it completely to the module, no matter what..well..I'm a little unsure about it. I'd be more comfortable with being able to have your scenario and mine 'both work'. At what point, does 'principled' violation of encapsulation, just become a violation of encapsulation?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Any new keywords, or reuse of existing keywords, does make the language more complex. Everything that is added must have a reason. Private is module level because friend is so common in C++, i.e. people find it useful and it would be great to support something similar in D. Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. yeah, I probably agree that it's a good decision, when the module is the boundary. (aka so-called 'principled' violation of encapsulation) what I don't like, is that I have no way at all to protect members of my class, from things in the module, without moving that class out of that module. D wants me to completely trust the module, no matter what. That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". what about a new access attribute (and no, I haven't though this through much): owned string _FirstName; (now the class 'owns' this. It is neither readable nor writeable outside the boundary of that class. This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership. or another idea: ownedBy T string _FirstName; where T could be 'Module' (meaning it works the way it currently does. The module can read/write to it). or T could 'Universe' (where universe means everyone can do whatever they want with it). or T could be 'This'(so class can regain control overs its own members), The default could be ownedBy Module, to retain existing behaviour. I'd even go further, with extended attributes... ownedBy Module Read string _FirstName; ownedBy Module Write string _FirstName; ownedBy Module ReadWrite string _FirstName;
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". what about a new access attribute (and no, I haven't though this through much): owned string _FirstName; (now the class 'owns' this. It is neither readable nor writeable outside the boundary of that class. This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 07:05:48 UTC, rikki cattermole wrote: Your thought model is much younger than modules. Modules have existed since the mid 70's. They work, other designs over the years have proven to have faults and problems. D's design is evolved from already existing ideas to try and give the best of both worlds and modules is no different. The reality is, Java and C++ both are great examples where module system was added after many years too late. D had it built in from the get go and was designed to benefit from it. I don't have any objection to the idea that a module can have privileged access to members of classes within that model. It sounds sensible enough, if the module is a level of encapsulation also. My arguments is that, this was implemented in D, at the cost of removing the capacity for a class in the same module to protect it's own members (within the module). That's what I don't like about it. My other objection, as stated, is that D uses the same syntax as C++/C#/Java, but the semantics of that same syntax are completely different. I also don't like that.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:43:55 UTC, ketmar wrote: that is, we should stick to defective design only 'cause there is no "other D" that made it right? ;-) also, your question is not valid. you were told several times that you're evaluating the whole thing wrong, but you're insisting on your view being right. and you're keep asking, omiting the *critical* piece of the picture: modules. you were told that in D, encapsulation unit is *module*, not class/struct. it is not a "misdesign", it is the proper modular design. it doesn't matter what others are doing in this case. p.s.: yes, i know such language. Delphi/FreePascal. Gee.. I feel like I'm on a Rust forum, being attacked my their sjw moderators. Whatever happened to the 'discussion' component of these 'discussions'?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: The same applies here. Encapsulation simply isn't broken by this feature. What you're saying, is in D, class encapsulation is really 'module' encapsulation. I get it. Fine. It's an intersting design decision. But, in doing that, D has shifted the boundary of class encapsulation, to a boundary that is outside the class. To me, that sounds like D has broken class encapsulation. I don't know how else one could describe it. I continue to think, that class encapsulation is sacred, a well defined, well understood, concept that has been around for a very long time. private could have still meant private, and surely someone could have come up with a different access modifier to mean 'private at module level'. Was that too hard the language designers? Was it not hard, but just to complex to implement? I don't get it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:26:13 UTC, Radu wrote: On Tuesday, 13 March 2018 at 06:14:49 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong?? Yes, they got it wrong! Because they don't have modules, and because Java & C# are OOP bondage-everything-is-a-class, and preach that the world spins on classes. C++ tried to fix it with 'friend', and it shows the hack that it is. Don't know why you think D should be just another Java or C#? Well I don't really. But one of the great things about D, is that a C++/C#/Java programmers can jump right in. But when the same syntax suddenly means something really different, I tend to think that's not a good design decision. And that's really the main point of my argument. As I said, this was a real gotcha for me. I only realised after I accidently tried to modify a private member directly, and discovered I did actually modify it! Maybe, a different modifier that made it private to the module would have been a better design decision.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote: psychoticRabbit wrote: So the 3 most used languages got it wrong?? yes. do you know any other language, where a private class memeber, is not private to the class? (btw. that's a question, not a statement).
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". That's kind of my point. That's what I would have done, if for no other reason, to prevent the same syntax from having different semantics (when C++/C#/Java programmers come over to D). And I switch between them all, and now, I have to remember D's private memeber is something very different indeed. In Java, it's recommended to manipulate private member variables through their accessors even in methods of the same class. I've always found that extreme. Java is extreme in many ways ;-) but at least, private member, is still a private member (to the class). If my private class memeber can be directly modified outside of the class, then class encapsulation IS broken. Just saying, oh no, it's module encapsulation you should be thinking about, seems kinda strange, since we still use classes - which are their own level of encapsulation. That's the whole point of them.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote: There is another problem: 3rd: You are a brainwashed monkey who can't think for himself. Gee..takes some real brains to come up with that one. See, You learned a little about C++/C#/Java and think the world must conform to what they say is correct and deny everything that contradicts it rather than first seeing if you are on the wrong side of the contradiction. The fact is, there is no reason a module should be restricted to see it's own classes private members. Yeah that sounds fine. As long as you're willing to give up the concept of class encapsulation. And, as long as you are willing to have programmers use the same syntax in D, as used in the 3 most widely used lanaguages on the planet, but get very different semantics. It's a real gotcha for those programmers. It's sorta like a family who runs around pretending that they can't see each others private parts. Sure, it sounds like a good thing... until someone accidentally drops the towel and the offended calls the cop on their brother and has him arrested for breaking the law. I'm not interested in your fanatasies. Keep them to yourself. You should learn that your view of the world is very minute and stop trying to fit the world in to your box. It's called growing up. If you can't make a distinction between C++ encapsulation and D encapsulation you have far bigger problems than you think. I think the view of the 3 most widely used langauges on the planet, is not something to dismiss so easily. D has what, 1000 programmers, maybe.. so I wonder whose world is really minute. In any case, I'm not attacking D. I use it. I am just questioning whether the different semantics for private, in D, is really worth it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong??
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote: psychoticRabbit wrote: There are two problems I see: 1) it is not how C++ done it. 2) it is not how C++ done it. and you're completely right: it is not how C++ done it. umm...didn't you forget something: 1) it is not how C# done it. 2) it is not how C# done it. 1) it is not how Java done it. 2) it is not how Java done it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote: Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective. There are two problems I see: 1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion. 2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident). D has made many good design decisions. I do not see this as one of them.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members. - Jonathan M Davis Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all.
how to make private class member private
I cannot get my head around, why private is not private, in D.
How do I make a private member, private?
-
module test;
import std.stdio;
void main()
{
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
writeln(c.myPrivateClassMember);
}
class myClass
{
private string myPrivateClassMember; // private does not mean
private anymore??
}
--
Re: List installed modules
On Sunday, 11 March 2018 at 03:52:19 UTC, psychoticRabbit wrote: Whether dub does that currently I do not know, as i don't use dub, or any additional packages outside of phobos. oh > dub list ;-)
Re: List installed modules
On Sunday, 11 March 2018 at 01:04:27 UTC, Roberto wrote: How do I list installed modules? or.. https://dlang.org/phobos/index.html
Re: List installed modules
On Sunday, 11 March 2018 at 01:04:27 UTC, Roberto wrote: How do I list installed modules? dmd --list-modules datefmt dateparser std.algorithm std.array std.conv std.datetime std.digest std.exception std.file std.format std.getopt std.json std.math ... Presumably, you mean packages installed by dub, as opposed to what comes with phobos as part of the installation. If that's what you mean, then that could be an enhancment request - i.e. to have dub maintain a list of what's installed, like any good package manager should. Whether dub does that currently I do not know, as i don't use dub, or any additional packages outside of phobos.
Re: Speed of math function atan: comparison D and C++
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote: So the codes are trivial, simply some check of raw speed: double x = 0.0; for (int a = 0; a < 10; ++a) x += atan(1.0/(1.0 + sqrt(1.0 + a))); for C++ and double x = 0.0; for (int a = 0; a < 1_000_000_000; ++a) x += atan(1.0/(1.0 + sqrt(1.0 + a))); for D. C++ exec takes 40 seconds, D exec takes 68 seconds. should a be an int? make it a double ;-)
Re: string object won't compile
On Monday, 5 March 2018 at 23:34:50 UTC, askjfbd wrote: Someone please tell me how, for I am a newbie and don't know any solutions even to this very simple problem. As I learned dlang using the Dlang tour page, I stuck at the alias & Strings page. I have tried to compile the following simple code many times but still get the same error both from dmd and gdc. They both say that... This is mistake I made too, when i began using D. I quickly got into the habit of putting module test; at the beginning of every file I create, unless I determine a better module name. Actually, I wrote my own IDE, so it does that for me whenever I select a new D file. Personally, I think that is one of the first things newcomers need to learn about - modules. - "Modules have a one-to-one correspondence with source files. The module name is, by default, the file name with the path and extension stripped off, and can be set explicitly with the module declaration." "Modules automatically provide a namespace scope for their contents." https://dlang.org/spec/module.html
Re: single loop copy in D
On Friday, 2 March 2018 at 10:08:57 UTC, Simen Kjærås wrote:
This is of course only partly true.
while ((*dst++ = *src++) != 0) {}
works just great, and also better shows what's actually being
tested for in the loop.
--
Simen
That's what I was after. Thanks!
single loop copy in D
trying to do this C code, in D, but getting error:
"Error: assignment cannot be used as a condition, perhaps `==`
was meant?"
any help much appreciated:
--
while ((*dst++ = *src++)) {}
--
Re: forcing tabs in regex
On Wednesday, 28 February 2018 at 01:06:30 UTC, dark777 wrote:
Regex validates years bisexto and not bisextos in format:
const std::regex
pattern(R"(^(?:(?:(0?[1-9]|1\d|2[0-8])([-/.])(0?[1-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec|[Ff]eb)|(29|30)([-/.])(0?[13-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec)|(31)([-/.])(0?[13578]|1[02]|[Jj]an|[Mm]a[ry]|[Jj]ul|[Aa]ug|[Oo]ct|[Dd]ec))(?:\2|\5|\8)(0{2,3}[1-9]|0{1,2}[1-9]\d|0?[1-9]\d{2}|[1-9]\d{3})|(29)([-/.])(0?2|[Ff]eb)\12(\d{1,2}(?:0[48]|[2468][048]|[13579][26])|(?:0?[48]|[13579][26]|[2468][048])00))$)");
this regex above validates the formats through backreferences.
what is this evil dark magic?
Re: iota to array
On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote: A 64-bit double can only hold about 14-15 decimal digits of precision. Anything past that, and there's a chance your "different" numbers are represented by exactly the same bits and the computer can't tell the difference. T I really miss not having a (C# like) decimal type.
Re: iota to array
On Sunday, 25 February 2018 at 14:52:19 UTC, Steven Schveighoffer wrote: 1 == 1.0, no? no. at least, not when a language forces you to think in terms of types. 1 is an int. 1.0 is a floating point. I admit, I've never printed output without using format specifiers, but still, if I say write(1.0), it should not go off and print what looks to me, like an int. Inheriting crap from C is no excuse ;-) and what's going on here btw? assert( 1 == 1.01 ); // assertion error in DMD but not in LDC assert( 1 == 1.001 ); // no assertion error?? (compiled in 64bit mode)
Re: iota to array
On Sunday, 25 February 2018 at 12:13:31 UTC, Andrea Fontana wrote: On Sunday, 25 February 2018 at 09:30:12 UTC, psychoticRabbit wrote: I would have preffered it defaulted java style ;-) System.out.println(1.0); // i.e. it prints 'what I told it to print'. System.out.println(1.0); // print 1.0 System.out.println(1.0); // print 1.0 So it doesn't print "what you told it to print" Andrea Fontana can someone please design a language that does what I tell it! please!! is that so hard?? print 1.0 does not mean go and print 1 .. it means go and print 1.0 languages are too much like people.. always thinking for themselves. I fed up! fed up I say!
Re: iota to array
On Sunday, 25 February 2018 at 08:46:19 UTC, rumbu wrote:
On Sunday, 25 February 2018 at 08:08:30 UTC, psychoticRabbit
wrote:
But umm what happended to the principle of least
astonishment?
writeln(1.1); (prints 1.1)
whereas..
writeln(1.0); (prints 1)
I don't get it. Cause it's 'nicer'??
Because writeln(someFloat) is equivalent to writefln("%g",
someFloat). And according to printf specification, "trailing
zeros are removed from the fractional part of the result; a
decimal point appears only if it is followed by at least one
digit"
oh. that explains it.
I would have preffered it defaulted java style ;-)
System.out.println(1.0); // i.e. it prints 'what I told it to
print'.
Re: iota to array
On Sunday, 25 February 2018 at 06:35:07 UTC, Jonathan M Davis
wrote:
It's not printing ints. It's printing doubles. It's just that
all of the doubles have nothing to the right of the decimal
point, so they don't get printed with a decimal point. If you
did something like start with 1.1, then you'd see decimal
points, because there would be data to the right of the decimal
point. The same thing happens if you do
writeln(1.0);
as opposed to something like
writeln(1.3);
thanks.
But umm what happended to the principle of least astonishment?
writeln(1.1); (prints 1.1)
whereas..
writeln(1.0); (prints 1)
I don't get it. Cause it's 'nicer'??
I ended up having to work around this..like this:
---
void printArray(T)(const ref T[] a) if (isArray!(T[]))
{
if( isFloatingPoint!T)
foreach(t; a) writefln("%.1f", t);
else
foreach(t; a) writefln("%s", t);
}
---
Re: iota to array
On Sunday, 25 February 2018 at 05:40:19 UTC, Jonathan M Davis
wrote:
int[] intArr = iota(1, 11).array();
- Jonathan M Davis
thanks!
oh man. It's so easy to do stuff in D ;-)
But this leads me to a new problem now.
When I run my code below, I get ints printed instead of doubles??
-
module test;
import std.stdio : writeln;
import std.traits : isArray;
import std.array : array;
import std.range : iota;
void main()
{
int[] intArr = iota(1, 11).array(); // 1..10
double[] doubleArr = iota(1.0, 11.0).array(); // 1.0..10.0
char[] charArr = iota('a', '{').array(); // a..z
printArray(intArr);
printArray(doubleArr); // why is it printing ints instead of
doubles??
printArray(charArr);
}
void printArray(T)(const ref T[] a) if (isArray!(T[]))
{
foreach(t; a)
writeln(t);
}
-
iota to array
Hi. Anyone know whether something like this is possible?
I've tried various conversions/casts, but no luck yet.
Essentially, I want to cast the result set of the iota to an
array, during initialisation of the variable.
no, I don't want to use 'auto'. I want an array object ;-)
--
module test;
import std.stdio;
import std.range : iota;
void main()
{
int[] intArr = iota(1, 11); // 1..10
double[] doubleArr = iota(1.0, 11.0); // 1.0..10.0
char[] charArr = iota('a', '{'); // a..z
}
-
Re: Template Constraints
On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis wrote: Why is there anything dodgy going on and why would you need contracts? Contracts actually tend to go very badly with generic code, because whatever they assert has to be generic, and while that works sometimes, more often than not, it doesn't. - Jonathan M Davis what if 3.3 is passed to the template, and it explicately casts it to an int. To me, that would be dodgy - unless there was a contract, that I had accepted and agreed to, so that this not dodgy.
Re: Template Constraints
On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis wrote: Whether an implicit cast or an explicit cast makes more sense depends entirely on what the code is doing, but either way, the conversion needs to be forced inside the function, or you end up with bugs. Far too often, when someone has a template constraint that checks an implicit conversion, the function doesn't actually force the conversion, and that can do anything from resulting in some instantiations not compiling to causing subtle bugs due to the argument being used without being converted. In general, it's actually best to avoid conversions entirely with generic code and force the caller to do the conversion if a conversion is appropriate. But ultimately, what works best depends on what the code is trying to do. - Jonathan M Davis yeah it's hard to say much more without knowing what the code really wants to do..but presumably, you'd want to incorporate some contract programming in such a solution too, particulary given there's something potentially dodgy going on within such a function.
Re: Template Constraints
On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis wrote: That does not do what the OP requested at all. That tests whether T is one of byte, ubyte, short, ushort, int, uint, long, and ulong, whereas what the OP wants is to test whether T can be cast to int. - Jonathan M Davis yeah. I realised that after I had posted. I posted a more suitable response after that though (I hope), with the intention of leading the OP away from an explicit cast, towards an implicit cast.
Re: Template Constraints
On Saturday, 24 February 2018 at 03:30:45 UTC, psychoticRabbit
wrote:
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be
possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");
}
or this is probably more suitable ;-)
(should you really be using an explicity convert anyway?)
void testTemplate2(T)(T x) if (isImplicitlyConvertible!(T, int))
{
writeln(x, " is implicitly convertible to an int. yeah!");
}
Re: Template Constraints
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");
}
Re: Template Constraints
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
I would have thought contracts would be ideal here?
https://dlang.org/spec/contracts.html
Re: Building from source on FreeBSD
On Wednesday, 21 February 2018 at 11:41:18 UTC, Diederik de Groot wrote: Removing the pragma(lib, "curl") seems to fix the issue on DFly (and FreeBSD). Updated the pull request. I guess pragma(lib, xxx) needs a little bit of attention to see what causes it not to work. something to do with this perhaps? https://stackoverflow.com/questions/23214697/trouble-with-curl-and-pragma in any case, that line doesn't even need to be there AFAICT. dget builds and works just fine with it commented out. I've commented it out on my linux builds too.
Re: Building from source on FreeBSD
On Monday, 19 February 2018 at 12:01:31 UTC, Jonathan M Davis wrote: I've never been able to figure this problem out, so I've I always just edited the makefile so that the two programs in CURL_TOOLS aren't built. IIRC, if you use -v to see the full linker command, it's even actually linking to the curl library that's there but somehow not succeeding. It's all quite weird. It's been a while since I dug into it though. - Jonathan M Davis ok... so I decided to dig into it a little further. seems the problem relates to a single line, in dget.d pragma(lib, "curl"); I just commented out the one line in dget.d, and it all seems to build ok (including dget). So no need to comment out tools in posix.mak anymore.
Re: Building from source on FreeBSD
On Monday, 19 February 2018 at 12:01:31 UTC, Jonathan M Davis wrote: I've never been able to figure this problem out, so I've I always just edited the makefile so that the two programs in CURL_TOOLS aren't built. IIRC, if you use -v to see the full linker command, it's even actually linking to the curl library that's there but somehow not succeeding. It's all quite weird. It's been a while since I dug into it though. - Jonathan M Davis Thanks for the quick response. So I took your advice and just commented out (as per below), and now it all builds fine - AFAICT ;-) -FROM 61:all: $(TOOLS) $(CURL_TOOLS) $(ROOT)/dustmite 76:$(TOOLS) $(DOC_TOOLS) $(CURL_TOOLS) $(TEST_TOOLS): $(ROOT)/%: %.d -TO 61:all: $(TOOLS) $(ROOT)/dustmite 76:$(TOOLS) $(DOC_TOOLS) $(TEST_TOOLS): $(ROOT)/%: %.d
Building from source on FreeBSD
So I finally got around to building from source. I have builds working just fine on a variety of linux machines, it's just a FreeBSD problem I'm having. So, on FreeBSD, I can build the dmd directory, and the phobos directory ok. When building tools directory, most tools get built ok, but the build process stops during something to do with curl.. gmake -f posix.mak -j8 (yeah on FreeBSD use gmake not make) . .. ... (bunch of stuff builds ok.. then this next line) /usr/bin/ld: cannot find -lcurl cc: error: linker command failed with exit code 1 (use -v to see invocation) Error: linker exited with status 1 gmake: *** [posix.mak:77: generated/freebsd/64/dget] Error 1 gmake: *** Waiting for unfinished jobs Yes, I do have the FreeBSD curl package installed - curl-7.56.0 Yes, curl is in the path> which curl -> /usr/local/bin/curl So I can only assume my FreeBSD machine is missing some curl related library/package?? Any help would be appreciated.
Re: countUntil to print all the index of a given string.
On Sunday, 18 February 2018 at 15:23:14 UTC, Cym13 wrote: On Sunday, 18 February 2018 at 14:48:59 UTC, Cym13 wrote: [...] Just thought of a much better/simpler solution for that last case that also doesn't force you to read all data (which might be impossible when dealing with infinite ranges): import std.range; import std.algorithm; a[] .enumerate // get tuples (index, value) .filter!(t => t[1] == "Test2") // keep only if value == "Test2" .map!(t => t[0]) // keep only the index part .writeln; Completely lazy. A nice example of how D's multiparadigm programming model allows the utilisation of algorithms that can scale to process massive datasets. There is an article in there somewhere ;-)
Re: Disk space used and free size of a Network share folder in Windows
On Wednesday, 14 February 2018 at 15:24:42 UTC, Vino wrote: ...the only problem is i am not sure hot to get the out put without the headings(Caption FreeSpace,Size) any help on same is much appreciated. writeln(result.output[38..$]);
Re: Disk space used and free size of a Network share folder in Windows
On Wednesday, 14 February 2018 at 12:29:13 UTC, rikki cattermole
wrote:
See:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364935(v=vs.85).aspx
any idea on how I'd convert this C# code to D?
==
public class Program
{
[DllImport("kernel32.dll")]
[return:MarshalAs(UnmanagedType.Bool)] static extern bool
GetDiskFreeSpaceEx(string lpDirectoryName,
out ulong lpFreeBytesAvailable,
out ulong lpTotalNumberOfBytes,
out ulong lpTotalNumberOfFreeBytes);
static void Main()
{
string dir = "C:\\";
ulong lpFreeBytesAvailable;
ulong lpTotalNumberOfBytes;
ulong lpTotalNumberOfFreeBytes;
GetDiskFreeSpaceEx(dir, out lpFreeBytesAvailable, out
lpTotalNumberOfBytes, out lpTotalNumberOfFreeBytes);
Console.WriteLine(lpFreeBytesAvailable");
Console.WriteLine(lpTotalNumberOfBytes");
Console.WriteLine(lpFreeBytesAvailable");
}
}
=
Re: import strangeness with std.stdio.write
On Tuesday, 13 February 2018 at 14:21:31 UTC, bauss wrote:
What you can do is use aliases to use both functions.
import io = std.stdio;
void main()
{
import file = std.file;
file.write("hello");
io.writeln("hello again");
}
that's a nice simple solution.
thanks.
Re: import strangeness with std.stdio.write
On Tuesday, 13 February 2018 at 14:18:05 UTC, ketmar wrote:
psychoticRabbit wrote:
Also, if I do this below, how does the compiler choose the
correct write function?
import std.stdio;
import std.file;
void main()
{
write("hello");
writeln("hello again");
}
it's easy: just take a look at `std.file.write()`. first, it
require two arguments. this is enough to rule
`stf.file.write()` out in your case.
oh..function overloading..makes sense.
thanks again.
Re: import strangeness with std.stdio.write
On Tuesday, 13 February 2018 at 13:57:38 UTC, ketmar wrote:
`std.file` has function named `write()` too. and local import
completely shadows global imports (i.e. it removes global
imports from overload set for the given scope), hence
`std.stdio.write()` is not available there.
"..local import completely shadows global imports"
oh... I didn't realised imports are subject to scope rules in
that way.
This new knowledge will certainly prevent some ongoing confusion
;-)
thanks.
Also, if I do this below, how does the compiler choose the
correct write function?
import std.stdio;
import std.file;
void main()
{
write("hello");
writeln("hello again");
}
Re: import strangeness with std.stdio.write
On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole
wrote:
On 13/02/2018 1:46 PM, psychoticRabbit wrote:
So, strange problem below.
The commented-out line will not compile (if I un-comment it),
unless I either move std.stdio into main, or, move std.file
out of main.
Whereas writeln works just fine as is.
-
module test;
import std.stdio;
void main()
{
import std.file;
//write("hello");
writeln("hello again");
}
---
write exists in both, writeln exists only in std.stdio.
Use named imports to pick which write you want.
oh..you must have posted as I why posting ;-)
That makes sense then. Thanks for clearing that up.
And I should have read the compiler message more clearly..cause
the answer was in that error message (more or less)
Re: import strangeness with std.stdio.write
On Tuesday, 13 February 2018 at 13:46:11 UTC, psychoticRabbit
wrote:
So, strange problem below.
The commented-out line will not compile (if I un-comment it),
unless I either move std.stdio into main, or, move std.file out
of main.
Whereas writeln works just fine as is.
-
module test;
import std.stdio;
void main()
{
import std.file;
//write("hello");
writeln("hello again");
}
---
I should add, that this problem seems directly related to
std.file.
i.e. if I replace std.file, with say, std.conv, then the write
function (once uncommented) will compile ok.
import strangeness with std.stdio.write
So, strange problem below.
The commented-out line will not compile (if I un-comment it),
unless I either move std.stdio into main, or, move std.file out
of main.
Whereas writeln works just fine as is.
-
module test;
import std.stdio;
void main()
{
import std.file;
//write("hello");
writeln("hello again");
}
---
Re: No error message in DMD 2.078.2
On Tuesday, 13 February 2018 at 05:51:05 UTC, Domain wrote:
module main;
void main ()
{
writeln("Hello");
}
Of course, this won't compile, but error message is confused:
C:\Git\hello\source>dmd app.d
app.d(5): Error:
object.Error@(0): Access Violation
0x0065445A
0x006548FE
0x0064DBD3
0x004B0B90
0x004B8A02
0x00594813
0x005797E2
0x77E40608 in RtlAllocateHeap
0x77E3EB5E in RtlAllocateHeap
0x77E2DD5A in RtlRandom
0x004E0F98
0x005B6D16
0x0047BFCA
0x005DD152
erh?
I get a good enough error message(v2.078.2)
Exit code is: 1
..Error: `writeln` is not defined, perhaps `import std.stdio;` is
needed?
Sounds more like you have env issues.
Re: Fixed size array initialization
On Sunday, 11 February 2018 at 01:13:00 UTC, psychoticRabbit
wrote:
Well, in C.. I can do:
int arr[2] = { [0]=10, [1]=20 };
I cannot work out how to do that in D yet (anyone know??)
Oh. just worked it out after reading this thread ;-)
int[2] arr = [ 0:10, 1:20 ];
Re: Fixed size array initialization
On Saturday, 10 February 2018 at 10:55:30 UTC, rumbu wrote:
I have a large static initialized array, let's say int[155],
and I forgot to declare the last element:
int[155] myarray = [
a,
b,
c,
...
//forgot to declare the 155th element
];
Well, in C.. I can do:
int arr[2] = { [0]=10, [1]=20 };
I cannot work out how to do that in D yet (anyone know??)
In the meantime, I'd suggest doing it this way, as you're more
likely to see that whether you forgot an element:
int[2] arr;
{
arr[0] = 10;
arr[1] = 20;
}
