Re: SQLite3
On Wednesday, 7 May 2014 at 06:21:10 UTC, Jack wrote:
First off a Disclaimer: I'm a noob and still learning. Please
don't bash me like some forums.
Now to the questions: I'm searching for a quick and easy way to
integrate SQLite3 in my application. I came across the
etc.c.sqlite3 and the DSQLite
library(https://github.com/bioinfornatics/DSQLite).
Thinking that the C bindings is more documented I tried learning
that. Though I can't understand the arguements of the callback
function.
extern(C) int callback(
void* NotUsedAtAll, // Null variable
int argc, // What?
char** results, // Results?
char** columnNames //Column Names?
){
for(int i = 0; iargc; i++){
writeln(results);
getchar();
}
I've been reading through many explanations about this and I
understand why the callback is needed but I can't seem to
understand how to really use the callback function. Can someone
provide a brief explanation or just point me in the right
direction?
May as well throw an undocumented library at you:
https://github.com/JesseKPhillips/SQLite3-D
I only used it to pull data out of SQLite database. Once you have
your db object it is something like this.
foreach(data; db.query(statement).range!Structure)...
Where you define a struct with Nullable!() types your statement
pulls out.
Re: [Rosettacode] D code line length limit
On Wed, 07 May 2014 18:51:58 +
Meta via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote:
On Wednesday, 7 May 2014 at 14:40:37 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
My eyes... Oh, how that hurts readibily.
While I agree that
pure @safe @nogc nothrow
void doSomething(int n)
{
}
is quite ugly, it is really not much worse than
void doSomething(int n) pure @safe @nogc nothrow
{
}
I would argue that the latter hurts readability more, as parsing
meaning from long lines is difficult for humans. Also, we can
always go deeper ;-)
Actually, I find the second version perfectly readable, and I think that it is
by far the best way for that function signature to be written, whereas I find
the first one to be much, much harder to read. But ultimately, this sort of
thing pretty much always ends up being highly subjective.
- Jonathan M Davis
Re: __traits with alias
alias a = __traits(getMember, module_, m); // fails
//Error: basic type expected, not __traits
//Error: semicolon expected to close alias declaration
Is this a bug or I've missed something?
It's a syntax limitation for alias. That bites us from time to time.
A workaround is to wrap it into another template, to 'hide' __traits.
Like this:
alias Alias(alias a) = a; // A bit circular, I know.
void registerAll(alias module_)()
{
foreach (m; __traits(derivedMembers, module_)) {
regInner!(__traits(getMember, module_, m));
alias a = Alias!(__traits(getMember, module_, m)); // compiles
}
}
void regInner(alias T)()
{
// ...
}
void main(){}
I think there is bug report / enhancement for this. I find it a bit
annoying, since aliasing a __traits expression is quite common.
Re: Need help with movement from C to D
Artur Skawina: But I have no idea why anybody would want to wrap this trivial expression like that. And, I have no idea if the, hmm, /unconventional/ D offsetof semantics are in the bugzilla. It's not really a bug, but a design mistake... https://issues.dlang.org/show_bug.cgi?id=12714 Bye, bearophile
Re: Need help with movement from C to D
On Tuesday, 6 May 2014 at 15:13:41 UTC, Artur Skawina via Digitalmars-d-learn wrote: On 05/06/14 16:45, via Digitalmars-d-learn wrote: On Tuesday, 6 May 2014 at 14:25:01 UTC, Artur Skawina via Digitalmars-d-learn wrote: I'm not sure why you'd want to wrap the .offsetof expression in a template, but it can easily be done like this: enum offsetOf(alias A, string S) = mixin(A.~S~.offsetof); Great, that's even shorter. Somehow I was fixated on converting the symbol to a string first, but of course the name is directly available in the mixin: enum offsetof(alias typenfield) = mixin(typenfield.offsetof); I didn't realize that worked, but it does. So... enum offsetOf(alias A) = A.offsetof; But I have no idea why anybody would want to wrap this trivial expression like that. And, I have no idea if the, hmm, /unconventional/ D offsetof semantics are in the bugzilla. It's not really a bug, but a design mistake... artur just out of curiousity, why an alias is used there?
Re: [Rosettacode] D code line length limit
On Thu, 08 May 2014 07:29:08 +
bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Jonathan M Davis:
ultimately, this sort of
thing pretty much always ends up being highly subjective.
But please put the const/immutable of methods on the right:
struct Foo {
void bar1() const {} // Good
const void bar2() {} // Bad
}
Well, that's one case where there's actually an objective reason to put it on
the right due to one of the flaws in the language - that it's the one place
that const inconsistently does not apply to the type immediately to its right
(though it's consistent with how attributes are applied to the function itself
- just not consistent with variables).
It's also because of this that I favor putting most attributes on the right
(though that's subjective, unlike with const). I only put attributes on the
left if they're on the left in C++ or Java (e.g. static, public, or final).
Everything else goes on the right.
Unfortunately, making this consistent by doing something like enforcing that
all function attributes go on the right would then be inconsistent with other
languages with regards to the attributes that they have which go on the left,
so I don't know how we could have gotten it completely right. No matter which
way you go, it's inconsistent in one way or another. If it were up to me, I'd
probably enforce that all attributes which could be ambiguous go on the right
but that all others could go on either side, but Walter has never liked that
idea. So, we're stuck with arguing that everyone should put them on the right
by convention in order to avoid the ambiguity.
- Jonathan M Davis
throws Exception in method
Hello everyone,
in java, you can have exceptions on methods.
Thus we can write:
public static void control (String string) throws
MyException {}
Is that possible in D and if so how does it work? If I write this
D:
public void testMe () throws MyException {}
The compiler refuses to compile.
What is the proper behavior for this D?
thank you
Re: throws Exception in method
On Thursday, 8 May 2014 at 09:15:16 UTC, amehat wrote:
Hello everyone,
in java, you can have exceptions on methods.
Thus we can write:
public static void control (String string) throws
MyException {}
Is that possible in D and if so how does it work? If I write
this D:
public void testMe () throws MyException {}
The compiler refuses to compile.
What is the proper behavior for this D?
thank you
All functions/methods can throw in D, unless they are marked
nothrow.
Re: throws Exception in method
amehat: What is the proper behavior for this D? D doesn't have that Java syntax, because it was widely regarded as a Java design mistake. So in D omit the throws part. If your function tree doesn't throw exceptions (but it can throw errors) add a nothrow. Bye, bearophile
Re: throws Exception in method
On Thu, 08 May 2014 09:15:13 +
amehat via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Hello everyone,
in java, you can have exceptions on methods.
Thus we can write:
public static void control (String string) throws
MyException {}
Is that possible in D and if so how does it work? If I write this
D:
public void testMe () throws MyException {}
The compiler refuses to compile.
What is the proper behavior for this D?
thank you
At this point, the programming community at large seems to have decided that
while checked exceptions seem like a good idea, they're ultimately a bad one.
This article has a good explanation from one of the creators of C# as to why:
http://www.artima.com/intv/handcuffs.html
At this point, Java is the only language I'm aware of which has checked
exceptions (though there may be a few others somewhere), and newer languages
have learned from Java's mistake and chosen not to have them.
What D has instead is the attribute nothrow. Any function marked with nothrow
cannot throw an exception. e.g.
auto func(int bar) nothrow {...}
It's similar to C++11's noexcept except that it's checked at compile time
(like Java's checked exceptions), whereas noexcept introduces a runtime check.
If a function is not marked with nothrow, then the only ways to know what it
can throw are to read the documentation (which may or may not say) or to read
the code. There are obviously downsides to that in comparison to checked
exceptions, but the consensus at this point is that it's ultimately better.
- Jonathan M Davis
Re: [Rosettacode] D code line length limit
On Thu, 08 May 2014 09:30:38 + bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Jonathan M Davis: Unfortunately, making this consistent by doing something like enforcing that all function attributes go on the right would then be inconsistent with other languages with regards to the attributes that they have which go on the left, This is a job for a Lint. like DScanner :-) Sure, that could point out that putting const or the left is bug-prone and warn you that you should change it, but while it's not really possible to have a fully consistent design with regards to function attributes, I still think that allowing const on the left is simply a bad design decision. A linter is then just a way to help you work around that bad design decision. - Jonathan M Davis
Re: SQLite3
On Wednesday, 7 May 2014 at 19:03:34 UTC, Arjan wrote:
On Wednesday, 7 May 2014 at 06:21:10 UTC, Jack wrote:
First off a Disclaimer: I'm a noob and still learning. Please
don't bash me like some forums.
Now to the questions: I'm searching for a quick and easy way to
integrate SQLite3 in my application.
maybe:
https://github.com/buggins/ddbc/wiki ?
I seem to have a problem with that library. Even if the modules
have been imported and the libraries linked and yada yada, it
spews error upon error. Sample code is this:
import std.stdio;
import ddbc.drivers.sqliteddbc;
void main(){
SQLITEDriver driver = new SQLITEDriver();
writeln(SUCCESS);
}
Error spewed out is this:
hello.d|7|Error: undefined identifier SQLITEDriver|
I think Code::Blocks is importing the modules but not detecting
the modules. Been at it for a few hours now. Any help?
On Thursday, 8 May 2014 at 05:57:39 UTC, Jesse Phillips wrote:
On Wednesday, 7 May 2014 at 06:21:10 UTC, Jack wrote:
First off a Disclaimer: I'm a noob and still learning. Please
don't bash me like some forums.
Now to the questions: I'm searching for a quick and easy way to
integrate SQLite3 in my application. I came across the
etc.c.sqlite3 and the DSQLite
library(https://github.com/bioinfornatics/DSQLite).
Thinking that the C bindings is more documented I tried
learning
that. Though I can't understand the arguements of the callback
function.
extern(C) int callback(
void* NotUsedAtAll, // Null variable
int argc, // What?
char** results, // Results?
char** columnNames //Column Names?
){
for(int i = 0; iargc; i++){
writeln(results);
getchar();
}
I've been reading through many explanations about this and I
understand why the callback is needed but I can't seem to
understand how to really use the callback function. Can someone
provide a brief explanation or just point me in the right
direction?
May as well throw an undocumented library at you:
https://github.com/JesseKPhillips/SQLite3-D
I only used it to pull data out of SQLite database. Once you
have your db object it is something like this.
foreach(data; db.query(statement).range!Structure)...
Where you define a struct with Nullable!() types your statement
pulls out.
Sounds easy enough, I'll take a look at it. Thank you ...
Re: [Rosettacode] D code line length limit
Jonathan M Davis: I still think that allowing const on the left is simply a bad design decision. I opened a request on this, and it was closed down :-) Bye, bearophile
Re: [Rosettacode] D code line length limit
On Thu, 08 May 2014 10:27:17 + bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Jonathan M Davis: I still think that allowing const on the left is simply a bad design decision. I opened a request on this, and it was closed down :-) I know. Walter doesn't agree that it was a bad decision. He thinks that being consistent with the other function attributes and letting them all be on both sides of the function is more important, but given the fact that that's highly error-prone for const and immutable, I definitely think that it was a bad decision. Unfortunately, we're stuck with it, because Walter doesn't agree, and I don't expect that anyone is going to be able to convince him. - Jonathan M Davis
Re: SQLite3
On Thursday, 8 May 2014 at 10:29:16 UTC, Jack wrote:
On Wednesday, 7 May 2014 at 19:03:34 UTC, Arjan wrote:
On Wednesday, 7 May 2014 at 06:21:10 UTC, Jack wrote:
First off a Disclaimer: I'm a noob and still learning. Please
don't bash me like some forums.
Now to the questions: I'm searching for a quick and easy way
to
integrate SQLite3 in my application.
maybe:
https://github.com/buggins/ddbc/wiki ?
I seem to have a problem with that library. Even if the modules
have been imported and the libraries linked and yada yada, it
spews error upon error. Sample code is this:
import std.stdio;
import ddbc.drivers.sqliteddbc;
void main(){
SQLITEDriver driver = new SQLITEDriver();
writeln(SUCCESS);
}
Error spewed out is this:
hello.d|7|Error: undefined identifier SQLITEDriver|
I think Code::Blocks is importing the modules but not detecting
the modules. Been at it for a few hours now. Any help?
Did you specify the configuration to use to dub?
dub -c SQLite
Re: SQLite3
On Thursday, 8 May 2014 at 11:07:06 UTC, Arjan wrote:
On Thursday, 8 May 2014 at 10:29:16 UTC, Jack wrote:
On Wednesday, 7 May 2014 at 19:03:34 UTC, Arjan wrote:
On Wednesday, 7 May 2014 at 06:21:10 UTC, Jack wrote:
First off a Disclaimer: I'm a noob and still learning. Please
don't bash me like some forums.
Now to the questions: I'm searching for a quick and easy way
to
integrate SQLite3 in my application.
maybe:
https://github.com/buggins/ddbc/wiki ?
I seem to have a problem with that library. Even if the
modules have been imported and the libraries linked and yada
yada, it spews error upon error. Sample code is this:
import std.stdio;
import ddbc.drivers.sqliteddbc;
void main(){
SQLITEDriver driver = new SQLITEDriver();
writeln(SUCCESS);
}
Error spewed out is this:
hello.d|7|Error: undefined identifier SQLITEDriver|
I think Code::Blocks is importing the modules but not
detecting the modules. Been at it for a few hours now. Any
help?
Did you specify the configuration to use to dub?
dub -c SQLite
Yes. I've also linked the library to it.
Dub:
http://puu.sh/8DYrR.png
Code::Blocks Configuration:
http://puu.sh/8DYug.png
Re: throws Exception in method
On Thursday, 8 May 2014 at 10:14:27 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Thu, 08 May 2014 09:15:13 +
amehat via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
Hello everyone,
in java, you can have exceptions on methods.
Thus we can write:
public static void control (String string) throws
MyException {}
Is that possible in D and if so how does it work? If I write
this
D:
public void testMe () throws MyException {}
The compiler refuses to compile.
What is the proper behavior for this D?
thank you
At this point, the programming community at large seems to have
decided that
while checked exceptions seem like a good idea, they're
ultimately a bad one.
This article has a good explanation from one of the creators of
C# as to why:
http://www.artima.com/intv/handcuffs.html
At this point, Java is the only language I'm aware of which has
checked
exceptions (though there may be a few others somewhere), and
newer languages
have learned from Java's mistake and chosen not to have them.
What D has instead is the attribute nothrow. Any function
marked with nothrow
cannot throw an exception. e.g.
auto func(int bar) nothrow {...}
It's similar to C++11's noexcept except that it's checked at
compile time
(like Java's checked exceptions), whereas noexcept introduces a
runtime check.
If a function is not marked with nothrow, then the only ways to
know what it
can throw are to read the documentation (which may or may not
say) or to read
the code. There are obviously downsides to that in comparison
to checked
exceptions, but the consensus at this point is that it's
ultimately better.
- Jonathan M Davis
My English might not be very good and I'm not sure I understand.
If I understand what you say, D for all methods (and functions)
can raise exceptions, unless it has nothrow. And if I still
includes exceptions that are thrown are at the time of
compilation.
So I can not write:
public void testMe () throws MyException {}
However, if I write this and my method throws an exception, it
will take place at compile time:
public void testMe () {}
And if do not want an exception thrown, I should write:
public void testMe () : nothrow {}
or perhaps :
public void testMe () pure nothrow @safe {}
Is that correct?
PS: Thanks for the article on the interveiw Anders Hejlsberg, it
enlightens me a little more about how exceptions sen D (and C #;))
Re: throws Exception in method
On Thursday, 8 May 2014 at 12:00:40 UTC, amehat wrote:
On Thursday, 8 May 2014 at 10:14:27 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Thu, 08 May 2014 09:15:13 +
amehat via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
Hello everyone,
in java, you can have exceptions on methods.
Thus we can write:
public static void control (String string) throws
MyException {}
Is that possible in D and if so how does it work? If I write
this
D:
public void testMe () throws MyException {}
The compiler refuses to compile.
What is the proper behavior for this D?
thank you
At this point, the programming community at large seems to
have decided that
while checked exceptions seem like a good idea, they're
ultimately a bad one.
This article has a good explanation from one of the creators
of C# as to why:
http://www.artima.com/intv/handcuffs.html
At this point, Java is the only language I'm aware of which
has checked
exceptions (though there may be a few others somewhere), and
newer languages
have learned from Java's mistake and chosen not to have them.
What D has instead is the attribute nothrow. Any function
marked with nothrow
cannot throw an exception. e.g.
auto func(int bar) nothrow {...}
It's similar to C++11's noexcept except that it's checked at
compile time
(like Java's checked exceptions), whereas noexcept introduces
a runtime check.
If a function is not marked with nothrow, then the only ways
to know what it
can throw are to read the documentation (which may or may not
say) or to read
the code. There are obviously downsides to that in comparison
to checked
exceptions, but the consensus at this point is that it's
ultimately better.
- Jonathan M Davis
My English might not be very good and I'm not sure I understand.
If I understand what you say, D for all methods (and functions)
can raise exceptions, unless it has nothrow. And if I still
includes exceptions that are thrown are at the time of
compilation.
So I can not write:
public void testMe () throws MyException {}
However, if I write this and my method throws an exception, it
will take place at compile time:
public void testMe () {}
And if do not want an exception thrown, I should write:
public void testMe () : nothrow {}
or perhaps :
public void testMe () pure nothrow @safe {}
Is that correct?
PS: Thanks for the article on the interveiw Anders Hejlsberg,
it enlightens me a little more about how exceptions sen D (and
C #;))
Exceptions are runtime-only (or ctfe (compile time function
execution), but that's not relevant here).
functions that are not marked nothrow can, at any point in the
body of the function, exit via an exception. Functions marked
nothrow cannot exit via an exception; the compiler must be able
to prove that all exceptions that could be thrown are caught, e.g.
void foo() nothrow
{
try
{
throw new Exception();
}
catch(Exception e){}
}
is fine.
Re: SQLite3
On Thursday, 8 May 2014 at 11:48:14 UTC, Jack wrote:
On Thursday, 8 May 2014 at 11:07:06 UTC, Arjan wrote:
On Thursday, 8 May 2014 at 10:29:16 UTC, Jack wrote:
On Wednesday, 7 May 2014 at 19:03:34 UTC, Arjan wrote:
On Wednesday, 7 May 2014 at 06:21:10 UTC, Jack wrote:
First off a Disclaimer: I'm a noob and still learning.
Please
don't bash me like some forums.
Now to the questions: I'm searching for a quick and easy
way to
integrate SQLite3 in my application.
maybe:
https://github.com/buggins/ddbc/wiki ?
I seem to have a problem with that library. Even if the
modules have been imported and the libraries linked and yada
yada, it spews error upon error. Sample code is this:
import std.stdio;
import ddbc.drivers.sqliteddbc;
void main(){
SQLITEDriver driver = new SQLITEDriver();
writeln(SUCCESS);
}
Error spewed out is this:
hello.d|7|Error: undefined identifier SQLITEDriver|
I think Code::Blocks is importing the modules but not
detecting the modules. Been at it for a few hours now. Any
help?
Did you specify the configuration to use to dub?
dub -c SQLite
Yes. I've also linked the library to it.
Dub:
http://puu.sh/8DYrR.png
Code::Blocks Configuration:
http://puu.sh/8DYug.png
Ah ok. CodeBlocks does not integrate with dub.
Take a look in the dub.json file of ddbc and collect the
'versions' for the SQLite configuration (USE_SQLITE)
Add those 'versions' to the DMD commandline n codeblocks:
dmd.exe -version=USE_SQLITE -version=...
Re: throws Exception in method
On Thursday, 8 May 2014 at 12:27:55 UTC, John Colvin wrote:
On Thursday, 8 May 2014 at 12:00:40 UTC, amehat wrote:
On Thursday, 8 May 2014 at 10:14:27 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Thu, 08 May 2014 09:15:13 +
amehat via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
Hello everyone,
in java, you can have exceptions on methods.
Thus we can write:
public static void control (String string) throws
MyException {}
Is that possible in D and if so how does it work? If I write
this
D:
public void testMe () throws MyException {}
The compiler refuses to compile.
What is the proper behavior for this D?
thank you
At this point, the programming community at large seems to
have decided that
while checked exceptions seem like a good idea, they're
ultimately a bad one.
This article has a good explanation from one of the creators
of C# as to why:
http://www.artima.com/intv/handcuffs.html
At this point, Java is the only language I'm aware of which
has checked
exceptions (though there may be a few others somewhere), and
newer languages
have learned from Java's mistake and chosen not to have them.
What D has instead is the attribute nothrow. Any function
marked with nothrow
cannot throw an exception. e.g.
auto func(int bar) nothrow {...}
It's similar to C++11's noexcept except that it's checked at
compile time
(like Java's checked exceptions), whereas noexcept introduces
a runtime check.
If a function is not marked with nothrow, then the only ways
to know what it
can throw are to read the documentation (which may or may not
say) or to read
the code. There are obviously downsides to that in comparison
to checked
exceptions, but the consensus at this point is that it's
ultimately better.
- Jonathan M Davis
My English might not be very good and I'm not sure I
understand.
If I understand what you say, D for all methods (and
functions) can raise exceptions, unless it has nothrow. And if
I still includes exceptions that are thrown are at the time of
compilation.
So I can not write:
public void testMe () throws MyException {}
However, if I write this and my method throws an exception, it
will take place at compile time:
public void testMe () {}
And if do not want an exception thrown, I should write:
public void testMe () : nothrow {}
or perhaps :
public void testMe () pure nothrow @safe {}
Is that correct?
PS: Thanks for the article on the interveiw Anders Hejlsberg,
it enlightens me a little more about how exceptions sen D (and
C #;))
Exceptions are runtime-only (or ctfe (compile time function
execution), but that's not relevant here).
functions that are not marked nothrow can, at any point in the
body of the function, exit via an exception. Functions marked
nothrow cannot exit via an exception; the compiler must be able
to prove that all exceptions that could be thrown are caught,
e.g.
void foo() nothrow
{
try
{
throw new Exception();
}
catch(Exception e){}
}
is fine.
Okay.
Thank you for these explanations, I understand a little better
the exceptions D.
Re: SQLite3
On Thursday, 8 May 2014 at 12:47:55 UTC, Arjan wrote:
On Thursday, 8 May 2014 at 11:48:14 UTC, Jack wrote:
On Thursday, 8 May 2014 at 11:07:06 UTC, Arjan wrote:
On Thursday, 8 May 2014 at 10:29:16 UTC, Jack wrote:
On Wednesday, 7 May 2014 at 19:03:34 UTC, Arjan wrote:
On Wednesday, 7 May 2014 at 06:21:10 UTC, Jack wrote:
First off a Disclaimer: I'm a noob and still learning.
Please
don't bash me like some forums.
Now to the questions: I'm searching for a quick and easy
way to
integrate SQLite3 in my application.
maybe:
https://github.com/buggins/ddbc/wiki ?
I seem to have a problem with that library. Even if the
modules have been imported and the libraries linked and yada
yada, it spews error upon error. Sample code is this:
import std.stdio;
import ddbc.drivers.sqliteddbc;
void main(){
SQLITEDriver driver = new SQLITEDriver();
writeln(SUCCESS);
}
Error spewed out is this:
hello.d|7|Error: undefined identifier SQLITEDriver|
I think Code::Blocks is importing the modules but not
detecting the modules. Been at it for a few hours now. Any
help?
Did you specify the configuration to use to dub?
dub -c SQLite
Yes. I've also linked the library to it.
Dub:
http://puu.sh/8DYrR.png
Code::Blocks Configuration:
http://puu.sh/8DYug.png
Ah ok. CodeBlocks does not integrate with dub.
Take a look in the dub.json file of ddbc and collect the
'versions' for the SQLite configuration (USE_SQLITE)
Add those 'versions' to the DMD commandline n codeblocks:
dmd.exe -version=USE_SQLITE -version=...
That did it! Thanks a lot.
Never knew Code::Blocks was stubborn with Dlang.
Re: throws Exception in method
On Thursday, 8 May 2014 at 13:06:05 UTC, amehat wrote: Okay. Thank you for these explanations, I understand a little better the exceptions D. Keep in mind that D also has the concept of Error. Both Exception and Error derive from Throwable. nothrow only means the function will not throw an *Exception*. Error can be thrown any time, from anywhere. They bypass the nothrow, bypass destructor cleanup, and fly past catch (Exception). An Error is basically: A critical Error has occurred. Salvage what you can before dying.
Re: [Rosettacode] D code line length limit
On Thu, May 08, 2014 at 01:59:58AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Thu, 08 May 2014 07:29:08 +
bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Jonathan M Davis:
ultimately, this sort of thing pretty much always ends up being
highly subjective.
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T)
{
...
}
But please put the const/immutable of methods on the right:
struct Foo {
void bar1() const {} // Good
const void bar2() {} // Bad
}
Well, that's one case where there's actually an objective reason to
put it on the right due to one of the flaws in the language - that
it's the one place that const inconsistently does not apply to the
type immediately to its right (though it's consistent with how
attributes are applied to the function itself - just not consistent
with variables).
Due to this flaw, I've stopped writing const T completely -- now I
only ever write const(T). Besides, there is also the ambiguity between
const(T)[] and const(T[]), so I regard writing const without parens
(const T[]) as a bad practice in D.
It's also because of this that I favor putting most attributes on the
right (though that's subjective, unlike with const). I only put
attributes on the left if they're on the left in C++ or Java (e.g.
static, public, or final). Everything else goes on the right.
[...]
Ditto. I think this is the closest we can come to consistency given the
current language.
T
--
My program has no bugs! Only undocumented features...
Re: Signals far from Slots
Thanks Ali, In the second part of that example I was hoping it was understood that Bar generates it's own signal. Sorry, I guess I wasn't clear; I was just trying to reduce code. I think maybe I'm really looking for a way that BarContainer doesn't have to know that Bar and Foo are connected. One way I used to do this was to have a central EventManager object that all other objects knew about and it would be the traffic cop for events. So you have the traditional Java type of Observer implementation and then listeners register with the EventManager saying that they are interested in a type of event while signalers send all their events to the EventManager. Since signals and slots are intended to have some advantage over the Java way, I wondered if there was a better way to handle the setting up of the connection. (Signals and slots decreases coupling of objects, but then some controller object needs to know about them enough to connect them.) Sorry, maybe this is the wrong place to ask such questions. I know there are plenty of forums for specific languages and APIs. But I don't know of any that just deal with general design, which is what I'd like to get better at. BTW, thanks for your D tutorial! It's a big help to me. Jim
Re: [Rosettacode] D code line length limit
On Thu, 8 May 2014 07:32:52 -0700
H. S. Teoh via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
On Thu, May 08, 2014 at 01:59:58AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Thu, 08 May 2014 07:29:08 +
bearophile via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com wrote:
Jonathan M Davis:
ultimately, this sort of thing pretty much always ends up being
highly subjective.
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T)
{
...
}
That's that I do with the params, but I'd still put the attributes to the
right of the last param rather than on their own line. I don't think that I'd
_ever_ put attributes on their own line. But as always, it's all quite
subjective, and everyone seems to prefer something at least slightly
different.
- Jonathan M Davis
DOSNEWSIZE Error
I had a compiler error with just a DOSNEWSIZE Error with no more information. Code: http://pastebin.com/UDAgmjtx I was trying to learn to implement SQLite connections to a local file with only the path to the file and no port or localhost nonesense from this : https://github.com/buggins/ddbc/wiki I tried a google search about the error but so far it landed me into a post with no replies, and various other non-D related posts.
Re: [Rosettacode] D code line length limit
H. S. Teoh:
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T)
{
...
}
You also need the prepost-conditions :-)
Bye,
bearophile
Re: Any chance to avoid monitor field in my class?
On Wed, 07 May 2014 10:44:55 -0400, Yuriy yuriy.gluk...@gmail.com wrote: Hello, is there a way of reducing size of an empty class to just vtbl? I tried to declare it as extern(C++) which works, but has a nasty side effect of limited mangling. The de-facto minimum size of a class is 16 bytes, due to the minimum block size of the heap. 8 bytes vtbl pointer on 64-bit systems would still allocate into 16-byte blocks. -Steve
Re: [Rosettacode] D code line length limit
On Thu, May 08, 2014 at 02:50:54PM +, bearophile via Digitalmars-d-learn
wrote:
H. S. Teoh:
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T)
{
...
}
You also need the prepost-conditions :-)
[...]
I actually had them in my first draft. :)
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T)
in {
assert(x = 0 x 5);
assert(y = 0 y 5);
assert(z = 0 z 5);
}
out(result)
{
assert(result[0] = 0 result[0] 5);
assert(result[1] = 1 result[1] 6);
assert(result[2] = 2 result[2] 7);
}
body
{
...
}
There. :)
T
--
You are only young once, but you can stay immature indefinitely. -- azephrahel
Re: [Rosettacode] D code line length limit
On Thursday, 8 May 2014 at 14:34:27 UTC, H. S. Teoh via
Digitalmars-d-learn wrote:
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T)
{
...
}
I like this one with only exception that I prefer to keep
parameter list to fill the line and always match brackets:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
int x, int y, int z, ExtraArgs extraArgs
)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T
)
{
}
for quick overview of parameters DDOC fits better IMHO
Re: throws Exception in method
On Thursday, 8 May 2014 at 14:02:06 UTC, monarch_dodra wrote: On Thursday, 8 May 2014 at 13:06:05 UTC, amehat wrote: Okay. Thank you for these explanations, I understand a little better the exceptions D. Keep in mind that D also has the concept of Error. Both Exception and Error derive from Throwable. nothrow only means the function will not throw an *Exception*. Error can be thrown any time, from anywhere. They bypass the nothrow, bypass destructor cleanup, and fly past catch (Exception). An Error is basically: A critical Error has occurred. Salvage what you can before dying. I do not know the mistakes, at least not as you speak. I just read on http://dlang.org/errors.html errors. You mean errors and exceptions are almost identical?
Re: static if (__ctfe)
On 05/07/2014 12:07 PM, Yuriy wrote:
On Wednesday, 7 May 2014 at 09:51:01 UTC, John Colvin wrote:
On Wednesday, 7 May 2014 at 09:47:20 UTC, Yuriy wrote:
Hello, is there any way to static if(__ctfe)? I want to declare class
members which are only available in ctfe. Thanx.
Sadly not as far as I know. What's the use-case? There may be a nice
solution none-the-less.
Well, i'm currently playing with std.variant so it can be ctfe-friendly.
And it works pretty much, however i need to use T.stringof.ptr/length
instead of typeid (typeid is ctfeable), and i'm not sure if it's good
for performance in runtime. So for type comparison i'd like to compare
TypeInfos in rt, and T.stringof in ct. Using both with rt if will likely
generate more code.
I'd suggest to just look into making typeid's comparable in CTFE.
I have grepped around DMD's source code a little bit, but I am not
familiar with it. (And I don't want to get involved in DMD development,
because the code base is horrid.)
If you add in ctfeexpr.c/isCtfeComparable the conjunct 'x-op !=
TOKsymoff' (which probably is a very blunt way of enabling typeid
comparisons and should be done more precisely), then you will notice
that comparisons now work but always return 'false' for some types. I
have attempted a fix for this for classes as follows in typinf.c:
TypeInfoDeclaration *TypeClass::getTypeInfoDeclaration(){
if(!sym-vclassinfo){
if (sym-isInterfaceDeclaration())
return TypeInfoInterfaceDeclaration::create(this); // still buggy!
else{
sym-vclassinfo = TypeInfoClassDeclaration::create(this);
}
}
return sym-vclassinfo;
}
I.e. the problem is that the frontend always creates new
TypeInfoDeclarations instead of reusing a single existing one.
After this, typeid comparisons appear to work correctly for classes at
least.
You might look into getting this fixed completely for all types (or at
least file a bug containing the above information.)
Re: [Rosettacode] D code line length limit
On Thu, May 08, 2014 at 03:13:48PM +, Dicebot via Digitalmars-d-learn wrote:
On Thursday, 8 May 2014 at 14:34:27 UTC, H. S. Teoh via Digitalmars-d-learn
wrote:
FWIW, for very long function signatures I write it this way:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
intx,
inty,
intz,
ExtraArgs extraArgs)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T)
{
...
}
I like this one with only exception that I prefer to keep parameter
list to fill the line and always match brackets:
const(T)[] myVeryLongFunction(T)(const(T)[] arr,
int x, int y, int z, ExtraArgs extraArgs
)
pure @safe nothrow
if (is(T : int)
someOtherLongCriteria!T
yetMoreVeryLongCriteria!T
)
{
}
for quick overview of parameters DDOC fits better IMHO
I find the hanging )'s rather jarring. But, it's subjective after all,
right? :)
One thing I haven't quite figured out, is what to do when there are many
of both compile-time and runtime-parameters. None of my usual formatting
techniques seem to produce a nice result; it always looks ambiguous:
Result myFunc(alias veryLongCompileTimeArgument,
alias anotherVeryLongCompileTimeArgument,
int compileTimeIntegerArgument)
(int runtimeArg1,
const(int)[] runtimeArg2,
int moreRuntimeArgs)
pure @safe nothrow
...
This is the best I can do, but I'm not very happy with it. One
alternative is:
Result myFunc(
alias veryLongCompileTimeArgument,
alias anotherVeryLongCompileTimeArgument,
int compileTimeIntegerArgument
)(
int runtimeArg1,
const(int)[] runtimeArg2,
int moreRuntimeArgs
)
pure @safe nothrow
in { ... }
out(result) { ... }
body
{
}
This doesn't look that great either. :-/
T
--
The fact that anyone still uses AOL shows that even the presence of options
doesn't stop some people from picking the pessimal one. - Mike Ellis
Re: throws Exception in method
On Thu, May 08, 2014 at 03:19:04PM +, amehat via Digitalmars-d-learn wrote: On Thursday, 8 May 2014 at 14:02:06 UTC, monarch_dodra wrote: [...] Keep in mind that D also has the concept of Error. Both Exception and Error derive from Throwable. nothrow only means the function will not throw an *Exception*. Error can be thrown any time, from anywhere. They bypass the nothrow, bypass destructor cleanup, and fly past catch (Exception). An Error is basically: A critical Error has occurred. Salvage what you can before dying. I do not know the mistakes, at least not as you speak. I just read on http://dlang.org/errors.html errors. You mean errors and exceptions are almost identical? What he meant, is that in D there are two kinds of throwables: Throwable /\ Exception Errors The 'nothrow' attribute means that the function will not throw an Exception. But it does not guarantee that it will not throw something else, like an AssertError (which is a subclass of Throwable but not a subclass of Exception). The intention is that normal exceptions must all inherit from class Exception. Exceptions represent recoverable problems that can be handled by catch blocks. Other Throwable subclasses, like Errors, represent non-recoverable problems with the program. E.g., AssertError means a wrong logic in the program was detected by an assert statement, so the program is in an inconsistent state that cannot be recovered from. So you should never catch an Error. Or if ever you do, you should make sure you terminate the program immediately afterwards. Also, note that some language guarantees will not hold when inside an Error catch block, so it's a bad idea to do anything other than emergency cleanup and then terminate the program. T -- Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard
Re: Any chance to avoid monitor field in my class?
On Thursday, 8 May 2014 at 14:57:37 UTC, Steven Schveighoffer wrote: The de-facto minimum size of a class is 16 bytes, due to the minimum block size of the heap. 8 bytes vtbl pointer on 64-bit systems would still allocate into 16-byte blocks. -Steve Yes, but still the question remains open for non-empty classes (e.g. want to use a 64bit useful payload), and for _emplacing_ any classes anywhere (e.g. on stack). Afaiu, there's no solution except for declaring extern(C++) (yes, i know, it's a hack), and it will not work, if a class is templated on something which can not be cpp-mangled. So the question is: is there any reason why this is not possible? I mean, maybe this question was closed long before. Also, do shared classes actually require monitors?
Re: Any chance to avoid monitor field in my class?
On Thu, 08 May 2014 13:21:07 -0400, Yuriy yuriy.gluk...@gmail.com wrote:
On Thursday, 8 May 2014 at 14:57:37 UTC, Steven Schveighoffer wrote:
The de-facto minimum size of a class is 16 bytes, due to the minimum
block size of the heap.
8 bytes vtbl pointer on 64-bit systems would still allocate into
16-byte blocks.
-Steve
Yes, but still the question remains open for non-empty classes (e.g.
want to use a 64bit useful payload), and for _emplacing_ any classes
anywhere (e.g. on stack).
To what end? What are you trying to save?
Afaiu, there's no solution except for declaring extern(C++) (yes, i
know, it's a hack), and it will not work, if a class is templated on
something which can not be cpp-mangled. So the question is: is there any
reason why this is not possible? I mean, maybe this question was closed
long before.
It would not be derived from Object, which has the field. In other words,
this would crash:
synchronized(cast(Object)obj) { ... }
Also, do shared classes actually require monitors?
Perhaps you meant unshared classes? No, they don't, but a monitor is only
allocated on demand, so you don't have to worry about it.
However, note that it is perfectly acceptable to cast to and from shared
as long as you guarantee the uniqueness of the reference. If the monitor
is not present, this can cause problems.
-Steve
Re: Any chance to avoid monitor field in my class?
On Thursday, 8 May 2014 at 17:49:01 UTC, Steven Schveighoffer
wrote:
To what end? What are you trying to save?
I'm trying to reimplement std.variant in a nice OOP way, that
supports CTFE, zero-size and a minimal amount of void*-casts. For
that i'm using my VariantPayload(T) class, which i want to be as
small as possible, as this is supposed to be an utility class
which you never know how will be used.
It would not be derived from Object, which has the field. In
other words, this would crash:
synchronized(cast(Object)obj) { ... }
Wouldn't cast(Object) return null here, so that synchronized will
throw or assert or smth? I see no reason for a crash.
Perhaps you meant unshared classes? No, they don't, but a
monitor is only allocated on demand, so you don't have to worry
about it.
Errm.. I'm not sure i understand the subject correctly, but
according to Alexandrescu's book, a class declared as shared does
not require synchronized() over it. I mean, it manages it's
synchronization inside itself, and it's user just has to trust
it. And if so, why ever synchronizing() on it?
Re: Any chance to avoid monitor field in my class?
On Thu, 08 May 2014 14:17:42 -0400, Yuriy yuriy.gluk...@gmail.com wrote:
On Thursday, 8 May 2014 at 17:49:01 UTC, Steven Schveighoffer wrote:
To what end? What are you trying to save?
I'm trying to reimplement std.variant in a nice OOP way, that supports
CTFE, zero-size and a minimal amount of void*-casts. For that i'm using
my VariantPayload(T) class, which i want to be as small as possible, as
this is supposed to be an utility class which you never know how will be
used.
Well, I don't think I know enough to judge whether what you are doing is
worthwhile...
But my question more was about where do you plan to put so many of these
objects that you will save a significant amount of bytes, aside from the
heap (which already uses 16-byte blocks).
It would not be derived from Object, which has the field. In other
words, this would crash:
synchronized(cast(Object)obj) { ... }
Wouldn't cast(Object) return null here, so that synchronized will throw
or assert or smth? I see no reason for a crash.
Then what is this object? All D objects derive from Object.
Perhaps you meant unshared classes? No, they don't, but a monitor is
only allocated on demand, so you don't have to worry about it.
Errm.. I'm not sure i understand the subject correctly, but according to
Alexandrescu's book, a class declared as shared does not require
synchronized() over it. I mean, it manages it's synchronization inside
itself, and it's user just has to trust it. And if so, why ever
synchronizing() on it?
The meaning of shared is not well defined. Even TDPL is outdated on this.
The idea in the book is that shared types would use memory barriers to
ensure correct ordering of access, and correct data access. But it does
not prevent races for multiple threads, you still need synchronized.
Unshared objects, on the other hand, should not ever need synchronization
tools, since only one thread has access!
-Steve
Re: CMake for D
On Monday, 24 March 2014 at 23:55:14 UTC, Dragos Carp wrote: I moved cmaked2 to github [1], updated and simplified the usage a little (system cmake patch not necessary anymore). You can give it a try. Dub registry support is also on the way. [1] - https://github.com/dcarp/cmake-d Verified tested and working on CentOS 6.5 with cmake28 package from epel repository. Thanks! -- Chris
Re: Any chance to avoid monitor field in my class?
But my question more was about where do you plan to put so many
of these objects that you will save a significant amount of
bytes, aside from the heap (which already uses 16-byte blocks).
Hm.. Stack/emplace, arrays, n-dimensional arrays? :) Besides, if
we're talking of D as a system language to replace C++ and to
scratch everything out of a silicon wafer (also think of embedded
platforms here), it's crucial for me to be able to control such
things. From my experience, in a 5000-class project you would
have about 20 classes that need to be synchronized on. Moreover,
mutex synchronization is not in fashion nowadays, as we tend to
use transitional synchronization. And so my 4980 classes will
contain an extra field i don't use. What?? =)
It would not be derived from Object, which has the field. In
other words, this would crash:
Those are your words.
Then what is this object? All D objects derive from Object.
Those are your words also =)
The meaning of shared is not well defined. Even TDPL is
outdated on this.
The idea in the book is that shared types would use memory
barriers to ensure correct ordering of access, and correct data
access. But it does not prevent races for multiple threads, you
still need synchronized.
Yes, i understand that. By implementing a shared class, you're on
your own with syncing, but also you tell the user, that your
class doesn't need to be synchronized on. Right?
Unshared objects, on the other hand, should not ever need
synchronization tools, since only one thread has access!
Here's two use-cases.
class A {}
shared class B {}
// Somewhere in code
{
shared A sharedA; // This would need synchronized() on access.
A unsharedA; // This would not. But since, the class is
defined as unshared, we still will have __monitor in it, and that
is good, since we can cast between unshared A and shared A.
B b;
shared B sharedB; // Here in both cases we know, that we will
never need to sync on b or sharedB, as both of those are thread
safe (it's not our business, how they do it, but they kinda
are). So do we need this __monitor, which will never be used
actually?
}
Re: Any chance to avoid monitor field in my class?
On Thu, 08 May 2014 15:47:46 -0400, Yuriy yuriy.gluk...@gmail.com wrote:
But my question more was about where do you plan to put so many of
these objects that you will save a significant amount of bytes, aside
from the heap (which already uses 16-byte blocks).
Hm.. Stack/emplace,
How many of these? In order to justify saving 8 bytes per instance, you
have have a lot. I don't see emplacing thousands or tens of thousands of
objects on the stack.
arrays, n-dimensional arrays?
Arrays of objects are stored as arrays of object references, with each one
pointing at a separate block on the heap.
:) Besides, if we're talking of D as a system language to replace C++
and to scratch everything out of a silicon wafer (also think of embedded
platforms here), it's crucial for me to be able to control such things.
From my experience, in a 5000-class project you would have about 20
classes that need to be synchronized on. Moreover, mutex synchronization
is not in fashion nowadays, as we tend to use transitional
synchronization. And so my 4980 classes will contain an extra field i
don't use. What?? =)
In D, class is not used for such things, struct is.
It would not be derived from Object, which has the field. In other
words, this would crash:
Those are your words.
I'm assuming you want D classes, but without the monitor object. D classes
derive from Object.
Then what is this object? All D objects derive from Object.
Those are your words also =)
Any chance to avoid monitor field in my class? Those are your words.
What is it that you want?
The meaning of shared is not well defined. Even TDPL is outdated on
this.
The idea in the book is that shared types would use memory barriers to
ensure correct ordering of access, and correct data access. But it does
not prevent races for multiple threads, you still need synchronized.
Yes, i understand that. By implementing a shared class, you're on your
own with syncing, but also you tell the user, that your class doesn't
need to be synchronized on. Right?
A defined shared class I think is supposed to imply that all its methods
are shared (meaning the 'this' pointer must be shared). It does not imply
that they are thread safe.
Unshared objects, on the other hand, should not ever need
synchronization tools, since only one thread has access!
Here's two use-cases.
class A {}
shared class B {}
// Somewhere in code
{
shared A sharedA; // This would need synchronized() on access.
A unsharedA; // This would not. But since, the class is defined as
unshared, we still will have __monitor in it, and that is good, since we
can cast between unshared A and shared A.
B b;
shared B sharedB; // Here in both cases we know, that we will never
need to sync on b or sharedB, as both of those are thread safe (it's
not our business, how they do it, but they kinda are). So do we need
this __monitor, which will never be used actually?
}
shared != thread safe. You still need to synchronize
-Steve
dxl (the d port of jexcelapi)
So i was thinking i wonder if anyone has a d library for excel and behold there it was. however, it seems like d has grown since this was written. I'm getting bunches of errors telling me that i can't override a function without the override keyword. which is not a big deal, however I seem to be missing libraries. std.date; cannot be found :( is this equivalent to std.datetime? dcollections.LinkList; I found it but should i use It? is there not something in std.containers; that would replace it?
Re: Any chance to avoid monitor field in my class?
On Wednesday, 7 May 2014 at 14:44:57 UTC, Yuriy wrote: Hello, is there a way of reducing size of an empty class to just vtbl? I tried to declare it as extern(C++) which works, but has a nasty side effect of limited mangling. Just a general FYI: Classes are relatively heavyweight in D. struct-based approaches are often favoured, as can be seen across the more heavily developed parts of phobos.
Re: dxl (the d port of jexcelapi)
By the way the weblink is: http://www.dsource.org/projects/dexcelapi
Re: Any chance to avoid monitor field in my class?
How many of these? In order to justify saving 8 bytes per instance, you have have a lot. I don't see emplacing thousands or tens of thousands of objects on the stack. Ok, i guess i have to agree with you. But. Why are you protecting __monitors so eagerly? :) Arrays of objects are stored as arrays of object references, with each one pointing at a separate block on the heap. Or again you can emplace them in the heap, so that they occupy a continuous chunk. In D, class is not used for such things, struct is. But classes have vtbls which is an ultimate feature for me, and moreover, it works in ctfe, while reinventing vtbls for ctfe might be a challenging task. I'm assuming you want D classes, but without the monitor object. D classes derive from Object. Any chance to avoid monitor field in my class? Those are your words. What is it that you want? Thats right. I was saying that extern(C++) almost suits me except for it's mangling. And you said that extern(C++) classes are not derived from Object? But still such objects would have RTTI which will forbid casting to Object, wouldn't they? shared != thread safe. You still need to synchronize Ok. So shared class is not a reason to omit __monitor field, as it still can be used, am i right here?
Re: Any chance to avoid monitor field in my class?
Yuriy: But. Why are you protecting __monitors so eagerly? :) Also take a look at the Rust language, that avoids some of your problems :-) Bye, bearophile
Re: DOSNEWSIZE Error
On Thursday, 8 May 2014 at 14:49:09 UTC, Jack wrote: I had a compiler error with just a DOSNEWSIZE Error with no more information. Code: http://pastebin.com/UDAgmjtx I was trying to learn to implement SQLite connections to a local file with only the path to the file and no port or localhost nonesense from this : https://github.com/buggins/ddbc/wiki I tried a google search about the error but so far it landed me into a post with no replies, and various other non-D related posts. Optlink error. Are you builing a x86_32 exe or x86_64 exe? when 32 bits use the dmd -m32 and make sure to use omf libs. when 64 bits don not use optlink but MS VS link.exe and use coff libs.
Re: dxl (the d port of jexcelapi)
On Thursday, 8 May 2014 at 21:02:05 UTC, Taylor Hillegeist wrote: By the way the weblink is: http://www.dsource.org/projects/dexcelapi That will need some work before it works with modern D.
Re: Any chance to avoid monitor field in my class?
Also take a look at the Rust language, that avoids some of your problems :-) Done already =). Rust is great, but I like D, and i strongly believe it's the next big language. If only it could allow a bit more tweaks ;)
Re: Any chance to avoid monitor field in my class?
On Thu, 08 May 2014 17:05:56 -0400, Yuriy yuriy.gluk...@gmail.com wrote: How many of these? In order to justify saving 8 bytes per instance, you have have a lot. I don't see emplacing thousands or tens of thousands of objects on the stack. Ok, i guess i have to agree with you. But. Why are you protecting __monitors so eagerly? :) I'm not, I'm trying to help you justify the path your taking :) Because where it's currently leading is somewhere that D doesn't support. This means in order to support it, you have to maintain a parallel compiler, or somehow convince the compiler writers to add such support. Neither of these burdens is small. Arrays of objects are stored as arrays of object references, with each one pointing at a separate block on the heap. Or again you can emplace them in the heap, so that they occupy a continuous chunk. This is not a good idea. The dtors of classes in the GC is stored per block, not per chunk of a block. In D, class is not used for such things, struct is. But classes have vtbls which is an ultimate feature for me, and moreover, it works in ctfe, while reinventing vtbls for ctfe might be a challenging task. Removing the monitor could also prove quite challenging. I don't doubt your reasons, but then again, you have what you have right now in D. Asking for more, you have to provide it, or convince others to. If it's the latter, you need to make a very very strong case. I'm assuming you want D classes, but without the monitor object. D classes derive from Object. Any chance to avoid monitor field in my class? Those are your words. What is it that you want? Thats right. I was saying that extern(C++) almost suits me except for it's mangling. And you said that extern(C++) classes are not derived from Object? But still such objects would have RTTI which will forbid casting to Object, wouldn't they? extern(C++) objects are not considered D objects. A D object can implement a C++ interface, but once you get to the C++ interface, you cannot go back. This sounds to me very different from your goal. -Steve
Re: Any chance to avoid monitor field in my class?
I don't doubt your reasons, but then again, you have what you have right now in D. Asking for more, you have to provide it, or convince others to. If it's the latter, you need to make a very very strong case. I want to provide it, but before i do, i want to know if there were any decisions made earlier, that would render my work useless. I mean, i have to know all possible cons for not having __monitor in an instance. What i suggest is the following: - Object does not have any __monitor field by default. - One can add a __monitor object to his class. - Offset to monitor is stored in TypeInfo. -1 if doesn't exist. - synchronized() inspects typeInfo. If an object has monitor, then it is used. Otherwise, the monitor is allocated/looked up in a global hash-table from object pointer to monitor. This way we could achieve performance in terms of both speed and memory. Also old code would not break. Some additional optimizations might always include a __monitor field to a class, if compiler can prove, that this class is being synchronized on.
Down the VisualD0.3.38-1.exe ,found virus!
Hi,everyone, down VisulaD from http://rainers.github.io/visuald/visuald/StartPage.html found the virus:Win32.Troj.Undef.(kcloud) Why? Frank
Re: DOSNEWSIZE Error
On Thursday, 8 May 2014 at 21:10:34 UTC, Arjan wrote: On Thursday, 8 May 2014 at 14:49:09 UTC, Jack wrote: I had a compiler error with just a DOSNEWSIZE Error with no more information. Code: http://pastebin.com/UDAgmjtx I was trying to learn to implement SQLite connections to a local file with only the path to the file and no port or localhost nonesense from this : https://github.com/buggins/ddbc/wiki I tried a google search about the error but so far it landed me into a post with no replies, and various other non-D related posts. Optlink error. Are you builing a x86_32 exe or x86_64 exe? when 32 bits use the dmd -m32 and make sure to use omf libs. when 64 bits don not use optlink but MS VS link.exe and use coff libs. -m32 did the trick. Thanks again
Re: Down the VisualD0.3.38-1.exe ,found virus!
On Friday, 9 May 2014 at 01:02:39 UTC, FrankLike wrote: Hi,everyone, down VisulaD from http://rainers.github.io/visuald/visuald/StartPage.html found the virus:Win32.Troj.Undef.(kcloud) Why? Frank Most probably a false positive. What antivir do you use?
Re: Down the VisualD0.3.38-1.exe ,found virus!
Most probably a false positive. What antivir do you use? http://www.ijinshan.com/duba/newduba.shtml
vibe.d's example is good,but Memory Usage is bigger than beeblog?
I build the vibe.d's example: http-server-example,the exe's size is 5M ,it's very good, is better than go's beeblog,the beeblog's size is 12M. I very like D,but the Memory Usage is bigger than go's exe. http-server-example.exe's Memory Usage is 3.5M,but the beeblog's Memory Usage is 2.5M,I don't believe it,really? I very hope vibe.d should have a lowwer Memory Usage than go's exe's. Like D. Frank
Re: vibe.d's example is good, but Memory Usage is bigger than beeblog?
The form-interface-example.exe's Memory Usage is 3.5M,if have some error,then Memory Usage is 6.7M,if error is closed,the Memory Usage keeps in 6.7M ,until you close the exe. the error :such as '500 - Internal Server Error Internal Server Error Internal error information: object.Exception@..\..\source\vibe\http\form.d(234): No method found that matches the found form data: Overload addUser(vibe.http.server.HTTPServerRequest,vibe.http.server.HTTPServerResponse,immutable(char)[],immutable(char)[],immutable(char)[]) failed: ' Like D. Frank
How to use 'Heat the compiler' to vibe.d?
How to use 'Heat the compiler' to vibe.d? If you can not stop the exe ,how to do? Thank you. Frank
Re: Down the VisualD0.3.38-1.exe ,found virus!
On Friday, 9 May 2014 at 01:02:39 UTC, FrankLike wrote: Hi,everyone, down VisulaD from http://rainers.github.io/visuald/visuald/StartPage.html found the virus:Win32.Troj.Undef.(kcloud) Why? Frank I've been using VisualD for a long time without problems. If it makes you nervous, you can get the source from Github and compile it yourself.
Re: __traits with alias
On Thursday, 8 May 2014 at 07:33:34 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: A workaround is to wrap it into another template, to 'hide' __traits. Like this: alias Alias(alias a) = a; // A bit circular, I know. Oh, thank you. I think there is bug report / enhancement for this. I find it a bit annoying, since aliasing a __traits expression is quite common. This one https://issues.dlang.org/show_bug.cgi?id=7804, I believe.
Re: Down the VisualD0.3.38-1.exe ,found virus!
On Friday, 9 May 2014 at 01:02:39 UTC, FrankLike wrote: Hi,everyone, down VisulaD from http://rainers.github.io/visuald/visuald/StartPage.html found the virus:Win32.Troj.Undef.(kcloud) Why? Frank https://www.virustotal.com/en/file/bbd76ddb41a80f0526f6cf1e37a2db2736cfa8f29ed3f5fd7a4336bf4c8bbe43/analysis/ Just 5 of 52. Probably a false alarm.
