Re: What is iota function full name
So basically iota spills Increments Over The Array. Am 21.06.2019 um 11:18 schrieb Jonathan M Davis: On Friday, June 21, 2019 3:01:17 AM MDT lili via Digitalmars-d-learn wrote: Hi Guys: What is range.iota function full name iota _is_ its full name. It's named after an STL function which does basically the same with iterators in C++: https://en.cppreference.com/w/cpp/algorithm/iota Apparently, C++ got it from the APL programming language, which uses Greek characters and other symbols that you can't find on most keyboards, which makes APL code more like what you see in equations in a math textbook, and APL uses the Greek letter iota for a function with similar behavior to the C++ and D functions. And since unlike APL, C++ couldn't use the Greek letter, when they named their version of the function, they used the name of the letter rather than the letter. And then D's function name was named after the C++ function. So, iota is the name of the function, and it doesn't stand for anything. It's just the name of the Greek letter that was used for a similar function in another language that most programmers these days have probably never heard of. - Jonathan M Davis
Re: Use of GUID constants
For GUIDs you often have to take the address (e.g. for calls to QueryInterface), so I think phobos does not correctly implement this. In the meantime I took a look at the VisualD project which accesses the COM interfaces of visual studio. They solve the problem by using the following idiom (see https://github.com/D-Programming-Language/visuald/blob/master/sdk/port/servprov.d for an example): const GUID IID_IServiceProvider = IServiceProvider.iid; interface IServiceProvider : IUnknown { static const GUID iid = { 0x6d5140c1, 0x7436, 0x11ce, [ 0x80, 0x34, 0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] }; public: /* [local] */ HRESULT QueryService( /* [in] */ in GUID* guidService, /* [in] */ in IID* riid, /* [out] */ void **ppvObject); } If every interface declaration contains the static iid member this enables you to provide something similar to the the __uuidof operator in VisualC (see https://msdn.microsoft.com/de-de/library/zaah6a61.aspx). In VisualD something along that line is implemented in the qi_cast template (see https://github.com/D-Programming-Language/visuald/blob/master/stdext/com.d). Is the above pair (const GUID and static member) the right way to declare this idiom or would the following be better ? Both compile and seem to be equivalent (in terms of achieving the same goal): enum IID IID_IServiceProvider = { 0x6d5140c1, 0x7436, 0x11ce, [ 0x80, 0x34, 0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] }; interface IServiceProvider : IUnknown { static immutable GUID iid = IID_IServiceProvider; public: /* [local] */ HRESULT QueryService( /* [in] */ in GUID* guidService, /* [in] */ in IID* riid, /* [out] */ void **ppvObject); } Thanks for your insights -- KlausO Am 10.03.2016 um 14:49 schrieb Mike Parker: On Thursday, 10 March 2016 at 10:16:30 UTC, KlausO wrote: Ok, but what's the intention behind defining GUIDs as enums in the first place ? Probably just an implementation error, i.e. someone not fully appreciating how GUIDs are intended to be used. Is there a recommended way to declare/define constants (e.g. as enums or consts) ? Generally, you should use a manifest constant, e.g. enum myConst = 10; Unless you need to take the address, then you should use immutable: immutable myConst = 10; The value of a manifest constant is substituted for the symbol at the point of use and is not stored in the data segment (so has no memory address), but an immutable (or const) variable is stored in the data segment.
Re: Use of GUID constants
Ok, but what's the intention behind defining GUIDs as enums in the first place ? Why not defining them as const(GUID) and let the linker sort them out ? Is there a recommended way to declare/define constants (e.g. as enums or consts) ? In C (separate compilation) they are declared as "EXTERN_C const GUID" and you use one C file to define this GUIDs for the Linker. Thanks -- KlausO For the record, found two somehow related issues in bugzilla: https://issues.dlang.org/show_bug.cgi?id=14309 https://issues.dlang.org/show_bug.cgi?id=4092 Am 09.03.2016 um 23:20 schrieb Ali Çehreli: On 03/09/2016 10:35 AM, KlausO wrote: > IUnknown pUnk; > > // > // Does not compile: > // > // Error: function > core.sys.windows.unknwn.IUnknown.QueryInterface(const(GUID)* riid, > void** pvObject) is not callable using argument types (const(GUID), void**) > // > hr = storage.QueryInterface(IID_IUnknown, cast(void**)&pUnk); Without any experience with COM or (current) Windows programming, just by looking at that error message, the following may work: IID unknown = IID_IUnknown; // (Apparently, IID is an alias for const(GUID).) storage.QueryInterface(&unknown, /* ... */); Ali
Use of GUID constants
Dear list, I use DMD 2.070.0 I try to access COM Interfaces via the declarations in core.sys.windows.* I have some problems and maybe someone could give me a usage hint. Have a look at the following (relatively meaningless) sample program which demonstrates the problem. IMHO the problem is that GUID constants are declared as enums in the winapi bindings (see src\druntime\import\core\sys\windows\uuid.d). Within the dclient.d sample which comes with dmd they are explicitely defined as GUIDs: GUID IID_IHello = { 0x00421140, 0, 0, [0xC0, 0, 0, 0, 0, 0, 0, 0x46] }; So maybe they should be declared as "extern GUID ..." because they also seem to be defined in windows\lib\uuid.lib which comes with DMD. What do you think ? Thanks -- KlausO Sample program: import std.stdio; import std.utf; import core.stdc.stdlib; import core.sys.windows.windows; import core.sys.windows.com; import core.sys.windows.objidl; bool CreateCompoundDoc(const wstring filename) { IStorage storage; HRESULT hr = StgCreateDocfile( toUTF16z(filename), STGM_READWRITE | STGM_SHARE_EXCLUSIVE | STGM_DIRECT | STGM_CREATE, 0, &storage); if (S_OK == hr) { IUnknown pUnk; // // Does not compile: // // Error: function core.sys.windows.unknwn.IUnknown.QueryInterface(const(GUID)* riid, void** pvObject) is not callable using argument types (const(GUID), void**) // hr = storage.QueryInterface(IID_IUnknown, cast(void**)&pUnk); // // Does not compile either: // // Error: GUID(0u, cast(ushort)0u, cast(ushort)0u, [cast(ubyte)192u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)0u, cast(ubyte)70u]) is not an lvalue // hr = storage.QueryInterface(&IID_IUnknown, cast(void**)&pUnk); } } int main(string[] argv) { HRESULT hr=CoInitialize(null); // Initialize OLE if (FAILED(hr)) { printf("OLE 2 failed to initialize\n"); return EXIT_FAILURE; } CreateCompoundDoc("hello.doc"); // Only call this if CoInitialize worked CoUninitialize(); return EXIT_SUCCESS; }
scope keyword within template mixins
Hi D users, I created/tested a little logging class under DMD 1.062: //- // // helper class for debugging/logging // import std.string; import std.stdio; scope class LogEnter { static int mIndent; static char[] doindent() { return "\n" ~ repeat(" ", mIndent); } this(char[] text) { mText = text; writef(doindent() ~ "<" ~ mText ~ ">"); mIndent += 2; } ~this() { mIndent -= 2; writef(doindent() ~ ""); } char[] mText; } //- // // logging with scope keyword // void C() { scope auto log = new LogEnter("C"); D(); } void D() { scope auto log = new LogEnter("D"); } void main() { // C(); } //- Together with the scope keyword this works as expected. The output looks like: After that I tried to move the LogEnter instantiation into a template mixin, as follows: //- // // logging via template mixin // template Log(char[] msg) { scope auto log = new LogEnter(msg); } void A() { mixin Log!("A"); B(); } void B() { mixin Log!("B"); } void main() { A(); } //- I get the following output: IMO the template mixin variant should behave the same. Did I miss something or is this a bug ? I already searched bugzilla for similar bugs, but I found none. Thanks in advance for your help KlausO
Encoding of eol in multiline wysiwyg strings
Hello, does the D specification specify how the "end of line" is encoded when you use wysiwyg strings. Currently it seems to be '\n' on windows (And I guess it will '\n' on linux, too.). Is this the intended behaviour ? It's not a big issue but somtimes when you use wysiwyg strings, string concatenation and import expressions to combine some text the result is a string with mixed EOL encodings. Thanks for clarifying, KlausO