On Monday, 28 January 2013 at 07:17:56 UTC, Rob T wrote:
On Monday, 28 January 2013 at 04:40:34 UTC, Andrei Alexandrescu
wrote:
I'm not convinced that's a bad thing. I've come to realize
functions and variables _are_ different.
The behavior of the variable seems to be a subset of what the
fun
On 2013-01-27 21:15, Philippe Sigaud wrote:
This means, for example, you'll need to squeeze pretty much all storage
allocation out of it. A lexer that does an allocation per token will is not
going to do very well at all.
How does one do that? Honest question, I'm not really concerned by
extre
On Monday, 28 January 2013 at 04:40:34 UTC, Andrei Alexandrescu
wrote:
I'm not convinced that's a bad thing. I've come to realize
functions and variables _are_ different.
The behavior of the variable seems to be a subset of what the
function does, i.e., they are both the exact same thing excep
On Mon, Jan 28, 2013 at 12:22:01AM -0500, Steven Schveighoffer wrote:
[...]
> Disagree. @property serves a very good purpose -- specifying
> intent. If the intention of a function is to be used as a dynamic
> field, use @property, otherwise do not.
>
> Whether or not parentheses should be requir
On Monday, 28 January 2013 at 04:42:34 UTC, Andrei Alexandrescu
wrote:
Do you think the Ferrari (i.e. optional parens) has got
what it needs under the hood?
I'm not sure I understand the question.
Just that the elegant appearance of UFCS and optional parens
isn't offset underneath by built-
On 01/27/2013 12:13 PM, Daniel Kozak wrote:
> On Sunday, 27 January 2013 at 19:55:07 UTC, rsk82 wrote:
>> What's wrong here ?
>
> class myClass () {
> this() {
>
> }
> };
>
> should be
>
> class myClass {
> this() {
>
> }
> }
Yeah... Those empty parentheses were making myClass a class template,
On Thu, 24 Jan 2013 03:34:42 -0500, Walter Bright
wrote:
This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
Perhaps we should revert to a simple set of rules.
1. Empty parens are optional. If there is an ambiguity with the return
value taking (), the () go on the re
On Monday, 28 January 2013 at 04:40:34 UTC, Andrei Alexandrescu
wrote:
To get the address of a function's result: &fun().
That is kind of the point, fun is equivalent to fun(), but &fun
is not equivalent to &fun(), not equivalent to (&fun)(), which is
weird.
I'm not convinced that's a bad
On 1/27/13 9:16 PM, deadalnix wrote:
On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu wrote:
On 1/27/13 3:22 PM, Zach the Mystic wrote:
Several suggestions here:
With regard to optional parentheses, it had been suggested that any
ambiguity be regarded as an error. This is the ex
On 1/27/13 9:25 PM, Zach the Mystic wrote:
I first saw UFCS and optional parentheses in Ruby and it seemed both
alluring and deceptively simple. I will give you a thought in return for
your thought. Reading the other people's posts who prefer always parens
makes it seem that if they had to choose
On 01/27/2013 06:50 PM, Vladimir Panteleev wrote:
Alternatively, you could right-click the post title to obtain a
canonical link to the post, which should work with all view modes
(unless you are using some kind of web browser which ignores anchors in
redirects).
It is documented here:
http://
On Monday, 28 January 2013 at 00:51:28 UTC, Walter Bright wrote:
On 1/27/2013 4:48 PM, David Nadlinger wrote:
On Sunday, 27 January 2013 at 23:49:11 UTC, Walter Bright
wrote:
On 1/27/2013 1:39 PM, Brian Schott wrote:
The file name is accepted for eventual error reporting
purposes.
Use an Out
On Sat, 01 Dec 2012 20:03:21 -0500, Jonathan M Davis
wrote:
I'd _love_ to make it illegal to call non-property functions without
parens,
and there are definitely folks around here who agree with me, including
some on
the Phobos dev team (e.g. Steven has always agreed with me when this has
On 01/27/2013 06:50 PM, Vladimir Panteleev wrote:
On Sunday, 27 January 2013 at 20:25:30 UTC, Chad J wrote:
I just searched for something in the property discussion. I wanted to
link a friend to one of deadalnix's posts, so I put "I'm so happy to
read this " into the search box and punched i
On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu
wrote:
BTW also regarding optional parentheses, while I was working on
https://github.com/D-Programming-Language/tools/pull/41/files I
refactored a bit of code to use UFCS and paren-less syntax. I
must say I find this a very fluid
On Monday, 28 January 2013 at 00:53:03 UTC, Brian Schott wrote:
On Sunday, 27 January 2013 at 23:49:11 UTC, Walter Bright wrote:
On 1/27/2013 1:39 PM, Brian Schott wrote:
The file name is accepted for eventual error reporting
purposes.
Use an OutputRange for that.
I think you misunderstand.
On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu
wrote:
I was thinking of just using &foo, like in C.
BTW also regarding optional parentheses, while I was working on
https://github.com/D-Programming-Language/tools/pull/41/files I
refactored a bit of code to use UFCS and paren-le
On Monday, 28 January 2013 at 00:07:05 UTC, Andrei Alexandrescu
wrote:
On 1/27/13 3:22 PM, Zach the Mystic wrote:
Several suggestions here:
With regard to optional parentheses, it had been suggested
that any
ambiguity be regarded as an error. This is the example I used:
int foo() { return 4;
On Sunday, 27 January 2013 at 17:37:29 UTC, Dicebot wrote:
On Sunday, 27 January 2013 at 16:50:47 UTC, deadalnix wrote:
Off topic rant.
I suppressed a counterexample in the section Optional
parentheses
- Extra note .
The note state that some stuff are valid for *function* and
the counter ex
On 1/27/2013 4:53 PM, Brian Schott wrote:
On Sunday, 27 January 2013 at 23:49:11 UTC, Walter Bright wrote:
On 1/27/2013 1:39 PM, Brian Schott wrote:
The file name is accepted for eventual error reporting purposes.
Use an OutputRange for that.
I think you misunderstand. The file name is so t
On 1/27/13 9:50 AM, SomeDude wrote:
On Thursday, 24 January 2013 at 06:26:13 UTC, Andrei Alexandrescu wrote:
There's quite a bit of work left to do, but the PDF spec already has
386 pages of goodness and starts to look seriously cool. Take a peek!
http://dlang.org/dlangspec.pdf
(still subject
On Sunday, 27 January 2013 at 23:49:11 UTC, Walter Bright wrote:
On 1/27/2013 1:39 PM, Brian Schott wrote:
The file name is accepted for eventual error reporting
purposes.
Use an OutputRange for that.
I think you misunderstand. The file name is so that if you pass
in "foo.d" the lexer can s
On 1/27/2013 4:48 PM, David Nadlinger wrote:
On Sunday, 27 January 2013 at 23:49:11 UTC, Walter Bright wrote:
On 1/27/2013 1:39 PM, Brian Schott wrote:
The file name is accepted for eventual error reporting purposes.
Use an OutputRange for that.
What about that delegate-based design? I thou
On Sunday, 27 January 2013 at 23:49:11 UTC, Walter Bright wrote:
On 1/27/2013 1:39 PM, Brian Schott wrote:
The file name is accepted for eventual error reporting
purposes.
Use an OutputRange for that.
What about that delegate-based design? I thought everyone agreed
that it was nice?
David
On 01/15/2013 07:55 AM, Andrei Alexandrescu wrote:
> We're a couple of weeks inside the Call for Submissions for DConf 2013,
> and so far we have collected a few strong proposals but indeed only a
few.
Bump... Submission deadline is January 28:
http://dconf.org/
Ali
On 01/28/13 00:23, Timon Gehr wrote:
> On 01/27/2013 07:12 PM, Artur Skawina wrote:
>> ...
>> While it's true that "counter-example" is not the best way to describe the
>> issue,
>> it /is/ something that is worth considering. And I say that as somebody who
>> was
>> (and still is) arguing for ke
On Sunday, 27 January 2013 at 20:25:30 UTC, Chad J wrote:
I'm sorry if this is already a known bug or something. I don't
actually remember what the forum front-end is called or where I
would go to properly find/add issues about it.
The source code is here:
https://github.com/CyberShadow/DFee
On 1/27/13 3:22 PM, Zach the Mystic wrote:
Several suggestions here:
With regard to optional parentheses, it had been suggested that any
ambiguity be regarded as an error. This is the example I used:
int foo() { return 4; }
auto x = foo; // Error: gives 4 or gives function foo?
I suggested the
On 1/27/13 3:29 PM, jerro wrote:
You need to put myClass_mod.d (or what ever the file name is) on the
command line. You could also use rdmd, which will find all the imported
files automatically.
BTW I just sent a pull request that makes rdmd faster for large projects
by reducing the number of
On Sunday, 27 January 2013 at 23:29:16 UTC, Timon Gehr wrote:
In the absence of language rules, every sequence of characters
has an ambiguous meaning. It is only ambiguous to you because
you seem not aware of the rule that states that free-standing
function names are an alternative notation for
On Sunday, 27 January 2013 at 20:25:30 UTC, Chad J wrote:
I just searched for something in the property discussion. I
wanted to link a friend to one of deadalnix's posts, so I put
"I'm so happy to read this " into the search box and
punched it.
What it brought up was one of David Nadling
On 1/27/2013 1:39 PM, Brian Schott wrote:
The file name is accepted for eventual error reporting purposes.
Use an OutputRange for that.
On 01/28/2013 12:34 AM, Timon Gehr wrote:
On 01/27/2013 06:33 PM, Dicebot wrote:
...
"unambiguous" == "I can understand semantics of code I have just read
with as little additional context as possible"
...
In order to do that, it is necessary
to be
aware of the precise definitions,
or at l
On 01/27/2013 06:33 PM, Dicebot wrote:
...
"unambiguous" == "I can understand semantics of code I have just read
with as little additional context as possible"
...
In order to do that, it is necessary aware of the precise definitions,
or at least specifications, of referenced declarations in a
On Monday, January 28, 2013 00:18:15 Adam D. Ruppe wrote:
> I was just working on some work code and noticed this line that I
> wrote a while ago:
>
> public @property string userId(string file = __FILE__, size_t
> line = __LINE__) {
>
>
> That's a getter, I always use it "getUser(userId);" etc.
On 01/27/2013 10:47 PM, Zach the Mystic wrote:
...
Okay, I was ignorant of that, and it's a bad example. I'm not going to
pretend I know everything. But the man issue is to make ambiguous cases
an error and not silently accepted as one or the other. If there aren't
very many, or even any, then gr
On 01/27/2013 07:12 PM, Artur Skawina wrote:
...
While it's true that "counter-example" is not the best way to describe the
issue,
it /is/ something that is worth considering. And I say that as somebody who was
(and still is) arguing for keeping the last pair of (),
You can do that in any case
On 01/27/2013 10:39 PM, Brian Schott wrote:
...
Regarding the times that I posted, my point was that it's not slower
than "dmd -c", nothing more.
Sure. The point you brought across, however, was that it is not
significantly faster yet. :o)
I was just working on some work code and noticed this line that I
wrote a while ago:
public @property string userId(string file = __FILE__, size_t
line = __LINE__) {
That's a getter, I always use it "getUser(userId);" etc. but
it "takes" two arguments.
If we require getters to have ze
shared WorkerClass[] myWorkerArray;
static this()
{
myWorkerArray = new shared(WorkerClass)[numberOfWorkers];
}
This should probably be "shared static this()". I'm guessing one
would want this to run once before main(), not every time a
thread is started.
On Sunday, 27 January 2013 at 22:35:21 UTC, SomeDude wrote:
On Sunday, 27 January 2013 at 20:49:47 UTC, Freddie Chopin
wrote:
Ask him what the restrictions are, as I just don't see a 3000€
toolchain being included with a 300€ board... And - believe me
- Keil DOES cost 3000€ (~4000$) - per year.
On Sunday, 27 January 2013 at 20:49:47 UTC, Freddie Chopin wrote:
Ask him what the restrictions are, as I just don't see a 3000€
toolchain being included with a 300€ board... And - believe me
- Keil DOES cost 3000€ (~4000$) - per year... In case it's just
the regular demo version, you can downl
Thanks a lot. Sure, I post such questions on that forum.
Oh, I need to delete this thread, since there was an error. I did
not know how to edit, so I created another thread. My apologies.
Please delete it and read another one.
On Sunday, 27 January 2013 at 21:03:45 UTC, Maxim Fomin wrote:
int foo() { return 4; }
auto x = foo; // Error: gives 4 or gives function foo?
Unlike C, in D a function is not implicitly converted to
pointer to function, and because you cannot create functions as
stack variables, that statemen
Hello
I read: "The total size of a static array cannot exceed 16Mb. A
dynamic array should be used instead for such large arrays."
I want to make array which is shared but also has a large size,
e.g.
shared WorkerClass[numberOfWorkers] myWorkerArray;
where numberOfWorkers is large.
I
Hello
I read: "The total size of a static array cannot exceed 16Mb. A
dynamic array should be used instead for such large arrays."
I want to make array which is shared but also has a large size,
e.g.
shared WorkerClass[numberOfWorkers] myWorkerArray;
where numberOfWorkers is large.
If I
On Sunday, 27 January 2013 at 19:46:12 UTC, Walter Bright wrote:
On 1/27/2013 1:51 AM, Brian Schott wrote:
I'm interested in ideas on the API design and other high-level
issues at the
moment. I don't consider this ready for inclusion. (The
current module being
reviewed for inclusion in Phobos
28-Jan-2013 01:18, rsk82 пишет:
On Sunday, 27 January 2013 at 21:14:51 UTC, Dmitry Olshansky wrote:
and features a broken link.
And what about the features listed in this bogus entry ? Are they in
latest legitimate version or the new upcoming ?
These just list the bugs fixed since the last r
On Sunday, 27 January 2013 at 21:14:51 UTC, Dmitry Olshansky
wrote:
and features a broken link.
And what about the features listed in this bogus entry ? Are they
in latest legitimate version or the new upcoming ?
28-Jan-2013 01:10, rsk82 пишет:
(I don't know where to ask this, sorry for another topic, I know I was
asked not to post here trivial things. But this is not about language
itself.)
in download section: http://dlang.org/download.html last version is:
http://downloads.dlang.org.s3-website-us-east
(I don't know where to ask this, sorry for another topic, I know
I was asked not to post here trivial things. But this is not
about language itself.)
in download section: http://dlang.org/download.html last version
is:
http://downloads.dlang.org.s3-website-us-east-1.amazonaws.com/releases/201
> The hint is that your question is a bit faulty: by calling it "the D
> grammar" do you mean the exact one listed on the website or any equivalent
> that parses the same language (including the ones obtained by simple
> transformations)?
The latter. The one I use for Pegged to generate (what is h
On Sunday, 27 January 2013 at 20:22:57 UTC, Zach the Mystic wrote:
Several suggestions here:
With regard to optional parentheses, it had been suggested that
any ambiguity be regarded as an error. This is the example I
used:
int foo() { return 4; }
auto x = foo; // Error: gives 4 or gives fun
On 1/27/2013 12:11 PM, Dmitry Olshansky wrote:
27-Jan-2013 23:46, Walter Bright пишет:
On 1/27/2013 1:51 AM, Brian Schott wrote:
I'm interested in ideas on the API design and other high-level issues
at the
moment. I don't consider this ready for inclusion. (The current module
being
reviewed for
On 1/27/2013 12:18 PM, Philippe Sigaud wrote:
I concur. One of the biggest reason* there is a separate lexer step is
because it could be made to do this stage very-very fast. Then the rest of
the parser will greatly benefit from this underlying speed.
*Otherwise we could have just as well add th
28-Jan-2013 00:45, Philippe Sigaud пишет:
[snip]
AFAICT, one interesting consequence is the ability to have composition
of grammars, which I sure have with Pegged. But maybe it's not related
that much, that's not something I stopped to think about.
In any case, grammar composition is something I'
On Sunday, 27 January 2013 at 15:01:51 UTC, SomeDude wrote:
On Sunday, 27 January 2013 at 08:52:08 UTC, Freddie Chopin
wrote:
On Sunday, 27 January 2013 at 07:36:50 UTC, SomeDude wrote:
If you really are serious with this ucontroller, you want to
spend a few hundreds dollars and go with the Kei
>> ... which is exactly what parsing expression grammars (and other
>> scannerless parsers) do.
>>
>
> That is only a happenstance and is highly overrated. What does it buy you is
> the right question to ask. After all every LL-parser can be written avoiding
> notion of lexer and strangely I see no
I just searched for something in the property discussion. I wanted to
link a friend to one of deadalnix's posts, so I put "I'm so happy to
read this " into the search box and punched it.
What it brought up was one of David Nadlinger's posts. I want to say
nothing bad about David Nadlinge
On Sunday, 27 January 2013 at 20:24:38 UTC, rsk82 wrote:
On Sunday, 27 January 2013 at 20:13:05 UTC, Daniel Kozak wrote:
should be
class myClass {
this() {
}
}
Thanks, that killed the original error. Now the linker says:
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars
28-Jan-2013 00:18, Philippe Sigaud пишет:
I concur. One of the biggest reason* there is a separate lexer step is
because it could be made to do this stage very-very fast. Then the rest of
the parser will greatly benefit from this underlying speed.
*Otherwise we could have just as well add the le
Several suggestions here:
With regard to optional parentheses, it had been suggested that
any ambiguity be regarded as an error. This is the example I used:
int foo() { return 4; }
auto x = foo; // Error: gives 4 or gives function foo?
I suggested the ambiguity be resolved thus:
auto x = foo
On Sunday, 27 January 2013 at 20:13:05 UTC, Daniel Kozak wrote:
should be
class myClass {
this() {
}
}
Thanks, that killed the original error. Now the linker says:
OPTLINK (R) for Win32 Release 8.00.12
Copyright (C) Digital Mars 1989-2010 All rights reserved.
http://www.digitalmars.c
All of your topics shouldn't be here. Post in D.learn instead.
Am 27.01.2013 20:48, schrieb Walter Bright:
On 1/27/2013 2:17 AM, Philippe Sigaud wrote:
Walter seems to think if a lexer is not able to vomit thousands
of tokens a seconds, then it's not good.
Speed is critical for a lexer.
This means, for example, you'll need to squeeze pretty much all stor
> I concur. One of the biggest reason* there is a separate lexer step is
> because it could be made to do this stage very-very fast. Then the rest of
> the parser will greatly benefit from this underlying speed.
>
> *Otherwise we could have just as well add the lexer stage as simple rules to
> the
On Sunday, 27 January 2013 at 19:55:07 UTC, rsk82 wrote:
this is my module:
module myClass;
class myClass () {
this() {
}
};
and main app:
import myClass;
int main() {
myClass my_instance = new myClass();
return 0;
}
What's wrong here ?
class myClass () {
this() {
}
};
sh
On Sun, Jan 27, 2013 at 8:48 PM, Walter Bright
wrote:
> On 1/27/2013 2:17 AM, Philippe Sigaud wrote:
>>
>> Walter seems to think if a lexer is not able to vomit thousands
>> of tokens a seconds, then it's not good.
>
>
> Speed is critical for a lexer.
Something I never tought about: given a 10k l
27-Jan-2013 23:46, Walter Bright пишет:
On 1/27/2013 1:51 AM, Brian Schott wrote:
I'm interested in ideas on the API design and other high-level issues
at the
moment. I don't consider this ready for inclusion. (The current module
being
reviewed for inclusion in Phobos is the new std.uni.)
Just
27-Jan-2013 23:48, Walter Bright пишет:
On 1/27/2013 2:17 AM, Philippe Sigaud wrote:
Walter seems to think if a lexer is not able to vomit thousands
of tokens a seconds, then it's not good.
Speed is critical for a lexer.
This means, for example, you'll need to squeeze pretty much all storage
On Sunday, 27 January 2013 at 20:04:17 UTC, Dicebot wrote:
new MyClass.MyClass(), I suppose. Despite import is public,
module symbol has higher priority in name resolution.
Nope. I changed module name to myClass_mod, now got this:
Error: class myClass_mod.myClass() is used as a type
On Sunday, 27 January 2013 at 19:55:07 UTC, rsk82 wrote:
this is my module:
module myClass;
class myClass () {
this() {
}
};
and main app:
import myClass;
int main() {
myClass my_instance = new myClass();
return 0;
}
What's wrong here ?
new MyClass.MyClass(), I suppose. Despite i
this is my module:
module myClass;
class myClass () {
this() {
}
};
and main app:
import myClass;
int main() {
myClass my_instance = new myClass();
return 0;
}
What's wrong here ?
On Sunday, 27 January 2013 at 19:31:59 UTC, John Chapman wrote:
Actually, replace "LPCTSTR" above with "LPCWSTR".
Ok, fine, now the linker *again*. I have some lenghty code, if is
strip it down I post it here.
On 1/27/2013 1:51 AM, Brian Schott wrote:
I'm interested in ideas on the API design and other high-level issues at the
moment. I don't consider this ready for inclusion. (The current module being
reviewed for inclusion in Phobos is the new std.uni.)
Just a quick comment: byToken() should not ac
On 1/27/2013 2:17 AM, Philippe Sigaud wrote:
Walter seems to think if a lexer is not able to vomit thousands
of tokens a seconds, then it's not good.
Speed is critical for a lexer.
This means, for example, you'll need to squeeze pretty much all storage
allocation out of it. A lexer that does
On Sunday, 27 January 2013 at 19:25:28 UTC, rsk82 wrote:
extern(Windows)
ATOM class_atom = RegisterClassExW(&wc);
No, I'm wrong, now the compiler ignores the class that I put in
my module, I can write every nonsense that comes to my mind and
it compiles. But if I put extern outside of the cla
On Sunday, 27 January 2013 at 19:29:03 UTC, John Chapman wrote:
On Sunday, 27 January 2013 at 18:58:59 UTC, rsk82 wrote:
On Sunday, 27 January 2013 at 18:26:04 UTC, John Chapman wrote:
This must be declared at module level (not inside a function).
Ok, I've put it into module, linked in the mo
On Sunday, 27 January 2013 at 18:58:59 UTC, rsk82 wrote:
On Sunday, 27 January 2013 at 18:26:04 UTC, John Chapman wrote:
This must be declared at module level (not inside a function).
Ok, I've put it into module, linked in the module
pragma(lib, "user32.lib");
and
pragma(lib, "gdi32.lib");
al
On Sunday, 27 January 2013 at 17:51:40 UTC, Benjamin Thaut wrote:
extern(Windows)
I don't know If that what you meant but this works *inside* the
code:
extern(Windows)
ATOM class_atom = RegisterClassExW(&wc);
On Sunday, 27 January 2013 at 18:26:04 UTC, John Chapman wrote:
This must be declared at module level (not inside a function).
Ok, I've put it into module, linked in the module
pragma(lib, "user32.lib");
and
pragma(lib, "gdi32.lib");
all this works until I put
extern(Windows) ATOM RegisterCla
On Sunday, 27 January 2013 at 18:01:38 UTC, rsk82 wrote:
On Sunday, 27 January 2013 at 17:51:40 UTC, Benjamin Thaut
wrote:
extern(Windows)
I am not sure what I was supposed to do, so I did this:
extern(Windows) ATOM RegisterClassExW(const WNDCLASSEXW *lpwcx);
This must be declared at modul
Am 27.01.2013 19:01, schrieb rsk82:
On Sunday, 27 January 2013 at 17:51:40 UTC, Benjamin Thaut wrote:
extern(Windows)
I am not sure what I was supposed to do, so I did this:
extern(Windows) ATOM RegisterClassExW(const WNDCLASSEXW *lpwcx);
ATOM class_atom = RegisterClassExW(&wc);
and got lin
On 01/27/13 17:50, deadalnix wrote:
> On Friday, 25 January 2013 at 18:57:17 UTC, Johannes Pfau wrote:
>> But please keep off-topic stuff, offenses and meta discussion(release
>> process, ...) in the newsgroup.
>
> Off topic rant.
>
> I suppressed a counterexample in the section Optional parenthe
On Sunday, 27 January 2013 at 17:51:40 UTC, Benjamin Thaut wrote:
extern(Windows)
I am not sure what I was supposed to do, so I did this:
extern(Windows) ATOM RegisterClassExW(const WNDCLASSEXW *lpwcx);
ATOM class_atom = RegisterClassExW(&wc);
and got linker error:
OPTLINK (R) for Win32 Re
Am 27.01.2013 18:45, schrieb rsk82:
the error is :
Error: undefined identifier RegisterClassExW, did you mean function
RegisterClassExA?
No I didn't mean that.
So how to import winapi functions ?
extern(Windows)
the error is :
Error: undefined identifier RegisterClassExW, did you mean
function RegisterClassExA?
No I didn't mean that.
So how to import winapi functions ?
On 01/27/2013 09:26 AM, Andrei Alexandrescu wrote:
Language adoption is a complex phenomenon with many variables, and it's
easy to neglect certain aspects when assessing the impact of others.
Indeed it is, as you show below.
Java started as a well-designed language albeit small and underpowe
On 1/27/13 12:37 PM, Dicebot wrote:
On Sunday, 27 January 2013 at 16:50:47 UTC, deadalnix wrote:
Off topic rant.
I suppressed a counterexample in the section Optional parentheses
- Extra note .
The note state that some stuff are valid for *function* and the
counter example showed ambiguity usi
On Sunday, 27 January 2013 at 16:50:47 UTC, deadalnix wrote:
Off topic rant.
I suppressed a counterexample in the section Optional
parentheses
- Extra note .
The note state that some stuff are valid for *function* and the
counter example showed ambiguity using opCall. I don't know who
did
On Sunday, 27 January 2013 at 17:19:15 UTC, TommiT wrote:
On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
... but at scope level semantics for reader should be
perfectly clear and unambiguous even if opened in notepad.
I think we have been throwing the term ambiguous around too
car
On 27 January 2013 17:17, Johannes Pfau wrote:
> Am Sun, 27 Jan 2013 16:14:19 +
> schrieb Iain Buclaw :
>
> > >
> > > Are Thumb1 systems still relevant today? I'm not too familiar with
> > > Thumb,
> > so forgive my ignorance here. If we still do need to care about
> > Thumb1, then OK.
> > >
Am Sun, 27 Jan 2013 16:20:58 +0100
schrieb Alex Rønne Petersen :
>
> > * Do we need the arch specific SoftFloat/HardFloat if a target only
> > has those two? Why PPC_SoftFP and PPC_HardFP, doesn't
> >version(PPC){version(D_SoftFloat) else version(D_HardFloat)}
> > work?
>
> The intention was
Am Sun, 27 Jan 2013 16:14:19 +
schrieb Iain Buclaw :
> >
> > Are Thumb1 systems still relevant today? I'm not too familiar with
> > Thumb,
> so forgive my ignorance here. If we still do need to care about
> Thumb1, then OK.
> >
> >
>
> I seem to recall thumb being mostly 16bit systems.
Reall
On Sunday, 27 January 2013 at 13:42:33 UTC, Dicebot wrote:
... but at scope level semantics for reader should be perfectly
clear and unambiguous even if opened in notepad.
I think we have been throwing the term ambiguous around too
carelessly. Obviously code must be semantically unambiguous wh
On Friday, 25 January 2013 at 18:57:17 UTC, Johannes Pfau wrote:
But please keep off-topic stuff, offenses and meta
discussion(release
process, ...) in the newsgroup.
Off topic rant.
I suppressed a counterexample in the section Optional parentheses
- Extra note .
The note state that some
On 27 Jan 2013 15:26, "Alex Rønne Petersen" wrote:
>
> On 27-01-2013 10:42, Johannes Pfau wrote:
>>
>> I started implementing all the CPU based version symbols shown on
>> http://dlang.org/version.html for GDC
>> (https://gist.github.com/4647493), but I found some things to be
>> strange:
>>
>> Fl
I have added few last "tricky" moments discussed in newsgroup to
test code sample. Proposal authors - please do take some actions
;) Also all proposal is split to separate page to navigate and
edit easier.
On Sunday, 27 January 2013 at 15:42:40 UTC, TommiT wrote:
On Sunday, 27 January 2013 at 15:22:34 UTC, Dicebot wrote:
And how it is any better? Also D sources are unicode, so last
two are possible just now and you need no special keyboard for
it. Still the same good old text.
I don't know if w
1 - 100 of 191 matches
Mail list logo
