Is it okay to use C++ new, delete in a plugin these days?

[Guest]

Are C++'s new and delete operators totally kosher, not a time bomb that'll crash for some user two months from now?   The documentation I found says to ask Photoshop for memory through an awkward API, but then all documentation and sample plugin code I've found so far are old.   In years past, I've worked in programming environments where one had to get handles and then get pointers - the old Win32 API comes to mind - but eventually the makers of such environments said to just go ahead and use malloc() and free(), or new and delete, and it was fine.  

Maybe it's likewise for the PS CS5 SDK?

I just finished developing a Format plugin for CS5 on 64-bit Mac, using C++.  (No 32-bit, no Microsoft, no older CS.)   It works fine, no crashes or complaints so far.   To facilitate processing, it allocates memory and objects using new during handling of formatSelectorReadStart and deletes it during formatSelectorReadFinish.   So it seems okay. But of course "it runs on my machine okay" is not sound reasoning.

[Tom Ruark]

Yes, it is ok to use new and delete.

It is recommended to use Photoshop memory routines for *large* memory requests.

Photoshop (via user settings in preferences) and the system have already had a discussion about memory usage and if you go and ask the OS for large amounts of memory you are more likely to run into thrashing and unhappy users. Having said all that, I see you are 64 bit mac! So thrashing is far less of an issue in that world.

We used to over ride new and delete in the SDK examples and that was a BIG mistake. As you cannot guarantee when the over ride occurs and if libraries are using new and delete your over ride and on and on and it is a true mess! Don't do it.

[Guest]

Very good, then.  Yeah, we're all 64 bit where I work.  We just don't use the number "32" anymore!   My memory requests are comfortably smaller than 1MB, so we are safe.

[Guest]

The way that PSCS SDK handling plug-ins is really old and very complicated unlike InDesign SDK Plugins.

[Chris Cox]

That could be because Photoshop predates InDesign by many years.

And it could be a design decision: Photoshop does not keep all plugins loaded at all times (load on demand), does not let unused plugins slow it down, tries to isolate the plugin as much as possible, tries to use specialized plugins so they do targetted things and go in specific places in the UI, etc.  Photoshop's plugins are also not locked in to the particular compiler and compiler version like InDesign plugins.

Photoshop's API is also rather simple compared to InDesign (40,000 APIs, of which maybe 8000 are documented).

And Photoshop has a few orders of magnitude more plugin developers than InDesign.

[Guest]

It is true that Photoshop SDK and InDesign SDK are in different "design" style. From software design point of view, InDesign SDK is well organized and much better than PSCS SDK. PSCS SDK is full of "c" code,  It even keeps "go to" sentence in its sample code.

For this topic, I think it is fine to use C++ new and delete for ones own operation. PSCS SDK uses a lot of Global Pointers, which is not good coding practice from C++ point of view.

[Guest]

Normally c code is hard to debug, especially under Mac XCode environment. Code on Windows seems fine for debug.

Too many aspects I need to learn from PSCS SDK.