Re: unittest blocks not being run inside of class and struct templates
On Tuesday, 25 July 2017 at 02:18:41 UTC, Adam D. Ruppe wrote: On Tuesday, 25 July 2017 at 02:11:20 UTC, NoBigDeal256 wrote: it passes when it should fail because the unittest block is never executed. Why is this? Did you actually instantiate the class somewhere? A template has no concrete code unless created with an argument somewhere... What if it's instantiated in another module? Right now I'm having issues where if I run 'dmd a.d b.d -unittest' and the class template in b.d is instantiated in a.d and it compiles and the tests inside my class template run as they should, but when using 'dub test' the tests in my class template don't run at all as if it isn't instantiated in a.d even though it is. This is the original issue that I had that prompted me to create this thread.
Re: unittest blocks not being run inside of class and struct templates
On Tuesday, 25 July 2017 at 02:18:41 UTC, Adam D. Ruppe wrote: On Tuesday, 25 July 2017 at 02:11:20 UTC, NoBigDeal256 wrote: it passes when it should fail because the unittest block is never executed. Why is this? Did you actually instantiate the class somewhere? A template has no concrete code unless created with an argument somewhere... Well shit that was the issue. My mistake, I should have thought of that, but it makes total sense now. What is the standard way of testing class templates in the context of a library where some of the classes may never actually be used by the library itself? I know I could just make a private module-level field declaration that just instantiates a template but that seems like an ugly way of handling it. Any suggestions on how you would handle this?
unittest blocks not being run inside of class and struct templates
For example this code:
class Test {
unittest {
assert(false);
}
}
fails when ran with dmd test.d -unittest like you'd expect. But
if I make it a class template:
class Test(T) {
unittest {
assert(false);
}
}
it passes when it should fail because the unittest block is never
executed. Why is this? While googling I found this thread
http://forum.dlang.org/thread/Xns98A859B0CD274pchapinsovernet@63.105.9.61 but surely that bug hasn't gone unfixed for 11 years...
Re: Having a strange issue with std.net.curl.HTTP as a struct dependency
On Monday, 10 July 2017 at 20:55:19 UTC, ketmar wrote: NoBigDeal256 wrote: Do you happen to have a link to the bug report for this specific issue that I could look at? I looked at the known bugs list and couldn't find anything related to this. nope. it is a kind of "known bug nobody bothered to report". ;-) Okay, so I decided to ditch curl and switch over to dlang-requests, which doesn't depend on curl, and I'm running into this same issue again... I don't think this is a curl issue.
Re: Having a strange issue with std.net.curl.HTTP as a struct dependency
On Monday, 10 July 2017 at 20:31:12 UTC, ketmar wrote: NoBigDeal256 wrote: I'm currently learning D and started working on one of my first projects which is an API wrapper. I'm currently having an issue with my program getting a InvalidMemoryOperationError upon exiting the process on Windows 7. On my Debian VM I get a segmentation fault. known bug in curl finalization on program exit. should be fixed in the next release. for now you have to live with it, or build your own phobos. Ah. It's interesting that it works perfectly fine when used directly in main, and only becomes an issue when it's a struct member. Do you happen to have a link to the bug report for this specific issue that I could look at? I looked at the known bugs list and couldn't find anything related to this.
Re: Having a strange issue with std.net.curl.HTTP as a struct dependency
Still haven't figured out what's wrong. Any help would be appreciated.
Having a strange issue with std.net.curl.HTTP as a struct dependency
I'm currently learning D and started working on one of my first
projects which is an API wrapper. I'm currently having an issue
with my program getting a InvalidMemoryOperationError upon
exiting the process on Windows 7. On my Debian VM I get a
segmentation fault.
I have tried to minimize the code as much as I possibly can while
still reproducing the error. Here is the code:
import std.net.curl;
struct ThingA {
HTTP http;
this(HTTP http) {
this.http = http;
arrayOfThingBs();
}
ThingB[] arrayOfThingBs() {
ThingB[] thingBs;
thingBs ~= ThingB(this);
return thingBs;
}
}
struct ThingB {
ThingA thingA;
this(ThingA thingA) {
this.thingA = thingA;
}
}
void main() {
auto http = HTTP();
auto thingA = ThingA(http);
}
If I comment out the HTTP dependency like:
struct ThingA {
//HTTP http;
this(HTTP http) {
//this.http = http;
arrayOfThingBs();
}
ThingB[] arrayOfThingBs() {
ThingB[] thingBs;
thingBs ~= ThingB(this);
return thingBs;
}
}
The error goes away. The error also goes away if
ThingA.arrayOfThingBs returns a single instance of ThingB instead
of an array of ThingB. Removing ThingBs dependency on ThingA also
gets rid of the error. I'm new to low level languages in general
so maybe I'm doing something wrong, but this seems like really
strange behavior.
