vendredi 29 juillet 2016

What is the opposite of c++ `override` / `final` modifier?

  • In c++11 the override modifier protects from not overriding an intended virtual base function (because the signatures do not match).
  • The final modifier protects from unintentionally overriding a function in a derived class.

=> Is there a modifier (something like maybe first or no_override) that protects from overriding an unknown base function?

I'd like to get a compiler error when a virtual function was added to a base class with the same signature as an already existing virtual function in a derived class.

std::set find behavior with char * type

I have below code line-

const char *values[] = { "I", "We", "You", "We"};
std::set<const char*> setValues;

for( int i = 0; i < 3; i++ ) {

    const char *val = values[i];
    std::set<const char*>::iterator it = setValues.find( val );

    if( it == setValues.end() ) {
        setValues.insert( val );
    }
    else {
        cout << "Existing value" << endl;
    }
}

With this I am trying to inser non-repeated values in a set, but somehow code is not hitting to print for existing element and duplicate value is getting inserted.

what is wrong here?

Object Creation with a function c++

I have to find a possible mistake in the following code. Which could be it ?

cObject * CreateObject()
{
    cObject t;
    return &t;
}

Proper use of std::unique_ptr release() for raw pointer function argument

I'm adding a child element to a parent element. The parent's addChildElement() takes a raw pointer (and belongs to a library that I can't change), then assumes ownership and deletes.

std::unique_ptr<Element> child {new Element};

// ...do things...

parent.addChildElement (child.release()); // will be deleted by parent

Is this correct modern practice? To use a unique_ptr until the last possible moment, rather than a raw pointer?

Can't install tessocr (Tesseract) on CentOS

I've been trying to install tessocr (http://ift.tt/2agWTTy) node module on my server but I've been having no luck at all.

I'm getting this error when I try to compile it on my own with ncmake --build:

[ 50%] Building CXX object CMakeFiles/http://ift.tt/2avwi26
In file included from /home/hivee/server/node_modules/tessocr/src/tessocr.cc:5:
/home/hivee/server/node_modules/tessocr/node_modules/nan/nan.h:43:3:
error: #error This version of node/NAN/v8 requires a C++11 compiler

I updated my C++11 compiler, so it's that one but this is showing me that error, plus some other ones

And I'm getting the same error whenever I try to install with NPM (npm install tessocr --save) but with this extra error:

Failed at the tessocr@0.1.2 install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the tessocr package,
npm ERR! not with npm itself.

I just want to install tessocr node module on my CentOS server, I've had no luck at all.

rvalues with copy operator

Consider this simple class

class Foo
{
    public:
    Foo() = default;
    Foo(const Foo &) = default;
    Foo & operator=(const Foo & rhs)
    {
        return *this;
    }
    Foo & operator=(Foo && rhs) = delete; 
};

Foo getFoo()
{
    Foo f;
    return f;
}

int main()
{
    Foo f;
    Foo & rf = f;
    rf = getFoo();    // Use of deleted move assignment.
    return 0;   
}

When I compile the example above I get error: use of deleted function 'Foo& Foo::operator=(Foo&&)'

From the Copy Assignment:

If only the copy assignment is provided, all argument categories select it (as long as it takes its argument by value or as reference to const, since rvalues can bind to const references), which makes copy assignment the fallback for move assignment, when move is unavailable.

Why doesn't the compiler fallback to copy assignment when const lvalue reference can bind to rvalue and const Foo & f = getFoo(); works.

Compiler - gcc 4.7.2.

Abstract types Meet std Containers

I've been trying to solve a design problem involving both an abstract type and its derived classes, as well as std containers. I have a working solution, but I would like to see if it can be improved. I apologize for the "..."s. But it is to make the design issue more clear.

// the base class
class B { 
private:
    ...
public:
    // the virtual function which makes B an abstract type
    virtual void func(...) = 0; 
    ...
};

// the 1st derived class
class D1 : public B { 
    ...
    void func(...) {...}
};

// the 2nd derived class
class D2 : public B {
    ...
    void func(...) {...}
};

Based on the problem, both D1 and D2 have to point to or contain some instances of B w/o knowing their concrete types. Currently, I'm using the point to approach, which means D1 and D2 contain some pointers to B.

In addition, those pointed-to instances of B are in fact shared among higher-level instances of B in recursive compositions. To make it clear, I'll expand the definition of D1.

class D1 : public B { 
private:
    B *d1_b1;
    B *d1_b2;
    ...
public:
    D1 (B *b1, B *b2) {...}
    B* func(...) {...}
    ...
};

Now, although d1_b1 and d1_b2 are shared by some higher-level instances of either D1 or D2, I think none of higher-level objects should maintain the ownership or lifetime of lower-level objects. Instead, I use an std container with unique_ptrs, for example:

std::vector<std::unique_ptr<B>> unique_b_objs;

The unique_b_objs is declared at the scope where the recursive construction is first called, and is passed in by reference and used recursively.

Now, every time an new object of either D1 or D2 is created, a corresponding unique_ptr is pushed back into unique_b_objs. Essentially, the raw pointers to objects of B are used in recursive composition, but the lifetime and ownership of the objects of B are managed by the std container.

I hope I've made it clear so far. It's working as expected. But I'm trying to get rid of the raw pointers. I can think of two approaches, but none of them work right now.

  • Use the "contain" approach. Essentially, all the B * becomes B in D1 and D2. But B is an abstract type, which means compilers won't even compile something like D1 (B b1, B b2) {...}
  • Use reference in the container. It can be done via the reference_wrapper. However, since the objects are created locally in recursions, the references become invalid out of the scope. This means we cannot transport references between recursive calls.

One working approach is to use shared_ptr. But it is unnecessary to share the ownership at every recursion step. And it also leads to performance overhead.

At this point, thank you for reading through the question. I hope I've made it clear. If you can think of some better approach than a container of unique_ptrs + raw pointers, please let me know.