On 08/02/2012 09:17 PM, Zeh wrote:
> Hi, i am just a newbie trying learn D. But, i get having some trouble
> with "read_bool". More specifically on program of this lesson:
As Timon said, read_bool() is a separate function on the same page, a
little after main():
bool read_bool(string message)
Actually I just solved the problem, by copying all the libs from
dmd.2.0.59.zip into C:\dm\lib\
And this is my sc.ini:
[Environment]
LIB="C:\dmd\lib"
DFLAGS="-IC:\dmd\import" "-IC:\dmd\phobos"
LINKCMD=link.exe
On 8/3/2012 12:31 AM, Regan Heath wrote:
Have you downloaded and extracted a normal
On 08/03/2012 06:17 AM, Zeh wrote:
Hi, i am just a newbie trying learn D. But, i get having some trouble
with "read_bool". More specifically on program of this lesson:
import std.stdio;
import std.conv;
import std.string;
void main()
{
write("How many are we? ");
int personCount;
readf(" %s", &
Hi, i am just a newbie trying learn D. But, i get having some
trouble with "read_bool". More specifically on program of this
lesson:
import std.stdio;
import std.conv;
import std.string;
void main()
{
write("How many are we? ");
int personCount;
readf(" %s", &personCount);
wri
Thank you,guys,now all became clear to me.
On 08/02/2012 04:42 PM, Zhenya wrote:
> I mean that in ths code
>
> double f = 0;
>
> template T(alias a)
> {
> void doit()
> {
> a = 1;
> }
> }
>
> int main(string[] argv)
> {
> T!f.doit();
> writeln(f);//alias a is'nt 0,alias a is f
Yes, the a in template T is an alias of f.
> So why if we dec
On 8/3/12, Zhenya wrote:
> Huh,thank you,I understood.I just thought that by default alias
> parameter is an identifier.I was surprised then I saw that
> possible to pass value of variable,which is'nt enum.Could you
> explain me why it is?
I think alias can be seen as "pass by name". The template
I mean that in ths code
double f = 0;
template T(alias a)
{
void doit()
{
a = 1;
}
}
int main(string[] argv)
{
T!f.doit();
writeln(f);//alias a is'nt 0,alias a is f
readln();
return 0;
}
So why if we declared variable whith
Sorry for my terrible english
On Thursday, 2 August 2012 at 22:36:34 UTC, Andrej Mitrovic wrote:
On 8/3/12, Zhenya wrote:
snip
You mean how to extract the variable name?
import std.stdio;
template T(alias a)
{
enum string T = __traits(identifier, a);
}
void main(string[] argv)
{
char f = 'a';
writeln(T!f);
On 8/3/12, Zhenya wrote:
> snip
You mean how to extract the variable name?
import std.stdio;
template T(alias a)
{
enum string T = __traits(identifier, a);
}
void main(string[] argv)
{
char f = 'a';
writeln(T!f); // writes 'f'
}
module main;
import std.stdio;
immutable double f = 0;
template T(alias a)
{
auto T = a;
}
int main(string[] argv)
{
char f = 'a';
writeln(typeid(T!f));//deduce f as 'a'
readln();
return 0;
}
On Thursday, 2 August 2012 at 20:36:53 UTC, Ali Çehreli wrote:
On 08/02/2012 01:36 PM, Namespace wrote:
On Thursday, 2 August 2012 at 20:33:02 UTC, Eyyub wrote:
Hi,
std.variant with delegate seems to be buggy :
http://dpaste.dzfl.pl/24a87b46
Why the output is not 42 ?
Thx
writeln(*vastr.ge
On 08/02/2012 01:36 PM, Namespace wrote:
On Thursday, 2 August 2012 at 20:33:02 UTC, Eyyub wrote:
Hi,
std.variant with delegate seems to be buggy :
http://dpaste.dzfl.pl/24a87b46
Why the output is not 42 ?
Thx
writeln(*vastr.get!(typeof(() => 42)));
prints 42 ;)
And these:
a)
auto f
On Thursday, 2 August 2012 at 20:33:02 UTC, Eyyub wrote:
Hi,
std.variant with delegate seems to be buggy :
http://dpaste.dzfl.pl/24a87b46
Why the output is not 42 ?
Thx
writeln(*vastr.get!(typeof(() => 42)));
prints 42 ;)
On Thu, Aug 2, 2012 at 7:59 PM, rookie wrote:
> Hi,
>
> I have the following C++ code, what would be the equivalent D code;
IIRC, Test::pop is a method definition, right ?
>
> template
> T Test::pop(int ind)
> {
> T pop = T();
> // Stuff that not important
> //
> return pop;
Hi,
I have the following C++ code, what would be the equivalent D
code;
template
T Test::pop(int ind)
{
T pop = T();
// Stuff that not important
//
return pop;
}
Thanks,
rookie
On Thu, 02 Aug 2012 16:59:32 +0100, Andre Tampubolon
wrote:
I found this code from this page:
http://rosettacode.org/wiki/Category:D
import std.stdio, std.socket;
void main(){
writefln("%s", Socket.hostName());
}
When I tried to build it (I'm on Windows, anyway), I got this:
C:\Users\
On Thursday, August 02, 2012 09:55:51 Joseph Rushton Wakeling wrote:
> Hello all,
>
> While playing around I noticed something that rather disturbed me about
> const/immutable's relationship with arrays. If I do e.g.
>
> import std.stdio;
>
> void main()
> {
> immutable(int)[] foo = [1, 2, 3, 4,
I just remembered that the official dmd build has those libs. So I grab
them and put them into C:\dmd\lib.
Still, the same error still happens. Maybe because I build dmd,
druntime, and phobos from git?
On 8/2/2012 10:59 PM, Andre Tampubolon wrote:
When I tried to build it (I'm on Windows, a
I found this code from this page:
http://rosettacode.org/wiki/Category:D
import std.stdio, std.socket;
void main(){
writefln("%s", Socket.hostName());
}
When I tried to build it (I'm on Windows, anyway), I got this:
C:\Users\CSL-NB-064\Codes\D>dmd hostname.d
OPTLINK (R) for Win32 Release 8
On Thursday, 2 August 2012 at 14:52:58 UTC, Andrei Alexandrescu
wrote:
On 8/2/12 9:48 AM, monarch_dodra wrote:
By forcing the developer to chose the bitfield size (32 or
64), you ARE forcing him to make a choice dependent on the
machine's characteristics.
I think that's backwards.
I think
On 8/2/12 9:48 AM, monarch_dodra wrote:
On Thursday, 2 August 2012 at 12:38:10 UTC, Andrei Alexandrescu wrote:
On 8/2/12 5:26 AM, monarch_dodra wrote:
One of the *big* reasons I'm against having a hand chosen padding, is
that the implementation *should* be able to find out what the most
efficie
On Thursday, 2 August 2012 at 12:38:10 UTC, Andrei Alexandrescu
wrote:
On 8/2/12 5:26 AM, monarch_dodra wrote:
One of the *big* reasons I'm against having a hand chosen
padding, is
that the implementation *should* be able to find out what the
most
efficient padding is on the current machine (co
repost from issue list:
Austin Hastings 2010-09-24 18:06:53 PDT
Also, I think I'm going to request that repeated bitfield
definitions be allowed if they are identical - I'd like to
redeclare "opcode" rather than "".
How would you tell them apart? If I know how you may want to call
them, I ma
Following from issue list:
bearophile_hugs 2010-10-04 18:16:44 PDT
Another possible feature is to make std.bitmanip.bitfields
generate two
versions of the code, that get compiled conditionally according
to the CPU
endianess:
static if (std.system.endian == std.system.Endian.BigEndian) {
.
On Thursday, 2 August 2012 at 12:35:20 UTC, Andrei Alexandrescu
wrote:
Please don't. The effort on the programmer side is virtually
nil, and keeps things in check. In no case would the use of
bitfields() be so intensive that the bloat of one line gets any
significance.>
If you're using a t
On 8/2/12 5:26 AM, monarch_dodra wrote:
One of the *big* reasons I'm against having a hand chosen padding, is
that the implementation *should* be able to find out what the most
efficient padding is on the current machine (could be 32 on some, could
be 64 on some)
In my neck of the woods they ca
On Thursday, 2 August 2012 at 11:42:21 UTC, Joseph Rushton
Wakeling wrote:
Sure. What I'm looking for is not some absolute and
unachievable prohibition, but a safety-checking mechanism that
would be flagged by the compiler. The real problem was that I
couldn't just set bar = foo without bar b
On 8/2/12 5:14 AM, Era Scarecrow wrote:
On Thursday, 2 August 2012 at 09:03:54 UTC, monarch_dodra wrote:
I had an (implementation) question for you: Does the implementation
actually require knowing what the size of the padding is?
eg:
struct A
{
int a;
mixin(bitfields!(
uint, "x", 2,
int, "y",
If a function is marked @safe, casting away immutable is
not allowed by the compiler.
But, you can't put this on the array. It needs to be on
the user's functions:
@safe void foo(immutable(ubyte)[] arr) {
auto cheating = cast(ubyte[]) arr;
}
test2.d(2): Error: cast from immutable(ubyte)[] to
On Thursday, 2 August 2012 at 11:26:42 UTC, David Nadlinger wrote:
On Thursday, 2 August 2012 at 11:11:58 UTC, Era Scarecrow wrote:
How do I remove one of the pulls so I can concentrate on the
one set of features and continue the others later?
Hm? You can just close pull requests (button at th
On 02/08/12 10:25, Ali Çehreli wrote:
.dup and .idup will always make a copy, std.conv.to won't:
Brilliant. You could actually say that my _real_ problem was how to copy
const(int)[] to int[] without the cast, as it's the cast that brings the lack of
safety. std.conv.to seems to fit the bil
On 02/08/12 10:22, Era Scarecrow wrote:
If someone wants to modify something, they can go into assembly language and
force it or use C wrappers that lie wouldn't stop it. Comes down to the
programmers in the end.
That's a very good point. I'm not asking for something rock-solid, but just
wh
On Thursday, 2 August 2012 at 11:11:58 UTC, Era Scarecrow wrote:
How do I remove one of the pulls so I can concentrate on the
one set of features and continue the others later?
Hm? You can just close pull requests (button at the bottom of the
page), and reopen them later.
David
Currently since I've been concentrating more on bitfields and
BitArray needs more work, the two separate patches and trees are
out of sync and apparently the auto-tester brings them up as a
fail. How do I remove one of the pulls so I can concentrate on
the one set of features and continue the
On Thursday, 2 August 2012 at 09:26:04 UTC, monarch_dodra wrote:
Well, I was just trying to figure out the rationale: The most
obvious one for me being "it is much easier on the
implementation".
Since the template is recursive and at the end after bit
counting would know how much it needed,
On Thursday, 2 August 2012 at 09:14:15 UTC, Era Scarecrow wrote:
On Thursday, 2 August 2012 at 09:03:54 UTC, monarch_dodra wrote:
I had an (implementation) question for you: Does the
implementation actually require knowing what the size of the
padding is?
eg:
struct A
{
int a;
mixin(bit
On 08/02/2012 01:55 AM, Joseph Rushton Wakeling wrote:
> (i) is there a way to mark an array as "under no
> circumstances allow anything to modify the contents" in a way that
> _can't_ be cast away like this? and (ii) given that I can use instead
> bar = foo.dup to copy foo, is this guaranteed to
On Thursday, 2 August 2012 at 08:56:42 UTC, Joseph Rushton
Wakeling wrote:
But, 2 questions: (I) is there a way to Mark an array as "under
no circumstances allow anything to modify the contents" in a
way that _can't_ be cast away like this? and (ii) given that I
can use instead bar = foo.dup to
On Thursday, 2 August 2012 at 09:03:54 UTC, monarch_dodra wrote:
I had an (implementation) question for you: Does the
implementation actually require knowing what the size of the
padding is?
eg:
struct A
{
int a;
mixin(bitfields!(
uint, "x",2,
int, "y",3,
On Wednesday, 1 August 2012 at 07:24:09 UTC, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 20:41:55 UTC, Dmitry Olshansky
wrote:
Great to see things moving. Could you please do a separate
pull for bitfields it should get merged easier and it seems
like a small but important bugfix.
https
Hello all,
While playing around I noticed something that rather disturbed me about
const/immutable's relationship with arrays. If I do e.g.
import std.stdio;
void main()
{
immutable(int)[] foo = [1, 2, 3, 4, 5];
int[] bar = cast(int[]) foo;
bar[2]
43 matches
Mail list logo
