On Monday, 15 September 2014 at 16:28:19 UTC, amparacha wrote:
Can anyone looks at the following code to fix it.I am having
error when using pointers to functions with argument of type
T.This is a small portion of a program doing a generic quick
sort by passing a comparison function as an argum
On Wednesday, 27 August 2014 at 20:28:11 UTC, Phil Lavoie wrote:
On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie
wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the
On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon that
On Wednesday, 27 August 2014 at 19:56:29 UTC, Brian Schott wrote:
On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie wrote:
Ok so me and one of my colleagues have been working on some
code at a distance. We both use dmd as the compiler. I am
under Windows, she OSX.
It is not uncommon
Ok so me and one of my colleagues have been working on some code
at a distance. We both use dmd as the compiler. I am under
Windows, she OSX.
It is not uncommon that she experiences more strictness in the
type system than I do. For example, something like this does
compile for me, but not for
Nice talk!
Loved the joke about the factory/factory of factory of
metafactory at around 49 minutes hahaha. Reminded me of my Java
programming years.
On Wednesday, 4 June 2014 at 00:47:02 UTC, Vic wrote:
http://channel9.msdn.com/Blogs/Charles/Conversation-with-Andrei-Alexandrescu-All-things-
On Friday, 16 May 2014 at 23:14:13 UTC, Idan Arye wrote:
On Friday, 16 May 2014 at 20:31:40 UTC, Phil Lavoie wrote:
The idea is to eventually be able to do something like this:
constraint InputRange(Elt) {
Elt front();
void popFront();
bool empty();
}
void myTemplateFunction( InputRange
Hi, I'd like to share an idea I had. It was motivated by the
feeling I get when writing template functions and templates
altogether. The current template constraint mechanism is awesome
cuz it gives power and flexibility. However, I think it could be
improved, readibilty wise. Here is my sugges
On Monday, 25 March 2013 at 17:55:22 UTC, bearophile wrote:
Phil Lavoie:
I was not aware arr.length tolerated null slices. Does it
keeps its behavior in unsafe or system mode?
That behaviour is always kept. Because the underlying data
structure doesn't change.
Bye,
bearophile
Go
On Monday, 25 March 2013 at 17:44:42 UTC, Jonathan M Davis wrote:
On Monday, March 25, 2013 18:34:23 Phil Lavoie wrote:
On Monday, 25 March 2013 at 17:25:13 UTC, Timon Gehr wrote:
> On 03/25/2013 06:13 PM, Phil Lavoie wrote:
>> ...
>>
>> However, testing for
On Monday, 25 March 2013 at 17:40:27 UTC, H. S. Teoh wrote:
On Mon, Mar 25, 2013 at 06:34:23PM +0100, Phil Lavoie wrote:
[...]
Still comparing against null, since it has a different meaning,
maybe null means not found and empty means found but without
value.
If you want to make this
On Monday, 25 March 2013 at 17:25:13 UTC, Timon Gehr wrote:
On 03/25/2013 06:13 PM, Phil Lavoie wrote:
...
However, testing for null is kinda useful :)
...
It is currently basically useless for array slices, because
relying on it is brittle.
Well, since they CAN be null, it is at least
On Monday, 25 March 2013 at 17:14:47 UTC, H. S. Teoh wrote:
On Mon, Mar 25, 2013 at 08:46:42PM +0400, Dmitry Olshansky
wrote:
25-Mar-2013 20:43, Phil Lavoie пишет:
>I do believe that, in any case, this form is best:
>if( arr !is null && !arr.empty )
>
Now write that one t
However, testing for null is kinda useful :)
Scratch that, I thought you were implying something else :)
On Monday, 25 March 2013 at 17:05:31 UTC, bearophile wrote:
Phil Lavoie:
You think it should check for length to be more programmer
friendly,
My proposal is to turn "if(dyn_arr)" into a syntax error.
Bye,
bearophile
Yeah, but I also read you were in favor of changing its beha
On Monday, 25 March 2013 at 16:46:46 UTC, Dmitry Olshansky wrote:
25-Mar-2013 20:43, Phil Lavoie пишет:
I do believe that, in any case, this form is best:
if( arr !is null && !arr.empty )
Now write that one thousand times and count the typos.
Peace,
Phil
A thousand? !arr.empty in
On Monday, 25 March 2013 at 16:14:18 UTC, bearophile wrote:
Phil Lavoie:
IMHO, somebody coming from a C/C++ background (like me) has no
problem realizing that if( var ) means either if not null or
if not 0.
Some D programmers come from other languages, where if(arr)
means if its len is
On Sunday, 24 March 2013 at 22:10:06 UTC, bearophile wrote:
A recent discussion in D.learn reminds me of an enhancement
request of mine that is sleeping in Bugzilla since years:
http://d.puremagic.com/issues/show_bug.cgi?id=4733
The probles is that in D dynamic arrays can be non-null even
wh
On Tuesday, 29 January 2013 at 19:04:04 UTC, Phil Lavoie wrote:
In case you had not seen in the other thread:
On Sunday, 27 January 2013 at 14:06:00 UTC, rsk82 wrote:
Ok, nevermind, found, it, it was so easy that it simply didn't
have to had an example:
struct WNDCLASSEXW {
In case you had not seen in the other thread:
On Sunday, 27 January 2013 at 14:06:00 UTC, rsk82 wrote:
Ok, nevermind, found, it, it was so easy that it simply didn't
have to had an example:
struct WNDCLASSEXW {
UINT cbSize;
UINT style;
WNDPROC lpfnWndProc;
Just to clarify:
xxxA = Ascii;
xxxW = Wide chars (UCS-2);
And because I forgot to mention, to mimic the preprocessor
directive, the bindings use a version conditional compilation.
Therefore, you use it like that:
rdmd -I/where/you/put/the/bindings -version=Unicode yourmodule.d
You can double
On Sunday, 27 January 2013 at 14:06:00 UTC, rsk82 wrote:
Ok, nevermind, found, it, it was so easy that it simply didn't
have to had an example:
struct WNDCLASSEXW {
UINT cbSize;
UINT style;
WNDPROC lpfnWndProc;
int cbClsExtra;
int cbWndE
On Sunday, 20 January 2013 at 09:52:42 UTC, SaltySugar wrote:
Why it isn't popular? We must popularize it. There aren't any
tutorials with D, books and other stuff. How about writing a D
programming forum?
I think it is on its way there though. There is the excellent
book that Andrei wrote w
On Tuesday, 15 January 2013 at 19:11:43 UTC, Phil Lavoie wrote:
It'd be nicer if we could use an operator, but this is wishful
thinking:
auto r = r2.jumpTo( d2 ); //r2d2, yes.
Equivalent to:
auto r = r2[ d2 .. $ ];
Or:
auto r = r2[ d2 ... ];
Again, wishful thinking.
What about st
It'd be nicer if we could use an operator, but this is wishful
thinking:
auto r = r2.jumpTo( d2 ); //r2d2, yes.
Equivalent to:
auto r = r2[ d2 .. $ ];
Or:
auto r = r2[ d2 ... ];
Again, wishful thinking.
Continuing with reversible ranges:
struct ForwardRange {
_start;
_end;
BackwardRange reverse() { return BackwardRange( _end, _start ); }
}
struct BackwardRange {
_start;
_end;
//guess what reverse is.
}
That would give the power to mimick bidirectional ranges (see
post on popBack befor
And, if ever needed, popBack could become this:
void popBack( R )( ref R r ) if( isReversibleRange!R ) {
auto reversed = r.reverse.popFront();
r = reversed.reverse;
}
bool empty() { return _start is null || _end is null; } //The
This would have to be corrected.
I agree that there are too many primitives.
On Tuesday, 15 January 2013 at 18:19:48 UTC, H. S. Teoh wrote:
On Tue, Jan 15, 2013 at 06:03:06PM +0100, Phil Lavoie wrote:
[...]
An addition to this solution could be another new primitive:
reverse:
Pseudo:
original = range.save
reversed = range.reverse //Permanently invert start an end
Ok, so to sum it up:
rfind should return the same type as provided.
Its direction (popFront()) should be the same.
auto rfing( Range, E )( Range r, E e ) if (blablabla) {
auto original = r.save; //This is to remember the end of the
orginal range.
r.reverse; //Reverse it. The range keeps tra
return original.reversed ? res : res.reverse;
And correcting again, invert both to:
return original.reversed? res.reverse: res;
On Tuesday, 15 January 2013 at 17:14:32 UTC, Andrei Alexandrescu
wrote:
On 1/15/13 12:03 PM, Phil Lavoie wrote:
Pseudo:
original = range.save
resPos = range.retro.find
return Range.merge( resPos, original ) //DOES NOT WORK
The problem with this solution is that:
Retro returns a different range
The order of the range returned is the same as the one received.
Not true. It should default to the genuine bidirectional range's
direction.
If it was reversed before calling rfind we could: let the user
reverse the result again or add the possibility to query the
range to know it it's already
On Tuesday, 15 January 2013 at 05:51:16 UTC, Andrei Alexandrescu
wrote:
(Warning: this assumes a fair bit of background with ranges and
the STL.)
We've had a long-standing weakness of ranges when compared with
STL iterators: in a find() call we get to access the balance of
the range from the
On Sunday, 13 January 2013 at 17:26:16 UTC, bearophile wrote:
Phil Lavoie:
And of course I managed to invert alias terms again!
Use the new syntax:
alias forwardPermutations = permutations!(CombPolicy.forward);
Bye,
bearophile
Love it
On Sunday, 13 January 2013 at 16:31:30 UTC, Phil Lavoie wrote:
Personally,
I would have the policy implemented:
permutations( Policy p = Policy.forward )() {
...
}
And maybe extend it with aliases:
alias fPermutations permutations!( Policy.forward );
alias rPermutations permutations
Personally,
I would have the policy implemented:
permutations( Policy p = Policy.forward )() {
...
}
And maybe extend it with aliases:
alias fPermutations permutations!( Policy.forward );
alias rPermutations permutations!( Policy.backward );
alias biPermutations permutations!( Policy.bidirectio
This is a problem because 90% of the time you'll only iterate
forward, and of the remaining 10%, 9% is just iterating
backwards, and maybe 1% of the time you want to iterate from
both the front and back in the same iteration. This means that
99% of the time, having two buffers is just wasted me
On Friday, 11 January 2013 at 15:36:29 UTC, evilrat wrote:
On Friday, 11 January 2013 at 15:34:33 UTC, Phil Lavoie wrote:
On Thursday, 10 January 2013 at 07:35:54 UTC, Rob T wrote:
http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
I want to load shared libraries during runtime as
Excellent!
Thanks to both of you that was very instructive and you provided
answers to every one of my questions.
I might try to use the tools/options you suggested but I decided
to go the "load at runtime" way instead (or rather, in the
meantime). Since I got everything working it'd be hard
On Thursday, 10 January 2013 at 07:35:54 UTC, Rob T wrote:
http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
I want to load shared libraries during runtime as plug-in's,
but the consensus seemed to indicate that DMD is not yet ready
for this. I wonder if these functions provide an
Hi all,
This is actually a duplicate of my post on the D.learn forums :).
I am concerned that it hasn't been answered only because it is in
a less popular sub forum. I'll try to make it short.
This websites recommends implib for the creation of import
library therefore I have been using it. W
Hi Stewart,
I read the notes on the page of the win32 project. I looked at
your request for first assigning a module to one's self before
starting to work on it and I did not find any way to do so.
I thought maybe I had to be logged in on the site, so I created
an account but when I log in i
On Friday, 28 December 2012 at 18:54:40 UTC, Phil Lavoie wrote:
Yeah, sure, it's not a big problem, it's not even a problem.
It's really just a matter of emulating the macro better, though
using std.algorithm's might actually give the correct answer
when the macro
Yeah, sure, it's not a big problem, it's not even a problem. It's
really just a matter of emulating the macro better, though using
std.algorithm's might actually give the correct answer when the
macro does not. I was just mentioning this as an example of
possible things that could be discussed
Hi,
Sorry for the duplicate the forum did not seem to have processed
my post so I made another one. I'm sorry I didn't mean TYPE
INFERENCE did not work I meant that this:
int x
uint y;
min( x, y ) will not compile, you would have to rewrite it to
min( x, cast( int )y ) for example, or min!int
On Thursday, 27 December 2012 at 18:16:35 UTC, Andrej Mitrovic
wrote:
On 12/27/12, Walter Bright wrote:
Is it an issue as you describe? Yes. Is it a big enough issue
to merit a
language change? I doubt it.
Ok, but we should at least document it. Currently we only have
a small
remark in the
Hi,
I am currently using the win32 api bindings project and the
transition went smoothly. However, the "version" import library
is not included in dmd's windows' libs, so we should have to keep
that in mind, in order to provide a full out-of-the-box working
installation.
I am willing to hel
Hi,
I am currently using the win32 api bindings project and things
went rather smoothly in migrating my (not so big) code (so far).
I love that pragmas are everywhere to make the compiler link to
proper libraries.
Also, the windows lib included in the distribution of dmd lacks
the "version"
On Wednesday, 26 December 2012 at 21:56:31 UTC, Phil Lavoie wrote:
All right I got a problem now.
Including winver.d triggers the inclusion of version.lib
through this:
pragma(lib, "version.lib");
However, this import library does not exist. So I created it
using,implib /n
All right I got a problem now.
Including winver.d triggers the inclusion of version.lib through
this:
pragma(lib, "version.lib");
However, this import library does not exist. So I created it
using,implib /noi /system version.lib ...\System32\version.dll
then moved it to the dmd\windows\lib fol
You know what, I have browsed it a little bit and I think the
choice to make aliases to A and W versions was the right one. I
was thinking of adding a
version( Unicode ) {
aliases here...
}
Of my own but I can see this is exactly what has been done so I
am thrilled. One last question: do you
On Wednesday, 26 December 2012 at 18:35:56 UTC, Andrej Mitrovic
wrote:
On 12/26/12, Phil Lavoie wrote:
I believe everything was moved to the core.sys.windows.windows
header.
No, that module existed for a long time but it was lacking a
lot of
functionality, so a couple of devs created the
On Wednesday, 26 December 2012 at 17:52:02 UTC, Martin wrote:
http://www.dsource.org/projects/bindings/wiki/WindowsApi
KK cool, I will browse them. However, this is a 1 to 1
correlation between windows headers and D versions, which is
cool. I was hoping more for a direct replacement of
core.
I have learned Haskell during my bachelor's degree and I cannot
say it has made a big difference for me, although I do understand
why people like the concepts of it. Recently, I was suggested by
a professor to re-learn it. He suggested me so because I was
making a presentation on how to extend
Holà,
I am currently reading Programming Windows and coding his
examples + my own initiatives. I know I am not the first one to
do this and Andrej Mitrovic directed me to his code samples. I
could not help but notice that those directives:
import win32.SOME_MODULE;
were used and are not suppo
In this case, I am convinced that there is no use of having the
"no accessibility but visibility" particularity, because I cannot
find any reason for it to stay like that (feature/exploit wise).
On the other hand, I don't work on the compiler and I have no
idea of what difficulties in would imp
private is _always_ module scope.
Ooops I meant private functions inside a module. I was wondering
if that would be allowed:
module a;
public auto aFunc( T )( T t ) { cantSeeMe( t ); }
private auto canSeeMe( SomeType t ) { ... }
module b;
import a;
alias a.canSeeMe canSeeMe
public auto canSeeM
Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.
I'd like to know if there is any functionality provided by having
private functions/methods being visible? Does it mean you can
override them in your module (for modul
Ok so it's the feature that allows you to write something like
myObject.notInClassDeclarationMethod( zeParam );
Which is awesome.
I'd like to know if there is any functionality provided by having
private functions/methods being visible? Does it mean you can
override them in your module (for mo
Never mind my last question. Found that it stands for: uniform
function call syntax. Now I am going to look into what that means
and how it affects the "no accessibility but visibility" thingy.
I'd like to add that I have programmed with google Go for some
time and moved to D for various reasons. It is true that unused
imports and variables may be a hint that something was done
wrong, or forgotten, and a review might be desirable. I am all
for being warned about this. However, it is a
On Monday, 14 May 2012 at 02:35:11 UTC, Jonathan M Davis wrote:
On Monday, May 14, 2012 02:53:20 Alex Rønne Petersen wrote:
Hi,
Would anyone be terribly angry if equals_t was deprecated and
later
removed? I sent a patch a while back to add a compare_t type
for
consistency, but the consensus e
Hi,
Yes indeed Kenji pointed me in the right direction. I tried
posting that I looked at the code he suggested and found what I
was looking for, but I had some issue posting :(.
Thanks
On Friday, 7 December 2012 at 07:57:09 UTC, Jacob Carlborg wrote:
On 2012-12-06 22:49, Phil Lavoie
I tested your code and it seems to work correctly. However, what
I find troubling is that I would never have thought of trying
this out. This is because those two properties are said to return
DELEGATES, according to this page:
http://dlang.org/hash-map.html, but it does not seem to be
correct
Hi,
Indeed as he suggested. I tried to reply that I was looking at
the code yesterday and that it was what I was looking for, but my
post did not get through for some reasons.
Thanks!
On Friday, 7 December 2012 at 07:57:09 UTC, Jacob Carlborg wrote:
On 2012-12-06 22:49, Phil Lavoie wrote
Got it!
Thanks
All right, thanks for your reply buddy!
Cool, I can see that we all (us three) agree then! Now, I am new
to this forum (and forums in general in fact) and I am unaware if
there is a different approach for suggesting changes (that are
not bugs) to the D language/runtime. Should I submit a form of
some sort elsewhere or will mentioning
I mean automatically dispatch to template members, not doing it
in a case by case fashion (using template if clauses for example).
Thanks
Greetings,
Given the following code:
struct Inner {
void fun1() {}
void fun2( string toto ) {}
string fun3() { return "tata"; }
string fun4( string tutu ) { return "this is going too far"; }
void fun5( string ohOh )() {}
}
struct Outer {
private Inner _inner;
auto opDispatch(
Hi,
I tested the code you provided and extended it a little and here
is the result:
struct bar (bool B, N...) {
int n = 0;
}
struct foo (N...) {
bar!(true, N) _bar = void;
bar!(true, N) getN() {
return _bar;
}
alias getN this;
public this(T) (T other)
if (is(T unused : int)) {
It's just that ranges are so attractive in the way they
"lazily" fetch values that it would make it easier to wrap
associative arrays in struct that return relevant ranges based
on the aa's content of constructing the result, than returning
the range/or result.
Typos, read:
It's just that ran
Hi,
I am aware that you can iterate over associative arrays in
multiple ways using the structure's opApply and different
delegates returned by properties. I think adding a "range"
property returning an input range to the associative array would
benefit the users of the D language.
I'd like
74 matches
Mail list logo
