Identifying uninitialized pointer - c++

Considering:
my class.h
class MyClass
{
Var* var;
public:
MyClass();
};
my class.cpp
MyClass::MyClass()
{
if(var) {};
}
Is there any compiler, or compiler flag, that will tell me I forgot to initialize var, Var* var = nullptr;?
I tried Microsoft (Visual Studio 2019) and MinGW compilers on Qt Creator (Qt 5.15.2), passing -Wall flag to the compiler and seen nothing telling me about that.
So the above was on Windows. And the following I tried on macOS:
class MyClass
{
int* var;
public:
MyClass();
};
MyClass::MyClass()
{
if(var) {}
}
int main()
{
MyClass a;
return 0;
}
While compiling with
g++ -Wuninitialized main.cpp -o main
and
clang++ -Wuninitialized main.cpp -o main
I see no warning, even with -Wall. Why?
g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
clang++ --version
Apple clang version 13.0.0 (clang-1300.0.29.30)
Target: x86_64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

With Visual Studio and the Microsoft C++ compiler, I suggest compiling your code at warning level 4 (/W4).
If you are using the IDE, in Solution Explorer right click on your project and select Properties.
Then select C/C++ | General, and choose Warning Level 4, as shown below:
However, testing your case with VS2019, I got this warning message even at warning level 3:
Warning C26495 Variable 'MyClass::var' is uninitialized. Always
initialize a member variable (type.6).

Related

asyncF.cpp:24:31: error: no member named 'async' in namespace 'std'; [duplicate]

I know that std::async is a C++11 thing but I am pretty sure that my compiler has C++11 support.
#include <future>
using namespace::std;
void functionToRun() {
// some code
}
int main() {
auto x = 2; // throws warning warning: 'auto' type specifier is a C++11 extension [-Wc++11-extensions]
std::future<void> metricLoggerFuture = std::async(std::launch::async, functionToRun); // throws error no member named 'async' in namespace 'std'
}
and if I use
std::future<void> metricLoggerFuture = async(std::launch::async, functionToRun); // error: use of undeclared identifier 'async'
Also g++ --version shows
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I have gone through the following,
No member named 'size' in namespace 'std'
No Member named stoi in namespace std
Also,
OS: macOS Catalina
This code is part of a bigger project (wrapper over TigerVNC) so there is a makefile, but since auto complies without any issues I don't think C++11 is the issue and hence passing -std=c++11 in the CXXFLAGS and CPPFLAGS also doen't help.
Looks like you are not compiling with c++11, add -std=c++11 (or later) to your compiler command line or makefile.

unable to compile c++ code in macbook due to __GLIBC__ issue

g++ -std=c++11 -Wall -g threads.cpp -o threads.out
In file included from threads.cpp:1:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/iostream:37:
In file included from /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/ios:215:
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__locale:401:32: error: use of undeclared identifier '_ISspace'
static const mask space = _ISspace;
^
Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__locale:402:32: error: use of undeclared identifier '_ISprint'
static const mask print = _ISprint;
^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__locale:403:32: error: use of undeclared identifier '_IScntrl'
static const mask cntrl = _IScntrl;
^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__locale:404:32: error: use of undeclared identifier '_ISupper'
static const mask upper = _ISupper;
^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__locale:405:32: error: use of undeclared identifier '_ISlower'
static const mask lower = _ISlower;
^
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/__locale:406:32: error: use of undeclared identifier '_ISalpha'
static const mask alpha = _ISalpha;
can you please help me to resolve this __locale issue while compiling the c++ code.
#include <iostream>
#include <thread>
using namespace std;
void fun(void)
{
cout << "Vaule " << 10 << endl;
}
int main()
{
thread t1(fun);
thread t2(fun);
return 0;
}
compiling command:
g++ -std=c++11 -Wall -g thread.cpp -o thread.out
Two things fix the problem you're having.
Thing the first, add the compiler option -pthread. My compile command: clang++ -Wall -Wextra -std=c++11 -pthread main.cpp
Thing the second, join your threads before ending the program.
t1.join();
t2.join();
Something it does not fix, is that your std::cout statement will likely be jumbled because the threads simply dump their data into the single stream as they please. For an example, my output was the following:
Vaule Vaule 10
10
In order to fix that, you'll likely need to place a lock(mutex) around the std::cout statement.
As I said in my comment, I do not recommend using g++ unless you installed it yourself. The command you're using is an alias that doesn't behave, because of some text you left out.
❯ g++ --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Contrast with clang++
❯ clang++ --version
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Of note in the g++ section is the 'Configured with' line. It uses a Standard Library from gcc 4.2.1, which is pre-C++11. You should not have left that information out.

C++20 modules on clang (Windows): typeinfo error in simplest example

File first_module.cppm
export module first_module;
int foo(int x) {
return x;
}
export int e = 42;
export int bar() {
return foo(e);
}
Pre-compiling (no problems):
$ clang++ --std=c++20 -fmodules --precompile first_module.cppm -o first_module.pcm
Compiler information:
$ clang++ -v
clang version 10.0.0
Target: x86_64-pc-windows-msvc
File first-main.cc
import first_module;
int main() {
return bar();
}
Compiling (no problems):
$ clang++ --std=c++20 -fmodules first-main.cc -fmodule-file=first_module.pcm first_module.pcm
Everything is ok.
File second-main.cc
import first_module;
#include <iostream>
int main() {
std::cout << bar() << std::endl;
}
Compiling same way:
$ clang++ --std=c++20 -fmodules second-main.cc -fmodule-file=first_module.pcm first_module.pcm
Result: ton of errors like:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include\eh.h:56:14: error: reference to 'type_info' is ambiguous
_In_ type_info const& _Type,
^
note: candidate found by name lookup is 'type_info'
note: candidate found by name lookup is 'type_info'
I have feeling that I am doing something wrong, because I have newest MSVS (updated recently), newest clang, but something still not working on Windows on trivial examples.
Or may be this is known bug? Tried to google it, no results.
The core problem resides in that your current Clang installation it's working with the MSVC toolchain and there's a known issue when you compile using #include directives with the Microsoft toolchain with Clang using the modules feature.
You can find it here, opened since 2018
https://github.com/llvm/llvm-project/issues/38400

G++ -Wshadow doesn't warn about static member shadowing

Once again I lost some hours because of mere stupidity which could have been recognized by the compiler. This is the source code in question:
class f {
static int mVar;
int g(int x) { int mVar=3; return x+mVar; }
};
int f::mVar = 1;
The problem is, that I accidentally added int in front of mVar. When I compile this with: g++ -c -Wall -Wextra -Wshadow shadowtest.cpp I don't get any warning, about the local mVar shadowing the static member mVar.
But if I don't declare the member variable to be static, then g++ correctly issues a warning:
class f {
int mVar;
f(int rVar) : mVar(rVar) {};
int g(int x) { int mVar=3; return x+mVar; }
};
compile with g++ -c -Wall -Wextra -Wshadow shadowtest2.cpp gets:
shadowtest2.cpp:5:24: warning: declaration of ‘mVar’ shadows a member of ‘f’ [-Wshadow]
int g(int x) { int mVar=3; return x+mVar; }
^
shadowtest2.cpp:3:9: note: shadowed declaration is here
int mVar;
^
Tested with g++ 4.9.2 and 5.2.1.
Is this correct behavior or a bug? Why?
Edit: I filed a bug report here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68374
Edit 2018-02-12: Doesn't warn in these versions:
g++-4.9 (Debian 4.9.4-2) 4.9.4
g++-5 (Debian 5.4.1-4) 5.4.1 20161202
g++-5 (Debian 5.5.0-8) 5.5.0 20171010
g++-6 (Debian 6.3.0-18) 6.3.0 20170516
g++-6 (Debian 6.4.0-12) 6.4.0 20180123
g++-7 (Debian 7.2.0-16) 7.2.0
g++-7 (Debian 7.3.0-3) 7.3.0
but successfully warns in:
g++-8 (Debian 8-20180207-2) 8.0.1 20180207 (experimental) [trunk revision 257435]
This looks potentially like a bug given the description of -Wshadow in the gcc documentation:
Warn whenever a local variable or type declaration shadows another variable, parameter, type, class member (in C++), or instance variable (in Objective-C) or whenever a built-in function is shadowed. Note that in C++, the compiler warns if a local variable shadows an explicit typedef, but not if it shadows a struct/class/enum.
Especially considering that clang warns for this case. This is basically a quality of implementation issue since this is not ill-formed code. I would file a bug report. Most likely they they will provide a rationale for not warning in this case or they will eventually fix the warnings.
It looks like gcc used to warn about this case if we go all the way back to version 4.5.4 see it live.

c++ -std=c++11 -stdlib=libc++ with boost.thread gives Segmentation fault: 11 on OSX

Tried to run some sample code.
But something unexpected occured.
I wonder is there any known issus about boost.thread used with libc++ together ?
Program compiled with -std=c++11 or no option runs well.
But when I compiled with -stdlib=libc++ or -std=c++11 -stdlib=libc++
The output was like:
in main
in thread
bash: line 1: 37501 Segmentation fault: 11 ./a.out
Compiler:
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
OS: Mac OS X 10.8.3
The sample code is quite simple:
#include "stdio.h"
#include <boost/thread/thread.hpp>
class callable
{
public:
void operator()()
{
printf("in thread\n");
}
};
int main()
{
boost::thread t = boost::thread(callable());
printf("in main\n");
t.join();
return 0;
}
boost.thread is probably linked to libstdc++.
libstdc++ and libc++ have incompatible ABI. They shouldn't be used both in one program.