PC-Lint

$389 is cheap.

Quote:

Original post by Shannon Barber $389 is cheap.

Depending on the size of the team, but searching half a day for a problem that could have been detected by lint costs usually more than $389.

Also, most places are probably only need one license. You can install it on one machine that runs it automatically (or manually, doesn't really matter), and then make the results available for everyone.

With the way that application development has progressed over the past decade, it would seem that anyone still using C/C++ is at a clear natural disadvantage in terms of being able to keep up with the features and constructs that some other languages provide. Programs aren't getting any easier to write with C/C++ and most likely never will.

For serious programmers who do not work in large companies with vast resources, remaining competitive and at the edge of technology is vital to their survival. The only way to stay competitive and do more with less, is to work more efficiently. How does one work more efficiently? By investing in the tools that cater towards the fact we are all human and will make mistakes in our coding practices no matter how hard we try not to. Luckily, there are tools such as this that give use the extra boost we can use to keep working efficiently and not be over burdened with the complexities of development.

I am very interested in this product having seen the review and the site's bug of the month pages, but I ran one test case of a type of bug I've made many times in threaded code and it was not detected.

That leads me into a personal delima. Will this program actually help me fix bugs that I do not recognize or will it mostly catch the things I am already tuned to being able to recognize. I don't doubt it will work efficiently in use, but I am not yet sold on whether or not I actually need this product to boost efficiency.

For someone that has a lot of C++ code to analyze, I could imagine it would help a lot. However, I've more or less disavowed my old C++ code since it was poorly written code. When I develop nowadays, I think in terms of possible problems before I commit to the code. I program a lot more defensively and add in debugging systems to help me catch the runtime bugs as the occur. How effective will PC-Lint actually boost my productivity? (rhetorical question)

I agree with Mr. Barber that the price certainly is cheap for what you are getting. However, knowing how complex and unmanageable C++ code is, I wonder how effective the tool is in that language compared to C, where lint was regarded as an amazing program for C.

I will have to do some mulling over this product and think about the future, especially with a new C++09 standard coming as well as windows development platform (Windows 7).

Hi,

thanks for your comments. I'd like to reply to some of your statements :)

When I say that $389 isn't cheap, I had the average gamedev.net user in mind. Most people in here are spare time developers and no professionals. Being a professional, I purchased a copy because a) it wasn't too expensive for me, b) it helps me a lot reviewing the large code base I have, c) it helps me finding bugs in the code base I inherited and d) it helps me to write better code. So for me, it's a valuable tool.

In a couple of weeks I'll review Visual Lint, which integrates tightly PC-Lint into Visual Studio. This makes the configuration and the parsing result handling a lot easier and more comfortable. IMHO both combined are what boosts your productivity because a) it's no fun scanning a 2Mb Lint file for possible bugs and b) Visual Lint does sort by project, file, error type, etc. So for those hesitating to pick up PC-Lint, wait until you've read the Visual Lint review and take a decision then.

As for picking a number of licenses or not for a team, it all depends on your team structure and the time you want your team to invest to learn this tool. I'd rather have one or two guys sitting there really knowing this tool than my entire 20 man team. Rattenhirn is right when stating a single license (for one programmer) could be enough as long as that license is used to generate reports for the different team members during review.

The tool will not help you to write code faster. It will help you to write more secure and less bug infested code. Now, if you see the coupling between this and efficiency (hint: less bugs equals less debugging sessions), you have a win-win situation. But as I stated, if you use this tool on an already existing, large code base, the number of problems you'll be pointed at can be discouraging and overwhelming.

The online tool, which can be used to test the software, doesn't really do a favor to the software. You can't configure it as you need it. And as I stated it in my review, configuration of PC-lint can be crucial.

Have fun,
Stefan

The software is really fine, technically and from a maintainers point of view, except that it's not cheap enough to ever make it into my hobbytime.

But I have a nitpick:

Quote:

http://gimpel.com PC-lint for C/C++ the longest continuously advertised software tool in human history, was first introduced in 1985.

This is imho a bit grandstanding and a little bit unsharp. Certainly there is older software still in use, just look at yacc (an integral part of unix; just recently a 33 year old bug has been fixed) or Unix itself.

There Visual LINT that is an incredible tool that integrates PC-LINT with Visual Studio, from the company Riverblade. That tool makes the use of PC-LINT as easy as use the compliler. It integrates perfectly and made the check of the solution files in the background while you work.

The website of the tool is: http://www.riverblade.co.uk/products/visual_lint

PD: I don´t work for riverblade, i only use it in my company.

I think that the most part of the bugs reported on "bug of the month" are due to C/C++ itself and these bugs are easily avoided if one use a more modern language.
When a programmer has to write large and complex programs needs a language that allow him to focus on the problem and not on the language's subleties.

Quote:

Original post by luckybit I think that the most part of the bugs reported on "bug of the month" are due to C/C++ itself and these bugs are easily avoided if one use a more modern language. When a programmer has to write large and complex programs needs a language that allow him to focus on the problem and not on the language's subleties.

What language would I use for a large and complex program like an AAA game?

[Edited by - Rattenhirn on February 20, 2009 8:49:04 AM]

Quote:

Original post by Rattenhirn What language would I use for a large and complex program like an AAA game?

For writing AAA games maybe C/C++ today is the only choice, but AAA games are not the only kind of sofware existing in the world.

Quote:

Original post by luckybitFor writing AAA games maybe C/C++ today is the only choice, but AAA games are not the only kind of sofware existing in the world.

Indeed! There's a lot of software that can only be written in C/C++. The article discussed here showcases a possible solution for practical problems in C/C++. As do the "Bug of the Month" articles.

So, please tell me why you felt the urge to go ahead and state out of the blue on this threat that the solution is to use a "more modern language"?

I don't get it!

Quote:

Original post by Rattenhirn Indeed! There's a lot of software that can only be written in C/C++.

Among these are device drivers and boot loaders. Oh wait, I forgot about Forth. o_O

Quote:

So, please tell me why you felt the urge to go ahead and state out of the blue on this threat that the solution is to use a "more modern language"? I don't get it!

It has been said again and again, but here goes...

C/C++ are low level languages. You have to do much boilerplate code and spend lots of time (coding and debugging) even on things which are trivial in higher level, more abstracted languages.

With modern processors and large main memory, there are less and less cases where the memory/performance gain that C/C++ can get you justify the vastly increased development burden on the programmer. That's a good reason for switching to another, modern, HLL. After all, most of these languages provide a native interface which can be used to optimize performance-critical parts of your code (rendering etc).

Quote:

Original post by Konfusius Quote: So, please tell me why you felt the urge to go ahead and state out of the blue on this threat that the solution is to use a "more modern language"? I don't get it! It has been said again and again, but here goes... C/C++ are low level languages. You have to do much boilerplate code and spend lots of time (coding and debugging) even on things which are trivial in higher level, more abstracted languages. With modern processors and large main memory, there are less and less cases where the memory/performance gain that C/C++ can get you justify the vastly increased development burden on the programmer. That's a good reason for switching to another, modern, HLL. After all, most of these languages provide a native interface which can be used to optimize performance-critical parts of your code (rendering etc).

That does not answer my question at all.

How can using a "more modern language" solve practical problems with C/C++ better than using PC-Lint?

Some people use C/C++ because they like or they have to or there's no viable alternative. A lot of these people work as programmers in game development (what this site is about btw).

Yet, every time, a C/C++ issue or even a solution to such issues, like in this case is discussed, some people feel obliged to tell everyone to dump C/C++ and use a "more modern language" or worse.

I want to know: Why?

$389 probably breaks down into $20 for static code analysis and $369 for the pain and suffering of having to parse C++.

Quote:

With modern processors and large main memory, there are less and less cases where the memory/performance gain that C/C++ can get you justify the vastly increased development burden on the programmer. That's a good reason for switching to another, modern, HLL. After all, most of these languages provide a native interface which can be used to optimize performance-critical parts of your code (rendering etc).

To expand on Rattenhirn's post, the attitude that "with all these more powerful processors who cares!" gets me too.
Am I the only one upset that my fancy new quadcore takes just as long(or longer) to do some tasks as my old 486?

I mean, I understood on an old machine, pressing ctrl-f to open the find dialog was going to take a while. But why does it STILL take so long to pop up that window that 3 times out of 10 my search query will be typed into my document before the find window pops up (unless i wait the inordinate amount of time for the silly window to come up)? (talking VS 2008 here). Same issue with the ctrl-tab sometimes takes forever, even when i've been tabbing back and forth between the same two documents for a while. And it isn't like I have anything but VS and my debugger open, so it isn't something else eating my cpu.

One more reason I still use non-gui programs like vim, I can type /searchstring as fast as i possibly can, and there is no way it will screw up my document unless i typo. But I still woulda thought the GUI stuff would have improved by now.

I'm glad RAD tools let people turn out shovelware apps for stupid utility or prototype. But I hate that it ends up used on final products in such a way that the end product's gui does the same thing as the commandline version, only 20000% slower.

Quote:

Original post by Rattenhirn That does not answer my question at all. How can using a "more modern language" solve practical problems with C/C++ better than using PC-Lint? Some people use C/C++ because they like or they have to or there's no viable alternative.

The discussion was about how much time PC-Lint saves and it was my point that a lot of time can be saved by considering alternatives to and/or minimizing usage of C++.

Quote:

Original post by KulSeran To expand on Rattenhirn's post, the attitude that "with all these more powerful processors who cares!" gets me too.

That's fully not my attitude. I am all for efficiency. It's my point that you can code efficient applications without using C++ all the way through.
Modern processors are already optimized for heavily data-driven applications, which means interpreted or byte-compiled HLLs perform well on them.

Quote:

Am I the only one upset that my fancy new quadcore takes just as long(or longer) to do some tasks as my old 486?

No. I hate that too.

Quote:

One more reason I still use non-gui programs like vim, I can type /searchstring as fast as i possibly can, and there is no way it will screw up my document unless i typo. But I still woulda thought the GUI stuff would have improved by now.

So what about TextMate or it's clone e-Editor? They are slim C++ applications, but it's in their nature that most functionality is in bash/ruby scripts. They don't execute nearly as fast as native code would but I like that I can write scripts for it in a matter of seconds.

Quote:

Original post by Konfusius The discussion was about how much time PC-Lint saves and it was my point that a lot of time can be saved by considering alternatives to and/or minimizing usage of C++.

Ok, so instead of spending USD 389.- on PC-Lint, I just need to rewrite of all (or most) of my C/C++ code in some other language. Programmers must be really cheap where you come from! ;)

Quote:

Original post by KonfusiusModern processors are already optimized for heavily data-driven applications, which means interpreted or byte-compiled HLLs perform well on them.

No.

CPUs, old and modern, don't do much more than manipulating data, so of course they are optimised for this task. Thanks to that it has become feasible to run interpreted languages for some application (starting around 1960).

Unfortunately, for many applications, using interpreted languages was/is still too slow, so some clever guys invented Just-In-Compilation to speed them up (that was around 1980).

So actually, the applications have been optimised for the CPU and not vice versa, as it has always been.

The CPU on a x86 box is something very special. Interpreted, JIT, and otherwise "slower" languages still run really fast on x86. Why? the x86 has both instruction and register reordering capability (the corner stones of any optimizing compiler). So, when a program become very unpredictable at runtime (ie a VM) the CPU can still organize some of the code on the fly.

Now, hop over to 90% of the embedded (and console) CPUs. TADA! all the fancy CPU reordering circuits are out the window, and now your non-native code isn't looking to fast. Maybe that isn't so bad though, if you keep the higher level logic in a high level language (scripting) then maybe it doesn't matter, since the scripts will be taking a tiny amount of CPU compared to all the vertex, audio, and streaming data processing.

Right tools for the right job and all. And I think PC-Lint is one of those right tools. Mostly because it helps to kill off usage problems between the optimized code and the higher level logic and wrappers. Especially when people are rushed, and aren't as pedantic about adding debug error checking code as they should be. (expecially when person A makes assumptions about function Foo() because they are at-the-moment the only one using that function they made)