Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Pointers to members?
> 
>   You don't need them.

That's what I was pretty much hoping, yeah.

Looks like it would only be useful for some pretty obscure situations...

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> Copy...constructor...? x_x
> 
>   Usually you don't need copy constructors unless you have pointers as
> member variables of your class and you explicitly allocate memory to
> them with 'new'. But we don't do that, do we? ;)

Heh. I get the impression that most of the stuff I'm reading about now 
is stuff that "you won't normally need". ;-)

(E.g., apparently you can overload the "->" operator... GAH! >_< OK, I 
am *so* not trying that out!)


Anyway, the main reason I haven't written a Third C++ Program yet is 
that I'm trying to think of something I actually want to write that's 
implementable without automatic memory management...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Pointers to members?
> > 
> >   You don't need them.

> That's what I was pretty much hoping, yeah.

> Looks like it would only be useful for some pretty obscure situations...

  They are useful in certain situations, but those situations are so rare
and usually so advanced, that even very experienced C++ programmers basically
never need them.

  I once created a command-line parameter interpreter which was used like
this (extremely simplified):

class MyCLI: public CommandLineInterpreter
{
    void inputFile() { ... }

 public:
    MyCLI()
    {
        // registerCLParameter() is a function in the base class.
        registerCLParameter("input", &inputFile);
    }
};

  Basically this meant that when the interpreter encountered the command-line
parameter "-input", it would call the 'inputFile()' method I defined above.
This uses method pointers.

  (The actual implementation is quite complicated because there are some
issues about a base class calling a derived class method through a method
pointer, but with template magic it's possible to do this portably and
safely.)

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> wrote:
> >> Copy...constructor...? x_x
> > 
> >   Usually you don't need copy constructors unless you have pointers as
> > member variables of your class and you explicitly allocate memory to
> > them with 'new'. But we don't do that, do we? ;)

> Heh. I get the impression that most of the stuff I'm reading about now 
> is stuff that "you won't normally need". ;-)

  It's not like you don't need copy constructors (and copy assignment).
It's just that a beginner doesn't usually need them. When you start needing
copy constructors, your code will be a bit more advanced.

> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I 
> am *so* not trying that out!)

  You can overload almost any operator, including 'new' (it's considered
an operator in C++) and the prefix-&.

  I think the only operator you can't overload is the dot operator.

> Anyway, the main reason I haven't written a Third C++ Program yet is 
> that I'm trying to think of something I actually want to write that's 
> implementable without automatic memory management...

  Hmm, is that sentence correct? Everything is implementable without
automatic memory management. Perhaps you meant something else?-)

-- 
                                                          - Warp

Post a reply to this message

>> Heh. I get the impression that most of the stuff I'm reading about now 
>> is stuff that "you won't normally need". ;-)
> 
>   It's not like you don't need copy constructors (and copy assignment).
> It's just that a beginner doesn't usually need them. When you start needing
> copy constructors, your code will be a bit more advanced.

Well, yeah. And *I* am unlikely to be writing anything "advanced" any 
time soon! ;-)

>> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I 
>> am *so* not trying that out!)
> 
>   You can overload almost any operator, including 'new' (it's considered
> an operator in C++) and the prefix-&.
> 
>   I think the only operator you can't overload is the dot operator.

And .* (apparently).

Also, unlike Haskell, you apparently can't make up new operators of your 
own, just overload the ones that already exist.

>> Anyway, the main reason I haven't written a Third C++ Program yet is 
>> that I'm trying to think of something I actually want to write that's 
>> implementable without automatic memory management...
> 
>   Hmm, is that sentence correct? Everything is implementable without
> automatic memory management. Perhaps you meant something else?-)

Well, yeah, but it's a touch harder to implement heap-allocated data in 
such a way that your program doesn't leak like a sieve. ;-)

[I'm actually surprised that using std::vector doesn't do this already...]

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Also, unlike Haskell, you apparently can't make up new operators of your 
> own, just overload the ones that already exist.

  Aren't C++ compilers already stressed enough? Think about all the problems
they would have with user-defined operators, with their own precedence
rules, ambiguous situations, etc... :P

> Well, yeah, but it's a touch harder to implement heap-allocated data in 
> such a way that your program doesn't leak like a sieve. ;-)

  You usually use the STL data containers for dynamically allocated
memory, and if what you need is to allocate a single object, you can
use a smart pointer (I posted in the other group an URL to one smart
pointer implementation I have made).

> [I'm actually surprised that using std::vector doesn't do this already...]

  Doesn't do what?

-- 
                                                          - Warp

Post a reply to this message

>> Also, unlike Haskell, you apparently can't make up new operators of your 
>> own, just overload the ones that already exist.
> 
>   Aren't C++ compilers already stressed enough? Think about all the problems
> they would have with user-defined operators, with their own precedence
> rules, ambiguous situations, etc... :P

Heh, yeah... I can see that. ;-)

>> Well, yeah, but it's a touch harder to implement heap-allocated data in 
>> such a way that your program doesn't leak like a sieve. ;-)
> 
>   You usually use the STL data containers for dynamically allocated
> memory, and if what you need is to allocate a single object, you can
> use a smart pointer.

Fair enough.

>> [I'm actually surprised that using std::vector doesn't do this already...]
> 
>   Doesn't do what?

Leak like a sieve! ;-)

I've never actually seen a programming environment with manual memory 
management *and* dynamically resizable collections. The two are usually 
muturally exclusive.

Then again, I'm not really sure what the story is if you try to put 
user-defined data types into a vector...

Post a reply to this message

Invisible wrote:

> 
> (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I 
> am *so* not trying that out!)
> 

Useful for the "Smart Pointer" pattern. The autogen stuff for COM uses 
these a lot.

-- 
~Mike

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >> [I'm actually surprised that using std::vector doesn't do this already...]
> > 
> >   Doesn't do what?

> Leak like a sieve! ;-)

  The class constructors, assignment and destructor help in automatizing
the internal memory management of the vector.

  You can write your own dynamic data container as a class in the exact
same way as std::vector and the other STL containers, which will be safe
and will automatically manage its memory.

  And not only memory. There are also other resources which can be
automatically managed with classes. Consider this:

void foo()
{
    std::ofstream os("outfile.txt");
    os << "Hello\n";
    bar();
    os << "there.\n";
}

  Note that nowhere is the file actually explicitly *closed*. However,
no open file handles are leaked because it gets closed automatically
because the std::ofstream class handles this resource.

  This is even so even if the function is exited abnormally. For example,
assume that the bar() call throws an exception. If that happens, the
function will be exited immediately (before the "there.\n" string is
written to the file). This is "unexpected" and we didn't take that
possibility into account. However, it doesn't matter: The file will
still be closed and thus no resource leak happens.

  Unless I'm completely mistaken, this is not something you can achieve
in Java. (In Java you have to close files explicitly and catch all
possible exceptions which might otherwise bypass that closing.)

> I've never actually seen a programming environment with manual memory 
> management *and* dynamically resizable collections. The two are usually 
> muturally exclusive.

  Well, it's not like *all* resources in C++ are managed manually.
More precisely, stack-allocated objects are managed automatically. Which
is exactly the reason why automatic management heap-allocated objects
becomes possible through these stack-allocated objects.

> Then again, I'm not really sure what the story is if you try to put 
> user-defined data types into a vector...

  If the user-defined type doesn't allocate memory in itself, or if it
does but manages it properly, there shouldn't be any problems.

-- 
                                                          - Warp

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Invisible wrote:

> > (E.g., apparently you can overload the "->" operator... GAH! >_< OK, I 
> > am *so* not trying that out!)
> > 

> Useful for the "Smart Pointer" pattern. The autogen stuff for COM uses 
> these a lot.

  Also used with iterators. (An iterator is an object which behaves
like a pointer.)

-- 
                                                          - Warp

Post a reply to this message