RE: Dependencies for tokenizer?
Any ideas about how to get this functionality w/o all the headers? Thanks, -- Tony K. In order to use the tokenizer classes I end up requiring 47 files, which
What's wrong with 47 files? How much longer does it take to compile?
It actually does slow things down noticeably, since it's a small project.
He might be sub setting boost and only wants to include the needed files.
Exactly. I have 47 more files checked into source control that everybody else has to download (and have the tool check every time they refresh) so that I can parse a command line. I suppose I could check in the whole boost library, (~2000 files in the download I got,) but I'd rather just take what I need for now.
Anyway, this was brought up during the review, but at the time only 20 files were needed (the very first tokenizer only need 2 boost headers). It was the switch to iterator_adaptors that caused the include explosion at the time...
Evidently reviewers thought 20 was reasonable, and I assume that some major problems are solved by the 47 headers that weren't by 20. I just wondered if there was a lighter weight way in boost to do my little tokenizing task. Is there? -- Tony K.
Evidently reviewers thought 20 was reasonable, and I assume that some major problems are solved by the 47 headers that weren't by 20. I just wondered
I was the person that raised the point in the review. I wasn't asking for changes, b/c I didn't consider dependence on other boost libraries to be a big issue. On projects where I have used boost we didn't try to remove the libraries we weren't using, so this wasn't an issue. So that's the history, unfortunately this doesn't solve your problem...
if there was a lighter weight way in boost to do my little tokenizing task. Is there?
I'm sure there is. It is a matter of getting the "25 lines of actual code" (my guess) in those 47 headers that tokenizer really needs into a small header. I'm sure with a small effort you could do it. Perhaps you could even find a way to improve the overall design in the process. Jeff
on 1/29/02 4:36 PM, Jeff Garland at jeff@crystalclearsoftware.com wrote:
Evidently reviewers thought 20 was reasonable, and I assume that some major problems are solved by the 47 headers that weren't by 20. I just wondered
I was the person that raised the point in the review. I wasn't asking for changes, b/c I didn't consider dependence on other boost libraries to be a big issue. On projects where I have used boost we didn't try to remove the libraries we weren't using, so this wasn't an issue. So that's the history, unfortunately this doesn't solve your problem...
if there was a lighter weight way in boost to do my little tokenizing task. Is there?
I'm sure there is. It is a matter of getting the "25 lines of actual code" (my guess) in those 47 headers that tokenizer really needs into a small header. I'm sure with a small effort you could do it. Perhaps you could even find a way to improve the overall design in the process.
Some percentage of these files will be support for config,hpp. I can't remember if tokenizer was added before or after the change away from single file. Tony, We use boost in the same way that Jeff does. We add a particular release to our version control and then typically do not upgrade boost unless really necessary for the life the project. As long as you keep boost stable the additional files aren't too onerous. Chris
On Tue, 29 Jan 2002, Jeff Garland wrote: jeff> jeff> I'm sure there is. It is a matter of getting the "25 lines of jeff> actual code" (my guess) in those 47 headers that tokenizer jeff> really needs into a small header. I'm sure with a small jeff> effort you could do it. Perhaps you could even find a way to jeff> improve the overall design in the process. Well, it could get a little messy. The iterator adaptors use some stuff from the type_traits headers, which have lots of workarounds for different compilers, etc., etc. For a super simple C++ stringtok see the header boost/pending/stringtok.hpp It's not an official boost library, but you might find it fits your needs. Cheers, Jeremy ---------------------------------------------------------------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek@osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 855-3608 ----------------------------------------------------------------------
participants (4)
-
Anthony Kolarik -
Chris Little -
Jeff Garland -
Jeremy Siek