Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

Should llabs() be used instead of abs() for long long int?

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


parrisimo at gmail

Jul 4, 2012, 4:51 AM

Post #1 of 5 (375 views)
Permalink
Should llabs() be used instead of abs() for long long int?

I ran into a compile error on my QNAP NAS with Marvell 6282 1.6GHz (ARM)
and kernel 2.6.33.2:

transcode.cpp:541: error: call of overloaded 'abs(long long int)' is
ambiguous

When I edited the code and changed from abs to llabs, the compile was
successful. Is this a particular for my system or would other systems
benefit from this change? Patch text below:

diff --git a/mythtv/programs/mythtranscode/transcode.cpp
b/mythtv/programs/mythtranscode/transcode.cpp
index dcf0e11..eb0bf0a 100644
--- a/mythtv/programs/mythtranscode/transcode.cpp
+++ b/mythtv/programs/mythtranscode/transcode.cpp
@@ -538,7 +538,7 @@ class Cutter
{
return false;
}
- else if (abs(audioFramesToCut - frames) < audioFramesToCut)
+ else if (llabs(audioFramesToCut - frames) < audioFramesToCut)
{
// Drop the packet containing these frames if doing
// so gets us closer to zero left to drop


gary.buhrmaster at gmail

Jul 4, 2012, 6:32 AM

Post #2 of 5 (350 views)
Permalink
Re: Should llabs() be used instead of abs() for long long int? [In reply to]

On Wed, Jul 4, 2012 at 4:51 AM, Matthew Parris <parrisimo [at] gmail> wrote:
> I ran into a compile error on my QNAP NAS with Marvell 6282 1.6GHz (ARM) and
> kernel 2.6.33.2:
>
> transcode.cpp:541: error: call of overloaded 'abs(long long int)' is
> ambiguous

My recollection is that a long long abs was officially added to the
specification in c++11 (to go along with an int abs, and a long abs).

> When I edited the code and changed from abs to llabs, the compile was
> successful. Is this a particular for my system or would other systems
> benefit from this change?

Your (and when I say your, I mean any particular distro or cross
compiler) compiler/header/libraries will vary as to when they
supported a long long abs (various backports, various compiler
c++ standards defaults, etc.) I am not at all surprised that an ARM
port has some differences than the standard x86 variants.

Gary
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


parrisimo at gmail

Jul 4, 2012, 7:50 AM

Post #3 of 5 (356 views)
Permalink
Re: Should llabs() be used instead of abs() for long long int? [In reply to]

Thanks, Gary, for the reply. Do you think the project would accept a patch
to change from abs to llabs? Are there benefits of using abs that couldn't
be achieved with llabs?

On Wed, Jul 4, 2012 at 9:32 AM, Gary Buhrmaster
<gary.buhrmaster [at] gmail>wrote:

> On Wed, Jul 4, 2012 at 4:51 AM, Matthew Parris <parrisimo [at] gmail>
> wrote:
> > I ran into a compile error on my QNAP NAS with Marvell 6282 1.6GHz (ARM)
> and
> > kernel 2.6.33.2:
> >
> > transcode.cpp:541: error: call of overloaded 'abs(long long int)' is
> > ambiguous
>
> My recollection is that a long long abs was officially added to the
> specification in c++11 (to go along with an int abs, and a long abs).
>
> > When I edited the code and changed from abs to llabs, the compile was
> > successful. Is this a particular for my system or would other systems
> > benefit from this change?
>
> Your (and when I say your, I mean any particular distro or cross
> compiler) compiler/header/libraries will vary as to when they
> supported a long long abs (various backports, various compiler
> c++ standards defaults, etc.) I am not at all surprised that an ARM
> port has some differences than the standard x86 variants.
>
> Gary
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-dev
>


danielk at cuymedia

Jul 4, 2012, 9:22 AM

Post #4 of 5 (353 views)
Permalink
Re: Should llabs() be used instead of abs() for long long int? [In reply to]

On 07/04/2012 10:50 AM, Matthew Parris wrote:
> Thanks, Gary, for the reply. Do you think the project would accept a
> patch to change from abs to llabs? Are there benefits of using abs that
> couldn't be achieved with llabs?

As long as you explain why it is needed in the ticket and include the
proper header in the file it will be accepted.

I think "long long" isn't a C++98 type, though it in practice
is supported by all C++ compilers since it is a C99 type and
a C++11 type. I guess compilers also adding abs(long long) to
their libraries is not universal and hence the error.

-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev


lvr at softsystem

Jul 4, 2012, 12:01 PM

Post #5 of 5 (350 views)
Permalink
Re: Should llabs() be used instead of abs() for long long int? [In reply to]

On Wed, 2012-07-04 at 12:22 -0400, Daniel Thor Kristjansson wrote:
> On 07/04/2012 10:50 AM, Matthew Parris wrote:
> > Thanks, Gary, for the reply. Do you think the project would accept a
> > patch to change from abs to llabs? Are there benefits of using abs that
> > couldn't be achieved with llabs?
>
> As long as you explain why it is needed in the ticket and include the
> proper header in the file it will be accepted.
>
> I think "long long" isn't a C++98 type, though it in practice
> is supported by all C++ compilers since it is a C99 type and
> a C++11 type. I guess compilers also adding abs(long long) to
> their libraries is not universal and hence the error.

IMHO the most compatible solution is to keep with abs and rely upon
polymorphism i.e.

#include <cstdlib>
...
sometype_t x; // maybe long long
std::abs(x);

It's not a good idea to use abs without a namespace due to conflicting
(macro) implementations (M$ et al). This covers most C++ compilers
since ~2000 and the the C++0x N2798 quasi-standard which added the
signature:

long long abs(long long);

and compatibility with C1x N1570 <stdlib.h> which included llabs.
However, C1x isn't widespread so relying on it is dubious.

--
Lawrence
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-dev

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.