Re: D float types operations vs C++ ones
On Friday, 18 December 2015 at 07:30:52 UTC, drug wrote: What I mean about order of operations is that if you go a = b*a+c*c + e; the compiler is free to rewrite that as float __tmp0 = a*b; float __tmp1 = c*c; and then do either of float __tmp2 = __tmp0+__tmp1; a = __tmp2 + e; OR float __tmp2 = __tmp0+e; a = __tmp2+__tmp1; I see, thanks to all! I don't think this can be right, unless you use some kind of fast-math optimizer. But: Modern C++ compilers try to support ieee754-2008, which is needed to get reproducible results. D is based on the older 1985 version, and there is no announced effort to make it modern.
Re: View Expanded Templates?
On 12/18/2015 10:54 AM, Taylor Hillegeist wrote:
> pragma(msg, code_generation_function())
>
>
> simple + awesome.
Yes, and perhaps unittest blocks:
unittest
{
assert(makeCode("foo") == "int foo = 42;");
}
Unfortunately, neither works with template mixins or regular templates.
Ali
View Expanded Templates?
Is it possible to view the expanded form of templates or perhaps view the post-ctfe pre-compiled d code? I couldn't find any information on this topic but I think it would be useful. sometimes I use templates/mixins to write code for me but, sometimes i would rather have the expanded functions in the final versions.
Re: View Expanded Templates?
On Friday, 18 December 2015 at 18:25:03 UTC, Taylor Hillegeist wrote: Is it possible to view the expanded form of templates or perhaps view the post-ctfe pre-compiled d code? I couldn't find any information on this topic but I think it would be useful. sometimes I use templates/mixins to write code for me but, sometimes i would rather have the expanded functions in the final versions. Check out my tip of the week from last month: http://arsdnet.net/this-week-in-d/nov-22.html If you just write out the string yourself instead of mixing it in, you can get a lot of progress on it.
Re: D float types operations vs C++ ones
On 12/18/2015 12:19 AM, Ola Fosheim Gr wrote: On Friday, 18 December 2015 at 07:30:52 UTC, drug wrote: What I mean about order of operations is that if you go a = b*a+c*c + e; the compiler is free to rewrite that as float __tmp0 = a*b; float __tmp1 = c*c; and then do either of float __tmp2 = __tmp0+__tmp1; a = __tmp2 + e; OR float __tmp2 = __tmp0+e; a = __tmp2+__tmp1; I see, thanks to all! I don't think this can be right, unless you use some kind of fast-math optimizer. But: Modern C++ compilers try to support ieee754-2008, which is needed to get reproducible results. D is based on the older 1985 version, and there is no announced effort to make it modern. Thank you for the reference. If the Wikipedia article is precise in language, it is just a recommendation: "Clause 10: Expression evaluation This clause is new; it recommends how language standards should specify the semantics of sequences of operations, and points out the subtleties of literal meanings and optimizations that change the value of a result." https://en.wikipedia.org/wiki/IEEE_754_revision#Clause_10:_Expression_evaluation Ali
Re: View Expanded Templates?
On Friday, 18 December 2015 at 18:35:40 UTC, Adam D. Ruppe wrote: On Friday, 18 December 2015 at 18:25:03 UTC, Taylor Hillegeist wrote: Is it possible to view the expanded form of templates or perhaps view the post-ctfe pre-compiled d code? I couldn't find any information on this topic but I think it would be useful. sometimes I use templates/mixins to write code for me but, sometimes i would rather have the expanded functions in the final versions. Check out my tip of the week from last month: http://arsdnet.net/this-week-in-d/nov-22.html If you just write out the string yourself instead of mixing it in, you can get a lot of progress on it. pragma(msg, code_generation_function()) simple + awesome. :)
Scope of D packages
I'm coming from Java where "packages" are not that much more than directories. Each class can be exposed or hidden inside a package etc. In Java it is common that an API consists of many packages and subpackages. All classes are simply wrapped up in a JAR (Zip) file, and then they can be used as a library. What is common in D? Does a library have all its classes inside the same package (same directory) ? Or can you have multiple packages / subpackages inside the same library *and* same source root?
Re: D programming video tutorial
I have a few videos on about D on YT. But those are ... well suboptimal. I will probably talk a bit about SDC... when time permits
Re: Scope of D packages
To be exact it doesn't need the sources, it needs the function signatures and type definitions so the equivalent of C header files. If you don't want to share the full sources with your library you can generate those header files automatically using the -H flag in dmd. It will produce a "D interface" file with a "di" extension. But - if the library was open source, it would be better to just share the sources than a compiled file? (In Java we share/use the zipped JAR file with compiled classes).
Re: Scope of D packages
On Saturday, 19 December 2015 at 00:52:40 UTC, Jakob Jenkov wrote: To be exact it doesn't need the sources, it needs the function signatures and type definitions so the equivalent of C header files. If you don't want to share the full sources with your library you can generate those header files automatically using the -H flag in dmd. It will produce a "D interface" file with a "di" extension. But - if the library was open source, it would be better to just share the sources than a compiled file? (In Java we share/use the zipped JAR file with compiled classes). If it's open source it's better to share the sources, sure. As the compiler is able to do more optimization when it has all the sources at hand it is customary to limit the use of shared libraries and just compile everything at once (although you can quickly run into things like memory limitations as it demands quite a lot of resources). Typically you'd segment your compilation by module if needed. If you are to give the sources (with or without a standalone lib) then you allow your users to benefit from such optimizations if they want to, so it's better to give the sources when possible. D Interface files are there mostly (only?) to answer the problematic of closed source libraries.
Re: Problems with string literals and etc.c.odbc.sql functions
On Friday, 18 December 2015 at 22:18:34 UTC, Adam D. Ruppe wrote: That's what the examples on MSDN do too though, a cast. At first I thought the binding was missing a const, but the ODBC docs don't specify it as const either and cast. The ODBC functions also have a size parameter for string parameters. You can set it to SQL_NTS to use the 0 terminated C standard. Might justify on why it's char* instead of const char*. It looks like it's alright, then. Just one implementation detail I didn't notice before.
Re: Scope of D packages
On Saturday, 19 December 2015 at 00:09:16 UTC, Basile B. wrote: On Friday, 18 December 2015 at 23:20:34 UTC, Jakob Jenkov wrote: I'm coming from Java where "packages" are not that much more than directories. Each class can be exposed or hidden inside a package etc. In Java it is common that an API consists of many packages and subpackages. All classes are simply wrapped up in a JAR (Zip) file, and then they can be used as a library. What is common in D? Does a library have all its classes inside the same package (same directory) ? Or can you have multiple packages / subpackages inside the same library *and* same source root? each sub directory in a package is also a package lib/package.d : allow to put all the lib modules as public import lib/module1.d : this is module 1 from package lib lib/module2.d : this is module 2 from package lib lib/sub1/package.d : allow to put all the lib.sub1 modules as public import lib/sub1/module1: this is module 1 from package lib.sub1 lib/sub1/module2: this is module 2 from package lib.sub1 but when you compile 'lib' library it's a monolithic *.a or *.lib file, which still requires the sources. look at https://github.com/gecko0307/dlib/tree/master/dlib structure for example. To be exact it doesn't need the sources, it needs the function signatures and type definitions so the equivalent of C header files. If you don't want to share the full sources with your library you can generate those header files automatically using the -H flag in dmd. It will produce a "D interface" file with a "di" extension.
Re: Scope of D packages
On Friday, 18 December 2015 at 23:20:34 UTC, Jakob Jenkov wrote: I'm coming from Java where "packages" are not that much more than directories. Each class can be exposed or hidden inside a package etc. In Java it is common that an API consists of many packages and subpackages. All classes are simply wrapped up in a JAR (Zip) file, and then they can be used as a library. What is common in D? Does a library have all its classes inside the same package (same directory) ? Or can you have multiple packages / subpackages inside the same library *and* same source root? each sub directory in a package is also a package lib/package.d : allow to put all the lib modules as public import lib/module1.d : this is module 1 from package lib lib/module2.d : this is module 2 from package lib lib/sub1/package.d : allow to put all the lib.sub1 modules as public import lib/sub1/module1: this is module 1 from package lib.sub1 lib/sub1/module2: this is module 2 from package lib.sub1 but when you compile 'lib' library it's a monolithic *.a or *.lib file, which still requires the sources. look at https://github.com/gecko0307/dlib/tree/master/dlib structure for example.
Re: Problems with string literals and etc.c.odbc.sql functions
On Friday, 18 December 2015 at 22:35:04 UTC, anonymous wrote: If the parameter is de facto const, then the cast is ok. Though, maybe it should be marked const then. I'm just worried about casts because I read somewhere that strings start with the number of characters inside them (probably in slices documentation), and not with actual content (though string literals probably act different in this case). Documentation on casts say: Casting a pointer type to and from a class type is done as a type paint (i.e. a reinterpret cast). Reinterpretation is rather dangerous if strings are stored differently. But this test gives me a good hope on this case: writeln(*(cast(char*) "Test")); Casting is what I'm going with. .dup.ptr is less clear in this case.
Re: View Expanded Templates?
On Friday, 18 December 2015 at 18:25:03 UTC, Taylor Hillegeist wrote: Is it possible to view the expanded form of templates or perhaps view the post-ctfe pre-compiled d code? I couldn't find any information on this topic but I think it would be useful. sometimes I use templates/mixins to write code for me but, sometimes i would rather have the expanded functions in the final versions. I am builing a tool based on SDC that will allow just that :)
DUB config format: SDLang or JSON?
I am just looking at DUB and I can read that there are two config formats: SDLang and JSON. Which one is the "new" format? Which one is the "future" of DUB?
Re: DUB config format: SDLang or JSON?
On Friday, 18 December 2015 at 22:30:00 UTC, Jakob Jenkov wrote: I am just looking at DUB and I can read that there are two config formats: SDLang and JSON. Which one is the "new" format? Which one is the "future" of DUB? SDLang is the new one. JSON will remain supported. Use whichever you like better.
Problems with string literals and etc.c.odbc.sql functions
By the use of this tutorial (http://www.easysoft.com/developer/languages/c/odbc_tutorial.html), I thought it would be very straightforward to use etc.c.odbc.sqlext and etc.c.odbc.sql to create a simple odbc application. But as soon as I started, I noticed a quirk: SQLRETURN ret; SQLHDBC dbc; ret = SQLDriverConnect(dbc, null, "DNS=*mydns*;", SQL_NTS, null, 0, null, SQL_DRIVER_COMPLETE); This gives me an error: function etc.c.odbc.sqlext.SQLDriverConnect (void* hdbc, void* hwnd, char* szConnStrIn, short cbConnStrIn, char* szConnStrOut, short cbConnStrOutMax, short* pcbConnStrOut, ushort fDriverCompletion) is not callable using argument types (void*, typeof(null), string, int, typeof(null), int, typeof(null), int) After some casting, I found out it's all related to the string literal. I thought it would work straight off the box, after reading the "Interfacing to C" spec (http://dlang.org/spec/interfaceToC.html). When I remove the string literal and replace it with null, it compiles. .ptr and .toStringz both give immutable char* references, and don't work. A "cast(char *)"DNS=*maydns*;"" works, but it feels a lot like a hack that will not work in the long run.
Re: Problems with string literals and etc.c.odbc.sql functions
On 18.12.2015 23:14, Fer22f wrote: By the use of this tutorial (http://www.easysoft.com/developer/languages/c/odbc_tutorial.html), I thought it would be very straightforward to use etc.c.odbc.sqlext and etc.c.odbc.sql to create a simple odbc application. But as soon as I started, I noticed a quirk: SQLRETURN ret; SQLHDBC dbc; ret = SQLDriverConnect(dbc, null, "DNS=*mydns*;", SQL_NTS, null, 0, null, SQL_DRIVER_COMPLETE); This gives me an error: function etc.c.odbc.sqlext.SQLDriverConnect (void* hdbc, void* hwnd, char* szConnStrIn, short cbConnStrIn, char* szConnStrOut, short cbConnStrOutMax, short* pcbConnStrOut, ushort fDriverCompletion) is not callable using argument types (void*, typeof(null), string, int, typeof(null), int, typeof(null), int) After some casting, I found out it's all related to the string literal. I thought it would work straight off the box, after reading the "Interfacing to C" spec (http://dlang.org/spec/interfaceToC.html). When I remove the string literal and replace it with null, it compiles. .ptr and .toStringz both give immutable char* references, and don't work. A "cast(char *)"DNS=*maydns*;"" works, but it feels a lot like a hack that will not work in the long run. If the parameter is de facto const, then the cast is ok. Though, maybe it should be marked const then. If the parameter is really not const, i.e. the function may mutate the argument, then the cast is not ok. You can use `.dup.ptr` instead to get a proper char* from a string. Also, remember that D's GC doesn't scan foreign memory. So if the function keeps the string around, and that's the only reference, then the GC would collect it. The function probably doesn't keep the string around, though.
Re: D programming video tutorial
I have written more than 750 tutorials about Java ... and web development and other related stuff. Not only Java.
Re: D programming video tutorial
On Sunday, 13 December 2015 at 20:29:47 UTC, Pederator wrote: Hi. Does anybody who is familair with D consider to make a comprehensive D programming video tutorial / training / course? This could be encouraging and helpful for people to start with D. It could also help in promoting D programming language. This is a question for all the community, please comment what do you think about this idea, we will know if there is an interest in such a training video, or is it just me. Hi, I have written more than 750 tutorials about Java, and made 19 videos. My experience is, that once I have the written tutorial then I also have the TOC for the corresponding video. I can usually record a screencast in about 0,5 to 2 hours, and then it takes about the same time to put the screencast parts together into a coherent video. Someone else can normally do that, though. I have been thinking about writing about D too. Maybe make a few videos. But I don't know... I don't know how big the interest is in total.
Re: Problems with string literals and etc.c.odbc.sql functions
On Friday, 18 December 2015 at 22:14:04 UTC, Fer22f wrote: When I remove the string literal and replace it with null, it compiles. .ptr and .toStringz both give immutable char* references, and don't work. A "cast(char *)"DNS=*maydns*;"" works, but it feels a lot like a hack that will not work in the long run. That's what the examples on MSDN do too though, a cast. At first I thought the binding was missing a const, but the ODBC docs don't specify it as const either and cast. So it is kinda weird but I think right according to docs. However, I'd argue we should make it const if it can be...
Re: D programming video tutorial
On Friday, 18 December 2015 at 22:35:45 UTC, Jakob Jenkov wrote: On Sunday, 13 December 2015 at 20:29:47 UTC, Pederator wrote: I have been thinking about writing about D too. Maybe make a few videos. But I don't know... I don't know how big the interest is in total. Well considering documentation is one of Ds biggest criticizers, i think a video would be very high in demand. Not that you can explain much in a single video but the video is supposed to be a tutorial.
Re: Problems with string literals and etc.c.odbc.sql functions
On 19.12.2015 01:06, Fer22f wrote: Documentation on casts say: Casting a pointer type to and from a class type is done as a type paint (i.e. a reinterpret cast). That sentence doesn't apply. string is not a class, it's an alias for immutable(char)[], i.e. it's an array. Reinterpretation is rather dangerous if strings are stored differently. But this test gives me a good hope on this case: writeln(*(cast(char*) "Test")); Casting is what I'm going with. .dup.ptr is less clear in this case. Correctness beats clarity. I'd like to advise you not to use casts unless you know for sure that they're safe. Here, you need to know what a string is exactly, what the cast does exactly, and what exactly the called function does with the pointer.
