maybe it is a stupid question.but I really don't know how to use it. :shock:
can anyone help me??Thanks.
I only get these result.
Quotecppcheck --version
Cppcheck 1.40
cppcheck --verbose --all --style --xml "main.cpp"
Checking main.cpp...
<?xml version="1.0"?>
<results>
</results>
Ok,I use cppcheck to check CppCheck.cpp project.and it got two results.
QuoteCppCheck.h|31|memleak : possible error : Memory leak: CppCheck::m_CppCheckLog|
CppCheck.h|32|memleak : possible error : Memory leak: CppCheck::m_ListLog|
QuoteCppCheck::CppCheck()
{
if (!Manager::LoadResource(_T("CppCheck.zip")))
{
NotifyMissingFile(_T("CppCheck.zip"));
}
m_LogPageIndex = 0; // good init value ???
m_CppCheckLog = 0;
m_ListLog = 0;
m_ListLogPageIndex = 0;
m_CppCheckApp = _T("cppcheck");
} // end of constructor
and here I suggest use
m_LogPageIndex = NULL;
m_CppCheckLog = NULL;
and when I use it to check c::b.
it get such result.what is the problem???
Quotecppcheck --version
Cppcheck 1.40
cppcheck --verbose --all --style --xml "base\tinyxml\tinystr.cpp" "base\tinyxml\tinywxuni.cpp" "base\tinyxml\tinyxml.cpp" "base\tinyxml\tinyxmlerror.cpp" "base\tinyxml\tinyxmlparser.cpp" "build_tools\autorevision\autorevision.cpp" "include\annoyingdialog.h" "include\autodetectcompilers.h" "include\backgroundthread.h" "include\base64.h" "include\blockallocated.h" "include\cbauibook.h" "include\cbeditor.h" "include\cbeditorprintout.h" "include\cbexception.h" "include\cbfunctor.h" "include\cbplugin.h" "include\cbproject.h" "include\cbstyledtextctrl.h" "include\cbthreadedtask.h" "include\cbthreadpool.h" "include\cbthreadpool_extras.h" "include\cbtool.h" "include\cbworkspace.h" "include\compileoptionsbase.h" "include\compiler.h" "include\compilercommandgenerator.h"
[......]
Quote from: blueshake on February 19, 2010, 08:41:01 AM
and when I use it to check c::b.
it get such result.what is the problem???
Quotecppcheck --version
Cppcheck 1.40
cppcheck --verbose --all --style --xml "base\tinyxml\tinystr.cpp" "base\tinyxml\tinywxuni.cpp" "base\tinyxml\tinyxml.cpp" "base\tinyxml\tinyxmlerror.cpp" "base\tinyxml\tinyxmlparser.cpp" "build_tools\autorevision\autorevision.cpp" "include\annoyingdialog.h" "include\autodetectcompilers.h" "include\backgroundthread.h" "include\base64.h" "include\blockallocated.h" "include\cbauibook.h" "include\cbeditor.h" "include\cbeditorprintout.h" "include\cbexception.h" "include\cbfunctor.h" "include\cbplugin.h" "include\cbproject.h" "include\cbstyledtextctrl.h" "include\cbthreadedtask.h" "include\cbthreadpool.h" "include\cbthreadpool_extras.h" "include\cbtool.h" "include\cbworkspace.h" "include\compileoptionsbase.h" "include\compiler.h" "include\compilercommandgenerator.h"
[......]
C::B project contains very much files and therfore creates a commandline, that's much too long.
The actual version of cppcheck can not handle it.
Quote from: jens on February 19, 2010, 09:26:34 AM
The actual version of cppcheck can not handle it.
More exactly, it's the OS, that can not handle the long commandline, but it's cppcheck that does not provide another mechanism (like reading the list from a file) at the moment.
this will change within 2 weeks.
I have committed a patch to ccpcheck team, which got applied, and this will allow to specify the files to check in an input file. At that moment I will also update our plug-in and we will only support this new way.
With respect to the X =NULL; ; my very strong personal feeling is not to use NULL, but use 0.
And in the future we will have a special null_ptr keyword (C++Ox) and then all discussions are over ;-)
Quote from: killerbot on February 19, 2010, 12:29:45 PM
With respect to the X =NULL; ; my very strong personal feeling is not to use NULL, but use 0.
And in the future we will have a special null_ptr keyword (C++Ox) and then all discussions are over ;-)
Sorry, I know this is not the right place to ask this, but my curiosity overwhelms my common sense sometimes.
Why against NULL so much? The C++ standard (such that it is) guarantees the keyword NULL to be compatible with all pointer types, but (at my last reading) the constant 0 was
NOT guaranteed to be converted to a null pointer (unlike the older linear C, where constant 0
WAS guaranteed to be a null pointer). (I could be very much out of date here regarding the standards).
Ringo
Quote from: killerbot on February 19, 2010, 12:29:45 PM
With respect to the X =NULL; ; my very strong personal feeling is not to use NULL, but use 0.
And in the future we will have a special null_ptr keyword (C++Ox) and then all discussions are over ;-)
In my opinion using NULL (or a custom nullptr version) is better than 0, because when the C++1x is supported we can do Replace all NULL -> nullptr and we are done, but with 0 you can't do this.
BTW, NULL is #define NULL 0L most of the time (not 100% sure)
Quote from: oBFusCATed on February 19, 2010, 01:56:01 PM
BTW, NULL is #define NULL 0L most of the time (not 100% sure)
In the (rather old) copy of the standard I have, NULL is defined as a macro
#define NULL ((void *) 0)
where the constant 0 is type-cast to a void*, ensuring the created value would represent an invalid address. Obviously, on some machines (an old CDC comes to mind), the "actual" address of 0 was valid (it was a machine register).
Ringo
Extract from some of the headers in:
VC2005:
/* Define NULL pointer value */
#ifndef NULL
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
#endif
GCC 4.4.3
#if defined (_STDDEF_H) || defined (__need_NULL)
#undef NULL /* in case <stdio.h> has defined it. */
#ifdef __GNUG__
#define NULL __null
#else /* G++ */
#ifndef __cplusplus
#define NULL ((void *)0)
#else /* C++ */
#define NULL 0
#endif /* C++ */
#endif /* G++ */
#endif /* NULL not defined and <stddef.h> or need NULL. */
#undef __need_NULL
BTW: for everyone interested in nullptr -> http://blogs.msdn.com/vcblog/archive/2009/10/27/channel-9-video-stephan-t-lavavej-everything-you-ever-wanted-to-know-about-nullptr.aspx
Quote from: oBFusCATed on February 19, 2010, 02:31:13 PM
Extract from some of the headers in:
VC2005:
/* Define NULL pointer value */
#ifndef NULL
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
#endif
GCC 4.4.3
#if defined (_STDDEF_H) || defined (__need_NULL)
#undef NULL /* in case <stdio.h> has defined it. */
#ifdef __GNUG__
#define NULL __null
#else /* G++ */
#ifndef __cplusplus
#define NULL ((void *)0)
#else /* C++ */
#define NULL 0
#endif /* C++ */
#endif /* G++ */
#endif /* NULL not defined and <stddef.h> or need NULL. */
#undef __need_NULL
BTW: for everyone interested in nullptr -> http://blogs.msdn.com/vcblog/archive/2009/10/27/channel-9-video-stephan-t-lavavej-everything-you-ever-wanted-to-know-about-nullptr.aspx
Excellant! I trust the GCC definitions, and so that means that now NULL is a synonym for a constant 0. But I still prefer to use NULL when assigning to pointers, if only for the fact that the definition of NULL might change in the future (as it already has), and so my code would stay compatible with future compilers.
Ringo
the argument NULL is easier to replace by the new keyword sounds good to me.
But people like Dewhurst, Meyers convinced me to use 0. So my 'NULL' days are over ;-)
But if you really prefer to use NULL, just do it, but I wouldn't go into changing source that already uses 0, instead of the macro, since that is a little bit one step backward.
QuoteCppCheck.h|31|memleak : possible error : Memory leak: CppCheck::m_CppCheckLog|
CppCheck.h|32|memleak : possible error : Memory leak: CppCheck::m_ListLog|
Did we miss the important thing??It seems some memory leak here. :D
Quote from: blueshake on February 20, 2010, 05:32:04 AM
QuoteCppCheck.h|31|memleak : possible error : Memory leak: CppCheck::m_CppCheckLog|
CppCheck.h|32|memleak : possible error : Memory leak: CppCheck::m_ListLog|
Did we miss the important thing??It seems some memory leak here. :D
Cppcheck reported that "possible memory leak" because it saw a constant value (see our discussion about NULL) being assigned to pointers, without a preceeding "delete" or "free" on those pointers. Therefore, Cppcheck thinks there is a possibility of "orphan" data blocks in memory.
However, the piece of code in question appears to be a constructor, meaning that there is no memory block assigned to those pointers; the assignment is merely an initializer.
Ringo
Which brings us here: http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.6
Quote
Initialization lists. In fact, constructors should initialize as a rule all member objects in the initialization list. One exception is discussed further down.