如何应对3ds max SDK这类不支持const的非const感知类库/SDK？

我太懂这种糟心的感受了——用3ds Max SDK做开发久了，绝对会被它完全不重视const修饰符的设计逼疯！连Bitmap::Width()、Bitmap::Height()这种纯查询的方法都不标记为const，小项目里还只是偶尔膈应，到了大型项目里简直是埋雷，尤其是你提到的用shared_ptr<Bitmap>在多个类实例里共享同一个位图对象的场景，稍不注意就会踩莫名其妙的坑。

先聊聊核心痛点 #

这种设计最大的问题就是完全没有“只读访问”的安全性约束：当你拿着一个shared_ptr<Bitmap>只想做些查询操作时，SDK的接口根本不帮你把关是否会意外修改对象状态——哪怕你只是想获取宽高，编译器也没法帮你排查潜在的修改风险。在多人协作的大型项目里，这种无约束很容易导致某个模块不小心改了共享位图的状态，排查起来简直要掉头发。

几个可行的规避方案 #

我在项目里试过几种办法，分享给你：

• 封装只读访问器（最推荐）
  自己写一个轻量的ConstBitmapWrapper类，内部持有shared_ptr<Bitmap>，只暴露那些逻辑上应该是只读的方法，并且把这些方法标记为const。比如：

  class ConstBitmapWrapper {
  public:
      explicit ConstBitmapWrapper(std::shared_ptr<Bitmap> bmp) 
          : m_bmp(std::move(bmp)) {}
      
      int Width() const { return m_bmp->Width(); }
      int Height() const { return m_bmp->Height(); }
      // 其他你需要的只读方法，比如获取像素数据的只读接口
  private:
      std::shared_ptr<Bitmap> m_bmp;
  };
  

  这样在需要只读访问的地方，就传递ConstBitmapWrapper而不是原始的shared_ptr<Bitmap>，编译器直接帮你守住“不能修改”的边界，从根源上避免误操作。

• 团队代码规范约束
  如果暂时没时间写封装类，可以在团队内部明确约定：除非确实需要修改Bitmap状态，否则所有持有shared_ptr<Bitmap>的成员变量尽量用const std::shared_ptr<Bitmap>（注意这里的const是修饰指针本身，不是对象，但能减少无意的指针重赋值），并且调用接口时只碰那些逻辑上只读的方法。不过这全靠自觉，不如封装类靠谱，应急用用还行。

• 谨慎使用const_cast（下策）
  如果某些场景下你需要把非const的Bitmap指针传给一个期望const参数的函数，并且你能100%确认该函数不会真的修改对象状态，可以用const_cast做转换，但一定要加详细注释说明原因，不然后续维护的同事绝对会骂街。

总的来说，SDK的设计缺陷我们没法改变，只能通过自己的代码层做弥补，封装只读访问器是最稳妥的长期方案，能从编译层面避免很多不必要的错误。

内容的提问来源于stack exchange，提问作者user2328447