# How can I work on DSP using C/C++?

I have been working on MATLAB for signal processing for a while. Many companies from DSP for a communication background has asked me whether I know C/C++ very well. I am confused as to why the companies are using C/C++ for signal processing. Why not work with MATLAB as it has all the libraries/toolbox available and is also easy to use? I would just like to know how C/C++ fits into the the project of wireless communication using signal processing. What would be the flow here for the project?

What is the general purpose to use C/C++? How can I use C/C++ for DSP? What are some references? I need to get started with C/C++ for building DSP algorithms. I am not aware how to use C/C++ for DSP applications.

• MATLAB also has its own Real-Time development tools. Yet, nothing can replace a sound C/C++ standalone production. Nov 20, 2021 at 18:36
• When you say "working", do you mean actually as your day job, or as learning in your spare time? If it's your day job, then cross-training into C/C++ is a key part of your professional development which your company should be taking you through. If not, then be warned that some companies are reluctant to hire people who are self-taught, because they have often developed bad habits because they're not aware of best practise in industry. Personally I'd rather take someone good and keen, and polish their rough edges off :) but not all companies work like that. Nov 21, 2021 at 9:08
• i ain't voting to close this question. Nov 22, 2021 at 1:47
• MATLAB is for investigating algorithms, for developing proof of concept demonstrations, and creating test vectors for shaking down the final system. C/C++ is for running the target systems. A DSP professional needs to know both. Nov 23, 2021 at 8:42

MATLAB is a desktop computing environment, that's designed to make it easy to do math in batches. And if you were to have access to the MATLAB source code, you'd find that as you dig down into it, the actual computational bits are written in C++, C, or (very likely) Fortran.

However, its interface to the underlying mathematical packages is big and slow, and isn't something that can easily run in real time*

The general process for a signal-processing related development effort is more or less as follows:

First, someone does the basic research, to see if what's being proposed is even possible. This would involve doing a mix of basic mathematics and experimental mathematics. The basic math part is - math. The output is a series of research papers or white papers. The experimental math part could well include MATLAB, but might involve using Python and numerical packages again (in my opinion MATLAB is best for programs that don't exceed 500 lines total; beyond that the clunkiness of the language exceeds the fact that Python and its available packages are less thoroughly integrated for math).

Then, someone does an initial system design, using the output of the above step (sometimes these two steps might happen at the same time; sometimes, as in the case of a straightforward SDR, the basic research has been established for decades). If you're being systematic about your design approach, you'd also use MATLAB or Python here, but you would also be aware of what processing will be available on a processor (with code written in C/C++) and/or any digital logic (FPGA or ASIC).

The output of this initial system design is a fully-detailed algorithmic description that goes all the way down to the established functions that are available in C/C++ (so, arithmetic if there's not an available math package, or the package's operations if there is). This initial design will include an estimate of processor loading, and will have an analysis of what processors need to be used, and if digital logic is used, how the work is divided between the processor(s) and the digital logic.

(Note that an alternative path here is that you're given a prescription for the hardware you can use, and your job is to determine how much functionality can be squeezed into it. It uses the same knowledge base, but it generally involves a lot of cut-and-try technical work, and a lot of meetings with non-technical stakeholders to explain things and to negotiate a solution that everyone can live with).

Finally, end-point hardware is obtained or designed, and the actual design is realized. This part is done in C or C++ in the processors, and in VHDL or Verilog in the digital logic bits (possibly with some SystemC thrown in there for fun). It is this final step that is the most labor-intensive. It requires not just an understanding of signal processing math, but a deep understanding of numerical methods (because you generally can't just do everything in 64-bit floating point: you'll often be squeezing your design into smaller floating point words, or into fixed-radix arithmetic), and general embedded programming good practices.

In the working world, you either start out at the bottom step, implementing designs and then (maybe) learn enough on the job that you can be trusted to do detailed systems design and you move into that step. Alternatively, you get a PhD with an absolutely dynamite thesis that essentially does that first basic research part for some problem that someone with money wants to solve, and then you do research for the rest of your career, because the only way to know how to do the initial system design is to know how to do the detailed design.

If you're a MATLAB-slinging top-level DSP practitioner and you want to actually write code, then these are skills that you need to make sure you have when all is said and done:

• Know what all those MATLAB library calls actually do. I've seen a lot of posts from people who think that DSP begins and ends at knowing what MATLAB functions to call -- it doesn't. If all you know is what MATLAB functions to call, start by figuring out what they do, both arithmetically and to a signal.
• Learn how to implement math in C/C++. First learn how to do it so it works at all, and then learn how to do it with reduced data widths and with fixed point. Then learn how to do it so that it runs fast. If you don't have a numerical methods text, get at least one; if you're still in school take a numerical methods class.
• Learn how to do embedded programming, or at least get a start on it. This means learning how to write your code so that it does not depend on any higher-level operating system functions, and learning how to be mindful of how much memory you are using, and at least the basics of inter-thread communications on a processor that doesn't have an MMU.

* If you don't know what "real time" means in the context of embedded systems programming -- learn.

• (+1) Very informative answer, though it was scary when you dropped the other F word at the end of the first paragraph!
– Ed V
Nov 21, 2021 at 0:59
• //" then learn how to do it with reduced data widths and with fixed point..."// ---- they might not need to, they could have an ARM or a SHArC or something. ---- //" ...Then learn how to do it so that it runs fast."// That's usually necessary for embedded processing because sometimes they throw the least MIPS power necessary to accomplish a job. But this answer is spot on. Brings me back to 1979 to 1990 . Nov 23, 2021 at 0:49
• @robertbristow-johnson: I'm currently working on a cost-sensitive video processing app. So, yes -- speed is essential, and part of that is going to be half-precision floats or integers or something. Nov 23, 2021 at 1:48
• If you get to influence the design of the "half-precision floats ...or something", and if you're not doing Block Floating-Point, I really recommend a float format that is like the DEC PDP-10 but put in denormals at the bottom of the range. Then no bit pattern is not a number. And fixed-point compare works with floating-point numbers. And you may not need 8 bits for the exponent, but do the constant-offset exponent like IEEE. 00000 is your smallest exponent. Nov 23, 2021 at 1:59

C/C++ is the standard language for real time and embedded signal processing. MATLAB is in most cases way too memory hungry and way too slow.

There is a lot of signal processing happening in, for example, your cell phone or a small Bluetooth speakers. These don't have enough resources to run MATLAB and in any case it would be way too inefficient and expensive.

MATLAB is great for research and development, but it's not suitable for implementation or deployment in an actual product.

• i know some people at The Math Works that want to dispute your main thesis: "... not suitable for implementation or deployment in an actual product" ---- but we both know that your thesis is correct. Nov 22, 2021 at 1:46
• @robertbristow-johnson In their defense, they have done quite a bit to make MatLab compatible with production development, via tools that can start with MatLab code, and either convert it to C source and compile it into your code, or create shared libs to link with your C/C++ binaries... but either way, you still need to be fluent in C/C++ to integrate those MatLab pieces.
– FeRD
Nov 23, 2021 at 14:58
• i just think that, in nearly all cases, MATLAB is critically handicapped from being production-quality DSP code. the C code generated has not had good repute. but, i admit, i have not seen it in examples. Nov 23, 2021 at 15:03

I come from the game development world, and I knew C/C++ programming way before I did my first signal processing program (in the context of audio filters for games), so I hope I can give you another point of view.

The other answers mentioned speed and memory, and while that might be true, I'd say it's not the most important reason to choose one enrollment such as Matlab or a programming language such as C or C++.

I'd say it depends on what you're trying to do. If you're trying to do standalone signal processing, that is, you have some data, you have to process it, and then you do something with the result, then MATLAB is probably a very good tool, as it is easy to use, and widely known and used for that purpose.

However, if your signal processing algorithm is integrated into a large system, where you get data from the system, you process it, and send it to another system for further processing, then MATLAB might create more problems than it solves.

Memory and speed is definitely one factor, but licensing is another. It's not reasonable to ask every customer who uses your software to purchase and install MATLAB, just because a small part of your system uses it.

What I'm trying to say it's that MATLAB is a poor choice for integrating into a system. On the other hand, one of the biggest advantages of C (even more than C++) is that it's very easy to integrate into other systems, not just those written in C, but also in Java, C#, PHP, Rust, Ruby, JavaScript, Python, etc. You can even load a C library into MATLAB itself!

You want to write a VST plugin? You do that in C. You want to write a Core Audio module for signal processing in an iPhone? You do that in C (or Objective-C). Embedded programming? C or assembly. Audio processing for games? C. The list goes on.

C is the lingua franca of the systems integration world, so if you want to write a piece of code that works with as many systems as possible, you may want to seriously consider C.

Your MATLAB experience is very useful though. If you're designing a new algorithm, you probably will find it easier to prototype it and test it in MATLAB, before going to build the final version in C.

I find it borderline misleading to even call MATLAB a programming language. –Well, it is a Turing complete language... but so is Brainfuck (BF). You can theoretically write any software in it (given sufficient memory an time) – Yes. But would you? No.

Ok ok, the BF comparison is exaggerated. People do write comprehensive programs in MATLAB, and they work, but any bigger project I've ever seen in MATLAB was an unmaintainable heap of hacks upon hacks. That has in part to do with the fact that the authors tend to be engineers, physicists, etc., who are smart in their field, but have never learned about good software engineering practices. But also with the fact that scripting languages like MATLAB, and particularly MATLAB, actively encourage bad practices.

Henning Thielemann has written a very opinionated post (in German). The essence is this:

einfache Aufgaben noch einfacher und schwierige noch schwieriger zu machen

translated: scripting languages make easy tasks even easier, and hard tasks even harder.

In particular in MATLAB, the ready availability of all kinds of powerful standard numerical methods out of the box make it very alluring for beginners. There's nothing wrong with that per se – as long as you never stray too far from what has already been implemented by others. But, it's telling that not much of MATLAB itself is actually implemented in MATLAB – certainly none of the performant low-level code.

There are valid arguments for the use of MATLAB in education. Should students need to spend the time to learn how to structure projects, how to import libraries, how to implement low-level code themselves, before they can even run some simple ODE solvers or DSP filters? Maybe not. (I personally think yes!)
But if you're going to work for a company then you most likely will need those skills eventually. That's true even if your work would actually mostly be prototyping DSP methods in MATLAB. Even if that covers 90% of your duties – eventually your code will need to be integrated in the main project, probably translated to another language. If you can't do that, then all your MATLAB code won't be very valuable to the company – they'll need to have another developer do that work. (Who will first need to read into your MATLAB, which likely will take considerable time of itself.) Compared to that, it makes much more sense for the company to hire somebody who can already do C++, even for the mostly-MATLAB DSP job. Because even if she takes a little longer for the prototyping, she will be much more efficient at the large-scale integration.

Even in case if your job is intended to be 100% in MATLAB, just knowing how to program in C will be a big asset, because it means you have a grasp on what's actually going on in the processor, regardless of what language is used on the top level.

I refute also the common assumption that one needs to choose between either a simple language like MATLAB, or a difficult one like C/C++. That's a relic from the days where Fortran was the industry standard (well, it still is in some HPC domains). Nowadays there are many alternatives available that lie between these extremes, and in some cases arguably are better for both quick prototyping and product code.

• Julia has this as its explicit goal. It's strongly inspired by MATLAB (IMO way too strongly, to the point of inheriting most of its problems), yet strives to be at the same time usable for writing new, performant code that can be used in any application.
• Modern C++ does by no means need look like low-level C-ish code. It supports powerful object-oriented, generic, functional, etc. styles, and there are tons of well-developed libraries available. C++ has definitely a bit of a learning curve, but in the end you'll be able to do just about anything with it, and your code can run anywhere, including embedded devices.
• Python is undeniably a scripting language, but with (at least originally) very different focus from MATLAB; it wasn't intended for numerical / DSP applications at all. But for clean, maintainable development without too much difficulties or boilerplate. By now however, it has become the de-facto standard in the machine learning community, and has very powerful and easy to use libraries. SciPy + MatPlotLib is almost as convenient as MATLAB's strongest sides, but within a much cleaner base language and permissive licenses.
Python still has the issue of being dynamic, which means you can't directly write high-performance low-level code or use it in embedded applications, but there are many decent workarounds and the situation keeps getting less of an issue.
• Rust takes roughly the same starting point of C++ (zero-overhead replacement for C with more features), but attempts to avoid being such a complicated behemoth.
• My personal favourite (take this with a grain of salt) is Haskell. Again completely different background. Haskell is very different from all the above languages. It's in a sense much higher-level than even Matlab, being completely declarative, but the way it does this makes Haskell code extremely robust for large-scale development. And it compiles to performant, native code. It also has a pretty big ecosystem, though unfortunately nowhere near as well-maintained libraries as Python. Few people in numerical applications have Haskell on their radar.
OCaml is a similar story, also a static functional language, not quite so extreme as Haskell.

The list could be made much longer, but that would go beyond the scope of this question.

Learning any of those languages will increase your value on the job market.
Julia or Python will be easiest to get into.
C and/or C++, as you have noticed, will give the strongest immediate employment bonus. Rust may be a slightly easier entry to that world.
Haskell or OCaml won't directly land you any DSP or machine learning jobs, but they will enormously widen your horizon on what “programming” can be, and teach you the functional programming style, which is increasingly in demand also in C++, JavaScript or Python jobs.

tl;dr: MATLAB is more comparable to spreadsheet software than to a production programming language.

• Matlab is #17 on the Tobie Index and #12 on the PYPL index. Matlab is very good at what it's designed to do: exploring different scientific ideas quickly and effectively. It's bad at what it's not designed to do: production code. Nov 21, 2021 at 14:35
• "project I've ever seen in Matlab was an unmaintainable heap of hacks upon hacks" That's been my personal experience trying to write large applications in Matlab code, and I've got a lot of years writing production code in C, C++, Python and Rust. It's just not easy to write decent applications in the Matlab scripting language. Nov 21, 2021 at 16:24
• @CrisLuengo well, a brief glance at the DIPlib project that you advertise on your profile as “the very best Image Analysis library” confirms my conception. Hundreds of useless boilerplate files that all redirect to a single god class? Case matching on strings like 'row vector'? Sanity checks like if ~isint(tsize(2)), hacks like if iscomplex(obj) {n = n / 2}? Mysterious matrix concatenations like a = [a,repmat(a(end),1,ndims-numel(a))]... and of course in the end the computation isn't done here anyway but in C++. Yup, all that quite reaffirms what I wrote in the answer. Nov 22, 2021 at 6:31
• @leftaroundabout So you pick some random bits of code you don't understand and call them hacks and mysterious? Great. That certainly cements your case. Well done! Anyway, I'm not going to defend a 20-something-year-old project that started off as a glue layer to a C library. There are a lot of things you could criticize in there. And MATLAB certainly has some quirks and annoyances, just like every other useful language. It's just as easy to find poorly written programs in Python or C++ or Java as it is MATLAB. And I have seen lots of good MATLAB code.¯\_(ツ)_/¯ Nov 22, 2021 at 15:35
• We're ranting against the MATLAB language now? nayuki.io/page/matlab-language-pet-peeves Nov 22, 2021 at 19:45

First of all, as others mentionned you should learn about embedded programming, real-time programming and C/C++

That being said, there are ways to minimize the Matlab to C/C++ conversion.

First method, you can use the legacy code tool to adapt C/C++ functions or C++ classes and integrate them in your Matlab/Simulink code. This is really useful if you have legacy code in C/C++ that you don't want to convert back in Matlab. Also, you can also use this to make sure your hand written C/C++ code behaves the same the equivalent Matlab functions or Simulink blocks.

Second method, you can use Matlab code/Simulink coder/Embedded coder to automatically generate C/C++ code. The generated code is actually pretty good AND legible. You can also easily navigate between the C/C++ code and the equivalent Matlab/Simulink block. This minimizes the conversion effort between Matlab and Simulink. Despite Mathworks' claims, you still need C/C++ skills as this does not give you a complete code. This will only port the DSP algorithm. You still need handwritten code to manage I/Os, ADCs, DACs, communication, remote firmware update, interrupts, etc.

In addition to the several answers already given here, I just want to link this superb answer from @Fat32. My focus is on MATLAB and the bad rap often directed at it (I am not one of them). As it has been and always will be:

Use the right tool for the right task!

For instance, I've once had a colleague who implemented a complete modulator in Excel. Yes that's right, MS Excel! Link budget we get it, but modulator.... Anyway, for what he wanted MS Excel was sufficient, and he simply just wanted to play with it similar to some here on dsp SE who've been (rightfully) playing around with R.

I will conclude here by quoting the comment in the linked answer:

Not so. MATLAB's natural syntax is so powerfully, uniquely and inherently linked with linear algebra and DSP notation that it certainly deserves an oscar (for those subjective lovers) if not a nobel (for those strictly objective lovers ;-) ). I hope you didn't try to compare Matlab Development Environment with languages like C / C++ / Java / Python etc. which I deduced from your semantics argumentation. Matlab is not a software development system, rather a mathematical algorithm development environment; the de-facto choice for most academics and especially (electrical) engineers.