 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I prefer the Eiffel way, where the compiler looks at your program and
>> automatically decides which things can be bound statically (with all the
>> optimisations that follow), and which things actually require dynamic
>> binding.
>
> That's incompatible with precompiled and dynamically loadable libraries.
It's certainly incompatible with dynamic loading. I don't see a problem
with precompiled code though. (Provided the precompiled code isn't just
a blob of executable data but actually contains enough metadata.)
> I have always wondered why so many "fancy" languages seem to completely
> disregard the idea of dynamically loadable libraries.
Because it's a tricky thing to get right? IDK.
Certainly the Java guys love to scream and shout about how easy this is
in Java. Which is amusing, because actually it *isn't* especially easy.
You still have to write a heap of code yourself to make this possible...
As an aside... does anybody here know anything about how Windoze DLLs
actually work?
>> Does it actually build a seperate copy of the function for each data
>> type, or just build one generic version that works with all of them?
>
> How could it use one generic function for all possible data types,
> given that the data types can have different sizes and even have completely
> different implementations for their operators, etc?
Plain ordinary OOP manages to do this without difficulty. (Argue
amoungst yourselves about how *efficient* it is, but it works.)
> One common misconception people have about templates is that they
> increase the size of the executable because the functions are created
> for each used type. However, this is only true in some cases.
>
> If they were template functions, however, the ones which are never
> called are never instantiated.
>
> Inlining can also help reducing the size of the executable, besides
> making the program faster.
>
> The great thing about templates is that the compiler is able to optimize
> the code on a per-type basis.
...so templates are like a kind of less-stupid macro expansion system?
(Everybody *talks* about how great templates are, or how much templates
suck, but few people ever say what they *are*.)
>>> Yes, debug checks are nice. They are nicer if you can turn them off
>>> for a final release.
>
>> There is certainly something to be said for that.
>
>> The problem is that, certainly with C anyway, there's no switch to turn
>> it ON in the first place. :-(
>
> It depends on the compiler. Some compilers do insert checks in debug
> mode.
Mmm, OK. Well my only experience with writing C is Borland's C compiler
for MS-DOS. (Actually, that's a lie. It was a C++ compiler, but we only
wrote C.)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
