It's long been a guideline (and IIRC a Weff-c++ warning) that either all, or
none, of the copy methods should be defined, but this became a standard warning
in GCC9. Presumably to account for a later language change though I'm not sure
which.
I don't remember why the ChanMapping copy constructor can't just be a simple
copy (it's just a map of POD), but figure it's safer to just copy what that
does.
This avoids possible demotion of unsigned integers when using the
add_property(char*, long) API. Which is unlikely to have ever been an issue but
worth noting.
This does not change the actual mapping logic, but makes the application of
the mapping much more robust. If there is no valid mapping for a given port,
that port is connected to silence (instead of crashing messily and/or via a
failed assertion).
Also tolerate mappings that nonsensically map to a buffer that is not present
(this particularly happens for MIDI ports in some cases) as a temporary fix.
The mapping logic needs work and/or our concept of just how much MIDI we support
in a route needs simplification...
git-svn-id: svn://localhost/ardour2/branches/3.0@10262 d708f5d6-7413-0410-9779-e7cbd77b26cf
Vimmers, try let c_space_errors = 1 in your .vimrc to highlight this kind of stuff in red. I don't know the emacs equivalent...
git-svn-id: svn://localhost/ardour2/branches/3.0@5773 d708f5d6-7413-0410-9779-e7cbd77b26cf
