Archive for the ‘C/C++’ Category

April 6th, 2016

The University of Sheffield recently purchased licenses for the Windows version of the Intel compiler suite and I’m involved in the release to campus process. As part of this, I wrote some basic documentation on how to compile Hello World using the Intel C++ Compiler within Visual Studio Community Edition 2015. Since this may be useful to people outside of University of Sheffield, I reproduce this part of our documentation here.

These notes were prepared using Intel C++ XE  2015 version 15.0.6 and Visual Studio Community Edition 2015 RTM version. Note that there are problems with using this version of Intel C++ and later versions of Visual Studio Community Edition.

Click on any of the images to see them full size.

  • Launch Visual Studio and click on File->New Project
  • Choose Visual C++ -> Win32 Console Application and give your project a name.

cpp_project

  • In the Win32 Application wizard, untick Precompiled header and Security Development Lifecycle (SDL) checks and click Finish.

setup_cpp

  • A skeleton main() function will appear. Modify the code so that it reads
#include 

int main()
{
    std::cout << "Hello World";
    return 0;
}
  • Click on Project->HelloWorld Properties and under the C++ -> General section, ensure that Suppress Startup Banner is set to No and click OK. This will ensure that when you compile, you’ll be able to see that it’s the Intel Compiler doing the work rather than Visual Studio C++.

startupbanner

  • Click on Project->Intel Compiler->Use Intel C++
  • Build and run the code by pressing CTRL F5. You should see something like the following
>------ Build started: Project: HelloWorld, Configuration: Debug Win32 ------
1>  icl /Qvc14 "/Qlocation,link,C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin" /ZI /W3 /Od /Qftz- -D __INTEL_COMPILER=1500 -D WIN32 -D _DEBUG -D _CONSOLE -D _UNICODE -D UNICODE /EHsc /RTC1 /MDd /GS /Zc:wchar_t /Zc:forScope /FoDebug\ /FdDebug\vc140.pdb /Gd /TP HelloWorld.cpp stdafx.cpp
1>
1>  Intel(R) C++ Compiler XE for applications running on IA-32, Version 15.0.6.285 Build 20151119
1>  Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

Once the compilation has completed, a console window should pop up showing the Hello World output.

March 30th, 2016

I recently tried to use the XE 2015 Update 6 version of the Intel C++ compiler with Visual Studio Community Edition 2015 Update 1. Even a simple Hello World console application didn’t work. I got lots of compilation errors that looked like this

1>C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\exception(248): error : expected an attribute name
1>    [[noreturn]] _CRTIMP2_PURE void __CLRCALL_PURE_OR_CDECL __ExceptionPtrRethrow(_In_ const void*);
1>     ^

There are two solutions to this problem.

May 8th, 2014

This is a guest article written by friend and colleague, Ian Cottam. For part 1, see http://www.walkingrandomly.com/?p=5435

So why do computer scientists use (i != N) rather than the more common (i < N)?

When I said the former identifies “computer scientists” from others, I meant programmers who have been trained in the use of non-operational formal reasoning about their programs. It’s hard to describe that in a sentence or two, but it is the use of formal logic to construct-by-design and argue the correctness of programs or fragments of programs. It is non-operational because the meaning of a program fragment is derived (only) from the logical meaning of the statements of the programming language. Formal predicate logic is extended by extra rules that say what assignments, while loops, etc., mean in terms of logical proof rules for them.

A simple, and far from complete, example is what role the guard in a while/for loop condition in C takes.

for (i= 0; i != N; ++i) {
/* do stuff with a[i] */
}

without further thought (i.e. I just use the formal rule that says on loop termination the negation of the loop guard holds), I can now write:

for (i= 0; i != N; ++i) {
/* do stuff with a[i] */
}
/* Here: i == N */

which may well be key to reasoning that all N elements of the array have been processed (and no more). (As I said, lots of further formal details omitted.)

Consider the common form:

for (i= 0; i < N; ++i) {
/* do stuff with a[i] */
}

without further thought, I can now (only) assert:

for (i= 0; i < N; ++i) { 
/* do stuff with a[i] */ 
} 
/* Here: i >= N */

That is, I have to examine the loop to conclude the condition I really need in my reasoning: i==N.

Anyway, enough of logic! Let’s get operational again. Some programmers argue that i<N is more “robust” – in some, to me, strange sense – against errors. This belief is a nonsense and yet is widely held.

Let’s make a slip up in our code (for an example where the constant N is 9) in our initialisation of the loop variable i.

for (i= 10; i != N; ++i) {
/* do stuff with a[i] */
}

Clearly the body of my loop is entered, executed many many times and will quite likely crash the program. (In C we can’t really say what will happen as “undefined behaviour” means exactly that, but you get the picture.)

My program fragment breaks as close as possible to where I made the slip, greatly aiding me in finding it and making the fix required.

Now. . .the popular:

for (i= 10; i<N; ++i) {
/* do stuff with a[i]
}

Here, my slip up in starting i at 10 instead of 0 goes (locally) undetected, as the loop body is never executed. Millions of further statements might be executed before something goes wrong with the program. Worse, it may even not crash later but produce an answer you believe to be correct.

I find it fascinating that if you search the web for articles about this the i<N form is often strongly argued for on the grounds that it avoids a crash or undefined behaviour. Perhaps, like much of probability theory, this is one of those bits of programming theory that is far from intuitive.

Giants of programming theory, such as David Gries and Edsger Dijkstra, wrote all this up long ago. The most readable account (to me) came from Gries, building on Dijkstra’s work. I remember paying a lot of money for his book – The Science of Programming – back in 1981. It is now freely available online. See page 181 for his wording of the explanation above. The Science of Programming is an amazing book. It contains both challenging formal logic and also such pragmatic advice as “in languages that use the equal sign for assignment, use asymmetric layout to make such standout. In C we would write

var= expr;

rather than

var = expr; /* as most people again still do */

The visible signal I get from writing var= expr has stopped me from ever making the = for == mistake in C-like languages.

May 6th, 2014

This is a guest article written by friend and colleague, Ian Cottam.

This brief guest piece for Walking Randomly was inspired by reading about some of the Hackday outputs at the recent SSI collaborative workshop CW14 held in Oxford. I wasn’t there, but I gather that some of the outputs from the day examined source code for various properties (perhaps a little tongue-in-cheek in some cases).

So, my also slightly tongue-in-cheek question is “Given a piece of source code written in a language with “while loops”: how do you know if the author is a computer scientist by education/training?”

I’ll use C as my language and note that “for loops” in C are basically syntactic sugar for while loops (allowing one to gather the initialisation, guard and increment parts neatly together). In other languages “for loops” are closer to Fortran’s original iterative “do loop”. Also, I will work with that subset of code fragments that obey traditional structured (one-entry, one-exit) programming constructs. If I didn’t, perhaps one could argue, as famously Dijkstra originally did, that the density of “goto” statements, even when spelt “break” or “continue”, etc., might be a deciding quality factor.

(Purely as an aside, I note that Linux (and related free/open source) contributors seem to use goto fairly freely as an exception case mechanism; and they might well have a justification. The density of gotos in Apple’s SSL code was illustrated recently by the so-called “goto fail” bug. See also Knuth’s famous article on this subject.)

In my own programming, I know from experience that if I use a goto, I find it so much more difficult to reason logically (and non-operationally) about my code that I avoid them. Whenever I have used a programming language without the goto statement, I have never missed it.

Now, finally to the point at hand, suppose one is processing the elements of an array of single dimension and of length N. The C convention is that the index goes from 0 to N-1. Code fragment A below is written by a non computer scientist, whereas B is.

/* Code fragment A */
for (i= 0; i < N; ++i) {

/* do stuff with a[i] */

}
/* Code fragment B */
for (i= 0; i != N; ++i) {

/* do stuff with a[i] */

}

The only difference is the loop’s guard: i<N versus i!=N.

As a computer scientist by training I would always write B; which would you write?

I would – and will in a follow-up – argue that B is better even though I am not saying that code fragment A is incorrect. Also in the follow-up I will acknowledge the computer scientist who first pointed this out – at least to me – some 33 years ago.

December 20th, 2012

I recently installed the 64bit version of the Intel C++ Composer XE 2013 on a Windows 7 desktop alongside Visual Studio 2010.  Here are the steps I went through to compile a simple piece of code using the Intel Compiler from within Visual Studio.

  • From the Windows Start Menu click on  Intel Parallel Studio XE 2013->Parallel Studio XE 2013 with VS2010

  • Open a new project within Visual Studio: File->New Project
  • In the New Project window, in the Installed Templates pane, select Visual C++ and click on Win32 Console Application.  Give your project a name.  In this example, I have called my project ‘helloworld’. Click on OK.

  • When the Win32 Application Wizard starts, accept all of the default settings and click Finish.
  • An example source file will pop up called helloworld.cpp.  Modify the source code so that it reads as follows
#include "stdafx.h"
#include<iostream>
using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
	cout << "Hello World";
        cin.get(); 
	return 0;
}

We now need to target a 64bit platform as follows:

  • Click on Project->helloworld Properties->Configuration Properties and click on Configuration Manager.

  • The drop down menu under Active Solution Platform will say Win32. Click on this and then click on New.

  • In the New Solution Platform window choose x64 and click on OK.

  • Close the Configuration Manager and to return to the helloworld Property Pages window.
  • At the helloworld Property Pages window click on C/C++ and ensure that Suppress Startup Banner is set to No and click OK.

  • Click on Project->Intel Composer XE 2013->Use Intel C++ followed by OK. This switches from the Visual Studio Compiler to the Intel C++ compiler.
  • Finally, build the project by clicking on Build->Build Solution.  Somewhere near the top of the output window you should see
    1> Intel(R) C++ Intel(R) 64 Compiler XE for applications running on Intel(R) 64, 
    Version 13.0.1.119 Build 20121008
    1> Copyright (C) 1985-2012 Intel Corporation. All rights reserved.

    This demonstrates that we really are using the Intel Compiler to do the compilation.

  • Once compilation has completed you can run the application by pressing F5. It should open a console window that will disappear when you press Enter.

TOP