I took this right down to the absolute most basic scenario but for some reason I can't get anything back from the GPU when this completes, could someone explain what I am doing wrong ...
Here's my CPU code:
using (var debugBuffer = new ComputeBuffer(27, sizeof(int)))
{
var kernel = compute....
See also: "What if I told you static fields are just globals?" See also: "What if I told you globals are just fields of the global namespace singleton?"
@MickLH you can do that with nearly the same technique as a singleton, but without the GetInstance() method, still using static or a free function. I have an example here: icydev.net/when-to-use-singletons
in C# or Java it's even easier, since it has built-in static constructors
the singleton design pattern has a "GetInstance" method. if you're talking about something without that, you're using a different definition of "singleton" from everyone else.
but sure, with your definition, it's GetInstance() that I'm really arguing against
and I'm not trying to "prove" anything, and even if I were, it would be an appeal to popularity, not authority. I'm just saying we're talking about different things.
@MickLH it's inherent to the definition of "singleton" that everyone besides you is using, and since pretty much every blog post on the internet says "if you want to limit a class to one instance, use a singleton" then shows an example with GetInstance(), that's what I'm arguing against.
@IcyDefiance A static class is a fucking single instance class (singleton) by definition. What do you not understand? Can you make multiple instances of the static class? So it's a convenient singleton? Ok thought so.
@MickLH it's inherent to the definition of "singleton" that everyone besides you is using, and since pretty much every blog post on the internet says "if you want to limit a class to one instance, use a singleton" then shows an example with GetInstance(), that's what I'm arguing against.
> then shows an example with GetInstance(), that's what I'm arguing against.
you can try to resist that change if you want, and plenty of people do, but when people are trying to discuss something with a certain definition, then trying to argue with a completely different definition is just dishonest
if someone random comes in here and asks "should I use a singleton" and you say "yes", 99.999% of the time they'll type GetInstance(), and you would never qualify your statement to prevent them from doing that.
So, we've covered objectively that a single instance class (singleton) can be implemented by static classes (which is your recommended strategy), or by a GetInstance method (which you recommend against)... is there anything else @AidanMueller needs to know about this topic?
When you consider the opinions of every "shitty blog post" about religion and "the chuck norris of religion" into your religious viewpoint, then you can come back to this argument.
@IcyDefiance logic: All raisins fly harder than fluffy. Therefore your point is invalid.
I can prove this reasoning to be exactly equivalent to yours. Were your parents religious or something?
Because you are.
So, we've covered objectively that a single instance class (singleton) can be implemented by static classes (which is your recommended strategy), or by a GetInstance method (which you recommend against)... is there anything else @AidanMueller needs to know about this topic?
Also, just to be clear, Jon Skeet's definition agrees with mine with exact precision.
"I can prove this reasoning to be exactly equivalent to yours." you can, IF you define "raisins" and "fluffy" yourself. if you neglect to do that, then people will use the normal definitions for those words, which would make the statement nonsensical. just like when you neglect to define "singleton" yourself, people will use the normal definition, which is mine, not yours.
What real (i.e. practical) difference exists between a static class and a singleton pattern?
Both can be invoked without instantiation, both provide only one "Instance" and neither of them is thread-safe. Is there any other difference?
It's really crazy how some people bash something so religiously just because they have never experienced the actual need for it.
The moment you actually need a singleton once, ever, you will understand what it actually is. Your understanding will not be subject to "shitty blog posts".
I asked myself, "who needs to use X". The answer was "Y needs to use X". So anytime I make a new Y, I first make sure that X is ready. Of course, I don't leave Y responsible for the initialization of X, I made an X manager (I will call it X-man).
The problem that I always have that leads me to using Singletons is where there is a class that does one thing, which needs to be called by a lot of things.
The problem I have is that I don't know the proper use of other design patterns well enough...
And I finally decided that thinking about which mine field to cross wasn't getting me anywhere, so I picked a mine field and started walking. I think the mine field I ended up picking isn't too dense. It's working pretty good. In fact I think I boom OW MY LEG OUCH NOT THE RIGHT MINE FIELD.
The biggest thing that I gathered from reading Design Patterns was understanding how OOP should work, and using that knowledge to make "my own" patterns.
Actually I am serious about 3 points on a line, think about it there is 1 possible value of Y on a line with known X, out of infinity possible random choices, therefore probability zero. But mines are not points so of course don't actually trust that algorithm with your life
@TimB Dependency injection is great and all, but what if are trying to abstract everything, and you won't always need to have the dependency? You get what I'm saying?
You're gambling with your horse gibs as you throw them in the line, you may lose some number of horse gibs during mine-tests but never gambling on the correctness of the next step
The problem that I was trying to solve is this: * Main creates an A * B is an implementation of A * All Bs need a C, but not all As are B. Therefore, not all As need a C * ...Meaning that Main can't be responsible for the creation of C, since C is implementation-specific
And also it follows from there being 3 random points on a line with probability zero, that the number of horse gibs used is proportional to the density of mines in the field, not the size of the field itself
user136984
My browser crashed so I got quite a bit delayed, but is everything ok in here now? Or perhaps I have the wrong room? :D
@AidanMueller a line by definition is drawn between 2 points right .. so the probability of finding any random point in between those 3 ... 3 times in a row ... is probably > 0
OK. You could think of the possible places for the point to end up as an infinite set. That infinite set would also include the infinite number of points on the line.
Well, really, the points of the line is a subset of the infinite possible positions, but...
OK, I don't really see too much practical application for this in my life, especially since physical objects don't really have zero size. At least not any physical object that I will be working with, so...
@AidanMueller anything divided by infinity is undefined in the real numbers, which is why I said earlier that you must go into the infinitesimals to explain "next to zero" exactly
lets hear Icy saying that actually math is defined by how you use it
@PearsonArtPhoto or use a static class that wraps the GameObject, which Mick calls a singleton, but no one else on the planet does so I doubt that's what you were thinking of.
@TimB dependency injection solves a different problem than singletons do. DI is to let something else manage the lifetime of an object, while singletons are just global.
I've literally never seen DI used to manage the lifetime of an object, the notion itself almost seems nonsensical to me, so I'll keep an eye out, thanks for the heads up!
DI isn't used to manage the lifetime, it's used to push the responsibility for that management outside of a certain class.
and @AidanMueller, Mick is being loose with definitions again when he talks about 1/infinity, though he did fix that by finally saying it's undefined and the end of your discussion. much simpler explanation here: mathsisfun.com/calculus/limits-infinity.html
and hey, feel free to prove that your definition of "singleton" is the right one. of course you first need to come up with some metric for rightness better than popularity. unfortunately just saying your definition is right doesn't make it so.
@MickLH yeah I noticed that, but since you just expected people to infer the definitions you were using, Adrian didn't get it, at least not at first. my mathsisfun link is a lot simpler because it didn't beat around the bush and try to "blow your mind" by using words in strange ways.
I don't do that, I think this is the projecting thing again.
Can you stop trying to use your own emotional reactions and compensations to model mine? They are simply not related in any meaningful way outside of any other pair of humans.
and hey, feel free to prove that your definition of "singleton" is the right one. of course you first need to come up with some metric for rightness better than popularity. unfortunately just saying your definition is right doesn't make it so.
I took this right down to the absolute most basic scenario but for some reason I can't get anything back from the GPU when this completes, could someone explain what I am doing wrong ...
Here's my CPU code:
using (var debugBuffer = new ComputeBuffer(27, sizeof(int)))
{
var kernel = compute....
What real (i.e. practical) difference exists between a static class and a singleton pattern?
Both can be invoked without instantiation, both provide only one "Instance" and neither of them is thread-safe. Is there any other difference?
