C++ abs ambiguous overloaded function: fix the include order

You add a small helper header to a working depth-camera example, rebuild, and the compiler throws error C2668 'abs': ambiguous call to overloaded function — aimed at a line inside the camera SDK's own header file. You did not write a single call to abs. The cause is include order: which headers the compiler has already read decides which set of abs overloads it can choose from at that line. This page is for engineers integrating a 3D camera SDK with OpenCV or another C++ library. It explains why the same file compiles on one machine and fails on another, gives the fixes in the order to try them, and shows how to keep a code formatter from silently undoing the repair.

What the compiler is telling you

The failure arrives with one of two signatures. On MSVC: error C2668 'abs': ambiguous call to overloaded function, pointing at a header and line you never edited — in the reported case, line 96 of a depth SDK's rsutil.h utility header. On GCC and Clang: call of overloaded 'abs(int64_t&)' is ambiguous, same cause, different wording.

The file and line in the message are the call site, not the cause. Somewhere in that vendor header an inline helper calls the unqualified function abs. Whether that call is legal depends entirely on which declarations the compiler has already read when it reaches the line — and you control that through your include order, above the SDK header in the same.cpp file.

That is also why the error can appear with no code change at all: an automatic include reordering, a new library added above the SDK, or an SDK update that pulls different headers first. A missing header fails earlier and with a clearer message; the missing OpenCV headers guide covers that sibling case. Ambiguity fails late, on the vendor's line, which is what makes it confusing.

Why include order decides which abs the compiler sees

Two function families meet at that line. C brought one: abs(int), declared in <stdlib.h>, plus labs and llabs for long and long long. C++ multiplied the name: compile <cmath> or <math.h> as C++ and overloads for long, long long, float, double and long double come into scope — the runtime library documentation for these compilers lists exactly that set. Most implementations place the floating overloads in the global namespace alongside std; whether they do is implementation-defined, which is exactly why the same file compiles on one machine and refuses on another.

The ambiguity needs one more ingredient: the SDK helper calls abs on a value that is not exactly an int. With only the C declaration visible, the call compiles and quietly converts the argument. With the full C++ set visible, converting that argument to int, to long long and to double are all ordinary conversions of the same rank; none wins, and the compiler lists them all. Float and double arguments are safe once <cmath> is in scope — they hit an exact overload. Unsigned, 64-bit and size-type arguments are the ones that tie.

Likely causes, in order of probability:

1. A C++ library include — OpenCV is the usual one in vision code — sits above the SDK header and pulls <cmath> in first. Most common by a wide margin.
2. An auto-formatter sorted the includes alphabetically and moved the SDK header below the C++ block. This was the trigger in the reported case.
3. Your own code calls abs on unsigned, size_t or 64-bit values, where the integer and floating overloads tie.
4. An SDK update changed what the vendor header includes for itself before its own abs call.

The bottom row is the error you are looking at. The top row is quieter and worse in one way: it hides a truncation instead of stopping the build.

The fixes, in the order to try them

Work the list in order. The first step proves the diagnosis; the rest make the fix survive tooling and teammates.

1. Prove it in one minute. Move every SDK include above all C++ library includes in the failing.cpp file and rebuild. The vendor guidance in the reported case was exactly this: the error comes from what is included before the SDK header. If it compiles now, cause confirmed.
2. Set the order yourself at the top of every file that mixes SDK and C++ headers, instead of trusting whichever header gets there first:

#include <cstdlib> // std::abs: integer overloads
#include <cmath> // std::abs / std::fabs: float, double, long double
#include "rsutil.h" // depth SDK utility header
#include "cv-helpers.hpp" // SDK-to-OpenCV glue from the example you started from

3. Name the type before the function at call sites you own. A typed argument matches exactly one overload and cannot be ambiguous:

float delta = std::fabs(b - a); // floating-point difference
int64_t diff = int64_t(b) - int64_t(a); // signed difference of unsigned counters
auto moved = std::abs(diff); // exact long long overload

4. Keep vendor-first order where the call is not yours. For a call inside a vendor header you cannot edit, the include order is the fix; leave a one-line comment saying so, and treat that order as part of the build, like a compiler flag.
5. Leave the vendor header alone. It compiles in the intended order; an edit is overwritten at the next SDK update and the error returns as a mystery. If the break followed an update, work through the build errors after a library upgrade guide instead.
6. Build once with a second compiler. Global-namespace visibility of the floating overloads differs between standard libraries, so an MSVC-clean file can still fail on GCC, and the reverse.

Worked example: one unsigned subtraction, three outcomes

Two 32-bit unsigned frame counters, a = 3 and b = 5, and you want the magnitude of the change:

uint32_t a = 3, b = 5;
uint32_t d = a - b; // wraps, see below
float m = abs(d); // three possible outcomes

The wrap comes first: 3 − 5 = −2, and 32-bit unsigned arithmetic holds 2^32 values, so the stored result is 4,294,967,296 − 2 = 4,294,967,294.

Under C++20 the unsigned-to-signed conversion is defined to wrap modulo 2^32, so the silent path lands on −2 by rule; earlier standards left it implementation-defined, and mainstream compilers wrapped the same way. The escape hatch to refuse is abs(static_cast<double>(d)): it compiles everywhere and returns 4,294,967,294.0 — wrong by 4,294,967,294 − 2 = 4,294,967,292. A clean build is not proof the magnitude is right.

Keep the formatter from undoing the fix

In the reported case the code was correct until a .clang-format file sorted the includes alphabetically. That pushed the SDK header below the C++ block, and the error returned with no source change. Formatter include sorting and IDE organize-imports commands both do this, silently, weeks after you fixed the file.

Fix the tool, not just the file. Configure include sorting to keep block groups separate — standard library group, vendor SDK group, project group — so sorting happens inside a group and never across groups. If the formatter cannot preserve groups, switch include sorting off for files that include camera SDKs.

Prevention, four habits:

• One fixed include block at the top of every.cpp that touches an SDK: standard C++ headers, then SDK headers, then project headers.
• Warning level up: /W4 on MSVC, -Wall -Wextra on GCC and Clang, so double-to-int narrowing surfaces where the silent truncation lives.
• One grep for unqualified abs( across the codebase, converted to typed std::abs or std::fabs.
• A second-compiler build in CI whenever the project runs on mixed machines.

Check the depth math once it compiles

The ambiguous call never ran, so the error itself changed no measurement. The include state that produced it can still corrupt numbers quietly: with only abs(int) in scope, abs(3.9) returns 3, and 0.9 vanishes. That is why the typed-call habit matters more than the include reorder.

If you replaced the SDK's per-pixel distance call with your own scaling — the DEPTH_UNITS and depth_frame_to_meters route, chosen to cut the per-pixel overhead of get_distance — validate on a flat target at a fixed standoff. Read the frame's scale once, in meters per count, then compare count × scale against the built-in call for a handful of pixels. With a 0.001 m/count scale, a one-count difference is 1 mm and is rounding; a systematic 1000× factor is millimeters meeting meters; an offset that grows with distance points at a missing reference. Depth scale and capture settings move together — the capture-time depth resolution guide covers that side.

Hosts and sensors for this kind of build

The project behind this error has a shape: a depth or laser profile sensor driven through its C++ SDK, OpenCV on top, one host doing acquisition and processing. A laser profiler such as the MV-DP4180-03P is exactly the kind of device whose SDK you compile against this way.

On the host side, a single-camera bench builds comfortably on the MV-VC3301H-128G66, which keeps the PCIe slot free for an extra network card. Multi-camera cells step up to the MV-VC5525-256G70-NN, whose PoE camera ports carry power and data on one cable.

The full controller range is on the vision controllers page; the profilers and stereo cameras are on the 3D sensors page, with the 3D camera finder for filtering by type and interface.

Standardize once, then stop patching

Fixed this error three times in three projects? Standardize once instead: the ordered include block, typed std::abs everywhere, formatter configured to preserve groups, a second compiler in the build. After that, the failures you meet are the loud kind, and they have their own guides: linking errors and CMake dependencies when it compiles but will not link, and missing ATL headers when building an SDK from source when the toolchain itself is short a header.

Include-order fights like this one are not tied to one depth-camera maker; same failure with a stereo depth camera SDK on an embedded ARM host walks the identical diagnosis on a different stack.

For the wider station — cameras, lenses, lights and the controller in one configuration — the system configurator walks the parts in order, the applications team will check a build host before you order through the contact page, and the rest of the build-and-integration guides sit on the Learn guides hub.