0

What I want to do is this:

#include <memory>

class autostr : public std::auto_ptr<char>
{
public:
    autostr(char *a) : std::auto_ptr<char>(a) {}
    autostr(autostr &a) : std::auto_ptr<char>(a) {}
    // define a bunch of string utils here...
};

autostr test(char a)
{
    return autostr(new char(a));
}

void main(int args, char **arg)
{
    autostr asd = test('b');
    return 0;
}

(I actually have a copy of the auto_ptr class that handles arrays as well, but the same error applies to the stl one)

The compile error using GCC 4.3.0 is:

main.cpp:152: error: no matching function for call to `autostr::autostr(autostr)'
main.cpp:147: note: candidates are: autostr::autostr(autostr&)
main.cpp:146: note:                 autostr::autostr(char*)

I don't understand why it's not matching the autostr argument as a valid parameter to autostr(autostr&).

Georg Fritzsche
  • 97,545
  • 26
  • 194
  • 236
fret
  • 1,542
  • 21
  • 36
  • I don't actually use stl at all, but I have co-opted the auto_ptr class for my own uses. – fret May 26 '10 at 05:08
  • @fret: Sorry, I deleted on you when I posted an answer. If you're programming in C++, why not use the standard library? What purpose is there re-implementing things, if not to waste time and introduce bugs? :/ – GManNickG May 26 '10 at 05:09
  • I'm learning C++ and I'd like to know what you're trying to do here. It seems interesting. – dreamlax May 26 '10 at 05:21
  • @dreamlax: I've been using something like "typedef auto_ptr autostr" (but with array handling, i.e. delete[]), for ages now and it's proving to be great for memory management. So I thought to myself... wouldn't it be great to hang a whole bunch of string utils off that typedef. Things like 'upper' and 'lower' and 'split(delims)'. Yeah... well that didn't go so great hehe. – fret May 26 '10 at 05:34
  • 2
    @fret: That's what `std::string` is for. :( – GManNickG May 26 '10 at 05:50
  • So you can inherit from std::string and add new member functions? I thought you said stl is not inheritable in general. – fret May 26 '10 at 06:01
  • 1
    @fret: I mean for memory management. By the way, free functions are to be preferred over member-functions in modern C++ code. There's really no need to inherit, to extend (just think of all the instances you need to change your code to get new functionality!) I could go on and on about the benefits of free functions, but to summarize, they: apply to anything that fits the mold (reusable via templates), are non-intrusive, and increase encapsulation. See also http://punchlet.wordpress.com/2009/12/29/letter-the-fifth/ – GManNickG May 26 '10 at 06:06

1 Answers1

1

The autostr that is returned from the function is a temporary. Temporary values can only be bound to references-to-const (const autostr&), but your reference is non-const. (And "rightly so".)

This is a terrible idea, almost none of the standard library is intended to be inherited from. I already see a bug in your code:

autostr s("please don't delete me...oops");

What's wrong with std::string?

GManNickG
  • 494,350
  • 52
  • 494
  • 543
  • So I'm screwed in other words? As soon as that auto_ptr becomes const it's almost un-usable. I wasn't aware of that rule. – fret May 26 '10 at 05:10
  • @fret: You can do what `auto_ptr` does, and introduce a utility class (`auto_ptr` has `auto_ptr_ref`) who's only purpose is to allow functions to return `auto_ptr`'s. But I'd hate to give a solution when the problem is in the design. – GManNickG May 26 '10 at 05:14
  • Yeah I understand that, I thought this implementation would actually use the auto_ptr_ref without having to copy it. My probably mistake belief is that stl will add a lot of bloat to my application in terms of download size. I'll revisit that and do some actual metrics this week to convince myself one way or another. I do have to be careful because I target VC6+VS2010/Win32, GCC/Linux and GCC/Mac all at the same time. – fret May 26 '10 at 05:22
  • @fret: Download size where? By the way, there is no "STL", there's the "Standard Library", STL is a misnomer. And the standard library is just that; standard. Every compiler you use (worth salt) with come with a (heavily tested and optimized) standard library, and I know GCC and VC do. You are guaranteed things about the behavior of the standard library, so you should feel free to use it; it's part of the language. – GManNickG May 26 '10 at 05:32
  • It's fairly well understood that the VC6 compiler's STL is buggy as hell. But there are other options out there, STLport etc. – fret May 26 '10 at 05:45
  • @fret: I didn't see you had VC6, sorry. VC6 is pre-standard and pretty terrible in general, why are you using it? – GManNickG May 26 '10 at 05:50
  • @gman: I like the speed on the IDE, haven't had issues with it really. But the writing is on the wall, which is why I've got my software building on VS2010 as well. But I get the grumpy users complaining that the VS2010 build is "twice" the size due to the CRT dll being part of the installer. Yeah it's 700kb or something, but thats what I'm dealing with. Other issues with 2010 are that I'm not going to buy the pro version (it cost how much! hahaha *gag*) and there is no standard version... so it's express for me and geez they killed the JIT debugging support. So I'm still if'y about it. – fret May 26 '10 at 05:56
  • @fret: You could still probably try CS2008, it lacks the subset of C++0x features VS2010 implements but is otherwise perfectly usable. Any new version is better than VC6. Sorry to hear you're getting complaints from people stingy about their enormous amount of storage. :) – GManNickG May 26 '10 at 06:04