I have been doing some work with STXXL, and I've kind of encountered a problem with the maps inheriting from boost::noncopyable... For this project, I create several maps with the statement:
stxxl::map<int, mapData, CmpIntGreater, 4096, 4096> node_map((stxxl::unsigned_type)(4096 * 4), (stxxl::unsigned_type)(4096 * 3));
Needless to say the hard coded values in the constructor will be replaced once I solve this problem, but in any case, I get the error:
C2248: 'boost::noncopyable_::noncopyable::noncopyable' : cannot access private member declared in class 'boost::noncopyable_::noncopyable'
Has anyone else encountered this problem with STXXL maps? Or does anyone have some general advice or best practices when working with noncopyable objects?
Thanks for all your help guys :)
Just to add an official answer here to accept, my problem was that I had some functions returning maps by value and some function arguments being passed by value. Once this was fixed, it worked like a charm! So, moral of the story, when using a version of STXXL that inherits from noncopyable, make sure that all instances of your STXXL object are used with your functions by reference only, not by value.
Related
I have an abstract class A with about 20 pure virtual functions, and subclasses B and C which implement all of them. They work great.
I just wrote another non-abstract class D that's also a subclass of A. I thought I provided an implementation for all of the pure functions inside D, but when I try instantiating the class g++ 4.9.2 gives either the error "cannot declare variable d to be of abstract type D" or "invalid abstract return type D" (depending on the context).
I'm guessing that either:
I forgot one of the methods
The type signature on one of the methods is wrong.
I've gone through and starred at the code and I don't see either of these being the case. However, I suspect that I just missed something. Now, I could post all of the code here and ask others to stare at it and find the problem. That's what happened here: C++ why is my class still abstract? Namely, the code was almost correct except for a teeny missing ampersand that caused the type signatures to differ and thus an error. But I don't really want to post my code because it's long, templated, not self-contained, and mostly irrelevant to the actual problem.
Instead, I would like a general solution/tool for solving this problem. It should be very easy for the compiler to automatically tell me which method is causing the problem (i.e. which method of the abstract base class isn't overridden in D). Is there a flag for g++ that could help me out? Another tool? Another idea? I'd rather not upgrade from g++ 4.9 (because that will take quite a bit of work for the project) but I would be willing to if it gives me better error messages for situations like this.
The real solution seems to be upgrading to recent g++ for a real error message.
A best practice and helpful technique is to add override annotations to help identify any methods whose type signatures are incorrect.
I have library that im using to load images. The library makes class objects out of the files and has their own drawing functions. Im trying to build a class that can handle these objects and implement some simple logic once im done loading my files. What would be a good way to pass them as reference or pointer to my handling class?
This is what i got so far:
1) Passing them as reference one by one. When i add a file i will always have to write the new file to my class definition.
2) Loading all the objects into array and pass that as reference. I still have to set the class defition so that i know how many items are in the array. But what if i have different amount files to load at various steps of my program? Writing many constructor/function overloads doesnt seem like a right way to do it.
I searched for the weekend and didnt really find any solutions to this so any points and tips would be welcome. Oh and im pretty new to C++ so consider my knowledge limited. I can grasp the idea what the pointers and references are but implementing things with them are slow.
So to repeat my question. What would be a good way to pass variable amount of objects as reference or pointer to my handling class?
you can make your function look like this:
void my_function(std::vector<SomeObject *> &objs) {
// ...
}
and you can then iterate over the objs vector using an Iterator, or just check
objs.size()
see http://en.cppreference.com/w/cpp/container/vector
You did not include source code details about your issue but your solution # 2 should be fine and you can just pass an int variable to hold the number of elements in the array.
I am trying to understand the programming of Siemens scanner using C++ and given that my C++ skills are limited, I am having problems in understanding many parts of the code provided by the vendor.
Problem 1
For instance, the code uses reference (rMrProt) to object MrProt and notations (such as the use of use of (). and ()[].) are very confusing to me.
For instance:
ImageSamples = rMrProt.kSpace().baseResolution()
ImageSize = rMrProt.sliceSeries()[0].readoutFOV()
Some explanation of these statements would be appreciated.
All information regarding object MrProt are in “MrProt.h”, “MrProt.dll”, “MrProt.lib”. All these files have been shared at:
https://docs.google.com/open?id=0B0Ah9soYnrlIYWZkNDU2M2EtYTNmNC00YTc5LTllMzItYzIyMWU4M2ZhY2Fi
Problem 2
Also, I have been trying to read MrProt.dll and MrProt.lib without any success. Only now, I came to know of dumpbin. Any help would be appreciated.
Problem 3
Another confusion that I have is related to some part of MrProt.h itself. There is a statement in MrProt.h:
class __IMP_EXP MrProt: public MrProtocolData::MrProtDataDelegate
{
typedef MrProtocolData::MrProtDataDelegate BasicImplementation;
public:
MrProt();
MrProt(const MrProt& rSource);
…
….
}
Here, __IMP_EXP, I guess that it’s some compiler specific stuff.. some decoration etc. But, I still have no idea what to make of this.
Problem 1.
rMrProt.sliceSeries()[0].readoutFOV()
means
Take rMrProt's sliceSeries member and call that. Apparently, it returns an array-like object, something that can be indexed.
From the result, take the first element ([0]). That's some kind of object.
On that element/object, call readoutFOV.
Problem 2. You're not really supposed to read binary files. There should be documentation with them.
1)
ImageSamples = rMrProt.kSpace().baseResolution()
This is just method chaining. You call the method kSpace() on rMrPrto which returns an object, and you call baseResolution() on that object.
2) Those are binary files. What would you expect to see? To read them you'd have to be an expert in asm or at least know some low-level concepts.
3) __IMP_EXP is a common type of directive that tells the compiler that the class is either exported or imported.
It expands to _declspec(dllimport) or _declspec(dllexport), depending on whether the definition of the class is in the current module or another module.
identifier() is a method/function call
identifier[i] returns the i'th element in an array.
identifier()[i] returns the i'th element of the array returned by identifier()
I can only help on problem 1:
if the return value of rMrProt.kSpace() is a struct. instead of saving it to a struct and then access it's member you can directly access a member of his with rMrProt.kSpace().MemberName
same for rMrProt.sliceSeries() which I guess is returning an array. so rMrProt.sliceSeries()[0] will access the first value in the returning array.
I had a question about boost python. I've been working on exporting some functionality of a project into boost python, and I haven't found a way to solve the following problem:
I have a set of StatusEffect objects that i store and use throughout the game. At the game startup, I want to be able to call a python script that will populate/add to the set of status effect objects. I'm having no problems exposing the StatusEffect class and it's derived class to python and calling the script.
The problem is that I'm storing that StatusEffect objects in an std::vector<boost::shared_ptr<StatusEffect> > Effects;
I have no idea how to create new instances of boost::shared_ptr<StatusEffect> aside from the method of adding a static create method as described here http://wiki.python.org/moin/boost.python/PointersAndSmartPointers Given the large number of constructors and the wide variety of derived classes I have, this seems an unoptimal solution at best. I'd like to be able to create instances of boost::shared_ptr directly using the constructors of the StatusEffect objects, and be able to add those to the vector. Is this possible?
An answer or some helpful suggestions would be helpful. I asked a simialr question yesterday but unfortunately it wasn't of much help.
Thanks in advance
I hope I am understanding your question. If you declare your python class with the shared_ptr as shown at http://wiki.python.org/moin/boost.python/PointersAndSmartPointers, then boost::python will automatically convert StatusEffect objects you create in python to shared_ptr<StatusEffect> if necessary (you can try this e.g. by .def-ing a function which takes const shared_ptr<StatusEffect>& or shared_ptr<StatusEffect> as argument, and call it with StatusEffect instance created in python.
If you want to assign an attribute of type vector<shared_ptr<StatusEffect> >, you must create converters for it (from python sequences, and back), that's described in documentation. For an example, see c++ to python converter template (line 120), python to c++ template (line 127), and then using it for various types (including shared_ptr's) contained in the sequences (line 212).
Then you can write something like yourObject.listOfStatusEffects=[StatusEffect(),StatusEffect(),StatusEffect()]
I'm writing in second-person just because its easy, for you.
You are working with a game engine and really wish a particular engine class had a new method that does 'bla'. But you'd rather not spread your 'game' code into the 'engine' code.
So you could derive a new class from it with your one new method and put that code in your 'game' source directory, but maybe there's another option?
So this is probably completely illegal in the C++ language, but you thought at first, "perhaps I can add a new method to an existing class via my own header that includes the 'parent' header and some special syntax. This is possible when working with a namespace, for example..."
Assuming you can't declare methods of a class across multiple headers (and you are pretty darn sure you can't), what are the other options that support a clean divide between 'middleware/engine/library' and 'application', you wonder?
My only question to you is, "does your added functionality need to be a member function, or can it be a free function?" If what you want to do can be solved using the class's existing interface, then the only difference is the syntax, and you should use a free function (if you think that's "ugly", then... suck it up and move on, C++ wasn't designed for monkeypatching).
If you're trying to get at the internal guts of the class, it may be a sign that the original class is lacking in flexibility (it doesn't expose enough information for you to do what you want from the public interface). If that's the case, maybe the original class can be "completed", and you're back to putting a free function on top of it.
If absolutely none of that will work, and you just must have a member function (e.g. original class provided protected members you want to get at, and you don't have the freedom to modify the original interface)... only then resort to inheritance and member-function implementation.
For an in-depth discussion (and deconstruction of std::string'), check out this Guru of the Week "Monolith" class article.
Sounds like a 'acts upon' relationship, which would not fit in an inheritance (use sparingly!).
One option would be a composition utility class that acts upon a certain instance of the 'Engine' by being instantiated with a pointer to it.
Inheritance (as you pointed out), or
Use a function instead of a method, or
Alter the engine code itself, but isolate and manage the changes using a patch-manager like quilt or Mercurial/MQ
I don't see what's wrong with inheritance in this context though.
If the new method will be implemented using the existing public interface, then arguably it's more object oriented for it to be a separate function rather than a method. At least, Scott Meyers argues that it is.
Why? Because it gives better encapsulation. IIRC the argument goes that the class interface should define things that the object does. Helper-style functions are things that can be done with/to the object, not things that the object must do itself. So they don't belong in the class. If they are in the class, they can unnecessarily access private members and hence widen the hiding of that member and hence the number of lines of code that need to be touched if the private member changes in any way.
Of course if you want to access protected members then you must inherit. If your desired method requires per-instance state, but not access to protected members, then you can either inherit or composite according to taste - the former is usually more concise, but has certain disadvantages if the relationship isn't really "is a".
Sounds like you want Ruby mixins. Not sure there's anything close in C++. I think you have to do the inheritance.
Edit: You might be able to put a friend method in and use it like a mixin, but I think you'd start to break your encapsulation in a bad way.
You could do something COM-like, where the base class supports a QueryInterface() method which lets you ask for an interface that has that method on it. This is fairly trivial to implement in C++, you don't need COM per se.
You could also "pretend" to be a more dynamic language and have an array of callbacks as "methods" and gin up a way to call them using templates or macros and pushing 'this' onto the stack before the rest of the parameters. But it would be insane :)
Or Categories in Objective C.
There are conceptual approaches to extending class architectures (not single classes) in C++, but it's not a casual act, and requires planning ahead of time. Sorry.
Sounds like a classic inheritance problem to me. Except I would drop the code in an "Engine Enhancements" directory & include that concept in your architecture.