Ja det er jo dejligt, når han er på toppen, men det er han nu næsten altid.

Men det var også dejligt, at jeg kunne lokke ham, op på stigen, så han kunne tage et billede af Ritas flotte tæppe – sådan lidt fra oven……Dette var det billede Bjarne tog.

Det er et rigtig flot reste tæppe, men bemærk alle de flotte detajler.

…och sina ideal. Och ibland är likheterna få

Eva Longoria (film & TV-stjärna) samt Bjarne Stroustrup (grundare av programmeringsspråket C++).

This is an interesting book about designing interactive systems. 

I have bought the book if someone from MMD will borrow it. 

The Author Bill Buxton, refers to video as a good way to sketch the user experience. You can find some

Video examples on.  

http://books.elsevier.com/companions/defaultindividual.asp?isbn=9780123740373

/Bjarne S.

Bjarne, creador del lenguaje C++ suele dejar consejos bastante buenos en su página web personal. Uno de los que yo creo más útiles es el que versa sobre la elección de un buen compilador de C++. Es lógico pensar que quien mejor que el creador del lenguaje para aconsejar a un neófito sobre el mejor compilador a usar.

La elección del compilador es seria, porque por un lado debe conocer al procesador, como suelo aconsejar yo (tanto para quien me pregunta como para mi mismo). Pero por otro lado debe ser un compilador que se ajustes a los estándares ISO en aras de la portabililidad del código. En este sentido la lista que Bjarne proporciona cumple las espectativas, la lista, si bien incompleta -como se encarga el mismo de advertir, pues no conoce todos los compiladores habidos y por haber- :

• Apple C++. It also comes with OS X on the developer tools CD.
• Bloodshed Dev-C++. A GCC-based (Mingw) IDE.
• Borland C++
• Cygwin (GNU C++)
• Digital Mars C++
• MINGW – “Minimalist GNU for Windows”. Another GCC version for Windows including a free (non-GPL) w32api.
• DJ Delorie’s C++ development system for DOS/Windows (GNU C++)
• GNU CC source
• Intel C++ for linux
• The LLVM Compiler Infrastructure (based on GCC).
• Microsoft Visual C++ 2008 Express edition.
• Sun Studio.

Es bueno ve que Bjarne aconseja un compilador de Sun microsystems (quienes desarrollan compiladores y máquinas virtuales java).

Según Bjarne la mejor prueba, o al menos la primera que debe pasar un compilador es que sea capaz de compilar el sigueinte código sin problemas:

#include<iostream>
#include<string>

using namespace std;

int main()
{
string s;
cout >> "Please enter your first name followed by a newline\n";
cin >> s;
cout << "Hello, " << s << '\n';
return 0; // this return statement isn't necessary
}

Es bueno saber a qué compiladores puede acogerse uno, aunque sea de entrada y para aprender.

Por otro lado y en uno de sus comentarios, me siento identificado porque esto que dice Bjarne es
algo que llevo diciendo yo desde 2006. Es relativo a C#, lo cito textualmente :

What do you think of C#?

I have no comments on C# as a language. It will take a lot to persuade me that the world needs yet another proprietary language (YAPL). It will be especially hard to persuade me that it needs a language that is closely integrated with a specific proprietary operating system.

If you want to write exclusively for the .Net platform, C# isn’t the worst alternative, but remember that C++ is a strongly supported – though less strongly hyped – alternative on that platform.

De este párrafo me quedo con "a language that is closely integrated with a specific proprietary
operating system" lo que suscribe mis sospechas -publicadas en PC-WORLD- acerca de la mal
intencionada relación entre C# y el sistema operativo windows vista .... que cada uno juzgue como
crea conveniente. 

Nunca está de más pasarse por la página de semajante genio para leerlo, que lo que cuenta es muy útil
y gratis.  .

Congratulations go out to Bjarne Riis and the rest of his team. The boys did well. Great job!

Dzisiaj rozpoczynam naukę języka C++ z dwiema nowymi, ledwo co rozpakowanymi książkami:

• “Język C++” – Bjarne Stroustrup
• “Język C++ – ćwiczenia i rozwiązania” – David Vandevoorde

Choć rozmiary pierwszej z nich mogą przerażać (ponad 900 stron) to mam nadzieję, że nie zniechęcę się do jej lektury i że będzie ona równie przyjemna co lektura dwóch innych, już rozpracowanych “książeczek” o języku C.

Życzcie mi powodzenia.

On May 27th, Ramshankar in one of the C++ communities at Orkut, asked what seemed like a pretty innocuous question:

class TUid
{
public:
IMPORT_C TInt operator==(const TUid& aUid) const;
static inline TUid Null();
public:
TInt32 iUid;
};

What is the purpose of defining “public” section again? Is it for allowing:

TUid myType = { 0×01232423 };

Multiple public/protected/private sections are very much allowed in C++. In fact, they are seen in MFC wizard generated code. But, the real problem lay in not whether it was allowed, but why has this been allowed? As the C++ standard states that:

12. Nonstatic data members of a (non-union) class declared without an intervening access-specifier are allocated so that later members have higher addresses within a class object. The order of allocation of nonstatic data members separated by an access-specifier is unspecified (_class.access.spec_).

So, to find accurate (reliable) answer I had to email Bjarne, and this was his reply:

Consider

struct S {
public:
int a;
private:
int b;
public:
int c;
private:
int d;
};

Is the compiler allowed to allocate the private members next to each other? (the answer is yes).

The reason for the rule was early ideas of separating private data from public data for some implementations to be able to alleviate code evolution problems when the data layout changed.

For example if you allocated public before private, then adding a private member could be done without affecting the public intercase (after creation). As far as I know, no compiler has ever done that.

However, some compilers do use rearrangement to create more compact layouts. For example:

struct SS {
char a;
public:
int b;
public:
char c;
public:
int d;
public:
char e;
};

If members are allocated in declaration order, the size will be 5 words, but you can (legally) reorder to get 3 words (assuming a 4-byte word).

Personally, I have never found this useful.

I’ll leave as an exercise how to reorder to get 3 words .

But, a mystery still remains as André asked:

Can you write any piece of strictly conforming code for which 9p12 (the above stated standard snippet) makes ANY difference for a non-POD (Plain Old Data) type?

Put another way (this is a different formulation of the same question):
Can you write any piece of code that uses 9p12 (the fact that the order is specified) for a non-POD type, without invoking undefined behaviour?

Can you?!

NO, C++ standard library is not a part of the C++ language but provides support.

The question was raised in an Orkut forum, and who better to ask than Bjarne. This is what his reply to my email was:

I would say no. Even though you can use NULL after #including that
appropriate standard library header, you don’t have to.

In C++0x, we’ll get nullptr as a keyword indicating the null pointer.

What’s the difference between the heap and the free-store? The C++ Programming Language keeps on referring them interchangeably. There was as huge cry over this issue in C/C++ programmer’s community in Orkut. I had to shoot a mail to Dr. Bjarne Stroustrup. Here’s our conversation:

My Mail:

Dear Mr Stroustrup,

Sorry to disturb you again. You have mentioned several times in the TC++PL that ‘new’ allocates memory from the ‘free store (or heap)’. There has been a huge cry on the C++ community at Orkut (that I am moderating) as to whether free-store is the same as heap. The argument given against is that Mr Herb Sutter has mentioned that the free-store is different from the heap:

http://www.gotw.ca/gotw/009.htm

and that global ‘new’ has nothing to do with the heap.

So, if so, why has TC++PL used ‘free store (or heap)’ instead of mentioning the use of ‘heap’ separately.

Waiting anxiously for the response.

Regards,
Zaman Bakshi

His Reply:

<!– D(["mb","

",1] ); D(["mb","

",0] ); //–>Because even though it is undefined from where new and malloc() get their memory, they typically get them from exactly the same place. It is common for new and malloc() to allocate and free storage from the same part of the computer’s memory. In that case, “free store” and “heap” are synonyms. I consistently use “free store” and “heap” is not a defined term in the C++ standard (outside the heap standard library algorithms, which are unrelated to new and malloc()). In relation to new, “heap” is simply a word someone uses (typically as a synonym to “free store”) – usually because they come from a different language background.

My Reply:

Thank you Mr. Stroustrup, I had inferred the same thing (about using free store as general — or better, synonym — term) and had explained the community. But, I had been requested to reconfirm.

With warm regards,
Zaman Bakshi

The C language standard clearly ‘defines’ what an indeterminate value is in C. But the C++ standard is missing this definition. Naturally, we can’t adopt the definition in C standard to C++. I wanted to know, and who could have been more reliable than Mr. Bjarne Stroustrup to clear this cloud of uncertainty. So, I dashed an email to him. Here’s the conversation that followed:

———————————-

Dear Mr Stroustrup,

I am reading D&E, and let me congratulate you for writing such a great book. It has been of a lot of help. Mr. Stroustrup, I am moderating a C++ community on Orkut and there has been a very big issue over what ‘indeterminate value’ means for the C++ standard. The C standard clearly states what ‘indeterminate value’ means, but the C++ standard though using (indeterminate value) many times doesn’t specify its definition. Should we regard ‘indeterminate value’ in C++ as being undefined, or should we stick to the C standard’s definition (for ‘indeterminate value’)?

Anxiously waiting for the response.

Regards,
Zaman Bakshi.

———————————-

———————————-

Dear Mr Stroustrup,

Thank you for replying to my e-mail. Yes, it does answer my issue. This is exactly what I had inferred, but as you know, developers like me can’t argue over the standard, so had to clear the doubt. I, like others, are anxiously waiting for C++0x to be out with the standard. Good luck with it. And I thank you again for your response.

Regards,
Zaman Bakshi

———————————-

People believe that C code has faster execution speed than of C++. I argue otherwise. Many C++ gurus have spent their valuable time explaining that there’s no difference. Now, I may lack credibility but the writer of C++, Bjarne Stroustrup, certainly doesn’t. So, would you believe his words? While browsing the Internet, I found myself laying hands on one of the emails sent to Bajrne to explain his views on this contentious topic. Here’s the email (in full):

TITLE: Speed and size of C versus C++

PROBLEM: ???

I also heard the size of C++ program is generally bigger than C. I am a C programmer trying to learn C++. So, don’t blame me if I have created any misconception about C++.

RESPONSE: ???

For one minor detail: including printf/scanf can include more code than is actually used. An intelligent C++ linker will only get that parts of the stream library REALLY needed.

RESPONSE: cshaver@informix.com (Craig Shaver @ Informix Software, Inc.)

Who implements an intelligent C++ linker??? I was under the impression that you get all the functionality in a class when you link, whether you use it or not.

RESPONSE: bs@alice.att.com (Bjarne Stroustrup), 12 Jan 93
AT&T Bell Laboratories, Murray Hill NJ

Let me try to clear up one or two points. Consider first a somewhat minimal C and C++ program x1.c:

main()
{
int i;
for (i = 0; i < 1000000; i++ ) printf(“Hi,mom!\n”) ;
}

and its more C++ looking cousin x2.c:

main()
{
int i;
for (i = 0; i<1000000; i++ ) cout << “Hi,mon!\n” ;
}

I compiled and ran x1.c and x2.c:

c: cc x1.c
c: size a.out
text | data | bss | dec | hex
12288| 6144| 7608| 26040| 65b8

c: time a.out > /dev/null
25.5u 0.5s 37r a.out

c: PTCC x1.c
c: size a.out
text |data | bss | dec | hex
12288 | 6144 | 7620 | 26052 | 65c4

c: time a.out > /dev/null
25.7u 0.4s 33r a.out

PTCC is the driver for my standard off the-shelf Cfront 3.0 (i.e. I’m not using any technology you couldn’t buy half a year ago). Note that the size of the generated code is essentially the same. So is the speed. Running these examples a few times to eliminate random error in the timing mechanism shows that the run-time isn’t biased one way or the other.

This is what you should expect for a program in the common sub-set of C and C++. There is fundamental reasons for that. You should expect identical code from two C and C++ compilers using the same technology. The only possibly SYSTEMATIC difference I can think of is that a C++ compiler can use better function call sequences than a C compiler that doesn’t apply global optimization because in many cases a C compiler must guard against possible calls with differing numbers of arguments where a C++ compiler doesn’t need to because of C++’s stronger type checking. In most C and C++ compilers, this difference is theoretical, but I’m told that in Zortech C++ it is real (i.e. C++ programs are ever so slightly faster than their C equivalents). However, this is all noise, I doubt the difference between C and C++ in this kind of comparison matters to any real programmers. The difference is far smaller than differences between different C compilers – but surprisingly, it is in C++’s favor.

Programs in the common subset of C and C++ results in
equal sized code that execute at equal speed.

If that conclusion doesn’t appear to hold, check if your C and C++ compilers are of similar quality. If your C++ compiler appears to loose badly you have the option of using a Cfront variant to get the benefits of your C compiler’s code generation facilities. If your C compiler loose badly, switch to C++ even if you aren’t ready to use the “++ features.”

Now, a common argument is “OK, so C++ can match C for a C programs but as soon as you use the REAL C++ features your programs get bigger and slower.” Clearly you can write big and slow programs in any language (even C), but you don’t necessarily take a performance hit when you start using C++. Consider x2.c. It uses the C++ stream I/O library that is certainly bigger than C’s stdio and is unlikely to be tuned to the same degree as stdio. It is also a library that
uses a very large sub-set of C++’s features in its interface and implementation (operator overloading, multiple inheritance, virtual functions, etc.):

c: PTCC x2.c
c: size a.out
c: text | data | bss | dec | hex
17408 | 2048 | 0 |19456| 4c00
c: time a.out > /dev/null
32.8u 1.0s 43r a.out

Surprisingly enough, the code generated for x2.c is noticeably smaller than the code generated for x1.c (75% of x1.o) though – as expected it runs a bit slower (29% user cpu time, 16% better elapse time).

I claim, but cannot prove, that the run-time overhead is primarily a difference in tuning. Other programs that rely heavily on C++ features show improvements over their C counterparts – and others again show overhead. The differences does not appear systematic to me; that is, they are differences in design and effort, rather than inherent overhead in C or C++.

The space advantage of the C++ program is an advantage of the same kind; that is, it is there because a little extra care and thought was spent. Other implementations of stream I/O will show different space and time usage, as will different implementations of stdio. To do simple things only the essential parts of the stream I/O library is brought in. You don’t actually need a very “intelligent” linker, the dumb old Unix ld will do: Just manually split your implementation into several .c files. A simple example:

X.h:
class X {
// details
public:
void f(); // common function
void g(); // uncommon function
// more functions
};

X1.c:
// common functions:

void X::f() { … }

X2.c:
// uncommon functions:

void X::g() { … }

Now, any half-way decent archive program can bring in the object code for X1.c (only) for programs that use the common functions (only) and leave the expense of bringing in the object code for X2.c for the programs that actually use functions defined in X2.c.

There exist linkers that can do that without human help (mostly in the PC world), I just happen not to have one. I think it is important to note that this technique and the tools that supports it carried over from C to C++. We wasn’t at the mercy of some “smart” and possibly espensive or unavailable technology. We don’t have to forget or loose all of our effective techniques in moving from C to C++. We should – as ever – use them with a suitable amount of judgement.

C++ was designed not to leave room “below” for a lower level language, except assembler for machine specific operations.

I found this email on this following link:
http://nkari.uw.hu/Tutorials/CPPTips/split_impl

You can click on it to check for any inconsistencies. So, I take his words on this issue, do you?

It’s undefined !! Basically, in C and C++, if you read a variable twice in an expression where you also write it, the result is undefined. Don’t do that. Another example is:

 v[i] = i++;

Related example:

 f(v[i],i++);

Here, the result is undefined because the order of evaluation of function arguments are undefined.

You can even check it from Bjarne’s own blog on C++ FAQs.

Now click on the ads to your right :p