On 04/10/15 19:14, welkam wrote:
On Sunday, 4 October 2015 at 12:40:00 UTC, rsw0x wrote:
these tools are not very good and they don't help when the standard
library(...or builtin language features...) use the GC and tie your hands
IMO tools for memory management in D are way better than that
On 05/10/15 10:01, Dmitry Olshansky wrote:
When D structs has a destructor that is guaranteed to run for any
instance that finished construction, no matter what is the use case,
then we can have that discussion.
Supposed to be the case for structs except for any bugs.
Check this one out
On 05/10/15 10:40, deadalnix wrote:
Guaranteed construct/destruction is actually a desirable feature IMO.
You get all kind of extra case int he dtor to care for when you can't
ensure proper construction, and it is not always possible to have a
meaningful .init value, leading to many useless
On 05/10/15 10:49, Dmitry Olshansky wrote:
Yes and no, if your type is movable in C++ you have to have a T.init
equivalent to leave something behind after move (oops!).
No, under C++ you can choose whether it makes sense for your type to be
movable or not. No oops at all.
C++ does not make
On 05/10/15 13:39, Marc Schütz wrote:
On Monday, 5 October 2015 at 09:25:30 UTC, Shachar Shemesh wrote:
What's more, init is used even if you @disable this(). The following
compile and does what you'd expect (but not what you want):
struct S {
int d;
@disable this();
this( int d ) {
On 23/08/15 22:12, Walter Bright wrote:
On 8/23/2015 11:42 AM, deadalnix wrote:
No, x32 is basically amd64 with 32 bits pointers. You can use all other
functions of amd64, like the extended number of registers.
Makes sense.
At least right now, it sounds more useful than it actually is.
On 19/08/15 15:01, Kagamin wrote:
Just switch your editor to RTL mode, haha.
OT: (so this is an off topic reply to an off topic thread)
I actually tried to write a good RTL text editor (you can see the half
baked result at http://bidiedit.lingnu.com). I know your comment was
meant as a
On 14/08/15 17:57, Andrei Alexandrescu wrote:
I stumbled upon https://software.intel.com/en-us/node/471374 which gives
good detail on Intel's Math Kernel Library's data formats for sparse
matrices.
No doubt other popular linear algebra libraries have similar
documentation. I was thinking we
On 11/07/15 06:02, Nick B wrote:
On Thursday, 20 February 2014 at 10:10:13 UTC, Nick B wrote:
Hi everyone.
John Gustafson Will be presenting a Keynote on Thursday 27th February
at 11:00 am
The abstract is here:
http://openparallel.com/multicore-world-2014/speakers/john-gustafson/
There
On 08/07/15 15:08, Jonathan M Davis wrote:
I know that there are a number of people who get frustrated with shared
and using __gshared instead, but unless you fully understand what you're
doing and how the language works, and you're _really_ careful, you're
going to shoot yourself in the foot it
On 20/06/15 12:37, Martin Nowak wrote:
Which also comes with the usual e-mail benefit, people think a lot more
before hitting send.
You talk like someone who's never seen a flame war.
Shachar
On 14/06/15 04:31, Adam D. Ruppe wrote:
On Sunday, 14 June 2015 at 00:52:20 UTC, FujiBar wrote:
I have read that in D structs are always allocated on the stack while
classes are always allocated on the heap.
That's not true; it is a really common misconception.
Putting a struct on the heap
On 14/06/15 20:01, bitwise wrote:
On Sun, 14 Jun 2015 12:52:47 -0400, ketmar ket...@ketmar.no-ip.org wrote:
so it's by design.
Ok, makes sense ;)
Bit
Well, sortof.
It makes sense, until you try to compile a program that needs more
memory than your computer has. Then, all of a
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local variable diskIdx, and
they are confusing, what it has to do with UFCS?
auto diskIdx = data.diskIdx();
On 10/06/15 17:05, Kagamin wrote:
On Wednesday, 10 June 2015 at 13:43:45 UTC, Shachar Shemesh wrote:
On 10/06/15 15:37, Kagamin wrote:
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote:
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local
On 10/06/15 15:37, Kagamin wrote:
On Wednesday, 10 June 2015 at 08:53:40 UTC, Shachar Shemesh wrote:
On 10/06/15 11:31, Kagamin wrote:
Huh? If you have type's method diskIdx and a local variable diskIdx, and
they are confusing, what it has to do with UFCS?
auto diskIdx = data.diskIdx();
On 10/06/15 09:14, deadalnix wrote:
I do think you think at it the wrong way. people are not telling you it
is bad code. You are telling us it is bad code (because you mention
having problem that people using other style do not have).
It is not a problem in C++. It is not a problem with no
On 09/06/15 10:21, Paulo Pinto wrote:
It is no different than extension methods in .NET, Ceylon, Kotlin,
multi-methods in CLOS or implicits in Scala.
I never could understand that line of reasoning:
Argument: So and so is bad because A
Answer: X, Y, and Z also do so and so
How is the answer
On 09/06/15 11:17, Kagamin wrote:
Not sure what you compare it to. Even finding declaration was never an
easy job in C, and definition can be anywhere in the source tree. In D
symbols are at least tied to modules, so you can look only in the
respective module, this never worked for C though.
On 09/06/15 11:35, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
I agree, I have conventions in my C++ code where member functions and
free functions shouldn't mix.
But given C++ templates lack of type safety, I'm not surprised that BS
pushes it. It also
On 08/06/15 22:24, Walter Bright wrote:
Unified call syntax. This proposal, by Bjarne, seeks to unify the
member (x.f(y)) and non-member (f(x, y)) call syntaxes by allowing
functions of either kind to be invoked by syntax of either kind.
Dear god, I hope this doesn't pass.
It is one of the
On 09/06/15 10:27, Joakim wrote:
Perhaps Dscanner's declaration finder (the -d flag) or DCD would make
your life easier. I use Dscanner all the time and miss it when I'm
stuck with grep for C nowadays:
https://github.com/Hackerpilot/Dscanner
https://github.com/Hackerpilot/DCD
I use DCD, and
On 09/06/15 22:39, Walter Bright wrote:
I usually try to select identifiers that are easy to grep. So unless one
has a penchant for naming functions f(), in practice it isn't a
significant issue.
The difference between theory and practice is that, in theory, there is
no difference between
On 10/06/15 00:29, Walter Bright wrote:
First off, D does not allow shadowing local variable declarations.
Secondly, if you've got a lot of global variables, you've got a program
design problem anyway. And lastly, naming everything diskIdx is a
problem of your own creation.
The first one is
On 08/06/15 06:35, Jonathan M Davis wrote:
They're not polymorphic, and it doesn't make sense to call a base class
constructor on a derived class. I think that I heard somewhere that
C++11 added some sort of constructor inheritance
No, it didn't.
What C++11 added was the ability to use the
On 05/06/15 16:44, Dmitry Olshansky wrote:
* You seem to assume the same. Fine assumption given that OS usually
tries to keep the same cores working on the same threads, for the
similar reasons I believe.
I see that people already raised the point that the OS does allow you to
pin a thread
On 02/06/15 21:56, weaselcat wrote:
On Monday, 1 June 2015 at 15:40:55 UTC, Steven Schveighoffer wrote:
My original statement was obviously exaggerated, I would not put up
with days-long compile times, I'd find another way to do development.
But compile time is not as important to me as it is
On 01/06/15 18:40, Steven Schveighoffer wrote:
On 5/30/15 2:38 PM, Shachar Shemesh wrote:
So given that a compiler actually *works* (i.e. produces valid
binaries), is speed of compilation better than speed of execution of the
resulting binary?
There is no answer to that question.
During
On 30/05/15 21:44, Iain Buclaw via Digitalmars-d wrote:
Got any bug reports to back that up? I should probably run the
testsuite with optimisations turned on sometime.
The latest one (the one that stung my code) is
http://bugzilla.gdcproject.org/show_bug.cgi?id=188. In general, the bugs
On 31/05/15 02:08, Manu via Digitalmars-d wrote:
On 31 May 2015 at 04:39, Shachar Shemesh via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:
When he says Windows, he means MSVC, gcc backend will never support
interfacing that ABI
On 30/05/15 11:00, Iain Buclaw via Digitalmars-d wrote:
When he says Windows, he means MSVC, gcc backend will never support
interfacing that ABI (at least I see no motivation as of writing).
I thought that's what MINGW was. A gcc backend that interfaces with the
Windows ABI. Isn't it?
On 30/05/15 03:57, Steven Schveighoffer wrote:
I saw the slide from Liran that shows your compiler requirements :) I
can see why it's important to you.
Then you misunderstood Liran's slides.
Our compile resources problem isn't with GDC. It's with DMD. Single
object compilation requires more
On 13/05/15 12:29, Maxim Fomin wrote:
Giving how D is similar to C/C++ I am surprised that non-familiriarity
with D is a big problem.
D is a fairly complex language (far too complex, IMHO, relative to its
age). Its complexities are both different than C++, and also of a
different kind.
I
On 13/05/15 08:48, Walter Bright wrote:
On 5/12/2015 10:13 PM, Shachar Shemesh wrote:
And this is before mentioning stability. I've lost count of the number
of times
my compilation failed with an assert thrown by dmd, and just last week
I've had
to refactor the code around a consistent
On 12/05/15 21:35, FujiBar wrote:
Walter would probably violently disagree with the no decent development
tools assessment. But I got to say that people used to Visual Studio
and XCode (like myself) not being impressed by D's 1980s-style bare
basic command line tools is not surprising.
I don't
Hi all,
Please consider the following program:
void main() {
int array[13];
int[] internalFunc() {
return array;
}
}
This code does not compile (dmd 2.066.1), claiming:
test.d(5): Error: escaping reference to local array
The way I see it, the array in question is in scope
On 06/05/15 10:28, Shachar Shemesh wrote:
Hi all,
Please consider the following program:
void main() {
int array[13];
int[] internalFunc() {
return array;
}
}
This code does not compile (dmd 2.066.1), claiming:
test.d(5): Error: escaping reference to local array
The
On 22/04/15 04:42, Daniel Murphy wrote:
Colin wrote in message news:sbafvqyzjweacrhwd...@forum.dlang.org...
I notice when you run dmd with no args, it will print:
DMD64 D Compiler v2.067.0
Copyright (c) 1999-2014 by Digital Mars written by Walter Bright
Surely that's meant to be 2015?
Walter
On 19/04/15 22:58, ketmar wrote:
On Sun, 19 Apr 2015 07:54:36 +, John Colvin wrote:
it's not crazy, it's just broken in all possible ways:
http://file.bestmx.net/ee/articles/uni_vs_code.pdf
This is not a very accurate depiction of Unicode.
For example:
And, moreover, BOM is meaningless
On 19/04/15 10:51, Abdulhaq wrote:
MiOn Sunday, 19 April 2015 at 02:20:01 UTC, Shachar Shemesh wrote:
On 18/04/15 21:40, Walter Bright wrote:
Also, notice that some letters can only be achieved using multiple
code points. Hebrew diacritics, for example, do not, typically, have a
composite
On 18/04/15 21:40, Walter Bright wrote:
I'm not arguing against the existence of the Unicode standard, I'm
saying I can't figure any justification for standardizing different
encodings of the same thing.
A lot of areas in Unicode are due to pre-Unicode legacy.
I'm guessing here, but looking
On 17/04/15 19:59, H. S. Teoh via Digitalmars-d wrote:
There's also the question of what to do with bidi markings: how do you
handle counting the columns in that case?
Which BiDi marking are you referring to? LRM/RLM and friends? If so,
don't worry: the interface, as described, is incapable
On 08/04/15 02:58, Idan Arye wrote:
On Tuesday, 7 April 2015 at 22:58:44 UTC, weaselcat wrote:
Hi, I hope nobody minds but I'm just curious as to the popularity
amongst D IDEs for a blog post. Sorry if I forgot your favorite $editor.
http://goo.gl/forms/MmsuInzDL0
thanks : )
Vim. The only
On 08/03/15 15:56, w0rp wrote:
So if you want something to work as of right now, do that.
I realize that. What I'm saying is that this is unacceptable. This
violates D's own standard.
From http://dlang.org/exception-safe.html:
The RAII (Resource Acquisition Is Initialization) idiom and
On 07/03/15 23:44, w0rp wrote:
Why not handle the scope(failure) cases in the constructor itself?
Because this breaks encapsulation.
struct SomeStruct {
SomeOtherStruct a;
MoreStruct b;
this(int c) {
this.a = SomeOtherStruct(c);
this.b
On 07/03/15 07:09, Steven Schveighoffer wrote:
That's pretty horrible. So now I need to keep track of the
implementation of my members to figure out whether it is okay to skip
the destructor or not.
Why does it matter? If the member is constructed, insert a
scope(failure) destroy, otherwise
On 04/03/15 17:43, Steven Schveighoffer wrote:
On 3/4/15 8:43 AM, Shachar Shemesh wrote:
I'd expect A's destructor to run, which does not seem to be the case.
I believe destructors are not run when you throw inside a constructor.
So plan to deallocate if the ctor throws:
a = A(var + 1);
On 05/03/15 04:09, deadalnix wrote:
On Wednesday, 4 March 2015 at 19:36:20 UTC, Ali Çehreli wrote:
Even C++ gets this right.
Ali
Nop, I do think C++ destroy uninitialized fields.
I'm sorry, but you are wrong.
In C++, a destructor is run for fully constructed objects. Fully
constructed is
import std.stdio;
struct A {
int a = 3;
this( int var ) {
a += var;
}
~this() {
writeln(A down , a);
}
}
struct B {
A a;
this( int var ) {
a = A(var+1);
throw new Exception(An exception);
}
}
void main()
{
try {
I have a standard processing that needs to be done over and over again,
with an inner function that is different between invocations. Here is a
small sample that illustrates the need:
import std.stdio;
alias dtype = void delegate(int i);
void func(T)( T d )
{
foreach(i; 0 .. 10) {
On 31/12/14 15:52, Adam D. Ruppe wrote:
Try writing that:
void func(scope dtype d)
Yep. That's exactly what I was looking for. On GDC it even allows for
complete compile time evaluation of the entire loop.
Thanks,
Shachar
On 31/12/14 23:48, ketmar via Digitalmars-d wrote:
On Wed, 31 Dec 2014 13:52:02 +
Adam D. Ruppe via Digitalmars-d digitalmars-d@puremagic.com wrote:
Try writing that:
void func(scope dtype d)
an it's so well hidden that not many people know about it. being a not
very careful reader
Hi all,
Please consider the following program:
int main()
{
version(assert) int var;
assert(var == 0);
return 0;
}
When compiled with dmd test.d, it passes without a problem. When
compiled with dmd test.d -release, it produces the following error:
test.d(5): Error: undefined
On 17/12/14 17:02, Adam D. Ruppe wrote:
On Wednesday, 17 December 2014 at 13:13:43 UTC, Shachar Shemesh wrote:
It just seems like extra unneeded superfluous unnecessary redundancy.
It is somewhat important because storing a slice to a static array is a
big problem:
Any time you pass by
The subject pretty much says it all.
If I have a function:
void function(int[] arr);
I'd like to be able to call it with:
int[12] a;
function(a);
I know I can do:
function(a[]);
It just seems like extra unneeded superfluous unnecessary redundancy. I
don't see any static typing
Please consider the following program:
import std.exception;
void main()
{
struct A {
int a;
@disable this(this);
@disable ref A opAssign(const ref A);
ref A opOpAssign(string op: ~)(int data) {
a += data;
return this;
}
On 09/12/14 02:45, deadalnix wrote:
On Monday, 8 December 2014 at 15:44:55 UTC, Stefan Koch wrote:
I want to do a C backend first.
Building an LLVM Backand out of that is a small step.
There is already a very popular C to C compiler out there. It is
called cat, and come out of the box with
On 12/11/14 11:29, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote:
Supposedly, a struct destructor will only access resources that the
struct itself manages. As long as that's the case, it will be safe. In
practice, there's still a lot that can go wrong.
Either a struct's destructor can
On 10/11/14 16:19, Steven Schveighoffer wrote:
Only classes call dtors from the GC. Structs do not. There are many
hairy issues with structs calling dtors from GC. Most struct dtors
expect to be called synchronously, and are not expecting to deal with
multithreading issues.
Note that structs
On 11/11/14 22:41, Steven Schveighoffer wrote:
At this point, I am not super-concerned about this. I cannot think of
any bullet-proof way to ensure that struct dtors for structs that were
meant only for stack variables can be called correctly from the GC.
Isn't structs meant only for stack
For reasons I won't go into (but should be fairly obvious), I am trying
to write code that does not rely on the garbage collector. As such, I'm
using reference counting structs allocated on a pool.
To keep things sane, I'm trying to use RAII semantics, and to that end,
a smart pointer that
On 27/10/14 11:31, Szymon Gatner wrote:
Right, sorry. Tho I admit I made assumptions since that was not the full
code.
I've opened a bug. It has a fully contained sample (that does not, in
fact, implement smartptr).
https://issues.dlang.org/show_bug.cgi?id=13661
I am trying to debug an application compiled with no optimizations with
dmd v2.065. I am trying to debug with gdb 7.7-0ubuntu3.1.
When I try to access certain variables (some local, some class members),
here is the session I am getting:
(gdb) p stripeWidth
Internal error: `this' is not an
On 17/09/14 16:32, ketmar via Digitalmars-d-learn wrote:
On Wed, 17 Sep 2014 13:20:13 +
Shachar via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
From http://dlang.org/type, under Usual Arithmetic Conversions:
4. Else the integer promotions are done on each operand,
301 - 364 of 364 matches
Mail list logo
