On 2012-07-16 21:37, Adam Wilson wrote:
The only problem I can see with this is that the build would only for
whichever OS the merger happens to be running on. A two step process is
about the best we can do.
./merge does the following
git fetch upstream
git cherry-pick 534d44c979
git
On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg d...@me.com wrote:
On 2012-07-16 21:37, Adam Wilson wrote:
The only problem I can see with this is that the build would only for
whichever OS the merger happens to be running on. A two step process is
about the best we can do.
./merge does
On Mon, 16 Jul 2012 23:24:04 -0700
Adam Wilson flybo...@gmail.com wrote:
On Mon, 16 Jul 2012 23:17:38 -0700, Jacob Carlborg d...@me.com
wrote:
On 2012-07-16 21:37, Adam Wilson wrote:
./build does the following for all projects
git fetch origin
git merge origin/master
make clean -f
On 2012-07-17 08:24, Adam Wilson wrote:
Each parameter represents a specific commit ID to pick.
So you would pass those to the script?
--
/Jacob Carlborg
On Monday, 16 July 2012 at 17:27:32 UTC, Marco Leise wrote:
Am Fri, 20 Jan 2012 00:36:11 +0100
I didn't check your code, but does it handle case-insensitive
Windows OS as well as Unix like?
I didn't think consider this when working on it, so it's probably
always case-sensitive.
Did you
On Tue, 17 Jul 2012 02:08:55 -0700, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 08:24, Adam Wilson wrote:
Each parameter represents a specific commit ID to pick.
So you would pass those to the script?
Yup, I think that's probably the safest way to do it. Given the goals of
the
On 2012-07-17 19:04, Adam Wilson wrote:
Yup, I think that's probably the safest way to do it. Given the goals of
the project, we need to be explicit about which commits we choose so
forcing the maintainers to write down every commit is good practice.
Exactly. I took that example a bit too
On 2012-07-16 23:36, SomeDude wrote:
It's *not* textual search and replace. It's compiler checked semantic
refactoring.
Yet again we need a compiler as a library :)
--
/Jacob Carlborg
On Tuesday, 17 July 2012 at 06:29:46 UTC, Jacob Carlborg wrote:
On 2012-07-16 23:36, SomeDude wrote:
It's *not* textual search and replace. It's compiler checked
semantic
refactoring.
Yet again we need a compiler as a library :)
I find myself agreeing more and more.
To my understanding this is legal C :
int foo ();
It's a KR-style variadic functions, while their use is discouraged,
they're still legal C.
If I, in D, declare a variadic function with C linkage that doesn't
take, at least, one regular parameter the compiler will complain.
extern (C) int
On Tuesday, 17 July 2012 at 06:56:17 UTC, Jacob Carlborg wrote:
To my understanding this is legal C :
int foo ();
It's a KR-style variadic functions, while their use is
discouraged, they're still legal C.
My eyes!! They're bleeding!!
On Monday, 16 July 2012 at 22:42:47 UTC, Andrei Alexandrescu
wrote:
Wow, this is awesome. Did you discover that by inspection or by
testing? I think a malicious input range would be a great
tool for assessing which algorithms fail on input ranges.
Andrei
The first I discovered testing with
On Tuesday, 17 July 2012 at 07:06:38 UTC, Mehrdad wrote:
On Tuesday, 17 July 2012 at 06:56:17 UTC, Jacob Carlborg wrote:
To my understanding this is legal C :
int foo ();
It's a KR-style variadic functions, while their use is
discouraged, they're still legal C.
My eyes!! They're
I was trying to fix a few bugs in algorithm, as well as be more
correct in template type specifiers, and I have to say: There is
a serious restraint in the definition of an outputRange.
The current definition of isOutputRange is simply that an
output range is defined functionally as a range
I'm the bottleneck for that. My list of actual work (aside from
my duties as phobos/druntime/tools/dlang.org curator) is:
1. Put std.benchmark through the review process
2. Define allocators
3. Integrate allocators with std.container
If you have fixes for std.container that are faraway
Chris NS ibisbase...@gmail.com writes:
+1 for a 2.breaking.bugfix scheme. I've used this scheme on
anything serious for years, and know many others who have; so it is
not only popular but also quite tried and proven. Not for every
project, of course (although I don't understand why the
Era Scarecrow , dans le message (digitalmars.D:172568), a écrit :
On Monday, 16 July 2012 at 21:59:17 UTC, Tommi wrote:
On Monday, 16 July 2012 at 20:22:12 UTC, Era Scarecrow wrote:
MyEnumType y = cast(MyEnumType) 42; //Error: wtf is 42 anyways?
Like the previous fellow said, it's not an
On 2012-07-17 09:06, Mehrdad wrote:
My eyes!! They're bleeding!!
First I wanted to know if my interpretation is correct and then I was
trying to figure out how my tool should behave if it encounters a
function like this.
--
/Jacob Carlborg
Jonathan M Davis , dans le message (digitalmars.D:172564), a écrit :
They're likely to contain a lot of stuff negation of other template
constraints. For instance,
auto func(R)(R range)
if(isForwardRange!R !isBidirectionalRange!R)
{}
auto func(R)(R range)
On 17/07/2012 06:37, RivenTheMage wrote:
On Monday, 16 July 2012 at 22:14:03 UTC, Jonathan M Davis wrote:
Going to v3 would mean incrementing the 2.
We have _no_ intention of doing that for years
to come.
Small steps are perfect for many projects, but - in my opinion -
not for a programming
On Tue, 17 Jul 2012 12:43:46 +0100, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 09:06, Mehrdad wrote:
My eyes!! They're bleeding!!
First I wanted to know if my interpretation is correct and then I was
trying to figure out how my tool should behave if it encounters a
function like
On Tue, 17 Jul 2012 13:32:08 +0100, Regan Heath re...@netmail.co.nz
wrote:
On Tue, 17 Jul 2012 12:43:46 +0100, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 09:06, Mehrdad wrote:
My eyes!! They're bleeding!!
First I wanted to know if my interpretation is correct and then I was
monarch_dodra , dans le message (digitalmars.D:172586), a écrit :
I was trying to fix a few bugs in algorithm, as well as be more
correct in template type specifiers, and I have to say: There is
a serious restraint in the definition of an outputRange.
The current definition of
On Tuesday, 10 July 2012 at 09:24:42 UTC, Don Clugston wrote:
On 10/07/12 09:49, renoX wrote:
On Monday, 9 July 2012 at 11:40:37 UTC, Gor Gyolchanyan wrote:
[cut]
You're right. This is a bit advanced code sample, which uses
templates,template constraints, contract programming among
syntax
On 2012-07-17 14:32, Regan Heath wrote:
After a bit of googling and a test with my local MSVC9 I think old-style
variadics look like this:
#include varargs.h
#include stdio.h
void foo(va_alist)
va_dcl
{
va_list p;
va_start(p);
vprintf(%d %d %d\n, p);
}
void main()
{
On 2012-07-17 15:05, Regan Heath wrote:
In my specific case I could add int a as the first parameter, and all
was well. Each case will be different, and it's conceivable there is a
C old-style variadic which takes /any/ type of first parameter, which
could be a problem, however the key issue
On Tue, 17 Jul 2012 15:01:02 +0100, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 15:05, Regan Heath wrote:
In my specific case I could add int a as the first parameter, and all
was well. Each case will be different, and it's conceivable there is a
C old-style variadic which takes /any/
On Tue, 17 Jul 2012 15:02:44 +0100, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 14:32, Regan Heath wrote:
After a bit of googling and a test with my local MSVC9 I think old-style
variadics look like this:
#include varargs.h
#include stdio.h
void foo(va_alist)
va_dcl
{
va_list
On 2012-07-17 16:36, Regan Heath wrote:
I believe old-style no parameter function declarations MUST have void
i.e.
int foo(void);
That is still the case, regardless of style?
They cannot read:
int foo();
The latter MUST have parameters, we just can't tell what they are.
Take
On 7/17/12 4:41 AM, monarch_dodra wrote:
On Monday, 16 July 2012 at 22:42:47 UTC, Andrei Alexandrescu
wrote:
Wow, this is awesome. Did you discover that by inspection or by
testing? I think a malicious input range would be a great tool for
assessing which algorithms fail on input ranges.
On 2012-07-17 16:37, Regan Heath wrote:
All my googling for old style variadic etc returned the use of
va_alist and va_dcl so I can't see where/why Clang would do what it's
doing.
To be accurate it's the libclang function clang_isFunctionTypeVariadic
that returns true.
On 7/17/12 6:44 AM, monarch_dodra wrote:
I was trying to fix a few bugs in algorithm, as well as be more correct
in template type specifiers, and I have to say: There is a serious
restraint in the definition of an outputRange.
The current definition of isOutputRange is simply that an output
On 17/07/2012 08:56, Jacob Carlborg wrote:
To my understanding this is legal C :
int foo ();
It's a KR-style variadic functions, while their use is discouraged,
they're still legal C.
If I, in D, declare a variadic function with C linkage that doesn't
take, at least, one regular parameter the
I want to imitate golang's interface in D, to study D's
template. I wrote
some code: https://gist.github.com/3123593
Now we can write code like golang:
--
interface IFoo {
void foo(int a, string b, float c);
}
struct Foo {
void foo(int a, string b, float c) {
writeln(Foo.foo: ,
On Tue, 17 Jul 2012 15:46:34 +0100, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 16:36, Regan Heath wrote:
I believe old-style no parameter function declarations MUST have void
i.e.
int foo(void);
That is still the case, regardless of style?
They cannot read:
int foo();
On Tue, 17 Jul 2012 15:50:27 +0100, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 16:37, Regan Heath wrote:
All my googling for old style variadic etc returned the use of
va_alist and va_dcl so I can't see where/why Clang would do what it's
doing.
To be accurate it's the libclang function
On Tue, 17 Jul 2012 15:46:34 +0100, Jacob Carlborg d...@me.com wrote:
On 2012-07-17 16:36, Regan Heath wrote:
I believe old-style no parameter function declarations MUST have void
i.e.
int foo(void);
That is still the case, regardless of style?
They cannot read:
int foo();
OutputRange is designed for infinite output ranges, like output
files and appender.
[snip]
Well, designed is open for interpretation.
Yes, all (most) ranges defined as output (files, streams,
appenders) are infinite, and don't define empty (or define it as
false).
But that does not mean
I propose to introduce a reference to the current function, much
like 'this' in a class method. Call it 'self' or 'thisFunc', or
whatever ...
What might this be good for ?
For implementing recursion in a lambda function.
Writing in functional style, one creates many functions, and
looking for
On Jul 17, 2012 1:00 PM, angel andrey.gel...@gmail.com wrote:
I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
What might this be good for ?
For implementing recursion in a lambda function.
Writing in
On Tuesday, July 17, 2012 10:47:50 Andrei Alexandrescu wrote:
On 7/17/12 4:41 AM, monarch_dodra wrote:
On Monday, 16 July 2012 at 22:42:47 UTC, Andrei Alexandrescu
wrote:
Wow, this is awesome. Did you discover that by inspection or by
testing? I think a malicious input range would be a
Walter Bright:
auto code() { return cast(ushort)42; }
works fine. There isn't really a lack here, just some more
typing. I just don't see the case coming up hardly at all.
I have just found an example (reduced code):
import std.typecons;
void main() {
alias Tuple!(ubyte[]) Tu;
deadalnix deadal...@gmail.com wrote in message
news:ju3uqc$55g$1...@digitalmars.com...
It is used in testfptr.d from dmd's testsuite.
No, that's a D-linkage variadic.
On Tuesday, 17 July 2012 at 15:16:56 UTC, Regan Heath wrote:
On Tue, 17 Jul 2012 15:46:34 +0100, Jacob Carlborg
d...@me.com wrote:
On 2012-07-17 16:36, Regan Heath wrote:
I believe old-style no parameter function declarations MUST
have void
i.e.
int foo(void);
That is still the
On Tuesday, 17 July 2012 at 15:13:52 UTC, Regan Heath wrote:
On Tue, 17 Jul 2012 15:50:27 +0100, Jacob Carlborg
d...@me.com wrote:
On 2012-07-17 16:37, Regan Heath wrote:
All my googling for old style variadic etc returned the
use of
va_alist and va_dcl so I can't see where/why Clang would
On 17 July 2012 12:05, Wouter Verhelst wou...@grep.be wrote:
Chris NS ibisbase...@gmail.com writes:
+1 for a 2.breaking.bugfix scheme. I've used this scheme on
anything serious for years, and know many others who have; so it is
not only popular but also quite tried and proven. Not for every
On Tue, Jul 17, 2012 at 01:09:09PM -0400, Kevin Cox wrote:
On Jul 17, 2012 1:00 PM, angel andrey.gel...@gmail.com wrote:
I propose to introduce a reference to the current function, much
like 'this' in a class method. Call it 'self' or 'thisFunc', or
whatever ...
What might this be good
On Tue, Jul 17, 2012 at 08:07:08PM +0200, Paulo Pinto wrote:
On Tuesday, 17 July 2012 at 15:16:56 UTC, Regan Heath wrote:
[...]
So all KR function declarations were name() with no parameters.
R
KR was more than that.
This modern C declaration:
int main(int argc, char **argv) {
On 2012-07-17 17:11, Regan Heath wrote:
Ahh, I've been looking at the ANSI C spec and assuming that is what
you're basing things off, KR C was pre-ANSI C and may have different
rules. I think you should probably aim to be ANSI C compliant and
above, and ignore KR.
This page says otherwise:
On Tuesday, July 17, 2012 11:47:07 Christophe Travert wrote:
The compiler could stop displaying at about 10 failed constrains and
claim there are more. It would be best if it could figure out what are
the 10 most interesting constrains, but that may not be easy!
That seems like a good idea.
-
On Friday, 13 July 2012 at 14:58:57 UTC, bearophile wrote:
A blog post about one of the Rust pointers, the borrowed ones:
http://smallcultfollowing.com/babysteps/blog/2012/07/10/borrowed-pointer-tutorial/
Bye,
bearophile
Rust is a much more interesting language than Go. At least they
are
On 2012-07-17 17:13, Regan Heath wrote:
Is Clang open source, can we see the code for that function? Perhaps
it's a bug.. ANSI C may have made () without void obsolete, but no
compiler I've ever used has actually enforced that - or perhaps C++ made
old-style function definition/declarations
On 07/17/2012 07:25 PM, bearophile wrote:
Walter Bright:
auto code() { return cast(ushort)42; }
works fine. There isn't really a lack here, just some more typing. I
just don't see the case coming up hardly at all.
I have just found an example (reduced code):
import std.typecons;
void
I was sure that if function is declared with empty () than you
can call it with any arguments you imagine, as it is in following
examples.
= ex. 1
* cat main.c
void a() {
}
int main()
{
a(1, 2, 3);
return 0;
}
* gcc -Wall -Wextra -pedantic main.c
*
On 07/17/2012 06:56 PM, angel wrote:
I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or 'thisFunc', or whatever ...
What might this be good for ?
For implementing recursion in a lambda function.
Writing in functional style, one
I'm a fresh college graduate who just got a job as a software
developer, and I have been enthusiastically watching D for a
while now (I program primarily in Java and C). I have some
functional programming experience in Haskell and Scala as well.
I like using octal numbers, and I've always
angel:
I propose to introduce a reference to the current function,
much like 'this' in a class method. Call it 'self' or
'thisFunc', or whatever ...
Or __func or something. I'm asking for it for years.
Bye,
bearophile
Other languages provide other means.
In any case, I don't think it would be a problem if D solved a
problem other languages failed to resolve properly.
As for http://d.puremagic.com/issues/show_bug.cgi?id=7176, this
is pretty much orthogonal to the 'self reference'.
On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
I propose to introduce a reference to the current function,
much like 'this' in a class method. Call it 'self' or
'thisFunc', or whatever ...
What might this be good for ?
For implementing recursion in a lambda function.
Writing in
On Tue, 17 Jul 2012 23:53:47 +0200
Dave X. dxuhu...@gmail.com wrote:
I'm a fresh college graduate who just got a job as a software
developer, and I have been enthusiastically watching D for a
while now (I program primarily in Java and C). I have some
functional programming experience in
On Tuesday, 17 July 2012 at 22:13:13 UTC, Eyyub wrote:
On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
I propose to introduce a reference to the current function,
much like 'this' in a class method. Call it 'self' or
'thisFunc', or whatever ...
What might this be good for ?
For
On Jul 17, 2012 6:50 PM, Era Scarecrow rtcv...@yahoo.com wrote:
On Tuesday, 17 July 2012 at 22:13:13 UTC, Eyyub wrote:
On Tuesday, 17 July 2012 at 16:56:17 UTC, angel wrote:
I propose to introduce a reference to the current function, much like
'this' in a class method. Call it 'self' or
On Wednesday, July 18, 2012 00:03:25 bearophile wrote:
angel:
I propose to introduce a reference to the current function,
much like 'this' in a class method. Call it 'self' or
'thisFunc', or whatever ...
Or __func or something. I'm asking for it for years.
You could always use
Definitely - I live in a very technologically-savvy dorm in college, and
when I encountered it for the first time nobody there had any idea what
it was.
...we did later find an old book in our library that had it, though.
-Matt
On 07/17/2012 02:39 PM, H. S. Teoh wrote:
On Tue, Jul 17, 2012
On Tue, Jul 17, 2012 at 11:08 PM, David Piepgrass qwertie...@gmail.comwrote:
I, too, was enamored with Go Interfaces and implemented them for .NET:
http://www.codeproject.com/**Articles/87991/Dynamic-**
It is indeed supposed to work, and was actually touted as a
common and lauded example way back in the day. However, with the
advent of this-params for templates it seems less useful now
(once they've been through the ringer a little more at least).
I did use this-params to great effect in
How would you go about retrieving the exact underlying type of
enum?
There's a thorough explanation of how incomplete types work in
C++:
http://www.drdobbs.com/the-standard-librarian-containers-of-inc/184403814
And there's some more C++ related stuff:
http://www.boost.org/doc/libs/1_50_0/doc/html/container/containers_of_incomplete_types.html
I wouldn't know
On 7/17/2012 1:27 AM, Alexandr Druzhinin wrote:
16.07.2012 9:46, Mike Parker пишет:
On 7/16/2012 1:01 AM, Alexandr Druzhinin wrote:
15.07.2012 22:56, Alexandr Druzhinin пишет:
15.07.2012 22:33, Alex Rønne Petersen пишет:
test case:
class A {
}
__gshared A a;
void main(string[] args) {
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!MySubB
{}
void main()
{}
This pattern is actually quite common in C++ code, and referred
to as
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s = known.value(); // -- automatic
I just know how to do this:
string s =
On Tuesday, 17 July 2012 at 13:56:29 UTC, Andrea Fontana wrote:
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s =
Andrea Fontana:
class Known
{
void* data; // external data by c api
int type; // 0 for int, 1 for string, etc. ..
}
How can I implement a method like this?
Known known; // -- suppose known.type == 1;
string s = known.value(); // -- automatic
To do this Known.value()
Better than nothing :)
Hope in better template deduction...
Il giorno mar, 17/07/2012 alle 16.22 +0200, Tobias Pankrath ha scritto:
On Tuesday, 17 July 2012 at 13:56:29 UTC, Andrea Fontana wrote:
class Known
{
void* data; // external data by c api
int type; // 0 for
i'm not completely sure i understand your problem but i think you are
looking for something like this:
http://pocoproject.org/docs/Poco.DynamicAny.html
maybe the c++ source code could be of some inspiration. this should be
possible in d, too.
17.07.2012 18:34, Mike Parker пишет:
On 7/17/2012 1:27 AM, Alexandr Druzhinin wrote:
The reason were bindings to GeographicLib C++ library written in
analogue to Derelict bindings (I used it in my projects too).
Now I'm trying to make simple test cases for my trouble.
Bindings based on
16.07.2012 10:29, Ellery Newcomer пишет:
On 07/15/2012 09:01 AM, Alexandr Druzhinin wrote:
15.07.2012 22:56, Alexandr Druzhinin пишет:
sorry for my hurry - I've localized the problem in the linked libraries,
not in my code. Will find further... what the h*ll
Sorry again
I experienced this
I'm looking for a graphing library for D. Preferrably, something
that uses Qt, but it doesn't have to. I am plotting sonar data,
and I need to plot it 'live' so... I need something that is:
1. simple to use. I just want to graph x,y data.
2. ability to scale the display.
3. displaying more
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB : MyBase!MySubB
{}
void main()
On Tuesday, 17 July 2012 at 17:42:49 UTC, dcoder wrote:
I'm looking for a graphing library for D. Preferrably,
something that uses Qt, but it doesn't have to. I am plotting
sonar data, and I need to plot it 'live' so... I need something
that is:
1. simple to use. I just want to graph x,y
Al 17/07/12 19:53, En/na cal ha escrit:
On Tuesday, 17 July 2012 at 17:42:49 UTC, dcoder wrote:
I'm looking for a graphing library for D. Preferrably, something that uses
Qt, but it doesn't have to. I am plotting sonar data, and I need to plot it
'live' so... I need something that is:
1.
On 7/17/2012 12:23 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB :
How exactly does the compiler know how to do foreach on ranges
(for example, ones returned by std.algorithm.map ?) I've looked
around in std.algorithm and std.range, but can't seem to figure
it out.
On 07/17/2012 11:59 AM, Mike L. wrote:
How exactly does the compiler know how to do foreach on ranges (for
example, ones returned by std.algorithm.map ?) I've looked around in
std.algorithm and std.range, but can't seem to figure it out.
The spec mentions it under 'Foreach over Structs and
On Tuesday, July 17, 2012 20:59:12 Mike L. wrote:
How exactly does the compiler know how to do foreach on ranges
(for example, ones returned by std.algorithm.map ?) I've looked
around in std.algorithm and std.range, but can't seem to figure
it out.
It translates
foreach(e; range)
{}
into
On Tuesday, 17 July 2012 at 19:27:54 UTC, Jonathan M Davis wrote:
It translates
foreach(e; range)
{}
into something like
foreach(auto __range = range; !__range.empty;
__range.popFront())
{
auto e = __range.front;
}
The compiler knows just enough about ranges to enable foreach,
but
On Tuesday, July 17, 2012 21:38:51 Eyyub wrote:
On Tuesday, 17 July 2012 at 19:27:54 UTC, Jonathan M Davis wrote:
It translates
foreach(e; range)
{}
into something like
foreach(auto __range = range; !__range.empty;
__range.popFront())
{
auto e = __range.front;
On Tuesday, 17 July 2012 at 19:45:45 UTC, Jonathan M Davis wrote:
This post gives the current precedence, but there was some
discussion of
adjusting it a bit:
http://forum.dlang.org/post/mailman.275.1342019430.31962.digitalmars-
d...@puremagic.com
From the looks of it, opApply gets
On 07/17/2012 07:23 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes me as being a bug:
class MyBase(T)
{}
class MySubA : MyBase!MySubA
{}
class MySubB :
On 07/17/2012 10:50 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 22:36:10 Timon Gehr wrote:
On 07/17/2012 07:23 PM, Jonathan M Davis wrote:
On Tuesday, July 17, 2012 14:48:32 David Nadlinger wrote:
On Tuesday, 17 July 2012 at 05:24:26 UTC, Jonathan M Davis wrote:
This code strikes
On Tuesday, 17 July 2012 at 20:50:41 UTC, Jonathan M Davis wrote:
The problem is that if you have static ifs and the like in the
base class
which depends on compile time reflection of the derived class,
you effectively
have a recursive template definition. e.g.
class MyBase(T)
{
static
On Tuesday, July 17, 2012 23:11:43 Timon Gehr wrote:
This issue is unrelated to CRTP. (also, you probably want to negate
that static if condition, otherwise the code is valid and poses no
challenge to a compiler.)
It's not that it makes the compiler's life hard. It's the fact that
conditional
On 7/18/2012 12:45 AM, Alexandr Druzhinin wrote:
17.07.2012 18:34, Mike Parker пишет:
On 7/17/2012 1:27 AM, Alexandr Druzhinin wrote:
The reason were bindings to GeographicLib C++ library written in
analogue to Derelict bindings (I used it in my projects too).
Now I'm trying to make simple
Thanks for the reply. Not sure how I missed it there. Interesting
that the compiler has to be made aware of a concept that I had
thought was only supposed to be part of phobos. Would it be
possible to implement it in std.range using the new UFCs?
On Tuesday, 17 July 2012 at 19:17:47 UTC, Ali
On Wednesday, July 18, 2012 06:27:28 Mike L. wrote:
Thanks for the reply. Not sure how I missed it there. Interesting
that the compiler has to be made aware of a concept that I had
thought was only supposed to be part of phobos. Would it be
possible to implement it in std.range using the new
Hello. When I'm trying to create a class object by using a
dlsym-ed function, I'm getting a segmentation fault after
execution of program.
However, if I'm deleting that object before 'return 0' in main
(by using 'delete b'), everything is going fine.
I'm just started to learn D after using
On Wednesday, 18 July 2012 at 04:54:51 UTC, Jonathan M Davis
wrote:
On Wednesday, July 18, 2012 06:27:28 Mike L. wrote:
Thanks for the reply. Not sure how I missed it there.
Interesting
that the compiler has to be made aware of a concept that I had
thought was only supposed to be part of
On Wednesday, July 18, 2012 07:19:59 Kapps wrote:
If UFCS worked on operators, you would be able to make ranges
without any compiler support.
int opApply(T)(T Range) if(isInputRange!T) {
// Stuff.
}
You can't overload operators externally to a user-defined type. They must be
part of
http://d.puremagic.com/issues/show_bug.cgi?id=4517
--- Comment #4 from github-bugzi...@puremagic.com 2012-07-16 23:34:17 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
http://d.puremagic.com/issues/show_bug.cgi?id=7080
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
1 - 100 of 110 matches
Mail list logo
