Is “Let more people able to review” a valid reason to “write c++ as if Java” at some degree?

Question

According to Should we avoid language features that C++ has but Java doesn't?, I know it is horrible to write C++ as if Java, mostly because it drops the beneficial features of C++ languages.

But responding to the point 2 in this question:

C++ code with C++ specific features (e.g.: friend functions, multiple inheritance) can only be maintained or reviewed by C++ programmers, but if we just write C++ like Java (without C++ language specific feature), the code can be maintained or reviewed by both C++ and Java programmers.

I found it seems the following questions supports the statement above:

Is it effective to review code in language I don't know?

Should Junior Programmers be involved as code reviewers in the projects of Senior Programmers?

I think they seems support this point:

1.It allows more people (Java programmers) to review my C++ code

2.It allows Java programmers to learn C++ easier during reviewing my c++ code

I mean I'm not in extreme cases that dropping all C++ features, but I would prefer not using C++ features if the substitutes is not complex, for example, I would not write all C++ classes in .h like a single .java file:

class A{
private:
  int b;
  void methodC(){
    //some other code
  }
}

because separating .h and .cpp is easy for C++ newbies. But I would avoid C++ features if the C++ feature can easily be replaced by a pseudo code both for C++ and Java, for example: multiple inheritance, which can be replace by composition + multiple interface.

So My question is, is "letting more people(e.g.:Java programmers) to review my code" a reason to "write C++ like Java" at some degree?

Answer 1

The whole statement "write C++ as Java" is total nonsense. You cannot write C++ as Java. If you tried, your program would leak, or crash, or both. C++ does not have garbage collection. C++ does not have proper exceptions. C++ has very different approach on parametric polymorphism.

And after all, it implies that all developers know Java.

Also, you seem to be focusing too much at review. Will the other developer be able to find and fix the bug in code? Basically, the reviews are just there to ensure that the reviewer, and supposedly, others in team, will further be able to operate the code without its author.

If you rephrase your question as "may some C++ features be avoided so that developers (at hands) can understand and edit it easier", then answer is definite "yes, of course". Most project have in their code style guides notes "we don't use ...". Actually, there are many experienced C++ developers which think that some feature does not work correctly, and should be avoided.

Answer 2

The idea that Java programmers can review (i.e. find mistakes in) or maintain (i.e. modify) C++ code if it only uses the features that kinda look like Java is badly misguided.

The underlying execution model of C++ is different enough from Java that any such attempt will lead to bugs, pain, and in some cases expensive lawsuits from customers.

The main difficulty in switching from Java to C++ is not learning a few additional features of the language, it's understanding the execution model and idioms. Why is new in Java ubiquitous, but frowned upon in modern C++? How do you prevent memory leaks? How do you prevent use-after-free or invalidated iterators? What happens if you use an invalid index in an array, and how do you guard against that? These are the questions a C++ programmer must be able to answer, and a Java programmer just can't.

Answer 3

It isn't feasible at all to write C++ as if it was Java: memory leaks or ownership semantics, no explicit use of pointers/references etc. Besides, whoever is reviewing your code, should be able to understand what the code is doing.

Does that mean a learning C++ developer cannot review your code? Well, they sure can, because code reviews are a great learning tool. If you use a feature of C++ that the reviewer does not know about, they can ask. These additional questions can also help you catch mistakes.

Features such as multiple inheritance should be used sparingly, but not with the goal of making it more understandable for those that are not aware of the features/syntax of the language.

Answer 4

A very effective way to write c++ so that it is both readable and powerful is to hide expert complexity behind semantically simple interfaces.

A great example of this is std::shared_ptr<T>. Getting the implementation of a std::shared_ptr right without sacrificing performance or correctness in multi-threaded programs is not trivial.

But if your reviewer sees this code:

auto px = std::make_shared<X>();

It's pretty obvious to him that px is a pointer with shared ownership, regardless of the complexities of lock-free reference counting or type-erasure of the deleter (to name but 2).

Further, if ownership of X is always shared, then it makes sense to create a higher-level wrapper which can be treated as a value:

struct SharedX
{
    int some_x_method() { return px_->some_x_method(); }
private:
    std::shared_ptr<X> px_ = std::make_shared<X>();
}; 

Now we can write code like this:

auto x = SharedX();
do_something_with(x);

and we can't accidentally create an invalid SharedX.

If we want to be able to provide null handles, we can do that safely by demanding that the programmer specifically requests one:

struct SharedX
{
    SharedX()
    : px_(std::make_shared<X>())
    {}

    static SharedX invalidHandle() { return SharedX(nullptr); }

    int some_x_method() { 
        assert(px_);
        return px_->some_x_method(); 
    }

private:
    explicit SharedX(std::nullptr_t)
    : px_(nullptr)
    {}

private:
    std::shared_ptr<X> px_;
}; 

// create a new shared x
auto sx = SharedX();

// create an uninitialised shared x to act as a placeholder for
// some later value (eg if deserialised)
auto nsx = SharedX::invalidHandle();

Novices, Java programmers, experts and value-semantic-purists such as myself will now all be happy.