David Abrahams wrote:
Do you seriously think that reading the thought processes that led youYes, if they were asking the same question, which in my response to your post was no longer about quotes (was that unclear?). My problem was the IMHO unexpected and atypical behavior of bjam when MATCH (and therefore regex.*) encountered an escaped close bracket in a negated character set ( [^\]] is not equivalent to [^]] ), _after_ escape processing had occurred at the string literal level. Your example was quite helpful, as it was the best (only?) explanation I have seen to date for escape expansion in bjam string literals, but my "brain dump" was about a conundrum that remained after eliminating those effects.
to misunderstand bjam will help someone more than
"quotes don't prevent backslashes from acting like escapes."
with an accompanying example?
As it turns out, bjam's MATCH uses egrep style regular expressions - it's even says so in the jam documentation (if you can actually find it) although it doesn't say any more about what they should look like. And egrep (at least on one of my Linux systems) behaves the same way ( [^\]] fails, [^]] works ), and more or less says so in the man pages : "To include a literal ] place it first in the list.". Unfortunately egrep is one of those Unix-specific utilities not commonly available under Windows. In my experience, you're much more likely to find perl or python on a Windows box than cygwin or the like. And in perl, or python, or CodeWright, or even the MSVC IDE, [^\]] works just fine (in fact, [^]] fails on MSVC 6.0 and 7.1). Hence my concern that this is rather non-intuitive behavior, at least for us in the egrep-ignorant subset of those who regularly rely on regular expressions - and I suspect there are quite a few of us! (although the intersection between that subset and the subset of Boost users who will ever need to write a regular expression in a jam file might admittedly be thin. real thin ;) )
Well, I guess people needing help have different styles, but if I wereAgreed, if I had simply been trying to expand on your quite elegant synopsis for "string literal" escape processing in bjam. Either way (string escapes or regex pattern rules), its frustrating to go searching in the docs for such basic stuff and come up empty. While I am thankful for the existing bjam documentation, and I've certainly found it useful, bjam is a very powerful tool with some nasty, sharp, hidden edges which demands a good bit of skill, will, and patience to use well. With all due respect, you _wrote_ many of the current docs for bjam, so it might have lost some perspective on the kind of help the average joe new to Boost and using bjam might need, even if you weren't a friggin genius to boot (I get this image of Chick Corea trying to teach a normal five year old to play piano ;) ).
looking for quick help with this problem I would not have been drawn
to read your brain dump, and had I read it I doubt it would have been
much help.
Anyhow, the learning curve for merely building existing libraries with bjam gets steep fast when things don't "just work", and it gets worse from there trying to create new projects. While this may be an annoyance for the average current Boost user, it could become a major roadblock to Boost's growth beyond hard core C++ aficionados unless we do better. I want to see Boost grow, so I'm very interested in finding ways to get rid of these roadblocks. Consistent, comprehensive documentation is IMHO one of the key ingredients to making Boost more accessible to the "average" developer, which is why I've been spending so much time here.
Well hopefully that's the end of it... since this might border on ridiculous in any of the other forums! Although I also hope it has been only mildly obsessive, at least moderately entertaining, and perhaps someday even useful here in boost.docs. :)Don't worry, I won't flog this issue any further in this forum.
- james
--
__________________________________________________________ James Fowler, Open Sea Consulting http://www.OpenSeaConsulting.com, Marietta, Georgia, USA Do C++ Right. http://www.OpenCpp.org, opening soon!
------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click _______________________________________________ Boost-docs mailing list [email protected] Unsubscribe and other administrative requests: https://lists.sourceforge.net/lists/listinfo/boost-docs
