Java vs C++ (JAVAC)

Input validation

The string literal "Error!" is duplicated in multiple places. If you decide one day to change that text, you'd have to remember to change everywhere, which can be error prone. It's better to turn string literals into global constants.

But actually returning "Error!" is not a good way to handle invalid input. How will the caller know if the name was invalid? The caller would have to know to compare returned values against the correct string literal used internally by the method. It would be better to return an empty string instead, which is easier for the caller to validate (instead of a full string comparison), and document this fact in a comment above the function declaration. Or you could take a non-const in/out parameter and return a boolean for success/failure. (Thanks @200_success!)

Add some test cases

It's good to add test cases with expected output, so that if you want to refactor using different approaches there's an easy way to verify that everything still works. For example:

std::cout << convert("javaIdentifier").compare("java_identifier") << "\n";
std::cout << convert("longAndMnemonicIdentifier").compare("long_and_mnemonic_identifier") << "\n";
std::cout << convert("name").compare("name") << "\n";
std::cout << convert("nEERC").compare("n_e_e_r_c") << "\n";
std::cout << convert("c_identifier").compare("cIdentifier") << "\n";
std::cout << convert("long_and_mnemonic_identifier").compare("longAndMnemonicIdentifier") << "\n";
std::cout << convert("n_e_e_r_c").compare("nEERC") << "\n";
std::cout << convert("!_e_e_r_c").compare("Error!") << "\n";
std::cout << convert("n_e_e_R_c").compare("Error!") << "\n";
std::cout << convert("n_e_e_r_c_").compare("Error!") << "\n";

These should all output 0. If you make any changes, it's easy to verify by rerunning and looking for non-zero values in the output.

Simplify

The condition (java != cpp) || (!java && !cpp) can be simplified to !(java && cpp).

Other things

I think it would make sense to reverse the logic of the cpp and java variables. The current code sets cpp to true when converting from java to cpp. It would seem more intuitive to set cpp to true when cpp naming is detected. But maybe this is a matter of taste.

Lastly, a minor thing, I think it's more conventional to put a space after #include, like this:

#include <iostream>
#include <string>
#include <cctype>

Firstly I don't agree with a particular coding convention being tied to a language, implied by your excerpt. I know this isn't the point of your question but as an aside, coding conventions develop from an amalgamation of best practice, and what your development team is happy with adopting (I've been through this painful process).

Naming of Boolean Variables

A fairly neat convention I've adopted recently is naming of boolean variables by the name suggesting something is true (i.e. an assertion). What I mean by this is that where you have java and cpp, you could have isJava and isCpp. Then, when you need to use the variable in an if statement you have:

if (isJava) {
    ...
}

That's almost human readable! There are some variants on this like languageIsJava but they can begin to be a bit wordy, but the point is that you're implying that the variable is a boolean from its name.

Use of java and cpp Variables

In this context it doesn't make sense to have a boolean variable for each supported language. The reason being is that it is possible that both variables could be true, which you correctly identify as an error. I get the feeling you're procrastinating by leaving the error checking towards the end. My first recommendation is that you create an enum which stores the detected language, and can have one of three possible values:

enum ProgrammingLanguages{
    Undefined
    Cpp,
    Java
};

Then you can write your program such that it's only trying to guess the input language whilst your enum variable is set to Undefined. Of course you will still have to handle the case where your program has determined the input language but then encountered a character it wasn't expected (e.g. thought the input was a Java name only to encounter an underscore). This is an error and your code should throw an exception or do something to notify the calling code that they buggered up. It's not your responsibility to recover from it since that scenario is undefined based on your problem definition. Just to elaborate a bit more on why you shouldn't return "Error!" is that if something goes wrong your function always returns a string. This is ambiguous since your successful value goes in the same variable as an error. Don't make life hard for yourself, throw an exception so you force the calling code to implement error handling the proper way.

Consider Using Regular Expressions

Regular Expressions (RegEx for short) are a dark art and are very powerful for string pattern matching and manipulation. In this particular case I can't give you any real answers but a PHP framework I have used in the past has an Inflector class whose job is convert between naming conventions. You can find its implementation here.

Control Statement Nesting

This is a massive bugbear of mine and I see it all too often. Your code isn't especially bad but I think it's something you should be aware of. Control statement nesting is where you have an if-statement inside an if-statement inside a while-loop inside a switch statement, and so on. Doing this increases code complexity. Your for-loop is on the edge of what I consider being too complex, but I think given your implementation, there's not a lot you can do. You want to keep your code as flat as possible because it makes it easy for someone else reading your code (and yourself for that matter), to follow the logic.

There is going to cause confusion and potential errors:

bool java = false;
bool cpp = false;

What happens when a bug sets them both to true?
Use a enum:

enum LanguageType {Unknown, CPP, Java }; 
LanguageType  languageDetected = Unknown;    // looks like my convention is Java

Use self documenting code to explain what is happening:

languageDetected = detectLanguage(identifier);
switch(languageDetected)
{
    case CPP:  return convertIdentifierToCpp(identifier);
    case Java: return convertIdentifierToJava(identifier);
    default:
        // however you want to show errors
        // but do something.
}

Using return "Error!"; to indicate an error is a bit problematic (As it could be an identifier by the rules you specified above). So how does the code using this functions detect an error.

Assuming you are converting a valid program then errors should be very rare and you could use exception to indicate failure (as you probably want to terminate the program anyway).

Alternatively you could alter your function signature so that it returns true/false to indicate failure and then modify the identifier in place.

But since this is the interface required by the coding site fine (just leave it).

This is going to fail if the file contains an identifier with a space in it:

    std::string str;
    std::cin >> str;

Use getline.

    std::string str;
    std::getline(std::cin, str);

Bad Loop construct

Your while loop is not correct. Note the last succesfule read will read upto but not past the eof. So the stream will be good even though there is no dat on the stream. The first attempt to read it will cause it to become bad:

do {
    std::string str;

    // This read may fail
    // If the last read read the last line and there is no input
    // this read will fail
    std::cin >> str;

    // IF the read fails then this call is going to generate bogus ouput.
    std::cout << convert(str) << '\n';
} while (std::cin);

SO always test that a read worked.
This would be a better version that checks if the read worked.

do {
    std::string str;
    if (std::cin >> str) {
        std::cout << convert(str) << '\n';
    }
} while (std::cin);

More idiomatic is to test it as part of the loop:

std::string str;
while (std::cin >> str) 
{
    std::cout << convert(str) << '\n';
}