If you suspect there's a contradiction in requirements, you need
to specify them with better precision.
On Thursday, 9 July 2020 at 06:57:22 UTC, Kagamin wrote:
If you suspect there's a contradiction in requirements, you
need to specify them with better precision.
What are the contradictions in the requirements? I don't see any.
--
/Jacob Carlborg
On Thursday, 9 July 2020 at 12:12:06 UTC, wjoe wrote:
Also GC but it's possible to make a dynamic array
implementation which avoids the GC.
It's easy to make a dynamic array without using the GC. Did you
mean "implementation which avoids memory management"?
I'm not considering supposed
On Thursday, 9 July 2020 at 12:12:06 UTC, wjoe wrote:
I'm not considering supposed performance benefits/penalties
because these need to be profiled.
Considering the many downsides why would I ever want to choose
a static over a dynamic array ?
Simply put: static arrays are not dynamic
+ The size is known at compile time.
vs.
- Can neither grow nor shrink them
- Can't append elements
- Can't remove elements
- Can't slice them
- Can't range them
- Assignment copies the whole array, as in int[5] a; auto b = a;
- Size is limited by stack
- Stack overflow issues
Some of the
On Thu, Jul 09, 2020 at 12:12:06PM +, wjoe via Digitalmars-d-learn wrote:
> + The size is known at compile time.
>
> vs.
>
> - Can neither grow nor shrink them
> - Can't append elements
> - Can't remove elements
Consider a 3D game in which you represent vectors as static arrays of 4
I have one more question. I tested the programm, as you said, it
worked rarely because of OS restrictions. If I compile that code
to dll, and run it through dll launcher, should it work?
On Thursday, 9 July 2020 at 16:16:53 UTC, Quantium wrote:
I have one more question. I tested the programm, as you said,
it worked rarely because of OS restrictions. If I compile that
code to dll, and run it through dll launcher, should it work?
The OS restrictions don't care whether your
On 7/9/20 5:12 AM, wjoe wrote:
Considering the many downsides why would I ever want to choose a static
over a dynamic array ?
In addition to what others said, dynamic arrays can be more expensive
both in space and time.
Time: Dynamic array elements are accessed through an extra pointer
On Thu, Jul 09, 2020 at 04:16:53PM +, Quantium via Digitalmars-d-learn
wrote:
> I have one more question. I tested the programm, as you said, it
> worked rarely because of OS restrictions. If I compile that code to
> dll, and run it through dll launcher, should it work?
No, it's subject to
On Wednesday, 8 July 2020 at 20:33:39 UTC, Paul Backus wrote:
import std.stdio;
void main()
{
int i;
readf("%d\n", i); // read a number
ubyte* p = cast(ubyte*) i; // convert it to a pointer
writeln(*p); // write the data at that address to the
console
}
Note that this program
On Thursday, 9 July 2020 at 17:24:33 UTC, matheus wrote:
On Wednesday, 8 July 2020 at 20:33:39 UTC, Paul Backus wrote:
import std.stdio;
void main()
{
int i;
readf("%d\n", i); // read a number
ubyte* p = cast(ubyte*) i; // convert it to a pointer
writeln(*p); // write the data
So is Vibe-d still being actively maintained? I noticed there
have been no new releases in a while, and the forums are a bit of
a disaster (unless you love porn I suppose):
https://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/
On Thursday, 9 July 2020 at 12:12:06 UTC, wjoe wrote:
...
Static arrays are great because as already mentioned, they are
allocated on the stack (unless it is global variable something,
then it ends up in the data segment or TLS area).
As C/C++ now allows dynamically sized static arrays
On Thursday, July 9, 2020 10:21:41 AM MDT H. S. Teoh via Digitalmars-d-learn
wrote:
> > - Assignment copies the whole array, as in int[5] a; auto b = a;
>
> Sometimes this is desirable. Consider the 3D game example. Suppose
> you're given a vector and need to perform some computation on it. If
On Thursday, 9 July 2020 at 18:02:02 UTC, IGotD- wrote:
Static arrays are great because as already mentioned, they are
allocated on the stack (unless it is global variable something,
then it ends up in the data segment or TLS area).
As C/C++ now allows dynamically sized static arrays (for
On Thu, Jul 09, 2020 at 06:02:02PM +, IGotD- via Digitalmars-d-learn wrote:
[...]
> Is this the reason that ubyte[arraySize] doesn't create a dynamic
> array with size arraySize?
>
> Now you need to do.
>
> ubyte[] arr;
> arr.length = arraySize;
Nah, just do this:
arr = new
On Thursday, 9 July 2020 at 18:16:58 UTC, CraigDillabaugh wrote:
So is Vibe-d still being actively maintained? I noticed there
have been no new releases in a while, and the forums are a bit
of a disaster (unless you love porn I suppose):
On Thu, Jul 09, 2020 at 05:24:33PM +, matheus via Digitalmars-d-learn wrote:
[...]
> I wonder if the question was more like intended to display the value
> using pointers, ie:
>
> import std.stdio;
>
> void main(){
> int i;
> readf("%d\n", i);
> int *p =
> writeln(*p);
> }
>
On Thursday, 9 July 2020 at 18:51:47 UTC, Paul Backus wrote:
Note that using VLAs in C is widely considered to be bad
practice, and that they were made optional in the C11 standard.
If you want to allocate an array on the stack, the best way is
to use a static array for size below a
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
On 7/9/20 4:31 PM, Max Samukha wrote:
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer wrote:
Yes, that is correct.
Why isn't [] accepted as an empty AA literal?
Because it's an empty dynamic array literal.
If D were to accept an empty AA literal, I'd expect it to be [:].
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
foo( [] ) doesn't
Should work in principle, but you can foo(null) to work around.
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
I always did foo((int[int]).init);
On 7/9/20 5:13 PM, JN wrote:
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer wrote:
On 7/9/20 4:04 PM, JN wrote:
Hmm, foo(null) seems to work, but is it correct way to do it?
Yes, that is correct.
Interesting. Often in D discussion, an argument pops up that the
language
I just didn't expect that the address of a "this" reference may
change.
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
Hmm, foo(null) seems to work, but is it correct way to do
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer
wrote:
On 7/9/20 4:04 PM, JN wrote:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int]
On 7/9/20 4:04 PM, JN wrote:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
Hmm, foo(null) seems to
On Thursday, 9 July 2020 at 20:24:11 UTC, Steven Schveighoffer
wrote:
Yes, that is correct.
-Steve
Why isn't [] accepted as an empty AA literal?
I was learning copy constructors and got a really weird result.
It looks like a copy constructor and a destuctor of two unknown
objects are called. Could somebody please explain it to me?
import std.stdio;
struct Foo {
int value;
this(int n)
{
value =
On 7/9/20 6:08 PM, psycha0s wrote:
import std.stdio;
struct Foo {
int value;
this(int n)
{
value = n;
writeln("constuctor ", );
}
~this()
{
writeln("destuctor ", );
}
this(ref return scope Foo other)
{
value =
On Thursday, 9 July 2020 at 20:08:47 UTC, Anonymouse wrote:
On Thursday, 9 July 2020 at 19:53:42 UTC, JN wrote:
void foo(int[int] bar)
{
// ...
}
Is it possible to send an empty array literal?
foo( [ 0 : 2 ] ) works
foo( [] ) doesn't
int[int] empty;
foo(empty);
works but it's two lines
On Friday, 10 July 2020 at 03:01:20 UTC, mw wrote:
On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
Error: template std.datetime.systime.SysTime.opAssign cannot
deduce function from argument types !()(SysTime) shared,
candidates are:
/usr/include/dmd/phobos/std/datetime/systime.d(659,17):
On Friday, 10 July 2020 at 02:59:56 UTC, mw wrote:
Error: template std.datetime.systime.SysTime.opAssign cannot
deduce function from argument types !()(SysTime) shared,
candidates are:
/usr/include/dmd/phobos/std/datetime/systime.d(659,17):
opAssign()(auto ref const(SysTime) rhs)
of
On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote:
Interesting. Often in D discussion, an argument pops up that
the language should be protecting against hidden breakages from
API changes. This would be an example of that happening.
void foo(int[int] bar), someone calls it with a null,
On Friday, 10 July 2020 at 03:59:37 UTC, Mike Parker wrote:
On Thursday, 9 July 2020 at 21:13:49 UTC, JN wrote:
Interesting. Often in D discussion, an argument pops up that
the language should be protecting against hidden breakages
from API changes. This would be an example of that
```
import std.datetime;
class A {
SysTime time;
}
void main() {
shared A a = new A();
SysTime time;
a.time = time;
}
```
Error: template std.datetime.systime.SysTime.opAssign cannot
deduce function from argument types !()(SysTime) shared,
candidates are:
38 matches
Mail list logo
