Disclaimer
This is a very opinionated post based on my expirience for one particular project. I have not used the latest version of the coder, but I do have expirience with the equivalent product (embedded coder) for converting matlab code to C++ that was included as part of the former Real Time Workshop product. These comments should still apply. Your mileage may vary.
Early benefits...
In my situation, the embedded coder was used to make a processing block that fit into part of a larger audio application. The processing block had the job of processing a constant stream of sample buffers in real time. I made the original algorithm in matlab, and the conversion tool made it fairly simple to convert an early prototype into something that could be compiled to native code and used in a real time application. It was also nice to assume that the converted code was functioning numerically identically to the original without possibility of human error in the conversion process (assuming superhuman abilities of Mahworks engineers).
The benefits ended after this very early prototyping stage...
Problem 1: Wasting time interfacing
As the algorithm grew in complexity, i started worrying more and more about how to code the matlab interface to the function so that after conversion, it would be easy to interface with the C++ framework (I wanted to monitor the internal states in real time). This eventually started using as much time as the actual algorithm development itself, thus defeating the purpose of using such a tool. I could have broken down the algorithm into smaller chunks and then glued them together using C++, but then I'd loose the ability to have a direct Matlab-only comparison of he complete algorithm.
Problem 2: Not all functions are supported or supported fully
The coder supports a subset of the Matlab language. In some cases, supported functions are limited in some way. For example, in the application that I was working on, I wanted to be able to modify the characteristics of a filter in real time. I could not use the standard Matlab filter prototyping functions, because the code generation tool would not allow calls to the filter prototyping function with variable arguments. I ended up spending time with a DSP book developing my own implementation, even though we have a signal processing toolbox license.
Problem 3: Automatically generated code was inefficient
I got frustrated with the interface issues and coded the algorithm by hand in C++. For my application, there was a 75% performance boost in the favour of the hand written code over the converted code. Performance differences will be very different depending on your application, probably the version of the conversion tool used, and your fondness of your profiler. The conversion tool itself is a complex product that has many settings to learn. Trying to work out how to tweak settings and the matlab code to improve performance uses more time that could be spent hand coding.
I have not used the conversion tool since...
I now prefer a more test-assisted approach. I code a prototype in Matlab and tweak until I am sure that it behaves as I want it too. I then think in C++ and recode the algorithm in a way that is more natural to that language. I then make a mex file that interfaces with my C++ code so I can test it against my trusted matlab equivalent. For the problem space that I work in, this is a much more efficient (human and machine) way to get stuff done.
In conclusion, this is just the opinion of one user. Perhaps (as suggesred in a comment on your original post) you should sign up for the trial to see how you get along. However, if you are a bit of a C++ ninja, testing by building mex files does not require an expensive license for an add-on product and it will make you a better developer.
