On Tuesday, 31 July 2012 at 00:21:59 UTC, bearophile wrote:
Jonathan M Davis:
I'd actually argue that structs without opCmp shouldn't have
it implicitly defined. It's just begging for bugs otherwise.
For reference, this is the issue we are talking about:
On Monday, 30 July 2012 at 22:58:28 UTC, Timon Gehr wrote:
On 07/31/2012 12:30 AM, maarten van damme wrote:
2012/7/31 Timon Gehrtimon.g...@gmx.ch:
...
further comments whose application does not lead to immediate
benefit:
- in contracts are better specified in their dedicated
section to
On Tuesday, 31 July 2012 at 05:27:58 UTC, Philippe Sigaud wrote:
No. Use a 3-params template or a tuple:
void func(A,B,C)(X!(A,B,C) x) {}
or
void func(Ts...)(X!(Ts) x) {}
I don't know how many arguments it will have (depends on how
many options I give it), and I honestly don't; It should be
On Monday, 30 July 2012 at 22:23:10 UTC, Timon Gehr wrote:
On 07/30/2012 03:52 PM, monarch_dodra wrote:
...
NaN then compares false with everything, making it
un-transitive, and
potentially breaking your cmp. COuld you try the algo with
return
1/(1+travelled).
That, or because of the
On 29/07/12 23:36, bearophile wrote:
Era Scarecrow:
Another commonly needed operation is a very fast bit count. There
are very refined algorithms to do this.
Likely similar to the hamming weight table mentioned in TDPL.
Combined with the canUseBulk I think I could make it fairly fast.
I now tried to bring it to the next level, using concurrency to bread
a couple of populations and make the best solutions migrate between
them.
But, to use concurrency in D, one has to continually cast between
immutable, cast immutable away,
Not only that, casting away from immutable (or too,
On Tuesday, July 31, 2012 11:41:19 maarten van damme wrote:
I now tried to bring it to the next level, using concurrency to bread
a couple of populations and make the best solutions migrate between
them.
But, to use concurrency in D, one has to continually cast between
immutable, cast
I agree that having the compiler make warnings about unused
variables is a really good idea!!!
Java has it and when I program in eclipse it's really useful
because the editor can highlight the particular lines.
On Tuesday, 31 July 2012 at 00:44:16 UTC, Andrej Mitrovic wrote:
On 7/31/12, Era Scarecrow rtcv...@yahoo.com wrote:
It assumes the largest type we can currently use which is
ulong
Ah yes, it makes sense now. Thanks for the brain cereal. :p
I saw your bug report:
On 07/31/2012 11:55 AM, Minas wrote:
I agree that having the compiler make warnings about unused
variables is a really good idea!!!
Java has it and when I program in eclipse it's really useful
because the editor can highlight the particular lines.
An editor can be configured to point it out
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW. bitfields
works quite nice with 33 or whatever. More details in the report.
Yeah 32 or 64 bits, thanks for changing the title.
On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW.
bitfields works quite nice with 33 or whatever. More details
in the report.
Yeah 32 or 64 bits, thanks for changing
On 7/31/12, Era Scarecrow rtcv...@yahoo.com wrote:
I wonder, is it really a bug? If you are going to have it fill a
whole size it would fit anyways, why even put it in as a
bitfield? You could just declare it separately.
I don't really know, I'm looking at this from a point of wrapping C++.
On Tuesday, 31 July 2012 at 16:48:37 UTC, Andrej Mitrovic wrote:
On 7/31/12, Era Scarecrow rtcv...@yahoo.com wrote:
I wonder, is it really a bug? If you are going to have it fill
a whole size it would fit anyways, why even put it in as a
bitfield? You could just declare it separately.
I
On Tuesday, 31 July 2012 at 16:16:00 UTC, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW.
bitfields works quite nice with 33 or whatever. More
On Tuesday, 31 July 2012 at 16:59:11 UTC, monarch_dodra wrote:
No, it's a bug. There is no reason for it to fail (and it
certainly isn't a feature).
If I made two fields in a 64bit bitfield, each 32bits int's I'd
like it to complain; If it's calculated from something else then
finding the
On 07/31/2012 06:57 PM, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 16:48:37 UTC, Andrej Mitrovic wrote:
On 7/31/12, Era Scarecrow rtcv...@yahoo.com wrote:
I wonder, is it really a bug? If you are going to have it fill a
whole size it would fit anyways, why even put it in as a bitfield?
On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
(Also IMO, the once-in-a-year wtf that is caused by
accidentally assigning in an if condition does not justify
special casing assignment expressions inside if conditions.
Also, what is an useless compare?)
I've noticed in my
On Tuesday, 31 July 2012 at 17:17:25 UTC, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 16:59:11 UTC, monarch_dodra wrote:
Maybe the user needs a 32 bit ulong? This way the ulong only
takes 32 bits, but can still be implicitly passed to functions
expecting ulongs.
I would think the bug
On Tuesday, 31 July 2012 at 17:34:33 UTC, monarch_dodra wrote:
No, the bug shows itself if the first field is 32 bits,
regardless of (ulong included).
I would add though that requesting a field in bits that is
bigger than the type of the field should not work (IMO). EG:
struct A
{
On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
This is obviously a mistake in the bitfield implementation.
What else could be concluded from the error message:
std\bitmanip.d(76): Error: shift by 32 is outside the range
0..31
Requesting a 32 bit or 64 bit member on the other
On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
This is obviously a mistake in the bitfield implementation.
What else could be concluded from the error message:
std\bitmanip.d(76): Error: shift by 32 is outside the range
0..31
Requesting a 32 bit or 64 bit member on the other
On Monday, 30 July 2012 at 20:56:30 UTC, Jonathan M Davis wrote:
On Monday, July 30, 2012 23:44:56 cybevnm wrote:
During initializing Variant, D discards top level const of
array, which
leads to little unintuitive behaviour. Consider code:
import std.stdio;
import std.variant;
void main()
{
On 07/31/2012 09:15 AM, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 15:25:55 UTC, Andrej Mitrovic wrote:
On 7/31/12, monarch_dodra monarchdo...@gmail.com wrote:
The bug is only when the field is EXACTLY 32 bits BTW. bitfields
works quite nice with 33 or whatever. More details in the
Thank you for your reply.
I have some more questions:
I simplified my example. Now my monitor is used for mutual
exclusion, to understand how monitors work first.
// 3 threads are running P() - the main thread is not one of them
void P()
{
while( run )
{
On 31-Jul-12 22:21, Era Scarecrow wrote:
On Tuesday, 31 July 2012 at 17:17:43 UTC, Timon Gehr wrote:
This is obviously a mistake in the bitfield implementation. What else
could be concluded from the error message:
std\bitmanip.d(76): Error: shift by 32 is outside the range 0..31
Requesting a
On Tuesday, 31 July 2012 at 09:41:31 UTC, maarten van damme wrote:
I now tried to bring it to the next level, using concurrency to
bread
a couple of populations and make the best solutions migrate
between
them.
But, to use concurrency in D, one has to continually cast
between
immutable, cast
On Tuesday, 31 July 2012 at 20:41:55 UTC, Dmitry Olshansky wrote:
On 31-Jul-12 22:21, Era Scarecrow wrote:
Well curiously it was easier to fix than I thought (a line for
a static if, and a modification of the masking)... Was there
any other bugs that come to mind? Anything of consequence?
28 matches
Mail list logo
