"Greg London" <[email protected]> writes:
>> I missed the original question, but if OP (Greg?) can wait
>
> At the perl meeting, I mentioned that I'm using a lot of c++
> at work and groused that I haven't found a good
> "intro to c++" book.
>
Sounds to me like Accelerated C++ might be close to what you're looking
for. Perhaps you might also enjoy Design and Evolution of C++ for
justification of various features (though I wonder if you like the
language well enough to go there). Effective C++ also sounds like a good
choice for where you're at. Or maybe, though it's possibly a little
dated, Ruminations on C++. Personally, I preferred the latter. Scott
Meyers is very comprehensive, but, for me, to the point where I get a
little tired. IMO, Koenig strikes a better balance between covering
what's most important and covering every last little detail that may
trip you up (though I guess I've been burned often enough by the details
that maybe I should like Meyers better).
> I would like a book that introduces c and c++ from the
> point of view of showing the best practices first
> and comp-sci theory gets put in the second edition
> so I don't have to buy it.
>
> For example, unless I'm missing something fundamental,
> I don't see any reason to have parameters to a c++ function
> ever be a pointer. If I need an in/out, I pass by reference.
If a reference and a pointer each work equally well, I also prefer a
reference usually. But what about optional parameters? e.g....
void do_something(Connection *pConn = 0)
{
if (!pConn)
pConn = GetConnection();
...
}
I've seen other cases where I thought pointer seemed more natural,
though I can't remember them now exactly (I think they weren't only a
straightforward parameter, but had a class involved with a using
relationship or something where you'd want to emphasize you're pointing
to some external thing you don't own maybe). Even for a simple in/out
parameter, there's no consensus on which to use, though. Some C++
programmers really do prefer the ptr claiming it adds info at the call
site because maybe you have a & over there suggesting something along
the lines of what the parameter to scanf in C does.
OTH, there is consensus on how you use references when you use
them. e.g. a huge pet peeve of mine is when people use references for in
only parameters, as an optimization because the object passed is large,
and fail to mark the references as const, which, aside from suggesting
to you in the signature the argument is out or in/out instead of just
in, prevents you from passing temp objects to the function. I think
Meyers's book cures people of that kind of gaff.
>
> The sigils in c++ also seem to have some inconsistencies
> similar in flavor to the way perl has an array declared
> with @array and indexes into the array with $array[]
> but you can also have a scalar called $array.
sigils? You mean & vs. * on types? Not sure what you're thinking of
here. Certainly pointers and references are different things, if that's
what you mean. e.g. you only bind to a reference at initialization
whereas you can change pointer values whenever -- a reason why you might
need a pointer sometimes.
> For the life of me, I cannot wrap my head around the
> line noise that is c++ declaring a function or variable
> by putting all manner of line noise in the code.
All the type information, you mean? Maybe you could convince your
co-workers to switch to ML. In the mean time, if they'll at least go to
C++11 you can use the auto keyword in places for a limited amount of
type inference (though according to Sutter and Meyers there are
caveats).
>
> There's also the various and many flavors of a sequence
> of characters in c++. You could have an array of chars,
> a pointer to an array of chars, a std::string, a sstream,
> and I'll be DAMNED if c++ isn't designed so that not one of
> them will work in every situation.
>
> Most of my code is using std::string, but sometimes I need
> to convert to c_str() and sometimes I need to use streams
> and it just makes me want to gouge my eyes out.
Could be worse. Where I'm at we're still using a general purpose class
library that was popular in the 90s with its own string class in
addition to std::string and C style string handling (which people got
wrong in subtle ways nearly every chance they could). Then we also have
to deal with the various string classes you need to interact with MFC
and COM. And with COM there's both plain old C style versions and C++
template using ATL versions -- then you have wide char versions
vs. regular too and whether the BSTR you have came with the Pascal style
size in the position behind the first char or if it's been slammed into
an OLESTR and... oh I don't even want to think about that, never mind
the special allocation routines for those guys ... and strings hanging
out within VARIANT types, argh. Oh yeah, and these days we have to
support .NET of course so throw System::String into the mix. Be very
thankful if you don't have to learn C++/CLI btw. Woohoo, let's take a
large language and add a second large language to it, each with its own
class library, and with two implicit targets (native and managed)
possible simultaneously.
Still, I like C++. It's more being in a MS shop that bugs me a little. I
mean in modern C++ on Unix you should be mostly able to use std::string
except when interfacing to things needing char* I would think. Is that
really so bad? I mean, if you have to interface with char* in Perl,
it's what, xs, ffi, or swig. Is that fun?
> So, really, if the way to move text around is with strings
> then I'd like a book that starts out introducing strings
> and then later on, when some stupid exception to the rule
> comes up, it goes into char* or streams and explains the
> difference at that point.
Accelerated C++ at least will start you out with std::string and other
standard library classes where appropriate. Does the following review
excerpt sound promising?
"Whilst the full range of the Standard C++ Library is introduced early
and on a basis of need (and that includes early introduction of STL
containers, algorithms etc.) writing your own template types is just
covered lightly later on. I believe this is entirely correct. All C++
programmers should be using the tools provided by the language, but
designing types, particularly generic types is not a necessity, and
certainly not needed early on. The theme might be summarised as learn to
use the tools provided before trying to design your own tools."
http://accu.org/index.php?module=bookreviews&func=search&rid=1185
But you have to decide whether you want or need to care about C++11 or
not, cause I don't think Accelerated C++ for C++11 is coming, or at
least not soon. Personally, if I were taking the time now to brush up on
C++, I'd not want to ignore the new stuff (if you were learning Perl
now, would you want a book that doesn't mention say, smart match,
given/when, Moose, etc.). OTH, if your workplace is like mine, your
co-workers will never want to modernize their use of the language, so
knowing about C++11 might just be frustrating. I'm reminded of this a
little whenever I hear Perl programmers whinge about being unable to use
everything they know because work has a RHEL with a very old perl.
>
> That was the sort of book I was looking for.
> Probably doesn't exist because no one will agree on the
> best way to pass strings around in c++.
I think most people are in agreement that std::string (or in special
cases another string class) is the way to go except maybe in interfaces
where there are ABI or need to be called by C considerations or where C
library functions are especially handy.
- Mike
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
