Walter Bright wrote:
dsimcha wrote:
I assume, when referring to the ones that do throw, you mean functions
written in
C++ or D, but declared w/ C linkage. If so, you could make this a
per-module
setting that defaults to not assuming nothrow. For example, let's say
you made
this pragma(Linkag
Don wrote:
tango.math doesn't use the C library at all, except when inline asm is
unavailable. Of they differ from the C functions, in that none of them
set errno!
One really annoying issue still remains, though -- the floating point
flags in the CPU. They are entirely deterministic, but are th
Walter Bright wrote:
Don wrote:
tango.math doesn't use the C library at all, except when inline asm is
unavailable. Of they differ from the C functions, in that none of them
set errno!
One really annoying issue still remains, though -- the floating point
flags in the CPU. They are entirely det
dsimcha Wrote:
> Is there any decent reading material out there about how exception handling is
> works under the hood
Matt Pietrek is famous for such a material. You can also look at
NtRaiseException in wine sources.
It seems one group of ideas and syntax I did suggest for D weren't so Krazy,
after all. I have just found that they can be seen almost equal in C#.
You can read something about them here:
http://msdn.microsoft.com/en-us/library/a569z7k8.aspx
There is the checked/unchecked keyword that can be use
Jacob Carlborg wrote:
Frits van Bommel wrote:
Jacob Carlborg wrote:
Could we get a LP64 version identifier? I know that you can use this
code:
"static if ((void*).sizeof > int.sizeof)"
Shouldn't that be "static if ((void*).sizeof == long.sizeof)" or just
"static if ((void*).sizeof == 8)"?
Jacob Carlborg wrote:
Walter Bright wrote:
Jacob Carlborg wrote:
Could we get a LP64 version identifier? I know that you can use this
code:
"static if ((void*).sizeof > int.sizeof)"
to do the same but that's not particular clear that the programmer
wants to check for LP64. If so, I hope we
On 2009-01-25 14:39:52 -0500, Walter Bright said:
I did think of making all functions that are extern(C) automatically
nothrow, but was concerned that it would result in a lot of bugs and
broken code from ones that did throw.
It's better that way, because it allows you to write proper wrappe
Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
void move(ref T src, ref T dst);
void swap(ref T lhs, ref T rhs);
...
But if "prop" is a property with get and set, everything falls apart.
Properties effectively hide the address of the actual data and only
tr
Walter Bright wrote:
Jacob Carlborg wrote:
Could we get a LP64 version identifier? I know that you can use this
code:
"static if ((void*).sizeof > int.sizeof)"
to do the same but that's not particular clear that the programmer
wants to check for LP64. If so, I hope we could get it in D1 also
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
[snip]
get/set/free?
With these you can't move a resource inside the property.
Andrei
Python has an overload for removing properties. In all my years of
using Python, I've *NEVER* once had a use for it, or even worked out
"Andrei Alexandrescu" wrote
> I'm working on the new range stuff and the range-based algorithm. In all
> likelihood, you all might be pleased with the results.
>
> I wanted to gauge opinions on a couple of issues. One is, should the
> empty() member function for ranges be const? On the face of it
Jacob Carlborg wrote:
[on properties]
What about this:
class Host
{
property acquire release prop
{
T get();
}
}
And then the compiler will automatically created the "acquire" and
"release" methods.
There could also be what I would like to call "property shortcuts" (r
Sean Kelly wrote:
> Daniel Keep wrote:
>> Andrei Alexandrescu wrote:
>>> Denis Koroskin wrote:
[snip]
get/set/free?
>>> With these you can't move a resource inside the property.
>>>
>>> Andrei
>>
>> Python has an overload for removing properties. In all my years of
>> using Python
Steven Schveighoffer wrote:
"Andrei Alexandrescu" wrote
I'm working on the new range stuff and the range-based algorithm. In all
likelihood, you all might be pleased with the results.
I wanted to gauge opinions on a couple of issues. One is, should the
empty() member function for ranges be co
Andrei Alexandrescu wrote:
Jacob Carlborg wrote:
[on properties]
What about this:
class Host
{
property acquire release prop
{
T get();
}
}
And then the compiler will automatically created the "acquire" and
"release" methods.
There could also be what I would like to
Daniel Keep wrote:
Sean Kelly wrote:
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
[snip]
get/set/free?
With these you can't move a resource inside the property.
Andrei
Python has an overload for removing properties. In all my years of
using Python, I've *NEVER* on
== Quote from Daniel Keep (daniel.keep.li...@gmail.com)'s article
> Sean Kelly wrote:
> > Daniel Keep wrote:
> >> Andrei Alexandrescu wrote:
> >>> Denis Koroskin wrote:
> [snip]
>
> get/set/free?
> >>> With these you can't move a resource inside the property.
> >>>
> >>> Andrei
> >>
Hello dsimcha,
== Quote from Daniel Keep (daniel.keep.li...@gmail.com)'s article
Sean Kelly wrote:
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Denis Koroskin wrote:
[snip]
get/set/free?
With these you can't move a resource inside the property.
Andrei
Python has an overload for
"Andrei Alexandrescu" wrote
>I realized that properties are not a complete model for actual data. The
>current conventional wisdom about properties goes like this (T is some
>type):
>
> class Host
> {
> property prop
> {
> T get() { ... }
> void set(T value) { ... }
>
bearophile wrote:
Andrei Alexandrescu: You can take a look at my dlibs, they may give
you ideas, because contain all such lazy functions and some more.
You mean the libs in my signature? Sure. :o)
In http://www.fantascienza.net/leonardo/so/dlibs/func.html, I like
functions such as any and all
Don wrote:
Andrei Alexandrescu wrote:
Jacob Carlborg wrote:
[on properties]
What about this:
class Host
{
property acquire release prop
{
T get();
}
}
And then the compiler will automatically created the "acquire" and
"release" methods.
There could also be what I wo
"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>>> I'm working on the new range stuff and the range-based algorithm. In all
>>> likelihood, you all might be pleased with the results.
>>>
>>> I wanted to gauge opinions on a couple of issues. One is, should
Andrei Alexandrescu:
> You mean the libs in my signature? Sure. :o)
:-]
> I like frequency a
> lot, would be very useful for my NLP code (although probably I'd replace
> it with counts and let the user normalize).
It doesn't perform a normalization (I can add to it few more functionalities
bearophile:
> and sometimes not even much intelligent.
I meant: "sometimes not even much interesting."
"bearophile" wrote in message
news:glk5pj$22r...@digitalmars.com...
> It seems one group of ideas and syntax I did suggest for D weren't so
> Krazy, after all. I have just found that they can be seen almost equal in
> C#.
>
> You can read something about them here:
> http://msdn.microsoft.com/e
Steven Schveighoffer wrote:
"Spacen Jasset" wrote
Steven Schveighoffer wrote:
...chop
For us Linux DMD users a bug should be raised against dmd so that Walter
will hopefully compile against an older glibc on future releases.
As long as it doesn't cause weird problems. I have had weird stu
Walter Bright wrote:
Spacen Jasset wrote:
For us Linux DMD users a bug should be raised against dmd so that
Walter will hopefully compile against an older glibc on future releases.
Yet when I do that the other half of the linux users have a problem.
Do you know what problems they had Walter,
bearophile wrote:
Andrei Alexandrescu:
I like frequency a lot, would be very useful for my NLP code
(although probably I'd replace it with counts and let the user
normalize).
It doesn't perform a normalization (I can add to it few more
functionalities can be added, but not this one), I'll impr
Jacob Carlborg wrote:
Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
void move(ref T src, ref T dst);
void swap(ref T lhs, ref T rhs);
...
But if "prop" is a property with get and set, everything falls apart.
Properties effectively hide the address of the
Jacob Carlborg wrote:
Are you saying that D_LP64 isn't implemented in the current version?
Because I noticed that it was already listed in the documentation:
http://www.digitalmars.com/d/1.0/version.html
When I tried to set the D_LP64 version with GDC it said: "Error: version
identifier 'D_LP64
Don wrote:
Walter Bright wrote:
Don wrote:
tango.math doesn't use the C library at all, except when inline asm
is unavailable. Of they differ from the C functions, in that none of
them set errno!
One really annoying issue still remains, though -- the floating point
flags in the CPU. They are
Frits van Bommel wrote:
Some testing shows that all DMD-frontend based compilers (i.e. DMD, GDC
and LDC) seem to produce that error message for any version identifier
starting with "D_" (Including "D_" itself).
The point of that is to ensure that the D_ name space is reserved for
predefined v
Frits van Bommel wrote:
[1]: Hey, x86 technically has 6-byte pointers if you count segments as
part of the pointer (which would be mostly useless on currently popular
operating systems though).
It does, but I know of no compiler that supports that (C, C++, or any
other), and code that needs t
Steven Schveighoffer wrote:
"Andrei Alexandrescu" wrote
If Retro.empty is const and Range.empty is not, that won't compile. If
Retro.empty is non-const and Range.empty is const, it will compile, but
passing a const Retro won't work as well as passing a const Range.
Hm... you need the template
Steven Schveighoffer Wrote:
> "Andrei Alexandrescu" wrote
> > I'm working on the new range stuff and the range-based algorithm. In all
> > likelihood, you all might be pleased with the results.
> >
> > I wanted to gauge opinions on a couple of issues. One is, should the
> > empty() member functi
Steven Schveighoffer wrote:
"Andrei Alexandrescu" wrote
I realized that properties are not a complete model for actual data. The
current conventional wisdom about properties goes like this (T is some
type):
class Host
{
property prop
{
T get() { ... }
void set(T value)
"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> There are two possibilities that I can think of.
>>
>> 1. ref return from get, which gets you part-way there. You can still do
>> some useful things like which member you are returning getting
>> calculated, but it doesn't make the cal
Steven Schveighoffer wrote:
I guess I'm not really sure what the "acquire" method does. I saw you
mention it in another post, but with no explanation as to what it actually
does, just that it was needed. I'm sure I'm not getting what should be
obvious, but if you could enlighten, I would appr
"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> I guess I'm not really sure what the "acquire" method does. I saw you
>> mention it in another post, but with no explanation as to what it
>> actually does, just that it was needed. I'm sure I'm not getting what
>> should be obvious,
On Tue, 27 Jan 2009 01:52:26 +0300, Steven Schveighoffer
wrote:
"Andrei Alexandrescu" wrote
Steven Schveighoffer wrote:
I guess I'm not really sure what the "acquire" method does. I saw you
mention it in another post, but with no explanation as to what it
actually does, just that it was nee
On Mon, 26 Jan 2009 20:54:38 +0300, Nick Sabalausky wrote:
"bearophile" wrote in message
news:glk5pj$22r...@digitalmars.com...
It seems one group of ideas and syntax I did suggest for D weren't so
Krazy, after all. I have just found that they can be seen almost equal
in
C#.
You can read s
On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <2kor...@gmail.com> wrote:
Steven Schveighoffer Wrote:
"Andrei Alexandrescu" wrote
> I'm working on the new range stuff and the range-based algorithm. In
all
> likelihood, you all might be pleased with the results.
>
> I wanted to gauge opi
Mon, 26 Jan 2009 08:06:05 -0800, Andrei Alexandrescu wrote:
> Anyhow, here's a simple D example. Consider we define a BigInt type as a
> value-type struct: when you copy a BigInt to another, the latter becomes
> an independent copy:
>
> BigInt a = 100;
> BigInt b = a;
> ++b;
> assert(a == 100);
Sergey Gromov wrote:
Mon, 26 Jan 2009 08:06:05 -0800, Andrei Alexandrescu wrote:
Anyhow, here's a simple D example. Consider we define a BigInt type as a
value-type struct: when you copy a BigInt to another, the latter becomes
an independent copy:
BigInt a = 100;
BigInt b = a;
++b;
assert(a
Sun, 25 Jan 2009 13:53:43 -0800, Andrei Alexandrescu wrote:
> Christopher Wright wrote:
>> Andrei Alexandrescu wrote:
>>> Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
> I'm working on the new range stuff and the range-based algorithm. In
> all
Sun, 25 Jan 2009 13:51:28 -0800, Andrei Alexandrescu wrote:
> Christopher Wright wrote:
>> Andrei Alexandrescu wrote:
>>> Never ever *ever* EVER *EVER* email a password in clear. I'd say, if
>>> anyone thinks she wants to do that, she doesn't deserve a server that
>>> understands basic security
"Denis Koroskin" wrote
> On Mon, 26 Jan 2009 23:37:25 +0300, Denis Koroskin <2kor...@gmail.com>
> wrote:
>> Checking if a range is empty() prior to accessing its head is useful. If
>> empty() is const, you can't do that.
>
> Err.. if empty() is not const and you have a const range reference.
emp
"Denis Koroskin" wrote
> On Tue, 27 Jan 2009 01:52:26 +0300, Steven Schveighoffer
> wrote:
>
>> "Andrei Alexandrescu" wrote
>>> Steven Schveighoffer wrote:
I guess I'm not really sure what the "acquire" method does. I saw you
mention it in another post, but with no explanation as to wh
"Andrei Alexandrescu" wrote
> Probably many people would expect to just write this:
>
> void foo(in SomeRange range) { ... }
>
> and have foo look at the range and its elements no problem, without
> actually iterating through the range.
Consider that some type const Range!(T), where T is a refer
Sergey Gromov wrote:
Sun, 25 Jan 2009 13:51:28 -0800, Andrei Alexandrescu wrote:
Christopher Wright wrote:
Andrei Alexandrescu wrote:
Never ever *ever* EVER *EVER* email a password in clear. I'd say, if
anyone thinks she wants to do that, she doesn't deserve a server that
understands basic s
Sergey Gromov wrote:
Sun, 25 Jan 2009 13:53:43 -0800, Andrei Alexandrescu wrote:
Christopher Wright wrote:
Andrei Alexandrescu wrote:
Sergey Gromov wrote:
Sat, 24 Jan 2009 17:09:07 -0800, Andrei Alexandrescu wrote:
I'm working on the new range stuff and the range-based algorithm. In
all li
On 2009-01-26 14:21:18 -0500, Walter Bright said:
I guess it's reasonable to argue that using the floating-point flags is
sufficiently hard-core that pure and nothrow should pretend that they
don't exist.
Still, some functions (especially correctly-rounded floating-point i/o)
go to a lot of
Andrei Alexandrescu:
>Probably array and assign will make the cut as well.<
assign() of my libs is an ugly hack, I'd like such feature to be built-in in
the language, with the comma syntax:
a, b = foo(...)
I use such syntax all the time in Python and it's quite handy.
Something like my Record/r
I was forgetting, Clojure (the nice lisp variant that works on the JavaVM) also
has pmap(), a parallel map() function, that executes the functions in parallel,
on different CPU cores. Such stuff can become quite useful in D2 too:
http://clojure.org/api#toc571
Bye,
bearophile
55 matches
Mail list logo
