How are an object INSTANCE and a Companion object different and which situations should they be used in.
ObjectName.INSTANCE.iAmStaticMethod();
ClassName.Companion.iAmStaticMethod();
ClassName.Companion can be used also for accessing a non static method
iAmStaicMethod() is a static function and iAmNonStaticMethod() is a non-static function.
So, to call the above methods in Java, write the below code:
ClassName.iAmStaticMethod(); // works fine
ClassName.iAmNonStaticMethod(); // error: not a static method
ClassName.Companion.iAmStaticMethod(); // instance method remains
ClassName.Companion.iAmNonStaticMethod(); // the only way it works
Related
If I have code like this
object ObjectTest {
#JvmStatic
fun init() {
}
}
is it possible to hide the ObjectTest.INSTANCE variable that Kotlin automatically generates? I don't want the object to be accessible via an instance and nor will it have any instance methods, so the INSTANCE variable is just polluting autocomplete and could be confusing to potential users (This code is for a library that will be consumed by others).
Yes, you can do it, by converting an object into a plain file.
#file:JvmName("ObjectTest")
// maybe a package statement here
fun init() {
// here `init` is public static final void
}
And there's no INSTANCE object. In Kotlin this is a top-level function, but in Java it's a class named ObjectTest with a private constructor and it has a public static final void method called init.
I'm attempting to create a class in Swift 3 to implement a Cordova plugin. I have this building and running, but the application crashes whenever any properties of the class are accessed. I've tried two ways of initializing the class:
#objc(DSFMediaCentre)
class DSFMediaCentre : CDVPlugin
{
var players = [UUID:DSFPlayerHandler] ();
...
}
and
#objc(DSFMediaCentre)
class DSFMediaCentre : CDVPlugin
{
var players :[UUID:DSFPlayerHandler];
override init () {
players = [:];
}
...
}
However, when my players property is used, the result is a EXC_BAD_ACCESS exception, with an address that looks like a null pointer dereference.
The object is being created by Objective C code, which is a language I have no familiarity with at all, but I think this is the line that creates it:
obj = [[NSClassFromString(className)alloc] initWithWebViewEngine:_webViewEngine];
The CDVPlugin class contains a comment stating that initWithWebViewEngine should not be overridden (and indeed I do not seem to be able to override this method, because while it is declared in the CDVPlugin.m file, it isn't mentioned in CDVPlugin.h, so the Swift compiler doesn't seem to know about it), but rather initialization code should be placed in a method called pluginInitialize instead. However, if I do that I get a compiler error ("Class DSFMediaCentre has no initializers").
Furthermore, if I put my init() method back in and set it to call pluginInitialize(), like this:
override init () {
super.init(); // necessary otherwise next line is an error
pluginInitialize();
}
override func pluginInitialize() {
players = [:];
}
the error then changes to "Property 'self.players' not initialized at super.init call".
How do I make this class initialize correctly?
You have a mismatch between the strict initialization system required by the language and the procedure used by the framework you're working with.
Swift demands that a) properties be initialized as part of object construction, and b) that construction be chained to the type's supertype. But the CDVPlugin type is doing the construction on your behalf; you don't have the ability to customize it. (This makes more sense in ObjC, because it doesn't have the same compile-time restrictions as Swift.)
The situation is similar to unpacking an object from a nib file. In that case too, because it's the nib loading system that's constructing your object, you don't have the ability to customize the initializer. Your type will always be constructed by init(coder:). In a certain sense, your initialization point moves further down, to awakeFromNib(), and among other things, that forces outlets to other objects in the archive to be declared as optional, usually implicitly unwrapped.
The same solution should avail you here. You should consider pluginInitialize() to be your initialization point. The language then requires that properties be optional, since they are not filled at its initialization point. Therefore, make the property an IUO:
#objc(DSFMediaCentre)
class DSFMediaCentre : CDVPlugin
{
var players :[UUID:DSFPlayerHandler]!
override func pluginInitialize() {
players = [:];
}
}
and all should be well.
The other solution is to use lazy keyword
lazy var players :[UUID:DSFPlayerHandler] = [:]
So, you don't need to initialize players in initializer but still make sure players always non-nulable
I would like to use TComInterface to replace raw pointer.
My current code is:
{
TComInterface<IStoreNamespace> pStore;
if (SUCCEEDED(CoCreateInstance(CLSID_StoreNamespace, NULL, CLSCTX_INPROC_SERVER, IID_IStoreNamespace, (LPVOID*)&pStore)))
{
if (SUCCEEDED(pStore->Initialize(Form1->Handle, 1)))
{
//pStore->CallOtherMethods...
}
}
// Release()'d automatically?
}
If I understood correctly this overwrites the pStore pointer with new pointer so it doesn't call pStore->Release(); automatically from eventually previous instance using pStore.
Under what conditions is Release() called? I believe it may be when the variable goes out of scope even if I initialized it like this. And what is the proper way to initialize pStore in above example so it doesn't just overwrite pointer but also calls Release() first?
TComInterface calls Release() on its internal interface when TComInterface goes out of scope and gets destructed. You can also call the TComInterface::Unbind() method if you want to manually Release() the interface sooner. TComInterface also calls Release() on its current interface if you assign a new interface pointer (or other TComInterface instance) via the = assignment operator.
TComInterface overrides the & operator to return a pointer to its internal interface, so you have to make sure that TComInterface is not holding an active interface before you call CoCreateInstance() (or anything else that will copy a new interface into TComInterface) or else the preview interface will be leaked and not released. TComInterface's default constructor sets the internal interface to NULL, so you don't usually have to worry about that, unless you re-use the same TComInterface variable multiple times, such as when using interface enumerators in a loop.
Well, I have something like this:
trait A
class Serving(a: => A)
object App extends Serving(App.Main) {
object Main extends A
}
And I get the error super constructor cannot be passed a self reference unless parameter is declared by-name. I can work around by doing
object App extends Serving(Serv.Main)
object Serv {
object Main extends A
}
but I don't want to. It adds 2 extra .classes and it strikes me as unelegant.
And using object App extends Serving(this.Main) also creates an error. The structure of A and Serving cannot really be changed, but is there any way to work around this error?
Your code compiles just fine in Scala 2.8.1, even if the parameter is not declared by-name.
I want to make a global vector of my own object class called "Person". However, the compiler says that
error C2039: '{dtor}' : is not a member of 'System::IDisposable'
1> c:\windows\microsoft.net\framework\v2.0.50727\mscorlib.dll : see declaration of 'System::IDisposable'
So I looked up how to implement IDisposable (which I now know is used primarily for unmanaged resources) but still can't seem to implement it with the following:
ref class Globals : System::IDisposable
{
public:
static cliext::vector<Person^> person_data = gcnew cliext::vector<Person^>;
void Dispose()
{
delete person_data;
}
};
The 2 errors I get are:
error C2605: 'Dispose' : this method is reserved within a managed class
1> did you intend to define a destructor?
error C3766: 'Globals' must provide an implementation for the interface method 'void System::IDisposable::Dispose(void)'
1> c:\windows\microsoft.net\framework\v2.0.50727\mscorlib.dll : see declaration of 'System::IDisposable::Dispose'
You don't have to explicitly derive from IDisposable. Following the MSDN doco, use the following pattern:
ref class Globals
{
public:
static cliext::vector<Person^> person_data = gcnew cliext::vector<Person^>;
!Globals() // finalizer
{
delete person_data;
{
protected:
~Globals() // destructor calls finalizer
{
this->!Globals();
}
};
Use a destructor. In C++/CLI ~ClassName() is Dispose() and !ClassName() is equivalent to C#'s ~ClassName(). In your case:
ref class Globals : System::IDisposable
{
public:
static cliext::vector<Person^> person_data = gcnew cliext::vector<Person^>;
void ~Globals()
{
delete person_data;
}
};
use a finalizer as shown at http://www.codeproject.com/KB/mcpp/cppclidtors.aspx
You don't need to implement Dispose() yourself, either directly or via a destructor. The implicitly-generated destructor already destroys all member objects. The IDisposable interface will be added automatically, don't mention it explicitly.
Next, you need to make up your mind whether person_data is a handle (which has to be set to an instance created with gcnew) or member object semantics (like stack semantics, the constructor is automatically called by the constructor of the parent object, the destructor called automatically when the lifetime of the parent object ends, and you use "." instead of "->" to access members).
Also, are you sure you want one copy of person_data shared between all instances of "Globals", but destroyed by the first instance to be disposed, leaving any other instances holding an invalid reference (reference to disposed object)? It looks like you're trying to use a Singleton anti-pattern here, is that correct?
From C++/CLI in Action The C++/CLI Dispose pattern has these rules (paraphrased):
If a class has a finalizer or a
destructor the compiler generates
Dispose(bool) that will call either
the finalizer or destructor based on
the bool value.
If it has just a d'tor (~type) then the compiler calls
Dispose(true) so the d'tor is called.
If it has just a finalizer (!type)
then the compiler calls
Dispose(false) so the finalizer is
called
Also for the second rule: The compiler will implement the IDisposable interface for you (by generating Dispose()). It then uses SuppressFinalize to make sure the finalizer isn't called.
I did this to your code and the only way I could get it to compile was to make person_data a instance member. The error i got when it was static was error C2039: '{dtor}' : is not a member of 'System::IDisposable' which doesn't make much sense.
Also, do you even need to delete the person_data vector since is a managed object? Maybe you do but I haven't used the cliext enough to say.
Edit Perhaps the first paragraph of this article has the answer (emphasis mine):
When you declare a member variable as
static and when the application
starts, the compiler creates a copy of
that member. This member would be
maintained by the compiler while the
program is running. If you declare an
instance of a class, like the above
vehicle variable, the static member is
not part of the object: the compiler
creates and maintains the static
member, whether you use it or not,
whether you declare a class variable
or not.