Re: Partial classes
On 01/29/2012 01:43 PM, Mars wrote:
Hello everybody.
Quick question, is there anything like C#'s partial classes in D?
Mars
As already said template mixins are close to partial classes.
A snippet. HTH
import std.stdio, std.cstream;
void main(string[] args)
{
auto bar = new Bar();
writeln(bar.onClick());
// Lets the user press Return before program stops
din.getc();
}
mixin template FooMixin()
{
void initCommonControls()
{
}
string onClick()
{
return Clicked;
}
}
class Foo
{
mixin FooMixin;
}
class Bar : Foo
{
}
combine different data type
when i do that auto x = [1, ha]; i have an error Error: incompatible types for ((1) ? (hgh)): 'int' and 'string' if there any method to combine different data type?
Chained Catch Statements
In Java and C++, I can do something to the effect of:
try
{
//Some code
}
catch (Exception1)
{
}
catch (Exception2)
{
}
//etc...
However, this doesn't seem to be possible in D. What is the idiom for handling
a case where multiple exceptions of different types may be thrown?
Re: Chained Catch Statements
What is the idiom for handling a case where multiple exceptions of different types may be thrown? I think you could catch a common baseclass like Exception and test if it's a specific Exception by casting.
Re: Chained Catch Statements
On Monday, 30 January 2012 at 14:37:19 UTC, Jared wrote:
In Java and C++, I can do something to the effect of:
That works in D too.
I believe it does it linearly though, so it will use the
first catch that matches.
try {}
catch (Exception e) {} // most throwable objects derive from
Exception
catch (SpecialException e) {} // never used, because Exception
matches it all
Try putting the more specific catches first, and the generic
base classes at the end of the list.
Compile Time Printing
So from what I've found searching the newsgroup and my own
experimentation, the best way to accomplish compile time printing
is to do something like this:
string ctMain()
{
//evaluate and return the final result string
}
enum result = ctMain();
pragma(msg, result);
I'm not a fan of having to build a single string and print it all
at once. I know it's not that bad but it just means I have to
pass around an Appender!string to all my logic functions that
print results instead of having a central function they can call.
I know a ctwriteln never really caught on, and pragma(msg, ...)
has some limitations in that it can't use local variables even
in CTFE. Are there any alternatives I'm overlooking?
Re: Chained Catch Statements
I suppose that works, though it does seem a little hackish (and I'm pretty sure it's considered bad form in Java). What was the line of reasoning for omitting this (to me, at least) extremely useful construct?
Re: Chained Catch Statements
30.01.2012 16:37, Jared пишет:
However, this doesn't seem to be possible in D.
Why not?
import std.stdio;
class Exception1 : Throwable { this( string s ) { super( s ); } }
class Exception2 : Throwable { this( string s ) { super( s ); } }
void foo() {
throw new Exception1( foo );
}
void bar() {
throw new Exception2( bar );
}
int main() {
enum tryBar = false;
try {
static if( tryBar ) {
bar();
} else {
foo();
}
} catch( Exception1 e1 ) {
writeln( First catch block: , e1.msg );
} catch( Exception2 e2 ) {
writeln( Second catch block: , e2.msg );
}
return 0;
}
Re: combine different data type
On Mon, 30 Jan 2012 13:58:38 +0100, sami s...@hotmail.com wrote: when i do that auto x = [1, ha]; i have an error Error: incompatible types for ((1) ? (hgh)): 'int' and 'string' if there any method to combine different data type? You might want to check out std.variant. It's Variant type can hold any type you may want.
sub() in D2?
Is there a direct analog to sub() in D2? The replace() function in regex seems a bit overkill for what I need. I just want to substitute one string for another.
Re: combine different data type
Simen Kjærås simen.kja...@gmail.com wrote in message news:op.v8wj38qf0gp...@biotronic.lan... On Mon, 30 Jan 2012 13:58:38 +0100, sami s...@hotmail.com wrote: when i do that auto x = [1, ha]; i have an error Error: incompatible types for ((1) ? (hgh)): 'int' and 'string' if there any method to combine different data type? You might want to check out std.variant. It's Variant type can hold any type you may want. Or std.typecons.tuple. It will allow you to have a collection of values of different types. It deptends what your use case it.
Re: sub() in D2?
http://www.d-programming-language.org/phobos/std_array.html#replace import std.array; string a = test; string b = a.replace(t, p); assert(b == pesp);
Re: sub() in D2?
Thanks.
RPC module for D ?
There are any RPC module for D ??
Re: RPC module for D ?
On 1/30/12 5:27 PM, luis wrote: There are any RPC module for D ?? I implemented support for Apache Thrift during last summer's GSoC, it's currently under review for inclusion into Thrift trunk: http://klickverbot.at/code/gsoc/thrift/ David
Re: Chained Catch Statements
On 30-01-2012 15:37, Jared wrote:
In Java and C++, I can do something to the effect of:
try
{
//Some code
}
catch (Exception1)
{
}
catch (Exception2)
{
}
//etc...
However, this doesn't seem to be possible in D. What is the idiom for handling
a case where multiple exceptions of different types may be thrown?
Huh? I do this several places in my code. Works For Me (TM).
- Alex
Re: Chained Catch Statements
On Monday, 30 January 2012 at 14:50:23 UTC, Adam D. Ruppe wrote:
On Monday, 30 January 2012 at 14:37:19 UTC, Jared wrote:
In Java and C++, I can do something to the effect of:
That works in D too.
I believe it does it linearly though, so it will use the
first catch that matches.
try {}
catch (Exception e) {} // most throwable objects derive from
Exception
catch (SpecialException e) {} // never used, because Exception
matches it all
Try putting the more specific catches first, and the generic
base classes at the end of the list.
To me this seems like a mistake. Since likely your catching the
current exception and not one of the previously stored ones; A
codepath like that should either:
A) Fail at compile time, hopefully telling you a suggested order
so there's no problems.
B) Reorder the catch blocks on it's own during compile time,
since only one can get caught at a time anyways.
At least that's how I see it.
Re: Chained Catch Statements
On 1/30/12, Era Scarecrow rtcv...@yahoo.com wrote: To me this seems like a mistake. You could throw SpecialException in the handler for Exception. So it's legal code.
Re: Compile Time Printing
Blake Anderton: I know a ctwriteln never really caught on, There is an open pull request about it. And I think we'll have it in D. A problem is, that ctwriteln too adds a newline... :-( Bye, bearophile
Re: Chained Catch Statements
On Monday, 30 January 2012 at 17:17:46 UTC, Andrej Mitrovic wrote:
On 1/30/12, Era Scarecrow rtcv...@yahoo.com wrote:
To me this seems like a mistake.
You could throw SpecialException in the handler for Exception.
So it's
legal code.
Yes, thanks to inheritance it is legal code. However it's almost
the same as this, which is legal code too.
try {
} catch (Throwable t) {
} catch {Exception e) { //never executed
} catch (StreamException st) { //never executed
} //and the list can go on forever.
See the problem? Everything that COULD be caught by exception is
now caught by throwable since it's inherited. At the very least
the compiler should warn you that certain sections won't be
executed, But then I would have to manually look up the
relationships when the compiler already knows them. In GCC known
code blocks that are never executed aren't even compiled in. If
the compiler reorders the blocks for you, the above would become
this.
try {
} catch (StreamException st) { //specific case
} catch {Exception e) { //less specific but no other inheritances
of this kind
} catch (Throwable t) { //everything else.
}
Re: RPC module for D ?
On 2012-01-30 17:27, luis wrote: There are any RPC module for D ?? The Mango project has some support for RPC. But this if for D1 with Tango: http://dsource.org/projects/mango -- /Jacob Carlborg
Re: Chained Catch Statements
On Monday, 30 January 2012 at 18:23:56 UTC, Era Scarecrow wrote:
try {
} catch (Throwable t) {
} catch {Exception e) { //never executed
} catch (StreamException st) { //never executed
} //and the list can go on forever.
See the problem?
No?
Error: catch at test.d(3) hides catch at test.d(4)
The compiler does not reorder the exceptions because it enforces
order in the written code. As you say the compiler knows the
relationship, the one reading it may not.
Re: Chained Catch Statements
On Monday, 30 January 2012 at 19:25:03 UTC, Jesse Phillips wrote:
On Monday, 30 January 2012 at 18:23:56 UTC, Era Scarecrow wrote:
try {
} catch (Throwable t) {
} catch {Exception e) { //never executed
} catch (StreamException st) { //never executed
} //and the list can go on forever.
See the problem?
No?
Error: catch at test.d(3) hides catch at test.d(4)
The compiler does not reorder the exceptions because it
enforces order in the written code. As you say the compiler
knows the relationship, the one reading it may not.
So long as it errors from the hiding (as it appears it does) then
it's fine, and the previous example shown was wrong.
try {}
catch (Exception e) {} // most throwable objects derive from
Exception
catch (SpecialException e) {} // never used, because
Exception matches it all
Re: RPC module for D ?
I will try it. I only need to make a remote hello world , do a short description , and compare with other RPCs in other 3 languages (university homework...) . On Mon, 30 Jan 2012 17:30:59 +0100, David Nadlinger wrote: On 1/30/12 5:27 PM, luis wrote: There are any RPC module for D ?? I implemented support for Apache Thrift during last summer's GSoC, it's currently under review for inclusion into Thrift trunk: http://klickverbot.at/code/gsoc/thrift/ David -- Yep, I'm afraid that I have a blog : zardoz.es
Re: Pure Contract bug? (unnecessarily strict)
On Sunday, 29 January 2012 at 06:22:26 UTC, Era Scarecrow wrote: Maybe someone's brought this up, but i seem to have the compiler complaining to me that my function isn't 'pure' by calling a non-pure function, specifically to!string(). I don't see why this couldn't be done, not only does it get not exist in release, it shouldn't be changing variables in non-release. As mentioned there is a hole for debug code. Report it: http://d.puremagic.com/issues/ and we'll see what happens with that.
Re: Pure Contract bug? (unnecessarily strict)
I don't see why this couldn't be done, not only does it get not exist in release, it shouldn't be changing variables in non-release. As mentioned there is a hole for debug code. Report it: http://d.puremagic.com/issues/ and we'll see what happens with that. Reported; Minor priority (Won't break code) http://d.puremagic.com/issues/show_bug.cgi?id=7401
Re: RPC module for D ?
On Mon, 30 Jan 2012 17:30:59 +0100, David Nadlinger wrote: On 1/30/12 5:27 PM, luis wrote: There are any RPC module for D ?? I implemented support for Apache Thrift during last summer's GSoC, it's currently under review for inclusion into Thrift trunk: http://klickverbot.at/code/gsoc/thrift/ David I try to build it and when i did make check to see it all works I get two fails : thrift.transport.base.TTransportException@src/thrift/transport/socket.d(255): Failed to connect to 127.0.0.1:11122. ./unittest/debug/thrift/server/transport/socket(void thrift.server.transport.socket.__unittest3()+0x1ba) [0x45e2ea] ./unittest/debug/thrift/server/transport/socket(void thrift.server.transport.socket.__modtest()+0x9) [0x46529d] ./unittest/debug/thrift/server/transport/socket(extern (C) bool core.runtime.runModuleUnitTests().int __foreachbody272(ref object.ModuleInfo*)+0x30) [0x47f228] ./unittest/debug/thrift/server/transport/socket(int object.ModuleInfo.opApply(scope int delegate(ref object.ModuleInfo*))+0x55) [0x4712d9] ./unittest/debug/thrift/server/transport/socket(runModuleUnitTests+0xa7) [0x47f0f7] ./unittest/debug/thrift/server/transport/socket(extern (C) int rt.dmain2.main(int, char**).void runAll() +0x27) [0x47583f] ./unittest/debug/thrift/server/transport/socket(extern (C) int rt.dmain2.main(int, char**).void tryExec (scope void delegate())+0x2a) [0x4753ae] ./unittest/debug/thrift/server/transport/socket(main+0xd3) [0x47533f] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x2b67f2bc730d] FAIL: unittest/debug/thrift/server/transport/socket thrift.transport.base.TTransportException@src/thrift/transport/socket.d(255): Failed to connect to 127.0.0.1:11122. ./unittest/release/thrift/server/transport/socket(void thrift.server.transport.socket.__unittest3()+0x19f) [0x45e0a7] ./unittest/release/thrift/server/transport/socket(void thrift.server.transport.socket.__modtest()+0x9) [0x46372d] ./unittest/release/thrift/server/transport/socket(extern (C) bool core.runtime.runModuleUnitTests().int __foreachbody272(ref object.ModuleInfo*)+0x30) [0x47d32c] ./unittest/release/thrift/server/transport/socket(int object.ModuleInfo.opApply(scope int delegate(ref object.ModuleInfo*))+0x55) [0x46f749] ./unittest/release/thrift/server/transport/socket(runModuleUnitTests+0xa7) [0x47d1fb] ./unittest/release/thrift/server/transport/socket(extern (C) int rt.dmain2.main(int, char**).void runAll() +0x27) [0x473caf] ./unittest/release/thrift/server/transport/socket(extern (C) int rt.dmain2.main(int, char**).void tryExec (scope void delegate())+0x2a) [0x47381e] ./unittest/release/thrift/server/transport/socket(main+0xd3) [0x4737af] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x2b6f742c530d] FAIL: unittest/release/thrift/server/transport/socket -- Yep, I'm afraid that I have a blog : zardoz.es
Re: sub() in D2?
Am 30.01.2012, 16:57 Uhr, schrieb adamss3 sadam...@woh.rr.com: Thanks. The only downside of strings being arrays: a lot of typical string functions are in std.array. :D
Re: RPC module for D ?
On 1/30/12 11:35 PM, Zardoz wrote: I try to build it and when i did make check to see it all works I get two fails : […] Oh, I'm afraid you caught me in a bad moment – because the version for upstream integration is frozen at Thrift's JIRA, I've been a bit more careless with multi-platform testing when pushing to my GitHub master (resp. d-gsoc) branch than normal – was an artifact of IPv6 support being rolled out, should be fixed now. Also, please note that the »all green« status on the project page applies to commit 73e7e5e (the one submitted for upstream integration), I didn't have time to check whether the IPv6 stuff works on Windows yet. David
Re: RPC module for D ?
On Tue, 31 Jan 2012 00:17:18 +0100, David Nadlinger wrote: On 1/30/12 11:35 PM, Zardoz wrote: I try to build it and when i did make check to see it all works I get two fails : […] Oh, I'm afraid you caught me in a bad moment – because the version for upstream integration is frozen at Thrift's JIRA, I've been a bit more careless with multi-platform testing when pushing to my GitHub master (resp. d-gsoc) branch than normal – was an artifact of IPv6 support being rolled out, should be fixed now. Also, please note that the »all green« status on the project page applies to commit 73e7e5e (the one submitted for upstream integration), I didn't have time to check whether the IPv6 stuff works on Windows yet. David At least I can say that the Tutorial client server works (async_client not compile) :) . For me it's enough . -- Yep, I'm afraid that I have a blog : zardoz.es
Re: RPC module for D ?
On 1/31/12 12:29 AM, Zardoz wrote: At least I can say that the Tutorial client server works (async_client not compile) :) . For me it's enough . Because you don't have libevent installed (the tutorial makefile doesn't have detection for that by design), or do you encounter another error? Thanks, David
Re: Chained Catch Statements
On 1/30/12, Era Scarecrow rtcv...@yahoo.com wrote: If the compiler reorders the blocks for you A warning, maybe. But I'm against compilers which try to be too smart and rewrite code to change its semantics. If there's something wrong with my code I want to know about it (warning or error) and fix it, I don't want the compiler rewriting bad code behind-the-scenes. That only encourages writing sloppy code, and I end up having to know implementation details of each compiler to really know what some function body actually does (it could be someone else's code and not just mine).
Re: Chained Catch Statements
On Tuesday, January 31, 2012 01:05:20 Andrej Mitrovic wrote: On 1/30/12, Era Scarecrow rtcv...@yahoo.com wrote: If the compiler reorders the blocks for you A warning, maybe. But I'm against compilers which try to be too smart and rewrite code to change its semantics. If there's something wrong with my code I want to know about it (warning or error) and fix it, I don't want the compiler rewriting bad code behind-the-scenes. That only encourages writing sloppy code, and I end up having to know implementation details of each compiler to really know what some function body actually does (it could be someone else's code and not just mine). I see no reason why the compiler should be reordering anything here. That changes the semantics of the code. It's not like it's a great burden on the programmer to just reorder the blocks so that they're in the correct order. Having the compiler give a warning or error would be plenty, and a lot better than letting the programmer continue to screw up their code in ignorance. If they don't understand how the catch blocks work, they're likely to screw up more than just the order. I do think that having the compiler complain when one catch block hides another makes a lot of sense, but I think that that's as far as it should go. It's the programmer's job to fix their code, not the compiler's. - Jonathan M Davis
Re: Chained Catch Statements
Jonathan M Davis: I do think that having the compiler complain when one catch block hides another makes a lot of sense, but I think that that's as far as it should go. It's the programmer's job to fix their code, not the compiler's. I agree. Do we create a new diagnostic enhancement request then? Bye, bearophile
About to!int
In Python int() and float() convert a string into a number even if it contains some whitespace before and after the number: s = 12\n int(s) 12 float(s) 12.0 In D to!int( 12\n) gives a run-time error. So time ago I have weakly asked Andrei to change to!int, to let it ignore leading and trailing whitespace, but he has ignored my request. A leading newline comes often from input stdin.readln() and other sources. So in D you need to add a strip(): int n = to!int(stdin.readln().strip()); I sometimes forget to add the strip(). Do you know why Andrei has not appreciated the idea of to!int and similar functions to ignore leading and trailing whitespace? Bye, bearophile
Re: Chained Catch Statements
I see no reason why the compiler should be reordering anything here. That changes the semantics of the code. It's not like it's a great burden on the programmer to just reorder the blocks so that they're in the correct order. Having the compiler give a warning or error would be plenty, and a lot better than letting the programmer continue to screw up their code in ignorance. If they don't understand how the catch blocks work, they're likely to screw up more than just the order. I do think that having the compiler complain when one catch block hides another makes a lot of sense, but I think that that's as far as it should go. It's the programmer's job to fix their code, not the compiler's. You are right.. I just have wishful thinking of the compiler being smart enough to auto-fix some things, but when you start making assumptions then errors and problems tend to arise more. That and if the compiler DOES reorder those blocks, then you re-ordering them for a specific reason may not work and could have unintended results. Course I don't see how with Try/catch since only one block (plus finally) can be used at a time.
Re: sub() in D2?
On 2012-01-31 00:09, Marco Leise wrote: Am 30.01.2012, 16:57 Uhr, schrieb adamss3 sadam...@woh.rr.com: Thanks. The only downside of strings being arrays: a lot of typical string functions are in std.array. :D If everything in std.array works for strings as well, shouldn't std.string publicly import std.array? -- /Jacob Carlborg
Re: sub() in D2?
On Tuesday, January 31, 2012 08:16:25 Jacob Carlborg wrote: On 2012-01-31 00:09, Marco Leise wrote: Am 30.01.2012, 16:57 Uhr, schrieb adamss3 sadam...@woh.rr.com: Thanks. The only downside of strings being arrays: a lot of typical string functions are in std.array. :D If everything in std.array works for strings as well, shouldn't std.string publicly import std.array? You could quickly get into similar arguments with std.range and std.algorithm, as well as std.ascii and std.uni. Ultimately, functions are organized into modules based on where they make the most sense to ones writing the functions, and you import the modules that have what you need. You can't get away from having to know what module has what you need unless we get something like std.all which publicly imports _everything_. And the folks who get paranoid about importing symbols that they don't need are going to tend to want modules to include _less_ rather than more. So, there's that to contend with as well. No matter how you organize the functions, there will always been problems with it. Ultimately, you just learn where what you need is. And in this case, a string is an array, so as long as you understand that, std.array should definitely be one of the places that you look for functions when messing with strings, not just std.string. - Jonathan M Davis
Re: About to!int
On Mon, 30 Jan 2012 21:01:38 -0500, bearophile wrote: In D to!int( 12\n) gives a run-time error. So time ago I have weakly asked Andrei to change to!int, to let it ignore leading and trailing whitespace, but he has ignored my request. A leading newline comes often from input stdin.readln() and other sources. So in D you need to add a strip(): int n = to!int(stdin.readln().strip()); Bye, bearophile Try parse!int( 12\n); http://www.d-programming-language.org/phobos/std_conv.html#parse -- Yep, I'm afraid that I have a blog : zardoz.es
