Annoying Overloading ambiguity

If the following code is compiled with Studio 12u1 or express 0610, the following compilation error is reported:
CC /tmp/bug.cc
"/tmp/bug.cc", line 32: Error: Overloading ambiguity between "built-in operator[](int, const char*)" and "Object::ValueProxy::operator[](const std::string &)".
gcc is happy with the code and I think it is valid (what is "built-in operator[](int, const char*)"?).
Removing the template operator T() gets rid of the error.
#include <string>
struct Value
struct BaseHolder {};
template <typename T> struct Holder : BaseHolder {};
template <typename T> operator const T() const; // <-- this line
Value operator[]( unsigned n );
Value( const Value& ) {}
struct Object
struct ValueProxy : Value
operator Value();
ValueProxy operator[](const std::string& );
ValueProxy operator[](const std::string& s);
int main()
Object o;
o["a"]["b"][0];
}

1. Please always put code examples, scripts, and compiler messages in "code" brackets, to ensure they are displayed correctly. In particular, some punctuation characters are otherwise taken as formatting directives and not displayed.
2. Class Value has a user-defined copy constructor, so the compiler will not generate a the default no-argument constructor.
The fragment struct ValueProxy : Value { ... }is not valid because no constructor for Value is available. (CC does not catch this error, but gcc does.) I removed the copy constructor to avoid this error.
3. The operator Value() conversion function in class ValueProxy would convert a ValueProxy to its base class, which is an implicit conversion. The conversion function will never be called for an explicit or implicit conversion. Perhaps this code does not work as you expect. (You could call the function explicitly by name, but then you might wind up with two different results for a conversion.)
4. I think the last line really is ambiguous, as indicated by CC. I think gcc is wrong to accept the code.

Similar Messages

  • Overloading ambiguity between "std::pow(double, int)" and "std::pow(long do

    hello all,
    we have a problem with sources coming from visual c++, i can reproduce the problem with the small code:
    $ cat test.cc
    #include <math.h>
    int main()
    double kk;
    int j11;
    j11=4;
    kk=pow(2,j11);
    $ CC test.cc
    "test.cc", line 8: Error: Overloading ambiguity between "std::pow(double, int)" and "std::pow(long double, int)".
    1 Error(s) detected.we are on linux, with sun studio 12u1
    thanks in advance for help,
    gerard

    The issue is whether the standard headers associated with the compiler have the overloads required by the standard. If the required overloads are present, the original call of std::pow is ambiguous, and the compiler will report it.
    If you have a recent version of Visual C++, I'd be very surprised if the function overloads were not available. Possibly you are using a compiler option, perhaps a default option, that hides the overloaded declarations. In that case, some C++ code that conforms to the standard would not behave correctly when used with the compiler in that mode.
    The correct approach is to use the compiler in standard-conforming mode so that code you write will be accepted by other standard-conforming compilers. That is, after all, the purpose of the standard.

  • Overloading ambiguity when compile with stlport

    I am trying to compile code with sun compiler 5.3 with stlport 4.5.3 with sun standard iostream.
    Got the following error. Is this a bug in compiler ?
    "/opt/local/STLport-4.5.3/stlport/stl/_vector.c", line 76: Error: Overloading ambiguity between "_STL::uninitialized_fill_n<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>>(_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, const _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>&)" and "std::uninitialized_fill_n<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>>(_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, const _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>&)".
    "/opt/local/STLport-4.5.3/stlport/stl/_vector.h", line 460: Where: While instantiating "_STL::vector<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>, _STL::allocator<_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>>>::_M_fill_insert(_STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>*, unsigned, const _STL::basic_string<char, std::char_traits<char>, _STL::allocator<char>>&)".
    "/opt/local/STLport-4.5.3/stlport/stl/_vector.h", line 460: Where: Instantiated from non-template code.

    It's impossible to say whether the problem is in your code, the compiler, or in the STLport files without seeing the source code that you are trying to compile. Can you post a small example that illustrates the problem?
    But we do not support STLport with C++ 5.3. If you have problems with that combination, you are on your own. If you can identify a compiler bug, we can try to fix it, but C++ 5.3 has been declared End Of Life, and only limited support is available.
    Our recent compilers include a supported version of STLport. The current release is Sun Studio 10, but Studio 11 will be released within two weeks. Watch this space for details.
    http://www.sun.com/software/products/studio/index.xml

  • Error: Overloading ambiguity between "operator+(const RWCString&, const RWC

    We always get the following error when we are compiling our source codes:
    Error: Overloading ambiguity between "operator+(const RWCString&, const RWCString&)" and "RWCString::operator const char*() const"
    Our compiler is Workshop 6 update 1. We can compile the same source codes in Workshop 5.0. We found out that we can solve this problem if we explicitly cast the const strings to RWCString. However, since we are building on previous source codes and modules, we find this solution close to impossible. Is there other solution for this problem? Are there any patch which we can use?
    Thanks!

    The code really does have an ambiguity in it.
    The RWCString class operator() member function, which you invoke as str1(...) with an integer value, returns a char. You then have the operation
            RWCString + char
    The RWCString class does not have an associated operator+ that takes a RWCString and a character. The compiler could convert the string to a char* via "operator const char*" and add the value of the char to it, or it could convert the char to a RWCString via a constructor and use the operator+ that takes two RCWCstrings.
    The compiler has no way to prefer one choice over the other.
    You can write an explicit cast, or you can store the result of the str1(...) operation in an explicit RWCString temp, or you could use the += operator:
    str2 = str2 + RWCString(str1(str1.length()-1));
    RWCString temp = str1(str1.length()-1);
    str2 = str2 + temp;
    str2 += str1(str1.length()-1);
    BTW, this problem illustrates why it's usually a bad idea to have multiple constructors and also type conversion operators in a class. It's hard to write code that doesn't lead to ambiguities.

  • Overloading ambiguity errors

    Any suggestions on how to resolve the error below?
    "/opt/SUNWspro/current-compiler/include/CC/Cstd/./vector", line 1131: Error: Overloading ambiguity between
    "std::distance<std::vector<bool, std::allocator<bool>>::const_iterator, unsigned>(std::vector<bool,
    std::allocator<bool>>::const_iterator, std::vector<bool, std::allocator<bool>>::const_iterator, unsigned&)"
    and "distance<std::vector<bool, std::allocator<bool>>::const_iterator, unsigned>(std::vector<bool,
    std::allocator<bool>>::const_iterator, std::vector<bool, std::allocator<bool>>::const_iterator, unsigned&)".
    Sometimes the subsequent "Where: While instantiating ...." helps locate the ambiguity.
    (None in this case. ) If this error were coming from user code, specifying '::' or 'std::' helps.
    But when it is in one of the CC include files, is there a recommended approach?
    Any input is appreciated.
    % CC -V
    CC: Sun WorkShop 6 update 1 C++ 5.2 2000/09/11
    Thanks.

    If you have copied the error message correctly, it appears you have declared your own "distance"function template outside namespace std, which is causing the ambiguity.
    If you haven't done that, you might have run into a compiler bug. C++ 5.2 is obsolete and is no longer supported, but you can download the most recent patches for it here
    http://wwws.sun.com/software/products/studio/patches/index.html
    and see if that fixes the problem. (In your case, select the link for Forte Developer 6 update 1. The most recent patches are from about 2002.)
    If patches don't help, see if you can post a small compilable code sample that shows the problem.

  • Wrong overloading ambiguity error

    Hi,
    The following compiles on Studio 7, but not on Studio 11, where an error is reported:
    Error: Overloading ambiguity between "myString::operator char*&()" and "myString::operator char*()"
    However, when myStr is defined const, then the code compiles.
    Why this difference in the behaviour of the compilers? Is it intended? Should unaccesible operators be checked for ambiguity? Why does the compiler check for ambiguity of methods which it obviously should not select in this case?
    #include <string.h>
    class myString {
      private:
         char * content;
      public:
         myString(const char * str) { content = new char[strlen(str)+1]; strcpy(content,str);};
         operator char*&() { char * cpy = new char[strlen(content)+1]; strcpy(cpy,content); return cpy;};
         operator const char* () const {return content;};
      private:
         operator char*() { char * cpy = new char[strlen(content)+1]; strcpy(cpy,content); return cpy;};
    int main() {
         myString myStr = "MyString Test String"; // COMPILE ERROR HERE
         const char * str = myStr;
         return 0;
    };

    The error is not on the marked line, but on the next
    line:
    const char * str = myStr;Yes, you are right, I marked the wrong line.
    >
    The rule for resolving overloaded functions is that
    all visible functions that can be called with the
    given arguments ("viable functions" in the
    terminology of the standard) are checked, and the
    best match is looked for.
    If there is no single best match, the call is
    ambiguous, an error.
    Only if there is a best match is accessibility
    checked. If the best match is not accessible, the
    call is in error.In this case, wouldn't the const operator be the best match?
    >
    The reason for checking accessibility last is to
    prevent changes in accessibility from changing the
    result of operator overload resoution. One can
    imagine different rules, but that is the C++ rule.
    (C++ Standard, section 13.3)This should only apply here if the compiler decided not to select the constant operator over the other operators. That would mean that doing two conversions (MyString -> char*/& -> const char*) would be preferred over doing one conversion (MyString -> const char *).
    Does this conform to the C++ standard rules?

  • Non-existent overloading ambiguity error on valid code

    $ cat >test.cxx
    #include <string>
    template <typename C, typename X>
    void
    f (std::basic_string<C> const&, X& );
    template <typename C>
    void
    f (std::basic_string<C> const&, unsigned char& );
    template<typename X>
    struct S
      template <typename C>
      S (std::basic_string<C> const& str)
        f (str, x_); // Error
      X x_;
    void
    g ()
      std::string str;
      unsigned char uc;
      f (str, uc); // Ok
      S<unsigned char> s (str);
    $ CC -V
    CC: Sun C++ 5.8 2005/10/13
    $ CC -c test.cxx
    "test.cxx", line 17: Error: Overloading ambiguity between "f<char, unsigned char>(const std::string &, unsigned char&)" and "f<char>(const std::string &, unsigned char&)".BTW, is there a no-nonsense (like paying Sun to report bugs in Sun's products) bug-tracking system where I can report things like this directly?
    hth,
    -boris

    Yes, it's a compiler bug. I have filed bug report 6370669 for you.
    If you have a service contract with Sun, you can monitor progress on fixing the bug and get early access to a fix before a patch is released. Otherwise, you can check the Sun Studio patch page from time to time to see if a new patch is available that fixes the bug.
    http://developers.sun.com/prodtech/cc/downloads/patches/
    We do not currently have a mechanism to allow customers to file or track Sun Studio bug reports directly.

  • Ambiguity in overloaded operator

    Hi All,
    Compiler barfs regards the overloaded operator [] .
    #include <iostream>
    #include <string>
    class String {
      public:
        String() { }
        String(const char* src) : myStr(src) { }
        String(const std::string& src) : myStr(src) { }
        String(const String& src) : myStr(src.myStr) { }
        operator const char*() const         { return myStr.c_str(); }
        char& operator[](size_t index)       { return myStr[index]; }
        char operator[] (size_t index) const { return myStr[index]; }
        size_t length() const { return myStr.length(); }
      private:
        std::string myStr;
    int main() {
        String s("abcd");
        char c = s[1];
        std::cout << c << std::endl;
        return 0;
    $ CC -m32 -g ambiguous.cc
    "ambiguous.cc", line 23: Error: Overloading ambiguity between "String::operator[](unsigned)" and "operator[](const char*, int)".
    1 Error(s) detected.1) I cannot modify all the instances like, c = s[1]. There are hundreds of similar things in code.
    2) operator const char* is required.
    Could someone suggest any work-around, considering the above 2 points.
    Thanks,
    Sreekar

    If you have both an operator char*() and and operator[](), you will have generally have overloading ambiguities. Adding more overloads as you did might cure some of them, but apart from complicating the code and reducing maintainability, can wind up with other ambiguities down the line.
    The standard string class does not have an operator char*(), but a named conversion operator c_str() instead, partly for that reason, but mostly to prevent accidental and unintended conversions from string to char*. As designed, the String class in the example suffers from both defects.
    The best fix is to re-think the design of the String class. If you are under pressure to get something working and out the door now, you could settle for a workaround such as you found. But make the time later to re-design and re-code. Otherwise the problems with the existing design will continue to cause problems, including code that mysteriously fails at run time, in the future.

  • Overloads SOLUTIONS

    Hi Guys,
    I've had like most of you, soooo many Overload messages "Disk Too Slow" etc... OK, Now listen well and do the following:
    1- NEVER record Audio on you Main Drive (the one that contains the System) NEVER!!!!
    2- Disable Journaling On your Drives as Journaling SLOWS down disk Read/Write.
    3- Try Increasing Buffer Size when Mixing, and Decreasing Buffer Size when recording.
    4- DEFRAG your Drives guys, we All forget to do maintenance to our Drives.
    5- Use Only Good Firewire Drives, Firewire 800 Recommended, don't expect Performance out of USB or USB 2 Drives.
    *These are the Basic steps that all of you should follow to avoid these annoying OVERLOADs
    I worked on a session thats 40 minutes long, with 122 Audio tracksplus many audio instruments and Loads of plugins on each track, 16 Reverbs open, VSS3,Spacedesigner,TC etc...... and I had no problems mixing down this project, I moved from drive to drive till I found out the Journaling problem, it also didnt work well on my internal second ATA drive,so....you got it??

    I should just shut up about this as it's been done to death and not really that huge a deal for me but i went through something similar in Sonar a couple of versions or so ago and and deeply sympathetic to those experiencing the problem. My guess is there's something deep broken and it will take them a while to fix it. i just don't want it papered over and brushed aside. As to bloat ware, well, yes and no. Logic is the only major that doesn't have a quality audio warp tool. PT's is pretty darn nice, especially if you need to keep phase relations intact over several tracks. Sonar's AudioSnap is incredibly powerful set of tools but makes the user work a bit a bit more. it comes with Izotope's logs included - the one's we pay, what, $300 bucks for? Live is incredible and Steiny's got theirs. Even Reaper, for $50; sheeesh. In this day and age it's a tool that should have been in 8, no two ways about it. While we're at it, audio comping, even even if swiping worked correctly is still pretty weak compared to the others. I use it because it's easy to write on. Let's just hope they fix it. I should be able to run 32 tracks with plenty of plugs at 64 sample latency without breaking a sweat on this machine. As it is I have to go to 256 to record 2 at a time with that track count.
    Anyway, you're way ahead on all this and now i will shut up.

  • I'm sick of these overload messages! Is there ANY fix in sight? (Part 2)

    On Jan 2nd 2008
    Jack Q posted:
    "I get that annoying overload message:
    " Logic Pro: System overload. The audio engine was not able to process all required data in time (-10011)"
    I have 4 tracks going (which is nothing), my cpu meter is barely moving, and I RARELY got this message in Logic 7.
    I've trashed my preferences, and read this forum over and over and tried everything I can, and I cannot get this problem to go away.
    Is there ANYTHING that can be done and will Apple fix this??"

    Synesthesian,
    What about my comment do you disagree with? You call it a Huge problem. I call it a big problem. We are just getting into semantics now. This is in fact a monumental problem. We who are having these problems can all agree on this. I was saying to call apple and let your opinion be heard. Let them know how bad your experience with their product has been. Voice your disapproval.
    or,
    Am I off the mark and in a roundabout sort of way ,... you are saying you agree with my statements?
    For the most part I am repeating what others have said countless times. I just feel that this needs to be kept up.
    I dont' blame you for rolling back to logic 7. I think that is the best work around for the logic 8 "problem" period.

  • Various coding issues

    Here are a few issues I had lately:
    template < typename U >
    struct B
      struct A
        typedef char C;
      A* f ( typename A :: C )
    template < class U >
    typename B < U > :: A*
    B < U > :: f ( typename A :: C )
      return 0;
    }CC complains about an ambiguity between B < U > :: A and B < U > :: A.
    #include <iostream>
    template<class T>
    struct A
      void do_something() const {
        std::cerr << "A's do_something" << std::endl;
        T().do_something();
    template<class T>
    struct B
      typedef A<T> Nested;
      void do_something() const {
        std::cerr << "B's do_something" << std::endl;
        T().do_something();
    template<class T>
    class C
      friend class B< C<T> >;
      friend class B< C<T> >::Nested;
    protected:
      void do_something() const {
        std::cerr << "C's do_something" << std::endl;
    int main()
      A< C<int> > a;
      B< C<int> > b;
      a.do_something();
      b.do_something();
      return 0;
    };CC refuses this code. However, if I replace "friend class" by "friend template", it accepts it with a warning. g++ does the exact contrary. Could there be an agreement?
    I also have a problem with something like the following, but it is probably a well-known issue.
    template < typename T >
    struct A {};
    template < typename T, typename U >
    T f(const U& ) { return T(); }
    template < typename T, typename U >
    T f(const A < U > & ) { return T(); }
    int main()
      A<double> a;
      int i = f < int > (a);
      return 0;
    }

    CC complains about an ambiguity between B < U > :: A
    and B < U > :: A.
    I have filed bug 6377582 for this issue.
    CC refuses this code. However, if I replace "friend
    class" by "friend template", it accepts it with a
    warning. g++ does the exact contrary. Could there be
    an agreement?"friend template" is not valid, and the compiler might not be doing what you intend.
    The code
    friend class B< C<T> >::Nested;
    is not valid because Nested is a typedef, not a class. You need to express what you mean some other way.
    I also have a problem with something like the
    following, but it is probably a well-known issue.
    I have filed bug 6377606 for the incorrect error message about overload ambiguity.
    If you have a Sun Service contract, you can track progress on the bugs and get a pre-release patch to try. Otherwise, you can check the Sun Studio patch page every month or so and see if a new patch is available that fixes these bugs.
    http://developers.sun.com/prodtech/cc/downloads/patches/index.html

  • Anyone familiar with ARPREC?

    Hi,
    We are trying to write a C++ program as part of a science project. We were getting calculation errors and were told they were due to round-off and had to include a high-precision library. The ARPREC library was recommended to us which we downloaded from:
    http://crd.lbl.gov/~dhbailey/mpdist/
    We followed the installation instructions in the INSTALL file:
    1) ./configure
    2) make
    3) make install
    The README file in the package included a simple C++ program:
    #include <iostream>
    #include <arprec/mp_real.h>
        int main() {
          mp::mp_init(300);
          mp_real a, b("0.1");
          a = sqrt(b);
          std::cout << " sqrt(0.1) = " << a << std::endl;
          mp::mp_finalize();
          return 0;
        }We assume the code is correct since it was included in the ARPREC package, but compiling gives the following error messages:
    line 2: Error: Could not open include file<arprec/mp_real.h>.
    line 13: Error: mp is not defined.
    line 13: Error: The function "mp_init" must have a prototype.
    line 14: Error: mp_real is not defined.
    line 14: Error: Cannot use const char* to initialize int.
    line 16: Error: Overloading ambiguity between "std::sqrt(double)" and "std::sqrt(float)".Our knowledge of C++ goes as far as our ability to program our formulas but we don't know much about the broader things (like installing and linking libraries) and we've never seen these types of errors before. We were thinking that maybe we didn't install the library correctly, or if there are other things we're supposed to do beyond the installation steps above, or we are not compiling our program properly. We're new to Solaris and so for now still compile from the command line using the command:
    CC -o our_program our_program.cpp
    Does anyone have any experience with ARPREC that can help us get the above program to work?
    Thank you!

    The compiler is telling you it failed to find the file arprec/mp_real.h, which means that the compiler didn't know where to look for it.
    Using angle brackets instead of quotes around the file name in the #include directive might be the problem. Angle brackets are supposed to be used only for system headers, like iostream or math.h. With angle brackets, the compiler looks in special directories for the file, but usually not in the current directory. (The code as written might work by accident with some compilers, but will not work with all compilers.)
    Try adding the option -I . (dash I space dot) to the command-line options for the CC command in the makefile(s). You should see a makefile macro called something like CCOPTS or CCCOPTS with a list of options that get passed to the C++ compiler. Try adding "-I ." to that macro.
    If that still doesn't work, gcc and Sun C++ have an additional option -I- (dash I dash) that tells the compiler to treat additional -I directives as system directories. Try -I- -I . and see if that works.
    A web search turned up several references to ARPREC, and you didn't say where you got yours. Try contacting the author about this problem, or a community forum for ARPREC if there is one.
    Taking a larger view, you might be barking up the wrong tree. Ordinary type double, having about 15 significant digits, is often enough for many scientific calculations. Or you can use type long double, with about 33 significant digits. The round-off and other calculation errors might be due to the way you write the calculation, or to using an unstable algorithm.
    Simple example: Suppose you compute 1e40+1-1e40. The mathematical answer is 1, but that is not the computational answer if you perform the calculations in that order. Using computer arithmetic, 1e40+1 is exactly 1e40, because you don't have 40 significant digits. If you reorder to 1e40-1e40+1 you get 1 as an answer. Another common error is comparing floating-point numbers for equality instead of allowing for small variations. Yet another, a component in an unstable algorithm, is dividing by the result of subtracting very large numbers.
    You might need to split a formula into separate steps to ensure the correct computational order. That is, instead of writing
    x = A - B + C;
    you might have to force the order by writing
    t = A - B;
    x = t + C;
    I would look to something like ARPREC only if you are sure you don't have basic numerical computation errors.

  • CC 5.5 vs CC 5.9

    I'm trying to port some C++ code from Solaris to Linux. The code was running on Solaris 9, compiled with CC version 5.5. I've installed the Sun StuidoExpress on Redhat EL 4 - which comes with Sun's CC 5.9 compiler (right?). I'm assuming that there is no CC 5.5 for Linux - right? (sorry, I'm a little new to these technologies/tools - I'm even quite rusty with C/C++ - I didn't write the code I'm trying to port).
    My problem is that I'm getting "Overloading ambiguity" errors between two operator functions when I compile in Linux. The code compiled fine with CC 5.5 on Solaris. I'm assuming that I'm getting these compiling errors because of the difference between CC 5.5 and CC 5.9 - the later version is better at catching ambiguities. I'm posting because I want to verify this assumption with people who are more familiar with these compilers.
    Any comments would be greatly appreciated!

         char operator[] (IC::Uint int i) const;
         char& operator [] (IC::Uint int i);These declarations do not look like valid C++ syntax. Were they copied correctly?
         IC_String pathname;
    if(pathname[0] == '/') <-- Error referes to this
    Error: Overloading ambiguity between
    n "My_String::operator[](unsigned) const" and
    "operator[](const char*, int)"You don't show enough code for me to evaluate the error message.
    >
    The weird thing is that (as far as I understand) the
    call looks very ambiguous, but somehow the old
    developers got it to compiled using CC 5.5. C++5.5 did not correctly follow the overload resolution rules regarding user-defined and built-in versions of operators like the arrary-index operator []. It is possible that the code is not valid and C++ 5.5 did not catch the error. It is also possible that the code is valid and C++ 5.9 is incorrectly rejecting it.
    Are
    there compiler flags that would relax a compiler's
    check for ambiguous things? No. We have options to relax some rules, but we cannot provide flags to change the way function overload resolution works. (Suppose we had a flag to ignore ambiguity errors. The compiler would pick one function arbitrarily, and you could not predict or control which one.)
    To determine whether the problem is in your code or in the compiler, and to suggest how to fix the code, I need to see an example that can be compiled except for the error messages that you cite.

  • Logic 7.2 and the new MBP or Dual/Quad MacPros

    Hello,
    I'm at a cross roads at the moment and I'm just wondering if you guys would be able to help me out?
    My G5 is kinda noisey, hot, annoyingly overloaded (especially with NI Massive..lol) and its time for a change. I'm toying with the idea of a new MBP or if/when Apple announce new MacPro's next week a MacPro/2.66.
    I'm just after some opinions on Logic and MBP's, if its a stable and useable platform to work on? I like the look of the new 2.4ghz MBP's and the possibility of integrating Ableton Live with my DJ setups. But Logic is my "wow" (no offence) and I'm undecided if moving from the G5 1.8DP to the MBP would be a big improvement. I imagine the laptop would be a lot more quieter than the MacPro.
    I was thinking of going for the 2.4 15" with the faster 7200.2 HD (i dont mind the 4-6 week wait) and buying a Motu Ultralite and a firewire caddy/hd for a 320gb Seagate.
    Then with the MacPro, its going to be really more powerful but then there's no portability.
    Hope you guys can help,
    Cheers.
    Simon
    Powermac G5 1.8DP   Mac OS X (10.4.9)  

    Thanks for the link. My G5 resulted in 1504. Did some searching around on that link and sound some very interesting speeds.
    Mac Pro [8 Core] - 8688 - http://browse.geekbench.ca/geekbench2/view/7508
    Mac Pro [3Ghz] - 5557 - http://browse.geekbench.ca/geekbench2/view/7222
    Mac Pro [2.66Ghz] - 4891 - http://browse.geekbench.ca/geekbench2/view/7577
    MacBook Pro [2.4Ghz] - 3236 - http://browse.geekbench.ca/geekbench2/view/7534
    MacBook Pro [2.2Ghz] - 2991 - http://browse.geekbench.ca/geekbench2/view/7451
    Hmmm... MacPro's are a big jump.
    Powermac G5 1.8DP   Mac OS X (10.4.9)  

  • Forte 6 update 2: Compile errors

    When I tried to recompile (using Forte C++ update 2) a project that was built fine under Workshop 4.2, Here are some of the errors that I received:
    Making CList.o...
    cc -g -Xc -I/usr/dt/include -I/usr/openwin/include -c CList.c
    "./XmI.h", line 113: (union) tag redeclared: __XmStringRec
    "CList.c", line 3605: warning: improper pointer/integer combination: op"="
    "CList.c", line 3861: warning: improper pointer/integer combination: op"="
    *** Error code 2
    make: Fatal error: Command failed for target 'CList.o'
    Making S_MoreTdimfElement.o...
    CC -g -I. -I/usr/dt/include -I/usr/openwin/include
    -I/home/lnguyen/tnp/include -compat -c S_Class.C
    "S_Class.C", line 2996: Error: Overloading ambiguity between
    "operator!=(const ClassA&, const ClassA&)" and
    "ClassA::operator const char*() const".
    "S_Class.C", line 3036: Error: Overloading ambiguity between
    "operator!=(const ClassA&, const ClassA&)" and
    "ClassA::operator const char*() const".
    2 Error(s) detected.
    ***Error code 2
    make: Fatal error: Command failed for target S_Class.o
    Anyone's seen this before?
    Thanks in advance...

    This was changed from an error to a warning about anacronism in the Forte Developer 7 C++ compiler. The warning can then be suppressed in a variety of ways including :
    CC -erroff=%all
    Since this structure is treated as an error in the Workshop 6 update 2 compiler, there's no way (of which I am aware) to get the compiler to compile files with the empty enum contained.

Maybe you are looking for

  • HP Pavilion DV6T-7000 Quad-Edition, Windows 7 64-bit Not Turning On

    I've got a problem with this laptop. I've only had it for a few weeks and already, it refuses to turn on for me. No lights will come on even when there is AC or battery as a power source. Prior to the problem, I was doing absolutely nothing that woul

  • Possible Bug with Drag-and-Drop Being Published via HTML5 - Getting "Undefined" Error When Dragging Object

    Hello, I came up with a way to use drag-and-drop interactions that will take advantage of file input so that I may create a drag-and-drop interaction that uses one draggable object over and over allowing multiple scoring/tracking possibilities.  Exam

  • FCC : receiver stucture changes using adapter

    hi experts, my target file structure is like this NODE1        comp_name        Project_name NODE2       header            one            two            three But i want my output file with only NODE2, i dnt want to show him NODE1 details to my clien

  • Never set a backup password

    Does Apple have any plans to help those of us who never set backup encryption passwords clear the encryption so we can backup?  I have no use for iTunes if I can't at least backup my phone.  Apple should never have encrypted the backups without givin

  • Attach  txt file

    begin Gen_Ces_Mail.email_files('[email protected]' -- van adres , '[email protected]' -- naar adres , 'test mail' -- onderwerp , 'message: test message' -- bericht , cesFiles('/usr/lib/oracle/xe/app/oracle/admin/XE/dpdump/test.txt) end; Can anybody h