Re: Properties don't behave like variables?
On 2012-05-07 23:34, Jonathan M Davis wrote: You mean the setter? Yes. Having a getter property function return by ref does allow you to use a property exactly as you would a variable, because you're operating on the ref that's returned. It also makes the property function nigh-on-useless, because then you're operating on its associated variable outside of the property function, making it so that you can no longer control access to it. You pretty much might as well make it a public variable at that point. Not to mention, even if returning by ref didn't have that problem, it would only work in cases where the property function was associated with an actual variable (since you have to return a ref to _something_), so it would still be impossible to emulate a variable with property functions which calculate the value from other variables or which grab the value from somewhere else (e.g. a database). - Jonathan M Davis Exactly. -- /Jacob Carlborg
Re: Why not all statement are expressions ?
On 2012-05-07 22:37, deadalnix wrote: This won't work anyway. We are talking about language grammar here. If made expression, statement would be of type void. Just like assert is. Says who? :) -- /Jacob Carlborg
Re: GSOC Linker project
Oops, copy/paste error. :( I'll check it, when I get back home. -- Paulo "Andre Tampubolon" wrote in message news:joa0lq$1t2k$1...@digitalmars.com... Interesting reading. I took a look at page 23, and didn't find the mention of C. Maybe I didn't read carefully? On 5/8/2012 3:34 AM, Paulo Pinto wrote: Hi, it seems I have to excuse myself. I could not find anything from Adele Goldberg. So my statement is false. Most likely I ended up confusing Fran Allen's interview in Coders at Work, with some nonsense in my head. Still, I leave here a few links I manage to find from Fran Allen. Some remarks about bad languages on the page 27 http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf Complaint about C on slide 23 http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf Another remark about C http://www.windley.com/archives/2008/02/fran_allen_compilers_and_parallel_computing_systems.shtml A video recorded at Purdue University, she also talks about C on minute 51 http://www.youtube.com/watch?v=Si3ZW3nI6oA -- Paulo Am 07.05.2012 10:41, schrieb Jens Mueller: Paulo Pinto wrote: On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote: Paulo Pinto wrote: AST/symbol table manipulation is way faster than reparsing code. People keep talking about D and Go compilation speed, while I was already enjoying such compile times back in 1990 with Turbo Pascal in computers much less powerfull than my laptop. But C and C++ with their 70's compiler technology, somehow won the market share, and then people started complaining about compilation speeds. Adele Golberg, once wrote a paper telling how C made the compiler technology regress several decades. Do you happen to remember to exact title of that paper? Thanks. Jens I'll try to find it, as I don't recall the title. I just remember that it made some remarks how primitive C was in regard to Algol toolchains. Many thanks. I couldn't find it myself and I'm interested because Fran Allen said something similar in Coders at Work. I didn't understand what she meant. Andrei suggested that it is mostly (only?) about overlapping pointers to memory. I'm just curious. Jens
Re: -wi on default?
"Jonathan M Davis" wrote in message news:mailman.408.1336451614.24740.digitalmar...@puremagic.com... > > I think that it makes sense to have flags for enabling certain types of > warnings. The programmer can then choose to enable warnings for the things > that that they want to warn about (be it on all builds or just on a build > which is intended to check for the type of stuff that lint checks for). > What I > do _not_ want to see is for such warnings to be part of -wi or -w. > > I'm _very_ much against having normal warnings which are things which > don't > definitively need to be fixed, because otherwise you get into the > situation > where people ignore them, and the quality of the software suffers, because > you > get a ton of warnings that don't get fixed, some of which _need_ to get > fixed > and others which just hide those warnings by helping to make the number of > warnings too many to examine. Optional flags for additional warnings don't > introduce quite the same problem (though obviously if you always insist on > them for your builds, you risk the same problems as if they were part > of -wi). > > However, as I understand it, Walter is against having a bunch of different > flags > for enabling or disabling different warnings, so it's unlikely that we're > going > to get that with dmd, regardless of whether it would be an improvement or > not. > Ok, yea, I completely agree on all counts.
Re: Does D have too many features?
On 05/07/2012 03:22 AM, Andrew Wiley wrote: I had some problems with floats being default initialized to NaN. That's still correct behavior for C, actually. Using an uninitialized variable in C results in undefined behavior, so D still complies with C requirements when it initializes floats to NaN. For variables with static storage, C initializes them by default to zero. It's in the spec.
Re: -wi on default?
On Monday, May 07, 2012 23:56:40 Nick Sabalausky wrote: > "Jonathan M Davis" wrote in message > news:mailman.407.1336445190.24740.digitalmar...@puremagic.com... > > > On Tuesday, May 08, 2012 04:21:06 bearophile wrote: > >> Jonathan M Davis: > >> > A good programmer will never leave _any_ warnings in committed > >> > code. > >> > >> Sometimes warnings are wrong, the compiler is not perfect. > >> If the compiler is certain there is a mistake in the code, then > >> generating an error is better. Bugs are probabilistic. > >> Good lints don't have just "errors", they report issues > >> classified in four or five levels of increasingly probability of > >> actual problem being present (naming them something like "Info", > >> "Note", "Warning", "Probable Error", and "Error"). > > > > If it's not something that _must_ be fixed, the compiler should _not_ > > complain > > about it precisely because you should _never_ leave any warnings in > > committed > > code. Leaving warnings in committed code (even if invalid) leads to valid > > warnings being missed and/or ignored, which leads to bugs being uncaught. > > If a > > compiler restricts itself to stuff which is _definitively_ wrong, then > > that > > isn't a problem. A compiler is _not_ a lint tool and shouldn't be treated > > as > > one. > > A compiler isn't a profilier, documentation generator or unittesting tool > either, but a big part of D's philosophy is that there *is* real value in > having such things in the compiler anyway. The more significant warnings > should normally be on (ie, stuff that's ok while debuggng, but shouldn't be > checked in), but lint-style pedantic analysis likely *shouldn't* be enabled > on every build anyway, so the "stuff getting ignored" argument doesn't > really apply. > > And as I said some time ago, if you still *really* want a line tool to be > separate from the compiler for whatever "purity" or ideological reason, > that'd be easy enough to do: > > $cat dlint > #!/bin/bash > dmd -lint "$*" > #or > dmd -pedantic-warnings "$*" I think that it makes sense to have flags for enabling certain types of warnings. The programmer can then choose to enable warnings for the things that that they want to warn about (be it on all builds or just on a build which is intended to check for the type of stuff that lint checks for). What I do _not_ want to see is for such warnings to be part of -wi or -w. I'm _very_ much against having normal warnings which are things which don't definitively need to be fixed, because otherwise you get into the situation where people ignore them, and the quality of the software suffers, because you get a ton of warnings that don't get fixed, some of which _need_ to get fixed and others which just hide those warnings by helping to make the number of warnings too many to examine. Optional flags for additional warnings don't introduce quite the same problem (though obviously if you always insist on them for your builds, you risk the same problems as if they were part of -wi). However, as I understand it, Walter is against having a bunch of different flags for enabling or disabling different warnings, so it's unlikely that we're going to get that with dmd, regardless of whether it would be an improvement or not. - Jonathan M Davis
Re: nginx reverse proxy for vibe tutorial
"James Miller" wrote in message news:tsqxxnxrqfcfyvxmp...@forum.dlang.org... > On Sunday, 6 May 2012 at 22:50:56 UTC, David Nadlinger wrote: >> On Sunday, 6 May 2012 at 22:42:21 UTC, James Miller wrote: >>> I think FUU is the most appropriate sentiment here. >> >> Wait till you try using conditional blocks in Lighty's configuration >> files. [1] >> >> David >> >> >> [1] lighttpd supports conditional blocks for a number of predefined >> variables, including http host, . - but only evaluates the first (or was >> it: last?) one of a kind, and silently discards the other ones. >> Especially funny if you use a Debian-style configuration where >> configuration is split over a number of files >> (conf-available/conf-enabled directories). > > I think I remember that from when I was running Lighty, it seemed awesome > at first, then quickly became a nightmare to manage. > > Yeah, I went Apache -> Lighttpd -> nginx for webservers, nginx is > definitely the best so far. Not as many features as Apache, but I find it > suitable, and (F)CGI is plenty fast enough using a local socket. > I guess I must have never gotten as fancy with Apache as other people have, but when I went Apache -> Nginx, my thought was "Wait a minute...I thought people said Nginx was less feature-rich than Apache." Maybe I just don't wear the sysadmin hat enough, but I've never come across anything I needed to do in Apache that I couldn't do in Nginx (assuming a version of Nginx compiled with all the official bells and whistles). It even supports directory listings, which [pleasantly] surprised me. And URL-rewriting in Nginx doesn't make my brain hurt, which is a nice change :)
Re: -wi on default?
"Jonathan M Davis" wrote in message news:mailman.407.1336445190.24740.digitalmar...@puremagic.com... > On Tuesday, May 08, 2012 04:21:06 bearophile wrote: >> Jonathan M Davis: >> > A good programmer will never leave _any_ warnings in committed >> > code. >> >> Sometimes warnings are wrong, the compiler is not perfect. >> If the compiler is certain there is a mistake in the code, then >> generating an error is better. Bugs are probabilistic. >> Good lints don't have just "errors", they report issues >> classified in four or five levels of increasingly probability of >> actual problem being present (naming them something like "Info", >> "Note", "Warning", "Probable Error", and "Error"). > > If it's not something that _must_ be fixed, the compiler should _not_ > complain > about it precisely because you should _never_ leave any warnings in > committed > code. Leaving warnings in committed code (even if invalid) leads to valid > warnings being missed and/or ignored, which leads to bugs being uncaught. > If a > compiler restricts itself to stuff which is _definitively_ wrong, then > that > isn't a problem. A compiler is _not_ a lint tool and shouldn't be treated > as > one. > A compiler isn't a profilier, documentation generator or unittesting tool either, but a big part of D's philosophy is that there *is* real value in having such things in the compiler anyway. The more significant warnings should normally be on (ie, stuff that's ok while debuggng, but shouldn't be checked in), but lint-style pedantic analysis likely *shouldn't* be enabled on every build anyway, so the "stuff getting ignored" argument doesn't really apply. And as I said some time ago, if you still *really* want a line tool to be separate from the compiler for whatever "purity" or ideological reason, that'd be easy enough to do: $cat dlint #!/bin/bash dmd -lint "$*" #or dmd -pedantic-warnings "$*"
Re: -wi on default?
"Jonathan M Davis" wrote in message news:mailman.406.1336442026.24740.digitalmar...@puremagic.com... > > And -w is _completely_ unique AFAIK. No, -w is literally the same as "Treat warnings as errors", which many compilers have (esp. C/C++). DMD is just unique in *calling* it "Warnings" instead of "Treat warnings as errors". > That said, I increasingly agree with Walter's philosophy that something > should > either be an error or not and that warnings are flawed by nature. I always felt (and still do) that that's an overly puritanical view of reality. In an ideal world, yes, there should be no need for warnings and everything is either right or wrong. Problem is, reality sucks, and there are times when it's impratical or unrealistic to cram a bit of grey into that binary "right-or-wrong" mold. Hence, warnings. > So, nothing > which is a warning is really any different from an error except for the > fact > that it may be reasonable to leave it alone temporarily while editing or > debugging code. I consider that a very strong argument *in favor* of warnings having real value. Of course, this isn't to say that there aren't any warnings we should change into errors. Mandatory flow-control at the end of a "case:" block is a prime example, IMHO.
Re: -wi on default?
On Tuesday, May 08, 2012 04:21:06 bearophile wrote: > Jonathan M Davis: > > A good programmer will never leave _any_ warnings in committed > > code. > > Sometimes warnings are wrong, the compiler is not perfect. > If the compiler is certain there is a mistake in the code, then > generating an error is better. Bugs are probabilistic. > Good lints don't have just "errors", they report issues > classified in four or five levels of increasingly probability of > actual problem being present (naming them something like "Info", > "Note", "Warning", "Probable Error", and "Error"). If it's not something that _must_ be fixed, the compiler should _not_ complain about it precisely because you should _never_ leave any warnings in committed code. Leaving warnings in committed code (even if invalid) leads to valid warnings being missed and/or ignored, which leads to bugs being uncaught. If a compiler restricts itself to stuff which is _definitively_ wrong, then that isn't a problem. A compiler is _not_ a lint tool and shouldn't be treated as one. > > But certainly the normal thing to do would be to make -wi the > > default. It'll never happen, but it would be how most compilers > > work. > > Thank you Jonathan for the very nice way you kill this idea ;-) I > have some faith in future improvements still. It'll never happen because you'll never convince Walter of it. As Nick points out, it was a miracle to get him to add -wi in the first place. Feel free to try, but I'd be _very_ surprised if you managed it. - Jonathan M Davis
Re: GSOC Linker project
Interesting reading. I took a look at page 23, and didn't find the mention of C. Maybe I didn't read carefully? On 5/8/2012 3:34 AM, Paulo Pinto wrote: > Hi, > > it seems I have to excuse myself. I could not find anything > from Adele Goldberg. > > So my statement is false. Most likely I ended up confusing > Fran Allen's interview in Coders at Work, with some nonsense > in my head. > > Still, I leave here a few links I manage to find from Fran Allen. > > Some remarks about bad languages on the page 27 > http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf > > Complaint about C on slide 23 > http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf > > Another remark about C > http://www.windley.com/archives/2008/02/fran_allen_compilers_and_parallel_computing_systems.shtml > > > A video recorded at Purdue University, she also talks about C on minute 51 > http://www.youtube.com/watch?v=Si3ZW3nI6oA > > -- > Paulo > > Am 07.05.2012 10:41, schrieb Jens Mueller: >> Paulo Pinto wrote: >>> On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote: Paulo Pinto wrote: > AST/symbol table manipulation is way faster than reparsing code. > > People keep talking about D and Go compilation speed, while I > was already > enjoying such compile times back in 1990 with Turbo Pascal in > computers much > less powerfull than my laptop. > > But C and C++ with their 70's compiler technology, somehow won > the > market share, > and then people started complaining about compilation speeds. > > Adele Golberg, once wrote a paper telling how C made the > compiler technology > regress several decades. Do you happen to remember to exact title of that paper? Thanks. Jens >>> >>> I'll try to find it, as I don't recall the title. >>> >>> I just remember that it made some remarks how primitive C was in >>> regard >>> to Algol toolchains. >> >> Many thanks. >> I couldn't find it myself and I'm interested because Fran Allen said >> something similar in Coders at Work. >> I didn't understand what she meant. Andrei suggested that it is mostly >> (only?) about overlapping pointers to memory. I'm just curious. >> >> Jens >
Re: -wi on default?
Jonathan M Davis: A good programmer will never leave _any_ warnings in committed code. Sometimes warnings are wrong, the compiler is not perfect. If the compiler is certain there is a mistake in the code, then generating an error is better. Bugs are probabilistic. Good lints don't have just "errors", they report issues classified in four or five levels of increasingly probability of actual problem being present (naming them something like "Info", "Note", "Warning", "Probable Error", and "Error"). But certainly the normal thing to do would be to make -wi the default. It'll never happen, but it would be how most compilers work. Thank you Jonathan for the very nice way you kill this idea ;-) I have some faith in future improvements still. Bye, bearophile
Re: -wi on default?
On Tuesday, May 08, 2012 01:25:54 bearophile wrote: > They are discussing about having -Wall on default in GCC 4.8: > > http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html > http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092 > > In D.learn I've seen plenty of people not use -wi (or -w) in D > programming, and this has caused some troubles. > > So what do you think about having "-wi" (and even -property too) > on default in D (and have a compiler switch to disable warnings > on request)? The funny thing is that what -wi does is how every other compiler I've ever used operates. Warnings are always on and never stop compilation. Additional flags may add new warnings, and others may be used to silence certain warnings, but dmd's default of _no_ warnings is very odd. And -w is _completely_ unique AFAIK. The idea of basically _adding errors_ is a bit odd. So, from the standpoint of how compilers typically work, Walter's choices are definitely odd. That said, I increasingly agree with Walter's philosophy that something should either be an error or not and that warnings are flawed by nature. A good programmer will never leave _any_ warnings in committed code. So, nothing which is a warning is really any different from an error except for the fact that it may be reasonable to leave it alone temporarily while editing or debugging code. And as such, having warnings becomes seriously suspect in the first place - _especially_ when a warning isn't something that a programmer would necessarily agree needs to be fixed. They ultimately lead to bad programmers leaving them in, making it difficult to see new ones or see what's wrong in general, and it can be a royal pain to go and spend the time to clean up all of the existing warnings (I've done it in real world projects in Java and C++; I hate it). So, I'd actually be tempted to argue for making -w the default, and ditching - w and -wi entirely. And Walter's probably more likely to go for that then making -wi the default. But certainly the normal thing to do would be to make -wi the default. It'll never happen, but it would be how most compilers work. - Jonathan M Davis
Re: -wi on default?
"bearophile" wrote in message news:rxwrviokohajqsmkb...@forum.dlang.org... > They are discussing about having -Wall on default in GCC 4.8: > > http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html > http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092 > > In D.learn I've seen plenty of people not use -wi (or -w) in D > programming, and this has caused some troubles. > > So what do you think about having "-wi" (and even -property too) on > default in D (and have a compiler switch to disable warnings on request)? I'm all for it, but (for DMD) I don't think Walter will ever go for it. Just getting him to cave and allow the -wi switch in the first place took a *lot* of nagging ;) (I'm still *very* thankful -wi did get put in, though!)
Re: run-time stack-based allocation
On 5/7/2012 12:08 PM, Gor Gyolchanyan wrote: Wasn't there an allocator mechanism under development for phobos? I remember there was a StackAllocator, that can span for arbitrary scopes. What's up with that? I wrote one. It's at https://github.com/dsimcha/TempAlloc . It hasn't been accepted to Phobos, though, because of issues w.r.t. figuring out what a more general allocator interface should look like.
Re: Escaping control in formatting (again)
Posted pull request:
https://github.com/D-Programming-Language/phobos/pull/573
Kenji Hara
2012/5/7 Denis Shelomovskij :
> 07.05.2012 11:39, kenji hara написал:
>
>> In prev thread, I have posted a proposal, but it didn't posted to
>> newsgroup, I don't know why.
>> I re-post my proposal.
>>
>>
>> If the leading compound format specifier has a '-' flag, like "%-( ...
>> %)", it disables auto-escaping for the elements formatting.
>>
>> writefln(">%(%s, %)<", ["hello", "world"]); // output:>"hello", "world"<
>> writefln(">%-(%s, %)<", ["hello", "world"]); // output:>hello, world<
>>
>> You can format the elements as like outside of compound format specifiers.
>> How about you?
>
>
> This is enough for my own needs. Thanks! Who is to implement this?
>
> Looks line nobody needs features from my original proposal so they shouldn't
> be discussed further (unless will become needed).
>
>
> --
> Денис В. Шеломовский
> Denis V. Shelomovskij
ZeroBUGS debugger for D
http://www.reddit.com/r/cpp/comments/tbouj/zerobugs_modular_debugger_for_ccd_including_gui/
Re: -wi on default?
Alex Rønne Petersen: I think individual options to turn specific warnings off will complicate things too much. What I think we should do is make -wi the default and make an option that is just the inverse. Right, that's what I meant, a single switch to disable all warnings. Bye, bearophile
Re: -wi on default?
On May 7, 2012 7:33 PM, "Alex Rønne Petersen" wrote: > (I mean, we're D, not C; we don't have over 9000 warning variants). > > -- > - Alex Yet.
Re: -wi on default?
On 08-05-2012 01:25, bearophile wrote: They are discussing about having -Wall on default in GCC 4.8: http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092 In D.learn I've seen plenty of people not use -wi (or -w) in D programming, and this has caused some troubles. So what do you think about having "-wi" (and even -property too) on default in D (and have a compiler switch to disable warnings on request)? Bye, bearophile We should strive to avoid warnings at all. Usually (though not always) something that is a warning should really be an error. That said, I think turning these on by default is a very good idea. I think individual options to turn specific warnings off will complicate things too much. What I think we should do is make -wi the default and make an option that is just the inverse. I think that will suffice for most real use cases (I mean, we're D, not C; we don't have over 9000 warning variants). -- - Alex
-wi on default?
They are discussing about having -Wall on default in GCC 4.8: http://gcc.gnu.org/ml/gcc/2012-04/msg00087.html http://gcc.gnu.org/ml/gcc/2012-04/threads.html#00092 In D.learn I've seen plenty of people not use -wi (or -w) in D programming, and this has caused some troubles. So what do you think about having "-wi" (and even -property too) on default in D (and have a compiler switch to disable warnings on request)? Bye, bearophile
Re: Defining a custom *constructor* (not initializer!)
On Monday, 7 May 2012 at 21:07:15 UTC, Steven Schveighoffer wrote:
I guess I don't really understand that. Who is responsible for
cleaning up your class instance? The way I was understanding
your description, I thought it was the C window runtime calling
a callback you provide to it. Why do you need to have the GC
clean it up?
Ah, I see why that's confusing.
Here's a (hopefully better) explanation:
Just as with any other object that represents an outside resource
(e.g. a File/Stream/whatever), the lifetime of the unmanaged
object should always follow the lifetime of the managed object.
In other words, this means that the creation of a Window object
MUST be associated with the system call CreateWindow() (which in
turns calls the window dispatcher function, WndProc, with the
message WM_CREATE).
And, more importantly, this means that if the GC collects the
Window object, then DestroyWindow() MUST be called on the kernel
object, so that the window handle doesn't get leaked.
Just as with any other resource.
The trouble is that, as-is, this behavior is NOT implementable
with a simple Window class whose constructor calls CreateWindow()
and whose destructor calls DestroyWindow().
Why? Because if you were to do that in the constructor or
destructor, the system would call back your WndProc() function,
which is a *virtual* function meant to be overridden in the
derived classes (so that they can handle events, such as the
creation/destruction of the window, or the calculation of the
window size, etc. properly).
That would mean your WndProc() in the derived instance would be
called *before* the constructor of the derived instance is
called, which is obviously not what you want.
Ditto with the destructor -- if you were to call DestroyWindow()
in the ~Window(), then it would call back WndProc with the
message WM_DESTROY in the derived class.
The only solution I see is to somehow call DestroyWindow()
*BEFORE* you call the destructor, and call the destructor
manually when the WM_DESTROY message is received. Ditto with the
constructor: you need to somehow call CreateWindow() *BEFORE* you
call the constructor, so that when you receive the WM_CREATE
message, you can call the constructor manually.
Only by hijacking the construction and destruction call can you
guarantee that the construction/destruction happens in an orderly
fashion, i.e. that the kernel object lifetime tracks the user
object lifetime properly. Otherwise you either miss getting some
notifications at critical points (which results in incorrect
code, which some people may or may not care about), or you risk
getting a handle leak (also obviously bad).
Or you risk making the design pattern pretty horrific, kind of
like how C# has a "NativeWindow" inside of the Control class, and
they both have creation parameters, and they both register
themselves ("park" themselves) globally on a static/shared field,
and run into all sorts of ugly issues that you shouldn't need to
run into. (If you look at the code and understand what they're
doing, you'll see what I mean when I say it's ugly...)
Summary: Yes, I need the GC so I can manage the HWND lifetime
properly, i.e. so it tracks the lifetime of the Window object
(otherwise you can easily leak a handle). But in order to do
this, I also need to be able to call the constructor/destructor
manually, because the C code does this through a callback, which
isn't possible when your object is being GC'd, due to virtual
method re-entrancy issues with finalization.
Does that make sense? Is any part of it still unclear?
Re: Properties don't behave like variables?
On 7 May 2012 23:43, Artur Skawina wrote:
> On 05/08/12 00:32, Iain Buclaw wrote:
>> On 7 May 2012 23:23, Artur Skawina wrote:
On 2012-05-07 21:53, Steven Schveighoffer wrote:
> How do you overload the operator for a property? For example:
>>>
>>> It can of course be done [1], but i think the question was whether the
>>> compiler should do the obvious rewrite from 'prop() |= 2' to
>>> 'prop(prop()|2)'.
>>> Unconditionally, as not doing it every time would be confusing and lead
>>> to bugs where the setter gets bypassed.
>>> But what about the case where you want to return a ref to /different/
>>> objects? I guess mandating a setter wouldn't be problem, and still better
>>> than the alternative.
>>>
>>> artur
>>>
>>> [1] I shouldn't even be posting this, as someone might actually think about
>>> using something like it...
>>>
>>> struct S {
>>> int i;
>>> @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; }
>>> }
>>>
>>> int main()
>>> {
>>> S s;
>>> s.p |= 2;
>>> return s.p;
>>> }
>>>
>>> struct PropProxy(RT, string sym) {
>>> @property ref data() { return *cast(RT*)&this; }
>>> @property ref get() { return __traits(getMember, data, sym); }
>>> alias get this;
>>> auto opOpAssign(string op, T)(T b) {
>>> return mixin("data." ~ sym ~ " " ~ op ~ "= b");
>>> }
>>> }
>>>
>>> Keep in mind this isn't a serious suggestion, more of a joke; i wrote it
>>> just
>>> out of curiosity, to check if GDC would be able to turn it all into
>>> "mov $0x2, %eax; ret;". ;)
>>>
>>
>> Your wishful thinking serves you well. :-)
>>
>
> Just to make it clear - the above results in:
>
> 08049e50 <_Dmain>:
> 8049e50: 55 push %ebp
> 8049e51: b8 02 00 00 00 mov $0x2,%eax
> 8049e56: 89 e5 mov %esp,%ebp
> 8049e58: 5d pop %ebp
> 8049e59: c3 ret
>
> and i believe that after Iain's recent GDC ABI changes the frame pointer
> manipulation is gone, so it all *really* compiles down to just one
> instruction.
Frame pointer manipulation only now occurs on x86 for functions that
compile in inline assembler (but not GCC inline assembler, and not
naked functions).
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Properties don't behave like variables?
On 05/08/12 00:32, Iain Buclaw wrote:
> On 7 May 2012 23:23, Artur Skawina wrote:
>>> On 2012-05-07 21:53, Steven Schveighoffer wrote:
>>>
How do you overload the operator for a property? For example:
>>
>> It can of course be done [1], but i think the question was whether the
>> compiler should do the obvious rewrite from 'prop() |= 2' to
>> 'prop(prop()|2)'.
>> Unconditionally, as not doing it every time would be confusing and lead
>> to bugs where the setter gets bypassed.
>> But what about the case where you want to return a ref to /different/
>> objects? I guess mandating a setter wouldn't be problem, and still better
>> than the alternative.
>>
>> artur
>>
>> [1] I shouldn't even be posting this, as someone might actually think about
>> using something like it...
>>
>> struct S {
>> int i;
>> @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; }
>> }
>>
>> int main()
>> {
>> S s;
>> s.p |= 2;
>> return s.p;
>> }
>>
>> struct PropProxy(RT, string sym) {
>> @property ref data() { return *cast(RT*)&this; }
>> @property ref get() { return __traits(getMember, data, sym); }
>> alias get this;
>> auto opOpAssign(string op, T)(T b) {
>> return mixin("data." ~ sym ~ " " ~ op ~ "= b");
>> }
>> }
>>
>> Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just
>> out of curiosity, to check if GDC would be able to turn it all into
>> "mov $0x2, %eax; ret;". ;)
>>
>
> Your wishful thinking serves you well. :-)
>
Just to make it clear - the above results in:
08049e50 <_Dmain>:
8049e50: 55 push %ebp
8049e51: b8 02 00 00 00 mov$0x2,%eax
8049e56: 89 e5 mov%esp,%ebp
8049e58: 5d pop%ebp
8049e59: c3 ret
and i believe that after Iain's recent GDC ABI changes the frame pointer
manipulation is gone, so it all *really* compiles down to just one instruction.
But i haven't checked with a current GDC. r748:ab99d67f04c2 generates the above
asm sequence, which is good enough for this quick test, ;)
artur
Re: Properties don't behave like variables?
On 7 May 2012 23:23, Artur Skawina wrote:
>> On 2012-05-07 21:53, Steven Schveighoffer wrote:
>>
>>> How do you overload the operator for a property? For example:
>
> It can of course be done [1], but i think the question was whether the
> compiler should do the obvious rewrite from 'prop() |= 2' to 'prop(prop()|2)'.
> Unconditionally, as not doing it every time would be confusing and lead
> to bugs where the setter gets bypassed.
> But what about the case where you want to return a ref to /different/
> objects? I guess mandating a setter wouldn't be problem, and still better
> than the alternative.
>
> artur
>
> [1] I shouldn't even be posting this, as someone might actually think about
> using something like it...
>
> struct S {
> int i;
> @property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; }
> }
>
> int main()
> {
> S s;
> s.p |= 2;
> return s.p;
> }
>
> struct PropProxy(RT, string sym) {
> @property ref data() { return *cast(RT*)&this; }
> @property ref get() { return __traits(getMember, data, sym); }
> alias get this;
> auto opOpAssign(string op, T)(T b) {
> return mixin("data." ~ sym ~ " " ~ op ~ "= b");
> }
> }
>
> Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just
> out of curiosity, to check if GDC would be able to turn it all into
> "mov $0x2, %eax; ret;". ;)
>
Your wishful thinking serves you well. :-)
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: run-time stack-based allocation
Yes! I really want it! There are tons of instances when a heap allocation is done instead of stack allocation because of dynamic size alone. If its lifetime is limited by a scope (any scope) - it doesn't belong on the heap! On Tue, May 8, 2012 at 2:07 AM, deadalnix wrote: > Le 07/05/2012 13:58, Gor Gyolchanyan a écrit : > >> I'm working on dynamic memory layout manager. Simply put, it will >> allow one to create and use struct types at run-time. >> Normally, you create a struct at compile-time type by specifying an >> ordered list of fields, each with its own type (basically a size) and >> name. >> You then access those fields by calling a compile-time evaluated dot >> operator, which computes the address of the specified field given the >> address of the struct. >> What I'm trying to make is precisely that, except at run-time. >> >> My question is: what is the best way of allocating such a structure on >> the stack? It will, of course, have a dynamically known size. >> > > About that, I already had the need to return a variable that will be > qualified as scope after the return. > > It would also be usefull to safely implement stack allocator. -- Bye, Gor Gyolchanyan.
Re: Properties don't behave like variables?
> On 2012-05-07 21:53, Steven Schveighoffer wrote:
>
>> How do you overload the operator for a property? For example:
It can of course be done [1], but i think the question was whether the
compiler should do the obvious rewrite from 'prop() |= 2' to 'prop(prop()|2)'.
Unconditionally, as not doing it every time would be confusing and lead
to bugs where the setter gets bypassed.
But what about the case where you want to return a ref to /different/
objects? I guess mandating a setter wouldn't be problem, and still better
than the alternative.
artur
[1] I shouldn't even be posting this, as someone might actually think about
using something like it...
struct S {
int i;
@property ref p() { return *cast(PropProxy!(typeof(this),"i")*)&this; }
}
int main()
{
S s;
s.p |= 2;
return s.p;
}
struct PropProxy(RT, string sym) {
@property ref data() { return *cast(RT*)&this; }
@property ref get() { return __traits(getMember, data, sym); }
alias get this;
auto opOpAssign(string op, T)(T b) {
return mixin("data." ~ sym ~ " " ~ op ~ "= b");
}
}
Keep in mind this isn't a serious suggestion, more of a joke; i wrote it just
out of curiosity, to check if GDC would be able to turn it all into
"mov $0x2, %eax; ret;". ;)
Re: run-time stack-based allocation
Le 07/05/2012 13:58, Gor Gyolchanyan a écrit : I'm working on dynamic memory layout manager. Simply put, it will allow one to create and use struct types at run-time. Normally, you create a struct at compile-time type by specifying an ordered list of fields, each with its own type (basically a size) and name. You then access those fields by calling a compile-time evaluated dot operator, which computes the address of the specified field given the address of the struct. What I'm trying to make is precisely that, except at run-time. My question is: what is the best way of allocating such a structure on the stack? It will, of course, have a dynamically known size. About that, I already had the need to return a variable that will be qualified as scope after the return. It would also be usefull to safely implement stack allocator.
Re: Properties don't behave like variables?
On Monday, May 07, 2012 23:41:33 Chris Cain wrote: > On Monday, 7 May 2012 at 21:34:29 UTC, Jonathan M Davis wrote: > > You mean the setter? > > > > Having a getter property function return by ref does allow you > > to use a > > property exactly as you would a variable, because you're > > operating on the ref > > that's returned. It also makes the property function > > nigh-on-useless, because > > then you're operating on its associated variable outside of the > > property > > function, making it so that you can no longer control access to > > it. You pretty > > much might as well make it a public variable at that point. Not > > to mention, > > even if returning by ref didn't have that problem, it would > > only work in cases > > where the property function was associated with an actual > > variable (since you > > have to return a ref to _something_), so it would still be > > impossible to > > emulate a variable with property functions which calculate the > > value from > > other variables or which grab the value from somewhere else > > (e.g. a database). > > > > - Jonathan M Davis > > And what about my idea of returning a struct by ref and using a > struct to represent all of the operations you're interested in? > As far as I can see, it should work, but admittedly, it's not as > slick as it could be. It doesn't work unless you have a member variable which is the struct, which may or may not be acceptable (properties don't _have_ to have underlying member variables at all), and while it may work as a clever workaround, I'd definitely argue that it's something that should be fixed in the language. It seems pretty bad to me to have to create a struct which you return by ref just to get a property to fully act like a variable. - Jonathan M Davis
Re: GSOC Linker project
Am 07.05.2012 15:27, schrieb Paulo Pinto: I like the idea, need to check what information I could provide. Wirth's books about Oberon also provide similar information. -- Paulo "dennis luehring" wrote in message news:jo85t1$1n9b$1...@digitalmars.com... Am 07.05.2012 07:53, schrieb Paulo Pinto: I really really think that mankind did a wrong turn when C won over Pascal in the 80's. And that Wirth somehow lost interest in the industry and did not try to push Modula-* or Oberon. There are some papers where he states this. Now we suffer from - daggling pointers - buffer overflows - pre-historic compiler toolchains With luck, Spec#, Go or more nicely D, will put us back on track. we should collect all the advantages of turbo pascal/delphi object-file-formats and make a small description post to show others in a clear understandable way how good/and longlife these technics are so the unit-system (turbo pascal: .pas -> .tpu, delphi: .pas->.dcu, free pascal: .pas -> ppu), the tpumover, ppumover for tpl or ppl libraries, the dll delphi solution .bpl and the advantage of controling the output of source inside the source program -> exe, unit -> object, library -> dynamic libray etc. any ideas how to start? Description of the Free Pascal unit format http://www.freepascal.org/docs-html/prog/progap1.html#progse67.html How the dump command works http://www.freepascal.org/tools/ppudump.htm The source code of the ppudump utility http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/utils/ppudump.pp?view=markup -- Paulo
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 20:20:34 UTC, Mehrdad wrote: Yeah, but mixins are so hacky. They're like C macros, basically. I'd have to say that C macros have many, _many_ more pitfalls than mixins.
Re: Properties don't behave like variables?
On Monday, 7 May 2012 at 21:34:29 UTC, Jonathan M Davis wrote: You mean the setter? Having a getter property function return by ref does allow you to use a property exactly as you would a variable, because you're operating on the ref that's returned. It also makes the property function nigh-on-useless, because then you're operating on its associated variable outside of the property function, making it so that you can no longer control access to it. You pretty much might as well make it a public variable at that point. Not to mention, even if returning by ref didn't have that problem, it would only work in cases where the property function was associated with an actual variable (since you have to return a ref to _something_), so it would still be impossible to emulate a variable with property functions which calculate the value from other variables or which grab the value from somewhere else (e.g. a database). - Jonathan M Davis And what about my idea of returning a struct by ref and using a struct to represent all of the operations you're interested in? As far as I can see, it should work, but admittedly, it's not as slick as it could be.
Re: Properties don't behave like variables?
On Monday, May 07, 2012 23:14:36 Jacob Carlborg wrote:
> On 2012-05-07 22:16, Michael wrote:
> > import std.stdio;
> >
> > int pro = 1;
> >
> > @property ref auto prop()
> > {
> >
> >return pro;
> >
> > }
> >
> > @property void prop(int value)
> > {
> >
> >pro = value;
> >
> > }
> >
> > void main()
> > {
> >
> >writeln(prop |= 2);
> >
> > }
>
> You're bypassing the getter.
You mean the setter?
Having a getter property function return by ref does allow you to use a
property exactly as you would a variable, because you're operating on the ref
that's returned. It also makes the property function nigh-on-useless, because
then you're operating on its associated variable outside of the property
function, making it so that you can no longer control access to it. You pretty
much might as well make it a public variable at that point. Not to mention,
even if returning by ref didn't have that problem, it would only work in cases
where the property function was associated with an actual variable (since you
have to return a ref to _something_), so it would still be impossible to
emulate a variable with property functions which calculate the value from
other variables or which grab the value from somewhere else (e.g. a database).
- Jonathan M Davis
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 20:20:34 UTC, Mehrdad wrote: On Monday, 7 May 2012 at 16:52:18 UTC, Arne wrote: I think you'd need to modify the compiler for this, since alloca is 'magical'. wouldn't mixin's be a solution, one can inject an alloca to the current scope, and then call the constructor... Yeah, but mixins are so hacky. They're like C macros, basically. /rant Well, I think if the world had never seen all the bad side-effects from 'C macros', most people would wholeheartedly embrace mixin's today... since it cleanly avoids 'x' number of design pitfalls from #define. For maintenance, performance, portability considerations I definitely prefer mixin's over reimplementing alloca for every current and future targets/calling conventions.
Re: Properties don't behave like variables?
On 2012-05-07 22:16, Michael wrote:
import std.stdio;
int pro = 1;
@property ref auto prop()
{
return pro;
}
@property void prop(int value)
{
pro = value;
}
void main()
{
writeln(prop |= 2);
}
You're bypassing the getter.
--
/Jacob Carlborg
Re: Properties don't behave like variables?
On 2012-05-07 21:53, Steven Schveighoffer wrote: How do you overload the operator for a property? For example: Hm, I didn't think that one through :) -- /Jacob Carlborg
Re: Properties don't behave like variables?
On Mon, 07 May 2012 16:15:54 -0400, Mehrdad wrote:
On Monday, 7 May 2012 at 12:43:42 UTC, Steven Schveighoffer wrote:
On Sun, 06 May 2012 22:05:20 -0400, Mehrdad
wrote:
Why doesn't this compile?
@property int foo() { return 1; }
@property void foo(int v) { }
void main()
{
foo |= 2;
}
It's like this in C#.
Um, I to differ...
Oh! I didn't express myself properly :) It's like this in C# means that
the above *does* compile in C# :) Sorry for the confusion.
-Steve
Re: Properties don't behave like variables?
Definitely a lot more code, but maybe something like this would work for this problem: https://gist.github.com/c65e2cc6011d7887efcd
Re: Defining a custom *constructor* (not initializer!)
On Mon, 07 May 2012 16:09:06 -0400, Mehrdad wrote:
On Monday, 7 May 2012 at 19:39:04 UTC, Steven Schveighoffer wrote:
I'm just asking if I can call the constructor manually, because
(like I wrote in my first post...) sometimes the C code you're
interoperating with takes control away from you, and just calls a
callback on your behalf when constructing the object.
I wasn't sure, but I just tried it out:
import std.stdio;
extern(C) void *_d_newclass(TypeInfo t);
class C
{
int x;
this(int x){this.x = x;}
}
void main()
{
C c = cast(C)_d_newclass(typeid(C));
c.__ctor(1);
writeln(c.x); // outputs 1
}
Seems to work
-Steve
Nonono :( you still missed what I was saying.
Unless you're suggesting I replace _d_newclass, but that isn't
type-specific (and I certainly don't want to replace it globally).
All _d_newclass does is allocate memory for the object and initialize it
to it's initial state (i.e. if an int member is initialized to 5, it does
this). It does not call the constructor. So no, I was assuming you'd
either re-use it, or implement some other allocation means.
Here's another attempt at the explanation:
I definitely CAN make a helper method to do this for me. It's the whole
factory pattern, etc.
The problems are that:
(1) The user wouldn't be able to say "new Window()" anymore (I already
explained why)
Right. new === allocate memory on the GC heap (via _d_newclass) and call
the constructor. If you don't want that you cannot use new.
(2) The object couldn't be garbage collected.
Then you definitely don't want GC allocated memory.
Regarding #2, in case it doesn't make sense why:
It's because the C code takes control *AWAY* from you when you tell it
to destroy the object.
In my case, DestroyWindow(HWND) calls WndProc(WM_DESTROY,..), which is a
member function.
So it should not call GC.malloc to create the memory, use C's malloc, and
GC.addRoot.
I CANNOT call DestroyWindow() in the finalizer, because then WndProc
would be called on a *derived* class during cleanup. (It's the *same*
issue as with the constructor.) So I'd have to do this manually, which
defeats the whole point of making the object garbage-collectible in the
first place.
What I'm *want* to be able to do is, basically, to specify that I have
a static method that will take care of finalizing an object. (Something
like: void finalize(Window o))
What I think you want is both an allocator/initializer and a destructor.
Kind of like malloc and free. The two are going to be tied together, so
you should always have to call the correct destructor for an object
allocated with the initializer.
Then, when the object is being finalized, the garbage collector would
NOT call the object's finalizer directly. Instead, it would call my
STATIC method to do the rest of the cleanup.
The STATIC destruction method would call DestroyWindow() on the handle,
and DestroyWindow() would send the notification to the window through a
modified WndProc() (which I can always redirect, to make it NOT be a
member function during the following phase).
It would pass in a context parameter -- which would probably be the
Window object itself -- to my (redirected) WndProc.
The WndProc() would THEN call the Window's finalizer manually (and tell
the GC that the object is done being finalized, so it can be collected).
I think avoiding the GC completely is a much better idea. All you need to
be concerned about is references from your object into the GC heap (i.e.
use addRoot/removeRoot).
I can't think of any "nice" way around this. Either the HWND would have
to be managed manually (in which case, that defeats the purpose of using
the GC to ensure its destruction along with the object), or I would need
an extra indirection in Window (which REALLY overcomplicates the design,
and introduces lots of inheritance/template usage issues).
I guess I don't really understand that. Who is responsible for cleaning
up your class instance? The way I was understanding your description, I
thought it was the C window runtime calling a callback you provide to it.
Why do you need to have the GC clean it up?
Do you (or others) reckon a pull request to modify _d_newclass and
_d_delclass so that they would call a custom static "constructor" and
"destructor" for a class (if it specifies this should be the case) might
be accepted?
_d_newclass does *not* call ctors, the compiler does that when you say
"new" Otherwise, _d_newclass it would have to handle passing through all
the parameters to the ctor.
It does roughly what I showed you in my quick example.
-Steve
Re: UFCS and operator overloading
Nick Sabalausky wrote:
> "Jens Mueller" wrote in message
> news:mailman.391.1336410464.24740.digitalmar...@puremagic.com...
> > Hi,
> >
> > from my understanding UFCS is supposed to work with operator overloading.
> > I.e.
> > in the following a + b should work
> >
> > struct Foo {}
> >
> > Foo opBinary(string op)(Foo lhs, Foo rhs) if (op == "+")
> > {
> >return Foo.init;
> > }
> >
> > unittest
> > {
> >Foo a, b;
> >a + b; // fails to compile
> > }
> >
> > Is UFCS supposed to work with operator overloading, isn't it?
> >
> > Jens
>
> I don't know why that doesn't work (unless you just need to make it "auto c
> = a + b;" so it isn't a "statement has no effect"?),
auto c = ... has no effect. I'm just ignoring the return value.
> but FWIW that's not an example of UFCS. UFCS would mean calling your
> opBinary above like this:
>
> a.opBinary!"+"(b)
>
> Instead of this:
>
> opBinary!"+"(a, b)
Right. So what is a + b rewritten to. I assume it is rewritten to
a.opBinary!"+"(b). And then UFCS should kick in and rewrite it to
opBinary!("+")(a, b).
You seem to believe that a + b is rewritten to opBinary!("+")(a, b).
Right?
Jens
Re: "R" suffix for reals
On Monday, 7 May 2012 at 19:23:03 UTC, Walter Bright wrote: On 5/7/2012 12:07 PM, Steven Schveighoffer wrote: However, I think these examples are misleading and do not prove the point. It shows IMO more that you are better off declaring the type on the left if your code depends on it always staying the same. i.e. this does not have that problem: real r = 1L; I tend to agree. If you're declaring things with 'auto', then you should not be relying on a specific type being inferred from the initializer - that would be poor style. Use of auto implies your code is more generic and adaptable to whatever type the initializer turns out to be. If your usage of r requires it to be a specific type, it should be declared as having that type. Alright, I admit 'auto' is somewhat of a contrived example, my main concern is with 'function overloading'/'template type inference'/when creating 'compound/complex types'. I think we have a general issue with concise definitions of literals... 1. ambiguous suffixes 2. manu's __vector() 3. dynamic vs static array literals: auto[$] ? any other similar issues? What is the main reason we don't allow... something like: sqrt(real(3)); ... does it result in any parsing ambiguities? I'm hoping for a consistent solution to all of the above issues... be it... suffix or function style initializer... or ... as long as it solves all the above 'literal issues' in a consistent way... Thanks for listening :) Arne
Re: UFCS and operator overloading
Still, not having non-member operator overloads is very bothersome.
On Tue, May 8, 2012 at 12:37 AM, Nick Sabalausky
wrote:
> "Jens Mueller" wrote in message
> news:mailman.391.1336410464.24740.digitalmar...@puremagic.com...
>> Hi,
>>
>> from my understanding UFCS is supposed to work with operator overloading.
>> I.e.
>> in the following a + b should work
>>
>> struct Foo {}
>>
>> Foo opBinary(string op)(Foo lhs, Foo rhs) if (op == "+")
>> {
>> return Foo.init;
>> }
>>
>> unittest
>> {
>> Foo a, b;
>> a + b; // fails to compile
>> }
>>
>> Is UFCS supposed to work with operator overloading, isn't it?
>>
>> Jens
>
> I don't know why that doesn't work (unless you just need to make it "auto c
> = a + b;" so it isn't a "statement has no effect"?), but FWIW that's not an
> example of UFCS. UFCS would mean calling your opBinary above like this:
>
> a.opBinary!"+"(b)
>
> Instead of this:
>
> opBinary!"+"(a, b)
>
>
>
--
Bye,
Gor Gyolchanyan.
Re: [Feature Request] Adding to D lang "set" built-in
On Monday, 7 May 2012 at 05:54:04 UTC, Jonathan M Davis wrote: On Monday, May 07, 2012 06:49:00 Russel Winder wrote: Any language with which the programmer has to develop their own set implementation is sadly lacking. It is true that set can be implemented using a map, but this should be seen as implementation detail, not as programmer level tool. It indicates that set should exist where set does. So for C++ it is in the standard library, for Python it is a built-in (*). The conclusion for D is straightforward. Which issue to I go to to vote? We have RedBlackTree, so we have a set already. What we don't have is a HashSet. However, once the custom allocator stuff has been sorted out, I'd fully expect to have one in std.container along with a variety of other container types which we really should have but don't. Been thinking about this a little. With arrays, fixed arrays and associative arrays being built in, you don't need set to be built in. First it's already hash-map like so it's going to be O(1), and the data being kinda useless can either be a byte, and int (offset to an array perhaps), or to itself. It has the added benefit of being a sparse array when asked of it. So aside from a slight loss in memory space which is only going to be critical in embedded systems. The only thing the builtins don't offer is a way to automatically sort the data, which the libraries and RedBlackTree's do quite well so far as I can see.
Re: opAssign and const?
On Saturday, May 05, 2012 05:50:26 Era Scarecrow wrote: Hmm maybe it should have a preference for Lvalue vs Rvalue... So... Walter or Andrei? 1. no match 2. match with implicit conversions (Lvalue required) 3. match with conversion to const (Lvalue required) 4. match with implicit conversions 5. match with conversion to const 6. exact match Thinking about this, perhaps it should attempt the following order instead. (Not sure of the no match here) 2. match with conversion to const (Lvalue required) 3. match with implicit conversions (Lvalue required) 4. match with conversion to const 5. match with implicit conversions 6. exact match 7. no match - Templates attempted 8. error? Trying the more restrictive ones first. You can convert mutable to const, but you can't turn it around without specific cast and knowledge. If you think about it too, very little code will likely be const, or ones that are const usually will be by themselves so ordering isn't going to be as important.
Re: Why typedef's shouldn't have been removed :(
On Monday, 7 May 2012 at 20:25:35 UTC, Steven Schveighoffer wrote: On Mon, 07 May 2012 15:48:22 -0400, Mehrdad wrote: I'm looking at this: m += 5; // ok m = m + 5; // error And thinking, hm.. this is no good :) Yeah, that means they were implemented poorly. :P It should've been an error for both, because neither of them make sense. I don't see why the first one couldn't have been an error though, so I guess I'll have to dig up old threads on why the first one wasn't disallowed, since I can't see why we couldn't just disallow it right there... C compatibility is not what we are after here, alias already handles C compatibility. I see, ok. Not being one to have used them much, I can only recollect that one example. I do remember people bitching about them quite a bit, and nobody really having any good ideas on how to fix them, but I don't know circa what time period to look for those discussons. One person who was an ardent supporter of typedefs, and still wants *something* like them is bearophile. He might be able to list some issues/find some old posts/bugs that make more sense. Ah okay thanks. @bearophile: If you see happen this, would you mind posting examples? :)
Re: Why not all statement are expressions ?
"deadalnix" wrote in message news:jo9be0$mgh$1...@digitalmars.com... > > This won't work anyway. We are talking about language grammar here. If > made expression, statement would be of type void. Just like assert is. > > The question is why assert is an expression ? Why not other statement > don't follow the same pattern ? Ok, I see what you mean. Maybe it's just because assert works like a function and functions are always expressions? Just a guess.
Re: UFCS and operator overloading
"Jens Mueller" wrote in message
news:mailman.391.1336410464.24740.digitalmar...@puremagic.com...
> Hi,
>
> from my understanding UFCS is supposed to work with operator overloading.
> I.e.
> in the following a + b should work
>
> struct Foo {}
>
> Foo opBinary(string op)(Foo lhs, Foo rhs) if (op == "+")
> {
>return Foo.init;
> }
>
> unittest
> {
>Foo a, b;
>a + b; // fails to compile
> }
>
> Is UFCS supposed to work with operator overloading, isn't it?
>
> Jens
I don't know why that doesn't work (unless you just need to make it "auto c
= a + b;" so it isn't a "statement has no effect"?), but FWIW that's not an
example of UFCS. UFCS would mean calling your opBinary above like this:
a.opBinary!"+"(b)
Instead of this:
opBinary!"+"(a, b)
Re: GSOC Linker project
Hi, it seems I have to excuse myself. I could not find anything from Adele Goldberg. So my statement is false. Most likely I ended up confusing Fran Allen's interview in Coders at Work, with some nonsense in my head. Still, I leave here a few links I manage to find from Fran Allen. Some remarks about bad languages on the page 27 http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf Complaint about C on slide 23 http://www-03.ibm.com/ibm/history/witexhibit/pdf/allen_history.pdf Another remark about C http://www.windley.com/archives/2008/02/fran_allen_compilers_and_parallel_computing_systems.shtml A video recorded at Purdue University, she also talks about C on minute 51 http://www.youtube.com/watch?v=Si3ZW3nI6oA -- Paulo Am 07.05.2012 10:41, schrieb Jens Mueller: Paulo Pinto wrote: On Monday, 7 May 2012 at 07:26:44 UTC, Jens Mueller wrote: Paulo Pinto wrote: AST/symbol table manipulation is way faster than reparsing code. People keep talking about D and Go compilation speed, while I was already enjoying such compile times back in 1990 with Turbo Pascal in computers much less powerfull than my laptop. But C and C++ with their 70's compiler technology, somehow won the market share, and then people started complaining about compilation speeds. Adele Golberg, once wrote a paper telling how C made the compiler technology regress several decades. Do you happen to remember to exact title of that paper? Thanks. Jens I'll try to find it, as I don't recall the title. I just remember that it made some remarks how primitive C was in regard to Algol toolchains. Many thanks. I couldn't find it myself and I'm interested because Fran Allen said something similar in Coders at Work. I didn't understand what she meant. Andrei suggested that it is mostly (only?) about overlapping pointers to memory. I'm just curious. Jens
Re: Why not all statement are expressions ?
Le 07/05/2012 22:27, Nick Sabalausky a écrit :
"Jacob Carlborg" wrote in message
news:jo98d1$frl$1...@digitalmars.com...
On 2012-05-07 19:06, deadalnix wrote:
Hi,
Working on D I noticed that some statement, notably assert, are
expression of type void. Why not all statement (that are not expression
already) are expression ?
I would like that as well.
I'm usually fairly ambivalent about the idea of statements being
expressions, but I would *love* for switch to be usable as an expression.
For instance, in Haxe, you can do stuff like the following, which I get a
ton of use out of and often wish D had:
a = switch(b)
{
case 1: "foo";
case 2: "bar";
case 3: "baz";
case 4: "whee";
default: "blork";
}
The D equivalents aren't terrible, but they aren't nearly as nice.
This won't work anyway. We are talking about language grammar here. If
made expression, statement would be of type void. Just like assert is.
The question is why assert is an expression ? Why not other statement
don't follow the same pattern ?
Re: Why not all statement are expressions ?
"Jacob Carlborg" wrote in message
news:jo98d1$frl$1...@digitalmars.com...
> On 2012-05-07 19:06, deadalnix wrote:
>> Hi,
>>
>> Working on D I noticed that some statement, notably assert, are
>> expression of type void. Why not all statement (that are not expression
>> already) are expression ?
>
> I would like that as well.
>
I'm usually fairly ambivalent about the idea of statements being
expressions, but I would *love* for switch to be usable as an expression.
For instance, in Haxe, you can do stuff like the following, which I get a
ton of use out of and often wish D had:
a = switch(b)
{
case 1: "foo";
case 2: "bar";
case 3: "baz";
case 4: "whee";
default: "blork";
}
The D equivalents aren't terrible, but they aren't nearly as nice.
Re: Why typedef's shouldn't have been removed :(
On Mon, 07 May 2012 15:48:22 -0400, Mehrdad wrote: On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote: I think it was more that the whole concept was flawed -- typedef int myint never really did exactly what you wanted it to. For example: myint m = 1; // ok m += 5; // ok m = m + 5; // error? It's definitely an error, because 5 isn't myint. Of course, it wouldn't be an error in C code, but keeping source compatibility isn't a goal either. I'm looking at this: m += 5; // ok m = m + 5; // error And thinking, hm.. this is no good :) C compatibility is not what we are after here, alias already handles C compatibility. Wouldn't a global search-and-replace that replaced "typedef" with "alias" when porting C code have fixed 99% of this issue, practically speaking? No, it's not a portability issue. It's a WTF issue. Things got even worse when you weren't typedef'ing a basic type. It sounds so trivial to fix though (especially since it's not silent breakage)... Would you mind giving another (actual) example (perhaps with a custom type?) that came up, and which shows the extent of the problem and why it was difficult to solve without disallowing typedef entirely? I'm having a hard time seeing why the problem was so difficult (or tedious) to fix... a search/replace for typedef/alias would've fixed all (or almost) all the cases when porting C code, right? I'm almost 100% certain that the issues had nothing to do with C compatibility. It was all in how D typedefs behaved strangely. Not being one to have used them much, I can only recollect that one example. I do remember people bitching about them quite a bit, and nobody really having any good ideas on how to fix them, but I don't know circa what time period to look for those discussons. One person who was an ardent supporter of typedefs, and still wants *something* like them is bearophile. He might be able to list some issues/find some old posts/bugs that make more sense. -Steve
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 16:52:18 UTC, Arne wrote: I think you'd need to modify the compiler for this, since alloca is 'magical'. wouldn't mixin's be a solution, one can inject an alloca to the current scope, and then call the constructor... Yeah, but mixins are so hacky. They're like C macros, basically.
Re: Properties don't behave like variables?
On Monday, 7 May 2012 at 02:05:21 UTC, Mehrdad wrote:
Why doesn't this compile?
@property int foo() { return 1; }
@property void foo(int v) { }
void main()
{
foo |= 2;
}
import std.stdio;
int pro = 1;
@property ref auto prop()
{
return pro;
}
@property void prop(int value)
{
pro = value;
}
void main()
{
writeln(prop |= 2);
}
No?
// dmd 2.059
Re: Properties don't behave like variables?
On Monday, 7 May 2012 at 20:16:27 UTC, Michael wrote: No? No. Remove "@property void prop(int value)" and see what happens.
Re: Properties don't behave like variables?
On Monday, 7 May 2012 at 12:43:42 UTC, Steven Schveighoffer wrote:
On Sun, 06 May 2012 22:05:20 -0400, Mehrdad
wrote:
Why doesn't this compile?
@property int foo() { return 1; }
@property void foo(int v) { }
void main()
{
foo |= 2;
}
It's like this in C#.
Um, I to differ...
This compiles just fine in C#:
class Program
{
static int Prop { get { return 0; } set { } }
static void Main()
{
Prop |= 1;
}
}
Re: Defining a custom *constructor* (not initializer!)
On Monday, 7 May 2012 at 19:39:04 UTC, Steven Schveighoffer wrote:
I'm just asking if I can call the constructor manually, because
(like I wrote in my first post...) sometimes the C code you're
interoperating with takes control away from you, and just
calls a
callback on your behalf when constructing the object.
I wasn't sure, but I just tried it out:
import std.stdio;
extern(C) void *_d_newclass(TypeInfo t);
class C
{
int x;
this(int x){this.x = x;}
}
void main()
{
C c = cast(C)_d_newclass(typeid(C));
c.__ctor(1);
writeln(c.x); // outputs 1
}
Seems to work
-Steve
Nonono :( you still missed what I was saying.
Unless you're suggesting I replace _d_newclass, but that isn't
type-specific (and I certainly don't want to replace it globally).
Here's another attempt at the explanation:
I definitely CAN make a helper method to do this for me. It's the
whole factory pattern, etc.
The problems are that:
(1) The user wouldn't be able to say "new Window()" anymore (I
already explained why)
(2) The object couldn't be garbage collected.
Regarding #2, in case it doesn't make sense why:
It's because the C code takes control *AWAY* from you when you
tell it to destroy the object.
In my case, DestroyWindow(HWND) calls WndProc(WM_DESTROY,..),
which is a member function.
I CANNOT call DestroyWindow() in the finalizer, because then
WndProc would be called on a *derived* class during cleanup.
(It's the *same* issue as with the constructor.) So I'd have to
do this manually, which defeats the whole point of making the
object garbage-collectible in the first place.
What I'm *want* to be able to do is, basically, to specify that
I have a static method that will take care of finalizing an
object. (Something like: void finalize(Window o))
Then, when the object is being finalized, the garbage collector
would NOT call the object's finalizer directly. Instead, it would
call my STATIC method to do the rest of the cleanup.
The STATIC destruction method would call DestroyWindow() on the
handle, and DestroyWindow() would send the notification to the
window through a modified WndProc() (which I can always redirect,
to make it NOT be a member function during the following phase).
It would pass in a context parameter -- which would probably be
the Window object itself -- to my (redirected) WndProc.
The WndProc() would THEN call the Window's finalizer manually
(and tell the GC that the object is done being finalized, so it
can be collected).
I can't think of any "nice" way around this. Either the HWND
would have to be managed manually (in which case, that defeats
the purpose of using the GC to ensure its destruction along with
the object), or I would need an extra indirection in Window
(which REALLY overcomplicates the design, and introduces lots of
inheritance/template usage issues).
The thing is, I think this doesn't need any compiler support
either -- just a change in druntime. (I could be wrong though,
since it might involve modifying TypeInfo_Class, I'm not sure.)
Do you (or others) reckon a pull request to modify _d_newclass
and _d_delclass so that they would call a custom static
"constructor" and "destructor" for a class (if it specifies this
should be the case) might be accepted?
If there's the possibility then I might try hacking around with
it...
I can already see there being issues with inheritance, but I
think it would be fixable in some cases, and disallowable in
others. (Would obviously need to try it and see though.)
Re: Defining a custom *constructor* (not initializer!)
On 2012-05-07 09:28, Mehrdad wrote: Is this something that actually modifies the 'new' operator, or is it just a separate factory function that my code would need to switch to using? This does not modify the new-operator. "_d_newclass" is actually the runtime function that is called by the compiler when it sees "new" in the code. It would be a separate factory function. As far as I know it's not possible to _not_ call the constructor when using new. -- /Jacob Carlborg
Re: Defining a custom *constructor* (not initializer!)
On 2012-05-07 21:09, Mehrdad wrote: Oh, and ditto with the destructor: I need to be able to call the destructor manually, because the C does that inside a callback on my behalf. About the destructor, have a look at how "clear" is implemented, it's supposed to replace "delete". Don't remember where it's defined. -- /Jacob Carlborg
Re: Defining a custom *constructor* (not initializer!)
On 2012-05-07 11:18, David Nadlinger wrote: On Monday, 7 May 2012 at 07:28:18 UTC, Mehrdad wrote: Is this something that actually modifies the 'new' operator, or is it just a separate factory function that my code would need to switch to using? Doing it without a separate factory function (and maybe disabling new along with it by protecting the constructor) is not possible in D. However, I don't quite see what it would gain you in the first place – besides potentially screwing up the semantics users expect from new… David http://pastebin.com/UV5R82dg A bit of a hack. An other option would to use a separate public method that acts as a constructor. -- /Jacob Carlborg
Re: Defining a custom *constructor* (not initializer!)
On 2012-05-07 18:01, Mehrdad wrote: On Monday, 7 May 2012 at 09:18:11 UTC, David Nadlinger wrote: Doing it without a separate factory function (and maybe disabling new along with it by protecting the constructor) is not possible in D. Okay that answers my question then. No, have a look at this example: http://pastebin.com/UV5R82dg A bit of a hack. An other option would to use a separate public method that acts as a constructor. -- /Jacob Carlborg
Re: Why typedef's shouldn't have been removed :(
On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote: Seriously though, I get what you are saying. Fortunately, we have a very significant team working on phobos (I think more than a dozen people have commit rights), so the situation for "grr... phobos really should do *this*, but I can't get phobos changed" can be pretty readily resolved. Github and pull requests have made this incredibly easy. I've looked at some pull requests that were dead simple, verified it in a matter of minutes, and click one button to pull it. Even when I have no experience in the related modules. Brad Roberts (and I think Daniel Murphy?) have set up an awesome testing system that automatically verifies pull requests on all the supported platforms using the latest from git. See here: http://d.puremagic.com/test-results/pulls.ghtml The chances of your pull request being validated and pulled -- if it makes a good improvement to phobos -- are much much higher than they used to be. -Steve Whoa! that auto-tester is pretty sharp! I've actually been wondering about this. I recently ran into a bug in Phobos, quickly tacked that there was an issue for it, made an easy fix, submitted a pull request and commented on the bug. All tests in the above page are coming out green, so I guess I've got that going for it. https://github.com/D-Programming-Language/phobos/pull/557 Is there some additional communication channel I need to notify for someone to have a look at it and at least comment on any errors/mistakes? Or am I pretty much stuck to wait for whoever is in charge of that module to run into it?
Re: Properties don't behave like variables?
On Mon, 07 May 2012 15:35:35 -0400, Jacob Carlborg wrote:
On 2012-05-07 14:43, Steven Schveighoffer wrote:
It's like this in C#.
I can't decide whether I like it better in D or C#. Clearly the compiler
lowering of foo |= 2 to foo = foo | 2 would be benficial in terms of
less code to write.
But I also like having control over how properties can implement
operators. For example, the above is two function calls, but it may be
easier/more efficient written as one. The issue is, how do you do that?
The current definition syntax doesn't lend itself well to extension...
-Steve
If an operator is overloaded use that single function, otherwise do a
rewirte.
How do you overload the operator for a property? For example:
struct S
{
int x;
}
struct T
{
private int _x;
@property S s() { return S(_x);}
@property void s(S news) { _x = newS.x; }
}
How do I define T.s |= 5 ???
I realize we could define opBinary("|") on S, and depend on the rewrite,
but I'd rather do it in one operation.
-Steve
Re: Why typedef's shouldn't have been removed :(
On Monday, 7 May 2012 at 19:29:26 UTC, Steven Schveighoffer wrote: I think it was more that the whole concept was flawed -- typedef int myint never really did exactly what you wanted it to. For example: myint m = 1; // ok m += 5; // ok m = m + 5; // error? It's definitely an error, because 5 isn't myint. Of course, it wouldn't be an error in C code, but keeping source compatibility isn't a goal either. Wouldn't a global search-and-replace that replaced "typedef" with "alias" when porting C code have fixed 99% of this issue, practically speaking? Things got even worse when you weren't typedef'ing a basic type. It sounds so trivial to fix though (especially since it's not silent breakage)... Would you mind giving another (actual) example (perhaps with a custom type?) that came up, and which shows the extent of the problem and why it was difficult to solve without disallowing typedef entirely? I'm having a hard time seeing why the problem was so difficult (or tedious) to fix... a search/replace for typedef/alias would've fixed all (or almost) all the cases when porting C code, right? I think the advents in type construction in D2 have made typedef almost completely implementable as a library type, and we can do it the way it was intended! Don't forget, typedef was there when we had no "alias this" and no blanket operator overloading. Well, I'll have to try it and see -- I neither agree nor disagree. Right now I'm just trying to understand the problems it was causing, though. When all you want is an opaque type that just can't be implicitly cast from something else (such as HANDLE) typedef is a crude and inaccurate method to do that. I don't really agree with that (though an example as I asked for above^ could definitely make me agree) Maybe it wasn't you, let me check... http://forum.dlang.org/post/jnueti$1opd$1...@digitalmars.com OK, it was you, but under a different context, and I actually don't see you mentioning C there. Sorry for the confusion/accusation. I have a hard time keeping track of all these different threads in my head :( Haha no worries. :) Seriously though, I get what you are saying. [...] The chances of your pull request being validated and pulled -- if it makes a good improvement to phobos -- are much much higher than they used to be. Awesome, I'll probably try my hand at it (probably around next week). :)
Re: Defining a custom *constructor* (not initializer!)
On Mon, 07 May 2012 15:09:34 -0400, Mehrdad wrote: Oh, and ditto with the destructor: I need to be able to call the destructor manually, because the C does that inside a callback on my behalf. You definitely can do this. I think it's just __dtor. But I'm not sure if that calls the whole chain. rt_finalize, the function that actually calls the dtors calls each dtor in the chain individually. You can see how it works here: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/lifetime.d#L1161 However, if C is calling your dtor, I'd highly recommend *not* using GC memory for your class data, you can std.conv.emplace it in C-malloced memory. If it has any references to GC data, use GC.addRoot to make sure that data isn't accidentally collected, and use GC.removeRoot before destruction. -Steve
Re: GSOC Linker project
On 2012-05-07 17:41, Pierre LeMoine wrote: On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote: If you are interested in getting results rather than reinventing the wheel, I would advice you to have a look at the openwatcom.org wlink, and the forked jwlink as a starting point. The linker is open source, written in C and has user documentation (not source doc unfortunately). Roald Thanks for the tip! :) What level of reinventing the wheel are we talking about? Did you suggest i fork (j)wlink or somesuch, or that i take a look at how it's implemented instead of reinventing from scratch? :) And does anyone know if wlink is able to link programs from dmd? I made a half-hearted attempt myself, but didn't manage to get it to work ;p /Pierre Perhaps you could have a look at "gold" as well: http://en.wikipedia.org/wiki/Gold_%28linker%29 -- /Jacob Carlborg
Re: Defining a custom *constructor* (not initializer!)
On Mon, 07 May 2012 15:08:16 -0400, Mehrdad wrote:
On Monday, 7 May 2012 at 17:04:08 UTC, Steven Schveighoffer wrote:
Not really, but then again, if you are not placing the class into the
GC heap, who cares? You have to manually delete anyways, just use your
specialized 'delete' function instead of delete.
-Steve
No, I *am* placing it on the heap.
You hadn't made that clear.
In your first post, I was assuming your ptr came from some non-GC
allocated space, which is why you wanted the ability to intercept it.
I'm just asking if I can call the constructor manually, because
(like I wrote in my first post...) sometimes the C code you're
interoperating with takes control away from you, and just calls a
callback on your behalf when constructing the object.
I wasn't sure, but I just tried it out:
import std.stdio;
extern(C) void *_d_newclass(TypeInfo t); // this is defined in
rt/lifetime.d I cheated and used this, because I didn't want to have to
type everything that was in it :)
class C
{
int x;
this(int x){this.x = x;}
}
void main()
{
C c = cast(C)_d_newclass(typeid(C));
c.__ctor(1);
writeln(c.x); // outputs 1
}
Seems to work
-Steve
Re: Why not all statement are expressions ?
On 2012-05-07 19:06, deadalnix wrote: Hi, Working on D I noticed that some statement, notably assert, are expression of type void. Why not all statement (that are not expression already) are expression ? I would like that as well. -- /Jacob Carlborg
Re: GSOC Linker project
On 2012-05-07 20:13, H. S. Teoh wrote: On Mon, May 07, 2012 at 07:21:54PM +0200, Paulo Pinto wrote: Sometimes I wonder what do students learn in modern CS courses. [...] Way too much theory and almost no practical applications. At least, that was my experience when I was in college. It gets worse the more prestigious the college is, apparently. I'm glad I spent much of my free time working on my own projects, and doing _real_ coding, like actually use C/C++ outside of the trivial assignments they hand out in class. About 90% of what I do at my job is what I learned during those free-time projects. Only 10% or maybe even less is what I got from CS courses. So true, so true. I feel exactly the same. -- /Jacob Carlborg
Re: Properties don't behave like variables?
On 2012-05-07 14:43, Steven Schveighoffer wrote: It's like this in C#. I can't decide whether I like it better in D or C#. Clearly the compiler lowering of foo |= 2 to foo = foo | 2 would be benficial in terms of less code to write. But I also like having control over how properties can implement operators. For example, the above is two function calls, but it may be easier/more efficient written as one. The issue is, how do you do that? The current definition syntax doesn't lend itself well to extension... -Steve If an operator is overloaded use that single function, otherwise do a rewirte. -- /Jacob Carlborg
Re: Why typedef's shouldn't have been removed :(
On Mon, 07 May 2012 14:08:33 -0400, Mehrdad wrote: On Monday, 7 May 2012 at 17:17:55 UTC, Steven Schveighoffer wrote: Nothing in this whole thread seems to be very useful. I don't know how else to answer your post except -- sorry, we're not going to change it. Okay. Though you'd be a lot more convincing if you could give an example of how typedef was causing problems previously. I think it was more that the whole concept was flawed -- typedef int myint never really did exactly what you wanted it to. For example: myint m = 1; // ok m += 5; // ok m = m + 5; // error? Things got even worse when you weren't typedef'ing a basic type. I think the advents in type construction in D2 have made typedef almost completely implementable as a library type, and we can do it the way it was intended! Don't forget, typedef was there when we had no "alias this" and no blanket operator overloading. When all you want is an opaque type that just can't be implicitly cast from something else (such as HANDLE) typedef is a crude and inaccurate method to do that. It's hard to see where you are coming from. You have mentioned that doing Windows low-level programming is hard on most platforms except for C. Well, if C made it easy, why not duplicate what they did? I don't understand your response or where you got that idea, but I don't think my response would be very interesting even if I did... Maybe it wasn't you, let me check... http://forum.dlang.org/post/jnueti$1opd$1...@digitalmars.com OK, it was you, but under a different context, and I actually don't see you mentioning C there. Sorry for the confusion/accusation. I have a hard time keeping track of all these different threads in my head :( 2) Make your own types. You are free to not use standard/existing libraries. Yes, and I can write the rest of Phobos from scratch as well... If it's better than phobos, then maybe we can use it! Seriously though, I get what you are saying. Fortunately, we have a very significant team working on phobos (I think more than a dozen people have commit rights), so the situation for "grr... phobos really should do *this*, but I can't get phobos changed" can be pretty readily resolved. Github and pull requests have made this incredibly easy. I've looked at some pull requests that were dead simple, verified it in a matter of minutes, and click one button to pull it. Even when I have no experience in the related modules. Brad Roberts (and I think Daniel Murphy?) have set up an awesome testing system that automatically verifies pull requests on all the supported platforms using the latest from git. See here: http://d.puremagic.com/test-results/pulls.ghtml The chances of your pull request being validated and pulled -- if it makes a good improvement to phobos -- are much much higher than they used to be. -Steve
Re: "R" suffix for reals
On 5/7/2012 12:07 PM, Steven Schveighoffer wrote: However, I think these examples are misleading and do not prove the point. It shows IMO more that you are better off declaring the type on the left if your code depends on it always staying the same. i.e. this does not have that problem: real r = 1L; I tend to agree. If you're declaring things with 'auto', then you should not be relying on a specific type being inferred from the initializer - that would be poor style. Use of auto implies your code is more generic and adaptable to whatever type the initializer turns out to be. If your usage of r requires it to be a specific type, it should be declared as having that type.
Re: Defining a custom *constructor* (not initializer!)
Oh, and ditto with the destructor: I need to be able to call the destructor manually, because the C does that inside a callback on my behalf. On Monday, 7 May 2012 at 19:08:18 UTC, Mehrdad wrote: No, I *am* placing it on the heap. I'm just asking if I can call the constructor manually, because (like I wrote in my first post...) sometimes the C code you're interoperating with takes control away from you, and just calls a callback on your behalf when constructing the object. (Yes, I realize there are different solutions to this problem. They're just not as elegant.)
Re: Defining a custom *constructor* (not initializer!)
On Monday, 7 May 2012 at 17:04:08 UTC, Steven Schveighoffer wrote: Not really, but then again, if you are not placing the class into the GC heap, who cares? You have to manually delete anyways, just use your specialized 'delete' function instead of delete. -Steve No, I *am* placing it on the heap. I'm just asking if I can call the constructor manually, because (like I wrote in my first post...) sometimes the C code you're interoperating with takes control away from you, and just calls a callback on your behalf when constructing the object. (Yes, I realize there are different solutions to this problem. They're just not as elegant.)
Re: GSOC Linker project
On Mon, 07 May 2012 13:34:49 -0400, Andrew Wiley wrote: On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer wrote: I agree that's the case with the current object/linker model. Something that puts inferred properties into the object file needs a new model, one which does not blindly link code that wasn't compiled from the same sources. Then all you've done is to make attributes the author can't control part of the API, which will force library users to recompile their code more often for non-obvious reasons. Avoiding that is one of the points of shared libraries. Shared library entry points have to have *no* inference. Otherwise you could inadvertently change the public API without explicitly tagging it. I believe in D, shared library entry points have to be tagged with export. Not to mention, shared libraries on a certain platform usually have to be linked by the platform's linker. So we can't exactly overtake that aspect with a new model. I think we're actually talking about different contexts. I'm speaking in the context of shared libraries, where I think the API needs to be exactly what the author requests and nothing more. With object files, static libraries, and static linking, I agree that this sort of thing could work and wouldn't cause the same problems because it's impossible to swap the library code without recompiling/relinking the entire program. OK, that makes sense, I think you are right, we were talking about two different pieces of the model. -Steve
Re: "R" suffix for reals
On Mon, 07 May 2012 14:11:34 -0400, Arne wrote: On Monday, 7 May 2012 at 12:34:26 UTC, Steven Schveighoffer wrote: On Sun, 06 May 2012 21:02:28 -0400, bearophile wrote: Or maybe you initially have written: auto r = 1.1L; And later you want to change the number to 1.0 and you fix it like this: auto r = 1L; Now you have a little bug. Or maybe you have initially written: auto d = 1.1; and later you want to change the number to 1.0 and you fix it like this: auto d = 1; Now you have a little bug. To me the problem of floating pt. vs. integral is orthogonal to the size of the integral/floating point. -Steve Since you use the suffix to disambiguate / explicitly specify the type... it is extremely unintuitive if the type suddenly changes while *keeping* the same suffix... I concede that is a concern, but really, ".[0-9]" is the suffix that determines it's a floating point, not "L". I almost think 1f should be an error, it should have to be 1.0f. Ohhh, I thought of another example: auto x = 0x1f; Remove the 0x prefix, and you have: auto x = 1f; // now a floating point 1 vs. integer 31 However, I think these examples are misleading and do not prove the point. It shows IMO more that you are better off declaring the type on the left if your code depends on it always staying the same. i.e. this does not have that problem: real r = 1L; -Steve
Re: "R" suffix for reals
On Monday, 7 May 2012 at 12:34:26 UTC, Steven Schveighoffer wrote: On Sun, 06 May 2012 21:02:28 -0400, bearophile wrote: Or maybe you initially have written: auto r = 1.1L; And later you want to change the number to 1.0 and you fix it like this: auto r = 1L; Now you have a little bug. Or maybe you have initially written: auto d = 1.1; and later you want to change the number to 1.0 and you fix it like this: auto d = 1; Now you have a little bug. To me the problem of floating pt. vs. integral is orthogonal to the size of the integral/floating point. -Steve Since you use the suffix to disambiguate / explicitly specify the type... it is extremely unintuitive if the type suddenly changes while *keeping* the same suffix...
Re: GSOC Linker project
On Mon, May 07, 2012 at 07:21:54PM +0200, Paulo Pinto wrote: [...] > I have spent a huge time in the university learning about compiler > development, reading old books and papers from the early computing > days. > > So in a general way, and not directed to you now, I saddens me that a > great part of that knowledge is lost to most youth nowadays. > > Developers get amazed with JavaScript JIT compilation, and yet it > already existed in Smalltalk systems. > > Go advertises fast compilation speeds, and they were already available > to some language systems in the late 70's, early 80's. > > We are discussing storing module interfaces directly in the library > files, and most seem to never heard of it. > > And the list goes on. > > Sometimes I wonder what do students learn in modern CS courses. [...] Way too much theory and almost no practical applications. At least, that was my experience when I was in college. It gets worse the more prestigious the college is, apparently. I'm glad I spent much of my free time working on my own projects, and doing _real_ coding, like actually use C/C++ outside of the trivial assignments they hand out in class. About 90% of what I do at my job is what I learned during those free-time projects. Only 10% or maybe even less is what I got from CS courses. T -- The two rules of success: 1. Don't tell everything you know. -- YHL
Re: Why typedef's shouldn't have been removed :(
On Monday, 7 May 2012 at 17:17:55 UTC, Steven Schveighoffer wrote: Nothing in this whole thread seems to be very useful. I don't know how else to answer your post except -- sorry, we're not going to change it. Okay. Though you'd be a lot more convincing if you could give an example of how typedef was causing problems previously. I've asked that question several times, but no one's ever given me an actual *example* or two of the problems. If I saw one then obviously I'd understand why it was removed... It's hard to see where you are coming from. You have mentioned that doing Windows low-level programming is hard on most platforms except for C. Well, if C made it easy, why not duplicate what they did? I don't understand your response or where you got that idea, but I don't think my response would be very interesting even if I did... 1) pull request. I'm sure a pull request that makes more correct semantic decisions on implicit casting of HANDLEs would be accepted. I'm busy right now but perhaps next week -- I'll try and see. (Haven't done one before so I may or may not succeed..) 2) Make your own types. You are free to not use standard/existing libraries. Yes, and I can write the rest of Phobos from scratch as well... Given that you want to write an *entire toolkit*, I doubt anyone gives a shit whether your low-level code works with standard phobos-defined HANDLE types. I don't either, so you're definitely right about that. Especially because I really doubt my library's gonna turn out very useful anyway, even if all this was perfect. I meant fixing the library solution so it *does* work how you want. In other words, "bringing back typedefs" isn't going to happen. It's not a solution that is practical, or likely. Yup, I'd love to know what the problems were though. (See the first part of the post.) But making std.typecons.TypeDef work *is* a valid path to get what you want (typedefs that work like they used to). If that isn't possible, let's fix the language constructs that are blocking it! Okay, at least the road is clear now. No I mean it's completely false that fixing HWND means we have to fix size_t. size_t is not broken in any way, HWND is, and I agree we need a solution that works. Lol, ok, another case of miscommunication then.
Re: GSOC Linker project
On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer wrote: > On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley > wrote: > > On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer > >wrote: >> >>> On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen < >>> >>> That's exactly what storing the interface in the object file does. You >>> don't need the source because the object file contains the compiler's >>> interpretation of the source, and any inferred properties it has >>> discovered. >>> >>> >> Putting inferred purity into an object file sounds like a bad idea. It's >> not hard to imagine this scenario: >> -function foo in libSomething is inferred as pure (but not declared pure >> by >> the author) >> -exeSomethingElse is compiled to use libSomething, and the compiler takes >> advantage of purity optimizations when calling foo >> -libSomething is recompiled and foo is no longer pure, and >> exeSomethingElse >> silently breaks >> > > no, it just doesn't link. > > > Purity inference is fine for templates (because recompiling the library >> won't change the generated template code in an executable that depends on >> it), but in all other cases, the API needs to be exactly what the author >> declared it to be, or strange things will happen. >> > > I agree that's the case with the current object/linker model. Something > that puts inferred properties into the object file needs a new model, one > which does not blindly link code that wasn't compiled from the same sources. > Then all you've done is to make attributes the author can't control part of the API, which will force library users to recompile their code more often for non-obvious reasons. Avoiding that is one of the points of shared libraries. I think we're actually talking about different contexts. I'm speaking in the context of shared libraries, where I think the API needs to be exactly what the author requests and nothing more. With object files, static libraries, and static linking, I agree that this sort of thing could work and wouldn't cause the same problems because it's impossible to swap the library code without recompiling/relinking the entire program.
Re: GSOC Linker project
Am 07.05.2012 15:30, schrieb Steven Schveighoffer: On Mon, 07 May 2012 09:22:05 -0400, Paulo Pinto wrote: This just confirms what I saw yesterday on a presentation. Many developers re-invent the wheel, or jump to the fad technology of the year, because they don't have the knowledge of old already proven technologies, that for whatever reason, are no longer common. We need better ways to preserve knowledge in our industry. Again, don't take offense. I never suggested Java's use of an already existing technology was in some way a "new" thing, just that it proves it can work. I'm sure back in the day, TurboPascal had to walk uphill through the snow to school both ways too. :) -Steve No offense taken. My reply was just a small rant, based on your answer on lack of contact with Turbo Pascal and other languages I mentioned. Yesterday I watched a presentation, where the guy complains on knowledge being lost due to the lack of proper mentors in the industry, http://www.infoq.com/presentations/The-Frustrated-Architect I have spent a huge time in the university learning about compiler development, reading old books and papers from the early computing days. So in a general way, and not directed to you now, I saddens me that a great part of that knowledge is lost to most youth nowadays. Developers get amazed with JavaScript JIT compilation, and yet it already existed in Smalltalk systems. Go advertises fast compilation speeds, and they were already available to some language systems in the late 70's, early 80's. We are discussing storing module interfaces directly in the library files, and most seem to never heard of it. And the list goes on. Sometimes I wonder what do students learn in modern CS courses. -- Paulo
Re: GSOC Linker project
On Mon, 07 May 2012 12:59:24 -0400, Andrew Wiley wrote: On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer wrote: On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen < That's exactly what storing the interface in the object file does. You don't need the source because the object file contains the compiler's interpretation of the source, and any inferred properties it has discovered. Putting inferred purity into an object file sounds like a bad idea. It's not hard to imagine this scenario: -function foo in libSomething is inferred as pure (but not declared pure by the author) -exeSomethingElse is compiled to use libSomething, and the compiler takes advantage of purity optimizations when calling foo -libSomething is recompiled and foo is no longer pure, and exeSomethingElse silently breaks no, it just doesn't link. Purity inference is fine for templates (because recompiling the library won't change the generated template code in an executable that depends on it), but in all other cases, the API needs to be exactly what the author declared it to be, or strange things will happen. I agree that's the case with the current object/linker model. Something that puts inferred properties into the object file needs a new model, one which does not blindly link code that wasn't compiled from the same sources. -Steve
Re: Why typedef's shouldn't have been removed :(
On Mon, 07 May 2012 12:10:20 -0400, Mehrdad wrote: On Monday, 7 May 2012 at 12:18:36 UTC, Steven Schveighoffer wrote: No, they are the same function. size_t is aliased to uint. What *you* want size_t to mean is not what it is, it's an alias to the word-sized unsigned integer on a platform. Get used to it, use another type if you don't want it to be that. No kidding! I use a different language altogether when I don't like D. That doesn't tell me anything useful though... Nothing in this whole thread seems to be very useful. I don't know how else to answer your post except -- sorry, we're not going to change it. It's the same in C/C++ BTW. D's alias === C's typedef, and C's size_t is a typedef. Did you read my own response to someone else? You're telling me something I already mentioned myself... My response: "C++ doesn't even _have_ reflection, and it treats typedefs pretty much the same as D does right now..." It's hard to see where you are coming from. You have mentioned that doing Windows low-level programming is hard on most platforms except for C. Well, if C made it easy, why not duplicate what they did? (2) I'm saying function(void*) and function(HANDLE) are different functions, and people are telling me to use TypeDef. Which is of course an alternative, except that it requires me to modify the source code of my library. Wait, you have to modify one type definition, right? Is that really not satisfactory? I don't understand this line of reasoning. No, it's not satisfactory, because I'm not always in control of the type definition. 1) pull request. I'm sure a pull request that makes more correct semantic decisions on implicit casting of HANDLEs would be accepted. 2) Make your own types. You are free to not use standard/existing libraries. Given that you want to write an *entire toolkit*, I doubt anyone gives a shit whether your low-level code works with standard phobos-defined HANDLE types. I can't say I ever used typedef when it was allowed. That doesn't make it useless. :P This was not my reason for saying it. I was qualifying what I was about to say by saying "I don't have a lot of experience with typedefs". I can see how it can be useful in certain situations, but I think the path is available to make an equivalent library solution work (it seems several people have said it doesn't, why not spend time trying to fix it rather than complaining about features that aren't coming back?) Um... if people don't agree that size_t should be a different type, why would I spend time 'fixing' something that won't be used anyway? I meant fixing the library solution so it *does* work how you want. In other words, "bringing back typedefs" isn't going to happen. It's not a solution that is practical, or likely. But making std.typecons.TypeDef work *is* a valid path to get what you want (typedefs that work like they used to). If that isn't possible, let's fix the language constructs that are blocking it! (I'm pretty sure none of the people who suggested using TypeDef for HWND realized that we'd have to do the same thing for size_t and such. Otherwise, when I'd have asked about that, the response wouldn't have been "who cares".) I think they didn't realize it because it's completely false ;) You saying it's not false doesn't make it any more true. It might have been false, but if so, that falsehood definitely wasn't communicated. So from my perspective, it's true. (I don't have ESP to figure out what people *really* think of, sorry... and no pun intended :P) No I mean it's completely false that fixing HWND means we have to fix size_t. size_t is not broken in any way, HWND is, and I agree we need a solution that works. -Steve
Re: Defining a custom *constructor* (not initializer!)
On Mon, 07 May 2012 11:57:22 -0400, Mehrdad wrote: On Monday, 7 May 2012 at 10:15:56 UTC, Era Scarecrow wrote: What is your objective? What are you trying to achieve? Did you read my first post? I already explained what this would be used for. Sure, you can do it with factories, but you can't factory-ize "delete", can you? Not really, but then again, if you are not placing the class into the GC heap, who cares? You have to manually delete anyways, just use your specialized 'delete' function instead of delete. -Steve
Re: GSOC Linker project
On Mon, May 7, 2012 at 8:42 AM, Steven Schveighoffer wrote: > On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen < > xtzgzo...@gmail.com> wrote: > > On 07-05-2012 14:50, Steven Schveighoffer wrote: >> >>> On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen >>> wrote: >>> >>> On 07-05-2012 13:21, Steven Schveighoffer wrote: > On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen > wrote: > > Purity inference won't happen either way. Purity is part of your API >> and also meant to help you reason about your code. If the compiler >> just infers purity in a function and you later change the >> implementation so it's no longer pure, you break your users' code. >> Also, purity would no longer help you reason about your code if it's >> not explicit. >> > > It can be pure for the purposes of optimization without affecting code > whatsoever. Inferred purity can be marked separately from explicit > purity, and explicitly pure functions would not be allowed to call > implicitly pure functions. > > -Steve > But that kind of inferred purity is something a compiler back end cares about, not something the language should have to care about at all. In practice, most compilers *do* analyze all functions for possible side-effects and use that information where applicable. >>> >>> It affects how callers code will be generated. >>> >>> If I have a function >>> >>> int foo(int x); >>> >>> and I have another function which calls foo like: >>> >>> int y = foo(x) + foo(x); >>> >>> Then the optimization is applied to whatever function this exists in. If >>> the source isn't available for foo, the compiler cannot make this >>> optimization. >>> >>> I have no idea if this is a back-end or front-end issue. I'm not a >>> compiler writer. But I do understand that the compiler needs extra >>> information in the signature to determine if it can make this >>> optimization. >>> >>> >> OK, point taken; didn't consider that. But in the first place, for >> inference of purity to work, the source would have to be available. Then, >> that inferred property has to be propagated somehow so that the compiler >> can make use of it when linking to the code as a library... >> > > That's exactly what storing the interface in the object file does. You > don't need the source because the object file contains the compiler's > interpretation of the source, and any inferred properties it has discovered. > Putting inferred purity into an object file sounds like a bad idea. It's not hard to imagine this scenario: -function foo in libSomething is inferred as pure (but not declared pure by the author) -exeSomethingElse is compiled to use libSomething, and the compiler takes advantage of purity optimizations when calling foo -libSomething is recompiled and foo is no longer pure, and exeSomethingElse silently breaks Purity inference is fine for templates (because recompiling the library won't change the generated template code in an executable that depends on it), but in all other cases, the API needs to be exactly what the author declared it to be, or strange things will happen.
UFCS and operator overloading
Hi,
from my understanding UFCS is supposed to work with operator overloading. I.e.
in the following a + b should work
struct Foo {}
Foo opBinary(string op)(Foo lhs, Foo rhs) if (op == "+")
{
return Foo.init;
}
unittest
{
Foo a, b;
a + b; // fails to compile
}
Is UFCS supposed to work with operator overloading, isn't it?
Jens
Why not all statement are expressions ?
Hi, Working on D I noticed that some statement, notably assert, are expression of type void. Why not all statement (that are not expression already) are expression ?
Re: run-time stack-based allocation
That won't do. This is way too ugly, considering, that it needs to be
heavily used in user code. I'm thinking an inline ASM solution, but
can't figure out when to deallocate.
On Mon, May 7, 2012 at 8:52 PM, Arne wrote:
> On Monday, 7 May 2012 at 16:03:15 UTC, Mehrdad wrote:
>>
>> On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:
>>>
>>> Basically I want what alloca does, but instead of considering the
>>> constructor's scope, I want it to hand to the constructor call's enclosing
>>> scope.
>>
>>
>> I think you'd need to modify the compiler for this, since alloca is
>> 'magical'.
>
>
> wouldn't mixin's be a solution, one can inject an alloca to the current
> scope, and then call the constructor...
>
> import std.stdio;
> import std.c.stdlib;
> import std.random;
>
> mixin template Init(alias var, alias size)
> {
> void* buf = alloca(size);
>
> bool foo_init()
> {
> var = (cast(typeof(var))buf);
>
> var[0]=0;
> var[1]=1;
> var[2]=2;
>
> return true;
> }
>
> auto foo_dummy_statement = foo_init();
> }
>
> void main()
> {
> int my_size = uniform(12, 24);
> int* my_var = void; mixin Init!(my_var, my_size);
>
> writeln(my_var[0..3]);
> }
--
Bye,
Gor Gyolchanyan.
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 16:03:15 UTC, Mehrdad wrote:
On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote:
Basically I want what alloca does, but instead of considering
the constructor's scope, I want it to hand to the constructor
call's enclosing scope.
I think you'd need to modify the compiler for this, since
alloca is 'magical'.
wouldn't mixin's be a solution, one can inject an alloca to the
current scope, and then call the constructor...
import std.stdio;
import std.c.stdlib;
import std.random;
mixin template Init(alias var, alias size)
{
void* buf = alloca(size);
bool foo_init()
{
var = (cast(typeof(var))buf);
var[0]=0;
var[1]=1;
var[2]=2;
return true;
}
auto foo_dummy_statement = foo_init();
}
void main()
{
int my_size = uniform(12, 24);
int* my_var = void; mixin Init!(my_var, my_size);
writeln(my_var[0..3]);
}
Re: Growing pains
On 5/7/12 10:25 PM, Robert Clipsham wrote: On 03/05/2012 15:50, Andrei Alexandrescu wrote: Just letting you all know we're working on the frustrating and increasingly frequent "Load at xx.xx, try again later" errors when reading this forum through NNTP. They are caused by a significant growth spurt in newsgroup readership that occurred in recent times. We are working with our provider to fix these issues. Thanks, Andrei I've gotta say... These have been a lot more frequent for me since you posted this message! For me it stopped shortly after this message, but then it started happening one or two days ago.
Re: run-time stack-based allocation
No idea, sorry. :\ On Monday, 7 May 2012 at 16:08:42 UTC, Gor Gyolchanyan wrote: Wasn't there an allocator mechanism under development for phobos? I remember there was a StackAllocator, that can span for arbitrary scopes. What's up with that? On Mon, May 7, 2012 at 8:03 PM, Mehrdad wrote: On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote: Basically I want what alloca does, but instead of considering the constructor's scope, I want it to hand to the constructor call's enclosing scope. I think you'd need to modify the compiler for this, since alloca is 'magical'.
Re: Why typedef's shouldn't have been removed :(
On Monday, 7 May 2012 at 12:18:36 UTC, Steven Schveighoffer wrote: No, they are the same function. size_t is aliased to uint. What *you* want size_t to mean is not what it is, it's an alias to the word-sized unsigned integer on a platform. Get used to it, use another type if you don't want it to be that. No kidding! I use a different language altogether when I don't like D. That doesn't tell me anything useful though... It's the same in C/C++ BTW. D's alias === C's typedef, and C's size_t is a typedef. Did you read my own response to someone else? You're telling me something I already mentioned myself... My response: "C++ doesn't even _have_ reflection, and it treats typedefs pretty much the same as D does right now..." (2) I'm saying function(void*) and function(HANDLE) are different functions, and people are telling me to use TypeDef. Which is of course an alternative, except that it requires me to modify the source code of my library. Wait, you have to modify one type definition, right? Is that really not satisfactory? I don't understand this line of reasoning. No, it's not satisfactory, because I'm not always in control of the type definition. I can't say I ever used typedef when it was allowed. That doesn't make it useless. :P I can see how it can be useful in certain situations, but I think the path is available to make an equivalent library solution work (it seems several people have said it doesn't, why not spend time trying to fix it rather than complaining about features that aren't coming back?) Um... if people don't agree that size_t should be a different type, why would I spend time 'fixing' something that won't be used anyway? (I'm pretty sure none of the people who suggested using TypeDef for HWND realized that we'd have to do the same thing for size_t and such. Otherwise, when I'd have asked about that, the response wouldn't have been "who cares".) I think they didn't realize it because it's completely false ;) You saying it's not false doesn't make it any more true. It might have been false, but if so, that falsehood definitely wasn't communicated. So from my perspective, it's true. (I don't have ESP to figure out what people *really* think of, sorry... and no pun intended :P)
Re: run-time stack-based allocation
Wasn't there an allocator mechanism under development for phobos? I remember there was a StackAllocator, that can span for arbitrary scopes. What's up with that? On Mon, May 7, 2012 at 8:03 PM, Mehrdad wrote: > On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote: >> >> Basically I want what alloca does, but instead of considering the >> constructor's scope, I want it to hand to the constructor call's enclosing >> scope. > > > I think you'd need to modify the compiler for this, since alloca is > 'magical'. -- Bye, Gor Gyolchanyan.
Re: run-time stack-based allocation
I'd decrease ESP to allocate my space, but the problem arises when I try to determine when should I increase it back where it was. Any suggestions on how to do this using asm? On Mon, May 7, 2012 at 8:03 PM, Mehrdad wrote: > On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote: >> >> Basically I want what alloca does, but instead of considering the >> constructor's scope, I want it to hand to the constructor call's enclosing >> scope. > > > I think you'd need to modify the compiler for this, since alloca is > 'magical'. -- Bye, Gor Gyolchanyan.
Re: run-time stack-based allocation
On Monday, 7 May 2012 at 13:36:02 UTC, Gor Gyolchanyan wrote: Basically I want what alloca does, but instead of considering the constructor's scope, I want it to hand to the constructor call's enclosing scope. I think you'd need to modify the compiler for this, since alloca is 'magical'.
Re: Defining a custom *constructor* (not initializer!)
On Monday, 7 May 2012 at 09:18:11 UTC, David Nadlinger wrote: Doing it without a separate factory function (and maybe disabling new along with it by protecting the constructor) is not possible in D. Okay that answers my question then. However, I don't quite see what it would gain you in the first place – besides potentially screwing up the semantics users expect from new… It's a similar thing as when you override new's memory allocation part... yes, it can screw up the semantics, but it's assumed you know what you're doing...
Re: Defining a custom *constructor* (not initializer!)
On Monday, 7 May 2012 at 10:15:56 UTC, Era Scarecrow wrote: What is your objective? What are you trying to achieve? Did you read my first post? I already explained what this would be used for. Sure, you can do it with factories, but you can't factory-ize "delete", can you?
Re: GSOC Linker project
On Monday, 7 May 2012 at 12:36:18 UTC, Roald Ribe wrote: If you are interested in getting results rather than reinventing the wheel, I would advice you to have a look at the openwatcom.org wlink, and the forked jwlink as a starting point. The linker is open source, written in C and has user documentation (not source doc unfortunately). Roald Thanks for the tip! :) What level of reinventing the wheel are we talking about? Did you suggest i fork (j)wlink or somesuch, or that i take a look at how it's implemented instead of reinventing from scratch? :) And does anyone know if wlink is able to link programs from dmd? I made a half-hearted attempt myself, but didn't manage to get it to work ;p /Pierre
Re: Growing pains
On 03/05/2012 15:50, Andrei Alexandrescu wrote: Just letting you all know we're working on the frustrating and increasingly frequent "Load at xx.xx, try again later" errors when reading this forum through NNTP. They are caused by a significant growth spurt in newsgroup readership that occurred in recent times. We are working with our provider to fix these issues. Thanks, Andrei I've gotta say... These have been a lot more frequent for me since you posted this message! -- Robert http://octarineparrot.com/
Re: [Feature Request] Adding to D lang "set" built-in
On Sun, 2012-05-06 at 23:23 -0700, Jonathan M Davis wrote: > There are multiple ways to implement a set or a map. If a programmer knows > their data structures (as one would hope that they would), then they know the > difference between a hash set and a tree set (or hash map and tree map), and > they'll pick the one that's most appropriate for what they're doing. And > because the containers are very similar, it should be quite possible in many > cases to replace one with the other quite easily - especially if you're using > templates. That's one of the reasons that Java has the Set interface with > HashSet and TreeSet implenting it. Indeed. And it is clear that Java's (and C++, but to a lesser extent) obsession with coding only to interfaces with no concern for the properties of the realization underneath can rapidly lead to appalling performance of programs. Classic example is sorting and the List interface -- though the switch to Mergesort and modified Timsort with hidden reflection did ameliorate most of the problems for Java 7. > std.container is designed with the idea that containers will be named after > their data structures and _not_ what they're used for. Programmers can then > select the data structure that best serves their purposes. And I'd be worried > about any professional programmer who didn't know that you can use a > red-black > tree as a set or a map. Works for me, but... Having done more training of middle of the road programmers recently, I am appalled at how poor the average programmer turns out to be. In particular, their knowledge of data structures is at a level where, were I still in academia, they would fail and be ejected from the computer science programme. The level seems to be: array map == associative array == hash table list == sequence == singly-linked list anything else is SEP. Sadly very much a "I just know enough to not get sacked and pick up my pay packet" attitude. Mention red-black tree, 2-3 tree, trie, b-tree, and they glaze over. My earlier comments we flavoured by the need for a language to have an API that can cope with these folks as well as the folks who, like everyone on lists such as this one, appreciate that there is always much more to data structures than you think at first sight. Big-O, omega, theta, etc. analysis is important and interesting but somehow there needs to be a layer that gets away from this to provide a default, not poor, implementation. If I go in, I shall just rant. Hopefully I have now made the point in this email that I should have made in the earlier email > It's clearly a hash map. If they want a tree map, then we have RedBlackTree > (though we should probably provide a wrapper that makes it easier to use > RedBlackTree as a map, since it's a bit unwieldy to do that at the moment). I > don't see the problem. I think it would be good for there to be façades to the implementing data structure to provide a functional indication. Perhaps the observation is that where a data structure type such as map or set is realized in the core language there is a single implementation. Where things are library based then you get the naming to show function and realization. The Python experience is that more programmers do more reasonable work with list, tuple, map, set all having a single realization. Where more care is needed then there are well crafted libraries to work with, not least of which is NumPy. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: GSOC Linker project
On Mon, 07 May 2012 09:27:32 -0400, Alex Rønne Petersen wrote: On 07-05-2012 14:50, Steven Schveighoffer wrote: On Mon, 07 May 2012 07:41:43 -0400, Alex Rønne Petersen wrote: On 07-05-2012 13:21, Steven Schveighoffer wrote: On Fri, 04 May 2012 20:30:05 -0400, Alex Rønne Petersen wrote: Purity inference won't happen either way. Purity is part of your API and also meant to help you reason about your code. If the compiler just infers purity in a function and you later change the implementation so it's no longer pure, you break your users' code. Also, purity would no longer help you reason about your code if it's not explicit. It can be pure for the purposes of optimization without affecting code whatsoever. Inferred purity can be marked separately from explicit purity, and explicitly pure functions would not be allowed to call implicitly pure functions. -Steve But that kind of inferred purity is something a compiler back end cares about, not something the language should have to care about at all. In practice, most compilers *do* analyze all functions for possible side-effects and use that information where applicable. It affects how callers code will be generated. If I have a function int foo(int x); and I have another function which calls foo like: int y = foo(x) + foo(x); Then the optimization is applied to whatever function this exists in. If the source isn't available for foo, the compiler cannot make this optimization. I have no idea if this is a back-end or front-end issue. I'm not a compiler writer. But I do understand that the compiler needs extra information in the signature to determine if it can make this optimization. OK, point taken; didn't consider that. But in the first place, for inference of purity to work, the source would have to be available. Then, that inferred property has to be propagated somehow so that the compiler can make use of it when linking to the code as a library... That's exactly what storing the interface in the object file does. You don't need the source because the object file contains the compiler's interpretation of the source, and any inferred properties it has discovered. -Steve
