I like the C# syntax:
listOfFoo.Where(x => x.size > 10);
even better if you could have this syntax (but perhaps it won't work):
listOfFoo.Where((x) x.size > 10);
I would be nice to have that in D
I like the C# syntax:
listOfFoo.Where(x => x.size > 10);
even better if you could have this syntax (but perhaps it won't work):
listOfFoo.Where((x) x.size > 10);
I would be nice to have that in D
listOfFoo.Where(x => x.size > 10);
even better if you could have this syntax (but perhaps it won't work):
listOfFoo.Where((x) x.size > 10);
I would be nice to have that in D
listOfFoo.Where(x => x.size > 10);
even better if you could have this syntax (but perhaps it won't work):
listOfFoo.Where((x) x.size > 10);
I would be nice to have that in D
One of my D library ideas that fell by the wayside was to make a
compile-time SQL parser. So you could do something like:
string[] results = Query!("
SELECT groups.name
FROM groups
INNER JOIN employees ON employees.groupId = groups.id,
GROUP BY employees.groupId
HAVING avg(employees.salary) > 50000
WHERE group.name != "Accounting" -- Nobody likes them
ORDER BY group.name
");
(or something like that; my SQL's a bit rusty). Ideally, you could have
an arbitrarily complex query including subqueries. Query would be a
template of some sort... not sure exactly how this would work... but
that's my pipe dream, anyway.
One of my D library ideas that fell by the wayside was to make a
compile-time SQL parser. So you could do something like:
string[] results = Query!("
SELECT groups.name
FROM groups
INNER JOIN employees ON employees.groupId = groups.id,
GROUP BY employees.groupId
HAVING avg(employees.salary) > 50000
WHERE group.name != "Accounting" -- Nobody likes them
ORDER BY group.name
");
(or something like that; my SQL's a bit rusty). Ideally, you could have
an arbitrarily complex query including subqueries. Query would be a
template of some sort... not sure exactly how this would work... but
that's my pipe dream, anyway.
I have wanted to make a template that lets you define a DB class with
stored procedures accessed through methods. It would work a lot like the
above but would optimize the queries at compile time.
The parser for either case would be big, slow and a memory hog but it
can be built.
One of my D library ideas that fell by the wayside was to make a
compile-time SQL parser. So you could do something like:
string[] results = Query!("
SELECT groups.name
FROM groups
INNER JOIN employees ON employees.groupId = groups.id,
GROUP BY employees.groupId
HAVING avg(employees.salary) > 50000
WHERE group.name != "Accounting" -- Nobody likes them
ORDER BY group.name
");
(or something like that; my SQL's a bit rusty). Ideally, you could have an
arbitrarily complex query including subqueries. Query would be a template
of some sort... not sure exactly how this would work... but that's my pipe
dream, anyway.
Have a look at Ultimate++:
http://www.ultimatepp.org/src$Sql$SqlExp$en-us.html
but in C++ and without strings like:
Select(COLUMN)
.From(TABLE)
.Where(COLUMN == (Select(COLUMN1).From(TABLE1) -
Select(COLUMN2).From(TABLE2)))
An interesting toolkit.
If you look at this page:
http://www.ultimatepp.org/www$uppweb$overview$en-us.html
The part titled "Value and Null" shows you that they are re-inventing dynamic
typing (== always using a variant-like type) to do GUI programming.
There's even a comparison with D:
http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
With the comment: "Means C++ is still well ahead of D (by 70%) if not being
hold back by standard library design and average implementation..."
:-)
Bye,
bearophile
Apr 04 2008
↑ ↓ ←→ Tomas Lindquist Olsen <tomas famolsen.dk> writes:
An interesting toolkit.
If you look at this page:
http://www.ultimatepp.org/www$uppweb$overview$en-us.html
The part titled "Value and Null" shows you that they are re-inventing dynamic
typing (== always using a variant-like type) to do GUI programming.
There's even a comparison with D:
http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
With the comment: "Means C++ is still well ahead of D (by 70%) if not being
hold back by standard library design and average implementation..."
:-)
Bye,
bearophile
U++ is an excellent toolkit, it takes a while to get used to their whole
transfer-semantics
thing, but once you do it's a pleasure. The code is really short and easy to
read.
For GUI app development I'd pick U++/C++ over D any day.
(a few years ago, I implemented a 3D height map editor with support for
"infinitely" big
terrains, WYSIWYG editing/texturing and a lot of other stuff in U++)
The code is really short and easy to read.
For GUI app development I'd pick U++/C++ over D any day.
Is it possible to design a similar API in D too?
I'll take a better look at U++ then, it seems it's partially free too. Its hash
maps seem quite faster than D ones, so I think such design ideas may be used to
improve D AAs.
I like the API of the now dead WAX GUI toolkit (that works with Wx):
http://zephyrfalcon.org/labs/wax.htmlhttp://zephyrfalcon.org/waxapi/index_h.html
Bye,
bearophile
Apr 04 2008
↑ ↓ ← → Tomas Lindquist Olsen <tomas famolsen.dk> writes:
bearophile wrote:
Tomas Lindquist Olsen:
The code is really short and easy to read.
For GUI app development I'd pick U++/C++ over D any day.
Is it possible to design a similar API in D too?
I'll take a better look at U++ then, it seems it's partially free too. Its
hash maps seem quite faster than D ones, so I think such design ideas may be
used to improve D AAs.
I like the API of the now dead WAX GUI toolkit (that works with Wx):
http://zephyrfalcon.org/labs/wax.htmlhttp://zephyrfalcon.org/waxapi/index_h.html
Bye,
bearophile
First, go get the real benefit from U++, you need to use their IDE. To me this
was a real pain
in the beginning. But _only for a few weeks_. After that it's really a pleasure.
* It has the best highlighting I've seen in any C++ editor (it highlight's
scopes with slightly
different background colors).
* The forms editor is a must for GUI apps.
* Internationalisation is trivial with built in features (you have to wrap all
strings in
_t("hello") etc though)
* nice component based project management.
I could go on and on. This thing just makes gui coding so nice, I can't
understand why more
people aren't using it...
It kinda funny how the way they do all their magic is by completely ignoring
"normal" C++
coding practices, with 'const' and 'mutable' [1] being the most important
keywords...
[1]: http://www.ultimatepp.org/srcdoc$Core$pick_$en-us.html - search for
'#define pick_ const'
Apr 04 2008
↑ ↓ ← → Charles D Hixson <charleshixsn earthlink.net> writes:
An interesting toolkit.
If you look at this page:
http://www.ultimatepp.org/www$uppweb$overview$en-us.html
The part titled "Value and Null" shows you that they are re-inventing
dynamic typing (== always using a variant-like type) to do GUI
programming.
There's even a comparison with D:
http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
With the comment: "Means C++ is still well ahead of D (by 70%) if not
being hold back by standard library design and average implementation..."
:-)
Bye,
bearophile
U++ is an excellent toolkit, it takes a while to get used to their whole
transfer-semantics thing, but once you do it's a pleasure. The code is
really short and easy to read.
For GUI app development I'd pick U++/C++ over D any day.
(a few years ago, I implemented a 3D height map editor with support for
"infinitely" big terrains, WYSIWYG editing/texturing and a lot of other
stuff in U++)
Pretty cool, but still not as nice as D's delegates. From the
proposal (5.1.1): "Each lambda expression has a unique type.
Except as specified below, the type of the closure object is
unspecified." This suggests that a closure really isn't intended
to escape the scope in which it is declared, because there's
no easy way to declare one (I can imagine some fancy template
tricks to do so, but I'm ignoring them).
This is actually somewhat interesting because the syntax for
declaring closures in C++ seems to allow for this by providing
a way for automatic local data to be saved (the capture list).
Perhaps they'll get another shot in the arm in the next iteration
of C++ to become more like full closures. Or maybe this was
enough of a language change and the rest is expected to be
taken care of in library code? I haven't been following the
progress of 0x in the past year or two so I really couldn't
say what the reasoning is here.
Interestingly, this proposal Herb mentions has removed 'auto' as
a storage class:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2546.htm
This seems completely unnecessary to me--the D way makes much
more sense. Simply omit the type portion of the declaration and the
type is inferred. I wonder what the reasoning was here?
It's kind of weird, but now that the new spec is basically finalized I
find myself having trouble finding many features that I'm actually
enthusiastic about. Most of the few features that sound really cool in
theory already exist in D and their syntax there is much nicer. And
some of the proposals are such obvious extensions of other proposals
that their existence simply stands as a testament to the bureaucracy
involved in the standardization process. This one, for example:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2547.htm
After more than sixteen years with the language it feels strange to
say that I actually feel somewhat relieved that my professional
work has led me away from C++ recently.
Sean
Yet another C++ hack, D does it the correct way.
Seriously though, I look forward to the day I never have to work with a
boost:bind or loki:functor again.
-Joel
Apr 03 2008
↑ ↓ ←→ Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
What happens to the outer variables? Is a copy of them created for each
evaluated closure object? Or does there exist only a single instance of
each, as in D?
And how is the closure object destroyed, since there is no GC? (does one
have to assign it to a variable, to later delete it?)
I tried to read the proposal to find an answer, but I couldn't quickly
grasp it.
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
evaluated closure object? Or does there exist only a single instance of
each, as in D?
And how is the closure object destroyed, since there is no GC? (does one
have to assign it to a variable, to later delete it?)
I tried to read the proposal to find an answer, but I couldn't quickly
grasp it.
From memory, it looked like variables could either be copied or manipulated
by reference, and that the closure object was basically just an opaque struct
much like a plain old functor.
Sean
Apr 11 2008
↑ ↓ ← → Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Sean Kelly wrote:
== Quote from Bruno Medeiros (brunodomedeiros+spam com.gmail)'s article
evaluated closure object? Or does there exist only a single instance of
each, as in D?
And how is the closure object destroyed, since there is no GC? (does one
have to assign it to a variable, to later delete it?)
I tried to read the proposal to find an answer, but I couldn't quickly
grasp it.
From memory, it looked like variables could either be copied or manipulated
by reference, and that the closure object was basically just an opaque struct
much like a plain old functor.
Sean
Yes, that seems to make sense all around.
I was originally surprised by this announcement because it was not
possible for C++ to implement "full" closures without having a GC. So it
was either closures with outer variables that became invalid after the
enclosing function exited (the D situation until some releases ago), or
making copies of outer variables.
Still, altough this closure semantics is not as 100% "full" as other
languages (latest D, C#, Lisps, etc.) it's still useful enough for C++,
and I'm surprised how relatively cleanly it fit in, unlike several of
the other extensions which seem like ugly and crufty additions.
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next