Re: What D related (or interesting development based) twitter accounts do you guys follow?
On Sunday, 28 July 2013 at 16:57:54 UTC, Gary Willoughby wrote: What D related (or interesting development based) twitter accounts do you guys follow? I'm pretty new to twitter and trying to follow accounts that i find interesting. Just remembered when reading this: http://www.viva64.com/en/b/0302/ "Twitter for C++ Programmers (updated)" it appeared here: https://isocpp.org/blog/2015/01/twitter-for-c-programmers-andrey-karpov Yes, it's about C++, but it mentions: WalterBright - @WalterBright - Digital Mars C, C++, D programming language compilers, and Javascript compiler. Andrei Alexandrescu - @incomputable - Please refer to my website for bio and contact information.
For those ready to take the challenge
https://codegolf.stackexchange.com/questions/44278/debunking-stroustrups-debunking-of-the-myth-c-is-for-large-complicated-pro
Re: Destructor/Finalizer Guarantees
On Wednesday, 12 November 2014 at 14:36:19 UTC, Kagamin wrote: With GC you usually have two destructors: Which is why this approach is so cumbersome. At least, in non-GC you only have just one kind of destructor.
Re: Cast to left hand side
On Monday, 10 November 2014 at 05:00:25 UTC, tcak wrote: On Sunday, 9 November 2014 at 21:47:03 UTC, eles wrote: On Sunday, 9 November 2014 at 19:00:01 UTC, tcak wrote: Because I am auto casting with a keyword, compiler shouldn't complain about it as well. This can also solve "uncast" thing. Is not the same. Auto or not, this is still an explicit cast. I was asking for a cast to be limited to the attribute that is targeted, and let data format unchanged. The two are fairly different notions, because one specifies the format of the data, the other specifies permissions on that data.
Re: status of D optimizers benefiting from contracts ?
On Sunday, 9 November 2014 at 16:31:46 UTC, bearophile wrote: H. S. Teoh: It's only a bad idea because people abuse assert() where it's not appropriate. It's a bad idea because Walter seems unable to understand the difference between verifying and proving. I fail to see the difference between assert() and a hypothetical assume().
Re: Cast to left hand side
On Sunday, 9 November 2014 at 19:00:01 UTC, tcak wrote: In some cases, I need to cast right hand side expression to left hand side. While it looks/feels simple for basic data types, it requires long lines with duplication when flexible code is desired to be written. Example: int a = 7; byte b; b = cast( byte )a; I am also strongly in favor of introducing an "uncast". For example, in C++'x const_cast and in D's cast for removing, for example immutability: immutable int* p = ...; int* q = cast(int*)p; I think the goal is not clearly expressed with this cast. It does not show that it's intension is to remove immutability and otherwise let that type unchanged. If later a mismatch is introduced between the left and the right type of data, that inoffensive cast could create problems by hiding an error that should have been spotted. Something like that would be more expressive: immutable int* p = ...; int* q = uncast(immutable)p; //or int* q = cast(~immutable)p; This way, invalid implicit conversions from p's type to q's type would be spotted.
Re: Destructor order
On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote: On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote: D version: `foo` should be a `Scoped!A`. When it's typed as `A`, the `Scoped!A` that is returned by `scoped`, is destructed immediately (and the reference leaks, I guess). And the compiler swallows this without even barking? Why Scoped!A is convertible to A, then? And what the resulting A-typed variable contains if the object gets destroyed. And what use for that content?
Re: Destructor order
On Wednesday, 22 October 2014 at 18:03:44 UTC, anonymous wrote: On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote: `foo` should be a `Scoped!A`. When it's typed as `A`, the `Scoped!A` that is returned by `scoped`, is destructed immediately (and the reference leaks, I guess). Just tell me that's a feature, not a bug...
Re: Destructor order
On Wednesday, 22 October 2014 at 17:13:35 UTC, Ola Fosheim Grøstad wrote: On Wednesday, 22 October 2014 at 16:55:41 UTC, Regan Heath So why wasn't the eles' destructor order in reverse if Scoped is a struct and calls explicit destroy(B) then destroy(A)? Maybe it's the writeln() inside the destructor which behaves badly, albeit the same should have happened for structs too.
Re: Destructor order
On Wednesday, 22 October 2014 at 15:45:02 UTC, eles wrote:
D version with structs:
{ //display ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
as expected.
Destructor order
C++ versions:
{ //displays ~C~B~A
A foo;
B bar;
C *caz = new C();
delete caz;
}
std::cout << std::endl;
{ //displays ~C~B~A
std::unique_ptr foo = std::make_unique();
std::unique_ptr bar = std::make_unique();
C *caz = new C();
delete caz;
}
D version:
{ //displays ~A~B~C
A foo = scoped!(A)();
B bar = scoped!(B)();
C caz = new C();
destroy(caz);
}
Why the objects are not destroyed in the inverse order of their
creation? Case in point, destroying foo releases a lock for bar
and caz.
Re: How to match string by word
On Friday, 17 October 2014 at 16:39:38 UTC, Uranuz wrote: I haven't touched any key on a keyboard and haven't pressed *Send* but message was posted somehow. Scan for rootkits...
Re: Beginner ?. Why does D suggest to learn java
On Friday, 17 October 2014 at 13:59:03 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 17 Oct 2014 10:10:09 +0200 spir via Digitalmars-d-learn wrote: computer programming is the literacy of the new age. Let's say, computer knowledge. There are also database administrators, package maintainers, network administrators etc. Knowledge of all is useful, not only the knowledge of programmers. Add builders, engineers, loggers (those with axes) and medics to the list...
Re: When betterC triggers errors in compilation?
On Tuesday, 14 October 2014 at 13:31:47 UTC, Adam D. Ruppe wrote: On Tuesday, 14 October 2014 at 13:20:50 UTC, eles wrote: http://forum.dlang.org/post/lddug4$jgv$1...@digitalmars.com -betterC right now is still an undocumented hack that doesn't do much. Thank you.
When betterC triggers errors in compilation?
Hello,
According to this:
http://forum.dlang.org/post/lddug4$jgv$1...@digitalmars.com
"-betterC" should disable support for exception handling. So I
expected dmd to reject the following code:
===
import std.stdio;
int readDieFromFile()
{
auto file = File("the_file_that_contains_the_value", "r");
int die;
file.readf(" %s", &die);
return die;
}
int tryReadingFromFile()
{
int die;
try {
die = readDieFromFile();
} catch (std.exception.ErrnoException exc) {
writeln("(Could not read from file; assuming 1)");
die = 1;
}
return die;
}
void main()
{
const int die = tryReadingFromFile();
writeln("Die value: ", die);
}
===
(from Ali's book; thanks once again)
But it compiles and runs fine:
$dmd betterC.d -betterC
$./betterC
(Could not read from file; assuming 1)
Die value: 1
This is with dmd 2.066 on Linux x86_64.
What code would fail under -betterC and how?
Re: Code fails with linker error. Why?
On Monday, 6 October 2014 at 19:03:13 UTC, John Colvin wrote: On Monday, 6 October 2014 at 16:04:02 UTC, eles wrote: On Monday, 6 October 2014 at 15:44:36 UTC, John Colvin wrote: On Monday, 6 October 2014 at 12:36:41 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 06 Oct 2014 11:54:55 + John Colvin via Digitalmars-d-learn In order to get access to private variables from another compilation unit, yes, you need some nasty hackiness. I haven't presented such a hack though. I know. Was not serious.
Re: Code fails with linker error. Why?
On Monday, 6 October 2014 at 15:44:36 UTC, John Colvin wrote: On Monday, 6 October 2014 at 12:36:41 UTC, ketmar via Digitalmars-d-learn wrote: On Mon, 06 Oct 2014 11:54:55 + John Colvin via Digitalmars-d-learn wrote: I disagree. It's simple and easy to understand. and hackish. D is very amenable to slightly hackish code. This is the only genuine problem I can see that requires a language extension. Separating class definition from method definition in to different compilation units doesn't allow access to private members without very nasty hacks. no hacks needed. I meant that without a language change, one does need hacks. So, you admit it is a hack! Gotcha!
Re: Code fails with linker error. Why?
On Monday, 6 October 2014 at 13:23:55 UTC, John Colvin wrote: On Monday, 6 October 2014 at 12:16:14 UTC, eles wrote: On Monday, 6 October 2014 at 11:54:56 UTC, John Colvin wrote: On Monday, 6 October 2014 at 10:10:04 UTC, eles wrote: On Saturday, 4 October 2014 at 15:29:57 UTC, John Colvin wrote: On Saturday, 4 October 2014 at 11:19:52 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 04 Oct 2014 11:01:28 + John Colvin via Digitalmars-d-learn This isn't a problem. You're not going to get the name-mangling right by accident. Even for free functions the module name is mangled in. It is. I could erase the definition of an identical class in another .d file and accidentally leave an orphan definition method therein. The only way this can happen is with extern(C) functions, which is because C doesn't mangle it's function names. This too is a hole. Why to leave holes? I like the "fromage à trous": http://fr.wikipedia.org/wiki/Paradoxe_du_fromage_à_trous But not in my software.
Re: Code fails with linker error. Why?
On Monday, 6 October 2014 at 11:54:56 UTC, John Colvin wrote: On Monday, 6 October 2014 at 10:10:04 UTC, eles wrote: On Saturday, 4 October 2014 at 15:29:57 UTC, John Colvin wrote: On Saturday, 4 October 2014 at 11:19:52 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 04 Oct 2014 11:01:28 + John Colvin via Digitalmars-d-learn wrote: On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via Digitalmars-d-learn wrote: > On Sat, 04 Oct 2014 10:27:16 + > John Colvin via Digitalmars-d-learn > > wrote: I don't quite follow. Example? Well, in the OP example, imagine that I was trying to compile this module along with another one that simply happened to have a method defined in a way that the linker would have find it. I would have compiled with: dmd app.d app2.d and be unaware what bug I have introduced because I forgot do declare formula() as abstract in the first class.
Re: Code fails with linker error. Why?
On Saturday, 4 October 2014 at 15:29:57 UTC, John Colvin wrote:
On Saturday, 4 October 2014 at 11:19:52 UTC, ketmar via
Digitalmars-d-learn wrote:
On Sat, 04 Oct 2014 11:01:28 +
John Colvin via Digitalmars-d-learn
wrote:
On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via
Digitalmars-d-learn wrote:
> On Sat, 04 Oct 2014 10:27:16 +
> John Colvin via Digitalmars-d-learn
>
> wrote:
I don't really see the point though.
class A
{
void foo(int a) { Afoo(this, a); }
}
then declare and define Afoo however you like.
That's hackish, bad and convoluted. And it does not/should not
allow one to mess with the private fields of the class,
especially if Afoo is defined in another module.
And on that matter, a function that is to be provided by another
module should be explicitly marked as such in its declaration.
Otherwise, I could declare a function, forget to provide its
definition, still having the surprise that the code compiles and
runs with very strange results because some other module provides
a function that just happens to work.
Let's not even say how messy this could get with version() where
you could disable a function definition by error, in one version,
but still have a software that compiles and runs nowhere.
Re: Code fails with linker error. Why?
On Saturday, 4 October 2014 at 10:38:32 UTC, ketmar via Digitalmars-d-learn wrote: On Sat, 04 Oct 2014 10:27:16 + John Colvin via Digitalmars-d-learn wrote: is there any possibility to declare *class* *method* in one Yes, that too. Is even worse.
Re: Code fails with linker error. Why?
On Saturday, 4 October 2014 at 10:27:18 UTC, John Colvin wrote: On Saturday, 4 October 2014 at 04:02:46 UTC, eles wrote: On Friday, 3 October 2014 at 15:47:33 UTC, John Colvin wrote: On Friday, 3 October 2014 at 15:44:16 UTC, eles wrote: So the compiler has no way of knowing whether you've forgotten to include a definition, or whether it's simply sitting in some other object file / library / whatever. The linker, however, can know, hence the linker error. No "extern" required?...
Re: Code fails with linker error. Why?
On Saturday, 4 October 2014 at 10:27:18 UTC, John Colvin wrote:
On Saturday, 4 October 2014 at 04:02:46 UTC, eles wrote:
On Friday, 3 October 2014 at 15:47:33 UTC, John Colvin wrote:
On Friday, 3 October 2014 at 15:44:16 UTC, eles wrote:
class ShapeSurface(T) {
public:
int formula();
that means you have a definition of formula elsewhere (which
the linker tries to find, but obviously fails. What you want
is
class ShapeSurface(T) {
public:
abstract int formula();
Thanks, but still. The compiler shall not let that code pass
down to the linker. It has everything it needs to not do that,
or it shall have. Linker errors shall be simply because the
libraries are not in place (either not installed, either
linking path not correctly configured, either broken versions
of those libraries).
Sorry, but that's just not how it works. There is no
requirement for the definition of a function to be found in the
same compilation unit as it's declaration.
// a.d
void foo();
void main() { foo(); }
// b.d
import std.stdio;
void foo() { writeln("Hello World"); }
$ ls
a.d b.d
$ dmd b.d -c
$ ls
a.d b.d b.o
$ dmd a.d b.o
$ ls
a a.d a.o b.d b.o
$ ./a
Hello World
This seem to allow an entire class of problems, by linking
against long-time forgotten functions...
Re: Code fails with linker error. Why?
On Saturday, 4 October 2014 at 09:39:12 UTC, Chris Nicholson-Sauls wrote: In the original you are casting an int to a pointer type, which is legitimate (although rarely a good idea). The other side of the matter is simply precedence. cast(T)a.b; Is really the same as: cast(T)(a.b); But this also means that the cast is useless there, so there is no compile-time binding, so no CRTP. Anyway, it ws just a game to write the equivalent.
Re: Code fails with linker error. Why?
On Saturday, 4 October 2014 at 09:39:12 UTC, Chris Nicholson-Sauls wrote: In the original you are casting an int to a pointer type, which is legitimate (although rarely a good idea). The other side of the matter is simply precedence. cast(T)a.b; Is really the same as: cast(T)(a.b); Yes, you are right. Then it's cast back when assigning.
Re: Code fails with linker error. Why?
On Friday, 3 October 2014 at 15:47:33 UTC, John Colvin wrote:
On Friday, 3 October 2014 at 15:44:16 UTC, eles wrote:
class ShapeSurface(T) {
public:
int formula();
that means you have a definition of formula elsewhere (which
the linker tries to find, but obviously fails. What you want is
class ShapeSurface(T) {
public:
abstract int formula();
Thanks, but still. The compiler shall not let that code pass down
to the linker. It has everything it needs to not do that, or it
shall have. Linker errors shall be simply because the libraries
are not in place (either not installed, either linking path not
correctly configured, either broken versions of those libraries).
Then, a quirk of D:
this passes and works correctly:
surface = cast(T *)this.formula();
this segfaults the produced binary:
surface = (cast(T *)this).formula();
this fails:
surface = cast(T)this.formula();
with
app.d(8): Error: cannot cast this.formula() of type int to
app.Square
while one has to throw in parentheses to make it work (correctly)
once again:
surface = (cast(T)this).formula();
Isn't this funny, that you have to throw in parentheses depending
on the type of the type you cast to?
Code fails with linker error. Why?
This is under Linux 64 with both dmd 2.066 (and latest gdc-4.9):
=
class ShapeSurface(T) {
public:
int formula();
int getSurfaceBy100() {
int surface;
surface = cast(T *)this.formula();
return surface*100;
};
};
class Square: ShapeSurface!Square
{
public:
int squareSize = 8;
override int formula() {
return squareSize*squareSize;
}
};
int main() {
Square square = new Square();
square.getSurfaceBy100();
return 0;
}
=
It fails with linker error:
dmd app.d
app.o:(.data._D3app31__T12ShapeSurfaceTC3app6SquareZ12ShapeSurface6__vtblZ+0x28):
undefined reference to
`_D3app31__T12ShapeSurfaceTC3app6SquareZ12ShapeSurface7formulaMFZi'
collect2: error: ld returned 1 exit status
--- errorlevel 1
OK, maybe the cast is broken (well, to a pointer...), so changed
this:
surface = cast(T *)this.formula();
into this:
T cls = cast(T)this;
surface = cls.formula();
giving:
dmd app.d
app.o:(.data._D3app31__T12ShapeSurfaceTC3app6SquareZ12ShapeSurface6__vtblZ+0x28):
undefined reference to
`_D3app31__T12ShapeSurfaceTC3app6SquareZ12ShapeSurface7formulaMFZi'
collect2: error: ld returned 1 exit status
--- errorlevel 1
So, if you could tell me:
1) Why the compiler defer to the linker
2) What is the CRTP equivalent here
Many thanks.
Re: Allowing Expressions such as (low < value < high)
On Friday, 5 September 2014 at 07:26:45 UTC, klpo wrote: On Thursday, 4 September 2014 at 20:29:09 UTC, Nordlöw wrote: On Thursday, 4 September 2014 at 20:03:57 UTC, Nordlöw wrote: The problem is in D "[0..9]" has a completely different signification. All the sins of the past...
Re: 'idiomatic' porting of c and or c++ code that does NULL checking
On Wednesday, 27 August 2014 at 05:45:34 UTC, eles wrote: On Wednesday, 27 August 2014 at 05:39:59 UTC, Vladimir Panteleev wrote: On Monday, 25 August 2014 at 03:19:09 UTC, Mike Parker wrote: failure and the SIGKILL. (and SIGKILL just because you cannot catch it, otherwise you could yell at the user...)
Re: 'idiomatic' porting of c and or c++ code that does NULL checking
On Wednesday, 27 August 2014 at 05:39:59 UTC, Vladimir Panteleev wrote: On Monday, 25 August 2014 at 03:19:09 UTC, Mike Parker wrote: Sorry, you're right, that description of Exception/Error is correct. But I don't think that SDL initialization is a non-recoverable error. The program might want to retry SDL initialization with different parameters While this may be true in this case, I think that, in general, you cannot draw such a clear line between what's recoverable and what's not. If you really want to push things to the extreme, the sole unrecoverable error shall be assertion failure and the SIGKILL. Everything else could be otherwise handled, even if for that you'd need to program a new operating system inside your program, just because the one that intend to use is missing ;) No, that's extreme. But, matter is, what is recoverable and what not, is a matter of what the architect (and the specification) decide to be.
Re: Learning D
On Monday, 25 August 2014 at 16:46:11 UTC, Ryan wrote: Me: Software developer for 30 years. What IDE should I use? I'm not big fan of Eclipse, although if If you are an Eclipse (CDT) user for C/C++, then you will find a very similar plugin for D, called DDT, here: http://code.google.com/p/ddt/
Re: How to get nogc to work with manual memory allocation
On Sunday, 24 August 2014 at 08:48:03 UTC, bearophile wrote: Bienlein: things in such Limbo for several years). decades
Re: Programming a Game in D? :D
On Sunday, 3 August 2014 at 12:37:51 UTC, eles wrote: On Saturday, 2 August 2014 at 20:58:34 UTC, Foo wrote: On Saturday, 2 August 2014 at 20:38:59 UTC, David wrote: on this road. It matters less for us to be able to use slices And this while D really nailed down two things very well: strings and templates (I dream that one day C++ will adopt D's syntax for templates...). And scope() too, albeit recently people are talking about its deprecation. We go back to C++'s RAII... Plus, there are some features that never were nailed down and, as long as they remain in fish tail, many will simply just wait for them to be, you know, cleared in a way or another: @property, the recent assert/assume, the allocation in Phobos, the destructors of a class etc. Facing all this stuff, one simply wonders sometimes how other languages managed to stick for a solution and still get some use in real life... Flame or not, too much hesitation on some topics. Yes, much concern to nail them perfectly, I agree. But sometimes is rather paralysis by analysis...
Re: Programming a Game in D? :D
On Sunday, 3 August 2014 at 05:17:08 UTC, Mike Parker wrote: On 8/3/2014 5:38 AM, David wrote: about platform support, I know the story. But throwing all the weight behind a more-standard back-end would improve things. Yes, it would require some transition effort. But, then, ldc and gdc won't be condemned to play catch-up forever.
Re: Programming a Game in D? :D
On Saturday, 2 August 2014 at 20:58:34 UTC, Foo wrote:
On Saturday, 2 August 2014 at 20:38:59 UTC, David wrote:
Hi, not too sure if there's still someone reading this post,
but i do have another question. So, I heared so much good
stuff about D, it's powerfull, fast the syntax is nice, but
well, why is D actually not used for common games yet? (I mean
I know about some smaller projects, but nothing "big")
Because D has a GC, is unstable and has many many bugs (even an
ape could find some).
I am not in the game industry, but in other time-constrained
industry (realtime). For me, it nails down to GC and lack of
volatiles.
I tried to use it for some scripting, but finally reverted back
to simple Bash and some Python.
My opinion on the matter is that, in order to succeed, D really
must become a tool that could be used everywhere. The discourse
that "yes, but you could do that part in C (speaking about
realtime)" usually receives this kind of reply: "yes, but, then,
why bother? If I have C for this part, I have Bash for the other
and C# for the GUIs".
As long as it does not try to cover all the range, the
differential that it offers wrt C+C#/Java+Bash/Python does not
seems conclusive enough to justify the effort.
Add to this the quality of tools, which are still in their
infancy (just consider dynamic libs, debug support, IDE support,
static analysis tools etc.)
Well, feel free to destroy it. But I tried to use it at my
workplace. It is a nice language, but the differential is simply
not enough. The main selling point would be its potential
ubiquity ("hey, boss, one language to rule them all!"), but here
it fails short in systems programming, embedded realtime
programming and, as far as I hear, in massive
multi-threading/couroutines where Go is better. And C# has that
async...
I agree it is a bit o chicken and egg problem: "we don't invest
in D because is not popular/ the language is not popular because
nobody invest in it". That's true, but, as I tried it, in the end
the marginal gain was too small for us to continue on this road.
It matters less for us to be able to use slices than it matters
to have robust and time-predictable code.
Re: GC.calloc(), then what?
On Friday, 27 June 2014 at 08:17:07 UTC, Ali Çehreli wrote: Thank you for your responses. I am partly enlightened. :p On 06/27/2014 12:34 AM, safety0ff wrote: > On Friday, 27 June 2014 at 07:03:28 UTC, Ali Çehreli wrote: But addRange doesn't seem to make sense for stdlib.malloc'ed memory, right? The reason is, that memory is not managed by the GC so there is no danger of losing that memory due to a collection anyway. It will go away only when I call stdlib.free. It is not about that, but about the fact that this unmanaged memory *might contain* references towards managed memory. If you intend to place such references into this particular chunk of memory, then you need to tell GC to scan the memory chunk for references towards managed memory. Otherwise, the GC might ignore this chunk of memory, find elsewhere no references towards a managed object, delete the managed object, then your pointer placed in the unmanaged memory becomes dangling.
Re: Is this reasonable?
On Thursday, 5 December 2013 at 19:36:46 UTC, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: [...] Cough, cough, make array length be an int. Do you really need arrays that big? :-S (I'm talking to Mr. D Compiler here) A negative length array makes no sense. Does really "unsigned" means "positive"? Or only "a value without sign"? I remember Walter defending the latter point of view and not accepting "unsigned" == "positive".
Re: Is this reasonable?
On Thursday, 5 December 2013 at 19:51:52 UTC, Ary Borenszweig wrote: On 12/5/13 4:35 PM, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: [...] Cough, cough, make array length be an int. Do you really need arrays that big? :-S (I'm talking to Mr. D Compiler here) A negative length array makes no sense. Of course not. And it will never be negative. But make it signed and all the problems everyone is having several times every month will be gone forever. I defended once the approach took by FreePascal: they declared a signed integer that covered the larges available range on a machine (now it occurred to me that the compiler could even cover *twice* that range with a simple trick) and then, all other integer types, signed or unsigned/positive were sub-ranges of the first. Comparisons were made at this largest level. I dunno how complicated and how much overhead for this.
Re: Is this reasonable?
On Thursday, 5 December 2013 at 17:44:18 UTC, H. S. Teoh wrote:
On Thu, Dec 05, 2013 at 06:15:37PM +0100, Steve Teale wrote:
Here I feel like a beginner, but it seems very unfriendly:
import std.stdio;
struct ABC
{
double a;
int b;
bool c;
}
ABC[20] aabc;
void foo(int n)
{
writefln("n: %d, aabc.length: %d", n, aabc.length);
if (n < aabc.length)
writeln("A");
else
writeln("B");
}
void main(string[] args)
{
int n = -1;
foo(n);
}
This comes back with "B".
If I change the test to (n < cast(int) aabc.length), then all
is
well.
Is this unavoidable, or could the compiler safely make the
conversion implicitly?
Comparing a signed value to an unsigned value is a risky
operation. You
should always compare values of like signedness, otherwise
you'll run
into problems like this.
You can't compare -1 to an unsigned value because if that
unsigned value
happens to be uint.max, then there is no machine instruction
that will
give the correct result (the compiler would have to substitute
the code
with something like:
uint y;
if (x < 0 || cast(uint)x < y) { ... }
which will probably introduce undesirable overhead.
The compiler also can't automatically convert aabc.length to
int,
because if the length is greater than int.max (which is half of
uint.max), the conversion would produce a wrong negative value
instead,
and the comparison will fail.
So, comparing a signed value to an unsigned value is a
dangerous,
error-prone operation. Sadly, dmd doesn't warn about such risky
operations; it just silently casts the values. Bearophile has
often
complained about this, and I'm starting to agree. This is one
me too, me too, me too
Re: Is this reasonable?
On Thursday, 5 December 2013 at 18:26:48 UTC, Jonathan M Davis wrote: On Thursday, December 05, 2013 19:16:29 Maxim Fomin wrote: On Thursday, 5 December 2013 at 17:15:39 UTC, Steve Teale wrote: the values. The best that could be done would be to warn about the comparison or to make it an error. http://d.puremagic.com/issues/show_bug.cgi?id=259 If Walter agrees...
Re: Is anything private by default when declared in a module?
On Monday, 2 December 2013 at 21:28:48 UTC, lomereiter wrote: On Monday, 2 December 2013 at 20:53:10 UTC, Namespace wrote: OMG now I get it why in 2.064 importing std.regex makes visible std.uni.isWhite all of a sudden. Unicorns cannot be white, as they are already pink & invisible. At least the std ones... http://en.wikipedia.org/wiki/Invisible_Pink_Unicorn
Re: Problem with rdmd
On Saturday, 31 August 2013 at 12:01:48 UTC, Dicebot wrote: On Friday, 30 August 2013 at 13:32:25 UTC, eles wrote: On Friday, 30 August 2013 at 11:34:59 UTC, Jacob Carlborg wrote: On 2013-08-30 09:39, eles wrote: This is an ancient dmd misfeature - it treats `dmd test` as `dmd test.d`, adding .d silently. No idea if someone actually wants this behavior.. Bump...
Re: using scons on 64-bit platform, with gdc
On Wednesday, 18 September 2013 at 07:09:27 UTC, eles wrote: import os env = Environment(ENV = os.environ) gcc -o test01 -m32 test01.o -L/usr/lib -lphobos2 -lpthread -lm Related, why the scons is passing the -L/usr/lib to the gcc, while the LD_LIBRARY_PATH variable of my bash shell is rather: /opt/gdc-4.9/lib/../lib64 This provides a bad version of lib(g)phobos.a. The verbose invocation of gcc (no -L parameter), that is: gcc -v -o test01 -m64 test01.o -lgphobos2 -lpthread -lm correctly specifies: LIBRARY_PATH=/opt/gdc-4.9/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/:/opt/gdc-4.9/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/opt/gdc-4.9/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../:/lib/:/usr/lib/ and finds the libgphobos.a from: /opt/gdc-4.9/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/../../../../lib64/ which, indeed, is the correct version. Note that I have two installations of gdc, but the PATH of /opt/gdc-4.9/bin preceded the /usr/bin: $ which -a gcc /opt/gdc-4.9/bin/gcc /usr/bin/gcc
using scons on 64-bit platform, with gdc
Hi,
Not sure it is a bug or a misuse of scons, but on Saucy 64, with
scons --version
script: v2.3.0, 2013/03/03 09:48:35, by garyo on reepicheep
engine: v2.3.0, 2013/03/03 09:48:35, by garyo on reepicheep
and a simple SConstruct like:
import os
env = Environment(ENV = os.environ)
env.Program(target='test01', source=Split('test01.d'));
it tries to execute:
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o test01 -m32 test01.o -L/usr/lib -lphobos2 -lpthread -lm
/usr/bin/ld: cannot find -lphobos2
collect2: error: ld returned 1 exit status
scons: *** [test01] Error 1
scons: building terminated because of errors.
which is expected to fail since:
1) the architecture (and the libraries) are m64, not m32 (why
does scons believe that?)
2) the gdc's phobos libraries is called libgphobos2, not
libphobos2
Manually correcting and executing the offending line:
gcc -o test01 -m64 test01.o -L/usr/lib -lgphobos2 -lpthread -lm
works as expected.
volatile
Among the intended uses of volatile is to "allow access to memory mapped devices" (quoting wikipedia). This play an immense role in the embedded, signaling to the compiler that the content of that variable/address could change without notice. It is not because other thread would change it. It is because it is a hardware device that is mapped at that address and its behavior is commanded/interrogated by R/W operations. As such, R/W operations of such variables should never be cached or optimized away, but always performed. AFAIK, the volatile keyword went away and I am not sure it was intended for this. Does D peek() and poke() functions (or similar) that guarantee R/W operations at a memory address? Thanks.
Re: Problem with rdmd
On Saturday, 31 August 2013 at 17:42:21 UTC, Andrei Alexandrescu wrote: On 8/30/13 6:32 AM, eles wrote: On Friday, 30 August 2013 at 11:34:59 UTC, Jacob Carlborg wrote: On 2013-08-30 09:39, eles wrote: One possible solution would be for rdmd to create a link in its temporary directory to the original file. (The link would have a .d extension.) Isn't more reasonable to change dmd's behavior?
Re: Problem with rdmd
Bah, what would be the meaning of accepting the shebang syntax
then? SCripts are made to provide a quick way to hack: you edit
it for 5 mins, you run it. You change a parameter inside, you run
it. Otherwise, there would be no need for scripts, everything
could be compiled, even if you fill everything with system()
statements.
On Saturday, 31 August 2013 at 11:08:57 UTC, Jacob Carlborg wrote:
On 2013-08-30 09:39, eles wrote:
On Linux 64
$chmod +x htest
$cat ./htest
#!/usr/bin/env rdmd
import std.stdio;
void main() {
writeln("hello world!");
}
then:
$./htest
Error: cannot read file ./htest.d
Failed: 'dmd' '-v' '-o-' './htest.d' '-I.'
OTOH:
$cp htest htest.d
$./htest.d
hello world!
It seems that rdmd expects the script to bear the .d
extension. This is
not a very good choice, at least when writing git helper
scripts.
For example, a "$git command" command would eventually try to
execute
the executable (script):
$git-command
The problem is that that line expects git-command, not
git-command.d.
A workaround for this?
Why don't just compile it manually once instead of using like a
script?
Re: Problem with rdmd
On Friday, 30 August 2013 at 11:34:59 UTC, Jacob Carlborg wrote: On 2013-08-30 09:39, eles wrote: I'm pretty sure it's DMD that is the problem. Yes. But that's, the least to say, limiting. This: https://github.com/D-Programming-Language/tools/blob/master/rdmd.d#L160 should be solved in other manner. Maybe creating a temporary copy. Or forcing dmd in some ways. Besides, for what reasons dmd would impose a .d extension?
Re: Problem with rdmd
On Friday, 30 August 2013 at 07:56:14 UTC, anonymous wrote: On Friday, 30 August 2013 at 07:39:41 UTC, eles wrote: A workaround for this? ln htest htest.d Thanks.
Problem with rdmd
On Linux 64
$chmod +x htest
$cat ./htest
#!/usr/bin/env rdmd
import std.stdio;
void main() {
writeln("hello world!");
}
then:
$./htest
Error: cannot read file ./htest.d
Failed: 'dmd' '-v' '-o-' './htest.d' '-I.'
OTOH:
$cp htest htest.d
$./htest.d
hello world!
It seems that rdmd expects the script to bear the .d extension.
This is not a very good choice, at least when writing git helper
scripts.
For example, a "$git command" command would eventually try to
execute the executable (script):
$git-command
The problem is that that line expects git-command, not
git-command.d.
A workaround for this?
Thanks
Re: trouble with long
On Tuesday, 16 July 2013 at 11:14:44 UTC, bearophile wrote: eles: Bye, bearophile Don C.: "There's a root cause issue -- integer overflow is not an error in general. The paper which bearophile keeps posting, which he has apparently never read, shows quite convincingly that you cannot make it an error in a C-family language. There are just too many legitimate uses of integer wraparound. eg. int.max + 200 - 300 should not be an error." Frankly, I keep thinking if FreePascal didn't nail it the good way: consider all integral values as belonging to the widest integral type, perform calculation (as if) in that type, then truncate (if needed) only the final result, on assignment.
Re: trouble with long
On Tuesday, 16 July 2013 at 11:14:44 UTC, bearophile wrote: eles: Bye, bearophile Walter: "Consider all the addressing modes used - they are all adds, with no overflow checks. Secondly, they all rely on wraparound (overflow) arithmetic, after all, that is how subtraction is done." I think the way to go is to introduce "sanitized" integral types, in conjunction with some compiler flag. If one day Walter agrees with... This way, everybody is free to use whatever it likes.
trouble with long
$cat test.cpp:
#include
int main() {
long long x = 125000 * 2;
std::cout << x << std::endl;
return 0;
}
g++-generated exe displays: -1794967296
$cat test.d:
import std.stdio;
int main() {
long x = 125000 * 2;
writefln("%d",x);
return 0;
}
dmd- and gdc-generated exes display: -1794967296
compiling with g++ at least gives a warning:
warning: integer overflow in expression [-Woverflow]
long long x = 125000 * 2;
Both dmd and gdc do not complain in any way.
Isn't the promotion to int so awful? Better ideas? (yes, I know
about casting to long).
Re: version(noboundscheck) + friends
On Tuesday, 4 June 2013 at 07:19:52 UTC, Jonathan M Davis wrote: On Tuesday, June 04, 2013 09:14:28 eles wrote: On Monday, 3 June 2013 at 22:19:23 UTC, Ali Çehreli wrote: > On 06/03/2013 03:11 PM, Timothee Cour wrote: Nothing in the language checks for integer overflow, and given the overhead that it would introduce, there's pretty much no way that it's ever going to be added. Just the same can be said about bounds checking. And those came into the language, however. Walter has been against it every time that it's come up. Yes, even in the -debug mode. What I fail to see is why. The overhead will be there only if asked for, only in debug mode.
Re: version(noboundscheck) + friends
On Monday, 3 June 2013 at 22:19:23 UTC, Ali Çehreli wrote: On 06/03/2013 03:11 PM, Timothee Cour wrote: > Why aren't we using version=noboundscheck (+ friends) instead of > -noboundscheck? Hijack: what about version(integeroverflow) ?
unsigned int in for loops
hi everybody, recently i was hit by an old-known programming error, using unsigned int in for loops could get into infinite traps: http://stackoverflow.com/questions/665745/whats-the-best-way-to-do-a-reverse- for-loop-with-an-unsigned-index so, i D (1 or 2) is counter-attacking in some way (for example, disabling implicit casting of (-1) to UINT_MAX). cordially, eles. PS i really like being able to use an unsigned int for those loops, both for logical and for programming (large values of the loop index), while still avoiding such traps. thanks.
help needed with gdb
hello everybody,
here is my setup:
Linux system 2.6.32-22-generic #33-Ubuntu SMP Wed Apr 28 13:28:05 UTC 2010
x86_64 GNU/Linux
and here is gdbtest.d
import std.stdio;
int x=0;
string t="hello!";
int main(){
writefln("x=%d",x);
writefln("t=%s",t);
return 0;
}
I compiled the latest weekly buid of gdb (7.1.50.20100519) and installed dmd
2.046 via the deb file (including the multilib tools).
then I tried to debug gdbtest. I received the errors below.
u...@system:~/Desktop/temp$ dmd gdbtest.d -g
u...@system:~/Desktop/temp$ ./gdbtest
x=0
t=hello!
u...@system:~/Desktop/temp$ gdb --version
GNU gdb (GDB) 7.1.50.20100519
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
u...@system:~/Desktop/temp$ gdb ./gdbtest
GNU gdb (GDB) 7.1.50.20100519
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/felix/Desktop/temp/gdbtest...done.
(gdb) break main
Breakpoint 1 at 0x804efd7
(gdb) run
Starting program: /home/felix/Desktop/temp/gdbtest
warning: the debug information found in "/lib/ld-2.11.1.so" does not match "/
lib/ld-linux.so.2" (CRC mismatch).
[Thread debugging using libthread_db enabled]
Breakpoint 1, 0x0804efd7 in main ()
(gdb) next
Single stepping until exit from function main,
which has no line number information.
x=0
t=hello!
0xf7e45bd6 in __libc_start_main () from /lib32/libc.so.6
(gdb)
Single stepping until exit from function __libc_start_main,
which has no line number information.
Program exited normally.
(gdb)
as you see, the debug session was unsuccesful. can anybody enlighten me why?
what is the line "warning: the debug information found in "/lib/ld-2.11.1.so"
does not match "/lib/ld-linux.so.2" (CRC mismatch)."?
thank you
eles
Re: compiled gdb
maybe it could be even integrated in the dmd archive, just like the windbg currently is...
compiled gdb
hello, since gnu debugger (gdb) is free and now there is a version which works properly with D, could someone host (and made available for download) *compiled* versions for windows and linux? of course, patched versions (so that it would work with D). maybe on dsource? thanks (I am not good when it comes to dependencies and so on). eles
Re: std.complex
== Quote from Lars T. Kyllingstad (pub...@kyllingen.nospamnet)'s article > On Tue, 11 May 2010 15:08:07 +0000, eles wrote: > > Maybe I am wrong, but my feeling is that if the complex numbers were a > > native type (like creal&co. are now), then it would have been possible > > to have a dedicated formatting (just like %f, %d and %s are) for > > writefln. > > > > Putting the type into the library seems to forbid some very nice things: > > > > - initializing with "Complex!double z=1+2i" or "Complex!double z=1+2*i" > I don't think there will still be a special syntax for complex literals > when the built-in types are deprecated. I'd guess not. It is, however, > likely that creal etc. will be aliases for Complex!real etc. And this > doesn't look that bad: > auto z = cdouble(1,2); My opinion is that it does. Image writing y=(3+2i)^2+z^2*i. OTOH, the suggestion you made below (see below)... > > or or > > "Complex!double z=2.23*exp(1.107*i)" syntax (which is very practical) - > The following does just that, and IMO it looks a lot better: > auto z = fromPolar(2.23, 1.107); > > even in C99 one could write "complex double z=1+2*I" (but "I" is a > > defined symbol) - instead of "Complex!double(2,3)" > If you want that, just define > immutable I = Complex!float(0, 1); it is nice. However, I think it should be defined as Complex!real (0,1); I hope it will be automatically downsized to Complex!int if the left value is a Complex!int and so on. I vote for defining it in std.complex for the folowing reasons: - it will enforce coding discipline and standardize code among libraries and users, the code will be consistent and copy-paste portable. - it is similar to C99, already judged as acceptable for the C community - if such an elementary thing is left to be defined by the programmer, what long before not using the std.complex module at all? I mean, as well one could re-define the whole complex library. I think having std.complex in the standard library is primarily for standardization and only second for its usefulness (ok, is useful too, but I want to make a point). Also, I think the best is to mimick the functions in the C99 : http://www.opengroup.org/onlinepubs/009695399/basedefs/ complex.h.html Me, for one, I prefer writing y=z*conj(z) instead of z=z*z.conj(). OK, maybe is just personal preference. OTOH, I feel like maintaining x.re and x.im instead of creal(x) and cimag(x), since the latter (as defined in C99) are only right-values. I have some experience with both C99 complex and with GNU Scientific Library GSL_COMPLEX. Both have ups and downs, I still prefer to work with C99, though. Also, if we are here, is any way to define ' (apostrophe) for an (unary) operator? Having z' to mean (z conjugate) would be awesome (y=z*z'). But maybe is just my Matlab background speaking here. Or another character (ideas, anyone?... #z, z#, z~ or ~z etc.). A note of modesty: I do not try to push it harder than it is acceptable, but since the complex numbers are just in a major rewrite, let's try to do it in the best way. We are not constrained by compatibility/legacy issues. Thanks. eles
Re: std.complex
Maybe I am wrong, but my feeling is that if the complex numbers were a native type (like creal&co. are now), then it would have been possible to have a dedicated formatting (just like %f, %d and %s are) for writefln. Putting the type into the library seems to forbid some very nice things: - initializing with "Complex!double z=1+2i" or "Complex!double z=1+2*i" or or "Complex!double z=2.23*exp(1.107*i)" syntax (which is very practical) - even in C99 one could write "complex double z=1+2*I" (but "I" is a defined symbol) - instead of "Complex!double(2,3)" - lack of support for formatting in writef (although, that should not be limited to native types) - formatting in writef/printf is quite versatile for regular use, and could be immediately extended to complex numbers (e.g. if one formatting is specified, then both real and imaginary parts would be displayed with that format), although 2 different complex-number formats should be defined: real/imaginary and amplitude/phase
Re: std.complex
the following test case also works:
Compiling
import std.stdio;
import std.complex;
Complex!(double) x,y;
int main(){
writefln("salut!\n");
x.re=1;
x.im=1;
y=x.conj();
writefln("x=%f+%f*i\n",x.re,x.im);
writefln("y=%f+%f*i\n",y.re,y.im);
return 0;
}
results in
C:\dmd2>dmd test.d
C:\dmd2>test
salut!
x=1.00+1.00*i
y=1.00+-1.00*i
C:\dmd2>
Which is OK. However, displaying complex numbers in that way is not
very nice. Is there any dedicated formatting for that? (it would be
nice to be able displaying a complex number in both Cartesian and
Polar formats)
eles
Re: std.complex
Confirmation: in the new beta, the test case for the std.complex
compiles on windows xp with dmd 2.046beta. I cannot post on the
D.phobos newsgroup, but I post the confirmation here.
I did not test it further.
Compiling
import std.complex;
int main(){
return 0;
}
results in:
C:\dmd2>dmd test.d
C:\dmd2>test
C:\dmd2>
While we are here, can somebody look at DMD bug 2460 please?
eles
Re: std.complex
Thank you, Don. I saw your post on the http://news.gmane.org/ gmane.comp.lang.d.dmd.beta group. I'll wait for the next release. Does anybody knows about when the http://d.puremagic.com/issues/ show_bug.cgi?id=2460 (DMD bug 2460) will be addressed?
Re: std.complex
actually, i think 2.045 was the second (after 2.044) release to include std.complex. as i understand, std.complex should replace the native types cfloat, creal, ifloat, ireal etc. i was eager to test the new std.complex. it seems that some work is still needed. maybe someone could submit a bug report? otoh, native types creal, cfloat etc. are not deprecated, it seems. they should be, i think. eles
Re: std.complex
Thanks for your answer. Me too, I prefer working on linux but for
some reasons I remain on windows until dmd goes 64-bit.
For the record, std.stdio works fine:
Compiling
import std.stdio;
int main(){
writefln("hello!\n");
return 0;
}
results in:
C:\dmd2>dmd test.d
C:\dmd2>test
hello!
So, the problem is somewhere in std.complex.
std.complex
Hello,
I just installed dmd 2.045 (unarchived in c:\dmd2) and put c:
\dmd2\windows2\bin on path.
Compiling the following:
import std.complex;
int main(){
return 0;
}
fails with:
C:\dmd2>dmd test.d
OPTLINK (R) for Win32 Release 8.00.2
Copyright (C) Digital Mars 1989-2009 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
test.obj(test)
Error 42: Symbol Undefined _D3std7complex12__ModuleInfoZ
--- errorlevel 1
why?
Re: Newsgroups, off-topic
Thank you for your answer. I hope to see std.complex integrated in the next release of dmd. I am mainly interested in scientific (i.e. numerical) computations, so a good numerical library (GSL, Lapack etc.) would be welcome in D. I like the std.algorithm, though. Eles PS Thanks to everybody for pointing me to Thunderbird and Opera. Both are nice. PS2 What does really means to use LLVM or GCC backends for dmd? Is a front-end somewhat like a parser (or bytecode compiler) and the back-end something like an assembler?
Newsgroups, off-topic
Hello,
I just started using D (2.0). I have three or four questions:
1) How to use the newsgroup link (e.g. news://news.digitalmars.com/
digitalmars.D.learn) to read the newsgroup? Is the "news://"; protocol handled
by some program under Linux (Ubuntu, 64)? I write this using the HTTP interface
(e.g. http://www.digitalmars.com/pnews/indexing.php?
server=news.digitalmars.com&group=digitalmars.D) which is not very pleasant.
COuld we, at least, have an interface like the one used by archives? (e.g.
http://www.digitalmars.com/d/archives/digitalmars/D/
Re_value_range_propagation_for_bitwise_OR_108807.html)? And a SEARCH button?
2) What is the status of complex numbers in D2? Is stated that module
std.complex will replace the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal. When and... how?
2a) Why the following program has the following output?
import std.stdio;
real x;
ireal y;
creal z;
int main(){
x=3;
y=5i;
z=x+y;
writefln("x=%f",x);
writefln("y=%f",y);
writefln("z=%f",z);
return 0;
}
=
x=3.00
y=5.00
z=3.00+5.00i
Since y is an ireal number, I would have expected to be written as 5.00i,
not 5.00. This is even more confussing as "%f" formatting seems to handle
well creal numbers, but not ireal ones.
3) When DMD for Linux will be 64-bit, too? (Now it works, with multilib).
However, it is a nuisance to install multilib.
Thanks everybody.
Eles
