Re: Passing a generic struct as parameter
Well, the problem is that I must do the cast always, see :
// alias Matrix!(real,4) Mat4r;
// alias Vector!(float, 3) Vec3f;
// alias Vector!(real, 4) Vec4r;
// In Mat4r, VCol it's aliased to Vector!(real, 4)
auto tcol = Mat4r.IDENTITY;
auto v = cast(tcol.VCol) Vec3f(1, 2 ,3 );
auto v2 = Vec4r(-1, -2 ,-3 ,-4);
tcol[1] = v2; // Do a compiler error
tcol[2] = v;
I get this error :
Error: function zmath.matrix.Matrix!(real,4).Matrix.opIndexAssign (real
c, ulong row, ulong cl) is not callable using argument types (Vector!
(real,4),int)
Error: cannot implicitly convert expression (v2) of type Vector!(real,4)
to Vector!(real,dim)
If I do cast(tcol.Vcol) to v2, this works.
Plus if I do a typeid(v1), typeid(v2) to see his types, I get this :
zmath.vector.Vector!(real,4).Vector zmath.vector.Vector!(real,dim).Vector
On Fri, 01 Jul 2011 02:29:58 +0200, Simen Kjaeraas wrote:
On Fri, 01 Jul 2011 01:39:53 +0200, Zardoz luis.panad...@gmail.com
wrote:
I have a parametrized struct (Vector!(T, dim)) that takes two
parameters (Type and a number). And made some Alias with defaults
parameters.
In other struct (Matrix!(T, dim)), that uses these struct to represent
a matrix in column-major order. I have a internall alias for Vector
using internally (alias Vector!(T,dim_) VCol;) . The problem that I
have it's when I try to use opIndexAssign to assign to a column a
Vector. I try this :
void opIndexAssign(Vector v, size_t j) {
if ( code that see if VCol if same type that v ) {
col[j] = v;
} else {
col[j] = cast (VCol) v;
}
}
But not compile... I get this error : Error: struct
zmath.vector.Vector(T,ulong dim_) if (__traits (isFloating,T)) is used
as a type
Error: template instance zmath.matrix.Matrix!(float,2) error
instantiating
So finally I try this :
/**
* Assigns a new column vector
*/
void opIndexAssign(VCol v, size_t j) {
col[j] = v;
}
But now I must do cast outside, even knowing that are same type. Plus
now I must keep VCol alias public.
How should fix this, or What is the correct way of doing this ?
Private symbols in D are visible outside the defining module (and
private symbols are accessible inside the same module), so having the
alias private is no problem.
In other words, the latter solution is good, and should not require any
casting or public alias.
Or have I perhaps misunderstood? Is there some other reason you need to
cast?
Also, the error message you get (Vector(...) is used as a type) is
indicative of your referring to the Vector template rather than an
instantiation. Struct templates in D behave as if defined thusly:
template Foo( T ) {
struct Foo {
}
}
for a struct Foo( T ).
Note : I have a opCast for Vector that cast between Vectors with
different parameters and it's checked that works.
Second Question : I'm thinking publish this small Vector/Quaternion/
Matrix lib that I made learning D2.. where I should put and how ? (and
I use Git)
GitHub, then? Or dsource.org.
--
Yep, I'm afraid that I have a blog : zardoz.es
Re: Passing a generic struct as parameter
Thanks. I imagined something similar, that Vector alone not is type.
How I can templatize opIndexAssign function ? I tried this :
void opIndexAssign(U)(U v, size_t j) {
col[j] = v;
}
And I get a error :
Error: template zmath.matrix.Matrix!(float,2).Matrix.opIndexAssign(U) conflicts
with function
zmath.matrix.Matrix!(float,2).Matrix.opIndexAssign at src/matrix.d(261)
That I interpret that this opIndexAssign clash with other opIndexAssign that I
have to direct access to
matrix cells
void opIndexAssign(T c, size_t row, size_t cl) {
col[cl][row] = c;
}
I said before that I made a opCast for Vector ?
On Fri, 01 Jul 2011 00:12:43 +, Jonathan M Davis wrote:
On 2011-06-30 16:39, Zardoz wrote:
I have a parametrized struct (Vector!(T, dim)) that takes two
parameters (Type and a number). And made some Alias with defaults
parameters.
In other struct (Matrix!(T, dim)), that uses these struct to represent
a matrix in column-major order. I have a internall alias for Vector
using internally (alias Vector!(T,dim_) VCol;) . The problem that I
have it's when I try to use opIndexAssign to assign to a column a
Vector. I try this :
void opIndexAssign(Vector v, size_t j) { if ( code that see if VCol if
same type that v ) { col[j] = v;
} else {
col[j] = cast (VCol) v;
}
}
But not compile... I get this error : Error: struct
zmath.vector.Vector(T,ulong dim_) if (__traits (isFloating,T)) is used
as a type
Error: template instance zmath.matrix.Matrix!(float,2) error
instantiating
So finally I try this :
/**
* Assigns a new column vector
*/
void opIndexAssign(VCol v, size_t j) { col[j] = v;
}
But now I must do cast outside, even knowing that are same type. Plus
now I must keep VCol alias public.
How should fix this, or What is the correct way of doing this ?
Note : I have a opCast for Vector that cast between Vectors with
different parameters and it's checked that works.
Second Question : I'm thinking publish this small Vector/Quaternion/
Matrix lib that I made learning D2.. where I should put and how ? (and
I use Git)
The first thing that you need to understand is that Vector is not a
type. It does not exist. Vector!(int, 4) is a type. Vector!(float, 3) is
a type. Vector is not. Vector is a template for a type. When you use a
template, you instantiate it for a particular set of arguments, and that
creates a new type. An instantiation of a templated type such as Vector
is a type, and every instantiation is its own, separate type which has
no connection with any other instantion of that template. So, it makes
no sense for a function to take a Vector (though within the Vector
template that works, because Vector stands for that particular
instantiation inside of the Vector template). If you want a function to
take multiple instantiations of a template, then you need to templatize
the function. If you want it to take a particular instantiation of a
template, then you give its parameter that exact template instantiation.
Now, if you want two separate instantions (such as Vector!(int, 3) and
Vector! (float, 3)) to interact, you're going to need to either write
opCasts to cast between them or have templated functions which are
templated on both of their types (e.g. func(V1, V2)(V1 vector1, V2
vector2) {...}). They are two completed different types, just like if
you created IntVector and FloatVector, so you have to write code which
allows them to interact. They aren't going to just work together because
they came from the same template.
- Jonathan M Davis
--
Yep, I'm afraid that I have a blog : zardoz.es
Re: C callback receives bad pointer argument
On 01/07/2011 00:30, Andrej Mitrovic wrote: Try this: int process (jack_nframes_t nframes, void *arg) - extern(C) int process (jack_nframes_t nframes, void *arg) Thank you Andrej, that solved the problem! Please can you biefly explain me what happens in the stack when calling that function with and without the extern(C) declaration? I think that the D language would benefit from a deep, complete and open guide on how to _practically_ interface with C, accounting some popular designs cases not just a bunch of trivial cases like using 'printf' and a translation table of base types. Marco
Re: C callback receives bad pointer argument
On 2011-07-01 11:13, Marco Cosentino wrote: On 01/07/2011 00:30, Andrej Mitrovic wrote: Try this: int process (jack_nframes_t nframes, void *arg) - extern(C) int process (jack_nframes_t nframes, void *arg) Thank you Andrej, that solved the problem! Please can you biefly explain me what happens in the stack when calling that function with and without the extern(C) declaration? I think that the D language would benefit from a deep, complete and open guide on how to _practically_ interface with C, accounting some popular designs cases not just a bunch of trivial cases like using 'printf' and a translation table of base types. Marco What happens without extern(C) is that the function will use the D calling convention, with it, it will use the C calling convention. The C code your interfacing with excepts functions and function pointers with the C calling convention. See: http://www.digitalmars.com/d/2.0/interfaceToC.html http://www.digitalmars.com/d/2.0/htomodule.html -- /Jacob Carlborg
Re: Creating a thread-local duplicate of a globally shared array
On Fri, 01 Jul 2011 01:14:26 -0400, Andrej Mitrovic
andrej.mitrov...@gmail.com wrote:
I have two functions running concurrently and they share data via a
globally shared array.
Generally one thread modifies an array and potentially changes its
length, the other thread reads from it. I have to avoid too many locks
and message passing wouldn't really work since I need fast access to
the array.
I can't use the array directly in the reading thread because the array
could possibly be reallocated by the writing thread (e.g. if it
changes the .length property), while at the same time the reading
thread could just have sent the .ptr value of that array to some API
function. I've had this problem occur and the app would crash due to a
reallocation while the API was reading the array.
Here's the gist of it:
__gshared int[] values;
void foo()
{
// modify, write to the array, and possibly change the length
}
It's not quite safe (even with locks) to alter __gshared array lengths
from more than one thread. This is due to the assumption that any array
not marked shared is thread local. This includes __gshared data, since
__gshared is not part of the type.
What can happen is the array block information can be cached in the thread
local LRU append cache, and another thread could extend the data, thereby
changing the block information. When the first thread then tries to use
the block information, he gets a stale block info from the runtime, and
can make incorrect assumptions.
Have you tried changing __gshared to shared? shared should be supported.
-Steve
Re: Passing a generic struct as parameter
On Fri, 01 Jul 2011 08:58:32 +0200, Zardoz luis.panad...@gmail.com wrote:
Well, the problem is that I must do the cast always, see :
// alias Matrix!(real,4) Mat4r;
// alias Vector!(float, 3) Vec3f;
// alias Vector!(real, 4) Vec4r;
// In Mat4r, VCol it's aliased to Vector!(real, 4)
auto tcol = Mat4r.IDENTITY;
auto v = cast(tcol.VCol) Vec3f(1, 2 ,3 );
auto v2 = Vec4r(-1, -2 ,-3 ,-4);
tcol[1] = v2; // Do a compiler error
tcol[2] = v;
So more likely, this is what you want:
void opIndexAssign(U)(Vector!(U,dim) v, size_t j) {
static if (is(U == T)) {
col[j] = v;
} else {
col[j] = cast(VCol)v;
}
}
--
Simen
Re: C callback receives bad pointer argument
On 7/1/11, Marco Cosentino cosentino...@gmail.com wrote: On 01/07/2011 00:30, Andrej Mitrovic wrote: Try this: int process (jack_nframes_t nframes, void *arg) - extern(C) int process (jack_nframes_t nframes, void *arg) Thank you Andrej, that solved the problem! Please can you biefly explain me what happens in the stack when calling that function with and without the extern(C) declaration? I think that the D language would benefit from a deep, complete and open guide on how to _practically_ interface with C, accounting some popular designs cases not just a bunch of trivial cases like using 'printf' and a translation table of base types. Marco This is a good start: http://en.wikipedia.org/wiki/Calling_convention
Re: Creating a thread-local duplicate of a globally shared array
Thanks for the help. But it appears I've ran into some kind of other bug. ddbg: Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc005) at __aaInX (0x0041b616) thread(552) That seems like the hash method for checking keys. I have a static int[int] hash which I'm not sharing with other threads, I just check if a key is in there. Damn, this will take some work to make a good test case..
Re: r/w binary
Ok, I get you. A whole int*, not one byte of the int* data. - Joel On 01-Jul-11 6:07 AM, Ali Çehreli wrote: On Fri, 01 Jul 2011 05:28:56 +1200, Joel Christensen wrote: Shouldn't file.rawWrite((i)[0..1]); have [0..4]? Or am I missing some thing? [0..1] follows the regular slicing syntax there: those are element indexes. Sincei is an int*, [0..1] slices the first int. It would be different if it were ubyte* or void*. Ali
void.sizeof == 1, not 0
What is contained within this byte? (T[0]).sizeof == 0, why isn't void also 0?
Re: Why does std.string use public imports?
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to be
in std.string but were generalized and moved to other modules. So, rather
than immediately break code, they were publicly imported in std.string.
They're scheduled for deprecation and will be removed once the deprecation
process has completed. However, they shouldn't be causing conflicts. It's
probably due to a bug related to explicit imports being seen as new
functions in the module that they're imported into (I forget the bug
number). Maybe using static imports with aliases would fix the problem.
Actually, now that I look at it more closely, the problem that you're seeing
is fully expected and desired. It's complaining that std.string has a count
function and that std.utf has a count function and that it doesn't know which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so you're
going to get the same conflict between std.algorithm.count and std.utf.count -
which is expected. The public import is part of the deprecation and will go
away eventually. At that point, std.string and std.utf will no longer conflict
for count, because std.string won't have a count function anymore. But there's
no bug here. What you're seeing here is exactly what std.string and std.utf
have been doing for some time. It's a natural side effect of using the same
function name in multiple modules. Using the full module path for the function
fixes the problem (though it doesn't work with the member function call syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
Re: void.sizeof == 1, not 0
On Fri, 01 Jul 2011 21:18:45 +0200, simendsjo wrote:
What is contained within this byte?
(T[0]).sizeof == 0, why isn't void also 0?
void* can point to any data, in which case it is considered to be
pointing at the first byte of the data. Having a size of one makes it
point to the next byte when incremented:
int i;
void * v = i; // first byte
++v; // second byte
Similarly, an empty struct has a size of one:
import std.stdio;
struct S
{}
void main()
{
assert(S.sizeof == 1);
}
But in that case it is needed to identify S objects from one another just
by having different addresses. The following array's data will occupy 10
bytes:
S[10] objects;
assert((objects[0]) != (objects[1]));
Ali
Re: Why does std.string use public imports?
On 01.07.2011 22:06, Jonathan M Davis wrote:
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to be
in std.string but were generalized and moved to other modules. So, rather
than immediately break code, they were publicly imported in std.string.
They're scheduled for deprecation and will be removed once the deprecation
process has completed. However, they shouldn't be causing conflicts. It's
probably due to a bug related to explicit imports being seen as new
functions in the module that they're imported into (I forget the bug
number). Maybe using static imports with aliases would fix the problem.
Actually, now that I look at it more closely, the problem that you're seeing
is fully expected and desired. It's complaining that std.string has a count
function and that std.utf has a count function and that it doesn't know which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so you're
going to get the same conflict between std.algorithm.count and std.utf.count -
which is expected. The public import is part of the deprecation and will go
away eventually. At that point, std.string and std.utf will no longer conflict
for count, because std.string won't have a count function anymore. But there's
no bug here. What you're seeing here is exactly what std.string and std.utf
have been doing for some time. It's a natural side effect of using the same
function name in multiple modules. Using the full module path for the function
fixes the problem (though it doesn't work with the member function call syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
Isn't it expected that std.string contains a count method?
import std.stdio;
import std.string;
void main() {
auto s = à;
writeln(s.length); // 2 - often you want the actual number of
characters, not code points
writeln(s.count()); // 1 - should a user need to import count from
algorithm/utf to get this?
}
Re: Passing a generic struct as parameter
Finally I try this small test code :
struct A(T, int U) {
T x;
static enum foo = U;
Tout opCast( Tout ) ()
if (isA!Tout) {
Tout nt;
nt.x = x;
return nt;
}
string toString() {
return to!string(x);
}
}
struct B(T, int I) {
enum foo2 = I;
alias A!(T, foo2) Internal;
Internal[foo2 * 2] y;
void opIndexAssign(K) (K v, size_t j)
if (isA!(K) K.foo == Internal.foo is(typeof(K.x) ==
typeof(y[0].x)) ) {
y[j] = v;
}
void opIndexAssign(K) (K v, size_t j)
if (isA!(K) (K.foo != Internal.foo || !is(typeof(K.x) ==
typeof(y[0].x))) ) {
y[j] = Internal(v.x);
}
}
template isA(T) {
immutable bool isA = __traits(compiles,
(){
T t;
auto x = t.x;
auto u = t.foo;
}
);
}
auto bla = A!(int, 2) (10);
auto bla2 =A!(int, 5) (5)
B!(int, 3) bleh;
bleh[1] = bla;
bleh[3] = bla2;
writeln(bleh.y);
And write : [0, 10, 0, 5, 0, 0]
So this works. Only I need to discover why when I try it over Vector
and Matrix class, I get errors...
Finally, I upload to github : git://github.com/Zardoz89/zmath.git
I hope that I not write some barbaric thing in my code
I do all self-learning D
On Fri, 01 Jul 2011 17:19:36 +0200, Simen Kjaeraas wrote:
On Fri, 01 Jul 2011 08:58:32 +0200, Zardoz luis.panad...@gmail.com
wrote:
Well, the problem is that I must do the cast always, see :
// alias Matrix!(real,4) Mat4r;
// alias Vector!(float, 3) Vec3f;
// alias Vector!(real, 4) Vec4r;
// In Mat4r, VCol it's aliased to Vector!(real, 4)
auto tcol = Mat4r.IDENTITY;
auto v = cast(tcol.VCol) Vec3f(1, 2 ,3 ); auto v2 = Vec4r(-1, -2 ,-3
,-4);
tcol[1] = v2; // Do a compiler error
tcol[2] = v;
So more likely, this is what you want:
void opIndexAssign(U)(Vector!(U,dim) v, size_t j) {
static if (is(U == T)) {
col[j] = v;
} else {
col[j] = cast(VCol)v;
}
}
--
Yep, I'm afraid that I have a blog : zardoz.es
Re: Why does std.string use public imports?
On 7/1/11, Jonathan M Davis jmdavisp...@gmx.com wrote:
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to be
in std.string but were generalized and moved to other modules. So, rather
than immediately break code, they were publicly imported in std.string.
They're scheduled for deprecation and will be removed once the deprecation
process has completed. However, they shouldn't be causing conflicts. It's
probably due to a bug related to explicit imports being seen as new
functions in the module that they're imported into (I forget the bug
number). Maybe using static imports with aliases would fix the problem.
Actually, now that I look at it more closely, the problem that you're seeing
is fully expected and desired. It's complaining that std.string has a count
function and that std.utf has a count function and that it doesn't know
which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long
time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so
you're
going to get the same conflict between std.algorithm.count and std.utf.count
-
which is expected. The public import is part of the deprecation and will go
away eventually. At that point, std.string and std.utf will no longer
conflict
for count, because std.string won't have a count function anymore. But
there's
no bug here. What you're seeing here is exactly what std.string and std.utf
have been doing for some time. It's a natural side effect of using the same
function name in multiple modules. Using the full module path for the
function
fixes the problem (though it doesn't work with the member function call
syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
When did I ever say it was a bug? I said it's annoying that there's
conflicts due to public imports. If it's going away, good. I know
algorithm has count, but I never imported that module, std.string
imported it publicly so I got conflicts even though I was trying to
avoid them.
Re: Passing a generic struct as parameter
Ok, I fixed it. I just need to put (K) type parameter to the other opIndexAssign
D not allow overload operators/methods with different type parameters.
They must share same type parameters :
void opIndexAssign(K)(K c, size_t row, size_t cl) {... }
void opIndexAssign(K) (K v, size_t j) { ... }
On Fri, 01 Jul 2011 21:46:56 +, Zardoz wrote:
Finally I try this small test code :
struct A(T, int U) {
T x;
static enum foo = U;
Tout opCast( Tout ) ()
if (isA!Tout) {
Tout nt;
nt.x = x;
return nt;
}
string toString() {
return to!string(x);
}
}
struct B(T, int I) {
enum foo2 = I;
alias A!(T, foo2) Internal;
Internal[foo2 * 2] y;
void opIndexAssign(K) (K v, size_t j) if (isA!(K) K.foo ==
Internal.foo is(typeof(K.x) == typeof(y[0].x)) ) {
y[j] = v;
}
void opIndexAssign(K) (K v, size_t j) if (isA!(K) (K.foo !=
Internal.foo || !is(typeof(K.x) == typeof(y[0].x))) ) {
y[j] = Internal(v.x);
}
}
template isA(T) {
immutable bool isA = __traits(compiles,
(){
T t;
auto x = t.x;
auto u = t.foo;
}
);
}
auto bla = A!(int, 2) (10);
auto bla2 =A!(int, 5) (5)
B!(int, 3) bleh;
bleh[1] = bla;
bleh[3] = bla2;
writeln(bleh.y);
And write : [0, 10, 0, 5, 0, 0]
So this works. Only I need to discover why when I try it over Vector and
Matrix class, I get errors...
Finally, I upload to github : git://github.com/Zardoz89/zmath.git I hope
that I not write some barbaric thing in my code I do all
self-learning D
On Fri, 01 Jul 2011 17:19:36 +0200, Simen Kjaeraas wrote:
On Fri, 01 Jul 2011 08:58:32 +0200, Zardoz luis.panad...@gmail.com
wrote:
Well, the problem is that I must do the cast always, see :
// alias Matrix!(real,4) Mat4r;
// alias Vector!(float, 3) Vec3f;
// alias Vector!(real, 4) Vec4r;
// In Mat4r, VCol it's aliased to Vector!(real, 4)
auto tcol = Mat4r.IDENTITY;
auto v = cast(tcol.VCol) Vec3f(1, 2 ,3 ); auto v2 = Vec4r(-1, -2 ,-3
,-4);
tcol[1] = v2; // Do a compiler error
tcol[2] = v;
So more likely, this is what you want:
void opIndexAssign(U)(Vector!(U,dim) v, size_t j) {
static if (is(U == T)) {
col[j] = v;
} else {
col[j] = cast(VCol)v;
}
}
--
Yep, I'm afraid that I have a blog : zardoz.es
Re: Why does std.string use public imports?
On 2011-07-01 14:58, Andrej Mitrovic wrote:
On 7/1/11, Jonathan M Davis jmdavisp...@gmx.com wrote:
On 2011-06-30 17:12, Jonathan M Davis wrote:
On 2011-06-30 16:14, Andrej Mitrovic wrote:
I'm referring to these two in std.string:
public import std.algorithm : startsWith, endsWith, cmp, count;
public import std.array : join, split;
Because whenever I try to use .count in my code:
import std.stdio;
import std.string;
import std.utf;
void main()
{
writeln(foo.count);
}
std.utf.count conflicts with std.string's publicly imported
std.algorithm.count
Can we avoid public imports in modules? The rise of conflicts in
Phobos is getting slightly annoying.
I believe that they're there because the functions in question used to
be in std.string but were generalized and moved to other modules. So,
rather than immediately break code, they were publicly imported in
std.string. They're scheduled for deprecation and will be removed once
the deprecation process has completed. However, they shouldn't be
causing conflicts. It's probably due to a bug related to explicit
imports being seen as new functions in the module that they're imported
into (I forget the bug number). Maybe using static imports with aliases
would fix the problem.
Actually, now that I look at it more closely, the problem that you're
seeing is fully expected and desired. It's complaining that std.string
has a count function and that std.utf has a count function and that it
doesn't know which
to use. That's exactly what's supposed to happen when two modules have
functions which conflict. std.string has had a count function for a long
time.
So, this is the behavior that you would have seen for a long time.
std.string's count has been generalized and moved to std.algorithm, so
you're
going to get the same conflict between std.algorithm.count and
std.utf.count -
which is expected. The public import is part of the deprecation and will
go away eventually. At that point, std.string and std.utf will no longer
conflict
for count, because std.string won't have a count function anymore. But
there's
no bug here. What you're seeing here is exactly what std.string and
std.utf have been doing for some time. It's a natural side effect of
using the same function name in multiple modules. Using the full module
path for the function
fixes the problem (though it doesn't work with the member function call
syntax
in that case). It's how the module system works and fully expected.
- Jonathan M Davis
When did I ever say it was a bug? I said it's annoying that there's
conflicts due to public imports. If it's going away, good. I know
algorithm has count, but I never imported that module, std.string
imported it publicly so I got conflicts even though I was trying to
avoid them.
Well, for some functions, conflicts are going to be pretty much inevitable.
And the number is only likely to go up as Phobos' size increases. Smart
function naming reduces it, but sometimes the best name is the same name as
one which already exists, and conflicts are going to happen. They won't
normally be public imports like that, but they're going to happen.
- Jonathan M Davis
A different vector op
Currently this is not allowed, but do you desire a feature like this?
struct Foo {
int x, y;
int[100] array;
}
void main() {
auto foos = new Foo[100];
foos[].y += 10; // ***
}
Bye,
bearophile
