Re: extern(C) enum
On 15/09/2017 5:15 AM, bitwise wrote:
I translated the headers for FreeType2 to D, and in many cases, enums
are used as struct members.
If I declare an extern(C) enum in D, is it guaranteed to have the same
underlying type and size as it would for a C compiler on the same platform?
No need for extern(C). Be as specific as you need, but most likely you
won't need to (e.g. first is automatically 0).
enum Foo : int {
Start = 0,
StuffHere
End
}
Re: Internal error mixing templates and CTFE
On Friday, 15 September 2017 at 05:58:47 UTC, David Bennett wrote: Is this an error in dmd, and should I open a bug report? Internal error is always a bug, so it should be reported! Andrea
Re: extern(C) enum
On Friday, September 15, 2017 04:15:57 bitwise via Digitalmars-d-learn wrote: > I translated the headers for FreeType2 to D, and in many cases, > enums are used as struct members. > > If I declare an extern(C) enum in D, is it guaranteed to have the > same underlying type and size as it would for a C compiler on the > same platform? extern(C) should have no effect on enums. It's for function linkage, and enums don't even have an address, so they don't actually end up in the program as a symbol. And since C's int and D's int are the same on all platforms that D supports (we'd have c_int otherwise, like we have c_long), any enum with a base type of int (which is the default) will match what's in C. - Jonathan M Davis
Re: Internal error mixing templates and CTFE
On Friday, 15 September 2017 at 07:12:36 UTC, Andrea Fontana wrote: Internal error is always a bug, so it should be reported! I have opened a issue: https://issues.dlang.org/show_bug.cgi?id=17828
Re: Access Violation when passing the result of a C function directly to a D function?
On Friday, 15 September 2017 at 04:01:13 UTC, Timothy Foster
wrote:
I'm compiling on Windows 7 x64, DMD32 D Compiler v2.075.1 and
I'm using Derelict Fmod to handle audio in my application.
Every Fmod function returns an int telling me if the function
ran okay, or if there was an error. I've written the following
helper function that will print something for me if it
encounters an error:
static void ErrorFMOD(int result, string msg = ""){
if(result != FMOD_OK)
writeln("[ FMOD ] ", msg, FMOD_ErrorString(result));
}
This function has been causing Access Violation Errors when I
call it. It doesn't happen every time and it doesn't always
happen in the same place. The errors occur _even when I comment
out everything inside the function_. I've been calling it like
so:
ErrorFMOD(FMOD_System_Create(&system), "Error Creating System:
");
Making the calls without my helper function doesn't cause an
Access Violation.
Calling it like this is the only thing that seems to fix it:
auto result = FMOD_System_Create(&system);
ErrorFMOD(result, "Error Creating System: ");
Is this a known issue, or am I required to save the result of a
C function to variable before passing it into another function
or?
Probably you have to use const char * msg when interfacing with
C. string is a struct - size_t length and const char * value
Re: extern(C) enum
On Friday, 15 September 2017 at 06:57:31 UTC, rikki cattermole
wrote:
On 15/09/2017 5:15 AM, bitwise wrote:
I translated the headers for FreeType2 to D, and in many
cases, enums are used as struct members.
If I declare an extern(C) enum in D, is it guaranteed to have
the same underlying type and size as it would for a C compiler
on the same platform?
No need for extern(C). Be as specific as you need, but most
likely you won't need to (e.g. first is automatically 0).
enum Foo : int {
Start = 0,
StuffHere
End
}
This is for D/C interop though.
enum E {
A, B, C
}
struct S {
E e;
}
So based on the underlying type chosen by each compiler, the size
of struct S could change.
I can't strongly type the D enums to match, because I don't know
what size the C compiler will make 'E', unless D somehow
gauntness the same enum-sizing as the C compiler would.
Re: extern(C) enum
On Friday, 15 September 2017 at 07:24:34 UTC, Jonathan M Davis wrote: On Friday, September 15, 2017 04:15:57 bitwise via Digitalmars-d-learn wrote: I translated the headers for FreeType2 to D, and in many cases, enums are used as struct members. If I declare an extern(C) enum in D, is it guaranteed to have the same underlying type and size as it would for a C compiler on the same platform? extern(C) should have no effect on enums. It's for function linkage, and enums don't even have an address, so they don't actually end up in the program as a symbol. And since C's int and D's int are the same on all platforms that D supports (we'd have c_int otherwise, like we have c_long), any enum with a base type of int (which is the default) will match what's in C. - Jonathan M Davis I'm confused...is it only C++ that has implementation defined enum size? I thought that was C as well.
Re: Internal error mixing templates and CTFE
On Friday, 15 September 2017 at 05:58:47 UTC, David Bennett wrote: Hi Guys, I've been playing around with CTFE today to see how far I would push it but I'm having an issue appending to an array on a struct in CTFE from a template: [...] are you using ucent ?
Re: failed loading freetype 2.6 via derelict-ft
On Friday, 15 September 2017 at 05:16:55 UTC, Mike Parker wrote:
On Wednesday, 13 September 2017 at 22:18:07 UTC, Mike Parker
wrote:
Missing symbols usually mean a version mismatch. The latest
DerelictFT requires FreeType 2.6 or later. It could also mean
your shared library was compiled without bzip2 support. I'm on
my phone right now else I'd check it myself, but if your
library os up to date you can use derelict's selective loading
mechanism to ignore missing symbols you don't need.
http://derelictorg.github.io/loading/failure/
Digging through the FreeType changelogs, I think it likely that
it's a configuration issue -- your copy of the freetype shared
library was compiled without bzip2 support.
Thanks for the reply that is exactly it. I downloaded several
dlls from the internet, and then decided to build it myself. I
see there is a bzip configuration option but I'll need to read
the documentation and presumably bzip gets linked into the dll.
I managed to get the application running by ignoring these
missing functions:
if(
symbolName == "FT_Stream_OpenBzip2" ||
symbolName ==
"FT_Get_CID_Registry_Ordering_Supplement" ||
symbolName ==
"FT_Get_CID_Is_Internally_CID_Keyed" ||
symbolName == "FT_Get_CID_From_Glyph_Index"
) {
I imagine there will be a crash if they actually get called.
Re: Access Violation when passing the result of a C function directly to a D function?
On Friday, 15 September 2017 at 10:33:55 UTC, Vadim Lopatin wrote: On Friday, 15 September 2017 at 04:01:13 UTC, Timothy Foster wrote: [...] Probably you have to use const char * msg when interfacing with C. string is a struct - size_t length and const char * value The string doesn't touch any C functions, it just gets printed in the writeln() call.
Re: Access Violation when passing the result of a C function directly to a D function?
On Friday, 15 September 2017 at 04:01:13 UTC, Timothy Foster wrote: am I required to save the result of a C function to variable before passing it into another function or? No. You probably have stack corruption. Does it crash if FMOD_System_Create returns ok?
Re: Access Violation when passing the result of a C function directly to a D function?
On Friday, 15 September 2017 at 16:55:27 UTC, Kagamin wrote:
On Friday, 15 September 2017 at 04:01:13 UTC, Timothy Foster
wrote:
am I required to save the result of a C function to variable
before passing it into another function or?
No. You probably have stack corruption. Does it crash if
FMOD_System_Create returns ok?
FMOD_System_Create is always returning FMOD_OK. I have zero
issues when I save the result of a fmod function to a variable
before passing it to my helper function.
Sometimes crashes:
ErrorFMOD(Some_FMOD_Function(...), "print text");
Never crashes:
auto result = Some_FMOD_Function(...);
ErrorFMOD(result, "print text");
The crashes happen even if ErrorFMOD is an empty function:
void ErrorFMOD(int r, string s = ""){
//nothing happening
}
Re: Ranges suck!
On Thursday, 14 September 2017 at 23:53:20 UTC, Your name wrote:
[...]
I understand your frustration. The fact that "inout" is actually
a keyword makes it hard not to think that some very strange
fetishes were at play during the creation of this language.
As a whole though, the language is very usable, and has many
great features not present in similar languages.
Just this morning, I was able to replace a fairly large and ugly
pile of code with this:
import std.utf;
foreach(c; myString.byUTF!dchar) {
// ...
}
Re: extern(C) enum
On Friday, September 15, 2017 15:35:48 bitwise via Digitalmars-d-learn wrote: > On Friday, 15 September 2017 at 07:24:34 UTC, Jonathan M Davis > > wrote: > > On Friday, September 15, 2017 04:15:57 bitwise via > > > > Digitalmars-d-learn wrote: > >> I translated the headers for FreeType2 to D, and in many > >> cases, enums are used as struct members. > >> > >> If I declare an extern(C) enum in D, is it guaranteed to have > >> the same underlying type and size as it would for a C compiler > >> on the same platform? > > > > extern(C) should have no effect on enums. It's for function > > linkage, and enums don't even have an address, so they don't > > actually end up in the program as a symbol. And since C's int > > and D's int are the same on all platforms that D supports (we'd > > have c_int otherwise, like we have c_long), any enum with a > > base type of int (which is the default) will match what's in C. > > > > - Jonathan M Davis > > I'm confused...is it only C++ that has implementation defined > enum size? I thought that was C as well. It is my understanding that for both C and C++, an enum is always an int (unless you're talking about enum classes in C++). The size of an int can change based on your architecture, but AFAIK, all of the architectures supported by D guarantee it it be 32 bits in C/C++ (certainly, all of the architectures supported by dmd do), and druntime would have serious issues if it were otherwise, as it assumes all of the place that D's int is the same as C/C++'s int. It's certainly possible that my understanding of C/C++ enums is wrong, but if it is, you'd basically be screwed when dealing with any C functions that take an enum in any case that an enum wasn't 32 bits - especially if the C/C++ compiler could choose whatever size it wanted that fit the values. - Jonathan M Davis
Re: extern(C) enum
On Friday, 15 September 2017 at 18:20:06 UTC, Jonathan M Davis
wrote:
It is my understanding that for both C and C++, an enum is
always an int (unless you're talking about enum classes in
C++). The size of an int can change based on your architecture,
but AFAIK, all of the architectures supported by D guarantee it
it be 32 bits in C/C++ (certainly, all of the architectures
supported by dmd do), and druntime would have serious issues if
it were otherwise, as it assumes all of the place that D's int
is the same as C/C++'s int.
It's certainly possible that my understanding of C/C++ enums is
wrong, but if it is, you'd basically be screwed when dealing
with any C functions that take an enum in any case that an enum
wasn't 32 bits - especially if the C/C++ compiler could choose
whatever size it wanted that fit the values.
- Jonathan M Davis
Not to hijack the thread, but is there anything about enums that
can't be done with a struct? The code below is just a simple
example that I'm sure I could complicate unnecessarily to
re-create much of the behavior of current enums with the syntax
of std.tuple.
I suppose what I'm wondering how E.B below is treated in the
writeln. With an enum, it would be a manifest constant. Does
static initialization of the struct do the same thing?
struct Enum(T)
{
T A;
T B;
}
static Enum!int E = {A:0, B:1};
void main()
{
import std.stdio : writeln;
writeln(E.B);
}
Re: extern(C) enum
On Friday, 15 September 2017 at 15:35:48 UTC, bitwise wrote: On Friday, 15 September 2017 at 07:24:34 UTC, Jonathan M Davis wrote: On Friday, September 15, 2017 04:15:57 bitwise via Digitalmars-d-learn wrote: I translated the headers for FreeType2 to D, and in many cases, enums are used as struct members. If I declare an extern(C) enum in D, is it guaranteed to have the same underlying type and size as it would for a C compiler on the same platform? extern(C) should have no effect on enums. It's for function linkage, and enums don't even have an address, so they don't actually end up in the program as a symbol. And since C's int and D's int are the same on all platforms that D supports (we'd have c_int otherwise, like we have c_long), any enum with a base type of int (which is the default) will match what's in C. - Jonathan M Davis I'm confused...is it only C++ that has implementation defined enum size? I thought that was C as well. I believe C enum size is implementation defined. A C compiler can pick the underlying type (1, 2, or 4 bytes, signed or unsigned) that fits the values in the enum. A D int is always the same size as a C int because C ints are 4 bytes on 32bit and above architectures and D doesn't support architectures below 32bit so you never run into a case where a C int is 2 bytes. D can't guarantee that the size of an extern(C) enum will match an arbitrary C compiler's choice, so I'm pretty sure it'll just default to a D int. It's further likely that padding in a struct will differ between C compilers so if you need a D struct to be the same size as a C struct in every case... welp that's not exactly going to be fun.
Re: extern(C) enum
On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster wrote: I believe C enum size is implementation defined. A C compiler can pick the underlying type (1, 2, or 4 bytes, signed or unsigned) that fits the values in the enum. No, at least, not C99. See 6.4.4.3: "An identifier declared as an enumeration constant has type int". You must be thinking about C++.
Re: extern(C) enum
On Friday, 15 September 2017 at 19:35:50 UTC, nkm1 wrote: On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster wrote: I believe C enum size is implementation defined. A C compiler can pick the underlying type (1, 2, or 4 bytes, signed or unsigned) that fits the values in the enum. No, at least, not C99. See 6.4.4.3: "An identifier declared as an enumeration constant has type int". You must be thinking about C++. Thanks - this works for me. The bindings are for an open source C library. So I guess I'm safe as long as I can be sure I'm using a C99 compiler and strongly typing as int in D. C++ seems to be a much more complicated situation, but it appears that for 'enum class' or 'enum struct' the underlying type is int, even when it's not specified. ยง 7.2: [1] "The enum-keys enum class and enum struct are semantically equivalent; an enumeration type declared with one of these is a scoped enumeration, and its enumerators are scoped enumerators." [2] "For a scoped enumeration type, the underlying type is int if it is not explicitly specified." [1][2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4296.pdf Shame that even relatively new C++ code tends to use unscoped enums.
Re: failed loading freetype 2.6 via derelict-ft
On Friday, 15 September 2017 at 16:04:52 UTC, Spacen wrote:
Thanks for the reply that is exactly it. I downloaded several
dlls from the internet, and then decided to build it myself. I
see there is a bzip configuration option but I'll need to read
the documentation and presumably bzip gets linked into the dll.
I managed to get the application running by ignoring these
missing functions:
if(
symbolName == "FT_Stream_OpenBzip2" ||
symbolName ==
"FT_Get_CID_Registry_Ordering_Supplement" ||
symbolName ==
"FT_Get_CID_Is_Internally_CID_Keyed" ||
symbolName == "FT_Get_CID_From_Glyph_Index"
) {
I imagine there will be a crash if they actually get called.
If you call them, yes. Or if you link with any third-party D
libraries that call them with the expectation that you've loaded
them (but I don't know of any such thing).
Re: extern(C) enum
On Friday, September 15, 2017 19:04:56 jmh530 via Digitalmars-d-learn wrote:
> On Friday, 15 September 2017 at 18:20:06 UTC, Jonathan M Davis
>
> wrote:
> > It is my understanding that for both C and C++, an enum is
> > always an int (unless you're talking about enum classes in
> > C++). The size of an int can change based on your architecture,
> > but AFAIK, all of the architectures supported by D guarantee it
> > it be 32 bits in C/C++ (certainly, all of the architectures
> > supported by dmd do), and druntime would have serious issues if
> > it were otherwise, as it assumes all of the place that D's int
> > is the same as C/C++'s int.
> >
> > It's certainly possible that my understanding of C/C++ enums is
> > wrong, but if it is, you'd basically be screwed when dealing
> > with any C functions that take an enum in any case that an enum
> > wasn't 32 bits - especially if the C/C++ compiler could choose
> > whatever size it wanted that fit the values.
> >
> > - Jonathan M Davis
>
> Not to hijack the thread, but is there anything about enums that
> can't be done with a struct? The code below is just a simple
> example that I'm sure I could complicate unnecessarily to
> re-create much of the behavior of current enums with the syntax
> of std.tuple.
>
> I suppose what I'm wondering how E.B below is treated in the
> writeln. With an enum, it would be a manifest constant. Does
> static initialization of the struct do the same thing?
>
> struct Enum(T)
> {
> T A;
> T B;
> }
>
> static Enum!int E = {A:0, B:1};
>
> void main()
> {
> import std.stdio : writeln;
>
> writeln(E.B);
> }
If you do that instead of using enum, you completely lose the extra bit of
type safety that enums give you (e.g. assigning a string to a variable whose
type is an enum that's a base type of string is not legal) - though the type
system is still annoyingly liberal with what it allows for enums (e.g.
appending to an enum of base type string is legal, and doing bitwise
operations on an enum results in the enum type instead of the base integral
type). And final switch wouldn't work with the struct, whereas it does with
enums. Also, a number of things in the standard library specifically treat
enums in a special way (e.g to!string and writeln use the enum's name rather
than it's value), and that would not happen with your struct. With your
struct, you've just namespaced a group of constants. Other than that,
they're the same as if they were declared outside of the struct, and while
IMHO D's enums are annoyingly lax in some of what they allow, they do do
more with the type system than a manifest constant would.
- Jonathan M Davis
Re: extern(C) enum
On Friday, 15 September 2017 at 19:35:50 UTC, nkm1 wrote:
On Friday, 15 September 2017 at 19:21:02 UTC, Timothy Foster
wrote:
I believe C enum size is implementation defined. A C compiler
can pick the underlying type (1, 2, or 4 bytes, signed or
unsigned) that fits the values in the enum.
No, at least, not C99. See 6.4.4.3: "An identifier declared as
an enumeration constant has type int". You must be thinking
about C++.
You are correct, however 6.7.2.2 "Enumeration specifiers" states:
"Each enumerated type shall be compatible with char, a signed
integer type, or an unsigned integer type. The choice of type is
implementation-defined, but shall be capable of representing the
values of all the members of the enumeration."
I believe that means that if you have the following:
enum ABC { A, B, C }
Then A, B, and C are by themselves ints, but the enum type ABC
can be a char if the compiler decides that's what it wants it to
be.
Convert user input string to Regex
Hi, Is there a way to transform user input string to a regular expression? For example, I want to write a `grep`-like program ``` mygrep -E '/pattern/i' file.txt ``` and here the user's parameter `/pattern/i` would be converted to a Regex object. Fyi, in Ruby, `to_regexp` is a useful gem: https://rubygems.org/gems/to_regexp Thanks a lot.
Re: Convert user input string to Regex
On Saturday, 16 September 2017 at 03:18:31 UTC, Ky-Anh Huynh wrote: Is there a way to transform user input string to a regular expression? For example, I want to write a `grep`-like program import std.regex; auto re = regex(user_pattern, user_flags); You'll probably want to split it on the '/' to split the pattern and the flags since they are two separate variables to the regex function, but that's all you need to do. http://dpldocs.info/experimental-docs/std.regex.regex.2.html
Binary serialization of a struct
Are there any simple direct serialization libraries where I can mark elements of a class or struct that I want serialized with an attribute and it will take care of all the rest(including recursive structures, arrays, etc) then deserialize back in to the structs? I want something straight forward without allot of plumbing on my end.
How to get DnD to work in GTKD?
This is my code:
TargetEntry te = new TargetEntry("test",
GtkTargetFlags.OTHER_APP, 0);
w.dragDestSet(GtkDestDefaults.ALL, [te], GdkDragAction.COPY);
w.addOnDragDataReceived((dragContext, x, y, selectionData, info,
time, widget)
{
writeln("ok1");
});
w.addOnDragDrop((dragContext, x, y, time, widget)
{
writeln("ok2");
return true;
});
w.addOnDragDataGet((dragContext, selectionData, info, time,
widget)
{
writeln("ok3");
});
I've used null in place of [te]. I'm not sure what target entry
is for and if that is the problem or what. I am trying to drag
files from windows explorer to a grid or label(I duplicated the
code above for the label) and none the callbacks are ever called.
I only need the filename of the file being dragged.
I will eventually also need to drag one list element to
another(virtually so, I just need to know the index that was
dragged).
Thanks.
