Le 16/04/2012 22:11, Orchid Win7 v1 nous fit lire :
>> Day #1: Compiling, linking and running.
>> Day #2: Program structure. Functions.
>> Day #3: Variables and constants. Assignments. Printing results.
>> Day #4: Statements, blocks and expressions. Branching.
>> Day #5: Writing functions.
> 
> Well, I wasn't expecting great things. And I'm not /finding/ great
> things. :-P
> 
> 
> 
> Day 1 contains almost no code. Which is fair enough. It begins by
> explaining how all complex programs inherently have to be written using
> OO techniques or they will be too difficult. It continues by explaining
> how somebody took C, the best programming language in the world, and
> added OO features to it to create C++, the new best programming language
> in the world.
> 
> On one point it is clear: Should I learn C before learning C++? The
> answer comes back as "no". Which seems quite correct to me.

Well, there is nothing really to learn in C, once you have learned
assembly programming of course.


> 
> On the subject of Java, it made me laugh.

> "In any case, C++ and Java are so similar that learning one involves
> learning 90% of the other."

Right & wrong. Class, reference, direct inheritance are similar. complex
inheritance, exception handling, pointer are not.

Traditional Java C++ war... not interesting.

> Then we are told that "more than any other programming language, C++
> demands that you /design/ a program before you build it". Followed by
> some mumbo-jumbo about how programmer time is more expensive than
> machine time, and how design mistakes are expensive, etc.

Well, they should look at some Ada or smalltalk... but it's right. Think
before you start coding.


> Then there's a cryptic reference to the fact that iostream and
> iostream.h aren't the same, but the differences are "subtle, exotic, and
> beyond the scope of an introductory primer". Yes, the 879-page monolith
> of a book is only an "introductory primer".

I.e: the author has no clue for you.

> 
> Day 2 continues to supply the laughs, opening with such gems as
> 
> Anyway, apparently main() must always return int. It is against the ANSI
> standard for it to return void.

The problem is to explain Unix: the return of main() is used as the
return of the called program... and some utility like "make" use that
result to check success or failure.

> Then there's some mumbo-jumbo about how you can use cout "to do
> addition", and how when you do count << 8+5, then "8+5 is passed to
> cout, but 13 is what is actually printed". Nice, clear explanation,
> that. :-P

Oh great, it's not cout that does the addition any way! So you now have
a false explanation.



> 
> There's a little bit about comments and how they work. The author
> suggests that "comments should not explain /what/ is happening, but
> /why/ it is happening".

At least a sensible sentence.
What is happening, at low level, is in the code.
Why it is happening is of higher level, and should be put in the comment.


> In an example demonstrating all this, cin is casually dropped in but not
> mentioned anywhere. Presumably we're supposed to /guess/ this detail.

Guess what: it's an input stream (whereas cout is output stream)

> Day 3: 

> And then it starts talking about types. Apparently C++ adds a new "bool"
> type, which is supposed to be 1 byte. Apparently "char" doesn't mean
> character at all, it means a 1-byte integer (and by default, a signed one).

The definition of type are inherited from C (and they f****d it large).
There was no bool in C.
A char is enough bits to store a native glyph. and you can assume that
the number of bit is at least 8.
It can be 9. It can be 16. It can even be 32. (the 9 are met only on
architecture with 9 bits per bytes in the hardware bus)

One warning: sizeof() will return the size in char, not bytes.

Second warning: the signedness of char is local to the compiler.

> 
> Now, this I did not know, but: There is a long int, and a short int. And
> then there's just int. I had always thought these were three different
> sizes of integer. But it appears that actually, long int is one size,
> short int is another size, and plain int refers to whichever one the
> compiler writer chose on a whim. So there's only actually two integer
> sizes, and plain int means "I don't care".

In 1999, there was only issue with 3 integers type. It was 32 bits time.
On nowadays 64 bits, there is also a new one "long long int" !

As inherited from C, it's a total garbage, you can only assume:

char <= short <= int <= long <= long long
unsigned char can store up to 255
unsigned short can store up to 65535
unsigned long can store up to 2^32-1
unsigned long long can store up to 2^64-1

Notice that it is possible that "char = long"

> 
> The book suggests "never use int, always use short int or long int". If
> the table is to be believed, long int is 32-bits. Christ knows what you
> do if you want more bits than that...
> 
> But hey, at least double and float work in a sane way, right?

Do not rely on that. I'm not sure C mandate that the double & float
should obey the IEEE-754 rules, or even their size, nor their
representation and mantissa/offset bitcount.

Usually, float is a 32 bits, double is 64 bits. But it is known that
some compiler would perform the computation on 80 bits registers...


> 
> The book casually mentions something which /seems/ to be claiming that
> variables are not initialised to anything in particular unless you
> specifically request this. That's interesting; I didn't know that.

Yep, variables are allocated, but whatever was in the memory at that
time is their value. You'd better set one.

> Apparently assigning a double to an int is only a /warning/, not a
> compile-time error. The book helpfully fails to specify how the
> conversion is actually done. (From the examples, it appears to round
> towards negative infinity... but it would be kinda useful to have that
> /stated/.)

The problem is they did not yet introduce the promotion/implicit cast.

Issue: it might be a local architecture/compiler choice.

> Alright, Day 4! And the first thing we learn is this: Every C++
> statement is also an expression.
> 
> This is obviously an extremely sick and twisted idea, and whoever
> thought of it was either mentally disturbed or merely failed to
> comprehend what a horrifying thing he just did.
> 
> On one hand, it means that
> 
>   x = y = z;
> 
> is a perfectly valid statement in C++. On the other hand, it also means
> that
> 
>   while (x[i] = y[i--]) ;
> 
> is perfectly valid. You sick, sick people.

It came from C. Put the blame on C.

> 
> Apparently every R-value is an L-value, but not vice versa. Which is
> fair enough, I guess.
> 
> In most programming languages, performing division promotes integers to
> reals. But not in C++, apparently. (Again, it is unspecified exactly how
> integer division works. Whether the author actually doesn't /know/ how
> it works or merely thought it unimportant is unclear.)

Operation on integers are perform with integers.
Integer division is performed as usual: 14/5 is 2.



> At this point, we
> are told that there's two ways to convert something to an double:
> 
>   double x = (double)y;
> 
>   double x = static_cast<double>y;
> 
> Apparently the former is bad, and the latter is good. No indication as
> to why, it just is.

cast is bad. Cast with () is bad.
Cast with static_cast<> is bad also, but at least you know it.
(it's bad by design: if you need a double, pass a double)

I'm in favor of calling the constructor instead... but you have not seen
that yet.

  double x(y);

> This being C++, some insane wacko
> thought that having c++ and ++c would be a good idea, and wouldn't be
> confusing in any way.

They are just explaining C so far.

> 
> Next we learn that false=0, and true /= 0. (Christ, I'm /never/ going to
> remember that!) Apparently there's a new bool type, but details are thin
> as to what the exact significance of this is.

Once again, C did not had bool, C++ has.

> 
> Then we learn about if/then, if/then/else, and finally ?: is
> demonstrated, without once mentioning how it's different from
> if/then/else. (I.e., it only works on expressions, not statements. Oh,
> but wait! Silly me, statements /are/ expressions...)

not really. expression becomes statement when you push a ; at the end.

And now for a mad trick: if you follow an expression with a , (comma),
its value will be replaced by the expression after the comma...
you only need one statement per block. so you can do dirty mad function
like:

int foo()
{
  return bar(),zoo()?kel():azbe(),foobar();
}

And it works in assignment & tests too...
> 
> 
> 
> Day 5 begins by explaining, all over again, what functions are, why
> that's useful, and how you use them. We learn how to pass values in, and
> return results out. So... /why/ did we need this in day 2, in half as
> much detail and then never used again?
> 
> Apparently every function must be declared before it can be used. (This
> constantly trips me up...) It seems a function prototype doesn't need to
> include argument names, just their types. (If only Java was like this!)
> Bizarrely, if you don't specify a return type, it defaults to int. Not,
> say, void. :-o

yep. C++ is maniac: you must provide the prototype before using the
function.
You can have the parameter's names in the prototype if you like.


> There's a side-box that shows you the syntax for a function prototype
> [even though the text already explained this]. But, for reasons unknown,
> the diagram /actually/ shows a normal function definition, but with a
> stray semicolon at the end of the prototype... In short, somebody seems
> to have got their stuff mixed up.

Nop.

int main(int,char**); // is enough for the compiler
int main(int argc, char** argv); // is more similar to the definition

Both are ok.

> 
> It appears that in C++ it is legal for a function to overwrite its
> arguments. In fact, there's an example of implementing a swap()
> function, to demonstrate that it completely fails to swap its arguments
> in the caller. Having done an extensive demonstration to call our
> attention to this fact, we learn that we won't be told how to write
> swap() correctly until day 8. Thanks for that. Couldn't you have brought
> this example up, say, on day 8?
> 
> It seems that C++ allows variables to be declared anywhere inside a
> block, and that variable is then local to the inner-most block. (Not
> that the text says it this clearly.) And it appears that nested
> functions are not allowed. Which is fine.

Variable can be declared anywhere. including in a for() parentheses.
They are usable from their declaration down to the end of the
inner-block that contained them.
(in the case of the for(), they can be used inside the () and the {}
block of the for, but not further)


> 
> Then we learn about global variables. Apparently if you write a variable
> outside of any block, it's global. No word on exactly when it's
> initialised, or precisely what "global" actually means. For example, I'm
> /guessing/ the variable is only in-scope /below/ the line where it's
> defined. That's how functions work, after all.

Global variables are either scoped by the file in which they are (static
prefix), or to the whole program.
(you haven't seen namespace yet).
Their position is irrelevant, but it's like prototype and declaration:
you need the prototype before using it. The declaration of a global
variable can also be used as its prototype, but you can only have one
declaration.

prototype (at head or in a header file):
int foo;

declaration (anywhere, usually at head to avoid a prototype):
int foo=5;



> So now you understand why global variables are bad, right?
> 
> No, I didn't think so.

> Seriously. It's /slightly important/ to understand why using a global
> variable is a bad idea. This is basic bread-and-butter programming
> knowledge. Way to completely fail to explain it. :-P



> 
> Next, we learn that function arguments can have default values. But get
> this:
> 
>   "Any or all of the function's parameters can be assigned default
> values. The one restriction is this: If any of the parameters does not
> have a default value, no previous parameter may have a default value."
> 
> ...um, what?

In foo(a,b,c,d,e), if you do not provide a default value for c, you
cannot provide one for either a or b.
At one point in the argument list, you must start providing default
values, for all argument at the right of that point.

> 
> So you're saying that you can freely choose which ones have defaults,
> except that if a parameter doesn't have a default, nothing to the left
> can either?

Yes.

> 
> So, aren't you basically saying all of the non-default parameters have
> to come before all of the default parameters? That doesn't sound like
> "any or all of the function's parameters can be assigned default
> values". That sounds like the parameters are split into two chunks. Why
> not just /say/ that? :-P

Because, in usage, with the strong typing of C++, you might nevertheless
provide some arguments and get the default values for others.

foo(a,b,d) might be possible (with a prototype of foo(a,b,c=,d=,e=); )
as long as the type of d is not related to the one of c (but it's more
complex, due to internal type promotion by the parser)

(you should understand "foo(a,b,c,d,e)" as "foo(type_a a, type_b b,
type_c c, type_d d, type_e e)", and so on for the default)

Post a reply to this message