Re: BetterC unexpected results
On Sunday, 8 January 2023 at 13:49:22 UTC, DLearner wrote: I thought dynamic arrays were unavailable under -betterC. .. ... See the 'Retained Features' section, and the 'Unavailable Features' section https://dlang.org/spec/betterc.html
Re: Address of a class object
On Thursday, 5 January 2023 at 17:23:39 UTC, H. S. Teoh wrote: On Thu, Jan 05, 2023 at 06:32:47AM +, areYouSureAboutThat Also, I cannot read hex, [...] IMNSHO, anyone who claims to be a programmer should at least know that much. ?? Well, like all, I learnt this at uni. .. as well as lot of other useless stuff. But in all my years as a well paid and productive 'programmer' ;-) .. I cannot recall ever, a consistent need to read hex (using by brain, that is). As such, those neuron connections needed to read hex do not exist anymore. Even the neurons in my brain are smarted than Knuth.
Re: forgetting -betterC means no runtime bounds checking?
On Thursday, 5 January 2023 at 09:10:00 UTC, areYouSureAboutThat wrote: btw. the output (when you forget to use -betterC): 0 1 2 3 4 src/rt/dwarfeh.d:330: uncaught exception reached top of stack This might happen if you're missing a top level catch in your fiber or signal handler core.exception.ArrayIndexError@test.d(25): index [5] exceeds array of length 5 Aborted (core dumped)
forgetting -betterC means no runtime bounds checking?
I was playing around with betterC, when I discovered, that if i
accidently forget to provide -betterC to the compiler, it will
still compile this, but, there will be no runtime bounds checking
occuring.
My question is: why is there no bounds checking occurring if I
forget to use -betterC?
module test;
extern(C) void main()
{
import core.stdc.stdio : printf;
int[5] arr = [ 0, 1, 2, 3, 4];
for (int i = 0; i < 10; i++) // oops!
{
printf("%d\n", arr[i]);
}
}
Re: Address of a class object
On Thursday, 5 January 2023 at 04:04:39 UTC, Paul wrote: .. Do I have this much right? ... First, i would say, add @safe to your main. @safe void main() ... Then you will see you are treading on dangerous waters ;-) Second, to be sure your getting the correct results, it would be nice if there was a 'category of type' in std.traits for: isAllocatedOnStack isAllocatedOnHeap As it is, your just guessing (although the addresses printed will clear this up for you anyway I guess). Also, I cannot read hex, so if it were me, I'd be casting the hex into an size_t: cast(size_t)
Re: Compile time vs run time -- what is the difference?
On Wednesday, 28 December 2022 at 12:42:24 UTC, thebluepandabear wrote: Before even running the code I get an IDE warning (IntelliJ). Does IntelliJ compile the code in the background? It will NOT compile successfully unless you do one of these things: (1) ensure the result of the 'static assert' is true. (2) comment out the static assert. Once you do either of (1) or (2) above, it will compile to an executable format. When you execute it, the runtime will catch the 'assert' failure (ie. assertion == false), and the runtime will bring your program to an immediate halt. This was just meant to be an example of differentiating compile time from runtime, as per you question. With static assert, your logic testing is traversed during compilation, and your compilation will come to a stop when the assertion is found to be false, whereas your asserts are traversed during program execution, and if they are found to be false, your program comes to a stop. https://dlang.org/spec/version.html#static-assert https://tour.dlang.org/tour/en/gems/contract-programming
Re: Compile time vs run time -- what is the difference?
On Wednesday, 28 December 2022 at 02:31:45 UTC, thebluepandabear
wrote:
..
Other errors are only able to be spotted during run time such
as exceptions, dividing by zero, assert blocks.
With regards to the 'assert blocks' you mention, D (like C++) has
both static assert and runtime assert.
// ---
module test;
@safe:
import std;
void main()
{
string val = "some string";
static assert(is(typeof(x) : int)); // assertion fails at
compile time.
assert(val == "some other string"); // assertion fails at
runtime.
}
// ---
Re: Is there such concept of a list in D?
On Tuesday, 13 December 2022 at 23:34:45 UTC, Salih Dincer wrote: We have nothing to do with unsafe stuff! Why do we waste time with unsafe things; To learn or to teach? SDB@79 @trusted class unsafeVector ... now it's @safe ;-)
Re: Is there such concept of a list in D?
On Tuesday, 13 December 2022 at 23:34:45 UTC, Salih Dincer wrote: We have nothing to do with unsafe stuff! Why do we waste time with unsafe things; To learn or to teach? SDB@79 btw. I reject your axiom: 'We have nothing to do with unsafe stuff!' It is demonstratably not correct, given the need for @safe.
Re: Is there such concept of a list in D?
On Tuesday, 13 December 2022 at 23:34:45 UTC, Salih Dincer wrote: We have nothing to do with unsafe stuff! Why do we waste time with unsafe things; To learn or to teach? SDB@79 Really? That example I provided was just to demonstrate that 'yes' you can implement a container using OOP. I mean why couldn't you? I just used some basic encapsulation here. It's pretty easy to make it 'safe'. But if you want me to provide such an example, utilising all the tools of OOP, you need to first pay me ;-)
Re: Is there such concept of a list in D?
On Tuesday, 13 December 2022 at 22:33:02 UTC, Ali Çehreli wrote: Or I can tell what I think, you counter, and we all learn. Proofs... Axioms... Pfft... Ali "I suppose sir, you are going to explain your puzzling remarks."
Re: Is there such concept of a list in D?
On Saturday, 10 December 2022 at 06:11:18 UTC, thebluepandabear
wrote:
I was wondering more if there is an object oriented way of
creating arrays, like in Java there is an `ArrayList`, in C++
there is `std::vector`, etc.
of course there is - I mean just imagine if there wasn't ;-)
e.g (an note, it's called unsafeVector for a reason ;-)
//
module test;
import std;
void main()
{
unsafeVector v = new unsafeVector(5);
writefln("size of v is: %s", v.size());
writeln;
writeln("v contains:");
for (int i = 0; i < v.size(); i++)
{
v[i] = i+1;
writefln("v %s : %s", i , v[i]);
}
writeln;
writeln(v[0..3]);
writeln(v[0..$]);
writeln(v[$-1]);
}
unittest
{
unsafeVector v = new unsafeVector(5);
assert(v.size() == 5);
// NOTE: be sure to use the interface here
// as D lets you shoot yourself in the foot
// by giving you direct access to sz !!!
for (int i = 0; i < v.size(); i++)
{
v[i] = i+1;
}
assert(v[0..3] == [1,2,3] );
assert(v[0..$] == [1,2,3,4,5]);
assert(v[$-1] == 5);
v[2] = 999;
assert(v[2] == 999);
}
class unsafeVector
{
private:
size_t *elem;
immutable size_t sz;
public:
this(size_t s)
{
assert( isIntegral!(typeof(s)) );
elem = cast(size_t*)new size_t[s];
sz = s;
}
auto ref opIndex(size_t i)
{
return elem[i];
}
auto ref opSlice(size_t start, size_t end)
{
return elem[start .. end];
}
auto ref opDollar()
{
return sz;
}
auto size()
{
return sz;
}
}
//
Re: Is there such concept of a list in D?
On Saturday, 10 December 2022 at 15:59:07 UTC, Ali Çehreli wrote: ... Object orientation don't go well with collections On what basis do you make that assertion? i.e. Which aspect of OOP programming 'don't go well with collections'? Is it encapsulation? Is it inheritance? Is it polymorphism? Is it generics? (which is an integral part of OOP these days) As evidence against your assertion (just to start with): C# -> System.Collections C# -> System.Collections.Generic C# -> System.Collections.Concurrent Only when you provide related proofs, can you come up with such an axiom.
