Which programming language is more useful?

[Gian-Carlo Pascutto]

I was actually a bit surprised that on many Linux distributions, it's difficult to get the latest Boost without installing it yourself. The problem seems to be a combination of C++'s lack of ABI guarantees and stability. I guess Mac OS X has the same issue.

With Mac OS/X, a bunch of the system interface topics like threads and timers are already covered by NextStep, er... I meant "Cocoa". So there's not much motivation for Apple to finance Boost integration and deployment.

Each platform has native threads and sockets libraries. I do not see what your statement has to do with anything. Or do you mean Apple wants to make it intentionally hard to port software to Mac OS X?

[andretaff]

I don't know if it's ugly, but I'd probably do something like this:

Code: Select all

char *move_string(char * dest, Move m) 
{
  sprintf(dest, ...);
  return dest;
}

[sje]

I was actually a bit surprised that on many Linux distributions, it's difficult to get the latest Boost without installing it yourself. The problem seems to be a combination of C++'s lack of ABI guarantees and stability. I guess Mac OS X has the same issue.

With Mac OS/X, a bunch of the system interface topics like threads and timers are already covered by NextStep, er... I meant "Cocoa". So there's not much motivation for Apple to finance Boost integration and deployment.

Each platform has native threads and sockets libraries. I do not see what your statement has to do with anything. Or do you mean Apple wants to make it intentionally hard to port software to Mac OS X?

Your earlier post seems to implicate that it as Apple's fault that Boost wasn't part of it's standard distribution, or at least it was a fault of some Linux distro makers that Boost was a tricky optional.

[Gian-Carlo Pascutto]

Each platform has native threads and sockets libraries. I do not see what your statement has to do with anything. Or do you mean Apple wants to make it intentionally hard to port software to Mac OS X?

Your earlier post seems to implicate that it as Apple's fault that Boost wasn't part of it's standard distribution, or at least it was a fault of some Linux distro makers that Boost was a tricky optional.

It is tricky to get the latest or a recent version (installing an older version is fairly trivial). This is a bit problematic because Boost is getting more and more popular, and Linux should be a platform that makes it generally easy for developers to get the latest development tools.

The Linux distributions seem to be working on resolving the issue, and I expect that Apple will have to follow suit or be left behind. Native libraries have no relevancy at all to that - both Windows and Linux have native threading and socket API's, and people still use Boost, for good reason.

[sje]

Your earlier post seems to implicate that it as Apple's fault that Boost wasn't part of it's standard distribution, or at least it was a fault of some Linux distro makers that Boost was a tricky optional.

It is tricky to get the latest or a recent version (installing an older version is fairly trivial). This is a bit problematic because Boost is getting more and more popular, and Linux should be a platform that makes it generally easy for developers to get the latest development tools.

The Linux distributions seem to be working on resolving the issue, and I expect that Apple will have to follow suit or be left behind. Native libraries have no relevancy at all to that - both Windows and Linux have native threading and socket API's, and people still use Boost, for good reason.

I'm considering moving to Boost for the Windows implementation of Symbolic. I note that Cygwin has Boost 1.33.1 available although I haven't tried it yet as I'm currently using Cygwin's pthreads implementation. I'd much rather be coding chess than screw around with system issues. The questions are:

1) Do the Boost libraries and header files work with MSVC++ Express?

2) Is it worthwhile to convert my working pthreads code to Boost on the Mac? This means a need to install Boost on several Macs including some G3 Tiger Macs and a Jaguar (!) PowerMac 7500.

3) I've got Boost on by Ubuntu box, but not on my old and non-upgradable Red Hat 9 rackmount. Is it possible to install Boost on a 2003 Red Hat system and hope for success?

[Gian-Carlo Pascutto]

I'm considering moving to Boost for the Windows implementation of Symbolic. I note that Cygwin has Boost 1.33.1 available although I haven't tried it yet as I'm currently using Cygwin's pthreads implementation. I'd much rather be coding chess than screw around with system issues. The questions are:

1.33.1 is quite old (more than a year). I think you'll want at least 1.35, because that includes the Asio (=sockets) library and a thread implementation that conforms closely to the new C++ standard. For Windows you can install from source, the library lives entirely in its own directory.

1) Do the Boost libraries and header files work with MSVC++ Express?

Yes, very well. You point it once to the libs and includes dir, it's smart enough to automatically link the correct debug/static/... version etc. (This is a strong advantage of MSVC over GCC, which can't do that).

2) Is it worthwhile to convert my working pthreads code to Boost on the Mac? This means a need to install Boost on several Macs including some G3 Tiger Macs and a Jaguar (!) PowerMac 7500.

pthreads is fairly portable (there is a Windows port as you mentioned), so I'm not sure if you will gain much in that case, your code is already portable...

3) I've got Boost on by Ubuntu box, but not on my old and non-upgradable Red Hat 9 rackmount. Is it possible to install Boost on a 2003 Red Hat system and hope for success?

I don't know. I could imagine the compiler would be so old that it won't accept some legal C++ constructs.

You could compile on another platform and try linking statically, though.

[sje]

For Cygwin, Boost 1.33.1 is the latest version available. For Ubuntu, version 1.34.1 is the standard with 1.35.0 available.

The Jaguar PowerMac has g++ v2.95, and the old version of Symbolic would trigger some compiler optimizer bugs with certain 64 bit integer constructs. The new Symbolic core is okay with this, though. The Red Hat 9 box g++ works fine with Symbolic although some adjustments are needed with including system header files as a few symbol definitions have migrated over the years.

A more problematic issue with the old compilers is the handling of the std::string type. The old Symbolic didn't use it at all because of purported memory leaks with early compiler run time implementations, but the new Symbolic core uses the type whenever appropriate.

I could live without Jaguar compatibility; the PowerMac is twelve years old and not very fast. I just don't like junking hardware that still works. The Red Hat box has seen more than 50,000 hours and I won't be too surprised if it conks out someday soon, so maybe compatibility isn't too much of an issue there as well.

I'm not interested in Cygwin all that much if a Windows version of Symbolic can be made without too much grief. Also, the behavior of setitimer() in Cygwin is a bit shaky with short (~10 ms) interval values.