got it. Thanks Ian
在 2018年12月7日星期五 UTC+8下午12:59:49，Ian Lance Taylor写道：
>
> On Thu, Dec 6, 2018 at 8:45 PM Chao Yuepan > wrote:
> >
> > Java implements singleton by double-checking must use keyword volatile :
> >
> >
> > class Foo {
> > private volatile Bar bar;
> >
> > public Bar
On Thu, Dec 6, 2018 at 8:45 PM Chao Yuepan wrote:
>
> Java implements singleton by double-checking must use keyword volatile :
>
>
> class Foo {
> private volatile Bar bar;
>
> public Bar getBar() {
> Bar value = bar;
> if (value == null) {
> synchronized (this) {
>
Java implements singleton by double-checking must use keyword volatile :
class Foo {
private volatile Bar bar;
public Bar getBar() {
Bar value = bar;
if (value == null) {
synchronized (this) {
value = bar;
if (value == null) {
bar = value =
How would generics help you here? The WithTxn function is already generic
(courtesy of closures) and there's no reason it couldn't be put in a
publicly importable package somewhere.
On Thu, 6 Dec 2018, 10:26 pm Eric Johnson
>
> On Thu, Dec 6, 2018 at 12:16 AM roger peppe wrote:
>
>>
>>
>> On
Hi Golangnuts,
I'm trying to run SignerCrc32() concurently, but instead it runs
sequentially. Can you explain why?
https://play.golang.org/p/l5A3tBSqfs1
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
On Thu, Dec 6, 2018 at 12:16 AM roger peppe wrote:
>
>
> On Wed, 5 Dec 2018 at 18:55, 'Eric Johnson' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I always go with the approach that uses the equivalent of the
>> "Transact()" method.
>>
>> On top of that, rather than use a generic
thanks Ian, i had it done this way
https://github.com/clementauger/stdlist/blob/master/raw.go
Le lundi 26 novembre 2018 21:06:24 UTC+1, Ian Lance Taylor a écrit :
>
> On Mon, Nov 26, 2018 at 7:07 AM >
> wrote:
> >
> > I m looking for a reliable way to determine if a package path string
>
That would definitely be possible. But it isn’t likely to happen. It would make
the rule several times more complicated that it currently is, to fix something
that only happens occasionally, is caught at compile time, and is easily taken
care of with an explicit type conversion. That doesn’t
Would it be possible in the future that the compiler holds a set of the
possible types for a given untyped value, and assigns it the "minimum" type
if int does not belong to the possible ones? this holds only for integer
types of course. In the current example we'd have :
1 << 64 - 1 is integer
I forgot to mention that the main way to work around this limitation has to
do with separating declarations of types shared by the two otherwise
circularly importing packages. But it gets tricky again then when it comes
to defining methods on the types, because you can't declare methods on
On Wed, 5 Dec 2018 at 18:55, 'Eric Johnson' via golang-nuts <
golang-nuts@googlegroups.com> wrote:
> I always go with the approach that uses the equivalent of the "Transact()"
> method.
>
> On top of that, rather than use a generic *sql.Tx parameter to the
> "txFunc" function, I pass an interface
11 matches
Mail list logo
