I have a class that is used to store and retrieve image data from a cache using NSFileManager. When an instance of it is created, I want to check whether the image directory already exists, and if not, create it. Where is the most appropriate place to put this code? Is this something one would override the designated initializer for?
Thanks for reading.
The initialiser (init) function would be the best place to do it from a programming perspective because the rest of the instance methods would probably rely on having access to the directory to store/retrieve images.
You'd also want any instances created to know whether the accessing/creating was successful so in your initialiser you may wish to put some error handling which returns a nil instance (or throws an exception) if it can't be accessed which can then be handled by the classes which use the instance of your cache class.
Related
As the topic, when I use ortools, I want to serialize cpsolver, CpSolverSolutionCallback and cpmodel to achieve multithread computing. However, I can't just serialize those objects directly and I think I need to only serialize their configuration and reset configuration in each thread, such as all the constraint and variables in the cpmodel and parameters in cpsolver. This is the question, how can I get all those values using ortools? Is there an api or something? I can't find it when searching on Google.
Every language implements a thin wrapper above a protocol buffer file.
This file is described here
This model is accessible from each CpModel class.
Now you can distribute work using this proto directly. You will need to look at the CpSolver class to understand how the c++ Solve method is called.
See the python solve method.
The way to implement your request.
Create your model normally.
Extract the underlying protocol buffer model underneath and use it for parallelism/distribution.
Solve will returns a CpSolverResponse object. To get the value of a variable in the response, call response.Value(var.Index()), or store the index of the relevant variables and use it in the Value() method call.
I have splitted my application into two main areas.
Part(A)
PartStashContainer(B)
The content of A should be set based on what user wants.
So basically i can have 1..N classes which could be used in Class URI of Part in application model.
I don't know if i should replace the whole Part(A) with new dynamically created Part(C) which has content i want, or i should somehow to modify the existing Part (call setContributionURI, or setObject methods on Part object?).
It does make more sense to me to modify the existing Part, because it is defined in Application model and therefore already describing the location where the content should be.
Possible solutions:
Modify the Part object so it "reload" its content based on new setup (But how? Can setContributionURI or setObject methods help?)
Remove the old Part and add dynamically on same place in Application model the new Part (using EModelService and EPartService).
other solution??
If you want to reuse the Part then do something like:
MPart part = find or inject your part
MyClass myClass = (MyClass)part.getObject();
... call a method of MyClass to change the contents
MyClass is the class you specify for the object in the application model. You should add a method to that to let you change the contents.
Don't try to call setObject, this is really only for use by Eclipse. I don't think setContributionURI would do anything after the part is created (but I am not sure).
If you want to use different classes for the different data then you really should use different Parts.
From within a class derived from FB::PluginCore (or FB::JSAPIAuto), for example in onPluginReady() or a JS method handler, I'd like to have access to the NPP instance. What is the best practice for getting this pointer?
The underlying goal is to be able to call NPN_SetValueForURL, to set cookies.
You can call any of the NPN functions on the NpapiBrowserHost object, which is what the BrowserHost actually is.
FB::Npapi::NpapiBrowserHostPtr npapiHost = FB::ptr_cast<FB::Npapi::NpapiBrowserHost>(m_host);
I think it has SetValueForURL on it, but if it's missing you can always add it and submit a pull request; I'll accept it as long as it's reasonable.
It appears that Unity IoC defaults to creating a new instance of an object when it resolves a type. But my question is there someway to be explicit and tell my container that whenever I have it resolve an object type to give me a new instance of said type?
IE i want to be explicit and force the container to make sure theInstance is a new instance each time it resolves type:MyNewObject (or all types for that matter)
MyNewObject theInstance = container.Resolve<MyNewObject>();
Yes it is easily configurable by a TransientLifetimeManager
When you register a class should have something like
container.Register<IMyNewObject, MyMewObject>(new TransientLifetimeManager());
//or
container.Register<MyMewObject>(new TransientLifetimeManager())
If you're applying IoC principles properly, your class declares its dependencies and then the container handles the lifecycles of them. For example, you want to grab an HttpRequest object and the container handles providing the current thread-local one, or whatever.
Your code shouldn't really have to care about the life-cycle of its dependencies, as it should never be responsible for clearing up after them or what-have-you (all of that should be encapsulated in the dependency itself, and invoked by the container when it is shut down).
However, if you do need to care in your code about whether you get a singleton instance or a per-injected instance of the same type, I like to be explicit about it by using the type system itself, just as the Guice container for Java does with its Provider pattern. I've created a Guice-style IProvider<T> interface that I use to do this, and I just wire it up with a simple static factory method for them like so:
Provider.Of<Foo>(() => { /* Code to return a Foo goes here */})
I know the basic definition of the following smart types and how to use them. However I am not very sure on the places/circumstances
where :
std::auto_ptr should be preferred over std::shared_ptr.
std::shared_ptr should be preferred over std::auto_ptr.
std::auto_ptr : used to ensures that the object to which it points gets destroyed automatically when control leaves a block.
std::shared_ptr : wraps a reference-counted smart pointer around a dynamically allocated object.
auto_ptr should never be used because it is deprecated as of C++111.
Use
std::shared_ptr if ownership is to be shared
std::unique_ptr if there should only be a unique view of the object, i.e. only one owner
auto_ptr can also not be used in standard containers as it is not copyable.
1: D.10 auto_ptr: "The class template auto_ptr is deprecated. [ Note: The class template unique_ptr (20.7.1) provides a better solution. —end note"
In the case there is only one owner, use lightweight std::unique_ptr. For more complicated scenarios use std::shared_ptr.
There is no reason to use std::auto_ptr: new smart pointers shared_ptr, unique_ptr and weak_ptr contain all required functionality. unique_ptr class supersedes auto_ptr
You use an auto_ptr (or unique_ptr in C++11) when one distinguished pointer instance has full ownership of the pointee. That is, if you can always look at the code and point with your finger at one instance of std::auto_ptr that owns the object the pointer points at, you have a good use case fo auto_ptr.
If things are not so clear, you use a shared_ptr. If in doubt and in a single-threaded environment, use a shared_ptr.