Re: Filter for opDispatch?

2021-05-15 Thread frame via Digitalmars-d-learn
On Sunday, 16 May 2021 at 04:38:52 UTC, Mike Parker wrote: On Sunday, 16 May 2021 at 04:07:15 UTC, frame wrote: But the same with fields work? They are also protected. I'm not sure what you mean by "fields" here. ```d protected: // inaccessible /* void s(int v) { _s = v; } int s() {

Re: Filter for opDispatch?

2021-05-15 Thread Mike Parker via Digitalmars-d-learn
On Sunday, 16 May 2021 at 04:07:15 UTC, frame wrote: But the same with fields work? They are also protected. I'm not sure what you mean by "fields" here.

Re: Filter for opDispatch?

2021-05-15 Thread frame via Digitalmars-d-learn
On Sunday, 16 May 2021 at 03:19:04 UTC, Mike Parker wrote: On Sunday, 16 May 2021 at 00:04:39 UTC, frame wrote: Yes, but why should the derived class not have access to it? I don't think that's your problem. From the template docs: _TemplateInstances_ are always instantiated in the scope

Re: Filter for opDispatch?

2021-05-15 Thread Mike Parker via Digitalmars-d-learn
On Sunday, 16 May 2021 at 00:04:39 UTC, frame wrote: Yes, but why should the derived class not have access to it? I don't think that's your problem. From the template docs: _TemplateInstances_ are always instantiated in the scope of where the _TemplateDeclaration_ is declared... Your

Re: Filter for opDispatch?

2021-05-15 Thread Paul Backus via Digitalmars-d-learn
On Sunday, 16 May 2021 at 00:04:39 UTC, frame wrote: On Saturday, 15 May 2021 at 23:59:49 UTC, Paul Backus wrote: Does it work if you remove `protected` from the derived class? Yes, but why should the derived class not have access to it? Possibly because you're accessing it from an

Re: ugly and/or useless features in the language.

2021-05-15 Thread zjh via Digitalmars-d-learn
I want to be able to support CP936, not just UTF8. I can't use CP936. It's my pet peeve. Hopefully we can solve the coding problem just like Python with #encoding= GBK.

Re: Filter for opDispatch?

2021-05-15 Thread frame via Digitalmars-d-learn
On Saturday, 15 May 2021 at 23:59:49 UTC, Paul Backus wrote: On Saturday, 15 May 2021 at 23:41:19 UTC, frame wrote: On Friday, 14 May 2021 at 23:02:22 UTC, frame wrote: Thanks! I stumbled around with static asserts and mixins... totally forgot about the constraints but they will to the

Re: Filter for opDispatch?

2021-05-15 Thread Paul Backus via Digitalmars-d-learn
On Saturday, 15 May 2021 at 23:41:19 UTC, frame wrote: On Friday, 14 May 2021 at 23:02:22 UTC, frame wrote: Thanks! I stumbled around with static asserts and mixins... totally forgot about the constraints but they will to the trick. Now I run into the error "class Foo member s is not

Re: Filter for opDispatch?

2021-05-15 Thread frame via Digitalmars-d-learn
On Friday, 14 May 2021 at 23:02:22 UTC, frame wrote: Thanks! I stumbled around with static asserts and mixins... totally forgot about the constraints but they will to the trick. Now I run into the error "class Foo member s is not accessible" "template instance Base.opDispatch!("s", int, Foo)

Re: ugly and/or useless features in the language.

2021-05-15 Thread Ola Fosheim Grostad via Digitalmars-d-learn
On Saturday, 15 May 2021 at 14:31:08 UTC, Alain De Vos wrote: Feature creep can make your own code unreadable. Having many ways to express the same concept makes code harder to read. This is an issue in C++, but you can combat it by creating coding norms. In general it is better to have

Re: struct destructor

2021-05-15 Thread mw via Digitalmars-d-learn
On Saturday, 15 May 2021 at 18:26:08 UTC, Adam D. Ruppe wrote: On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote: Feature request, a function old which does the opposite of new, allowing deterministic,real-time behavior and memory conservation. You're best off doing malloc+free if

Re: struct destructor

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
I'll try first the first tip of Adam, here the code, ``` import std.stdio:writeln; import core.memory: GC; void myfun(){ class C{ int[1] x; }//class C struct S { C c=null; @disable this(); this(int dummy) { c=new C();

Re: struct destructor

2021-05-15 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote: Feature request, a function old which does the opposite of new, allowing deterministic,real-time behavior and memory conservation. You're best off doing malloc+free if you want complete control though.

Re: struct destructor

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
Sorry free does , indeed.

Re: struct destructor

2021-05-15 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 15 May 2021 at 18:15:24 UTC, Dennis wrote: On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote: Feature request, a function old which does the opposite of new, allowing deterministic,real-time behavior and memory conservation. You can use

Re: struct destructor

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
Thanks, good idea but, It does not initiate a GC cycle or free any GC memory.

Re: struct destructor

2021-05-15 Thread Dennis via Digitalmars-d-learn
On Saturday, 15 May 2021 at 17:55:17 UTC, Alain De Vos wrote: Feature request, a function old which does the opposite of new, allowing deterministic,real-time behavior and memory conservation. You can use [object.destroy](https://dlang.org/phobos/object.html#.destroy) to destruct, and

Re: struct destructor

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
Feature request, a function old which does the opposite of new, allowing deterministic,real-time behavior and memory conservation.

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 15 May 2021 at 13:46:57 UTC, Chris Piker wrote: I'm trying to do that, but range3 and range2 are written by me not a Phobos wizard, and there's a whole library of template functions a person needs to learn to make their own pipelines. For example: Phobos has plenty of design

Re: struct destructor

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
On Saturday, 15 May 2021 at 16:53:04 UTC, Adam D. Ruppe wrote: On Saturday, 15 May 2021 at 16:52:10 UTC, Alain De Vos wrote: When I do a "new" in a struct constructor to assign to a member variable of this struct, what do i write in the same struct destructor to free the memory ? If you

struct destructor

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
When I do a "new" in a struct constructor to assign to a member variable of this struct, what do i write in the same struct destructor to free the memory ?

Re: struct destructor

2021-05-15 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 15 May 2021 at 16:52:10 UTC, Alain De Vos wrote: When I do a "new" in a struct constructor to assign to a member variable of this struct, what do i write in the same struct destructor to free the memory ? If you used `new` the garbage collector is responsible for it.

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Ali Çehreli via Digitalmars-d-learn
On 5/15/21 4:25 AM, Chris Piker wrote: > But, loops are bad. I agree with Adam here. Although most of my recent code gravitates towards long range expressions, I use 'foreach' (even 'for') when I think it makes code more readable. > Is there some obvious trick or way of looking at the

ugly and/or useless features in the language.

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
Which parts in dlang don't you use and why ? Personally i have no need for enum types, immutable is doing fine. Auto return types i find dangerous to use. Voldermont types. Named initialiser. Tuple features. Maybe some other ? Feature creep can make your own code unreadable. Offcourse taste can

Re: Scope of import

2021-05-15 Thread DLearner via Digitalmars-d-learn
On Saturday, 15 May 2021 at 11:38:22 UTC, Adam D. Ruppe wrote> Just use ``` dmd -i main.d instead. It will be about 2x faster and more reliable. ``` Your suggestion worked. Thank you.

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Chris Piker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 14:05:34 UTC, Paul Backus wrote: If you post your code (or at least a self-contained subset of it) someone can probably help you figure out where you're running into trouble. Smart idea. It's all on github. I'll fix a few items and send a link soon as I get a

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Chris Piker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 13:43:29 UTC, Mike Parker wrote: On Saturday, 15 May 2021 at 11:25:10 UTC, Chris Piker wrote: In addition to what Adam said, if you do need to store the result for use in a friendlier form, just import `std.array` and append `.array` to the end of the pipeline.

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Paul Backus via Digitalmars-d-learn
On Saturday, 15 May 2021 at 13:46:57 UTC, Chris Piker wrote: Every time I slightly change the inputs to range2, then a function that operates on *range3* output types blows up with a helpful message similar to: [snip] If you post your code (or at least a self-contained subset of it)

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 11:25:10 UTC, Chris Piker wrote: Thanks for your patience with a potentially dumb question. I've been working on the code for well over 12 hours so I'm probably not thinking straight it this point. BTW, I can send you a couple of documents regarding ranges that

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Chris Piker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 11:51:11 UTC, Adam D. Ruppe wrote: On Saturday, 15 May 2021 at 11:25:10 UTC, Chris Piker wrote: The idea is you aren't supposed to care what the type is, just what attributes it has, e.g., can be indexed, or can be assigned, etc. (Warning, new user rant ahead.

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 11:25:10 UTC, Chris Piker wrote: Is there some obvious trick or way of looking at the problem that I'm missing? In addition to what Adam said, if you do need to store the result for use in a friendlier form, just import `std.array` and append `.array` to the

Re: Scope of import

2021-05-15 Thread Alain De Vos via Digitalmars-d-learn
In unix i give the compiler: ``` ldc2 `find . -name \*.d -print` ``` So he always takes all sourcefiles

Re: Scope of import

2021-05-15 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 15 May 2021 at 11:46:49 UTC, Dennis wrote: You can do `dmd -i -run main.d` Yeah but that's weird with how it handles arguments and without the compilation cache it gets really annoying to use.

Re: Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 15 May 2021 at 11:25:10 UTC, Chris Piker wrote: Then the type definition of mega_range is something in the order of: The idea is you aren't supposed to care what the type is, just what attributes it has, e.g., can be indexed, or can be assigned, etc. You'd want to do it all in

Re: Scope of import

2021-05-15 Thread Dennis via Digitalmars-d-learn
On Saturday, 15 May 2021 at 11:38:22 UTC, Adam D. Ruppe wrote: * rdmd runs the program too, dmd -i just compiles. You run the program separately. You can do `dmd -i -run main.d`

Re: Scope of import

2021-05-15 Thread Adam D. Ruppe via Digitalmars-d-learn
On Saturday, 15 May 2021 at 07:15:51 UTC, DLearner wrote: rdmd main.d rdmd sucks, it runs the compiler twice and get the list of imports and even then it might not see them all. Just use dmd -i main.d instead. It will be about 2x faster and more reliable. The downside differences though:

Recommendations on avoiding range pipeline type hell

2021-05-15 Thread Chris Piker via Digitalmars-d-learn
Hi D Since the example of piping the output of one range to another looked pretty cool, I've tried my own hand at it for my current program, and the results have been... sub optimal. Basically the issue is that if one attempts to make a range based pipeline aka: ```d auto mega_range =

Re: Any suggestions on dmd error message formatting?

2021-05-15 Thread SealabJaster via Digitalmars-d-learn
On Saturday, 15 May 2021 at 09:09:36 UTC, Berni44 wrote: ... Honestly, even having a dumb formatter that puts things like this would be 100x more useable than what we currently get: ```d das2.range.PriorityRange!( DasRange!( Take!( ZipShortest!( cast(Flag)false, Result,

Re: What is the difference between these template declaration forms?

2021-05-15 Thread evilrat via Digitalmars-d-learn
On Saturday, 15 May 2021 at 08:37:21 UTC, cc wrote: Are these identical? Or is there a different usage for the (T : something) form? ```d auto opCast(T)() if (is(T == bool)) { return _obj !is null; } ``` They are the same in this case. ```d auto

Re: Any suggestions on dmd error message formatting?

2021-05-15 Thread SealabJaster via Digitalmars-d-learn
On Saturday, 15 May 2021 at 08:15:19 UTC, Chris Piker wrote: I did much the same as you and reformatted the error message to find the bug. As to the larger question of how to automatically process compiler output... got any ideas? Hope someone who knows how to modify DMD bothers to: 1.

Re: Any suggestions on dmd error message formatting?

2021-05-15 Thread Berni44 via Digitalmars-d-learn
On Saturday, 15 May 2021 at 04:54:15 UTC, Chris Piker wrote: As always, your advice is much appreciated I'm usually piping the results through hexdump. ;-) No, in earnest, I often would have liked to have better formatted messages. The only thing I can say: Sometimes it helps to increase

What is the difference between these template declaration forms?

2021-05-15 Thread cc via Digitalmars-d-learn
Are these identical? Or is there a different usage for the (T : something) form? ```d auto opCast(T)() if (is(T == bool)) { return _obj !is null; } ``` ```d auto opCast(T : bool)() { return _obj !is null; } ```

Re: Any suggestions on dmd error message formatting?

2021-05-15 Thread Chris Piker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 06:12:25 UTC, SealabJaster wrote: On Saturday, 15 May 2021 at 04:54:15 UTC, Chris Piker wrote: T_T My eyes burn. Good, it's not just me. If figured the Deities out there visually parse these messages even hung over. Seems the final `int function` parameter

Re: Scope of import

2021-05-15 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 07:15:51 UTC, DLearner wrote: On Saturday, 15 May 2021 at 07:05:00 UTC, Mike Parker wrote: That's odd. What's your command line? rdmd main.d Okay, so it's definitely a bug in rdmd. Change module A to look like this and it works properly: ```d module A;

Re: Scope of import

2021-05-15 Thread DLearner via Digitalmars-d-learn
On Saturday, 15 May 2021 at 07:19:08 UTC, Mike Parker wrote: Then it must be an issue with rdmd... rdmd build 20210311 Running under Win-10.

Re: Scope of import

2021-05-15 Thread DLearner via Digitalmars-d-learn
On Saturday, 15 May 2021 at 07:05:00 UTC, Mike Parker wrote: That's odd. What's your command line? rdmd main.d

Re: Scope of import

2021-05-15 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 07:15:51 UTC, DLearner wrote: On Saturday, 15 May 2021 at 07:05:00 UTC, Mike Parker wrote: That's odd. What's your command line? rdmd main.d Then it must be an issue with rdmd. The following both work as expected, whether your the `import B;` in `main` is

Re: Scope of import

2021-05-15 Thread Mike Parker via Digitalmars-d-learn
On Saturday, 15 May 2021 at 06:55:47 UTC, DLearner wrote: 1. Code above compiles but fails on linker step with 'Error 42 Symbol Undefined'. To me, unexpected behaviour as imports arranged to pick up symbols (with minimum scope). Your error is a linker error. Imports have nothing to do with

Scope of import

2021-05-15 Thread DLearner via Digitalmars-d-learn
``` // main void main() { import A; // import B; import std.stdio; writeln("Entered main"); fnA1(); writeln("Leaving main"); } ``` ``` module A; void fnA1() { import B; import std.stdio; writeln("Entered fnA1"); fnB1(); writeln("Leaving fnA1"); } ``` ```

Re: Any suggestions on dmd error message formatting?

2021-05-15 Thread SealabJaster via Digitalmars-d-learn
On Saturday, 15 May 2021 at 06:12:25 UTC, SealabJaster wrote: ... Honestly I also kind of wish that the D compilers could format functions better on the command line, because these giant blobs of "where's ~~wally~~ the difference?" are just horrid when they show up.

Re: Any suggestions on dmd error message formatting?

2021-05-15 Thread SealabJaster via Digitalmars-d-learn
On Saturday, 15 May 2021 at 04:54:15 UTC, Chris Piker wrote: Hi D T_T My eyes burn. Anyway, Here it is formatted slightly better: ```d PriorityRange.this( DasRange!( Tuple!(int, int)[], int function(Tuple!(int, int)) pure nothrow @nogc @safe,