Return to Answer

Regarding the _data param, names starting with _ may be reserved for compiler/library use. See this SO thread. It is best to avoid those.

using namespace std (or any namespace for that matter) is usually not a good practice because it defeats the purpose of a namespace, which is to allow identical names to coexist without clashes. You can read more about this here.

Regarding the _data param, names starting with _ may be reserved for compiler/library use. See this SO thread. It is best to avoid those.

using namespace std (or any namespace for that matter) is usually not a good practice because it defeats the purpose of a namespace, which is to allow identical names to coexist without clashes. You can read more about this here.

I've never used Crypto++, but can give you several suggestion on how to improve the overall style and quality of your code.

Missing an include guard:

Your header file doesn't have an include guard. You will need one to be able to include the header in other .cpp files. Note: #pragma once is also viable.

Type and variable naming:

It is unusual to start the name of a type in C++ with a lower-case letter (rServer). This form of camelCase is usually applied to variables and object instances. User defined C++ types are commonly named using CameCase (first letter upper-case).

Regarding the _data param, names starting with _ may be reserved for compiler/library use. See this thread. It is best to avoid those.

Declaring variables at the top of a function:

using namespace std:

Using namespace std is not a good practice because it defeats the purpose of a namespace, which is to allow identical names to coexist without clashes.

Using cout directly:

Your code is cluttered with log calls to std::cout. You shouldn't be using it directly inside functions like you did. Most users won't want the verbose output on every execution of the program. If you need them for debugging, a better approach is to wrap those calls in a macro that can be disabled at compile time, e.g.:

Magic constants:

Using old C-string functions:

I suspect you did this because DATA is using a char array internally. If that is the case, can't you also use an std::string in it? It would also be more efficient since you could then avoid a string copy all together by just doing data.body = std::move(ciphertext);

Avoid C-style casts:

C-style casts are ugly and unsafe.

Clear commented out code:

Be consistent with your comments and var names:

If you are writing code that will be read by programmers around the world, then all comments and variables/type-names must be in English.

I have never used Crypto++, but can give you several suggestion on how to improve the overall style and quality of your code.

Missing an include guard:

Your header file doesn't have an include guard. You will need one to be able to include the header in other .cpp files. Note that #pragma once is also viable.

Type and variable naming:

It is unusual to start the name of a type in C++ with a lower-case letter (rServer). This form of camelCaseing is usually applied to variables and object instances. User defined C++ types are commonly named using PascalCase (first letter uppercase).

Regarding the _data param, names starting with _ may be reserved for compiler/library use. See this SO thread. It is best to avoid those.

Declaring variables at the top of a function:

using namespace:

using namespace std (or any namespace for that matter) is usually not a good practice because it defeats the purpose of a namespace, which is to allow identical names to coexist without clashes. You can read more about this here .

Using cout directly:

Your code is cluttered with log calls to std::cout. You shouldn't be using it directly inside functions like you did. Most users won't want the verbose output on every execution of the program. If you need them for debugging, a better approach is to wrap those calls in a macro that can be disabled at compile time, e.g.:

Magic constants:

Using old C-string functions:

I suspect you did this because DATA is using a char array internally. If that is the case, can't you also use an std::string for it? It would also be more efficient since you could then avoid a string copy altogether by just using C++11's std::move: data.body = std::move(ciphertext);

Avoid C-style casts:

C-style casts are ugly, unsafe and provide no compiler diagnostics.

Clear commented out code:

Be consistent with your comments and var names:

If you are writing code that will be read by programmers around the world, then all comments and variables/type-names should be in English.

Mixing std::string and strcpy & friends is a blasphemy. std::string has all the methods you need. E.g.: operator +, +=, append(), etc.

Mixing std::string with strcpy & friends is totally unnecessary. std::string has all the methods you need. E.g.: operator +, +=, append(), etc.