On 13/03/2012 03:56 PM, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> In common with all known IDEs, hitting the "new project" button creates
>> a project with /way/ more useless boilerplate code than you will ever
>> need.
>
>    Probably because you created a new *Windows* project, rather than a
> portabla command-line one.

Nope. I specifically requested "console application".

>    Dynamic binding, abstract classes, and even inheritance, are needed
> in practice significantly less often than one might think (especially
> if one comes from a background where that's basically the only way of
> doing anything).

Perhaps. Although in a sense, I'm not actually "interested" in building 
a specific application here, I'm interested in figuring out how 
inheritance and so forth actually works in C++.

> In the case of a huffman coder, I really
> don't understand what do you need abstract classes for. (There *is* such
> a thing as over-designing, when talking about OOP.)

The most obvious way to implement this is to physically build a binary 
tree. That requires either inheritance, or else doing something sly with 
unions. (Or even being /really/ dirty and just having one node type, and 
ignoring the unused fields.)

Now for the /encoding/ part itself, I don't actually need a physical 
tree. I have a vague recollection that last time I did this, I ended up 
cheating and just storing a vector of codewords, and manually munging 
that. It's a lot less elegant, but avoids dynamic allocation. (Or 
rather, no it doesn't, but it hides it in STL containers, so you don't 
have to do it manually.)

This application is just supposed to be the "warm up" for my next 
project, which will involve building complex expression trees. I really 
don't see how you can get away with no dynamic binding when each node 
type needs to be processed differently. Unless you go all non-OO and try 
to implement node type dispatch manually...

>    In many cases if you design your program such that you don't need
> dynamic binding, your program will often become more efficient in terms
> of both speed and memory usage.

I guess to some extent it depends on whether your goals are efficiency 
or maintainability. Certainly the code I'm trying to write will probably 
take milliseconds to execute, whichever way I implement it. If I was 
writing something high-performance, I might care about such things.

>    If you are an experienced, competent c++ programmer, each time you have
> to write the dreaded keyword 'new', it should give you a feeling of unease,
> and the instinctive desire to think of better alternatives.

Well, I did try to think of a way around it. But I failed to come up 
with a solution.

>    There are, of course, situations where 'new' is the only and best
> solution. For example, if you are implementing your own dynamic array
> (which has something that std::vector does not provide), then there's
> no problem. However, the usage of 'new' should in this case be tightly
> restricted to happen inside this dynamic array class, strictly controlled
> by it. Maximum encapsulation of the memory management is the key.

The problem is, I want to copy some data, but since I don't know what 
class it belongs to, I have no idea how big it will be. Presumably 
there's some way around that, but damned if I know what it is... Like I 
say, I need to find a more thorough reading resource that explains this 
stuff properly.

>    Now, writing a class that properly manages its dynamically allocated
> memory is a non-trivial task of its own.

Is that not just a case of allocating the memory correctly in the 
constructor, and freeing it properly in the destructor? (I mean, 
assuming nobody tries to copy the object or free its dynamic memory or 
anything like that...)

Post a reply to this message