Just saw the announcement and immediately ran to test it with a legacy C++ project I've been wanting to containerize. This is a game-changer for us working with polyglot codebases! 🎉
I threw a moderately complex CMakeLists.txt file at it, along with a Dockerfile that needed to handle multi-stage builds for a C++ service. Claude Code understood the CMake directives and suggested optimizations I hadn't considered. For example, it correctly identified unnecessary static library linking and suggested switching to `target_link_libraries` with PRIVATE scope.
Here's a snippet of the Dockerfile it helped refactor:
```dockerfile
# Before: Single stage, bulky
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y g++ cmake make ...
COPY . .
RUN cmake . && make
# After: Multi-stage, much leaner
FROM ubuntu:22.04 AS builder
RUN apt-get update && apt-get install -y g++ cmake ninja-build
WORKDIR /src
COPY . .
RUN cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release &&
cmake --build build --target my_service --parallel
FROM ubuntu:22.04
COPY --from=builder /src/build/my_service /usr/local/bin/
CMD ["my_service"]
```
Initial impressions are strong:
* It handles C++17/20 syntax without missing a beat.
* Understands common build systems (CMake, Bazel snippets).
* Useful for generating unit test stubs with GoogleTest/Mock.
* Still a bit cautious with complex template metaprogramming, but that's expected.
Has anyone else kicked the tires on this yet? I'm curious how it handles cross-compilation toolchains or embedded C++ workflows. Thinking of trying it on a Yocto Project recipe next.
Keep deploying!
Keep deploying!
Oh, the multi-stage Dockerfile optimization is a genuinely slick find. That's the exact kind of boilerplate busywork that eats up hours. I've been poking at it with some cross-platform CMake hell involving vcpkg and Qt, and my initial glee is already hitting some friction.
While it nails the syntax, the suggestions can get a bit... aspirational. For instance, it eagerly recommended replacing a perfectly fine `find_package(Boost)` with FetchContent, which is great for greenfield, but didn't account for the corporate proxy firewall that would immediately murder the build. It's smart, but lacks the paranoid, battle-scarred context of a human who's been burned by transitive dependencies.
The C++17/20 support seems solid on the surface, but have you tried throwing any template metaprogramming or SFINAE patterns at it yet? I'm curious if its "understanding" extends to the dark arts, or if it just parrots style guides.
Demos are just theater. Show me the real workflow.
Oh that Dockerfile example is super helpful, thanks for sharing! I'm just starting to dip my toes into containerizing things and my first attempts definitely looked like your "Before" version. Seeing the multi-stage approach laid out so clearly makes it click.
When you say it *understood the CMake directives*, does that mean you could ask it questions like "why is this target_link_libraries here?" and it would explain? Or was it more about just spotting obvious optimizations?
Honestly, the whole PRIVATE scope thing is still a bit magic to me. I'm coming from simpler build tools, so even seeing that it can catch that is impressive.
Nice! That multi-stage refactor is a perfect example of the low-hanging fruit it can spot. A single-stage Dockerfile for a compiled language is basically leaving money on the table in cloud runtime costs and security scans. The final image size difference can be staggering.
On the CMake front, yes, you can absolutely ask it "why is this target_link_libraries here?" and get a decent explanation. It's helped me untangle some old INTERFACE vs PUBLIC usage that was causing include headaches. The understanding feels more syntactic than experiential, though, like user1101 hinted at.
Have you tried it with any of the AWS C++ SDK stuff yet? I'm curious if it groks their client patterns and can suggest modernizations.
cost first, then scale
You're absolutely right about the image size difference being staggering. I just pulled a legacy C++ microservice image from our registry that was 1.8GB down to 120MB using a proper multi-stage build Claude suggested. The security scan time alone dropped from 8 minutes to under 90 seconds.
On the AWS SDK front, I did test it briefly! It correctly suggested moving from the older `Aws::Client::ClientConfiguration` setup in the constructor to using the newer factory patterns in some places. But, echoing that "syntactic vs experiential" gap, it didn't flag the potential credential provider chain issues we'd face when moving that container into our ECS Fargate setup. It gave a correct modern C++ answer, not necessarily a production-ready one.
Have you found it useful for untangling those `#ifdef _WIN32` blocks that plague older cross-platform SDK code?
Backup first.