Re: Exit before second main with -funittest

[Ali Çehreli via Digitalmars-d-learn]

On 7/30/21 7:48 PM, Brian TIffin wrote:

> Found, find, C++ too hot for most to handle, so why?

I rubbed shoulders with C++ people who would argue to the effect of "C++ 
was not meant to be for everyone."


> And a deeper thanks, Ali, for the book.

You're welcome. I am very happy when it is helpful.

> Just in case you ever want to try Unicon programming, or need to glue to
> some COBOL data, I put these on offer, umm, meaning free.
>
> - Unicon Programming 
> - GnuCOBOL FAQ 

I've just browsed them. Impressive work; both the content and the 
technology covered. :)


Ali

Re: How to put an arbitrary string to clipboard in D?

[Adam D Ruppe via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 18:30:47 UTC, tastyminerals wrote:
So I thought there may be a way in D to communicate with the 
system clipboard...


You can always call the same system functions from D that you'd 
use from C.


This is the source to my simpledisplay.d library on its clipboard 
function:


https://github.com/adamdruppe/arsd/blob/master/simpledisplay.d#L5279

The Windows side isn't too bad, the linux side a bit more 
complicated. Generally window libs offer something for this but 
idk about the one you're using.

Re: How to put an arbitrary string to clipboard in D?

[rikki cattermole via Digitalmars-d-learn]

On 01/08/2021 6:30 AM, tastyminerals wrote:
So I thought there may be a way in D to communicate with the system 
clipboard...


No, this requires a windowing library and yes a window to do it 
(depending on the windowing system and even the desktop environment).

Re: How to put an arbitrary string to clipboard in D?

[tastyminerals via Digitalmars-d-learn]

On Friday, 30 July 2021 at 20:01:09 UTC, rikki cattermole wrote:


On 31/07/2021 7:33 AM, tastyminerals wrote:
I made a GUI app using tkd library. I am reading the string 
from one of the app widgets and would like to put it into the 
clipboard. Does anyone have an idea how to copy a string to 
the clipboard in D?


copyText on a Text widget appears to do what you want.

https://github.com/nomad-software/tkd/blob/9ca40d117649bb9a9db108d8f92e92870b9dc77e/source/tkd/widget/text.d#L477

https://wiki.tcl-lang.org/page/tk_textCopy


The problem is that I don't use Text widget but retrieve the 
string from TreeView widget which only has getSelectedRows 
method. So I thought there may be a way in D to communicate with 
the system clipboard...

Re: Why are class methods not allowed to call cons/destructors?

[kinke via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 13:59:46 UTC, Tejas wrote:

On Saturday, 31 July 2021 at 13:57:40 UTC, kinke wrote:

This is possible via:
```
__dtor();
super.__dtor();
```


WHOO YEAH!!!
THANK YOU SO MUCH :D


Heh you're welcome. Note that you'll probably want `__xdtor()`, 
which also destructs fields with dtor (no base fields - 
`super.__xdtor()` for the immediate base class etc.).

Re: Why are class methods not allowed to call cons/destructors?

[Tejas via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 13:57:40 UTC, kinke wrote:

This is possible via:
```
__dtor();
super.__dtor();
```


WHOO YEAH!!!
THANK YOU SO MUCH :D

Re: Why are class methods not allowed to call cons/destructors?

[kinke via Digitalmars-d-learn]

This is possible via:
```
__dtor();
super.__dtor();
```

Re: Any way to create derived classes from Exception with canned messages?

[Jeremy T. Gibson via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 11:30:06 UTC, Adam D Ruppe wrote:
On Saturday, 31 July 2021 at 08:25:56 UTC, Jeremy T. Gibson 
wrote:
Now, 
https://github.com/dlang/druntime/blob/master/src/object.d 
clearly expresses that the constructors of Exception are @nogc.


That doesn't mean your constructors have to be! You can do 
whatever you want. Constructors aren't an inherited interface.


Hah!  I knew it was something simple.  I should have guessed, 
when I was being shouted at when I tried to use the "override" 
keyword (obviously they're not virtual either), that I was 
approaching it all wrong.

Re: Why are class methods not allowed to call cons/destructors?

[Tejas via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 13:34:25 UTC, user1234 wrote:

On Saturday, 31 July 2021 at 13:12:21 UTC, Tejas wrote:

```d
class A{
~this(){}
destructA(){
~this()
}
}
class B:A{
~this(){}
destructB(){
~this();
~super();
}
}

```
This could allow ```@nogc``` crowd to run destructors without 
calling ```destroy```.
Yes, derived to base conversion is still a thing and someone 
who invokes the destructor just by looking at the parameter's 
type could get fooled, atleast we will have a way to destroy 
class instances without the gc.


Are there other problems? I'm genuinely curious.

I guess we can still just define normal methods and invoke 
them, but atleast this will allow us to maintain consistency 
with the gc crowd.


`destroy` is not the problem, see

https://forum.dlang.org/post/jsrjgmeblfukwhqbw...@forum.dlang.org

the problem is **what is called in `destroy()`**

see 
https://forum.dlang.org/post/rdcadsqsmszqg...@forum.dlang.org


for a very simple solution.


Both solutions also suffer from ```cast```, so one is not better 
than another(except that your solution doesn't require a language 
change, which makes it more feasible to use).


I'm simply curious why the requested behaviour is not available 
in the first place.

Re: Why are class methods not allowed to call cons/destructors?

[Tejas via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 13:34:25 UTC, user1234 wrote:

On Saturday, 31 July 2021 at 13:12:21 UTC, Tejas wrote:

```d
class A{
~this(){}
destructA(){
~this()
}
}
class B:A{
~this(){}
destructB(){
~this();
~super();
}
}

```
This could allow ```@nogc``` crowd to run destructors without 
calling ```destroy```.
Yes, derived to base conversion is still a thing and someone 
who invokes the destructor just by looking at the parameter's 
type could get fooled, atleast we will have a way to destroy 
class instances without the gc.


Are there other problems? I'm genuinely curious.

I guess we can still just define normal methods and invoke 
them, but atleast this will allow us to maintain consistency 
with the gc crowd.


`destroy` is not the problem, see

https://forum.dlang.org/post/jsrjgmeblfukwhqbw...@forum.dlang.org

the problem is **what is called in `destroy()`**

see 
https://forum.dlang.org/post/rdcadsqsmszqg...@forum.dlang.org


for a very simple solution.


It is simple indeed, but not _very_ simple.
If what I'm asking for is not too hard to implement and makes it, 
we can still use ```new```, ```destroy``` will be unnecessary 
since we can use an explicit method(just like your solution) , or 
we won't even use that if we're willing to let RAII do the 
work(I'm talking of allocating to a ```scope``` qualified 
variable, or ```rt.alloca``` or ```std.typecons.scoped```).


If we do this, the gc crowd will not be completely alienated when 
reading our code, since it's not out of the ordinary(assuming we 
use RAII; using the destruct methods explicitly... well that's 
atleast better than seeing **both** construction and destruction 
done in a weird way)

Re: Why are class methods not allowed to call cons/destructors?

[user1234 via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 13:12:21 UTC, Tejas wrote:

```d
class A{
~this(){}
destructA(){
~this()
}
}
class B:A{
~this(){}
destructB(){
~this();
~super();
}
}

```
This could allow ```@nogc``` crowd to run destructors without 
calling ```destroy```.
Yes, derived to base conversion is still a thing and someone 
who invokes the destructor just by looking at the parameter's 
type could get fooled, atleast we will have a way to destroy 
class instances without the gc.


Are there other problems? I'm genuinely curious.

I guess we can still just define normal methods and invoke 
them, but atleast this will allow us to maintain consistency 
with the gc crowd.


`destroy` is not the problem, see

https://forum.dlang.org/post/jsrjgmeblfukwhqbw...@forum.dlang.org

the problem is **what is called in `destroy()`**

see 
https://forum.dlang.org/post/rdcadsqsmszqg...@forum.dlang.org


for a very simple solution.

Why are class methods not allowed to call cons/destructors?

[Tejas via Digitalmars-d-learn]

```d
class A{
~this(){}
destructA(){
~this()
}
}
class B:A{
~this(){}
destructB(){
~this();
~super();
}
}

```
This could allow ```@nogc``` crowd to run destructors without 
calling ```destroy```.
Yes, derived to base conversion is still a thing and someone who 
invokes the destructor just by looking at the parameter's type 
could get fooled, atleast we will have a way to destroy class 
instances without the gc.


Are there other problems? I'm genuinely curious.

I guess we can still just define normal methods and invoke them, 
but atleast this will allow us to maintain consistency with the 
gc crowd.

Re: Routing of AssertError messages

[Tejas via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 12:03:49 UTC, DLearner wrote:

Hi

This may be due to Windows, not DMD.

Please see code below (held in test.d):

```
void main() {
   import std.stdio;

   writeln("Test");
   assert(false, "TestAssert");
}
```
`
dmd -i -run test.d
`
results in both "Test" and the "TestAssert" string (and trace) 
being routed to screen.


But
`
dmd -i -run test.d > op.txt
`
results in only "Test" going into op.txt, the "TestAssert" 
string (and trace) being routed to screen as before.


I expected both "Test" and the "TestAssert" string (and trace) 
to go into op.txt.


The idea was to use op.txt as documentation of a successful 
test of the "TestAssert" string.


Best regards


Please read the docs that jfronden referred to.

If you want a quick hack, use this:
```d
const(char)[] falseAssertMsg(string s){
writeln(s);
return "";
}
void main() {
   import std.stdio;

   writeln("Test");
   assert(false, falseAssertMsg("TestAssert failed in 
main()"));

}

```
There should be a better way of doing this though.

Re: Routing of AssertError messages

[jfondren via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 12:03:49 UTC, DLearner wrote:

Hi

This may be due to Windows, not DMD.

Please see code below (held in test.d):

```
void main() {
   import std.stdio;

   writeln("Test");
   assert(false, "TestAssert");
}
```
`
dmd -i -run test.d
`
results in both "Test" and the "TestAssert" string (and trace) 
being routed to screen.


But
`
dmd -i -run test.d > op.txt
`
results in only "Test" going into op.txt, the "TestAssert" 
string (and trace) being routed to screen as before.


I expected both "Test" and the "TestAssert" string (and trace) 
to go into op.txt.


"Test" is written to the standard out stream; "TestAssert" is 
written to the standard error stream. > only redirects standard 
out, so the error stream continues to write to the terminal.


Stream redirection depends on your shell. PowerShell docs appear 
to be here:

https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_redirection?view=powershell-7.1

Routing of AssertError messages

[DLearner via Digitalmars-d-learn]

Hi

This may be due to Windows, not DMD.

Please see code below (held in test.d):

```
void main() {
   import std.stdio;

   writeln("Test");
   assert(false, "TestAssert");
}
```
`
dmd -i -run test.d
`
results in both "Test" and the "TestAssert" string (and trace) 
being routed to screen.


But
`
dmd -i -run test.d > op.txt
`
results in only "Test" going into op.txt, the "TestAssert" string 
(and trace) being routed to screen as before.


I expected both "Test" and the "TestAssert" string (and trace) to 
go into op.txt.


The idea was to use op.txt as documentation of a successful test 
of the "TestAssert" string.


Best regards

Re: Any way to create derived classes from Exception with canned messages?

[Adam D Ruppe via Digitalmars-d-learn]

I'll add just for info sake even though you can just use normal 
gc in your own constructors as wanted, other options include:


1) making a buffer inside your new object and copying the message 
to it, then passing a slice of your buffer to the super ctor.


2) making all the messages compile-time literals so each class 
has a static message. then there's no runtime work at all. (and 
you can differentiate things based on type!)


can even be defined inline like

`throw new NotImplemented!"thing"`

and then the impl is like

class NotImplementedBase : Exception {
  mixin ExceptionCtors;
}

class NotImplemented(string msg) : NotImplmentedntedBase {
   this() { super ("Not implemented" ~ msg); }
}


that kind of thing just plus the file line info etc too arguments.

3) ignore hte msg member and just override toString



But again the base ctor limitations do NOT apply to derived 
classes so it is all moot.



btw for virtual interfaces base things do apply but you're 
allowed to tighten if you want. so like base toString is NOT 
@nogc but if you wanted derived @nogc that's perfectly allowed. 
virtual methods must be as strict or stricter since they're 
inherited. just again ctors are not inherited so there's no 
connection at all.

Re: Any way to create derived classes from Exception with canned messages?

[Adam D Ruppe via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 08:25:56 UTC, Jeremy T. Gibson wrote:
Now, https://github.com/dlang/druntime/blob/master/src/object.d 
clearly expresses that the constructors of Exception are @nogc.


That doesn't mean your constructors have to be! You can do 
whatever you want. Constructors aren't an inherited interface.

Re: Any way to create derived classes from Exception with canned messages?

[jfondren via Digitalmars-d-learn]

On Saturday, 31 July 2021 at 08:25:56 UTC, Jeremy T. Gibson wrote:
Now, https://github.com/dlang/druntime/blob/master/src/object.d 
clearly expresses that the constructors of Exception are @nogc. 
 Therein lies the problem: there is no way to use the ~ 
concatenation operator in a @nogc function.  At least at my 
current level of understanding of D (versus my background in C# 
where this is trivial), I can't think of any other way to pass 
a pure/nogc pair of strings that won't trip up the safety 
parameters.


Just as a raw test case, I tried the following:

https://run.dlang.io/is/VmCKwV



`annotation()` should also be nothrow as it's called by the 
nothrow constructor.


Option #1: https://run.dlang.io/is/OBNfxq

use a limited @nogc string formatter from dub, with an instance 
buffer.


Option #2: https://run.dlang.io/is/Osoiyd

for such a simple format, do it manually.

Option #3: NotYetImplemented()

require the caller to call a non-@nogc function which can build a 
string and then throw/return a constructed exception.

Any way to create derived classes from Exception with canned messages?

[Jeremy T. Gibson via Digitalmars-d-learn]

Is there any way to go about making derived Exception classes 
which produce a passed error message plus a hard-coded annotation 
string provided by the derived class, allowing me to use both a 
consistent error message suffix plus a programmer-specified error 
message?


I'm running into a problem where I want to create a set of 
Exception classes that automatically annotate Exception calls 
based on the class of the Exception, ensuring a more rigid 
syntax, avoiding typos and/or having to remember to identify the .


In my (barebones) production code, I currently have:

throw new Exception("vec3.bearing (NotYetImplemented)");

but I would vastly prefer that to be:

throw new NotYetImplementedException("vec3.bearing");

which offers code completion, typo safety, consistency, a toolbox 
of recommended exception types if I ever stop being the sole 
programmer, etc.  (Still nothing I can do to pull the name of the 
current function and include that automatically (I think?), since 
the best I've got is `__LINE__` etc.  But we can't all eat *pure* 
syntactic sugar or we'd die of code-abetes.)


Now, https://github.com/dlang/druntime/blob/master/src/object.d 
clearly expresses that the constructors of Exception are @nogc.  
Therein lies the problem: there is no way to use the ~ 
concatenation operator in a @nogc function.  At least at my 
current level of understanding of D (versus my background in C# 
where this is trivial), I can't think of any other way to pass a 
pure/nogc pair of strings that won't trip up the safety 
parameters.


Just as a raw test case, I tried the following:

https://run.dlang.io/is/VmCKwV

(where classes derived from MyException would then override the 
annotation function accordingly, avoiding the @safe limitation of 
global/static variables) and, sure enough, it didn't work -- as I 
anticipated it wouldn't.


I do get the reason why the Exception class is @nogc, as you 
can't necessarily rely on the memory state when an Exception is 
thrown.  If it wasn't memory-safe, it would be possible to enter 
a state where the Exception explaining why the program is failing 
won't be produced when the program fails because it too fails, 
making it even harder to figure out the problem.  But given that 
the substantial majority of manually thrown exceptions *do* 
consist of program states that aren't out of memory, it also 
limits my usage case.


I'm going to be digging around Phobos to see if I can mishmash 
something out of the stringizing functions, but that seems 
convoluted when a string concatenation "intuitively" should work, 
even though it obviously doesn't.


Has anyone else worked through this problem before and come up 
with a more elegant solution?  Am I just over-analyzing the 
problem?