Thanks for replying. I will send a pull request. Best!
On Friday, October 9, 2015 at 4:36:48 PM UTC+2, Kevin Squire wrote: > > It was probably an oversight. Why don't you open an issue, and perhaps a > pull request? > > Note that there are deeper/cleaner ways to solve the problem than simply > falling back on SharedArray(T,x). The goal is to move away from that type > of construct, I believe. > > That said, a pull request with that change would be a great start. > > Cheers! > Kevin > > On Fri, Oct 9, 2015 at 7:06 AM, cheng wang <[email protected] <javascript:> > > wrote: > >> Sorry, my second function is wrong. >> >> The following solves the problem. >> call{T}(::Type{Base.SharedArray{T}}, x::Int64) = SharedArray(T, x) >> >> >> On Friday, October 9, 2015 at 3:12:57 PM UTC+2, cheng wang wrote: >>> >>> Hello everyone, >>> >>> For example, In julia 0.4, SharedArray{Int}(100) does not work, while >>> Array{Int}(100). >>> It's kind of inconsistency, though we could get around it by >>> SharedArray(Int, 100). >>> >>> Is there any particular reason for not having SharedArray{T}() >>> constructor? >>> >>> >>> And I also tried to define a new constructor for SharedArray like the >>> follow: >>> 1. SharedArray{T}(x::Int) = SharedArray(T, Int) or, >>> 2. call{T}(Type{Base.SharedArray{T}}, x::Int64) = SharedArray(T, x) >>> Both are illegal. The first one is because T is not used in parameters. >>> and the second one is because "Type{Base.SharedArray{T}}" is invalid. >>> >>> But intuitively, I thought both should be right. Can someone also >>> explain this? >>> >>> Thanks in advance! >>> >> >
