0

I have this code

class GameViewModel
{
public:
    GameViewModel(PlayerData& playerData, std::unique_ptr<WeaponData> WeaponData) : m_playerData(playerData), m_WeaponData(std::move(WeaponData)){}

    PlayerData& GetPlayerData() const { return m_playerData; }
    // I want to do:
    //void SetPlayerData(PlayerData playerData) { m_playerData = playerData); }
    WeaponData& GetWeaponData() const { return *m_WeaponData; }
    
    bool IsVisible() const;
    int GetColour() const { return m_playerData.m_Envelope.GetColour(); }

private:
    PlayerData& m_playerData;
    std::unique_ptr<WeaponData> m_WeaponData;
};

I'd like to update the member variable m_playerData, (see SetPlayerData) but I get a C2280 attempting to ref a deleted function. I need to define my own move constructor and move assignment. I've looked at: Copy constructor for a class with unique_ptr but how do I initialize m_playerData in the move constructor?

Sergioet
  • 1,108
  • 13
  • 27
  • 5
    You can't set references. Full stop, end of story. If you want to be able to set it, you should consider changing the reference into a pointer (`PlayerData*`) – user253751 May 23 '22 at 14:41
  • 1
    Or a smart pointer like `std::unique_ptr` or `std::shared_ptr`. Perhaps you can clarify why you wanted `m_playerData` to be a reference instead of a pointer like `m_weaponData` so that we can advise you better. – CompuChip May 23 '22 at 14:53
  • 1
    btw error codes are compiler specific, you should include the compiler error message – 463035818_is_not_an_ai May 23 '22 at 14:55
  • and thank you @CompuChip, yes that's probably the best way, the use of a smart pointer. – Sergioet May 23 '22 at 15:08
  • Smart pointers are not automatically better. If a player quits the game but the GameViewModel stays, do you really want the GameViewModel to keep the player around? (as opposed to probably causing a crash, so you notice the bug and fix it) – user253751 May 23 '22 at 15:13
  • @user253751 The same would happen without a smart pointer. If you aren't explicitly deleting it, a new'd object would also "hang around". Not using a smart pointer doesn't buy you anything in that scenario you described. And there is nothing wrong with explicitly deleting or releasing a smart pointer, so it still seems the better choice. – Taekahn May 23 '22 at 15:16
  • Another option is a `std::reference_wrapper` – davidhigh May 23 '22 at 15:26
  • @Taekahn presumably you would delete the PlayerData when the player quits the game – user253751 May 23 '22 at 15:31
  • @user253751 yea….which you can do with a smart pointer or a raw one. – Taekahn May 23 '22 at 15:48
  • @Taekahn the GameViewModel does not own the PlayerData. If you accidentally leave the GameViewModel around it probably shouldn't cause the PlayerData to stick around. – user253751 May 23 '22 at 15:49
  • @user253751 exactly the reason _to_ use smart pointers. `player*` says nothing about ownership. It may or may not own it. Smart pointers explicitly delineate ownership. I have nothing against raw pointers, but I see no reason to use them outside of specific scenarios when there are better alternatives. But comments aren’t the place for discussion so I guess we’ll just have to disagree. – Taekahn May 23 '22 at 15:57
  • @Taekahn What's the smart pointer that says you don't own something? – user253751 May 23 '22 at 16:10
  • Shared_ptr. Random link https://george3d6.medium.com/being-smart-about-ownership-5ba2569a3ed7 – Taekahn May 23 '22 at 16:21

0 Answers0