Should this always work?
I always thought as long as an object implements an interface, it
should be able to cast it from a void* if it really points to a
supporting object.
I have the similar structure:
```d
interface AI {
string doSomething();
}
template S() {
void foo() {
}
}
abstract class A : AI {
string doSomething() {
return "Hello, World";
}
}
class B : A {
mixin S;
void other() {
}
}
auto b = new B;
auto p = cast(void*) b;
auto c = cast(AI) p;
c.doSomething();
```
But in my code with the real object, this generates a RangeError,
AcccesError, memory garbage:
```d
auto b = new B;
auto p = cast(void*) b;
auto c = cast(AI) p; // AI with corrupt data
c.doSomething(); // error
```
But this works:
```d
auto b = new B;
auto p = cast(void*) b;
auto c = cast(A) p; // A with correct data
c.doSomething(); // no error
```
If the runtime could not successfully cast it to AI, it should
return null. Am I wrong here?
Re: betterC examples?
On Saturday, 1 May 2021 at 01:29:05 UTC, Mike Parker wrote: As for the code, your main function should be `extern(C)`. Functions you want to make available to the C side should also be `extern(C)`, and will need equivalent declarations in C. DMD has an experimental feature to generate C headers for you via the `-HC` (`dmd -HC=?` for options). Then all that's left is to link the C objects into D or the D objects into C. Forgot to talk about going the other way. You'll need to declare in D any C functions you'd like to call, also as `extern(C)`, with the appropriate type translations. There are posts about that on the D Blog: https://dlang.org/blog/the-d-and-c-series/ Some documentation here: https://dlang.org/spec/interfaceToC.html A page on the D Wiki: https://wiki.dlang.org/D_binding_for_C And a rather lengthy chapter in my book 'Learning D'. (Email me about that chapter if you'd like).
Re: betterC examples?
On Friday, 30 April 2021 at 22:22:05 UTC, sfp wrote: To be clear, I'm mostly interested in examples that show how to structure a project. I'd like to know what the best way to start using D in my current project is, how to call D from C, and how to call C from D. There is nothing special about the structure of a BetterC _project_. It's just a D project without the full feature set, so you can structure it in whatever way makes sense to you in terms of packages and modules. As for the code, your main function should be `extern(C)`. Functions you want to make available to the C side should also be `extern(C)`, and will need equivalent declarations in C. DMD has an experimental feature to generate C headers for you via the `-HC` (`dmd -HC=?` for options). Then all that's left is to link the C objects into D or the D objects into C. Beyond that, it's just a matter of making use of a limited subset of D features: https://dlang.org/spec/betterc.html I'm unaware of any specific open source projects that do what you're looking to (integrate new D code into an existing C project) especially any using CMake. But I would approach by isolating the new D code as a library. Then you can structure it however you like and just add the library to your C project's dependencies. Alternatively, you could add individual D modules to your source tree and configure CMake such that they are compiled with a D compiler and a header generated for each. I mean, there's no one way to go about this. But whatever you end up doing, please consider writing it up in a blog post for the D blog (email me at aldac...@gmail.com when you're ready) describing how you approached it, then your project could be an example for someone else.
Re: betterC examples?
https://dlang.org/spec/interfaceToC.html
Re: betterC examples?
On Friday, 30 April 2021 at 23:06:48 UTC, bachmeier wrote: There is a blog series https://dlang.org/blog/the-d-and-c-series/#betterC Thanks for the link. I read through these, but they don't address my question. The first two posts are about specific -betterC features and the third one is about a total conversion from C to -betterC of a one or two file program. It's very cool that you can do the conversion so is easily, but this isn't my goal.
Re: betterC examples?
On Friday, 30 April 2021 at 22:22:05 UTC, sfp wrote: I'm developing a C library with Cython bindings, built using CMake. I'd like to use D with -betterC to write some new code where it would be handy to have access to some more advanced language features to keep things readable. For my domain, C is totally fine 99% of the time, and rewriting a bunch of C code that's already tested and works nicely isn't a priority for me. I would like to develop new "modules" using -betterC and freely mix them into my existing C code without it being a headache. [...] There is a blog series https://dlang.org/blog/the-d-and-c-series/#betterC
betterC examples?
I'm developing a C library with Cython bindings, built using CMake. I'd like to use D with -betterC to write some new code where it would be handy to have access to some more advanced language features to keep things readable. For my domain, C is totally fine 99% of the time, and rewriting a bunch of C code that's already tested and works nicely isn't a priority for me. I would like to develop new "modules" using -betterC and freely mix them into my existing C code without it being a headache. So, it would be helpful to see some real -betterC examples. They don't need to polished, but substantial enough to help me get my bearings. Are there any out there that use CMake? This seems like it should be natural: start with a C or C++ CMake project (common enough!), and work D into the mix. I'm aware of cmake-d, but haven't taken too close of a look at it. It doesn't look like it's being actively developed. To be clear, I'm mostly interested in examples that show how to structure a project. I'd like to know what the best way to start using D in my current project is, how to call D from C, and how to call C from D. Thanks!
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Friday, 30 April 2021 at 19:17:14 UTC, user1234 wrote: [...] Likely a side effect of https://github.com/dlang/dmd/pull/12178 but according to me the new behavior is correct. It breaks my code. I have files named $C containing struct or class $C plus some other stuff. Using the workaround means to switch to selective imports for all used types/functions within this module. Found another workaround: I created a symlink here -> . and replaced all imports $C with here.$C. In some places I had to remove an artificial "prefix" ($C.$C -> $C).
Re: serve-d and emacs
On 26.04.21 21:13, WebFreak001 wrote: On Monday, 26 April 2021 at 18:45:08 UTC, Christian Köstlin wrote: Does anybody use serve-d with emacs (lsp-mode or eglot)? I would love to see the configuration! Kind regards, Christian if you configure it yourself, feel free to share the configuration and maybe PR it to serve-d repo. Basic setup should be quite easy, see vim for reference: https://github.com/Pure-D/serve-d/blob/master/editor-vim.md I threw together a "minimal" emacs configuration that can be used if you have just a plain emacs and dlang installation. See https://github.com/gizmomogwai/demacs Kind regards, Christian
Re: dlang vs crystal-language
On Friday, 30 April 2021 at 14:16:16 UTC, Vinod K Chandran wrote: BTW, I wonder to see someone says that they have succeeded in compiling a **tkD** example code. I tried it with no luck. So I gave up that idea. I did this @2014. No problems remembered.
Re: Since dmd 2.096.0: import `x.t` is used as a type
On Friday, 30 April 2021 at 17:58:43 UTC, kdevel wrote:
dmd since 2.096.0 with ``t.d``
```t.d
module t;
class t {
}
```
and ``x.d``
```x.d
module x;
import t;
void main ()
{
t x = new t;
}
```
reports
$ dmd -i x.d
x.d(6): Error: import `x.t` is used as a type
x.d(6): Error: import `x.t` is used as a type
Could not find this Change in
https://dlang.org/changelog/2.096.0.html. Has this been "fixed"
with some other issue?
Workaround:
```x.d
...
import t : t;
...
```
Likely a side effect of https://github.com/dlang/dmd/pull/12178
but
according to me the new behavior is correct.
Re: Thoughts on Structure
On Friday, 30 April 2021 at 18:27:02 UTC, Alain De Vos wrote: Is there no room for improvement to discriminate between alive and dead ? What do you think ? Alive must fullfill these conditions in order to be referenced. I and others think there's something wrong with the dub registry. It has stopped updating
Re: Thoughts on Structure
Is there no room for improvement to discriminate between alive and dead ? What do you think ? Alive must fullfill these conditions in order to be referenced.
Re: Thoughts on Structure
On Friday, 30 April 2021 at 17:33:19 UTC, Alain De Vos wrote: An active maintainer is a living person, with a first name a last name and an email adress, who looks into issues and tries to fix them. Now go look to this page ... https://code.dlang.org/ Feel free to elaborate ... I don't get your point...
Since dmd 2.096.0: import `x.t` is used as a type
dmd since 2.096.0 with ``t.d``
```t.d
module t;
class t {
}
```
and ``x.d``
```x.d
module x;
import t;
void main ()
{
t x = new t;
}
```
reports
$ dmd -i x.d
x.d(6): Error: import `x.t` is used as a type
x.d(6): Error: import `x.t` is used as a type
Could not find this Change in
https://dlang.org/changelog/2.096.0.html. Has this been "fixed"
with some other issue?
Workaround:
```x.d
...
import t : t;
...
```
Thoughts on Structure
An active maintainer is a living person, with a first name a last name and an email adress, who looks into issues and tries to fix them. Now go look to this page ... https://code.dlang.org/ Feel free to elaborate ...
Re: dlang vs crystal-language
On Friday, 30 April 2021 at 14:16:16 UTC, Vinod K Chandran wrote: On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Pros of **Crystal** 1. Attractive syntax. I like Ruby like syntax. It's really expressive. Cons of Crystal 1. It doesn't have a compiler for Windows. It uses WSL based compiler and I think it's a bad idea. I don't think I need to tell the pros & cons of **D lang** in it's own forum. BTW, I wonder to see someone says that they have succeeded in compiling a **tkD** example code. I tried it with no luck. So I gave up that idea. I used tkD a long time ago. Look through [this repo](https://github.com/thegag96/codewrite) - maybe something in there will help you.
Re: write once type?
On Friday, 30 April 2021 at 13:36:10 UTC, Steven Schveighoffer wrote: I could have looped 2x over the args, and used an inner function to fetch the first one (or maybe used a staticIndexOf to get the first ColumnDef thing), and a second loop to verify all the remaining args have the same table def, but this loop works just as designed and is super-readable. I would say likewise using static indexing, is it really that slow? Otherwise, iterate over Pair-like partitions would also be a solution and compare if first.tableDef is second.tableDef, don't know if D has something for this statically available. Further, I would like to refactor the static if out to an in-requirement, though I'm unsure if in-assertions support arbitrary exception types.
Re: dlang vs crystal-language
tkd works perfectly. Which O.S. are you using ? I can guide.
Re: dlang vs crystal-language
On Wednesday, 28 April 2021 at 22:41:03 UTC, Alain De Vos wrote: What are the strengths and weaknesses comparing the two languages ? I can name a strength of dlang is the working binding to tk and gtk. Pros of **Crystal** 1. Attractive syntax. I like Ruby like syntax. It's really expressive. Cons of Crystal 1. It doesn't have a compiler for Windows. It uses WSL based compiler and I think it's a bad idea. I don't think I need to tell the pros & cons of **D lang** in it's own forum. BTW, I wonder to see someone says that they have succeeded in compiling a **tkD** example code. I tried it with no luck. So I gave up that idea.
Re: nothrow and std.exception.ifThrown
On Friday, 30 April 2021 at 13:42:49 UTC, Steven Schveighoffer
wrote:
On 4/30/21 9:24 AM, Meta wrote:
My point is that I think marking the *function* nothrow is not
correct, it's the second parameter that dictates the throwing
of the result.
And you can probably fix the second parameter to be a templated
delegate:
```d
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1,
T2)(lazy scope T1 expression, scope T2 errorHandler) if
(is(typeof(errorHandler(E.init
```
And of course, we get into chicken-and-egg problems with this
because if you pass in a lambda, there's no types for it to
figure this stuff out. Another option is to overload on the
delegate, but meh. I'd really like to see a language change
that says "infer the attributes of this function based on the
fact that it calls the delegate passed in."
-Steve
Now that you mention it, I don't see why lazy parameters can't
have their attributes inferred. What happened to the DIP to
replace lazy parameters with automatic conversion of passed
values to delegates, anyway? I.e.:
```
CommonType!(T1, T2) ifThrown(E: Throwable = Exception, T1,
T2)(scope T1 delegate() expression, scope T2 delegate()
errorHandler);
//getString() and "some string" automatically converted to
`string delegate()`
auto s = getString().ifThrown("some string");
```
Re: nothrow and std.exception.ifThrown
On Thursday, 29 April 2021 at 20:00:23 UTC, novice2 wrote:
i dont understand why (templates too dificult for me yet),
but if i comment "lazy" from T2,
then compiler allow add "nothrow" to "ifThrown"
```d
CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1,
T2)(lazy scope T1 expression, /*lazy*/ scope T2 errorHandler)
nothrow
```
https://run.dlang.io/is/KTdd3G
This is because marking a function parameter as `lazy` is just
syntax sugar for the following:
```
CommonType!(T1, T2) ifThrown(E: Throwable = Exception, T1,
T2)(scope T1 delegate() expression, scope T2 delegate()
errorHandler);
string def = "some string";
auto s = format("%d", x).ifThrown({ return def; });
```
Behind the scenes, a `lazy` parameter is not really a value -
it's a function that _returns_ a value. The problem is that this
function is not `nothrow`, and can't be marked as such (this is
arguably a gap in the language). Removing `lazy` changes
`errorHandler` to be a plain old value again - which cannot throw
an exception, of course - so `ifThrown` can be marked `nothrow`.
However, you lose all the benefits of `errorHandler` being lazily
computed.
Re: nothrow and std.exception.ifThrown
On 4/30/21 9:24 AM, Meta wrote: On Friday, 30 April 2021 at 13:05:00 UTC, Steven Schveighoffer wrote: On 4/29/21 1:50 PM, Meta wrote: The reason for this, apparently, is in the definition of `ifThrown`: ``` CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1, T2)(lazy scope T1 expression, lazy scope T2 errorHandler) nothrow ``` It's not marked as `nothrow` in the function's definition, so even if the delegate passed to ifThrown _is_ nothrow, the compiler can't tell. There's no easy way around this that I can think of OTOH that doesn't involve some effort on your part. Wait, I don't get what you are saying. You mean it should be marked nothrow? It's a template, so it *should* be inferred nothrow if it were actually nothrow. The current definition is not marked nothrow as you alluded, and when I do mark it nothrow, it complains that the lazy parameter used for the exception handler is not nothrow. It seems there's no way to infer the throwing of the lazy parameter, lazy parameters are never nothrow. The higher order function DIP would I think help with this. Change it to a delegate and it's the same thing. ifThrown being a template is irrelevant in this case because it is accepting the handler as a function argument, not a template argument. You: 1. Need to make it a delegate instead of a lazy argument. 2. Need to mark the delegate as nothrow. For the function to be inferred as nothrow. My point is that I think marking the *function* nothrow is not correct, it's the second parameter that dictates the throwing of the result. And you can probably fix the second parameter to be a templated delegate: ```d CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1, T2)(lazy scope T1 expression, scope T2 errorHandler) if (is(typeof(errorHandler(E.init ``` And of course, we get into chicken-and-egg problems with this because if you pass in a lambda, there's no types for it to figure this stuff out. Another option is to overload on the delegate, but meh. I'd really like to see a language change that says "infer the attributes of this function based on the fact that it calls the delegate passed in." -Steve
Re: dlang vs crystal-language
On Thursday, 29 April 2021 at 22:47:08 UTC, Alain De Vos wrote: What is the importance of type-annotations in which cases. Specifying invariants which becomes very important when refactoring code. Further it aids as documentation to understand the structures behind. @X @Y @Z makes code sometimes unreadable. You mean something like `List!(HashMap!(String,T))`, yes, but I like it in productive code. It's often the case that verbosity becomes a plus in productive software development, as more people have to read code that to write it, a reason why Java is so successful Sometimes there is a good reason Mostly for prototyping and obvious cases. But the most important point of that is to write faster, I wish the IDE would help for this instead of the compiler's inference. I even think D doesn't even profit very well for inferred types, you need anyway to specify auto which only saves work for large type(application)s. But when they are large, you probably want to prefer annotating the type for the variable. Instead, I want to point to some interesting solution C# offers to save typing and also being explicit about the type: https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/#target-typed-new-expressions In fact, one could imagine that they overload the new operator (at compiler level) to infer the type from the call site type annotation.
Re: write once type?
On 4/30/21 9:24 AM, sighoya wrote:
On Friday, 30 April 2021 at 01:30:54 UTC, Steven Schveighoffer wrote:
In my case, for value of a certain type in the loop, I was storing a
specific field from the first one I found, and then verifying that all
the other values of that type (not exactly the same type, but similar)
had the same value for that field, otherwise it was an error.
I could have done it in 2 loops, but it's wasteful.
I have problems to grok exactly what you're talking about, can you
provide some neat and small example for this?
I'll just show you the code here. This is from my (up and coming) sql
builder project.
A `ColumnDef!T` is an sql table column of type `T`, which contains an
expression describing the column, and a table definition of where the
column comes from. `TableDef` is const inside the column def:
```d
struct ColumnDef(T)
{
const TableDef table;
ExprString expr;
alias type = T;
}
```
Now, what if you wanted a "computed" column? that is, you wanted to
define a column with a type, but that is computed from other columns?
Like `select total - tax as netcost from sometable`
What I want to create is something that returns a ColumnDef from an
arbitrary expression. But there is only one table definition, so if you
want to return a ColumnDef, you need to ensure there is only one source
table. So here is my code that does that:
```d
ColumnDef!T exprCol(T, Args...)(Args args)
{
// first, find all columns, and ensure that table defs are all from the
// same table (a ColumnDef cannot have multiple tables).
const(TableDef)* tabledef;
foreach(ref arg; args)
{
static if(is(typeof(arg) == ColumnDef!U, U))
{
if(tabledef && arg.table != *tabledef)
throw new Exception("can't have multiple tabledefs in
the expression");
else
tabledef =
}
}
assert(tabledef !is null);
// build the expr string
ExprString expr;
foreach(ref a; args)
{
static if(is(typeof(a) == string))
expr ~= a;
else
expr ~= a.expr;
}
return ColumnDef!(T)(*tabledef, expr);
}
```
The pointer abstraction works perfectly, but if there was no way to use
that abstraction, there aren't any D facilities to allow this. It's
really tail-const that I need.
I could have looped 2x over the args, and used an inner function to
fetch the first one (or maybe used a staticIndexOf to get the first
ColumnDef thing), and a second loop to verify all the remaining args
have the same table def, but this loop works just as designed and is
super-readable.
-Steve
Re: nothrow and std.exception.ifThrown
On Friday, 30 April 2021 at 13:05:00 UTC, Steven Schveighoffer wrote: On 4/29/21 1:50 PM, Meta wrote: The reason for this, apparently, is in the definition of `ifThrown`: ``` CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1, T2)(lazy scope T1 expression, lazy scope T2 errorHandler) nothrow ``` It's not marked as `nothrow` in the function's definition, so even if the delegate passed to ifThrown _is_ nothrow, the compiler can't tell. There's no easy way around this that I can think of OTOH that doesn't involve some effort on your part. Wait, I don't get what you are saying. You mean it should be marked nothrow? It's a template, so it *should* be inferred nothrow if it were actually nothrow. The current definition is not marked nothrow as you alluded, and when I do mark it nothrow, it complains that the lazy parameter used for the exception handler is not nothrow. It seems there's no way to infer the throwing of the lazy parameter, lazy parameters are never nothrow. The higher order function DIP would I think help with this. -Steve Change it to a delegate and it's the same thing. ifThrown being a template is irrelevant in this case because it is accepting the handler as a function argument, not a template argument. You: 1. Need to make it a delegate instead of a lazy argument. 2. Need to mark the delegate as nothrow. For the function to be inferred as nothrow.
Re: write once type?
On Friday, 30 April 2021 at 01:30:54 UTC, Steven Schveighoffer wrote: In my case, for value of a certain type in the loop, I was storing a specific field from the first one I found, and then verifying that all the other values of that type (not exactly the same type, but similar) had the same value for that field, otherwise it was an error. I could have done it in 2 loops, but it's wasteful. I have problems to grok exactly what you're talking about, can you provide some neat and small example for this?
Re: nothrow and std.exception.ifThrown
On 4/29/21 1:50 PM, Meta wrote: The reason for this, apparently, is in the definition of `ifThrown`: ``` CommonType!(T1, T2) ifThrown(E : Throwable = Exception, T1, T2)(lazy scope T1 expression, lazy scope T2 errorHandler) nothrow ``` It's not marked as `nothrow` in the function's definition, so even if the delegate passed to ifThrown _is_ nothrow, the compiler can't tell. There's no easy way around this that I can think of OTOH that doesn't involve some effort on your part. Wait, I don't get what you are saying. You mean it should be marked nothrow? It's a template, so it *should* be inferred nothrow if it were actually nothrow. The current definition is not marked nothrow as you alluded, and when I do mark it nothrow, it complains that the lazy parameter used for the exception handler is not nothrow. It seems there's no way to infer the throwing of the lazy parameter, lazy parameters are never nothrow. The higher order function DIP would I think help with this. -Steve
