 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Manual memory management?
Less necessary in C++ than in C, with all the container STL libraries
around. When you do need it, I find new and delete to be more intuitive than
malloc and free.
> Pointers vs references?
References are easier than pointers and there's not too much to learn to use
them. C only has pointers.
> Copy constructors and assignment constructors?
These can be difficult. They do mirror concepts used in C though.
> The macro preprocessor?
I think that's more of a C thing than a C++ thing, though it's available in
both.
> Method overrides that don't actually override unless you insert special
> code?
I'm with Warp on this one: what?
> Templates?
They can cause some difficulties. But they can make your life a lot easier
too (STL again).
> Untrapped numeric overflows?
I think C and C++ both have this property. In practice you barely ever have
to worry about it.
> Unchecked array indicies?
Also a C and C++ thing. If you want your array indices checked, and you're
using the std::vector class, you can use the vector.at(index) function. (In
practice though, I usually just add my own asserts.)
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>> I would say learning C++ is easier than C.
>>
>> Seriously,
Bunch of people have already answered, but I might as well add to the
mix. I'll just add that I made the statement comparing C++ with C. Many
of your complaints seem to be more along the lines of C++ vs <Some other
language>.
Keep in mind I'm not a C++ expert.
> Manual memory management?
Easier in C++ than in C.
> Pointers vs references?
References are easier. Use them unless you need a pointer.
> Copy constructors and assignment constructors?
OK. Perhaps a pain. I haven't dealt with this much elsewhere so I don't
know how bad it is.
> The macro preprocessor?
C++ was designed to minimize the uses of the preprocessor. I think it's
used for stuff like header guards, but off hand I'm not sure of any
other important uses (and would like to be educated...).
> Method overrides that don't actually override unless you insert special code?
Same amount of confusion as everyone else.
> Templates?
*Using* templates make life much easier. I haven't coded them much, so
I can't comment on that.
> Untrapped numeric overflows? Unchecked array indicies?
Same as in C.
I'll grant that C & C++ have their pains. Yes, as you said, the
programmer is expected to know what he/she is doing. But why do you
think you can't program that way? You'll be bitten a few times, and
you'll learn from those mistakes and not make them again later.
I'd never ask someone to do a project in C++ if Java/Python/something
else will do the job. However, knowing C++ has its benefits: Namely
getting a job. My assertion is that it simply is something you *can* learn.
Trust me, I know it's a pain with the wrong resources. I first tried
learning it over 10 years ago and had to deal with the compilers I had
on me not handling the very code in the book I was learning from. The
DOS C++ compiler would give an error. The Windows version would give me
a General Protection Fault (3.1 days) - both were Borland products. Very
discouraging. I wish I could find that book now to see if it was illegal
code.
Then when I was at university, they made me write everything in a text
editor (when I was used to a very helpful IDE for all my coding), and
use an "obscure" command line tool for compilation (g++). And what's
more, for some crazy reason, all my a.out files would be 700K - even a
simple "Hello world" program.
And I tried a number of times since then to learn it, always giving up.
Until, of course, the last time.
In retrospect, the reason was not that the problem was with me, but
with the resources: Bad tools and bad books.
If you do stuff with vectors, you generally don't need arrays. You
don't get a lot of the bugs that arrays provide. You don't need to know
the size of the vector at compile time. You can grow a vector. I believe
you can insert an element in the middle of a vector.
You probably don't need to use pointers and code your own linked list.
The standard library has it for you.
But yes, of course, if you want to know C++ well enough, you should
learn references and pointers.
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawaz org<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> 1) If you ever get the temptation of using the keyword 'new', don't.
> (And no, "malloc()" is not good either. See rule 3.)
Out of curiosity, how realistic is that? Can you give a scenario where
one *should* use new? (i.e. can't find a way around it).
> 2) If possible, avoid using pointers.
As in, use references instead?
> 3) If possible, avoid functions in the C standard library.
Amen.
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>> Dynamically allocated vectors, strings, doubly-linked lists, binary
>> trees
>> (as sets, multisets, maps and multimaps) and double-ended queues. None of
>> them requiring any pointers or 'new' to use. (The upcoming C++ standard
>> will also include hashmaps as a new data container.)
>
> Well that's something then.
That's what I was referring to when I said that most introductory C++
books written in the past either did not mention them or put them
somewhere at the end of the book.
In reality, you should use a vector instead of an array unless you have
a good reason not to. It includes a lot of the protections people look for.
In coding Python, I've used sets and maps a lot. I'm sure you use them
even more in Haskell. I sure wish someone had told me years ago that the
C++ standard library had them.
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Dynamically allocated vectors, strings, doubly-linked lists, binary trees
> (as sets, multisets, maps and multimaps) and double-ended queues. None of
> them requiring any pointers or 'new' to use. (The upcoming C++ standard
> will also include hashmaps as a new data container.)
What's a hashmap? Or rather, how does it differ from a map?
--
Lisa: Oedipus killed his father and married his mother.
Homer: Who payed for THAT wedding?
/\ /\ /\ /
/ \/ \ u e e n / \/ a w a z
>>>>>>mue### [at] nawazorg<<<<<<
anl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Orchid XP v8 wrote:
> >>> The macro preprocessor?
> >>
> >> You usually don't need it in C++.
> >
> > Well, from what little I've seen, you "usually" don't need it in C
> > either. Unless you want symbolic constants...
> const int FOO = 42;
Unfortunately that's not a compiler-time constant in C (although it is
in C++).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> >> (And that you can *query the size* of an array?)
> >
> > Getting the size of a vector, string, deque and binary tree is O(1).
> > (For doubly-linked lists it's not guaranteed.)
> And libstdc++ developers decided to keep list::size as O(n) as a tradeoff
> (otherwise mutating operations would have to keep the size up-to-date,
> making *them* slower).
It's perfectly possible to have an O(1) size() function *and* O(1) splicing,
with the only price to pay that immediately after a splice (one where the
list cannot know how many elements were spliced) size() becomes an O(n)
operation once (but O(1) in subsequent calls).
I really don't understand why standard library developers are not doing
that. I have been studying the problem and can't see any rational reason
not to do that. Some sacrifice the speed of size() to get a constant-time
splice(), others do the other way around, but I have never heard of an
implementation like the one I describe, even though it's perfectly
possible. It's not only possible, it's rather trivial to do. (I have even
tested it myself in practice. There's no problem with it.)
Go figure.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> What's a hashmap? Or rather, how does it differ from a map?
Its usage is otherwise the same as a map, but the order of the elements
is undefined (in other words, if you traverse the hashmap from begin() to
end(), it returns the elements in an unspecified order). It will be called
std::unordered_set and std::unordered_map.
The difference is that it will use a hash table rather than a binary tree.
In most cases it considerably reduces memory usage and can potentially be
much faster. (On the downside you have to be able to come up with a
high-quality hash function for your elements. A poorly designed function
can make the hash map very slow.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mueen Nawaz <m.n### [at] ieeeorg> wrote:
> Warp wrote:
> > 1) If you ever get the temptation of using the keyword 'new', don't.
> > (And no, "malloc()" is not good either. See rule 3.)
> Out of curiosity, how realistic is that? Can you give a scenario where
> one *should* use new? (i.e. can't find a way around it).
I don't know about "should", but there are certainly situations where
there's no way around it, so it's a "must". For example if you want to
write a special dynamic data container not offered by the standard library.
There are also situations where you have to allocate dynamically some
object because it cannot be a direct member variable of a class (eg.
because it doesn't have a default constructor and the constructor
parameters cannot be known when the outer class is constructed, but
only later).
In the latter case it's often a good idea to use some type of smart
pointer (or, alternativaly, forbid the copying/assignment of the outer
class, although that's not always an option).
> > 2) If possible, avoid using pointers.
> As in, use references instead?
Mostly. (Althoug it *is* possible to misuse references. Just not as
easily.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <fak### [at] emailaddress> wrote:
> > As I say, the trouble is that if your program doesn't work, there is no
> > way you can ever find out why.
> Honestly, binary search with prints works in a lot of cases. If you know
> what the program is supposed to do, then you can identify the places it does
> something wrong.
Often a good debugger is easier to use than having to write those prints.
(OTOH debugger breakpoints aren't always the solution either...)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
