Sandwich wrote:
/*Me ends lurking*/
As far as allocators go, you may want to take a look at how eastl handles them:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#eastl_allocator
/*Resumes Lurking*/
Thanks. Wonder how many other knowledgeable lurkers are out there :o).
A
Robert Jacques wrote:
On Thu, 04 Mar 2010 18:22:55 -0500, Andrei Alexandrescu
wrote:
[snip]
I like this idea. I've gotten used to using template constraints and
ranges when coding which matches this strategy naturally. A lot of the
capabilities seem to match ranges, but why did you use diffe
Andrei Alexandrescu wrote:
I decided to let no assumption unchallenged and got back to the
question: do we really need a container _hierarchy_? How much joy and
usefulness do people derive from dynamically changing an array with a
list under the same interface? Or a rb-tree vs. a binary tree vs
Andrei Alexandrescu wrote:
Apologies for the dense message. I wanted to concentrate as much info in
as little time/space as possible.
Actually, thank you for making a concentrated message.
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> Hi everyone,
> I'm on a trip to Romania visiting relatives. Being disconnected for a
> while, I thought some about container types and started writing some code.
> It didn't take long to figure that a classic class hierar
I'd definitely go with the unconnected class solution. Sometimes it's useful
to be able to have a class hierarchy where you don't have to care whether
about things like whether a Map is a HashMap or a SortedMap, but it
frequently comes back to bite you - especially when they require that
differ
Andrei Alexandrescu Wrote:
> I decided to let no assumption unchallenged and got back to the
> question: do we really need a container _hierarchy_? How much joy and
> usefulness do people derive from dynamically changing an array with a
> list under the same interface? Or a rb-tree vs. a binary
Jerry Quinn wrote:
Hi, me again. Following up on this comment, can I bring up the
proposal of contributing a snapshot of the dmd frontend to the GCC
project? I think for D to be really viable in GCC, it must be a part
of the source tree.
I hope I'm not being a pest.
No, you're not being a pe
Walter Bright Wrote:
> grauzone wrote:
> > How many man years would you assume writing a full D compiler takes?
> > (Frontend starting from scratch, using an existing backend.)
>
> But there's little reason to implement a D compiler from scratch. For
> open source uses, you can just go ahead an
Walter Bright:
> But there's little reason to implement a D compiler from scratch.<
I'm ignorant about this topic, but I think there are various ways to create a
new D front-end:
- Copy the C++ code of DMD and create a small middle-end to adapt it to
something else, LDC and GDC have done this. T
On 03/04/2010 02:49 PM, Fawzi Mohamed wrote:
Bye,
bearophile
Doesn't tango's exception tracing do that?
sure it does, just import TraceExceptions...
The exception will contain the stacktrace at the throwing point
(adresses)... and with printOut you can get a symbolic trace (if possible).
/*Me ends lurking*/
As far as allocators go, you may want to take a look at how eastl handles them:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#eastl_allocator
/*Resumes Lurking*/
Andrei Alexandrescu Wrote:
> bearophile wrote:
> > Andrei Alexandrescu:
> >> As far as I ca
On Thu, 04 Mar 2010 18:22:55 -0500, Andrei Alexandrescu
wrote:
[snip]
I like this idea. I've gotten used to using template constraints and
ranges when coding which matches this strategy naturally. A lot of the
capabilities seem to match ranges, but why did you use different names for
som
On Thu, 04 Mar 2010 13:58:54 -0500, bearophile
wrote:
What do you think of the idea of the Exception to remember (so later it
can be shown if uncaught) the line number and file name where it was
instantiated?
void foo() {
auto e = new Exception(""); // instantiation line number here
grauzone wrote:
How many man years would you assume writing a full D compiler takes?
(Frontend starting from scratch, using an existing backend.)
I don't know. Somewhere in between.
Remember that EDG reported that it took them 3 man-years just to
implement one C++ feature - exported templates
bearophile wrote:
Andrei Alexandrescu:
As far as I can tell such changes of containers are a design-time
decision, and extremely rarely (never as far as I remember) a runtime
decision to hide behind a binary interface.
In your post there's lot of stuff to think about. I can see you are trying
"Matt Wilson" wrote in message
news:hmpco3$2ql...@digitalmars.com...
> Pantheios is an open source C/C++ Logging API library, offering an optimal
> combination of 100% type-
Announcements belong in digitalmars.D.announce. Also, this is a D newsgroup.
Does Pantheios have some sort of D capabili
Andrei Alexandrescu:
> As far as I can tell such changes of containers are a design-time
> decision, and extremely rarely (never as far as I remember) a runtime
> decision to hide behind a binary interface.
In your post there's lot of stuff to think about. I can see you are trying to
innovate,
Hi everyone,
I'm on a trip to Romania visiting relatives. Being disconnected for a
while, I thought some about container types and started writing some code.
It didn't take long to figure that a classic class hierarchy with
inheritance etc. would contain prohibitively many types (with awkwar
On Thu, 04 Mar 2010 17:37:55 -0500, Matt Wilson
wrote:
>Pantheios is an open source C/C++ Logging API library, offering an optimal
>combination of 100% type-safety, efficiency, genericity and extensibility. It
>is simple to use and extend, highly-portable (platform and
>compiler-independent) a
Pantheios is an open source C/C++ Logging API library, offering an optimal
combination of 100% type-safety, efficiency, genericity and extensibility. It
is simple to use and extend, highly-portable (platform and
compiler-independent) and, best of all, it upholds the C tradition of you only
pay
Walter Bright wrote:
bearophile wrote:
Walter Bright:
Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too!
The hard work of implementing C++ correctly was just beginning,
though.
C'mon Walter, give them some credit, wish them some luck, I think
they will be able to compile a go
Clemens:
>As soon as you have an instance variable x and a function parameter x, there
>will *always* be ambiguity (unless you don't use the parameter). Requiring the
>use of "this." amounts to disallowing access to the parameter x.<
Thank you for spotting my stupid idea :o)
I will update the en
bearophile wrote:
Walter Bright:
Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too!
The hard work of implementing C++ correctly was just beginning,
though.
C'mon Walter, give them some credit, wish them some luck, I think
they will be able to compile a good percentage of Boost
Walter Bright:
> Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too! The
> hard work of implementing C++ correctly was just beginning, though.
C'mon Walter, give them some credit, wish them some luck, I think they will be
able to compile a good percentage of Boost in less than 15
bearophile wrote:
Walter Bright:
Note that clang is a C compiler, not a C++ one.<
There's also Clang++ that has few days ago compiled itself for the first time
:-)
Yeah, I wrote a C++ compiler back in 1987. It compiled itself, too! The
hard work of implementing C++ correctly was just begin
On 2010-03-04 21:38:09 +0100, BCS said:
Hello bearophile,
What do you think of the idea of the Exception to remember (so later
it can be shown if uncaught) the line number and file name where it
was instantiated?
It shouldn't be hard, add default parameters to the constructor:
this(string
On 2010-03-04 21:29:15 +0100, "Nick Sabalausky" said:
"bearophile" wrote in message
news:hmovte$243...@digitalmars.com...
What do you think of the idea of the Exception to remember (so later it
can be shown if uncaught) the line number and file name where it was
instantiated?
void foo() {
au
Clemens wrote:
> bearophile Wrote:
>
>> Ary Borenszweig:
>> > So you suggest to forbid having an argument name that
>> > matches an attribute name? Or require this. for attribute access?
>>
>> I prefer the compiler to give an error when an argument has the same name
>> of an attribute, it's tidi
Hello bearophile,
What do you think of the idea of the Exception to remember (so later
it can be shown if uncaught) the line number and file name where it
was instantiated?
It shouldn't be hard, add default parameters to the constructor:
this(string msg, string file = __FILE__, int line = __
Hello bearophile,
If they accept D compilers too, then it can be used to keep an eye on
them, for example to spot regressions in performance, binary file
produced, etc.
sounds interesting, as long as it didn't become a distraction and an end
unto it's self.
--
... <
"bearophile" wrote in message
news:hmovte$243...@digitalmars.com...
> What do you think of the idea of the Exception to remember (so later it
> can be shown if uncaught) the line number and file name where it was
> instantiated?
>
> void foo() {
>auto e = new Exception(""); // instantiation
Walter Bright:
> The spell checker idea is a good one.
I have seen it used for the first time in Mathematica, even very old versions
of it. It's handy. In Python I have written something similar that works at
runtime.
Bye,
bearophile
Walter Bright:
> Note that clang is a C compiler, not a C++ one.<
There's also Clang++ that has few days ago compiled itself for the first time
:-)
Bye,
bearophile
Adam D. Ruppe wrote:
You should try Digital Mars C. Its error messages are similar to that,
though I don't think it has the built in spellchecker.
The ^ pointing to where it is on the line is something it's done for many
many years, though it isn't really that useful anyway in practice.
I drop
On 2010-03-04 13:19:25 -0500, Norbert Nemec said:
Exactly my point: contracts are not assertions.
Still, contracts are not exceptions either. A broken contract is a BUG.
A triggered exception is a run-time condition that can happen in a
perfectly correct program.
I think a big problem toda
On Thu, Mar 04, 2010 at 01:50:10PM -0500, bearophile wrote:
> It shows that there's some space for improvements in the error messages given
> by future D compilers (like a LDC-like compiler for D2 based on LLVM) too.
You should try Digital Mars C. Its error messages are similar to that,
though I
What do you think of the idea of the Exception to remember (so later it can be
shown if uncaught) the line number and file name where it was instantiated?
void foo() {
auto e = new Exception(""); // instantiation line number here
throw e;
}
void main() {
foo();
}
Exceptions get caugh
On Thu, 04 Mar 2010 13:38:30 -0500, grauzone wrote:
Steven Schveighoffer wrote:
So it probably should be marked as unsafe.
Doesn't it conform to Andrei's ideas about memory safety? It can stomp
over other data, but it can't be used to subvert the type system.
I think the idea is that a
This site collects and shows graphs of performance of Python interpreters:
http://morepypy.blogspot.com/2010/03/introducing-speedpypyorg.html
They say:
>if other performance-oriented opensource projects are interested, I would be
>willing to see if we can set-up such a Speed Center for them.<
If
Found in Reddit:
http://zi.fi/shots/clang.png
It shows that there's some space for improvements in the error messages given
by future D compilers (like a LDC-like compiler for D2 based on LLVM) too.
Bye,
bearophile
I was working on a web application framework kind of like Tomcat (using
AJP), but different. At one point I thought it was going quite well.
I foundered on the inability to dynamically load things, which was an
essential. I tried messing with DDL, but that seemed to be a dead end.
Shared libra
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 12:43:32 -0500, grauzone wrote:
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but
enabling to reuse the old memory would be nice:
int[] a = data;
a =
bearophile wrote:
Complex enough different parts of the same program need "user interfaces" for
each other, where the user is the programmer or another part of the program written by
the programmer or another programmer. So libraries need to test all their inputs well
anyway. I have programmed
On Thu, 04 Mar 2010 12:43:32 -0500, grauzone wrote:
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but enabling
to reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates
On Thu, 04 Mar 2010 12:29:25 -0500, Clemens wrote:
Steven Schveighoffer Wrote:
int[] a;
a.setCapacity(1); // pre-allocate at least 1 elements.
I would prefer the name reserve(). It has precedent in the STL, and the
method doesn't actually always set the capacity, only if the curre
"Justin Johansson" wrote in message
news:hmob4s$pa...@digitalmars.com...
>I throw this subject up for the D community's consideration.
>
> Admittedly the subject is quite broad in scope.
>
> However, in response to some of my posts of time ago, people on this NG
> have said things along lines of
Ary Borenszweig wrote:
Pelle Månsson wrote:
On 03/04/2010 02:24 PM, Ary Borenszweig wrote:
Norbert Nemec wrote:
Hi there,
following the recent thread on contracts, I come to the conclusion
that the current syntax is misleading and counterproductive.
* The concept of a contract is an expressi
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but enabling
to reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates (of course)
a.length = 0;
a ~= 1; //will reallocate (fo
Steven Schveighoffer Wrote:
> int[] a;
> a.setCapacity(1); // pre-allocate at least 1 elements.
I would prefer the name reserve(). It has precedent in the STL, and the method
doesn't actually always set the capacity, only if the current capacity is less
then the argument. Even then it m
On Thu, 04 Mar 2010 11:43:27 -0500, grauzone wrote:
Some sort of "resetAndReuse" function to clear an array, but enabling to
reuse the old memory would be nice:
int[] a = data;
a = null;
a ~= 1; //reallocates (of course)
a.length = 0;
a ~= 1; //will reallocate (for safety), used not to reall
bearophile Wrote:
> Ary Borenszweig:
> > So you suggest to forbid having an argument name that
> > matches an attribute name? Or require this. for attribute access?
>
> I prefer the compiler to give an error when an argument has the same name of
> an attribute, it's tidier.
I'd rather not have
On Thu, 04 Mar 2010 11:49:13 -0500, bearophile
wrote:
Steven Schveighoffer:
I think the point is, the statement x = x + 1; isn't any more or less
ambiguous in D than it is in python. There is a well-defined meaning
(and
in fact the same meaning).
It's not the same meaning, this program
I think, this should be broken down into different issues:
* Is real-life code ever stable enough to take deactivate assertion checks?
I think that there is no simple yes/no question. The best solution would
probably be to allow selectively deactivating assertions. It may indeed
be advisable t
Steven Schveighoffer:
> I think the point is, the statement x = x + 1; isn't any more or less
> ambiguous in D than it is in python. There is a well-defined meaning (and
> in fact the same meaning).
It's not the same meaning, this program prints "1":
import std.c.stdio: printf;
class Foo {
Steven Schveighoffer wrote:
On Thu, 04 Mar 2010 04:02:46 -0500, KF wrote:
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays
and remove them from the end. This incremental changes would most
conveniently be performed by a~=e for ad
On Thu, 04 Mar 2010 11:06:15 -0500, bearophile
wrote:
Ary Borenszweig:
But python doesn't do it either. Did you suggest the same thing to the
python devs? :-)
:-)
Well, when I teach Python I give the advice of not using the same names
for arguments and attributes. So it's a programming
Ary Borenszweig:
> But python doesn't do it either. Did you suggest the same thing to the
> python devs? :-)
:-)
Well, when I teach Python I give the advice of not using the same names for
arguments and attributes. So it's a programming practice.
Here the situation in D is worse, because in Pyt
bearophile wrote:
Ary Borenszweig:
So you suggest to forbid having an argument name that
matches an attribute name? Or require this. for attribute access?
I prefer the compiler to give an error when an argument has the same name of an
attribute, it's tidier.
But python doesn't do it either.
Ary Borenszweig:
> So you suggest to forbid having an argument name that
> matches an attribute name? Or require this. for attribute access?
I prefer the compiler to give an error when an argument has the same name of an
attribute, it's tidier.
If you think that solution is too much restricting
bearophile wrote:
Ary Borenszweig:
How is python safer than D in that sense?
This is correct D code:
class Foo {
int x;
this() { x = 5; }
}
void main() {}
In Python "self." is always needed to refer to the attribute, and "x" refers to
the argument (or a global name, but then you nee
Ary Borenszweig:
> How is python safer than D in that sense?
This is correct D code:
class Foo {
int x;
this() { x = 5; }
}
void main() {}
In Python "self." is always needed to refer to the attribute, and "x" refers to
the argument (or a global name, but then you need a global statement
Pelle Månsson wrote:
On 03/04/2010 02:24 PM, Ary Borenszweig wrote:
Norbert Nemec wrote:
Hi there,
following the recent thread on contracts, I come to the conclusion
that the current syntax is misleading and counterproductive.
* The concept of a contract is an expression, not a statement.
* A
bearophile wrote:
Ary Borenszweig:
This can be solved if the compiler warns when an assignment is from a
variable to the same one.
x = x; // error: assignment has no effect
That's nice in general to have, but I think it's not enough, because if I want
to assign to an attribute an increment
On 03/04/2010 02:24 PM, Ary Borenszweig wrote:
Norbert Nemec wrote:
Hi there,
following the recent thread on contracts, I come to the conclusion
that the current syntax is misleading and counterproductive.
* The concept of a contract is an expression, not a statement.
* A contract should *neve
On 03/04/2010 02:44 PM, Bane wrote:
This can be solved if the compiler warns when an assignment is from a
variable to the same one.
x = x; // error: assignment has no effect
Nice and useful.
struct A {
int i;
void opAssign(A a) {
i = a.i + 1;
}
}
why not?
bearophile wrote:
Ary Borenszweig:
This can be solved if the compiler warns when an assignment is from a
variable to the same one.
x = x; // error: assignment has no effect
That's nice in general to have, but I think it's not enough, because if I want
to assign to an attribute an increment
So I'll play devil's advocate for a while and see what transpires.
I'm not sure if it's useful but I've managed to write simple
web-server (I used tango since I'm used to it)
that served simple minesweeper application :)
async request were made using jquery,
some request were responsed with s
On 03/04/2010 02:04 PM, Justin Johansson wrote:
I throw this subject up for the D community's consideration.
Admittedly the subject is quite broad in scope.
However, in response to some of my posts of time ago, people on this NG
have said things along lines of "D is a Systems Programming Langua
On Thu, 04 Mar 2010 05:00:46 -0500, Lionello Lunesu
wrote:
On 3-3-2010 23:51, Robert Jacques wrote:
At the cost of forcing every single member function call to do an
additional stack push? DMD doesn't pass args in ECX and EDX for a
reason. Adapting free functions to delegates is a rare enoug
Ary Borenszweig:
> This can be solved if the compiler warns when an assignment is from a
> variable to the same one.
>
> x = x; // error: assignment has no effect
That's nice in general to have, but I think it's not enough, because if I want
to assign to an attribute an incremented value:
x =
Yes, though it needs a little more work on the library side to be simple
to use for it.
Web programming is still programming, a field in which D excels.
I don't really know what else to say, but I know having D's type system
is something I long for whenever using other web languages.
--
Adam D.
> This can be solved if the compiler warns when an assignment is from a
> variable to the same one.
>
> x = x; // error: assignment has no effect
Nice and useful.
bearophile wrote:
This is correct D code, but I think it's a bad practice to write code like
this, where method arguments have the same name as instance/static attributes
of the class/struct.
class Foo {
int x;
this(int x) { this.x = x; }
void inc(int x) { this.x += x; }
}
struct B
Norbert Nemec wrote:
Hi there,
following the recent thread on contracts, I come to the conclusion that
the current syntax is misleading and counterproductive.
* The concept of a contract is an expression, not a statement.
* A contract should *never* have side effects, otherwise debugging code
I throw this subject up for the D community's consideration.
Admittedly the subject is quite broad in scope.
However, in response to some of my posts of time ago, people on this NG
have said things along lines of "D is a Systems Programming Language so
we want none of that", or words to that effe
This is correct D code, but I think it's a bad practice to write code like
this, where method arguments have the same name as instance/static attributes
of the class/struct.
class Foo {
int x;
this(int x) { this.x = x; }
void inc(int x) { this.x += x; }
}
struct Bar {
static int
Norbert Nemec:
> No! No! No! Design-by-contract means that it is the application's duty
> to make sure that argument values are correct. If the program is
> correct, the library can trust that the argument values are correct and
> does not need to do checks. This is exactly the same situation t
On Thu, 04 Mar 2010 04:02:46 -0500, KF wrote:
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays
and remove them from the end. This incremental changes would most
conveniently be performed by a~=e for addition of e at the end of a,
On Wed, 03 Mar 2010 18:58:54 -0500, Lionello Lunesu
wrote:
You make a good point, but there's one problem I have with this.
I'm looking at this as a library writer. I can write in-contracts with
assertions, but I would not feel comfortable with only assertions, since
I know they will not get
That sounds pretty much like putting your application authors under
tutelage (great word - just found it in the dictionary... :-) )
Writing a library that other can use, you should always assume that they
are mature and responsible beings. The contracts explicitly tell the
application author t
On 3-3-2010 23:51, Robert Jacques wrote:
> At the cost of forcing every single member function call to do an
> additional stack push? DMD doesn't pass args in ECX and EDX for a
> reason. Adapting free functions to delegates is a rare enough operation
> that making everything else slower to save one
Hi there,
following the recent thread on contracts, I come to the conclusion that
the current syntax is misleading and counterproductive.
* The concept of a contract is an expression, not a statement.
* A contract should *never* have side effects, otherwise debugging code
may behave different
> Is SSE(2) inherently faster then (at least in real-world implementations) than
> x87, even when you don't vectorize? Would I be able to expect any speedup
> from
> going from x87 to SSE(2) for code that has a decent amount of implicit
> instruction
> level parallelism but wasn't explicitly ve
Brad Roberts wrote:
On Wed, 3 Mar 2010, Norbert Nemec wrote:
The edited Wikipedia text for D is so far correct, even though the whole page
is not quite as precise as it could be. The theoretical basis and the
practical application are somewhat mixed. Fixing that, however, would be a
major task.
I hope this is the right place to post it.
In my work, I often need to add elements at the end of dynamic arrays and
remove them from the end. This incremental changes would most
conveniently be performed by a~=e for addition of e at the end of a, and say
a=a[0..$-1]. Unfortunately, ~= always cre
86 matches
Mail list logo
