• 13
• 14
• 27
• 9
• 9

# C++ without pointers

This topic is 424 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I get C and pointers very well. But I'm trying to use C++ ~without~ standard pointers. It's working for the most part, but now I'm running into an issue:

// MyInterface &something = MyDummyBase(); is defined in the header as a private member

void MyClass::SetSomething(MyInterface &newSomething) {
something = newSomething;
}

MyInterface &MyClass::GetSomething() {
return something;
}

Now here's where it gets weird, from the caller:

1. myClassObj.SetSomething(AnotherClass());

2. MyInterface &Value = myClassObj.GetSomething();

At line 1, it calls the constructor of AnotherClass (as expected), sets something to AnotherClass (again, as expected), then calls the destructor of AnotherClass (not expected)

At line 2, it returns MyDummyBase instead. There are no lines inbetween.

All I can think, is that it considers AnotherClass() out of scope now, and destroys it. But what confuses me is, how does it know to revert back to MyDummyBase? I'm trying to do the equiv of .SetSomething(new AnotherClass()), but without raw pointers.

I'm assuming I have to explicitly declare AnotherClass outside of the method, and use it directly in the SetSomething method, but what happened with this logic confounds me.

Any ideas?

 Nevermind... it's not a pointer, so it can only be set in the constructor. Dur...

Edited by LunaticEdit

##### Share on other sites

A) What did you expect to happen in case 1? Why did you expect the destructor to not be called?

B) For case 2 you've invoked assign/copy on the original object. How is that defined (explicit/implicit)?

##### Share on other sites

Yeah, I've done a lot of C so malloc/realloc/free is more natural to me than new/delete, and other C++y things. I also use C# a lot, which has GC, which is a very different beast. C++ feels like a weird middle of the road, not quiet C#, not quite C. I do realize references are pointers, as the only things that actually exist are 64 bit values (or smaller depending on the architecture). You can't actually represent "MyClass" as anything more than a pointer to a block of memory that contains atomic values (int/byte/etc) or pointers (struct/class/etc) as far as passing goes -- it just pushes a pointer to the object onto the stack before calling the method.

So I'll read up on smart pointers, but honestly at this point I might as well just stick with new/delete as it is closer to malloc/free that I'm used to.

Thanks guys!

Yup I switch to standard pointers where it makes sense. I'll use visual leak detector and keep an eye out on things!

Edited by LunaticEdit

##### Share on other sites

I get C and pointers very well. But I'm trying to use C++ ~without~ standard pointers. It's working for the most part, but now I'm running into an issue:

// MyInterface &something = MyDummyBase(); is defined in the header as a private member

void MyClass::SetSomething(MyInterface &newSomething) {
something = newSomething;
}

MyInterface &MyClass::GetSomething() {
return something;
}

Now here's where it gets weird, from the caller:

1. myClassObj.SetSomething(AnotherClass());

2. MyInterface &Value = myClassObj.GetSomething();

At line 1, it calls the constructor of AnotherClass (as expected), sets something to AnotherClass (again, as expected), then calls the destructor of AnotherClass (not expected)

At line 2, it returns MyDummyBase instead. There are no lines inbetween.

All I can think, is that it considers AnotherClass() out of scope now, and destroys it. But what confuses me is, how does it know to revert back to MyDummyBase? I'm trying to do the equiv of .SetSomething(new AnotherClass()), but without raw pointers.

I'm assuming I have to explicitly declare AnotherClass outside of the method, and use it directly in the SetSomething method, but what happened with this logic confounds me.

Any ideas?

 Nevermind... it's not a pointer, so it can only be set in the constructor. Dur...

1- Out of scope.

2- Inheritence.

You're using it wrong.

A) Nothing is wrong with pointers.

B) A better solution is using std::unique_ptr and std::shared_ptr rather than implementating everything with references (which isn't ideal for certian situations).

It does the memory managment you need, not like C# GC but it does deallocates the memory (No need for manual deletion).

C) Use them when an instance owns memory, but when you need to refernece , use a regular pointer. (The instance does not own the memory).

Edited by WoopsASword

##### Share on other sites
You don't need a pointers in C++ these days. But the biggest problem is the declaration of 'something;. It shouldn't be a reference, it should be value as you intend to rebind it with SetSomething. So remove the reference, and your code will work as expected.

##### Share on other sites

I also use C# a lot, which has GC, which is a very different beast.

If anything they're rather similar, in languages like C# and Java everything is basically a pointer(or acts just like one) maybe I should say pointer with training wheels because the GC handles de-allocation of memory so you can essentially let things go out of scope on a whim. You can get similar behavior in C++ by using smart pointers, but obviously you have to take care of what you're doing.

So I'll read up on smart pointers, but honestly at this point I might as well just stick with new/delete as it is closer to malloc/free that I'm used to.

You're never going to take advantage of the features of a language by just trying to treat it like another language. That'd be like being used to drifting so when you switch to driving a bus you try to drift everywhere. Not super productive.

Smart pointers are a relatively new feature(at least in the standard library) or at least the good ones we have now are. But they're pretty simple to use, unique_ptr can be just thought of as changing the lifetime of a pointer to be just like a stack variable, as soon as it goes out of scope the memory gets freed with it. They're mainly important in C++(besides being nice to use) because C++ has a lot of corner cases with exceptions where things can be left dangling without careful planning. Placing all that load on the destructor means(in every case I can think of anyway) the memory gets freed even if everything comes crashing down. Edited by Satharis

##### Share on other sites

Sounds like you're avoiding new and delete for some reason I don't quite understand. New and delete are just malloc and free wrapped under the covers. If Malloc and free may seem more natural to you, keep using them, you're going to have a difficult time avoiding heap allocation altogether. Or switch to java, you can new objects all over the place and not worry about deleting them.

##### Share on other sites

Sounds like you're avoiding new and delete for some reason I don't quite understand. New and delete are just malloc and free wrapped under the covers. If Malloc and free may seem more natural to you, keep using them, you're going to have a difficult time avoiding heap allocation altogether. Or switch to java, you can new objects all over the place and not worry about deleting them.

Do not use malloc and free on C++ objects, as the constructors and destructors will not be called.

Technically you can malloc the memory and then placement-new the object into the memory - assuming correct alignment - and then manually call the destructor before calling free - but why go to all that trouble when new and delete do it correctly with less typing? There are valid use cases for placement-new and manual destructor calls, but most people won't run into them in normal coding.