New C++ Tutorial
Will Fitzgerald
I've created a short C++ tutorial, aimed at people who already have
experience with an object-oriented programming language (like Java or
Python).
It's at: http://www.entish.org/realquickcpp/
I'd be glad to hear of any feedback.
Will Fitzgerald
Gianni Mariani
I had a quick skim.
Look good !
Thanks
G
Default User
I couldn't tell, none of your links work in Mozilla or NS. With a
simplistic page like that, having such poor markup is a very poor idea.
It's just as easy to get it right.
Brian Rodenborn
Kevin Goodsell
After a quick look I only found a few errors.
[quote]
When the #included file is given as a string, the definitions are looked
for locally (usually in the same directory)
[/quote]
It is *not* a string. It just happens to look similar to a string
literal. They are quite distinct.
[quote]
#ifndef _UnigramTextClassifier_H_
#define _UnigramTextClassifier_H_
[/quote]
_UnigramTextClassifier_H_ is a reserved identifier. In general, I
recommend never beginning any identifier with an underscore, since such
identifiers are reserved in many contexts and the exact rules are
complicated.
Also, it uses the term "method" where the correct term is "member
function" and uses var++ where ++var would be preferable.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.
Gianni Mariani
That's funny, I use moz and it worked fine for me.
What did you do ?
Kevin Goodsell
Worked fine for me in Mozilla Firebird.
However, I was not able to validate it:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.entish.org%2Frealquickcpp%2F
Apparently no character encoding is specified.
Christoph Rabel
> Default User wrote:
>> I couldn't tell, none of your links work in Mozilla or NS. With a
>> simplistic page like that, having such poor markup is a very poor idea.
>> It's just as easy to get it right.
>
> That's funny, I use moz and it worked fine for me.
>
> What did you do ?
e.g. on the page:
http://www.entish.org/realquickcpp/memorymgt.html
The link
http://www.entish.org/realquickcpp/classesetall.html
doesnt work at all.
cya
Christoph
Kevin Goodsell
>
> e.g. on the page:
>
> http://www.entish.org/realquickcpp/memorymgt.html
>
> The link
>
> http://www.entish.org/realquickcpp/classesetall.html
>
> doesnt work at all.
>
It "works" for me in the sense that it attempts to load the page. But it
404s.
Christoph Rabel
> It "works" for me in the sense that it attempts to load the page. But it
> 404s.
So, for you links that 404 work for you?
Please dont answer its a rhetorical question...
Christoph
Alf P. Steinbach
I just skimmed it and didn't see any obvious disinformation. Also, nice
readable layout. At least in Internet Explorer.
Incorrect:
* Macro symbols such as '_UnigramTextClassifier_H_' are reserved by
the implementation, and gives undefined behavior.
* You cannot put new things into namespace std, as you do with class
UnigramTextClassifier. The compiler may incorrectly allow it, but
that does not mean another compiler will.
Details:
* Why write "i++" when you can write "++i"?
Bad habit to learn.
* Why use _leading_ underscores in member names?
Bad habit to learn, especially since leading underscore followed by
uppercase letter (not that I saw one in your code, except for the
header guards) is reserved for the implementation.
* It's a good idea to put 'const' on methods that do not change the
observable state of an object.
Bad habit to learn not to do that.
Hth.,
- Alf
Pete Becker
>
> * You cannot put new things into namespace std, as you do with class
> UnigramTextClassifier. The compiler may incorrectly allow it, but
> that does not mean another compiler will.
>
The compiler correctly allows it. <g> The behavior of a program that
adds names to std is undefined, so the standard does not require any
particular behavior when that's done. In practice this isn't diagnosed,
because compilers use ordinary files for their headers, and when you do
that you can't easily tell whether it's the user or the implementation
that's adding those names.
So the advice is right: don't do that. Compilers may correctly reject
it.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Alf P. Steinbach
>"Alf P. Steinbach" wrote:
>>
>> * You cannot put new things into namespace std, as you do with class
>> UnigramTextClassifier. The compiler may incorrectly allow it, but
>> that does not mean another compiler will.
>>
>
>The compiler correctly allows it. <g>
I guess I earned that one... ;-)
> The behavior of a program that
>adds names to std is undefined, so the standard does not require any
>particular behavior when that's done. In practice this isn't diagnosed,
>because compilers use ordinary files for their headers, and when you do
>that you can't easily tell whether it's the user or the implementation
>that's adding those names.
I can. Some (all?) compilers don't. Simplest way would be to have a
boolean state reflecting the directory of the currently parsed code;
more sophisticated, to have all standard headers precompiled into some
kind of database; and so on.
I think the real reason why there's no diagnostic is that it would add
no real value to the compiler, while requiring some work to implement.
Pete Becker
>
> On Sat, 16 Aug 2003 18:16:56 -0400, Pete Becker <peteb...@acm.org> wrote:
>
> > The behavior of a program that
> >adds names to std is undefined, so the standard does not require any
> >particular behavior when that's done. In practice this isn't diagnosed,
> >because compilers use ordinary files for their headers, and when you do
> >that you can't easily tell whether it's the user or the implementation
> >that's adding those names.
>
> I can. Some (all?) compilers don't. Simplest way would be to have a
> boolean state reflecting the directory of the currently parsed code;
> more sophisticated, to have all standard headers precompiled into some
> kind of database; and so on.
But if anyone did that they'd get complaints that they were locking in
their own standard headers.
>
> I think the real reason why there's no diagnostic is that it would add
> no real value to the compiler, while requiring some work to implement.
>
Well, "some work" is in the eye of the beholder. It's far from trivial,
and, as you say, it adds no real value.
Alf P. Steinbach
>"Alf P. Steinbach" wrote:
>>
>> On Sat, 16 Aug 2003 18:16:56 -0400, Pete Becker <peteb...@acm.org> wrote:
>>
>> > The behavior of a program that
>> >adds names to std is undefined, so the standard does not require any
>> >particular behavior when that's done. In practice this isn't diagnosed,
>> >because compilers use ordinary files for their headers, and when you do
>> >that you can't easily tell whether it's the user or the implementation
>> >that's adding those names.
>>
>> I can. Some (all?) compilers don't. Simplest way would be to have a
>> boolean state reflecting the directory of the currently parsed code;
>> more sophisticated, to have all standard headers precompiled into some
>> kind of database; and so on.
>
>But if anyone did that they'd get complaints that they were locking in
>their own standard headers.
Directory check would be easy to make configurable, and for any usable
compiler would have to be configurable anyway (otherwise the compiler's
headers would always have to be installed in the same place); for the
idea of precompiled standard headers, simply offer the precompilation
tool to the compiler user; and so on.
Pete Becker
>
> Directory check would be easy to make configurable, and for any usable
> compiler would have to be configurable anyway (otherwise the compiler's
> headers would always have to be installed in the same place); for the
> idea of precompiled standard headers, simply offer the precompilation
> tool to the compiler user; and so on.
>
Yup. Not easy.
Dave O'Hearn
> Gianni Mariani wrote:
> > Default User wrote:
> >> I couldn't tell, none of your links work in Mozilla or NS. With a
> >> simplistic page like that, having such poor markup is a very poor idea.
> >> It's just as easy to get it right.
> >
> > That's funny, I use moz and it worked fine for me.
> >
> > What did you do ?
That gives a 404 error. It isn't a browser issue.
--
Dave O'Hearn
Buster Copley
I'm not very impressed with the section on memory management. The
technique of pairing every 'new' with a 'delete' leads to memory
leaks if an exception is thrown between the two statements. A much
better way is use automatic variables whose destructors deallocate
resources. Sometimes std::auto_ptr is appropriate; otherwise you
can use the smart pointers provided by the boost library or write
'handle' classes specific to the kind of resource in question.
This technique, known as RAII (resource acquisition is initialization)
is an extremely important part of C++ programming. It works so well,
and makes resource management so much more predictable, that garbage
collection has become a dirty word (ok, two words) in some C++ circles.
Buster
Will, I didn't intend to mail this to you. I meant to post it to the
newsgroup. Sorry.
Will Fitzgerald
tutorial as a result. (A few more are still necessary).
-- Will