Maybe it would also be good to keep boost includes out of external headers. For example, many public headers currently include boost::thread headers, at first glance mostly because data-structures contain boost::thread types by value. A PIMPL pattern could probably get rid of most of those. The advantage would be that by recompiling just a small set of "core" packages, any system boost could be supported. cheers, Ingo On Thu, Feb 20, 2014 at 5:43 PM, Brian Gerkey wrote: > That's great feedback. We were just discussing this issue the other day > and came to the conclusion that we should start new projects (e.g., ROS 2) > using what's now in the standard, and only pull in boost if it becomes > really necessary. The cost of this approach is that you need a reasonably > modern compiler, but that seems like a good trafeoff to make. > > brian. > On Feb 20, 2014 8:01 AM, wrote: > >> On the boost topic, I have been a boost fan for many years... until >> having to support multiple versions. Recently I changed all our core to >> use C++0x equivalents which fixed the dependency issues, and surprisingly >> compiles 30% faster. (basically boost #include's a massive number of >> headers, while gcc equivalents do not) >> >> This is an important point for moving forwards with ROS simplicity in >> addition to API and tutorial type usability. Make use of what the compiler >> provides while avoiding "tricks" in the language (some template solutions >> out on the web are cool, but eat up compile time and complexity. >> *cough*mpl*cough*). Even something as common as Boost has potentially nasty >> dependency and code complexity issues. Maybe retrofitting roscpp is a poor >> use of resources at this time, but moving forwards with new code or ROS2.0 >> it makes sense. >> >> -----Original Message----- >> From: ros-users-bounces@lists.ros.org [mailto: >> ros-users-bounces@lists.ros.org] On Behalf Of kamicc olo >> Sent: Thursday, February 20, 2014 8:56 AM >> To: User discussions >> Subject: Re: [ros-users] ROS usability >> >> Been facing an issue with SSE and ARM for some time either. Not >> mentioning libboost... >> >> On 2/20/14, Arkapravo Bhaumik wrote: >> > Agree on the redundancy of packages (read xkcd zindabad) and the boost >> > issues ! Have faced serious boost issues. >> > >> > >> > On 20 February 2014 18:36, Michael Fritscher < >> > michael.fritscher@telematik-zentrum.de> wrote: >> > >> >> Hallo everybody, >> >> >> >> just my 2 cents: >> >> >> >> In my oppinion, the ROS core is fairly well documented and quite >> >> useable >> >> - >> >> both for beginners and advanced users. The problem are in my oppinion >> >> many of the packages. Most of the packages are more or less drivers >> >> for robots or middleware things. But even e.g. on the usb camera side >> >> there are at least 5 different drivers (see >> >> http://www.iheartrobotics.com/ >> >> 2010/05/testing-ros-usb-camera-drivers.html and >> >> http://pharos.ece.utexas.edu/wiki/index.php/How_to_Use_a_ >> >> Webcam_in_ROS_with_the_gscam_Package ) - why the heck we do need at >> >> least >> >> 5 drivers for a simple thing like capturing webcam pictures?! I know >> >> that there are different requirements, but forking isn't always the >> >> best solution... >> >> >> >> Additionally, many plugins aren't that usable. Are little example are >> >> localization using 1 or 2 video cameras. viso2_ros doesn't need sse2, >> >> which is a no-go for ARM-cpus which are getting more and more >> >> popular. >> >> PTAM is at least compiling, but it even fail to correctly display the >> >> video image (both on arm and on a normal x64 laptop). Sometimes it >> >> remembers me about https://xkcd.com/927/ ... >> >> >> >> Another problem is in my oppinion the library-hell problem. ROS >> >> packages are tightly tied with specific library version (e.g. >> >> libboost) which >> >> (roughly) exists only on one specific distro-version. This makes it >> >> almost inpossible to use binary versions of ros on another distros. >> >> Perhaps this can be solved that the binary packages depend on e.g. >> >> "libboost-1.42 | roslibboost-groovy" - so either the distro-version >> >> or a ros-own version can be used. >> >> >> >> Best regards, >> >> Michael Fritscher >> >> >> >> -- >> >> ZfT - Zentrum für Telematik e.V. >> >> Michael Fritscher >> >> Allesgrundweg 12 >> >> 97218 Gerbrunn >> >> Tel: +49 (931) 3 29 29 54 - 21 >> >> Email: michael.fritscher@telematik-zentrum.de >> >> Web: http://www.telematik-zentrum.de >> >> >> >> _______________________________________________ >> >> ros-users mailing list >> >> ros-users@lists.ros.org >> >> http://lists.ros.org/mailman/listinfo/ros-users >> >> >> >> >> > >> > >> > -- >> > *Arkapravo Bhaumik* >> > >> > >> > http://mobotica.blogspot.in/p/head.html >> > >> _______________________________________________ >> ros-users mailing list >> ros-users@lists.ros.org >> http://lists.ros.org/mailman/listinfo/ros-users >> >> ------------------------------------------------------- >> This is an e-mail from General Dynamics Robotic Systems. It is for the >> intended recipient only and may contain confidential and privileged >> information. No one else may read, print, store, copy, forward or act in >> reliance on it or its attachments. If you are not the intended recipient, >> please return this message to the sender and delete the message and any >> attachments from your computer. Your cooperation is appreciated. >> >> _______________________________________________ >> ros-users mailing list >> ros-users@lists.ros.org >> http://lists.ros.org/mailman/listinfo/ros-users >> > > _______________________________________________ > ros-users mailing list > ros-users@lists.ros.org > http://lists.ros.org/mailman/listinfo/ros-users > > -- Ingo Lütkebohle, Dr.-Ing. Machine Learning and Robotics Lab, IPVS, Universität Stuttgart http://www.ipvs.uni-stuttgart.de/abteilungen/mlr/abteilung/mitarbeiter/Ingo.Luetkebohle +49-711-685-88350 PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F 57D4 CD90 C164 34AD CE5B