interrupting a function
I wished I never come across the nightmare of such a question. And maybe, there is still a bug in my code, which I'm not aware of (which I strongly suppose :/ ). But nevertheless, and for learning purposes, assume I have something like this: ´´´ auto foo(/*input params*/) { //some long calculations, depending on input params. } void main() { foo; } ´´´ It can happen, that the input params are correct, however, the calculation lasts too long. Is there a way, to measure the execution time of foo (á la benchmark) and then, if some execution time limit is exceeded to interrupt the calculation? At best, with a flag, whether foo ended normally or because of the interruption.
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 20:13:42 UTC, Vinay Sajip wrote: More complicated for the compiler writers, or users of mixins/generics? For users of generics. It's hard to come up with an actual example because I don't know why one would ever use this, but in this concocted scenario: ``` mixin template initRange() { typeof(this) front = typeof(this).init; enum empty = true; void popFront() {} } class A { mixin initRange; } class B : A { mixin initRange; } ``` The initRange template would need a static if to decide whether to add `override` or not. On Friday, 16 November 2018 at 20:13:42 UTC, Vinay Sajip wrote: But presumably making it an error would potentially be a breaking change? It would be breaking. The question is how much breakage there is of 'correct' hiding vs. how often unintended hiding leads to problems.
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 15:59:14 UTC, Vinay Sajip wrote: This code should IMO give at least a warning, but it doesn't: abstract class A { int kind; } [...] This is not unique to D you can do the same in Java or C++. bye, Norm
Re: what are the rules for @nogc and @safe attributes inference?
On Friday, 16 November 2018 at 12:12:12 UTC, Alex wrote: = This code compiles as long as `lazy` is commented out. But I'd like to have both lazy parameter and @nogc inferrence for `library_func` so that user is not locked to code @nogc or not. Aha, aha... Interesting! I had a similar problem with passing a delegate. And it was solved: https://forum.dlang.org/thread/erznqknpyxzxqivaw...@forum.dlang.org For your problem, there is a bug report: https://forum.dlang.org/post/wedwfooqdxbwxttpm...@forum.dlang.org https://issues.dlang.org/show_bug.cgi?id=12664 https://issues.dlang.org/show_bug.cgi?id=12647 Thanks for these links. And yes, I have workaround with handmade delegate. It compiles and it is lazy, but also ugly. import std.traits; T library_func(T)(/*not lazy*/ T i) if (!isCallable!T) { return i; } ReturnType!T library_func(T)(/*lazy*/ T i) if (isCallable!T) { return i(); } void user_function_nogc() @nogc { int x = 1; library_func(x+1); } void user_function_gc() { library_func(()=>[1]); } void main() { }
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 19:12:42 UTC, Dennis wrote: If something is definitively wrong, then it should be an error. If it's not definitively wrong, then the compiler shouldn't say anything about it, and it should be left up to a linter tool of some kind like dcd." https://forum.dlang.org/post/mailman.3986.1537881312.29801.digitalmar...@puremagic.com Thanks for that link, it helps to understand the thinking behind the way things are. The language design could be fixed by requiring the use of the `override` keyword like in C#. However, in D it *might* make generic code (with mixins) more complicated, though I personally have never found a use for hiding member variables so I don't know the rationale. More complicated for the compiler writers, or users of mixins/generics? In any case, the example I showed was more commonplace than mixins and templates. Perhaps the default should be to fail compilation with an error, and allow `override` when someone actually wants to hide/shadow members in base classes, for whatever reason. I suggested "warning" rather than "error" in the OP, because I didn't know the philosophy behind warnings in D that you've now made me aware of. But presumably making it an error would potentially be a breaking change?
Re: Not able to load classes defined in archive file in Mac OSX using Object.factory
On Friday, 16 November 2018 at 14:55:52 UTC, Aditya wrote: How can one write own factory function ? Any pointers to this ? Something like Interface delegate()[string] factories; Interface create(string className) { if(className in factories) return factories[classname]; else return null; // or throw if you prefer } In every module in which you create a class, you will want to add code like this: class Class : Interface {} // register with the factory in a module constructor static this() { factories["Class"] = Interface delegate() { return new Class(); } } And it should work.
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 18:37:00 UTC, Vinay Sajip wrote: Design flaws in what? Design flaws in the language. Quoting Jonathan M Davis: "Honestly, in general, warnings are a terrible idea. Anything that's a warning in your code has to be fixed, because it's bad practice to leave warnings in your code, meaning that ultimately, there's not much difference between a warning and an error. To make matters worse, there's a compiler flag that turns warnings into errors. And when you combine that with stuff like is(typeof(...)) and template constraints, whether you use that compiler flag or not could actually change the resulting program. So, as it stands, warnings are an even worse idea in D than they are in other languages. Walter likes to talk about how warnings in C/C++ are there simply because folks couldn't agree on what should or shouldn't be an error in the language. If something is definitively wrong, then it should be an error. If it's not definitively wrong, then the compiler shouldn't say anything about it, and it should be left up to a linter tool of some kind like dcd." https://forum.dlang.org/post/mailman.3986.1537881312.29801.digitalmar...@puremagic.com The language design could be fixed by requiring the use of the `override` keyword like in C#. However, in D it *might* make generic code (with mixins) more complicated, though I personally have never found a use for hiding member variables so I don't know the rationale.
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 17:35:13 UTC, Basile B. wrote: D is not a compiler that warns much. You can still open an issue asking for this (and the warning must be easy to add at first glance), but the policy applied to warnings is "compilers warnings are a sign of design flaws so instead of emitting one we should rather fix the flaw". Design flaws in what? In this case, the flaw was in my code, but I would expect some help from the compiler in catching such an ambiguity, and so fixing the flaw in my code. That it didn't try to help me might itself be considered a design flaw in the compiler ;-)
Re: Compile time code generation
On 11/16/18 12:10 PM, boolangery wrote: Hi, Is something like this is doable ? --- // all compile time MapperGen.Create!(A, B) .Map!("p1", "p2") .Map!("myprop", "otherprop") .Gen(); // The code above must generate something like // // class Mapper { // B map(A value) { // B ret = new B(); // ret.p1 = value.p2; // ret.myprop = p2.otherprop; // return ret; // } // } // runtime use auto b = new Mapper().map(new A()); --- I can't figure out how to concatenate string at runtime and the mixin the resulting string?. I'm not understanding what you are trying to do, but to answer your question, you can only mixin a string generated at compile time. However, you can concatenate a string at runtime inside a CTFE-able function, and then mixin the result. Example: string foo(string[] fields...) { string result = "struct Foo {"; foreach(f; fields) result ~= "int " ~ f ~ ";"; return result ~ "}"; } mixin(foo()); // generate the struct -Steve
Re: subsystem:windows and writeln
On Friday, 16 November 2018 at 17:49:06 UTC, Domain wrote: But I cannot control the 3rd library! Hmm, I see. So one possibility would be to reopen stdout (and maybe stderr) to a different file. stdout.reopen("log.txt", "wt"); when you start your program and before you call the library and it should no longer error - unless it can't create the file. Then you can look at the file if you do need the output.
Re: subsystem:windows and writeln
BTW if you just want to ditch the output, you might be able to use "NUL" as the file name. I havent' tried tho.
Re: subsystem:windows and writeln
On Friday, 16 November 2018 at 17:46:20 UTC, Adam D. Ruppe wrote: On Friday, 16 November 2018 at 17:36:01 UTC, Domain wrote: I think this is unacceptable. Why? You are asking it to write to a file that doesn't exist... you probably shouldn't be doing that... But I cannot control the 3rd library!
Re: subsystem:windows and writeln
On Friday, 16 November 2018 at 17:36:01 UTC, Domain wrote: I think this is unacceptable. Why? You are asking it to write to a file that doesn't exist... you probably shouldn't be doing that...
subsystem:windows and writeln
When I link the app with /subsystem:windows, and all writeln and writefln will cause a enforcement failed (stdio.d:2889). I think this is unacceptable.
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 17:28:15 UTC, Vinay Sajip wrote: On Friday, 16 November 2018 at 17:08:00 UTC, Basile B. wrote: I agree that this is almost a case of shadowing but i don't know the exact rationale for allowing this. I'm not saying it shouldn't be allowed - just that the compiler could warn you about what might very well be a mistake (as it was in my case) - hard to debug with printf debugging, and source level debug for D is a bit thin on the ground, ISTM. D is not a compiler that warns much. You can still open an issue asking for this (and the warning must be easy to add at first glance), but the policy applied to warnings is "compilers warnings are a sign of design flaws so instead of emitting one we should rather fix the flaw".
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 17:08:00 UTC, Basile B. wrote: I agree that this is almost a case of shadowing but i don't know the exact rationale for allowing this. I'm not saying it shouldn't be allowed - just that the compiler could warn you about what might very well be a mistake (as it was in my case) - hard to debug with printf debugging, and source level debug for D is a bit thin on the ground, ISTM.
Compile time code generation
Hi, Is something like this is doable ? --- // all compile time MapperGen.Create!(A, B) .Map!("p1", "p2") .Map!("myprop", "otherprop") .Gen(); // The code above must generate something like // // class Mapper { // B map(A value) { // B ret = new B(); // ret.p1 = value.p2; // ret.myprop = p2.otherprop; // return ret; // } // } // runtime use auto b = new Mapper().map(new A()); --- I can't figure out how to concatenate string at runtime and the mixin the resulting string?. Thanks in advance !
Re: Fields with the same name not causing a warning?
On Friday, 16 November 2018 at 15:59:14 UTC, Vinay Sajip wrote: This code should IMO give at least a warning, but it doesn't: abstract class A { int kind; } class B : A { int kind; this(int k) { kind = k; } } In my actual code, the declaration of field "kind" in B was left in accidentally. Surprisingly, however, no warning was emitted when I compiled this, leading to B having two fields called kind which are distinct from one another. The complete program import std.stdio; abstract class A { int kind; } class B : A { int kind; this(int k) { kind = k; } } void main() { auto b = new B(4); A a = b; writeln(b.kind); writeln(a.kind); } prints 4 0 Given that this is the kind of thing that is easily done, surely the default behaviour should be for the compiler to emit at least a warning that field "kind" is ambiguous in B? This behaviour occurs even when the field is declared as "public" or "protected" in both classes. What am I missing? When you re declare with the same name in a sub class each generation has its own variable. To distinguish you can use the type for which you want "kind": writeln(b.A.kind); // the one from A writeln(b.B.kind); // the one from B I agree that this is almost a case of shadowing but i don't know the exact rationale for allowing this.
Re: Not able to load classes defined in archive file in Mac OSX using Object.factory
On Friday, 16 November 2018 at 14:55:52 UTC, Aditya wrote: On Friday, 16 November 2018 at 14:30:02 UTC, Adam D. Ruppe wrote: PS object.factory sucks and I hope it is removed some day. There's no plan to do so, but I still wouldn't actually rely on it... instead, I'd write your own factory function and registration system, so you control it and will have reliability to your specific needs. but still if the factory works for you, eh, you can use it. How can one write own factory function ? Any pointers to this ? Thanx for learning purpose you can make very simply a factory function based on string comparison. Object simpleFactory(string className) { import the_module_where_stuff_is_declared; import the_module_where_thing_is_declared; if (className == "Stuff") return new Stuff; else if if (className == "Thing") return new Thing; // and so on else return null; } although this requires imports so the command line for building should include more path using the "-I" cmd line switch. I propose this solution because making a true factory might be too complicated if you just start learning D.
Re: Not able to load classes defined in archive file in Mac OSX using Object.factory
On 11/16/18 9:51 AM, Aditya wrote: On Friday, 16 November 2018 at 14:28:22 UTC, Adam D. Ruppe wrote: On Friday, 16 November 2018 at 14:24:10 UTC, Aditya wrote: ./ss/Stat.d (defines interface named 'Stat') ./ss/Min.d (defines class named 'Min' that implements Stat) Did you put a module declaration at the top of those files? Like module ss.Stat; That ought to be required; the compiler lets you skip it, but it doesn't work reliably without it once you start importing the module or other similar things. But once you have that, the name of your class will be the full name with module, so like if min has module ss.Min; class Min {} the full class name will be ss.Min.Min the full module name dot the full class name. Module Names were not added. But after adding the same, still same result. // Following still doesn't work ss.Min.Min ss.ss.Min ss.ss.Min.Min stats.ss.Min.Min stats.Min So to let you know, Object.factory is not a maintained function. The ability to instantiate classes based on the ModuleInfo was overruled by the fact that we don't want to generate ModuleInfo if we don't have to, and it should be as small as possible. Therefore, you need some triggers to make sure the module info is included, and even then, I think, it's not guaranteed to include the classinfo in that moduleinfo. The better path is to use a registration system to add the desired classes for reflection. Not a trivial thing, but that's probably the path you want. I'd suggest looking at serialization libraries like orange (http://code.dlang.org/packages/orange) or cereald (http://code.dlang.org/packages/cerealed) for ideas, or maybe just use one of them. -Steve
Fields with the same name not causing a warning?
This code should IMO give at least a warning, but it doesn't: abstract class A { int kind; } class B : A { int kind; this(int k) { kind = k; } } In my actual code, the declaration of field "kind" in B was left in accidentally. Surprisingly, however, no warning was emitted when I compiled this, leading to B having two fields called kind which are distinct from one another. The complete program import std.stdio; abstract class A { int kind; } class B : A { int kind; this(int k) { kind = k; } } void main() { auto b = new B(4); A a = b; writeln(b.kind); writeln(a.kind); } prints 4 0 Given that this is the kind of thing that is easily done, surely the default behaviour should be for the compiler to emit at least a warning that field "kind" is ambiguous in B? This behaviour occurs even when the field is declared as "public" or "protected" in both classes. What am I missing?
Re: Not able to load classes defined in archive file in Mac OSX using Object.factory
On Friday, 16 November 2018 at 14:30:02 UTC, Adam D. Ruppe wrote: PS object.factory sucks and I hope it is removed some day. There's no plan to do so, but I still wouldn't actually rely on it... instead, I'd write your own factory function and registration system, so you control it and will have reliability to your specific needs. but still if the factory works for you, eh, you can use it. How can one write own factory function ? Any pointers to this ? Thanx
Re: Not able to load classes defined in archive file in Mac OSX using Object.factory
On Friday, 16 November 2018 at 14:28:22 UTC, Adam D. Ruppe wrote: On Friday, 16 November 2018 at 14:24:10 UTC, Aditya wrote: ./ss/Stat.d (defines interface named 'Stat') ./ss/Min.d (defines class named 'Min' that implements Stat) Did you put a module declaration at the top of those files? Like module ss.Stat; That ought to be required; the compiler lets you skip it, but it doesn't work reliably without it once you start importing the module or other similar things. But once you have that, the name of your class will be the full name with module, so like if min has module ss.Min; class Min {} the full class name will be ss.Min.Min the full module name dot the full class name. Module Names were not added. But after adding the same, still same result. // Following still doesn't work ss.Min.Min ss.ss.Min ss.ss.Min.Min stats.ss.Min.Min stats.Min
Re: Not able to load classes defined in archive file in Mac OSX using Object.factory
PS object.factory sucks and I hope it is removed some day. There's no plan to do so, but I still wouldn't actually rely on it... instead, I'd write your own factory function and registration system, so you control it and will have reliability to your specific needs. but still if the factory works for you, eh, you can use it.
Re: Not able to load classes defined in archive file in Mac OSX using Object.factory
On Friday, 16 November 2018 at 14:24:10 UTC, Aditya wrote: ./ss/Stat.d (defines interface named 'Stat') ./ss/Min.d (defines class named 'Min' that implements Stat) Did you put a module declaration at the top of those files? Like module ss.Stat; That ought to be required; the compiler lets you skip it, but it doesn't work reliably without it once you start importing the module or other similar things. But once you have that, the name of your class will be the full name with module, so like if min has module ss.Min; class Min {} the full class name will be ss.Min.Min the full module name dot the full class name.
Not able to load classes defined in archive file in Mac OSX using Object.factory
Hello ! I am trying to work out "The D programming Language" chapter 1.6 problem on Interfaces and Classes. folder ./stats.d(takes argument "Min/Max" on command line and loads them) ./ss/Stat.d (defines interface named 'Stat') ./ss/Min.d (defines class named 'Min' that implements Stat) $ dmd -lib -g ss/*.d -of=ss.a $ dmd -g stats.d ss.a $ echo 3 5 1.3 4 10 4.5 1 5 | stats Min object.Exception@stats.d(19): Invalid statistics function: Min Code for stats.d - import std.exception, std.stdio; import ss.Stat; // works !! void main(string[] args){ Stat[] stats; foreach (arg; args[1 .. $]) { // Doesn't work // string path = "stats." ~ arg ~ "." ~ arg; // string path = "stats." ~ arg; // string path = "stats.ss." ~ arg; // string path = "stats.ss." ~ arg ~ "." ~ arg; // string path = "ss." ~ arg; // string path = "ss." ~ arg ~ "." ~ arg; // string path = arg ~ "." ~ arg; // string path = arg; // string path = "stats.ss." ~ arg ~ "." ~ arg; string path = arg; auto newStat = cast(Stat) Object.factory(path); enforce(newStat, "Invalid statistics function: " ~ path); stats ~= newStat; } } What is the path for Min class defined in Min.d inside ./ss folder that is compiled into ss.a ? Thanks Aditya
Re: Sorting a subrange
On Friday, 16 November 2018 at 12:08:33 UTC, Stanislav Blinov wrote: import std.range.primitives : isRandomAccessRange; auto sortSubRange(R)(R range, size_t i, size_t j) if (isRandomAccessRange!R) { import std.algorithm.sorting : topN, partialSort; size_t start = i; if (i != 0) { topN(range, i); start++; } partialSort(range[start .. $], j-start); return range[i .. j]; } Wonderful!
Re: How do you debug @safe @nogc code? Can't figure out how to print.
On Friday, 16 November 2018 at 12:59:22 UTC, aliak wrote: Adding @trusted to declaration of opDispatch gets rid of @safe error but I still get "Error: @nogc function D main cannot call non-@nogc function". And going through the codebase and figuring out where to add @trusted is *very* cumbersome. I can't figure out how to make this work. The ideal way would be just a debug_print() function that works in nogc and safe code. I.e. does not affect the attribute inference of templates. As Zoadian points out, you can now (since 2.079: https://dlang.org/changelog/2.079.0.html#bugfix-list) shamelessly call @nogc inside debug blocks. To get at where the problematic areas were in the code in question though, it's as follows: auto assumeNoGC(T)(T t) { // point 1 import std.traits; enum attrs = functionAttributes!T | FunctionAttribute.nogc; // point 2: return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t; } At 'point 1', you just take by value. If `t` ends up being a closure, D will allocate. That's where it breaks the @nogc. Solution: auto assumeNoGC(T)(return scope T t) { /* ... */ } Now you take (and return) a `scope` t, in that case when `t` is a closure D won't allocate it on the GC heap. At 'point 2' you make an un-@safe cast, that's where it breaks @safe. Given that the whole deal is just a debugging hack, you could mark the whole function @trusted: auto assumeNoGC(T)(return scope T t) @trusted { /* ... */ }
Re: How do you debug @safe @nogc code? Can't figure out how to print.
debug { import std.stdio; writeln(args); }
How do you debug @safe @nogc code? Can't figure out how to print.
Hi, I previously had trouble trying to get print statements working while debugging in nogc. And that was hackishly solved [0], but I can't figure out how to do the same if I have @safe involved. Here's a cut down sample: // This is the function from the thread referenced auto assumeNoGC(T)(T t) { import std.traits; enum attrs = functionAttributes!T | FunctionAttribute.nogc; return cast(SetFunctionAttributes!(T, functionLinkage!T, attrs)) t; } private struct Dispatcher { public template opDispatch(string name){ auto ref opDispatch(Args...)(auto ref Args args) { import std.stdio; // Print args here for debugging purposes assumeNoGC({ writeln(args); })(); return 3; } } } @safe @nogc void main() { auto i = Dispatcher().getI(3); } So, basically with the above, using: debug writeln(args); Causes "Error: @nogc function D main cannot call non-@nogc function" Using: debug assumeNoGC({ writeln(args); })(); Causes: Error: @safe function D main cannot call @system function Error: @nogc function D main cannot call non-@nogc function Changing attrs in assumeNoGC enum attrs = functionAttributes!T | FunctionAttribute.nogc | FunctionAttribute.safe Causes same as previous errors Adding @trusted to declaration of opDispatch gets rid of @safe error but I still get "Error: @nogc function D main cannot call non-@nogc function". And going through the codebase and figuring out where to add @trusted is *very* cumbersome. I can't figure out how to make this work. The ideal way would be just a debug_print() function that works in nogc and safe code. I.e. does not affect the attribute inference of templates. Cheers, - Ali [0] https://forum.dlang.org/post/pmf4dm$jmo$1...@digitalmars.com
Re: what are the rules for @nogc and @safe attributes inference?
On Friday, 16 November 2018 at 10:25:26 UTC, ikod wrote: On Thursday, 15 November 2018 at 21:55:18 UTC, Steven Schveighoffer wrote: On 11/15/18 4:09 PM, Adam D. Ruppe wrote: On Thursday, 15 November 2018 at 21:00:48 UTC, ikod wrote: what are the rules for @nogc inference? It attempts it if and only if it is a template. Well, the general "rule" is, if it's code that must be available to the compiler when it's called, then it will be inferred. Examples of code that must be processed every time it's used: 1. Template functions 2. auto-returning functions 3. functions inside templates (like member functions of a templated struct) 4. Inner functions There may be others I didn't think of. Everything else must be manually attributed. The reasoning is that the function may be stubbed in a .di file, and in that case, attribute inference wouldn't be possible. -Steve Thanks for clarifications, Adam and Steven! My problem is next code: = import std.traits; T library_func(T)(/*lazy*/ T i) { // this fuction can be @nogc or not depending on T properties static if (isArray!T) { return i ~ i; } else { return i; } } void user_function_nogc() @nogc { int x = 1; library_func(x+1); } void user_function_gc() { library_func([1]); } void main() { } = This code compiles as long as `lazy` is commented out. But I'd like to have both lazy parameter and @nogc inferrence for `library_func` so that user is not locked to code @nogc or not. Aha, aha... Interesting! I had a similar problem with passing a delegate. And it was solved: https://forum.dlang.org/thread/erznqknpyxzxqivaw...@forum.dlang.org For your problem, there is a bug report: https://forum.dlang.org/post/wedwfooqdxbwxttpm...@forum.dlang.org https://issues.dlang.org/show_bug.cgi?id=12664 https://issues.dlang.org/show_bug.cgi?id=12647
Re: Sorting a subrange
On Friday, 16 November 2018 at 11:24:20 UTC, Per Nordlöw wrote: /** Sort sub-range [sub_begin, sub_end] of [begin, end]. * * Describe at https://www.youtube.com/watch?v=0WlJEz2wb8Y=2686s */ template// I models RandomAccessIterator void sort_subrange(I begin, I end, I sub_begin, I sub_end) { if (sub_begin == sub_end) { return; } if (sub_begin != begin) { std::nth_element(begin, sub_begin, end); ++sub_begin; } std::partial_sort(sub_begin, sub_begin, end); } Back-of-the-envelope translation (probably some error checking would be in order): import std.range.primitives : isRandomAccessRange; auto sortSubRange(R)(R range, size_t i, size_t j) if (isRandomAccessRange!R) { import std.algorithm.sorting : topN, partialSort; size_t start = i; if (i != 0) { topN(range, i); start++; } partialSort(range[start .. $], j-start); return range[i .. j]; } void main() { auto x = [1,2,7,4,2,6,8,3,9,3]; auto y = sortSubRange(x, 3, 6); import std.stdio; writeln(y); // 3, 3, 4 writeln(x); // ex. 2, 2, 1, 3, 3, 4, 6, 7, 9, 8 }
Sorting a subrange
How do I sort a subrange of a range `x` where the subrange is defined by a lower and upper (in this case exlusive) element contained within `x`? auto x = [1,2,7,4,2,6,8,3,9,3]; auto y = sortSubRange(x, 3,5]; should yield `y` being [3,3,4] and `x` being [a ,3,3,4, b] where - a contains the elements 1,2,2 in some undefined order and - b contains the elements 6,7,8,9 in some undefined order . Algorithm was highlighted in C++ at https://www.youtube.com/watch?v=0WlJEz2wb8Y=1719s as /** Sort sub-range [sub_begin, sub_end] of [begin, end]. * * Describe at https://www.youtube.com/watch?v=0WlJEz2wb8Y=2686s */ template// I models RandomAccessIterator void sort_subrange(I begin, I end, I sub_begin, I sub_end) { if (sub_begin == sub_end) { return; } if (sub_begin != begin) { std::nth_element(begin, sub_begin, end); ++sub_begin; } std::partial_sort(sub_begin, sub_begin, end); }
Re: what are the rules for @nogc and @safe attributes inference?
On Thursday, 15 November 2018 at 21:55:18 UTC, Steven Schveighoffer wrote: On 11/15/18 4:09 PM, Adam D. Ruppe wrote: On Thursday, 15 November 2018 at 21:00:48 UTC, ikod wrote: what are the rules for @nogc inference? It attempts it if and only if it is a template. Well, the general "rule" is, if it's code that must be available to the compiler when it's called, then it will be inferred. Examples of code that must be processed every time it's used: 1. Template functions 2. auto-returning functions 3. functions inside templates (like member functions of a templated struct) 4. Inner functions There may be others I didn't think of. Everything else must be manually attributed. The reasoning is that the function may be stubbed in a .di file, and in that case, attribute inference wouldn't be possible. -Steve Thanks for clarifications, Adam and Steven! My problem is next code: = import std.traits; T library_func(T)(/*lazy*/ T i) { // this fuction can be @nogc or not depending on T properties static if (isArray!T) { return i ~ i; } else { return i; } } void user_function_nogc() @nogc { int x = 1; library_func(x+1); } void user_function_gc() { library_func([1]); } void main() { } = This code compiles as long as `lazy` is commented out. But I'd like to have both lazy parameter and @nogc inferrence for `library_func` so that user is not locked to code @nogc or not.
Re: Writing Postgresql extension in D
On Friday, 16 November 2018 at 02:18:11 UTC, Ranjan wrote: On Thursday, 15 November 2018 at 17:03:55 UTC, Andrea Fontana wrote: On Thursday, 15 November 2018 at 13:05:59 UTC, Ranjan wrote: This is my first time on the Dlang forum. I like the language but my usecase is a bit different. I want to write Postgresql extension in D. Currently extension can be written in C or C linked languages. Has anyone done this or can point me to some code. Thanks Did you read this: https://dlang.org/spec/interfaceToC.html ? Andrea Yes, but it's not useful, in Postgesql extension C code needs to call D, without GarbageCollection. I am able to do this in RustLang but I am not sure how to in D, as it has a GC. Looking for examples from the community. Thanks I'm not an exert with C nor D. So I might misuderstand the issue... You can write a skeleton plugin for postgres in C that at init time starts the D runtime. From then on your C skelton plugin can call some function in D.