Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.
On Friday, 16 December 2016 at 22:37:13 UTC, hardreset wrote:
To be honest I was having some odd linking problems anyway. I
initially wrapped the FT init function in plain D function and
that kept causing "_FT_ not found" link errors. As soon as
I took all the actual D functions out and left just FT
declarations in there it stopped. Even now if I add...
int foo() { return 0; }
to my freetype.d (contains just FT interface declarations)
and call it from font.d (my font class)
i start getting linker errors. Why would adding a plain D
function suddenly make it sound the linker cant find what it
needs in the freetype.lib?
The only thing I can think of offhand: did you compile and link
your freetype.d? As long as it's just interface declarations,
there's no need to -- it only needs to be on the import path. But
once you start adding implementations, it needs to be compiled
and linked into the executable.
Re: Simplest way to build a DMD compatible C lib, and how to link using DUB.
On Friday, 16 December 2016 at 00:40:07 UTC, Mike Parker wrote:
On Thursday, 15 December 2016 at 20:34:47 UTC, hardreset wrote:
On Thursday, 15 December 2016 at 18:30:14 UTC, hardreset wrote:
I have pragma(lib,**fullpath**) in my freetype.d file, is
that the correct way?
Never mind, figured it out, I needer to add
"libs": ["libs/freetype27ST"]
to dub.json
The pragma alone should have been enough. Did you get the path
right? At any rate, if you're adding that line to dub.json,
then the pragma is redundant. They both do the same thing.
Im pretty sure i did, i tried absolute path, relative, just
filename, copied from address bar, etc..
To be honest I was having some odd linking problems anyway. I
initially wrapped the FT init function in plain D function and
that kept causing "_FT_ not found" link errors. As soon as I
took all the actual D functions out and left just FT declarations
in there it stopped. Even now if I add...
int foo() { return 0; }
to my freetype.d (contains just FT interface declarations)
and call it from font.d (my font class)
i start getting linker errors. Why would adding a plain D
function suddenly make it sound the linker cant find what it
needs in the freetype.lib?
Re: Allocating a class within another class during object init w/o passing in an allocator
On Friday, 16 December 2016 at 18:25:42 UTC, David Zhang wrote: I though all classes were aligned to sizeof(size_t) boundaries? I don't know. Wouldn't it then just be align(sizeof(size_t)) byte[__traits(classInstanceSize, SomeClass)] scStorage; I guess? I really don't have much of a clue here. Looking around a bit, I found std.traits.classInstanceAlignment which seems fitting. http://dlang.org/phobos/std_traits.html#classInstanceAlignment
Re: BetterC classes
On Friday, 16 December 2016 at 16:24:18 UTC, Daniel N wrote:
On Friday, 16 December 2016 at 15:17:15 UTC, Ilya Yaroshenko
wrote:
Hi
Is it possible to use classes, which do not have monitor and
other DRuntime stuff?
Object can be allocated/deallocated using allocators, but they
are very complex for betterC mode (monitor, mutex, object.d
dependency).
Can we have something more primitive?
Ilya
extern(c++)
class
Works pretty good in my experience, at least it gets rid of the
monitor, yay!
Thanks,
DRuntime is required anyway, but this is step forward.
ldmd2 -betterC -defaultlib= -O -inline -release -run cppclass.d
extern(C++) class Hw
{
import core.stdc.stdio;
this()
{
}
void hw()
{
printf("hey\n");
}
}
import std.traits;
extern(C)
int main()
{
enum classSize = __traits(classInstanceSize, Hw);
align(16)
ubyte[classSize] payload = void;
auto init = cast(const(ubyte)[]) typeid(Hw).initializer;
foreach(i; 0..classSize)
payload[i] = init[i];
auto object = cast(Hw) payload.ptr;
object.__ctor();
object.hw();
return 0;
}
-
Undefined symbols for architecture x86_64:
"__D14TypeInfo_Class6__vtblZ", referenced from:
__D8cppclass2Hw7__ClassZ in cppclass-7ed89bd.o
Re: Allocating a class within another class during object init w/o passing in an allocator
I haven't considered alignment here. I'm not sure if you have to. I though all classes were aligned to sizeof(size_t) boundaries? Wouldn't it then just be align(sizeof(size_t)) byte[__traits(classInstanceSize, SomeClass)] scStorage;
Re: BetterC classes
On Friday, 16 December 2016 at 15:17:15 UTC, Ilya Yaroshenko wrote: Hi Is it possible to use classes, which do not have monitor and other DRuntime stuff? Object can be allocated/deallocated using allocators, but they are very complex for betterC mode (monitor, mutex, object.d dependency). Can we have something more primitive? Ilya extern(c++) class Works pretty good in my experience, at least it gets rid of the monitor, yay!
Re: extern(C++) struct - what is it?
On Friday, 16 December 2016 at 13:02:11 UTC, Nicholas Wilson wrote: On Friday, 16 December 2016 at 12:40:19 UTC, Ilya Yaroshenko wrote: [...] Like any other struct. [...] Thank you Nicholas
BetterC classes
Hi Is it possible to use classes, which do not have monitor and other DRuntime stuff? Object can be allocated/deallocated using allocators, but they are very complex for betterC mode (monitor, mutex, object.d dependency). Can we have something more primitive? Ilya
Re: extern(C++) struct - what is it?
On Friday, 16 December 2016 at 12:40:19 UTC, Ilya Yaroshenko wrote: It was in DMD sources. How it can be used? Are methods virtual? How multiple inheritance works? Can this be used in betterC mode? What different between classes in C++? Thanks, Ilya See also https://dlang.org/spec/cpp_interface.html in particular https://dlang.org/spec/cpp_interface.html#classes
Re: extern(C++) struct - what is it?
On Friday, 16 December 2016 at 12:40:19 UTC, Ilya Yaroshenko wrote: It was in DMD sources. How it can be used? Like any other struct. Are methods virtual? No. How multiple inheritance works? Don't think it works. Can this be used in betterC mode? Yes all it should affect is the mangling. What different between classes in C++? Mangling on MSVC is different for struct and classes, but other that that nothing I think. The difference in default visibility needs to be consistent regardless of class/struct. Do note that declaring extern(C++) class makes it a reference type, like all classes in D. Random other notes: If you're going in the D -> C++ direction, you control there should be no gotcha's. The other way round, you need to make sure that the symbol actually exists (if its a template, that it is instantiated). I think templates work in both directions, i.e. correct mangling coming from C++, and from D. I'm not sure that alias parameters work as they AFAIK don't have an analog in C++. Thanks, Ilya
Re: not callable error
On Friday, 4 November 2016 at 23:26:40 UTC, lobo wrote: On Friday, 4 November 2016 at 14:37:04 UTC, bluphantom91 wrote: On Friday, 4 November 2016 at 02:59:49 UTC, Paul Backus wrote: On Friday, 4 November 2016 at 02:28:17 UTC, bluphantom91 wrote: Hello, Am I just using getc the wrong way? Try something like this: ... ch = getc(file.getFP); ... https://dlang.org/phobos/std_stdio.html#.File.getFP bye, lobo Hi, I having equal problems and it looks like you get the solution. so is it posible to get the full code listing from import to the counting that is working? Just as a conclusive answer for others aswell to read. /anders
extern(C++) struct - what is it?
It was in DMD sources. How it can be used? Are methods virtual? How multiple inheritance works? Can this be used in betterC mode? What different between classes in C++? Thanks, Ilya
Re: Other libraries - web site link, and other thoughts
Forgive if I'm suggesting something which was already discussed and dismissed, but I too would love a way to leverage C++ stuff into D. Can't we go to C++? Meaning there's a C++ compiler coming from the same hands as D. Couldn't we try to get the C++ compiler to compile in such a manner that D can easily pick up the result? I will only use libraries where I have the source code, so from my point of view, I don't need binary compatibility. I also don't need D to pollute itself with the past. But if the Digital Mars C++ compiler could help and assist with creating libs/dlls etc that are properly set up for D and possibly produce the import for D, then it would solve a lot of things. For instance, if a project is in C++, you will need to be able to track revisions to that project, meaning the D conversion should be reasonably painless. Take something like WxWidgets for instance, the D port is stale, but WxWidgets is compatible with Digital Mars. If any project doesn't support Digital Mars C++, then it would be a C++ to C++ port, which is always going to be easier and less volatile than a C++ to D port. Just wondering
Re: reading from file
On 12/15/2016 10:47 PM, KaattuPoochi wrote:
> On Tuesday, 13 December 2016 at 21:13:26 UTC, Ali wrote:
>>
>> And extending Ali's solution you can actually get the data in
>> to a two dimentional array at compile time and have it in static
>> memory with a small adjustment:
>>
>> static immutable matrix = import("data.txt")
>> .split("\n")
>> .map!(a => a.split(",").map!(to!int).array)
>> .array;
>>
>> void main() {
>> writeln(matrix);
>> }
>
> 1. For any non-trivial matrices (with 500 lines) runs DMD 2.072.1 out of
> memory (2GB). Not sure if this is a known bug. Works fine with LDC 1.0.0.
Just to note, there are 501 arrays generated at compile. You can reduce
that number to 1 if you know the width and the height of the matrix. The
following solution reads everything into a single array and then uses it
as an int[N][]:
import std.algorithm;
import std.conv;
import std.array;
import std.stdio;
static immutable buffer = import("deneme.txt")
.splitter
.map!(a => a.splitter(',').map!(to!int))
.joiner
.array;
// Assume these are known or are calculated at compile time:
enum width = 4;
enum height = 3;
immutable int[width][] matrix;
shared static this() {
matrix = (cast(immutable(int[width])*)buffer.ptr)[0..height];
// Make sure we did not copy into matrix
assert(cast(void*)matrix.ptr == cast(void*)buffer.ptr);
}
void main() {
writeln(matrix);
}
> 2. The EOL on the last line results in an empty row in the end. Is there
> a way to overcome this?
As an added bonus, the solution above does not suffer from empty lines.
Ali
Re: reading from file
On Friday, 16 December 2016 at 06:47:15 UTC, KaattuPoochi wrote:
On Tuesday, 13 December 2016 at 21:13:26 UTC, Ali wrote:
And extending Ali's solution you can actually get the data in
to a two dimentional array at compile time and have it in
static memory with a small adjustment:
static immutable matrix = import("data.txt")
.split("\n")
.map!(a => a.split(",").map!(to!int).array)
.array;
void main() {
writeln(matrix);
}
1. For any non-trivial matrices (with 500 lines) runs DMD
2.072.1 out of memory (2GB). Not sure if this is a known bug.
Works fine with LDC 1.0.0.
2. The EOL on the last line results in an empty row in the end.
Is there a way to overcome this?
Most likely you are using a 64bit ldc, and a 32bit dmd.
Since I am pretty sure the ldc guys have no CTFE patches.
I am working on fixing that problem.
