This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(102.4, 21%, 19%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EM%3C/text%3E%3C/svg%3E)
Does development continue in ATL for Visual Studio/C++ 2022? If writing a new service on native OS, is this technology a preferred recommendation?
Yes, ATL is supported in visual studio 2022. It continues to be an effective tool for working with COM in C++.
Having said that, without knowing more about what you mean by "a new service on native OS" I can't suggest whether or not ATL would be suitable in your circumstance.
I'm working on a project to refactor a Windows service that I wrote some time ago (basically an overlay network). It was written in a mixture of c++ libraries and technologies. I'd like to reduce the number of libraries and concepts and ATL was one of the libraries I used in past (specifically for the Service but used collections, critical section and smart pointer classes, and a few others). What I'm trying to figure out is if I continue to use ATL for these types of items that or the ones in the c++ standard now for concepts like strings, smart pointers, mutex for example. I'm not concerned about any cross-platform capabilities because I'd like to use Windows capabilities like native thread pool, registered I/O.
The other piece to this is that I'd like to create some type of pipeline concept where I can use free threaded com objects possibly to add capabilities to the processing of packets (as an idea, not sure if it's best route to take). This would seem to make ATL a good choice too in developing the pipeline and the stages loaded into it.
Hope this helps in clarifying my intent and any further suggestions will be welcomed.
I assume that the collections in the Standard C++ Library would perform better than similar ATL collection classes. Same assumption for the string classes although CString provides convenience methods without equivalence in the string/wstring classes. Of course, some performance measurements to validate such an assumption would be appropriate. ATL smart pointers (CComPtr/CComQIPtr for interfaces, CComHeapPtr for memory management) are specifically designed for COM. I doubt there wold be much to gain by replacing them with customizations of unique_ptr.
By the way, the Microsoft Best Practices guidance at https://learn.microsoft.com/en-us/windows/win32/procthread/thread-pools says -
"Avoid the COM single-threaded apartment model, as it is incompatible with the thread pool. STA creates thread state which can affect the next work item for the thread. STA is generally long-lived and has thread affinity, which is the opposite of the thread pool."
You can see that some ATL fixes can be found in VS 2022, like : Visual Studio 2022 version 17.0.5
And from MSDN, older article, but same thing in 2022 : MFC and ATL
In Visual Studio 2017 and later, MFC and ATL are optional sub-components under the Desktop development with C++ workload in the Visual Studio Installer program. You can install ATL support without MFC, or combined MFC and ATL support (MFC depends on ATL).