digitalmars-d@puremagic.com
Craig Black wrote:
In C++ I could to the following:
Vector3 cross(const Vector3 &a, const Vector3 &b) { ... }
and then call it like this:
Vector3 a, b, c;
a = cross(b, c);
a = cross(b-a, c-a);
But in D I have to define two functions if I want pass by reference to
work:
Vector3 cross(ref const Vector3 a, ref const Vector3 b) {...}
Vector3 cross(Vector3 a, Vector3 b) {...}
Isn't const for that (without ref)?
Vector3 cross(const Vector3 a, const Vector3 b) {...}
In this case, compiler should pass const by reference (since it will not
change).
digitalmars-d@puremagic.com
Jonathan M Davis wrote:
On Friday, December 10, 2010 14:31:34 Piotr Szturmaj wrote:
Craig Black wrote:
In C++ I could to the following:
Vector3 cross(const Vector3&a, const Vector3&b) { ... }
and then call it like this:
Vector3 a, b, c;
a = cross(b, c);
a = cross(b-a, c-a);
But in D I have to define two functions if I want pass by reference to
work:
Vector3 cross(ref const Vector3 a, ref const Vector3 b) {...}
Vector3 cross(Vector3 a, Vector3 b) {...}
Isn't const for that (without ref)?
Vector3 cross(const Vector3 a, const Vector3 b) {...}
In this case, compiler should pass const by reference (since it will not
change).
The compiler doesn't just make things references. You have to tell it to. If you
have a const parameter which is a value type, it's just going to be a const
local variable. It's not going to be a reference to anything no matter what that
means for efficiency (though structs are supposedly supposed to be cheap to
copy).
Now, if Vector3 were a class, then it's always a reference. But that's because
it's a reference type.
- Jonathan M Davis
Thank you for your explanations, I'm just learning D2. However, I meant
something different: passing by reference was not strict ref in my mind,
but some kind of address passing.
This is done in Pascal/Delphi for more than decade. Variables passed as
const parameters, are passed by address, to improve efficency, even if
they're value types. Of course smaller builtin types like 32 bit integer
doesn't get much advance. Const is supposed to be used with Vector3-like
structs with floating point coordinates (12 bytes float, 24 bytes
double), where it's better to not copy. Feel free to read first answer
to this post:
http://stackoverflow.com/questions/1600991/are-there-any-advantages-in-using-const-parameters-with-an-ordinal-type
Question is, if const parameters works similarly in D2?
Re: renamepalooza time
ljustify -> leftJustify rjustify -> rightJustify stripl -> leftStrip stripr -> rightStrip I suggest it should be rather justifyLeft/Right and stripLeft/Right. It's easier to read and it works better with code completion.
Re: Can your programming language do this?
Hi, I'm also working on postgresql client implementation and common DB
interface (in my spare time between other projects). It's using native
postgres protocol without using libpq. Tt also supports binary
formatting of row fields - that should outperform textual libraries (no
parsing/toString).
I already have working postgresql row querying. There are typed and
untyped rows. Untyped row is DBRow!(Variant[]), typed rows are
encapsulated using struct or tuple, for example:
PGConnection conn = new PGConnection;
conn.open([
"host" : "localhost",
"database": "test",
"user" : "postgres",
"password" : "postgres"
]);
auto cmd = new PGCommand(conn, "SELECT typname, typlen FROM pg_type");
struct S { string s; short l; }
auto result = cmd.executeQuery!(Tuple!(string, "s", short, "l"))();
auto result = cmd.executeQuery!S();
// those above two lines are equivalent
foreach (i, row; result)
{
// row is DBRow!Tuple or DBRow!S
writeln(i, " - ", row.s, ", ", row.l);
}
I've also written simple ORM mapping - creating and managing tables
based on struct layout. I see your solution is in opposite - creating
structs/classes based on SQL CREATE scripts.
Maybe we could join our efforts and create kind of hybrid DB library? :)
Re: Can your programming language do this?
Adam Ruppe wrote:
string name;
int id;
db_statement.execute();
while(db_statement.next(id, name)) {
// the variables id and name are now filled in with the row
}
That's nice too!
But, a real database has a lot of constraints on top of that -
field lengths, foreign keys, checks, and so on.
I tried two approaches: one was magic. Add stuff based on the names
and types, so assume "int id" is a primary key, for example.
Didn't work in practice. What about a table with a primary key
that spans two columns?
So, then I tried adding a bunch of attributes and templates, but
that felt like a buggy and incomplete SQL forced into D... didn't
feel like natural SQL nor D.
What approach did you take? I wonder if I didn't get anywhere because
I'm just so set in my old ways!
Please read my messages in "D2 postgresql interface - Phobos2?" thread
(D.learn). There are examples of structs with arrays (postgres supports
them); primary, unique and foreign keys. I've also managed to generate
D's enums using CREATE TYPE in postgres :)
Maybe we could join our efforts and create kind of hybrid
DB library? :)
Indeed. Is your code on the internet somewhere?
Not yet. First, I must clean it from some messed up code :) Then I plan
to publish it on github under Boost license.
Re: Can your programming language do this?
Andrew Wiley wrote:
I know I keep beating this horse, but in other languages, this is the
textbook example for why annotations are useful. Adding metadata to
code, even if it can only be examined at compile time, can be immensely
useful.
I fully agree. However, I did create some substitute:
struct City
{
Serial!int id; // auto increment
string name;
mixin PrimaryKey!(id);
mixin Unique!(name);
}
but still, legal attributes such as .NET ones would be more appreciated.
Re: Should we have an Unimplemented Attribute?
Andrej Mitrovic wrote:
We know what a Deprecated Attribute is for:
http://www.digitalmars.com/d/2.0/attribute.html#deprecated.
You can use a compiler switch to enable using these:
-d
allow deprecated features
But what about structs/classes/functions/etc which are partially
implemented, but still unusable? Marking them with deprecated doesn't
make sense, as this will likely confuse both the user and the library
writers. Would it be overkill to introduce a new attribute?
The idea came after I've spent some good time trying to get druntime's
getMembers function to work in my code, only to find out from this NG
that it's not properly implemented.
Discuss?
In C# there is NotImplementedException for that.
public class A
{
public int foo()
{
throw new NotImplementedException();
}
}
I see people ask for new attributes. Why not add user defined attributes
into language? C# has custom attributes and Java has custom annotations.
Custom attributes could be just classes (as in C#):
class GuidAttribute : Attribute
{
string guid;
this(string guid)
{
this.guid = guid;
}
}
used like this (COM interfaces):
@Guid("48eecd81-35d7-4d4e-9ab8-479a38713053")
interface MyInterface
{
byte foo();
ulong bar();
}
or used for ORM:
@DBTable("users")
struct UserRow
{
@NotNull string username;
@NotNull string password
ubyte age;
}
There would be also need for some method to enumerate those attributes
at compile time/run time. We already have that possibility for
predefined attributes.
Re: High performance XML parser
Tomek Sowiński wrote:
I am now intensely accumulating information on how to go about creating a
high-performance parser as it quickly became clear that my old one won't
deliver. And if anything is clear is that memory is the key.
One way is the slicing approach mentioned on this NG, notably used by RapidXML.
I already contacted Marcin (the author) to ensure that using solutions inspired
by his lib is OK with him; it is. But I don't think I'll go this way. One
reason is, surprisingly, performance. RapidXML cannot start parsing until the
entire document is loaded and ready as a random-access string. Then it's
blazingly fast but the time for I/O has already elapsed. Besides, as Marcin
himself said, we need a 100% W3C-compliant implementation and RapidXML isn't
one.
I think a much more fertile approach is to operate on a forward range, perhaps
assuming bufferized input. That way I can start parsing as soon as the first
buffer gets filled. Not to mention that the end result will use much less
memory. Plenty of the XML data stream is indents, spaces, and markup -- there's
no reason to copy all this into memory.
To sum up, I belive memory and overlapping I/O latencies with parsing effort
are pivotal.
Please comment on this.
Few years ago I needed to write my own parser in Delphi for my XMPP
(Jabber) client and server. In XMPP you get socket-streamed XML document
with xml elements as protocol messages ("XMPP stanzas").
The problem I had was no Delphi parser had hybrid support of SAX/DOM,
i.e. I wanted to parse xml nodes like SAX, but when I received whole
message then I wanted to return it as XML Element (like in DOM). This
way I could easily process incoming messages - now it's accomplishable
with pull parsers.
I think std needs both SAX/pull and DOM parsers. For DOM, if whole
document is in memory, maybe this approach could be advantageous:
http://en.wikipedia.org/wiki/VTD-XML
http://vtd-xml.sourceforge.net/
Re: Integer conversions too pedantic in 64-bit
spir wrote: Rename size-t, or rather introduce a meaningful standard alias? (would vote for Natural) Maybe ptrint and ptruint?
Re: Integer conversions too pedantic in 64-bit
spir wrote: On 02/15/2011 03:44 AM, Piotr Szturmaj wrote: spir wrote: Rename size-t, or rather introduce a meaningful standard alias? (would vote for Natural) Maybe ptrint and ptruint? If ptr means pointer, then it's wrong: size-t is used for more than that, I guess. Strangely enough, while "size" may suggest it, .length does not return a size_t but an uint. ptr prefix shows that int/uint depends on CPU word (32/64 bit), i.e. they have the same size as pointer. However, it may led to confusion, which type - signed or unsigned - is right for the job.
Re: Why can't structs be derived from?
Ary Manzana wrote:
Syntax matters. A lot. Which one is more readable/understandable?
struct Point2 {
int x;
int y;
}
1.
struct Point3 {
Point2 point2;
alias this point2;
int z;
}
2.
struct Point3 : Point2 {
int z;
}
You can't deny this last one is much more easier to understand and it
exactly does what your mind want to do: just give me what's in the other
struct and let me add more things.
The compiler can implement this using alias this and making the aliased
member private, and possibly disallowing adding another alias this.
Alias this gives you more power in case of struct serialization. You can
place new fields before or after "inherited" struct, or even on both
sides. In your 2nd case, z will be always after x and y.
Re: [GSOC] Database API
Christian Manning wrote:
Hi,
I'm a second year student at De Montfort University studying Computer
Science. I am very much interested in working on the database API idea
that is proposed at
http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas#DatabaseAPI (I was
also quite interested in the containers idea, but it looks like someone
else wants to do that)
I have limited experience with database libraries but have begun to
study the JDBC API (in my small amount of spare time only as term
doesn't finish for another 2 weeks for me and I still have assignments).
Has this idea/project been assigned a mentor? I'd like to ask them and
the list, what's the best thing for me to do right now to prepare for this?
Thanks
Chris
I'm at finishing stage of my PostgreSQL client, written entirely in D. I
will post sources in few days.
Before adding database support to Phobos, there are few important issues
which obviously need further discussion. One of this issues are handling
NULL values - essential thing in relational databases.
Although, there were some efforts to introduce standard Nullable or
Optional type, they were aborted.
Currently I'm using this simple definition:
struct Nullable(T)
{
Algebraic!(T, void*) Nullable;
alias Nullable this;
bool hasValue()
{
return cast(bool)Nullable.peek!(T);
}
bool isNull()
{
return cast(bool)!Nullable.peek!(T);
}
string toString()
{
T* t = Nullable.peek!T;
return t ? to!string(*t) : "null";
}
}
It flawlessy cooperates with Variant, which - I think - should
officially support nulls as well. I would propose that standard Nullable
type, should be a subtype of Algebraic union as above.
During writing my PostgreSQL interface, I also had some problems with
Variant and std.conv.to functions. Currently std.conv doesn't support
Variants, f.i. when using to!Variant(5), there are more than one toImpl
match.
In case of DB api, Variants are also essential, because field types
returned by database server aren't known at compile time.
To sum up, Phobos need some additional changes for database support,
mainly addition of Nullable.
Re: [GSOC] Database API
Kagamin wrote:
Christian Manning Wrote:
On 25/03/2011 14:56, Piotr Szturmaj wrote:
To sum up, Phobos need some additional changes for database support,
mainly addition of Nullable.
For now, couldn't this just be included with the database module?
Why not just use Variant? It should be able to hold anything, so Nullable
should be not needed.
I think it should, for the same reason. Many times you want more
constrained data type than Variant. Say, some interface expect int or
null. Nullable!int is perfect for it. But if you use Variant, you may
end up having some struct inside or maybe some string, like 'abc' :)
In other words, base type of Nullable (for example int) is enforceable
at compile time, unlike Variant.
Anyway my probosal is compatible with Variant. Variant is an alias for
backend type VariantN. Quote from std.variant:
"VariantN is a back-end type seldom used directly by user code. Two
commonly-used types using VariantN as back-end are:
Algebraic: A closed discriminated union with a limited type universe
(e.g., Algebraic!(int, double, string) only accepts these three types
and rejects anything else).
Variant: An open discriminated union allowing an unbounded set of types.
The restriction is that the size of the stored type cannot be larger
than the largest built-in type. This means that Variant can accommodate
all primitive types and all user-defined types except for large structs.
Both Algebraic and Variant share VariantN's interface. (See their
respective documentations below.)"
I propose that, Nullable should be an alias (or subtype) of Algebraic,
for example:
template Nullable(T)
{
alias Algebraic!(T, void*) Nullable;
}
This way it will share the same backend as Variant, so both types will
be compatible.
Re: [GSOC] Database API
Christian Manning wrote: On 25/03/2011 14:56, Piotr Szturmaj wrote: To sum up, Phobos need some additional changes for database support, mainly addition of Nullable. For now, couldn't this just be included with the database module? Yes. I think, currently this is the only option.
Re: [GSOC] Database API
Kagamin wrote: Robert Jacques Wrote: Should be Algebraic!(T, void). If that doesn't currently compile, we should make it compile. Andrei For what it's worth, both Algebraic!(T, void*) and Algebraic!(T, void) compile on my branch of std.variant. can't assign null alias Algebraic!(int,void) nint; nint n1=5; assert(n1==5); n1=null; \std\variant.d:497: Error: static assert "Cannot store a void* in a VariantN!(maxSize,int,void). Valid types are (int, void)" test.d:45:instantiated from here: opAssign!(void*) Yes, compiler qualifies null as void*. I was playing with void* version few weeks ago and I can confirm that both assignment and equality testing works for nulls. One thing I missed was lack of conversion to string "null". For example array of Algebraic!(int, void*) was printed as [0, 0, 2], when element 1 was null. I think it should rather be [0, null, 2].
Re: A case for valueless AA's?
Andrej Mitrovic wrote:
1. I'm wasting memory. I don't need the values, I only need the keys. But I
can't declare a void[string] hash.
But I don't know how to get rid of the values, which leaves the issue #1.
Maybe static array of zero length? From documentation:
"A static array with a dimension of 0 is allowed, but no space is
allocated for it. It's useful as the last member of a variable length
struct, or as the degenerate case of a template expansion."
And this code works:
void[0][string] aa;
aa["key"] = [];
assert("key" in aa);
But anyway, I feel that dedicated HashSet container would be more
appropriate.
Re: Asynchronicity in D
Max Klyga wrote: I've been thinking on things I can change in my GSoC proposal to make it stronger and noticed that currently Phobos does not address asynchronous I/O of any kind. A number of threads on thid newsgroup mentioned about this problem or shown ways other languages address asynchronicity. I want to ask D community about plans on asynchronicity in Phobos. Did somenone in Phobos team thought about possible design? How does asynchronicity stacks with ranges? What model should D adapt? etc. Yes, asynchronous networking API would be more scalable. If you're collecting information about async IO, please take a look at libevent and libev, also NT's completion ports, FreeBSD's kqueue and Linux epoll. Protocols implemented using event-driven APIs should scale to thousands of connections using few working threads. Moreover async protocols could be wrapped to be synchronous (but not other way around) and used just like well known blocking API's. Basically, while using async IO, you request some data to be written and then wait for completion event (usually by callback function). Then you request some allocated buffer to be read and then you wait until network stack fills it up. You do not wait for blocking operation like with using send() or recv(), instead you may do some useful processing between events.
Re: Asynchronicity in D
dsimcha wrote: == Quote from Piotr Szturmaj (bncr...@jadamspam.pl)'s article Max Klyga wrote: I've been thinking on things I can change in my GSoC proposal to make it stronger and noticed that currently Phobos does not address asynchronous I/O of any kind. A number of threads on thid newsgroup mentioned about this problem or shown ways other languages address asynchronicity. I want to ask D community about plans on asynchronicity in Phobos. Did somenone in Phobos team thought about possible design? How does asynchronicity stacks with ranges? What model should D adapt? etc. Yes, asynchronous networking API would be more scalable. If you're collecting information about async IO, please take a look at libevent and libev, also NT's completion ports, FreeBSD's kqueue and Linux epoll. Protocols implemented using event-driven APIs should scale to thousands of connections using few working threads. Moreover async protocols could be wrapped to be synchronous (but not other way around) and used just like well known blocking API's. Basically, while using async IO, you request some data to be written and then wait for completion event (usually by callback function). Then you request some allocated buffer to be read and then you wait until network stack fills it up. You do not wait for blocking operation like with using send() or recv(), instead you may do some useful processing between events. Forgive any naiveness here, but isn't this just a special case of future promise parallelism? Using my proposed std.parallelism module: auto myTask = task(&someNetworkClass.recv); // Use a new thread, but this could also be executed on a task // queue to keep the number of threads down. myTask.executeInNewThread(); // Do other stuff. auto recvResults = myTask.yieldWait(); // Do stuff with recvResults If I understand correctly (though it's very likely I don't since I've never written any serious networking code before) such a thing can and should be implemented on top of more general parallelism primitives rather than being baked directly into the networking design. Asynchronous tasks are great thing, but async networking IO aka overlapped IO is something different. Its efficency comes from direct interaction with operating system. In case of tasks you need one thread for each task, whereas in overlapped IO, you just request some well known IO operation, which is completed by the OS in the background. You don't need any threads, besides those which handle completion events. Here is a good explanation of how it works in WinNT: http://en.wikipedia.org/wiki/Overlapped_I/O
Re: A few thoughts on the existing GSoC student proposals
Andrei Alexandrescu wrote: 4. Database API This is a high impact item. I'd need to collect more information about the specifics of the application before creating an opinion about its chances of success. I see Piotr and others have some related ideas; I suggest them to apply appropriately (either as mentors or students). A solid mentor(s)/student(s) combo is a key ingredient of a successful project. Thanks, Andrei I do not feel very strong as a mentor and I'm not a student, so I'd rather not apply. However, I'll certainly try to help with this item :)
Re: A few thoughts on the existing GSoC student proposals
Christian Manning wrote: On 31/03/2011 18:30, Piotr Szturmaj wrote: Andrei Alexandrescu wrote: 4. Database API This is a high impact item. I'd need to collect more information about the specifics of the application before creating an opinion about its chances of success. I see Piotr and others have some related ideas; I suggest them to apply appropriately (either as mentors or students). A solid mentor(s)/student(s) combo is a key ingredient of a successful project. Thanks, Andrei I do not feel very strong as a mentor and I'm not a student, so I'd rather not apply. However, I'll certainly try to help with this item :) That would be much appreciated, especially your PostgreSQL client. I think the end goal of a database module for Phobos should be to have native D clients for the more popular (R)DBMSs. I'm in the process of drafting my proposal which I'll post to this ng once done. Ok, I feel I should post my code earlier, even if it's not finished yet, so you can take a look as soon as possible. I think you may find some of my ideas useful so maybe you'll want to throw them into your proposal.
Re: A few thoughts on the existing GSoC student proposals
simendsjo wrote: Piotr Szturmaj: I think the end goal of a database module for Phobos should be to have native D clients for the more popular (R)DMBSs. Isn't both a large undertaking as well as difficult to keep in sync with the reference implementations? I think wrapping the c libs would make everything less fragile. For some RDBMSes it may be difficult, but PostgreSQL's network protocol is very well documented and stable since version 7.4 (late 2003).
