Programming

Performance is essential for infrastructure software. Modern infrastructure software depends heavily on components. Therefore, writing performant code in this environment requires deep understanding of the characteristics of such components. The course will help programmers to improve performance of their code by learning how to use these existing generic components effectively. In addition, it will teach them to extend the library with new high-performance components. Along the way, participants will learn how to use C++ as a high-performance language. The course will be taught interactively with the class discussing, discovering, and developing components together.

The C language is relatively "small" in comparison to other modern computer languages. To completely specify it, (and its standard library) only requires about ~550 pages. To do the same for Java or C++ would require an entire bookshelf, rather than a single book. However, even though the language is small enough to be easily comprehended, it has some dark corners. The purpose of this article is to explore some of them. Since C is used in a wide variety of applications, the "dialect" of it varies. This means that some people may be quite familiar with many of the following items. However, the individual "non-obscure" subsets should hopefully vary, resulting in at least a few items you might not know about.

I am making this post thinking "Better late than never", as I was supposed to make this post a long time ago, actually in the beta period of Visual Studio 2012, like I did with Visual Studio 2010, unfortunately I was held up with other stuff, personal and work related. This post remained as partially completed in my blog's drafts for a long time which I took and finished.

We have checked the Windows 8 Driver Samples pack with our analyzer PVS-Studio and found various bugs in its samples. There is nothing horrible about it - bugs can be found everywhere, so the title of this article may sound a bit high-flown. But these particular errors may be really dangerous, as it is a usual practice for developers to use demo samples as a basis for their own projects or borrow code fragments from them.

Kernighan's rule for optimizations (Don't do it) is good advice. But as with most rules, there are exceptions.

For the purpose of testing our C/C++ analyzer PVS-Studio, we often check various open-source projects and publish reports about bugs we have found. It is obvious that we seek projects of large sizes (hundreds of thousands of code lines), as there is little to be tested and caught in just a few dozens of files. We already had opportunities to test large collections consisting of hundreds of small open-source projects, for example sets of test samples for various SDKs and Frameworks. We are especially interested in checking such collections to see how the analyzer supports various specific code constructs, Visual C++ project subtypes, and so on.

As an experiment, we have decided to offer everyone interested a PVS-Studio registration key for 5 days to study its 64-bit diagnostics more thoroughly. The PVS-Studio demo version is absolutely full-function. It is sufficient to study the tool and get familiar with its capabilities. The user has up to 200 clicks to navigate through code fragments the analyzer considers to be probably incorrect. We believe it's quite enough for the user to decide if he/she likes the tool or not. However, that might be insufficient in case you are searching for 64-bit errors. Many of the 64-bit warnings are false positives or are irrelevant to this program, as fragments they point to cannot cause errors. That's why the restriction of 200 messages you can click to navigate through the code may prevent you from forming a definite opinion of the tool. We have been watching an increasing interest towards development of 64-bit software lately. Perhaps this has to do with the release of Embarcadero RAD Studio XE3 Update 1 that has learned now to compile 64-bit applications. Or maybe it's just that the time has come.

We regularly check various open-source projects with PVS-Studio and send analysis results to developers and usually describe them in our posts as well. Besides, we add them into our bug database. This database is posted below on this page. The bugs are grouped according to the number of the diagnostic rule that is used to detect them. This number is given in the left column. Click on it to see the diagnostic rule description in the documentation. The right column contains a link to the corresponding error samples. Some diagnostics haven't detected any bugs in open-source projects yet. The lower you are in the list, the more diagnostics with no error samples there will be. The reason is simple: the later a certain rule had been added, the fewer projects were analyzed with this rule included into the rule set and therefore the fewer chances for it to demonstrate its capabilities.

PVS-Studio is a static analyzer that detects errors in source code of C/C++/C++11 applications. There are sets of rules included into PVS-Studio: General-purpose diagnosis Detection of possible optimizations Diagnosis of 64-bit errors (Viva64) Diagnosis of parallel errors (VivaMP)

We continue last week's discussion by getting down to details. We continue last week's discussion by getting down to details. If you haven't read it, please do so now; I'll wait. Thanks! We'll start by defining three important implementation-dependent types: ...

The traditional reasons for preferring C to C++ have been steadily whittled away. Are there any good reasons to still use C?

One of the largest UReddit classes to date, Introduction to C++ by user Skyeshatter (sarevok9 on Reddit) consists of a series of 46 video lectures on the C++ programming language, aimed at the novice programmer. In the teacher's own words,

Windows Store App Development, Windows Phone App Development.

As CPU cores become both faster and more numerous, the limiting factor for most programs is now, and will be for some time, memory access. Hardware designers have come up with ever more sophisticated memory handling and acceleration techniques-such as CPU caches-but these cannot work optimally without some help from the programmer. Unfortunately, neither the structure nor the cost of using the memory subsystem of a computer or the caches on CPUs is well understood by most programmers. This paper explains the structure of memory subsys- tems in use on modern commodity hardware, illustrating why CPU caches were developed, how they work, and what programs should do to achieve optimal performance by utilizing them.

In forums, people often say that 64-bit versions of programs consume a larger amount of memory and stack. Saying so, they usually argue that the sizes of data have become twice larger. But this statement is unfounded since the size of most types (char, short, int, float) in the C/C++ language remains the same on 64-bit systems. Of course, for instance, the size of a pointer has increased but far not all the data in a program consist of pointers. The reasons why the memory amount consumed by programs has increased are more complex. I decided to investigate this issue in detail.

The people who created C sure loved keeping the number of keywords low, and today I'm going to show you yet another place you can use the static keyword in C99.

Support has been implemented for several previous versions of C++Builder. Now PVS-Studio supports the following versions of C++Builder: XE3 Update 1, XE2, XE, 2010, 2009.

The article describes 10 sime-saving debugging techniques available in Visual Studio

I find this question pretty strange. The answer is yes, of course, and that will be so for a long time. But I'm asked this question from time to time at conferences or when communicating with developers on forums. I've decided to answer this question in the form of a brief post so that I could just refer people to it in the future.