Re: Error execute MS function fputc()
I found the solution. A problem in different structures of FILE
for MSVC and DMC. I take the pointer on structure of FILE from
CrtDLL.dll
Everything works!
// MGW 07.05.15
import core.runtime; // Загрузка DLL Для Win
import std.stdio;// writeln
version(Windows) {
import std.c.windows.windows; // GetProcAddress для Windows
}
alias extern (C) int function(int, FILE*) t_fputc;
t_fputc ms_fputc;
int main(string[] args) {
version(Windows) {auto libCrtDll = CrtDll.dll; }
// Load CrtDLL.DLL MS Windows
auto h = Runtime.loadLibrary(libCrtDll);
// Find function fputc
ms_fputc = cast(t_fputc)GetProcAddress(h, fputc);
// Find array struct FILE MS
void* ubuf = cast(void*)GetProcAddress(h, _iob);
import core.stdc.stdio: stdout;
try {
// stdout -- FILE dmc
auto rez = ms_fputc('A' , core.stdc.stdio.stdout);
}
catch {
writeln(Error execute MS function fputc(););
}
try {
// cast(FILE*)(ubuf + 0) == stdin MSVC
// cast(FILE*)(ubuf + 32) == stdout MSVC
// stdout -- FILE MSVC
auto rez = ms_fputc('B' , cast(FILE*)(ubuf + 32));
}
catch {
writeln(Error execute MS function ms_fputc(););
}
return 0;
}
Re: Utf8 to Utf32 cast cost
On Mon, 08 Jun 2015 18:16:57 + Anonymouse via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Monday, 8 June 2015 at 11:44:47 UTC, Daniel Kozák wrote: No difference even with GC.disable() results are same. Profile! Callgrind is your friend~ Yep, but I dont care, I am the one who makes transcode faster, so I am happy with results :P. P.S. I care and probably when I have some spare time I will improve to!dstring too
Why is there no named parameter support?
Is there any reasons/difficulties for not implementing named parameters? There is clearly a need: http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org
Re: Utf8 to Utf32 cast cost
On Monday, 8 June 2015 at 18:48:17 UTC, Daniel Kozak wrote: Yep, but I dont care, I am the one who makes transcode faster, so I am happy with results :P. P.S. I care and probably when I have some spare time I will improve to!dstring too Ah, so you are. I confused you with Kadir Erdem Demir.
Re: using D without GC
On Monday, 8 June 2015 at 13:37:40 UTC, Marc Schütz wrote: On Monday, 8 June 2015 at 12:24:56 UTC, Oleg B wrote: I guess you should follow andrei's post about new allocators! Can you get link to this post? These are some of his posts: http://forum.dlang.org/thread/mku0n4$s35$1...@digitalmars.com http://forum.dlang.org/thread/mkl1eh$1mdl$2...@digitalmars.com http://forum.dlang.org/thread/mjig8h$2rgi$1...@digitalmars.com http://forum.dlang.org/thread/mjdcep$11ri$1...@digitalmars.com http://forum.dlang.org/thread/mj3p2j$2qva$1...@digitalmars.com http://forum.dlang.org/thread/mir0lg$2l74$1...@digitalmars.com http://forum.dlang.org/thread/min9k8$9r9$1...@digitalmars.com Thank! Can you say how long wait (on average) to experimental modules will cease be an experimental and will be part of phobos? At next release or it unknown?
Re: Why is there no named parameter support?
On Monday, June 08, 2015 20:36:05 Yuxuan Shui via Digitalmars-d-learn wrote: Is there any reasons/difficulties for not implementing named parameters? There is clearly a need: http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org Function overloading and named arguments do not play well together, and we have function overloading, so we're not going to have named arguments. Walter made that clear at dconf. Now, as Idan pointed out in his reply, work has been done implement them via a library solution for those that want to, so you might get something there, but not in the language itself. - Jonathan M Davis
Re: exclude current directory from search path in dmd ?
On Mon, Jun 8, 2015 at 12:08 AM, Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: The easiest way is to not use search paths, and instead pass all the modules you want compiled to the compiler directly. Then it will look for the module name declaration instead of the directory/filename layout. Could you be more specific, perhaps with a command line example? If I understand correctly, what you suggest doesn't bode well with separate compilation. Really, I think the easiest would be a flag to disable including current directory implicitly in search path
Re: Why is there no named parameter support?
On Monday, 8 June 2015 at 20:36:10 UTC, Yuxuan Shui wrote: Is there any reasons/difficulties for not implementing named parameters? There is clearly a need: http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org http://forum.dlang.org/thread/hdxnptcikgojdkmld...@forum.dlang.org
Re: exclude current directory from search path in dmd ?
On Tuesday, 9 June 2015 at 00:22:09 UTC, Timothee Cour wrote: On Mon, Jun 8, 2015 at 12:08 AM, Adam D. Ruppe via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: The easiest way is to not use search paths, and instead pass all the modules you want compiled to the compiler directly. Then it will look for the module name declaration instead of the directory/filename layout. Could you be more specific, perhaps with a command line example? If I understand correctly, what you suggest doesn't bode well with separate compilation. Really, I think the easiest would be a flag to disable including current directory implicitly in search path dmd main.d ..\foo.d this will use base\foo.d dmd won't know base\bar\foo.d exists.
Re: Why is there no named parameter support?
On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn wrote: nim has both overloading and named arguments (with reordering and defaults allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments and it doesn't seem to cause issues. Is there a document / thread that explains the argument against named arguments in more details than 'do not play well together' ? Probably not, but Walter was quite adamant when it was discussed at dconf that it's a disaster to mix named arguments and function overloading in the same language. Maybe it's not as bad as he thinks it is, but personally, I think that named arguments are a terrible idea in general, so I'm not about to try and support a position that tries to bring them into D. - Jonathan M Davis
Re: Why is there no named parameter support?
On Mon, Jun 8, 2015 at 11:32 PM, Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn
wrote:
nim has both overloading and named arguments (with reordering and
defaults
allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments
and it doesn't seem to cause issues.
Is there a document / thread that explains the argument against named
arguments in more details than 'do not play well together' ?
Probably not, but Walter was quite adamant when it was discussed at dconf
that it's a disaster to mix named arguments and function overloading in the
same language. Maybe it's not as bad as he thinks it is, but personally, I
think that named arguments are a terrible idea in general, so I'm not about
to try and support a position that tries to bring them into D.
- Jonathan M Davis
I'd be very interested in reading more about those reasons beyond FUD.
The arguments in favor have been repeated many times over, and the only
argument against that I've heard ('overloading and named arguments do not
play well together') doesn't seem valid, given the precedent in nim.
Re: Why is there no named parameter support?
nim has both overloading and named arguments (with reordering and defaults allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments and it doesn't seem to cause issues. Is there a document / thread that explains the argument against named arguments in more details than 'do not play well together' ? On Mon, Jun 8, 2015 at 10:45 PM, Jonathan M Davis via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Monday, June 08, 2015 20:36:05 Yuxuan Shui via Digitalmars-d-learn wrote: Is there any reasons/difficulties for not implementing named parameters? There is clearly a need: http://forum.dlang.org/thread/wokfqqbexazcguffw...@forum.dlang.org#post-pxndhoskpjxvnoacajaz:40forum.dlang.org Function overloading and named arguments do not play well together, and we have function overloading, so we're not going to have named arguments. Walter made that clear at dconf. Now, as Idan pointed out in his reply, work has been done implement them via a library solution for those that want to, so you might get something there, but not in the language itself. - Jonathan M Davis
Re: Why is there no named parameter support?
On Tuesday, June 09, 2015 01:38:56 Timothee Cour via Digitalmars-d-learn wrote:
On Mon, Jun 8, 2015 at 11:32 PM, Jonathan M Davis via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Monday, June 08, 2015 23:18:50 Timothee Cour via Digitalmars-d-learn
wrote:
nim has both overloading and named arguments (with reordering and
defaults
allowed): http://nim-lang.org/docs/tut1.html#procedures-named-arguments
and it doesn't seem to cause issues.
Is there a document / thread that explains the argument against named
arguments in more details than 'do not play well together' ?
Probably not, but Walter was quite adamant when it was discussed at dconf
that it's a disaster to mix named arguments and function overloading in the
same language. Maybe it's not as bad as he thinks it is, but personally, I
think that named arguments are a terrible idea in general, so I'm not about
to try and support a position that tries to bring them into D.
- Jonathan M Davis
I'd be very interested in reading more about those reasons beyond FUD.
The arguments in favor have been repeated many times over, and the only
argument against that I've heard ('overloading and named arguments do not
play well together') doesn't seem valid, given the precedent in nim.
Then talk with Walter about it. Whether he's right or not is up for debate,
but it's certainly not FUD. He gave good examples, but I don't remember what
they were at this point.
Personally, I hate how named arguments affect the API (e.g. the names of the
parameters suddenly become part of the API), and for the most part, the only
times that they're worth much is when you have so many function parameters
that you should be creating structs to hold those values anyway. I don't
want them in the language, and I'm very glad that Walter is against them, so
I didn't feel the need to try and remember all he said about why they were a
bad idea.
- Jonathan M Davis
Re: string to char array?
On Monday, 8 June 2015 at 09:54:28 UTC, Kagamin wrote: On Sunday, 7 June 2015 at 17:41:11 UTC, Kyoji Klyden wrote: Do you perchance have any links to learning resources for the D runtime(aside from just the github repository), and also maybe x86 architecture stuff? (I know intel has some 1000+ page pdf on their site, but I think that's more for hardware and/or OS designers..) Well, instruction reference is all you need: http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2008/10/24594_APM_v3.pdf Awesome, this is exactly what I was looking for! Thanks!
