Re: Does dmd not always compile all of the source code?
On Wednesday, 6 December 2017 at 19:19:09 UTC, A Guy With a Question wrote: It seems D's fast compile times are achieved by skipping semantic checking and even parsing when it doesn't feel it's needed. I strongly disagree with this decision. This could leave complex dormant time bombs that break builds unexpectedly and even accidentally. It's understandable in certain situations where there is enough information, but the first step to testing code, is first making sure it compiles...I don't want the compiler making decisions on what is worthy to compile. If I pass a d source file into it, I want to know if it's valid. This is unfortunate. This might be a deal breaker for me. I'm very concerned of working with a language that, at minimum, doesn't let me know if a file I passed in even contains valid code.
Re: Does dmd not always compile all of the source code?
On Wednesday, 6 December 2017 at 18:09:45 UTC, Steven
Schveighoffer wrote:
On 12/6/17 12:17 PM, Steven Schveighoffer wrote:
So why wouldn't the compiler fail? Because it has no idea yet
what you mean by Nullable. It doesn't even know if Nullable
will be available or not. You could even import Nullable, but
Nullable!T may be an error.
To give an example of why the compiler waits until
instantiation:
class C(T) : T
{
void foo() { doesthisexist(); }
}
class D { void doesthisexist(); }
auto x = new C!D; // OK
auto y = new C!Object: // fail
-Steve
It also doesn't parse or do semantic checks on unit tests unless
you add the flag...apparently.
This compiles...
unittest
{
WHY DOESNT THE COMPILER FIND A PROBLEM HERE!?
}
It seems D's fast compile times are achieved by skipping semantic
checking and even parsing when it doesn't feel it's needed. I
strongly disagree with this decision. This could leave complex
dormant time bombs that break builds unexpectedly and even
accidentally. It's understandable in certain situations where
there is enough information, but the first step to testing code,
is first making sure it compiles...I don't want the compiler
making decisions on what is worthy to compile. If I pass a d
source file into it, I want to know if it's valid. This is
unfortunate. This might be a deal breaker for me.
Re: Does dmd not always compile all of the source code?
On Wednesday, 6 December 2017 at 16:49:51 UTC, A Guy With a
Question wrote:
module grrr.grr;
abstract class Test(T)
{
private:
T thing;
public:
this(T theThing)
{
thing = theThing;
thisdoesnotexist(); // expect compiler error right here
}
}
...but this compiles just fine.
It does produce there error when I do this:
class Test2
: Test!int
{
this(int thing)
{
super(thing);
}
}
Another example:
interface ITest(T)
{
@property
Nullable!T value(); // have not imported Nullable. Should fail.
}
compiles...
Fails when this happens:
class Test
: ITest!int
{
@property
Nullable!int value() { return nullable(0); }
}
I really do think, regardless of if this is considered a template
expansion, that dmd should be catching these obvious errors. When
one writes interfaces and abstract classes they are generally not
ready to implement the end class yet. And getting a ton of errors
at once when that occurs is really hard to deal with. I really
don't understand why the compiler would have issues with this.
Re: Does dmd not always compile all of the source code?
On Wednesday, 6 December 2017 at 16:32:05 UTC, A Guy With a
Question wrote:
I have to be honest, I'm a little worried about all of this
code I just translated and how much of it is actually valid...I
hope I didn't waste my time.
Ok, so I verified this much. I would expect an error from the
following, but it does not actually produce an error...
module grrr.grr;
abstract class Test(T)
{
private:
T thing;
public:
this(T theThing)
{
thing = theThing;
thisdoesnotexist(); // expect compiler error right here
}
}
...but this compiles just fine.
Re: Does dmd not always compile all of the source code?
On Wednesday, 6 December 2017 at 16:47:17 UTC, A Guy With a
Question wrote:
On Wednesday, 6 December 2017 at 16:32:05 UTC, A Guy With a
Question wrote:
I have to be honest, I'm a little worried about all of this
code I just translated and how much of it is actually
valid...I hope I didn't waste my time.
Ok, so I verified this much. I would expect an error from the
following, but it does not actually produce an error...
module grrr.grr;
abstract class Test(T)
{
private:
T thing;
public:
this(T theThing)
{
thing = theThing;
thisdoesnotexist(); // expect compiler error right here
}
}
...but this compiles just fine.
It does produce there error when I do this:
class Test2
: Test!int
{
this(int thing)
{
super(thing);
}
}
Re: Does dmd not always compile all of the source code?
I have to be honest, I'm a little worried about all of this code I just translated and how much of it is actually valid...I hope I didn't waste my time.
Re: Does dmd not always compile all of the source code?
On Wednesday, 6 December 2017 at 16:10:34 UTC, Atila Neves wrote: On Wednesday, 6 December 2017 at 16:07:41 UTC, A Guy With a Question wrote: Noticed several typos that dmd seems to have not picked up initially. Does dmd not compile all source code? I obviously wouldn't expect it to recompile something unnecessarily, but in a few cases I've just seen it not throw errors where it should have. It depends on how you're invoking it. In all likelihood, you had typos in uninstantiated templates. Atila I'm not sure how it works underneath the covers, but I'm not currently working with a ton of templates explicitly. I am utilizing interfaces and some generic container types, which I guess might mean templates underneath. However, if an abstract class with a generic parameter translates itself to a template underneath the covers, I still would expect it to throw an error if I have a clear syntax problem. If it's not, that's pretty unacceptable actually for it not to.
Does dmd not always compile all of the source code?
Noticed several typos that dmd seems to have not picked up initially. Does dmd not compile all source code? I obviously wouldn't expect it to recompile something unnecessarily, but in a few cases I've just seen it not throw errors where it should have.
Re: Embedded interfaces with generic members
On Tuesday, 5 December 2017 at 19:27:37 UTC, Ali Çehreli wrote:
On 12/05/2017 11:07 AM, A Guy With a Question wrote:
> The following doesn't appear to be valid syntax. Array!Item!T
You can ommit the template argument list parenteses only for
single symbols.
Starting with the full syntax:
Array!(Item!(T))
Since Item!(T) uses a single symbol, T, you can remove the
parenteses from that one:
Array!(Item!T)
The following compiles:
import std.container.array;
struct Item(T) {
}
void main() {
alias T = int;
auto a = Array!(Item!T)();
}
Ali
yup that was the issue.
Embedded interfaces with generic members
The following doesn't appear to be valid syntax. Array!Item!T
I get the following error:
"multiple ! arguments are not allowed"
Which is ok...I get THAT error, however, this does not work
either:
alias Items(T) = Array!Item(T);
This gives me the error:
Error: function declaration without return type. (Note that
constructors are always named `this`)
Item is defined as follows:
interface Item(T)
{
@property
T member();
}
That part compiles fine. However, even when I remove the
aliasing, I can't import this interface. I get "Error: undefined
identifier 'Item'"
I'm not quite sure I understand how to create a generic container
interface or class in D. Half of how I expect it to work works,
but the other half doesn't. The docs aren't too helpful. I'm not
sure if it's a case where there's just too much to go through or
if what I'm trying to do isn't really covered. Essentially I'm
trying to create an array of this type 'Item' that has some
generic members. I think people who come from C# will kind of get
what I'm trying to do here, because I'm trying to port C# code.
Re: Object oriented programming and interfaces
On Monday, 4 December 2017 at 20:43:27 UTC, Dirk wrote:
Hi!
float distance( Medoid other );
float distance( Item i ) {...}
The two signatures need to be the same. I think this is true of
most OOP languages. Have them both be:
float distance( Medoid other );
Re: Struct inside a class: How to get outer?
On Monday, 4 December 2017 at 14:01:08 UTC, Steven Schveighoffer
wrote:
On 12/3/17 2:38 AM, Jonathan M Davis wrote:
On Sunday, December 03, 2017 01:05:00 Nick Sabalausky via
Digitalmars-d-
learn wrote:
Is this even possible? My attempts:
class Outer {
struct Inner {
void foo() {
// Error: no property 'outer' for type 'Inner'
Outer o = this.outer;
// Error: cannot implicitly convert expression
// this of type Inner to testNested.Outer
Outer o = this;
}
}
}
As I understand it, there is no outer for nested structs, only
nested
classes. So, you'll either have to use a nested class or
explicitly pass a
reference to the outer class to the nested struct.
Yes, for structs inside structs or classes, there is no 'outer'
member.
However, there is a hidden context member in a struct if it's
nested inside a function. In that case, you must label the
struct "static"
The only reason inner classes have outer pointers to their
"owner" class instance, is for those familiar with Java
programming style (specifically, IIRC, it was to write dwt,
which was a port of jwt). I believe Walter mentioned elsewhere
recently, he would have done things differently today.
-Steve
Yes! Don't forget the 'static' otherwise you'll get some odd
errors.
Is std.container.array more or less an equivalent of C#'s List?
Reading this, the interface seems very similar, but I'm not sure. There's only like a two sentence general description, then it goes on to talk about a boolean specialization... https://dlang.org/phobos/std_container_array.html I'm looking for something that doesn't have to resize every insert/append, but also it's going to be copying the whole array either each time.
Re: Is std.container.array more or less an equivalent of C#'s List?
On Monday, 4 December 2017 at 16:26:02 UTC, A Guy With a Question wrote: Reading this, the interface seems very similar, but I'm not sure. There's only like a two sentence general description, then it goes on to talk about a boolean specialization... https://dlang.org/phobos/std_container_array.html I'm looking for something that doesn't have to resize every insert/append, but also it's going to be copying the whole array either each time. For clarity (had a typo in the original question). I do not want it copying the entire array every time. I'm looking for something close to C#'s List.
Re: Convert a single element into a range
On Thursday, 30 November 2017 at 22:52:33 UTC, Ali Çehreli wrote:
On 11/30/2017 02:47 PM, A Guy With a Question wrote:
This is probably a dumb question, but what I did looks ugly.
Is there a way (preferably a one liner) to convert a single
element, like an int or char or bool, into a range?
import std.range;
void main() {
auto r = only(42);
static assert(isInputRange!(typeof(r)));
}
Ali
Excellent!
Convert a single element into a range
This is probably a dumb question, but what I did looks ugly. Is there a way (preferably a one liner) to convert a single element, like an int or char or bool, into a range?
Re: Changing the class data underneath some reference
On Thursday, 30 November 2017 at 00:40:51 UTC, David Colson wrote:
Hello all!
I'm getting settled into D and I came into a problem. A code
sample shows it best:
class SomeType
{
string text;
this(string input) {text = input;}
}
void main()
{
SomeType foo = new SomeType("Hello");
SomeType bar = foo;
foo = new SomeType("World");
writeln(bar.text); // Prints hello
// I'd like it to print World
}
In the C++ world I could do this using pointers and changing
the data underneath a given pointer, but I can't use pointers
in D, so I'm not sure how I can get this behaviour?
I'd be open to other ways of achieving the same affect in D,
using more D like methods.
You are dealing with a reference type. Reference types can be
though of as a value type of an address. The new operator can be
though of as giving the variable a new address. This means the
foo and bar variables are not bound to the same value because
their referencing different address. You need a struct. Which
isn't a reference.
Re: Floating point types default to NaN?
On Wednesday, 29 November 2017 at 01:25:47 UTC, Michael V. Franklin wrote: On Wednesday, 29 November 2017 at 01:24:21 UTC, A Guy With a Question wrote: I was just more curious of the design decisions that were made. So am I. I'm trying to get to the heart of in the the PR comments. Mike That's a lot less code than I would have thought to implement that. The comment about phobos was a good one. Just reading through it.
Re: Floating point types default to NaN?
On Tuesday, 28 November 2017 at 20:00:53 UTC, Michael V. Franklin wrote: On Monday, 27 November 2017 at 23:05:55 UTC, Michael V. Franklin wrote: I think I'm going to implement a feature gate to require explicit initialization. It would be better to be strict up front and relax it as flow control analysis becomes more mature. Well, I implemented it (https://github.com/dlang/dmd/pull/7375), but it's off to a pretty rocky start. Mike To be honest, I didn't actually expect anyone to act on my question. :D I was just more curious of the design decisions that were made.
Re: Really? -- Error: function `object.Throwable.message` is not nothrow
On Wednesday, 29 November 2017 at 00:52:41 UTC, A Guy With a Question wrote: .msg worked. I will let you all live. Thanks!
Re: Really? -- Error: function `object.Throwable.message` is not nothrow
.msg worked. I will let you all live.
Really? -- Error: function `object.Throwable.message` is not nothrow
What's the clean way to extract the message that passes the nothrow argument? Do I really have to embed another try catch?
Re: On Attributes
On Monday, 27 November 2017 at 19:41:03 UTC, Adam D. Ruppe wrote: On Monday, 27 November 2017 at 19:10:04 UTC, A Guy With a One thing that is bugging me is having to mark up all of my declarations with attributes. Meh, you could also just ignore the attribute crap. Only reason I ever mess with them is if someone who is using them tries to use my code... otherwise you can pretend the spam doesn't exist and be more productive. Yeah, I'm leaning towards that direction. It seems they could have been useful if they were the default. But opting into them doesn't seem as useful, unfortunately. I'll probably continue fiddling with them, but I might just abandon using them.
On Attributes
Hi again! I've been trying to do my best to write idiomatically. One thing that is bugging me is having to mark up all of my declarations with attributes. Which means I'm having to remember them all. It's a bit much to keep in my head with every function. Is there a good way to reverse this (imply the attributes by default) and then turn them off explicitly? Like declaring them at the top of the file so they apply to everything below? Thanks!
Re: Linking multiple libraries
On Saturday, 25 November 2017 at 22:40:49 UTC, A Guy With a Question wrote: On Saturday, 25 November 2017 at 22:36:32 UTC, A Guy With a Question wrote: On Saturday, 25 November 2017 at 22:31:10 UTC, Mike Parker wrote: On Saturday, 25 November 2017 at 22:18:52 UTC, A Guy With a Question wrote: That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks? Is there a functional difference at the end of the day? You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior. Yes. That also worked when I tried it. Also when I said library, I'm actually talking about the dlls that are produced. I essentially have four projects in Visual D. Each produces a binary. 3 produce dlls and the final created the end exe. Actually ignore that last comment, they are producing libs not dlls. Funny how all three ways of linking work...
Re: Linking multiple libraries
On Saturday, 25 November 2017 at 22:36:32 UTC, A Guy With a Question wrote: On Saturday, 25 November 2017 at 22:31:10 UTC, Mike Parker wrote: On Saturday, 25 November 2017 at 22:18:52 UTC, A Guy With a Question wrote: That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks? Is there a functional difference at the end of the day? You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior. Yes. That also worked when I tried it. Also when I said library, I'm actually talking about the dlls that are produced. I essentially have four projects in Visual D. Each produces a binary. 3 produce dlls and the final created the end exe.
Re: Linking multiple libraries
On Saturday, 25 November 2017 at 22:31:10 UTC, Mike Parker wrote: On Saturday, 25 November 2017 at 22:18:52 UTC, A Guy With a Question wrote: That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks? Is there a functional difference at the end of the day? You don't link static libraries with each other. They're just collections of object files intended to be linked with an executable or a DLL. Order doesn't matter for optlink or the MS linker, but other linkers, such as ld (which is commonly used with GCC) require the libraries be passed in according to dependencies, e.g. dependent libraries come before their dependencies. Not sure if the LLVM linker retains that behavior. Yes. That also worked when I tried it.
Re: Floating point types default to NaN?
On Saturday, 25 November 2017 at 22:13:43 UTC, Adam D. Ruppe wrote: On Saturday, 25 November 2017 at 16:16:52 UTC, A Guy With a Question wrote: If D chooses it's defaults to make errors stick out, why not just error at declaration if they don't explicitly set it to something. It technically did: https://dlang.org/spec/function.html#local-variables "It is an error to use a local variable without first assigning it a value. The implementation may not always be able to detect these cases. Other language compilers sometimes issue a warning for this, but since it is always a bug, it should be an error. " But that paragraph was never implemented (it is a bit easier said than done to actually detect given if conditions and stuff too, especially in the early days of D when the compiler didn't even make any effort to track such things, though it does now...). The compiler author took the easy way out of initializing them to invalid values instead. While it is more realistic to implement technically now than it was years ago when the current behavior got in, I think we're at the point now that so many people use it as a convenience thing on ints and nulls that there'd be hell to pay if the compiler actually started calling it an error :( Fair enough!
Linking multiple libraries
Hi, So I got this working, I would just like to see if I have done this correctly or if it's just working out of a fluke. I am using Visual D. Lets say I have four projects: Library 1: Common Library Library 2: Base Service Library - Dependent on the Common Library. Library 3: More Specified Service Library - Dependent on the base service library. Final Exe - Dependent on Library 3. ^^^ That's how I set up the linking in Visual D. Everything builds. But should the final exe try to link against all 3 libraries, library 3 link to library 1 & 2 and library 2 link to library 1 (also builds)? Or is the single dependence chain I created work without quirks? Is there a functional difference at the end of the day?
Re: Floating point types default to NaN?
Nonetheless, my original question was answered. Thanks for the insights!
Re: Floating point types default to NaN?
On Saturday, 25 November 2017 at 09:39:15 UTC, Dave Jones wrote: On Friday, 24 November 2017 at 22:38:49 UTC, Jonathan M Davis wrote: On Friday, November 24, 2017 20:43:14 A Guy With a Question via Digitalmars- d-learn wrote: On Friday, 24 November 2017 at 14:43:24 UTC, Adam D. Ruppe That requires data flow analysis, which the compiler doesn't do a lot of, because it can be complicated. It also tends to result in the compiler giving warnings or errors in cases where it's not actually true that the variable is used before it's given a value, because it can't do it perfectly. There was a recent discussion on this in the main newsgroup with regards to guaranteeing with a pointer or reference was initialized to something other than null. I think he means just spew an error if a float is declared but not explicitly initialised... Whats the problem with... float foo; // compiler error "floats must be explicitly initialised" float foo = float.nan; // old behaviour. I mean at the end of the day, that would turn a run time error into a compile time error which is a good thing isnt it? That is exactly what I meant. I think most languages just choose to default it to something convenient, which is 0. C++ chooses not to default it for speed reasons. If D chooses it's defaults to make errors stick out, why not just error at declaration if they don't explicitly set it to something. Including void, which would give you C++ undefined behavior from what I've read so far.
Re: Floating point types default to NaN?
On Friday, 24 November 2017 at 14:43:24 UTC, Adam D. Ruppe wrote: On Friday, 24 November 2017 at 14:30:44 UTC, A Guy With a Question wrote: I would have expected 0 to be the default value. What's the logic behind having them being NaN by default? It gives you a runtime error (sort of) if you use an uninitialized variable. You ARE supposed to explicitly initialize variables to your own values in D. The automatic init is to make errors stand out more consistently if you don't do this as opposed to being random. So pointers are initialized to null - an invalid value that stands out if you try to use it. chars get \xFF - again, invalid that will throw if you try to utf decode it. Floats get NaN which is as close to invalid as they get. ints happen to get 0 not to be convenient, but because there is no clearly-invalid int value so something had to be chosen, and 0 was just easy to implement If thats the case why not just throw a compiler error? D has a way explicitly not set it right? Through void...So if the intent is to find erroneous code right away, just throw a compiler error no?
Floating point types default to NaN?
I would have expected 0 to be the default value. What's the logic behind having them being NaN by default? https://dlang.org/spec/type.html
Re: Error: 'this' is only defined in non-static member functions
here as non-static, nested class is associated with a specific instance of the class and has access to that class instance via its outer member. - Jonathan M Davis Hmmm...now you have me very intrigued. What is a use-case where you'd want to use a non-static embedded class? Sorry if I'm asking too many questions. But there's a lot to dig into with this language.
Re: Error: 'this' is only defined in non-static member functions
On Wednesday, 22 November 2017 at 22:45:53 UTC, A Guy With a Question wrote: On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven Schveighoffer wrote: On 11/22/17 5:36 PM, Steven Schveighoffer wrote: This allows access to the outer class's members. So you need an instance to instantiate. I bet it's the same for interfaces. All that being said, the error message is quite lousy. -Steve Yup that worked. Thanks! Out of curiosity, what does static mean in that context? When I think of a static class I think of them in the context of Java or C# where they can't be instantiated and where they are more like namespaces that you can't directly import the contents of. Clearly static has a slightly different meaning in D.
Re: Error: 'this' is only defined in non-static member functions
On Wednesday, 22 November 2017 at 22:37:46 UTC, Steven Schveighoffer wrote: On 11/22/17 5:36 PM, Steven Schveighoffer wrote: This allows access to the outer class's members. So you need an instance to instantiate. I bet it's the same for interfaces. All that being said, the error message is quite lousy. -Steve Yup that worked. Thanks! Out of curiosity, what does static mean in that context? When I think of a static class I think of them in the context of Java or C# where they can't be instantiated and where they are more like namespaces that you can't directly import the contents of.
Error: 'this' is only defined in non-static member functions
I have an interface where I have a classes embedded in it's scope
(trying to create something for the classes that implement the
interface can use for unittesting).
interface IExample
{
// stuff ...
class Tester
{
}
}
I'm trying to make an instance of it like:
auto tester = new IExample.Tester();
And I get the above error.
Re: Visual D >> TRACKER : error TRK0004: Failed to locate: "FileTracker32.dll". The system cannot find the file specified.
On Tuesday, 21 November 2017 at 04:39:52 UTC, A Guy With a Question wrote: I'm trying to learn D using Visual D in Visual Studio Community 2015. Both dmd and ldc give me this error when building from Visual Studio. Any ideas? I'm able to build C++ projects... So I figured this one out. I set my dmd directory wrong. I could not find where to correct this though in visual d's configurations. I probably just kept glossing over it. What I ended up doing was uninstalling visual d and reinstalling where I noticed it defaulted me to my D folder, but I needed to point it at dmd's root folder. Just in case anyone was wondering what the fix was to this.
Visual D >> TRACKER : error TRK0004: Failed to locate: "FileTracker32.dll". The system cannot find the file specified.
I'm trying to learn D using Visual D in Visual Studio Community 2015. Both dmd and ldc give me this error when building from Visual Studio. Any ideas? I'm able to build C++ projects...
