Re: [Boost-cmake] 1.40.0.cmake5 (?) builds cleanly
On Monday 21 December 2009 10:53:15 Denis Arnaud wrote: 2009/12/21 Vladimir Prus vladi...@codesourcery.com IIUC, mpi.so is a Python extension? If so, soname makes little sense for it. Python extensions on my system appear to have or not have soname at random. Yes, mpi.so is a Python extension, that is, pulling Python (libpython2.x) Boost.Python (libboost_python) as a dependency, and allowing Python programs to use Boost libraries. As I understand, it should also pull Boost.MPI (libboost_mpi) as a dependency (but in the version I have, boost-1.41.0-cmake0, it does not). Well, if mpi.so does not have a dependency on libboost_mpi, this is a separate matter from it not having a soname. I still think that not having a soname is fine, while not having a dependency on libboost_mpi sounds like a bug. (FOAD, I am obviously not in position to fix that bug) Then, the question is: where (in which dedicated directory) should that library (mpi.so) be delivered? Looking at https://fedoraproject.org/wiki/Packaging/Python I see paths like: /usr/lib/python2.4/site-packages Does it seem like it's gonna work? BTW, 'mpi.so' sounds too generic, using 'boost_mpi.so' would be better IMO. - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix
Sean Chittenden wrote: For sure it is. Debian is my primary platform and I'd like this to be seamless. I've pondered support for multiple simultaneous installations, possibly with a layout like this: Because of the trickery of the loader using unresolved symlinks (for non-statically linked apps, but who does that with boost?), please don't do something convenient like: /usr local lib boost-1.40.0 boost-1.41.0 boost - boost-1.41.0 Lazy developers will use boost and not boost-1.40.0 and suddenly things will break in strange, hard to figure out ways. Could you clarify what will break? - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Configuration for sonames for the boost dynamic libraries on Unix
Denis Arnaud wrote: 2009/10/28 troy d. straszheim t...@resophonic.com Would it be possible to have the option, with CMake build, to use a more conventional soname, so that Linux distribution packagers (Debianers and RPM-based packagers such as me, for instance) be happy (i.e., have less extra code to write)? So, like this (?): % ls -l build/lib total 1352 libboost_iostreams-mt-d.a libboost_iostreams-mt-d.so - libboost_iostreams-mt-d.so.1.41* libboost_iostreams-mt-d.so.1.41 - libboost_iostreams-mt-d.so.1.41.0* Whether this link should be present depends on whether soname has 1.41 or 1.41.0 at the end. If it has 1.41.0, to reflect the lack of any BIC between any versions of Boost, then 1.41-1.41.0 symlink is not really necessary. And whether point releases are required to have any binary compatibility or not is a tricky question, especially given that upstream does not want any point releases at all. libboost_iostreams-mt-d.so.1.41.0* libboost_iostreams-mt.a libboost_iostreams-mt.so - libboost_iostreams-mt.so.1.41* libboost_iostreams-mt.so.1.41 - libboost_iostreams-mt.so.1.41.0* libboost_iostreams-mt.so.1.41.0* Yes, exactly :) And the soname would read something like: $ readelf -a /usr/lib/libboost_date_time-mt.so | grep -i soname 0x000e (SONAME) Library soname: [libboost_date_time-mt.so.4] (that example is taken from Fedora 11, with Boost 1.37.0; the soname version is fixed within the RPM specification file). This might be obvious, but such a soname would be wrong if the above naming of libraries is used, since there would be no libboost_date_time-mt.so.4. - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Testing dependencies
Brad King wrote: David Abrahams wrote: I just realized we need a feature (surprise!) When I'm working on a Boost library, I need to be able to fire off all the tests of libraries that depend on the one I'm changing, to make sure I'm not breaking anything in the library collection before I check in. We discussed this at length during the BoostCon meeting, right? Currently CTest always runs all tests, which is *sufficient* to catch breakages. The problem is that it is not *necessary* to run all tests. This is the incremental re-testing feature. CTest is not aware of any build-system dependencies since they are all stored in platform-specific ways. Making it aware would require implementing most of a build-system in CTest. The solution to this problem was the last step of those we outlined on the board near the end of the meeting. We need to convert all tests to normal build rules using custom commands created by CMake. Then full build-system dependencies are available and incremental re-testing is possible. This is what Troy's custom-target-per-test approach last year tried to do, but it was not scalable. In what way, and why and can *that* be fixed? Instead all tests for each library need to be combined into one custom target that uses custom commands to drive tests. I can provide more details when the time comes. However, the major step before that is to package all tests for each library into test-driver executables. This is useful whether using bjam or CMake because it drastically reduces the total link time and disk space used for building tests. While it definitely will result in *some* improvement in that, it is not apparent such global and surely painful rearrangement is truly good idea. Not to mention that somebody would have to change the current reporting mechanisms. - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CMake Problems with boost 1.39
Tan, Tom (Shanghai) wrote: This is a re-post from the boost-users list, Thanks to Troy d. straszheim who reminded me there that there's a dedicated list here. I used CMake to build boost 1.39 and found at least two problems: - In the cmakelist.txt file the BOOST_VERSION_MINOR is 38, instead of 39 - The generated boost.test libs have an additional -s to the file names, ex. libboost_unit_test_framework-vc90-mt-1_39-s.lib, instead of libboost_unit_test_framework-vc90-mt-1_39.lib. This will cause a linking error while using boost.test. this does not happen to the bjamed results. Another thing I noticed but am not sure is that signal2 is not included in the CMake support(no cmakelists.txt under signals). It seems the cmakelist.txt file is still that of 1.38. By the way, I was very happy to have found and tried CMake in the Boost 1.38 release. Not that it compiles fast, but it has easier fine-tune of the compiler: I would have to open each individual jam file to define _BIND_TO_CURRENT_VCLIBS_VERSION in order to link those bins to the latest vc9 sp1 runtime, You are wrong. You can either add: define=_BIND_TO_CURRENT_VCLIBS_VERSION to command line or edit Jamroot to set a define for all of Boost. - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash dashboard now available
On Monday 11 May 2009 19:40:35 Doug Gregor wrote: On Mon, May 11, 2009 at 6:55 AM, Vladimir Prus vladi...@codesourcery.com wrote: On Monday 11 May 2009 01:24:08 Beman Dawes wrote: I'm going to experiment with pre-built binary installers, with an eye to supplying them for the 1.40.0 release. For what platforms? Windows and Mac will give us the biggest bang, I think. Building binaries for Linux is better left to the distribution maintainers, and with Windows and Mac we get the graphical, component-based installers that allow people to get a subset of Boost. Do you, or anybody else, have an installer I can play with? It does not matter if that's beta-quality, or alpha-quality, or even barely-working. - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash dashboard now available
On Tuesday 12 May 2009 20:50:19 Doug Gregor wrote: On Mon, May 11, 2009 at 9:27 AM, Vladimir Prus vladi...@codesourcery.com wrote: On Monday 11 May 2009 19:40:35 Doug Gregor wrote: On Mon, May 11, 2009 at 6:55 AM, Vladimir Prus vladi...@codesourcery.com wrote: On Monday 11 May 2009 01:24:08 Beman Dawes wrote: I'm going to experiment with pre-built binary installers, with an eye to supplying them for the 1.40.0 release. For what platforms? Windows and Mac will give us the biggest bang, I think. Building binaries for Linux is better left to the distribution maintainers, and with Windows and Mac we get the graphical, component-based installers that allow people to get a subset of Boost. Do you, or anybody else, have an installer I can play with? It does not matter if that's beta-quality, or alpha-quality, or even barely-working. I can build one for Mac OS X tonight. Do you have access to a machine running Mac OS 10.4 or 10.5? Not really -- x86 would be more convenient. - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] CDash dashboard now available
On Monday 11 May 2009 01:24:08 Beman Dawes wrote: I'm going to experiment with pre-built binary installers, with an eye to supplying them for the 1.40.0 release. For what platforms? - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
Re: [Boost-cmake] Variant Builds and missing libraries
Michael Jackson wrote: On Nov 12, 2008, at 11:39 AM, David Abrahams wrote: on Wed Nov 12 2008, Michael Jackson mike.jackson-AT-bluequartz.net wrote: Came across an interesting situation while doing some testing on the CMake build system. I configured my build tree to be SHARED+MULTI- THREADED+DEBUG. When I built I was almost immediately getting an error about not being able to link against boost_test_exec_monitor-mt- shared. Which is wrong because test_exec_monitor is a static-only library. As I walked through the CMake code to track down what was the problem I basically discovered for myself that if you have BUILD_STATIC=OFF then NO static libraries will be built, which has the side effect of disabling any regression test that relies on the test_exec_monitor. Question: Is this desired behavior? (I wouldn't think so but I would rather hear that from a boost dev) Well, you'd need a Boost-CMake dev, of which there are few, to tell you what BUILD_STATIC=OFF is supposed to mean. However, my guess is that it's really for deciding which library variants you're going to build and install, not what can get built as part of a dependency chain. Frankly, even in the build/install case, it seems implausible that people could be unhappy when a static-only library is built statically when the shared variant is requested. I would err on the side of building rather than not building, and let people use --without- libname or whatever its CMake equivalent is if they want to leave it out. I chatted with Volodya on the #boost irc channel and basically if you are doing regression testing then all the variants are built. Err, I did not say that. I said that Boost.Build does not need any up-front build of anything -- if you want to run regressions with specific properties, it will build all that's needed. - Volodya ___ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
[boost] Re: [BGL] Missing open delimiter for HTML tag indijkstra_shortest_paths.html
Janusz Piwowarski wrote: Hi, As in subject: first line, first character. Fixed, thanks! - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [BGL] Recent patch to depth_first_visitor.hpp breaks depth_first_search
Vladimir, The patch you recently checked in: revision 1.36 date: 2003/08/28 11:48:59; author: vladimir_prus; state: Exp; lines: +53 -18 Implement depth_first_visit variant which allows to stop the search at certain vertices. breaks depth_first_search by aborting before it starts unless a different TerminatorFunc is specified. I've checked in the patch below to fix this. Hi Doug, Apologies for breakage and thanks for fixing it. In fact, I've noteced this problem when running some BGL tests some time ago and made precisely the same fix. But... in a different location than the one I've comitted from :-( Oh... well. Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [BGL] vector_as_graph::remove_vertex proposal
Hi Janusz,
Janusz Piwowarski wrote:
I found remove_vertex member for vector_as_graph isn't implemented.
It's my proposal:
Thanks!
templateclass EdgeList, class Allocator
void
remove_vertex(typename EdgeList::value_type u,
std::vectorEdgeList, Allocator g)
{
typedef typename EdgeList::iterator iterator;
clear_vertex(u, g);
g.erase(g.begin() + u);
for (std::size_t i = 0; i g.size(); ++i)
for ( iterator it = g[i].begin(); it != g[i].end(); ++it )
// after clear_vertex none *it is equal to u
if ( *it u )
--*it;
}
The implementation is fine, AFAICT. The only problem with me is the comment:
I couldn't understand it for the first time because none *it sounded
confusing. Maybe *it is never equal to u is better?
BTW, if you could sumbit unified diff instead of new implementation, that
would be nice. If that's not convenient for you, no problem. I can apply
the thange anyway.
Thanks,
Volodya
Regards,
Janusz
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [bgl] typo in adjacency_list_io.hpp
Hi Janusz, Janusz Piwowarski wrote: Hi all gcc 3.2 generates warnings about implicit typename in line 313 in file adjacency_list_io.hpp. I think either there should be EdgePrinterG,E call or class G should be renamed to Graph, as is in the rest of templates in this file. Thanks for pointing this out. Changes to 'Graph'. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: program_options multiple source question
Hi Neal,
Neal D. Becker wrote:
I'm lost with trying to use the (unreleased) program_options lib.
I have no problem to use with just command line, but I'd like to have both
command line and config file.
Here's what I tried:
try {
options_description desc(Allowed options);
desc.add_options()
(help, , produce help message)
(esNodB,e, parameterdouble (value, esnodB), Es/No(dB))
(maxBursts,m, parameterint (value, maxBursts), stop after
#bursts)
(maxErrors,M, parameterint (value, maxErrors), stop after
#errors)
;
options_and_arguments opts = parse_command_line(argc, argv, desc);
variables_map vm;
store(opts, vm, desc);
ifstream ifs(TestUWP.cfg);
options_and_arguments opts2 = parse_config_file(ifs, desc);
variables_map cfg_file_vm;
store(opts2, cfg_file_vm, desc);
vm.next(cfg_file_vm);
if (vm.count(help)) {
std::clog desc \n;
return 1;
}
}
catch(std::exception e) {
std::cerr error: e.what() \n;
return 1;
}
I get this message:
error: config file options should have required parameter
I tried various variations, and also referred to the multiple_sources
example,
but I still can't find out what's wrong. Any clues?
The help option has no parameter. The program_options library does not
allow only (name,values) pairs in config file, so it complains about such a
option. One solution is to greate to option_descriptions instances: one for
command line only and one for general parameters. You can then combine
instances for command line parsing and pass only one to config file parser.
Of course, I'm open for other suggestions.
- Volodya
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: XMLUI (was Re: Re: UI++)
Hi Paul, Paul Hamilton wrote: Is there a URL available for samples we could look at? Talking about an XML user interface description isn't something I can do in the abstract. No URL yet. I'll setup a SourceForge project for it and post the whitepaper. It's really not in a state where it can be used right now, since it's all proprietary C++ code. I'll let you know when I get the SF stuff done. May I come with a bit of scepticism? There's already XUL (see http://xulplanet.com for a start, and http://www.mozilla.org/catalog/architecture/xul/ for more details). I think Mozilla folks put some effort into it, so I wonder if XMLUI offers something new/better? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem: create_directories
David Abrahams wrote: The documentation for create_directories makes no sense. It says only: void create_directories( const path ph ); Precondition: ph.empty() || forall p: p == ph || is_parent(p, ph): is_directory(p) || !exists( p ) Postcondition: exists(ph) is_directory(ph) It looks as though this is the same as create_directory, but has a weird precondition. Sure. It has the (almost) the same postcondition, but has waeker precondition: the parent directories are not required to exist. I swear I was *completely* baffled by its purpose until I looked at the header file. I'd say that pre/post conditions are just correct. Maybe more docs can be added. The comment in the header file describes it pretty well, though. Ehm... only postcondition there is not correct: is_empty(ph) is not guaranteed. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Sudden VC6 ICEs in BGL code
David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: Jeremy Siek [EMAIL PROTECTED] writes: I seem to remember the named parameters mechanism being fragile under VC6. After a painstaking binary search in recent CVS states for the ICE, I narrowed it down to: snip Worked around now in CVS. Had no idea my innocent change will break anything. Why doesn't vc6 like declarations of static methods inside class? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Re: Filesystem: create_directories
Reid Sweatman wrote: Another option might be: create_directory_and_parents That name is longer than create_directories although it better describes the function. I like create_directory_path That one's good, and captures the essential distinction well. Other possibles: create_full_directory, or create_rooted_directory. Dunno. On whole, I might prefer your choice. Although it again lengthens the name, create_directory_and_path captures another minor piece of the distinction. You could also play with the distinction (none save semantic in most file systems) between pathname and filename; a filename is usually just the thing at the leaf-terminal end of the path (and needn't be a file, save as a directory is often actually implemented as such), while the pathname is the full Monty. FWIW, I don't like - create_full_directory, because I don't understand what it means for directory to be full. Full of files is one interpretation which is not correct. - create_rooted_directory, because I don't know what's rooted directory. - create_directory_and_path, because how if one can create directory, one can name that directory, and the path should already exist. So, to summarize, I've no problem with the current name that I've introduced. Of other suggestions create_directory_and_parents looks best to me. ensure_directory_exists does not imply any operational semantic (i.e. the name does not say that the directory will be created. One might expect exception to be thrown if dir does not exist). demand_directory is good. One problem is that demand still does not communicate to me that something will be created. - Volodya In the original scheme, I would think the problem with create_directories is that it would seem to imply (to me, at any rate) the creation of multiple directories at the same depth in the file system. Anyway, them's my kibitz's. Reid Sweatman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [bgl] null vertex
FYI, I've just comitted a patch which adds the concept of 'null vertex' to BGL. If 'G' is a graph type, then graph_traitsG::null_vertex() will return vertex_descriptor which does not refer to any vertex. Of course, that value is never returned by add_vertex. I found this concept usefull in some code of mine, and I recall somebody asked for it long time ago. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Handling unix-characters with boost::filesystem (bug776146)
Hi Erkki,
Erkki Seppala wrote:
Source-code of a utility to remove those files from directory2 that
exist in directory1. It fails if any filename in directory1 contains a
':' (and I expect it'll fail with numerous other characters too):
[...]
for (fs::directory_iterator it(base);
it != end;
++it) {
std::cout Removing it-leaf() std::endl;
fs::remove(*it);
fs::remove(base2 / it-leaf());
[...]
testing: mkdir foo bar; touch foo/a foo/: bar/a bar/: bar/c; ./baz foo bar
As this behavior (handling certain characters differently on systems
that can handle them) seems to be a designed feature, I must raise my
concern that I really don't want to see a generation of unix-programs
that fail to handle some files I have in my hd. The program above
would seem to me to be perfectly portable even if had the ability to
handle all kinds of characters in filenames. (I wouldn't want to
resort to using some depreciated native-interfaces to accomplish that
either.)
I tend to believe that you've found a bug in filesystem library. It's
possible to take native path with : as last component. It possible to
extract that last component. But path::leaf returns string, so
base2 / it-leaf()
expression tries to convert : into path, and fails. It seems to be that
one I've converted native path into path instance, it should not complain
about disallowed characters. The above example works if I write
base2 / fs::path(it-leaf(), fs::native)
but this does not look like a solution... The real solution, IMO, would be
to make leaf() return path instance, but I don't know the rationale for
making it return string, so maybe this idea is not good. Beman, could you
comment?
And answering to Vladimir Prus on the bug report: I would hate to see
a program that was not able to create, manipulate and unlink certain
files, just for the sake that some other platforms have problems with
those characters. Handling files called ' ', '*?' isn't a problem for
me. I have almost a 1000 files with character : (perl manual-pages)
and some with letters and .. (think message-id's)
I don't think anybody will be happy with prohibiting to work on files with
special characters. It's only required to pass fs::native when you create a
path from external path name which can include system-specific characters.
(Btw, why is this a library-issue at all anyway? I'm sure the
operating system is more than pleased to tell the program that the
filename is invalid.)
Sometimes so, sometimes not. Imagine you pass a filename to system call,
something like
system(foobar + file.native_file_string())
Ok, and file is somefile rm -rf /. So this will wipe your entire
harddrive. You need to to some checks, naturally. With the current design,
you only have to do the checks when you accept input from external sources,
i.e. when you pass fs::native to ctor. If no checking for special symbols
is done, you have to examine all places where path objects are created.
Until now, I was not too troubled by fs::native. I usually create paths from
native strings in a few places and then manupulate the resulting paths.
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.Build V2, Milestone 6 released
I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m6.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m6.zip See also http://boost.sourceforge.net/boost-build2/ for online docs (a copy is included in distribution). Changes in this release are: - Segfault on use of RMOLD builtin fixed. - The gcc toolset handles threadingmulti now. - A bug which blocked update of certain targets was fixed. - BoostBook support was improved. - Boost.Build bootstrapping was improved. - A bug which caused wrong suffix to be used when linking to prebuilt targets was fixed. - A bug which prevented free features, like define from being specified in user-defined build variants was fixed. - Detection of loops in main target references was added. - Bug with : symbol in properties was fixed. - Bug which caused inline targets to be confused with top-level ones of the same name was fixed. Since some bugs are important, all users are advised to upgrade. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: plans for a bugfix release ?
From: Alisdair Meredith [EMAIL PROTECTED] Only *critical* fixes to the 1.30.0 release. What about updated compiler configs? For instance, Borland released a compiler update pretty much the same week that Boost 1.30 went out, so several version checks fail. Any other compilers release a point upgrade that can be easily integrated? Yes. g++ 3.3 is not recornized by 1.30.0. This is mostly harmeless, except for a annoying warning on using almost every boost header. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] iteration macros
Hi Csaba, Iteration macros did not work without some 'using' directives because it uses functions from boots but actually without the boost:: qualifier. E.g. BGL_FORALL_VERTICES(v,g,graph_t) did not compile unless you have using namespace boost or using namespace boost::vertices before the invocation of the macro. Pls find attached iteration_macros.hpp that corrects this problem. Thanks for sending this patch! Unfortunately, I don't think it's correct. The problem is that if I define my own graph type, then functions like vertices are not likely to be defined in namespace boost. Therefore, if your patch is applied, user-defined graph types are no longer usable with iteration macroses. Why the change is needed? Are you on a compiler which does not implement argument-dependent lookup? (BTW, it's more convenient if you send your patches as unified diff against the unmodified sources, in MIME attachment, not uuencoded) Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [test] shared library build broken
Vladimir Prus wrote: When trying to used current Boost.Test CVS HEAD state as shared libraries, I get errors from linker: Oops! Seems like I did not picked up changes to Jamfile. Sorry for the noise. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] shared library build broken
When trying to used current Boost.Test CVS HEAD state as shared libraries, I get errors from linker: ../../../libs/test/build/bin/libboost_unit_test_framework.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/libboost_unit_test_framework.so: undefined reference to `boost::unit_test_framework::detail::msvc65_like_log_formatter::msvc65_like_log_formatter[in-charge](boost::unit_test_framework::unit_test_log const)' ../../../libs/test/build/bin/libboost_unit_test_framework.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/libboost_unit_test_framework.so: undefined reference to `boost::unit_test_framework::detail::xml_log_formatter::xml_log_formatter[in-charge](boost::unit_test_framework::unit_test_log const)' collect2: ld returned 1 exit status To reproduce, just change lib to dll in examples/Jamfile and run bjam. I had the above errors with gcc 3.3 on Debian Linux. Is it possible to fix the problem? TIA, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.Build V2, Milestone 5 released
I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m5.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m5.zip See also http://boost.sourceforge.net/boost-build2/ for online docs (a copy is included in distribution). Changes in this release are: - Complete support for include dependencies between generated sources was implemented. - GNU gettext support was implemeneted. - inline targets were implemented. - Autoconfiguration of msvc and borland toolsets was improved. - Bug with causes linking to system libraries to fail on windows in some cases was fixed. - Bug which prevented linking to system libraries with '.a' suffix on windows was fixed. - Support for linkflags and archiveflags features was added to borland toolset. - The implicit build of target can now be suppressed with explicit rule. - Documentation was improved and new examples were added. All users are advised to upgrade. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Cvs trouble
Toon Knapen wrote: The boost-sandbox is showing some strange behaviour. When checking out the boost-sandbox/numeric/bindings/traits/type.h using the :ext: server I get version 1.3 (on the HEAD), with :pserver: it's only 1.2. The WebCVS also only shows up to version 1.2. That's the same as with main boost repository. All pserver accesses and ViewCVS accesses go to backup server. As some document on sourceforce says, the performance of hardware that they have is not enough to serve all acesses from main server. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] Yet another patch for nonrecursive DFS
Hi Bruce, Vladimir Prus wrote: There's another question: why store u at all. I'm guessing source(*ei, g) might be more efficient? That's a good thought, but there might be a problem trying to dereference a past-the-end iterator. I mentioned before that ei_end could always be generated from u instead of storing it, but it's just a question of trading cycles for bytes. Which resource is more critical? I don't know. It *seems* that source(*ei, g) should be pretty fast, but only seems. 1. It needs license from you. Can you copy the standard license in for me? Done. 3. Maybe, the FAQ, either fully or partically, must be added too. How about adding: // FAQ's can be found at: // http://lists.boost.org/MailArchives/boost/msg48752.php If you happen to know that one of those links can be counted on to persist, then the other three aren't really needed. I think the first link is reliable. Your patch is now comitted to CVS. Thanks! - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: tokenizer comments
Hi Pavol, Pavol Droba wrote: I'm already aware of string_algo and using it a bit. I wasn't aware it has tokenizer component, though. It was added only a few days ago along with some other improvements and more stuff is comming in the near future. Ah... the problem is that those new additions are not documented, AFAICT ;-) It makes it a little bit hard to understand the interface, especially since there are no examples/tests for split functionality. One of them is the integration with the container_traits idea proposed by Jeremy Siek and Thorsten Ottosen. It allows to use C-string the same way as any container. Ehmm... I see that you're using a local/modified copy of sandbox/boost/sequence_algo/container_traits.hpp. Do you plan to intergate those files? It would be very good idea, IMO. It's nice to know, that somebody is using the lib:) If you have any suggestion/problems, let me know. Thanks! - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] Yet another patch for nonrecursive DFS
Hi Bruce, Bruce Barr wrote: I'm glad Vladimir got me to take another look at this. I'm submitting a new patch to replace the one submitted on May 30. And I'm glad you're willing to polish your patch! There are other differences between the recursive and nonrecursive versions that, in my opinion, are good or necessary. 1) The objects color, u, ei, and ei_end are only created/destroyed once instead of at every level of recursion. I think that for 'u', you might have two invocations of copy constructor: when pushing to the stack and when popping ;-) But that's not every level of recursion anyway. 2) The overall number of constructions/destructions for types Vertex and Iter is different. It's possible for client code to depend on something like that, but I think trying to support that sort of code is going overboard. Agree. Here are some pseudo-FAQ's to explain some other details. Q) Why is the statement 'stack.reserve(num_vertices(g));' commented out? A) Because premature optimization is bad. Anyway, only the library user could know what the ideal capacity of the stack vector is. num_vertices(g) might be way too high. Maybe the argument for reserve could be passed in as a parameter someday. Q) Why use nested pairs for VertexInfo instead of tuples? A) Only because out_edges() returns a pair. Tuples probably would have been just as good. There's another question: why store u at all. I'm guessing source(*ei, g) might be more efficient? I'm thinking we have some technical questions left to apply your patch. 1. It needs license from you. Either the standard one: // (C) Copyright Bruce Barr, 2003 // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. // This software is provided as is without express or implied // warranty, and with no claim as to its suitability for any purpose. which, I belive, is preferred, or any one you like, which meets Boost guidelines. 2. Once you decide on 1) I'll commit your patch, making nonrecursive dfs default. I plan to retain the old version for a while, because it would be desirable to compare performance. 3. Maybe, the FAQ, either fully or partically, must be added too. That's up to you, though. Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [sandbox] sequence_algo problem
I've run into a problem using sandbox::boost/sequence_algo/algorithm.hpp. The header uses boost::find, but that function can't really be used, because: 1. (minor) it depends on new iterator adaptors, while I'm using sandbox with boost CVS. 2. It's not possible to use boost::find, since, as I've previously reported, some code in standard library uses unqualified 'find' and, thanks to ADL, will find not only standard find, but boost::find also. Which will be ambiguity. 3. I really don't understand what's boost::find is about. Seems like it manually unrolls search loop for random iterators. While this might be an optimization, I'm not sure it's worth the trouble in 2), especially since compiler might unroll the loop automatically. Thoughs? I think that either 1. all content of non_modifying.hpp should be moved to namespace boost::non_modifying (or even better, boost::algorithm::non_modifying), or 2. non_modifying.hpp should be removed - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem problem
Hi Beman, Beman Dawes wrote: how can I get rid of a read only file? At present it seems to be impossible? Yes, at the moment it is impossible with the filesystem library. [Warning: half-baked ideas follows. I don't even know if it is spelled writeable or writable.] If we can figure out portable behavior that will work on POSIX and Windows, and is likely safe if not useful on other operating systems, then perhaps we should add something to boost/filesystem/operations.hpp like: bool is_writeable( const path ); On Windows, the return would reflect the state of the read-only attribute bit. On POSIX, the return would reflect the Write permission bit for the most restrictive user class which applies. Will this be the same as result of POSIX call access(filename, W_OK) ? The question is that I'm not sure what most restrictive user class which applies means. The simple semantic is: - if user if the owner of the file, return user's w bit - if user if in the group which owns the file, return group's w bit - otherwise, return other's w bit The question if what's user --- there's real user id and effective user id. The latter really determines access rights, but the former is what 'access' function tests. I'm not sure that difference between real and effective id must be addressed by filesystem lib, since it's very platform dependent -- and only effective id must be used. But if so, the semantic above must be implemented manually, as 'access' uses real id. On O/S's which have no concept which usefully maps into is_writeable, return true. Note that a true return from is_writeable() does not guarantee that a file or directory can actually be written to by the program. void set_writeable( const path , bool value = true ); On Windows, would set the read-only attribute bit accordingly. May throw. On POSIX, would set the write permission bit for the most restrictive user class which applies. May throw. I see that man chmod says: The effective UID of the process must be zero or must match the owner of the file. So it only makes sense to set users's write bit. Attempt to set group's write bit when user is not owner will fail. Comments? This seems a good addition. Is it likely that someone will soon ask for 'x' bit support --- which sets 'x' bit on POSIX, and does nothing on Windows? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [Graph] Improved creation of visitors from functionobjects
Douglas Gregor wrote: Creating new visitors in the BGL can be a pain, because it may require a lot of extra typing for simple cases. I'd like to add the ability to attach function objects to visitor events like this: dfs_visitor() .do_on_back_edge(var(has_cycle) = true) .do_on_tree_edge(bind(vectoredge::push_back, ref(tree_edges), _1)); I'd really prefer on_XXX instead of do_on_XXX, but GCC trips over the former syntax. Anyway, the code is ready to check in if there are no objections. The patch isn't very large, but is bigger than I would like to post here. Hi Doug, did you commit that patch already? I can't find anything named do_on in current CVS. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] tokenizer comments
I have a few comments regarding the tokenizer library.
1. The documentation says that char_delimiters_separator is default parameter
to 'tokenizer' template, and at the same time says that
'char_delimiters_separator' is deprecated. I think that's confusing and
default parameter should be changed to 'char-separator'.
2. The token interator description is very brief. Specifically, it does not
say what that iterator is usefull for, or when it's preferrable to direct use
of tokenizer. The only way to construct the iterator is via
make_token_iterator function which takes two interators as arguments. The
meaning of those arguments is not documented.
Lastly, the usage example
typedef token_iterator_generatoroffset_separator::type Iter;
Iter beg = make_token_iteratorstring(s.begin(),s.end(),f);
Iter end = make_token_iteratorstring(s.end(),s.end(),f);
for(;beg!=end;++beg){
appears to be just longer than tokenizer use:
typedef tokenizer offset_separator tok_t;
tok_t tok(s, f);
for(tok_t::iterator i = tok.begin(); i != tok.end(): ++i) {
so I *really* wonder what this iterator is for. OTOH, if it could be used
like:
for(token_iterator offset_separator i(s, f), e; i != e; ++i) {
}
it would be definitely simpler and easier. Is something like this possible?
3. The 'escaped_list_separator' template could have default argument for the
first parameter, Char.
4. I almost always try to use tokenizer when values are separated by commas.
Believe me or not, I'm always confused as to which tokenizer function to use.
This time, I read all docs for char_separator and only then used escaped_list
separator -- which does the work out of the box. Maybe, a different name,
like csv_with_escapes_separator or extended_csv_separator would help?
It would make immediately clear what this separator is for.
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Comments on the bcp tool
John Maddock wrote: Another note is on usability. Say I create directory po and find that some files are missing. I tweak bcp source and try again. But attempt to override files fail. I remove po directory. But then bcp says the destination does not exist. It's a bit inconvenient --- maybe destination directory should be created if it does not exist. Or maybe, there should be --overwrite switch, which would simply clean up destination before doing copies. Or maybe it should just go ahead and overwrite, should be easy to fix. Except for one problem. If the second run of bcp selects less files than the first, and you only ovewrite files, not clean up the entire directory, the number of files will not be reduced. Uncessasary ones will just lay in the directory. And the last note: bcp --boost=/home/ghost/Work/boost boost/function/function1.hpp function1 creates a tree of 1975 kbytes. Hmm, never though there's that many dependencies... Hmm, it seems to pull in more of type_traits than I would have expected, and that pulls in part of mpl, and then a whole load of the preprocessor library. I don't think any given compiler will include half of that, but which half depends upon which compiler... :-( I start to understand why Gennadiy Rozental was saying that dependency from program_options to function is a bit too much --- don't feel all that good about adding 2Megs just for command line parsing. Of course, this only matters when packaging library separately. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: tokenizer comments
Pavol Droba wrote: Hi, I have no comment about the tokenize library, but if your are interested in the stuff like that, you can have a look into the sandbox. string_algo library already contains this functionality ( along with other interesting features ) and it is implemented in more generic way. Hi Pavol, I'm already aware of string_algo and using it a bit. I wasn't aware it has tokenizer component, though. I'll take a look. Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] Patch for nonrecursive DFS to fix stack overflow
Bruce Barr wrote:
Here's a patch to depth_first_search.hpp in BGL in version 1.30.0 of boost
that implements nonrecursive depth first search. This reduces or
eliminates the problem of stack overflow that occurs with DFS in large
graphs. There also may be a performance gain in some cases. If anyone has
a test suite for BGL I'd love to hear the results. Otherwise, it works
exactly the same. The event points
are all the same.
Just like Doug,
I think this patch is desirable. But I also think that a little bit of
additional work is required from Bruce ;-)
At least for me, the algorithm is not 100% clear. When I first say the
while(ei != ee) {
}
loop, I though huh, iteration over all out-edges? and when I saw:
vis.finish_vertex(u, g);
I though, huh, we're only pushed adjacent vertices to stack, why do we call
finish_vertex. Both problems arise from the fact that ei and u are modified
in case adjacent vertex is white. I think to avoid confusion in future,
comment describing what's going on is in order.
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Comments on the bcp tool
I have just tried the tool. On the whole, it's very usefull. Thanks to John!
However, it seems to be confused by the preprocessor library. Since the
includes sometime have the form:
#include BOOST_PP_ITERATE()
the 'bcp' tool does not find them. For example,
boost/preprocessor/iteration/detail/iter directory is needed by
boost/function.hpp but is not included. I've added some explicit dependencies
with the attached patch --- can it be applied?
Another note is on usability. Say I create directory po and find that some
files are missing. I tweak bcp source and try again. But attempt to override
files fail. I remove po directory. But then bcp says the destination does
not exist. It's a bit inconvenient --- maybe destination directory should be
created if it does not exist. Or maybe, there should be --overwrite switch,
which would simply clean up destination before doing copies.
And the last note:
bcp --boost=/home/ghost/Work/boost boost/function/function1.hpp function1
creates a tree of 1975 kbytes. Hmm, never though there's that many
dependencies...
- Volodya
Index: add_path.cpp
===
RCS file: /cvsroot/boost/boost/tools/bcp/add_path.cpp,v
retrieving revision 1.1
diff -u -r1.1 add_path.cpp
--- add_path.cpp 9 Jun 2003 11:52:33 - 1.1
+++ add_path.cpp 19 Jun 2003 10:53:57 -
@@ -137,6 +137,9 @@
std::pairfs::path, fs::path(tools/build/allyourbase.jam, Jamrules),
std::pairfs::path, fs::path(tools/build/allyourbase.jam, project-root.jam),
std::pairfs::path, fs::path(tools/build/allyourbase.jam, boost-build.jam),
+ std::pairfs::path, fs::path(boost/preprocessor/iterate.hpp,
+ boost/preprocessor/iteration),
+ std::pairfs::path, fs::path(boost/function.hpp, boost/function/detail)
};
for(unsigned int n = 0; n (sizeof(specials)/sizeof(specials[0])); ++n)
{
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] BOOST_CHECK_EQUAL_COLLECTIONS and chars
It appears that the error reporting is a little bit less helpfull when 'char'
type is compared. I've just run the following program:
#define BOOST_INCLUDE_MAIN
#include boost/test/test_tools.hpp
using namespace boost;
int test_main(int, char*[])
{
char m1[] = {'a', 'b', '\0'};
char m2[] = {'a', 'b', '\1'};
BOOST_CHECK_EQUAL_COLLECTIONS(m1, m1 + 3, m2);
}
using Boost CVS and recieved the following:
a.cpp(11): error in call_test_main: test {m1, m1 + 3} == {m2, ...} failed [ != ]
The '\0' and '\1' are not printed sensible by iostreams, so this message really does
not tell
what values were different. I suspect that BOOST_CHECK_EQUAL has this problem also.
Is it possible to somehow adress this? E.g. by quoting characters that are not
alphanumeric?
Of course, the example above is artifical. The real one where I found it is a code
which
deals with byte arrays, so it's really needed to compare chars.
TIA,
Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Experimental audience-targeted regression results
Aleksey Gurtovoy wrote: ... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are available from here: * user summary page - http://boost.sourceforge.net/regression-logs/user_summary_page.html * developer summary page - http://boost.sourceforge.net/regression-logs/developer_summary_page.html Please comment! This is very nice! However: 1. The developer_result_page.html as well as the user page are rendered incorrectly, both in Konqueror and Mozillaa. The first table (for any) is drawn in the middile of table of content, overlaying it. 2. The way results are computed, and how to inperpret them is still not clear. For example, I see that function is broken on borland and mingw. If I were just a user, I'd give up and resort to function pointers. But in fact, mingw only fails a single test, so it's basically usable. Borland fails many more tests, but it works good enough still to allow program_options library to pass all it's own tests. Probably, library authors should have a way to specify critical tests. If they don't pass, the library is broken. If some other test fails, it's partially working. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [program_option] post-review plan
I've put together a plan of post-review developement of the program_options library --- see attachemnt. I believe it includes all issues raised. If anybody mage a suggestion which got lost, or has any opinion on the document, I'd be interested to know. Thanks in advance, Volodya Program options post-review development plan. 0. Convert all documentation to BoostBook format 1. Simplify and clarify interface. It turns out that most users are interested in 'variables_map' class, so it must be possible to use it directly, without even knowing about 'options_and_arguments'. The proposed interface is: options_description desc; variables_map vm; load_from_command_line(vm, desc, argc, argv); 2. Better separation of syntaxic and semantic processing, as suggested by Pavol Droba. The problem with current 'option_description' interface is that the 'validator' and 'notifier' callbacks are not really usable by ordinary users --- it's extender's interface. The current 'parameter' function uses those callback to provide user-friendly semantic interface, but it's not documented nor completely worked out. In the new interface, the second parameter of 'option_description' ctor will have two possibilities: just a string and a pointer to a new class 'value_descriptor'. When passed the latter, it will invoke the instance on itself, and then delete the object. A function 'value' will be provided, that will create value specific for a type. Example (magic, valueint(n, n)-default_value(10), magic value). The 'value' function will create instances of 'typed_value_descriptor' type, with the following methods: - default_value - interpreter - validator - notifier The 'option_description' class we'll have two attributes to support semantic operation: 'generator', which will handle conversion from string into value (including application of default value), and 'notifier'. Similiar to the the current design, those attributes will be set by 'value_descriptor' instances. Another function, bool_switch will create value descriptor for type bool, with default value of false. The function is needed to avoid special-casing 'value' function on bool type, which was considered confusing (Neal D. Becker). Other issues here: - storing value to boost::optional - setting a flag when option is found 3. Support for positional options. Positional options will be treated uniformly with ordinary ones. User will be able to specify that, for example, third positional option is to be interpreted as option output-file with the same value. The user interface will be simple: user will provide two instanes of 'options_description' to functions which parse command line. For example. options_description desc; desc.add_options() (magic, n, magic value) ; options_description pdesc; pdesc.add_options() (output-file, n, output file) (input-files*, value vectorstring (n), files) ; variables_map vm; load_from_command_line(vm, desc, pdesc, argc, argv); 4. Multiple sources improvement. Need to implement support for registry/environment. Also, must devise a way to handle different naming of option in sources. Lastly, the storing of values into program variables should become part of 'variables_map' interface. 5. Improve documentation. Chuck Messenger: When code is given for an example program, after the code, give examples of using the program, along with the expected output. Pavol Droba: I would prefer a few chapters explaining various components of the library, each followed by a reference. Pavel Vozenilek: Documentation should contain list of compilers the library works on and also info whether MSVC 6 port is feasible or not. The non-Doxygen part of documentation can be also a bit expanded: e.g. I would welcome some high level overview of the algorithms and structures and info about expected CPU/memory consumption. Also info whether there are any internal limits (like option length) . Some examples may be bit more annotated, also contain what is expected output. Syntax highligting. Document * in option names Automated tests for examples? 6. Unicode support - unicode in argv/argc - Unicode in config files not supported ( The difference between ASCII and unicode files is: - big endian UTF16 starts with 2 bytes FE FF 9mandatory by Unicode standard) - little endian UTF16 starts with FF FE - UTF8 text starts with EF BB BF Pavel Vozenilek ) 7. Config file improvements - should have allow_unregistered for config_file. - bool options in config file do not work. - # inside strings, in config files (Pavel Vozenilek) 8. Cmdline improvements - must be able to parse WinMain string
[boost] Re: [program_option] post-review plan
Neal D. Becker wrote: On Tuesday 17 June 2003 10:49 am, Vladimir Prus wrote: I've put together a plan of post-review developement of the program_options library --- see attachemnt. I believe it includes all issues raised. If anybody mage a suggestion which got lost, or has any opinion on the document, I'd be interested to know. Postional parameters looks like an interesting addition. I guess this is what is commonly called non-option arguments? Yep. Given all the confusion about options, parameters, and arguments, I decided the library will simply have options and position options. Will non-option arguments be able to be placed anywhere on command line, like gnu getopt style? Yes. It's allowed even now. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Changed CRC
Daryle Walker wrote:
In CVS, I added an example file to the CRC library. I changed the
documentation to point to the example file.
Daryle,
I see this code in the example:
do
{
ifs.read( buffer, buffer_size );
len = ifs.gcount();
result.process_bytes( buffer, len );
} while ( ifs (buffer_size == len) );
and I think that check for buffer_size == len is not needed. If 'read'
fails to read 'buffer_size' bytes, it must set both eofbit and failbit, so
ifs will evaluate to false. Is there any particular reason you have the
check here --- maybe some library is buggy?
Also, as long as the program accepts several files as arguments, it's
probably better to output CRC for each file, not for all of them.
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Licence proliferation (Graph library)
John Maddock wrote: The following two files: boost/graph/transitive_closure.hpp boost/graph/vector_as_graph.hpp Use a licence that is different from any other file in boost (the closest approximation appears to be that used by the lambda and function libraries). Is it possible to avoid unnecessary licence proliferation, and reissue these files under another licence (one that is already in use elsewhere)? I would not mind to change my copyrights to use different wording --- either the one from function library or the standard one. The only problem is that boost/graph/transitive_closure.hpp is generated from libs/graph/doc/transitive_closure.w and only Jeremy knows how. And related note: probably the text of standard license should be placed somewhere and you could suggest that standard license to authors which used something different, instead for suggesting to use any license currently used? Of course, it must be settled what standard is. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Command Line Config review results
Aleksey Gurtovoy wrote: b) resolving the 'wchar_t' support issue before the library makes into official Boost distribution. I'm actually not that happy about solving general issue alone... You don't have to. I am sure a lot of people on this list have dealt with the issue and would be happy to help you out. Ok, let's hope so. but let it be. I assume I've not asked to implement any specific approach, and can decide myself? I think the general conclusion was that one should be able to use both 'char' and 'wchar_t' versions of the library facilities in the same program. Ehm... in fact I gleaned quite the opposite conclusion, and can't understand the need to use both in the same program. Anyway, I'm planning to use preprocessor-based solution, so can support this use case, too. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: program options question
Neal, Neal D. Becker wrote: Does/will program options support this style: -w1=10 -w2=20 w1 and w2 are options (with args) that act just the same as long options, but use a single '-' instead of the usual '--'. this style is supported already. The 'cmdline::allow_long_disguise' style option enables it. You can pass cmdline::default_style | cmdlike::allow_long_disguise to 'parse_command_line' function, and all should work. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: program options change request
Neal D. Becker wrote: Currently (last I tested) program options when used with variable map will set bool options to false even though they were not specified on the command line. What I'd prefer is that all options be left alone unless they are set on the command line. I've been bitten by this unexpected behaviour. (I set bool option = true, then use parse_command_line(argc, argv, desc); variables_map vm; store(opts, vm, desc); And my bool option winds up set false even though nothing was specified on the command line. Yes, that's true. All bool options implicitly have default value of false. In fact, I think this is quite reasonable. Unless some switch is on, it's off. This saves the user the need to check if option is present. Could you describe how this behaviour has bitten you? There's probably a solution already. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: program options change request
Neal,
Yes, that's true. All bool options implicitly have default value of
false. In fact, I think this is quite reasonable. Unless some switch is
on, it's off. This saves the user the need to check if option is present.
Could you describe how this behaviour has bitten you? There's probably a
solution already.
I thought I did describe it. I converted some code which was using a
different library (getopt or popt). Before calling the option parser, I
set
bool someopt = true;
After the parser the option is set false. I didn't expect this behavior.
This doesn't happen with other libraries, such as popt.
I see. You didn't mention you was moving from another library.
Furthermore, and
perhaps more important, the treatment of bool is different than any other
options. This inconsistency is bound to trip up other users beside
myself.
Good argument.
I can appreciate the usefulness of the current behavior, and I also know
that there is a workaround (.default_value(true)), but this only works
if you notice the unexpected behaviour!
The only good solution I can see is to either make the bool behaviour
configurable, or somehow force the user to choose so he will notice.
I think the latter is possible. I can make behaviour of 'parameter' function
the same for all types, and introduce another function, say 'switch' for
current ('false' as default value) behaviour. You'd have to write
desc.add_options()
(unified, switch(arg, b), unified format);
;
does this make sense?
- Volodya
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: program options change request
Neal D. Becker wrote:
On Friday 06 June 2003 10:39 am, Vladimir Prus wrote:
Neal,
[...]
I can appreciate the usefulness of the current behavior, and I also
know that there is a workaround (.default_value(true)), but this only
works if you notice the unexpected behaviour!
The only good solution I can see is to either make the bool behaviour
configurable, or somehow force the user to choose so he will notice.
I think the latter is possible. I can make behaviour of 'parameter'
function the same for all types, and introduce another function, say
'switch' for current ('false' as default value) behaviour. You'd have to
write
desc.add_options()
(unified, switch(arg, b), unified format);
;
does this make sense?
That sounds good.
OK, added to todo. I'll adress this together with other review comments.
- Volodya
P.S. Of course, switch won't do, since it's a keyword. But something like
that is possible.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Command Line Config review results
Aleksey Gurtovoy wrote: The Command Line Config library by Vladimir Prus has been accepted into Boost, pending the incorporation of suggestions brought up in the review. These are good news! I would like to thank all the reviewers. Being the library submitter is quite different from watching other reviews --- in particular, I was quite impressed with the number of good suggestions, and I think that the library will benefit greatly when they all are addressed. There've been a fair amount of suggested changes, many of which are documented on Wiki [1], and since the author himself keeps track of the issues, I won't reiterate them here - except for stressing the need for a) extensively reworked and extended documentation, and Completely agree. b) resolving the 'wchar_t' support issue before the library makes into official Boost distribution. I'm actually not that happy about solving general issue alone... but let it be. I assume I've not asked to implement any specific approach, and can decide myself? Also, as acting on the review comments should result in large number of interface and design changes, I suggest that after incorporating them in the library and before the public release the author posts a note to the list so that the interested parties have a chance to comment on the final version. That's my plan, actually. I think I'll look though all my notes and emails once again, and will either post a list of all planned changes to Wiki, or enter them into a publicly-available issue tracker, so that interested parties can add more opinions. As those issues are addressed, I'll inform the list. Thanks for all the comments, and to Aleksey for managing the review! - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: an XML API in boost
William E. Kempf wrote: there is no such thing as the 'Gnu licence'. There is the 'GNU General Public License' (aka GPL) and the 'GNU Lesser General Public License' (LGPL). libxml2 uses neither, and its license is fully compatible with boost's license requirements. Maybe, but it fails the Boost Library Guidelines: Use the C++ Standard Library or other Boost libraries, but only when the benefits outweigh the costs. Do not use libraries other than the C++ Standard Library or Boost. See Library reuse (edit: http://www.boost.org/more/library_reuse.htm). If a submitted library required libxml2, I'd personally vote no. If the interface was supposed to be portable to other backends, I'd probably still vote no unless at least one other backend was included as proof of concept. It would still be nice to have a Boost supplied backend, probably via Spirit, but so long as I was confident that I was not tied to any specific non-Boost library, it wouldn't matter that much. I tend to disagree here. Writing XML library is not easy, and libraries like expat and libxml2 are already here, working and debugged. The effort to write a new library from scratch would be quite serious, and will result in anything tangible only after a lot of time. Unless somebody has really lot of spare time, wrapping existing library is the only way how XML support can be added in boost. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: an XML API in boost
William E. Kempf wrote: I tend to disagree here. Writing XML library is not easy, and libraries like expat and libxml2 are already here, working and debugged. The effort to write a new library from scratch would be quite serious, and will result in anything tangible only after a lot of time. Unless somebody has really lot of spare time, wrapping existing library is the only way how XML support can be added in boost. Careful with what you disagree with. I stated that it would still be nice to have a Boost supplied backend, but I didn't state this was a requirement. What I think *is* a requirement is that any wrapper library not be tied to a single backend, and I personally believe that what follows from that is that the submission must have at least 2 referenced backends for proof of concept. Note that this is precisely what Boost.Threads does, for instance. Oh.. I misread your post. Apologies. Still, from a practical point of view I can hardly imagine that if libxml2 wrapper works, somebody will take the time to plug in another backend. That would mean rewriting all/most implementation method and will bring no end user value --- so it's not sufficiently interesting task to anybody to take. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost:program_options use case and review
Hi Misha, Misha Bergal wrote: I have 2 use cases for program options library. I would say that they are fairly advanced but nevertheless typical ones: Due to severe time constraints I am going to describe just the first use case, which I think will highlight significant number of boost::program_options benefits and problems . Thanks for finding the time for review! - USE CASE - 1. Program options of Perforce version control p4 client. p4 program options come from (in the order of descending priority) 1. Command line 2.standard input 3. config file 4. Windows registry 1. The command line has the general format: p4 [global-options] command [command-options] [...] Please note, that -c option has semantic is different between global-options and command options While I don't think such difference in semantic makes good UI, I won't argue this point here. A little bit later, I'll consider how to support it, as well as support options with the same meaning everywhere. 2.Describe options global_options_desc.add_options() ( c, parameters( client, go.client ), some comments here ) // Problem #1. // The first parameter is a mini-language. Usually C++ tends to avoid minilanguages. // For example: iostreams don't use w+, rw, a, although iostreams are not always // the example of practices to follow. // Still, for users minilanguage might be unexpected here I disagree. For iostreams, all those flags are not used all that often. For program_options they are likely to be present quite often. // Note: need to make sure that parameter can take optional Good point. Added to todo. 3. Read - lowest priority first // 3.1. Read registry and config file // Problem #2 - the names in the registry and config file are not the same as the names given in options_description Yep. It was noted by Gennadiy already, and I'm considering where to add remaning facility. As you've mentioned in use case description above, the names in config file can actually be derived from command line names. // --- custom written --- mtn::copy( config_file( .p4config ), inserter( go ) ); // insert options in go (variables_map, or lexical_map) // --- end custom written --- I assume mtn::copy works with containers, right? Still, for this to work, config_file must be container which value_type is something more fancy than string, while I'd prefer it to be purely syntax parser. // 3.2. Read command line // 3.2.1 Separate global options from command options options_and_arguments oa = parse_command_line(argc, argv, desc); // Problem #3: Would be nice if options_and_arguments was a sequence command_options_and_arguments = mtn::find_if( options_and_arguments, I guess the variable declared should be called command? Else I don't understand what's 'command' in the line below. is_argument ); global_options_and_arguments = mtn::iterator_range( options_and_arguments.begin(), command.begin() ); I think there are some problems here. In order to parse subprogram options, you need to register them. Else, how the parser is to tell if -c foo is a option with value, or an options without value and an argument? But you cannot register subprogram options, for example becuse -c is both global option and a subcommand option. So, you have to stop parsing options on the first argument, and assume all other tokens are arguments. I.e. add a style option which tells that non-options token ends arguments. If such facility is added, then subcommand options are retrievable via options_and_arguments::arguments() method. You can pass them to subcommand which can declare it's own options_description instance (which can include -c with different meaning), and parse it. Imagine a different approach: all options mean the same everywhere. Some subcommands however, don't use certain options. Ok, we'll have options_description desc() // declare all options ; options_and_arguments oa = parse_command_line(..., desc, ...); std::string subcommand = oa.arguments()[0]; std::setstd::string allowed = allowed_options[subcommand]; // validate that all options are allowed for this subcommand. // everything else is as usual. So, the added complexity is declaring list of options that each subcommand takes, and a small loop to do checking. // 3.2.2. Find out whether I need to read a rest of arguments from standard input // Problem #4: Seems that it is too late to ask boost::program_options to do that // May be the arguments need to be read from stdin and the command line parsed again? Yes, I think that's the right way. In fact, it's how response files can be supported. Hartmut Kaiser already used this approach in Wave and I was planning to add such support, but haven't yet. // 3.2.3 Store global_options store( global_options_and_arguments , go, desc); or //
[boost] Re: Formal review: program_options
Hi Beman,
Beman Dawes wrote:
This review is based purely on reading the documentation. The code was not
inspected and no tests were run. I also skim read some of the other review
comments.
In general, I like the library and think that it should be accepted by
Boost.
Thanks!
But there are a number of issues, and I have the feeling that
careful revision based on review comments would pay big dividends.
That's my opinion, too. Some of the comments already made would make
interface much more clear.
Design Issues
=
* As someone else already mentioned, cmdline and config_file might be
easier to use by STL-experienced programmers if they more clearly modelled
containers (with separate iterator types), or else followed the
options_and_arguments usage, which returns a vector ref that can be
iterated over. The current design seems to mix typical container
operations with typical iterator operations.
Thanks for previous comment of Misha Bergal, I realize why interface of the
two classes might be confusing. OTOH, it's still unclear what new interface
might be. I can imagine:
struct option {
std::vectorstd::string value;
virtual ~option() {}
};
struct named_options : option {
std::string name;
};
struct positional_option : option {
int position;
};
With option* as value_type of iterator. But this design looks not that good.
In effect, cmdline returns both named options and positional options, while
iterator has only one value_type. I could use boost::variant, but that's
extra dependency, and I'm not sure I'd like it.
Would it still be better to hide both classes from the public interface --
so that nobody would want to use them?
* boost::program_options::options_and_arguments - the difference between
the get_values() and get_all_values() members isn't clear. Not sure if
this is just a doc issue, or there is an underlying design confusion.
I think it's a doc issue. Imagine two cases:
prog --foo 1 2 --bar 3
prog --foo 1 2 --bar 3 --foo 4
In first case, get_values(foo) will work --- returning [1, 2]. In the
second case, it will not work, because --foo occurs two times on the
command line, and implicitly merging values from differenc occurences is
not good. So, in the second case, one should call get_all_values, which
will return [[1, 2], 4]
* wchar_t and UDT-char support. These are probably important long-term
goals, but IMO should be deferred until more experience has built up with
the basic narrow-char design.
Agree.
Questions
=
* Does a programmer have to be aware of a distinction between command line
args and config file args in normal usage? (This may be a documentation
issue rather than a design issue. Perhaps Design overview section (1)
dealing with cmdline and config_file needs an added sentence like Unless
a user wishes to explicitly control parsing, the use of these parser
classes is hidden from the programmer.)
My intention is that typically, programmer only calls 'parse_command_line'
and 'parse_config_file' functions, and indeed does not work with parser
classes. I though their use makes sense --- in one case some person wanted
absolutely minimal command line parser --- but now that everybody seem to
care only about options_description interface, those classes may be hidden.
* Are common forms of command line indirection to a config file
supported? Like @pathname, for example? [Later... it really doesn't look
like cmdline does indirection. If not, that's a serious oversight, IMO.
Easy to fix, however.]
Not directly. The Wave preprocessor implements response file on top of
program_options. Essentially, there's special option config-file (which
can be specified as @filename). After parsing, if this option is present,
the named file is opened and parsed too). I'm planning to provide this
functionality out-of-the-box.
* Can indirection be recursive? (@file1 contains an indirection like
@file2.) If so, are cycles detected?
The above scheme is quite simple and does not handle recursion.
* How do you code a comment in a config file? (Comments in config files
are really important - this feature needs to be added if not already
supported.)
The '#' character starts a comment.
* Is there a function or class which does the argc/argv replacement-trick
for command line indirection? It is so easy (one #include + one line of
code) even for existing programs that it might be valuable as a standalone
feature even if built-in to the cmdline parser itself.
That's very interesting idea! Two caveats, though:
1. The function for replacement should operate on vectorstring, since you
can't change argv, in general.
2. You've got to do some parsing of file. For example, if it contains
-c foo
then you'll have to add *two* elements to argv. If you add one, it will be
most likely parsed as option -c with value foo (note the extra space).
Minor Issues and Quibbles
[boost] Re: program_option library bug report
Hi Pavol Pavol Droba wrote: Hi, I have probably encountered a bug in the library. I'm not able to put a bool option in the config file. Regardles how I specify the option there, parsing always fails with the exception: config file options should have required parameter That's really a bug. I'm running home right now, but will try to address it soon. Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [BGL] null vertex?
I think that it would be handy to introduce null vertex value into BGL. For example, I'm computing some 'alternative vertices' in some function. If no such vertex exists, I'd like to record this fact, so that when the function is called again on the same vertex, I don't have to do anything. I'd like to write alternative[v] = null_vertex(g); or something similiar. This is feasible: if vertex_descirptor is pointer, you have a natural value for null. If vertex descriptor is interger, well... you can use index 0 for null vertex. This would waste a bit of space, but is it that important? Opinions? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: an XML API in boost
Aleksey Chernoraenko wrote: I wrote a C++ wrapper library around libxml2 (http://xmlsoft.org/), and would like to submit it to boost. It currently provides a DOM-like and a SAX-like interface, is parametrized for the (possibly unicode enabled) string type, and has already proven its value for my own projects. What is wrong with Xerces-C++ library (http://xml.apache.org/xerces-c/index.html) ? Probably, the fact that its tarball is comparable in size to the entire Boost? Another thing is that it's not a big friend of C++ standard library. For example, it does not use std::string, but its own XMLString class. Going back to original post, I wonder how the proposed library differers from http://gmetadom.sourceforge.net/, which is wrapper on gdome, which is wrapper on libxml. As another implementation worth checking out, I can recommend CenterPoint/XML (http://www.cpointc.com/XML/). This one is small, and is quite nice, IMO. If my colleagues can ever be persuaded to move away from home-grown hierarchical format with home-grown API to something somre standard, I'll propose this library first. The only problem with it that there's no XPath support. HTH, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Configuration ideas
Hi Daryle,
Daryle Walker wrote:
[I wrote this half-asleep a few days ago. You could add things like
signals/slots, better list management, etc. Take this suggestion as a
very general guideline, not as actual code to use.]
I haven't looked at the command-line/config library under review right
now. I have seen recent discussions over its design, though. Here's
my idea for such a library; maybe it'll inspire somebody:
Honestly, I'm a bit upset. You first say that haven't looked at my library,
and then go ahead and write down some long proposal. Is this supposed to be
in some respects better than what I propose? If so, could you explain?
1.Let's start with a container for the actual command line arguments:
template typename Ch = char, class Tr = std::char_traitsCh
struct arguments
{
typedef std::basic_stringCh, Tr string_type;
[snip lots of code].
If I understand correctly, the idea is simple. For each command line
element, you call several rules. Each one can declare the element as
consumed. The ones which declare element as consumed are then called to
finalize argument.
Is it the same idea that I explain (less verbosely), in
http://article.gmane.org/gmane.comp.lib.boost.devel/20588/
It would be possible to pack all styles supported by 'cmdline' as
separate 'style parsers'.
The idea was the all style parsers would be run on next token, and one will
succeed.
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Hi Misha, Misha Bergal wrote: Alas, this comment seems non-constructive for me. I don't think that the question is what kind of design should be promoted. What are the problems with the current design? Can you list some interesting things that would be possible if config_file were an iterator? What would be its value_type? And what will operator++ do on error? Gennadiy's comment might seem to be non-constructive. But I believe it has some merit to it. When I look at the Doxygen class reference cmdline I want to understand it's design quickly and unambigously [...] The smaller the number of those patterns (concepts) - the easier it is to the users. When I (and probably Gennadiy) looked at cmdline parser I could not quickly recognize any of the patterns we already know there. This design might be completely justified, but still it is kind of struggle for me to understand it. Saying I don't believe this is kind of design we want to promote I would mean 1. Introducing the new pattern (concept) is costly for the users 2. I believe it is important goal of Boost to build on or extend the existing patterns(concepts) used in the standard library or other parts of Boost where possible. This would significantly lower the users' costs I consider Gennadiy's question to be legitimate(but may be not perfectly stated). In your presentation the concern is quite clear, and indeed legitimate. I'll try to see if/how it can be changed to use more common patterns. The problem I see, is that to convert it into iterator, or an model of Generator concept, one would need to introduce special class for value_type. And that class will be very artificial: almost nobody would want to use it directly. And such classes are not good idea, IMO. Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Hi Misha, Misha Bergal wrote: You've missed the word directly. You can't have all possible styles work out of the box, because the number of possible styles is infitite. The problem with approach taken by the library is that to support the new style the user is advised to write a custom parser, although the author of the library uses different technique - it is not fair :-). If I was a user of PO library, I would be really confused, because cmdline class is closed to addition for me. It's probably not that unfair --- the user is not expected to reimplement all those style with custom parser. The idea is that most common styles are packed in cmdline class and custom parser is for exceptional special syntaxes. It would be possible to pack all styles supported by 'cmdline' as separate 'style parsers'. But the interaction between that will not be trivial. The parser for short options -k must know that -- starts a long option and don't process it. It also much handle sticky short options. And so on. In fact, I had the same kind of questions when looking at Gennadiy's code: the policies did not look orthogonal to me. speculative arrogant commentI suppose that if all styles were implemented as separate parsers, some common parts would be refactored into something resembling Gennadiy's cmdline? and parsers themselves being a lookup policies?/speculative arrogant comment I'm not sure. I still don't understand many things about his code... E.g. profile build of a simple program which uses BGL takes several minutes for me. Yes, program_options is not as large, but what if you add 20 small libraries.. It depends what I add them to. If it is one compilation unit as with your library - no problem, if it is 1000 compilation units as with std::string - big problem. First, you might have several programs, all of which use program options. Second, you might declare module-specific options in a translation unit specific to module. So, it's probably more that one translation unit. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: Command Line Config library
Hi Misha,
Misha Bergal wrote:
Vladimir Prus [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I think it's better to wait for Unicode users to formulate what's needed.
It
seems, for example, that the last approach would work better for me on
Linux.
Visual C++
int
wmain( int argc, wchar_t* argv )
{
std::wcout LHello, world! std::endl;
std::wcout ( boost::wformat( LHello, %s ) % Lworld ).str()
std::endl;
...
}
That's what I have, I am not sure I want the differrnt usage for
boost::program_options
I understand, you want to use:
... parse_command_line(argc, argv, ... )
The important point is that you don't necessary need two
versions/specialization of program_options to do that. QT can handle both
Unicode and 8-bit string, because QString is unicode.
On Linix, you don't have 'wmain', so you'll have to write
int main(int argc, char** argv)
{
vectorwstring wargs;
for(...)
wargs.push_back(local8bit_to_wstring(argv[i]);
}
Now, if you have portable implementation of 'local8bit_to_wstring',
program_options can be implemented using wstring. The interface functions
would merely convert char* to wstring if needed and wchar_t* will be
supported without any effort.
- Volodya
Misha
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
David Abrahams wrote: parameterstd::string( output ) place_to( output_file_name ) default_value( /tmp/abc ) description( output file name ) While I don't find the interface proposed by Vladimir to be offensive, when you get a pile of function arguments of the same type together a named parameter interface *can* be a help. I don't think I'd use operator, though. If it's really about readability I'd tend to sacrifice some non-intrusive extensibility for a cleaner syntax: parameterstd::string( output ) .place_to( output_file_name ) .default_value( /tmp/abc ) .description( output file name ) ; But anyway, neither of these looks like a huge win over a function which simply takes 3 parameters. Probably the complexity isn't justified. And one important point: there are only three unnamed parameters. There's a bunch of other things that can be configured, and they all use *named* interface: desc.add_options() (output, file, output file name).default_value(/tmp/abc) ; - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Formal Review: Command Line Config library
Hi Misha, Misha Bergal wrote: Vladimir Prus [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I think the point is that you hardly want both ascii and unicode in single program. In that case two versions of shared library can be built: for ascii and unicode, and you will link to the desired one. It's actually not necessary to add templates --- probably preprocessor will do. If user doesn't have a good build system or is not educated enough to use one - she will have to struggle a little bit (may be quite a bit). How will he specify the Unicode or non-Unicode version of the library to link with - project settings?, windows library autoselect (the whole thing with program_options_udd, program_options_dd, program_options_ds, program_options_uds etc.). Those issues are not specific to this library and are not unresolvable, but comparing it with other 2 libraries (in distribution sense) - regex and signal. Program options will probably be used in just one place, as compared with regex and signals which can be used in many places. Regex and signals get one point for going to the library I can expect program_options to be used in several places --- for declaring options. Also, if regex and signals were implemented inline, duplicate template instances/inlined functions will be removed during linking, so the argument applies only to compilation speed. Ok, so regex/signals get half a point. Program options would have 2 possible template arguments char and wchar_t, regex - 2, but signals much more than that. Signals gets one point for going to the library The code in library is not template. If it were declared as inline, there still would be one copy for all possible template parameters. No points to signals, IMO. Instantiated program options code takes much more space than regex and signals one. Even if that is true - it is in just one/two compilation units where the compilation time and their binary sizes would be affected. It is still going to affect the size of the application the same way (I don't think I would want to use program options as a shared library). Program options gets no point here. There's one important aspect. You're no likely to use signals just to try it out. You either use it through all your application or not use. Signals migh have serious impact on the way you structure code and give you serous benefits. Parsing of command line is not such an important thing in the whole program. So, the compilation time/space overhead must be small. This is at least 0.5 points to program_options Total: Signals - 2, Regex - 1, PO - 0. That's great news for PO library and its users :-). In my opinion, we get 0.5, 0.5, 0.5 ;-) - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Gennadiy Rozental wrote: I think the names arguments and options are as good as anything else. It may be so. But I do not understand how the library use these terms. Vladimir wrote: option is (name,value) pair argument is an command line element which is not option. These definitions unclear to me. Could you give me more explanations with examples. Consider command line my_prog --output=/tmp/log input.cpp Here is the option with name output and value /tmp/log. There's also argument input.cpp. Also I would like to know what term parameter means and what is the difference between parameter name and option name. The term parameter is undefined yet :-( It's used only as the name of 'parameter' function, and there's something wrong with this name. For example, when support for argument is added, the same mechanism should be used to describe type of options and type of arguments. Using 'parameter' function will became quite confusing, so I'll have to find a better name. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Gennadiy Rozental wrote: And one important point: there are only three unnamed parameters. There's a bunch of other things that can be configured, and they all use *named* interface: desc.add_options() (output, file, output file name).default_value(/tmp/abc) ; The question arize: Why do you prefer option description to defalt value, optional and other modifiers (I still could not reveal the mystery of second parameter, so couldn't comment here). I prefer treat them all same way. I though I've told it to you previously: because uniform syntax will be much more verbose - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Gennadiy Rozental wrote: Consider command line my_prog --output=/tmp/log input.cpp Here is the option with name output and value /tmp/log. There's also argument input.cpp. 1. Why you named namespace progrma_options it in fact you supply both. Because options are of a bit more importance, and high-level access to arguments will be in fact the same as for options. 2. How could I access argument using high level variable_map/option_description interface I seems like you did not read other review comments. It's not possible via high-level interface. It was requested, and will be implemented. 3. What is add_argument method in options_and_arguments It adds new argument to the list of arguments stored in the class. Also I would like to know what term parameter means and what is the difference between parameter name and option name. The term parameter is undefined yet :-( It's used only as the name of 'parameter' function, and there's something wrong with this name. Term parameter is also actively used in class class cmdline Then, if I'm to change 'parameter' function to something else, I'd need to tweak that class as well. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Rozental, Gennadiy wrote:
1. You store something inside class cmdline
Actually, only arguments, for the benefit of folks which might use 'cmdline'
standalone. Options are not stored there.
2. You store strings in options_and_arguments
3. You store typed values in variables_map
In my opinion 2 places are redundant. You should only have one.
OK, I understand your opinion. I'm probably misusing you don't pay for what
you don't use principle, but I find that 'options_and_argument' class is
important. Sometimes you really don't need typed storage.
Plus second layer managing composition of parameter originated by
different sources.
That's 'variables_map'.
But variables map is part of first layer, it's store typed arguments. And
it almost
does not have any functionality I expect to see on this second layer
dedicated to combinind parameters from different sources.
It's possible to link several variables_map instances in a chain, which
handles the primary need: different preference of options from different
sources. It's true that different naming of options is not handled, however
I'm still considering if it's better to do that in parsers.
b. Force same style for all parameters in command line (I could
not
define /h --my_long_param)
Do you need it in practice?
Why not. Maybe different modules require parameters in different
style.
I feel this to be artifical example, and would not be surprised if no
user
of program_options will ever want it. And if it wants... custom parsers
can be used.
But this is part of functionaly you supply out of the box. And now i need
ot rewrite it.
You keep repeating: use custom parser. I wonder why would I need this
framework then.
1. I think that less than 1% of users would ever need it. In that case,
there's nothing wrong with asking that 1% to put some effort for their
special needs.
2. BTW, you've said that I can't have /h --my_long_param and I've started
to argue that this style is rare and custom parser can help. But really,
that style *is* supported. There no unix style and windows style, but
rather a set of possible syntaxes. So, (cmdline::unix_style |
cmdline::allow_slash_for_short) enables the syntax you want.
In my terms above would look like this:
parameterstd::string( output )
place_to( output_file_name )
default_value( /tmp/abc )
description( output file name )
You do not need to know anything in addition about how parser works.
Moreover it's unifies and easily extendable to adopt different modifers.
It seems we'll make no progress with this question. I find your syntax more
verbose, and it still leaves questions. What if I have --output foo
--output bar or when does default value plays: can I write simply
--output, without any value?
With iterators, that would become
for(cmdline_iterator i(...), e; i != e; ++i) {
if (i-is_option()) {
Wait! Again, what's 'value_type'. Some imaginary 'option_or_argument'
class?
boost::variant? boost::any? Yep, that would be an interator, but you
gain
nothing. It will be only input iterator, and with such a specialized
'value_type', that to use that iterator, you need to known that you're
dealing with command line --- there's no place for genericity.
In my design I provide rnadom access iterator to the storage of parsed
arguments of
type cla::argument. And I could use whatever generic algorithm I like with
it.
Let's then postpone this question until your library is reviwed. I found
that 'argument's interface is too lean to make any use of it, but if that's
really so if not question about my library.
Why does anybody need raw_option_name()?
In short, this supports scenario where you define a group of options as
valid, using * symbol
desc.add_options()
(diff_option.*, , )
This would allow your program to accept everyting starting with
diff_option.. In this case, you really don't want to list all options of
'diff' as supported. It seems that multi-pass parsing won't help here.
Also it's beyond my understanding why we need at_option, at_argument. May
be it's because I still could not get what meaning you use for these terms
in this context.
I parsed argc/argv, stored typed argument. Now I only need ot get the
value
out of argument I identifued somehow (by name, or index, or order -
whatever)
You don't need 'at_option'/'at_argument' because you parse either all
options or all arguments. When you parse them at the same time, your really
have to know that's next on command line.
9. Multi-pass parsing support
If that's not sufficient (which I doubt), I can think of a more general
solution. Basically, 'cmdline' class can allow unregistered options.
With
a bit of tweaking, it can return unparsed tokens.
There is a solution. But it's not trivial. And not in a bound ot your
current design.
We'll see...
I don't see here handling of response files or config files... if you
were
to add it, would you
[boost] Re: Re: Re: Formal Review: Command Line Config library
Hi Pavol, Pavol Droba wrote: I have been reading the discussiong here about adding the support for unicode. Maybe there is a solution which would allow to have templated versions of relevant classes AND static library in one box. If we decide that specialization for char and wchar_t is sufficient, the headers can contain generic template based declarations, but the implementation will be given only for particular cases ( char and wchar_t ) and so it can be included in the static lib. Oh.. that's yet another approach. I *really* feel Boost-wide solution is needed. Similar idea is used in stl for streams, strings and locales. I though that's different. I need to check out again, but IIRC, RW STL shipped with borland's free compiler had all string definitions in headers. With a help from preprocessor, it should be easy to define two variants in one place. Also that could a possibility, that the .cpp file will be included as headers all this can be done using macros. Yep. Another viable option. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: command line parser review
Tanton Gibbs wrote: I realize that header file is easy. But that approach will bit sooner or later. It probably would be possible to supply alternative header-only option, but that would be a lot of work. Need to find more opinions here. BTW, if you have problems with shared libraries on cygwin, it's still possible to add all source files from program_options to your project and compile them? Yes that is an option, but not one I would like to use. I personally prefer the optional header-only, but understand either way. OK. I'll note your opinion. The error message indeed carry more information than it failed. I can also imagine cases where the kind of error matters. I think that exceptions are definitely superior to error codes because of the amount of information they convey. Therefore, I really like the exception option. Good. I have some problems here, too --- the config_file class is too small be become a separate library --- and was never intended to. I've no problem with using separate config_file, provided it can be converted into 'options_and_arguments' class, which is the common interface for command line and config file. However, I can't comment as what the separate config file library can do. Me neither. It could be that your library is accepted into boost on the condition that when a real config file library is accepted, you replace yours with it. Basically, given the little amount of time put in config_file, I'll be happy to replace it with anything better. 8. I agree that multi-pass command line parsing is important. We eat certain arguments and pass others to separate programs all of the time. Could you clarify why the approach with separating option to your program and options to another program by -- is not appropriate? I'd be willing to put some though into this, but would like to understand the problem first. The -- option would be fine for my purposes. Just stupidity on my part. :-) Now, 'whale_opts' and 'dolphin_opts' (of type std::mapstring, string) keep two different groups of options. I'm thinking something like that can be used. This is fine until Dolphin and Whale both use the same option (e.g., -f filename) in which case they cannot have separate values. Good case. I feel that multi-pass parsing will fail in this case, too. The first parser will extract '-f' and the second one will never see it. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Formal Review: Command Line Config library
Matthias Troyer wrote: On Tuesday, May 27, 2003, at 05:44 PM, John Torjo wrote: - does not work for wchar_t. While this might seem silly, it's not, since VC allows for a TCHAR* command line string. I have to consider this. An obvious approach would be to add template parameter to every class, telling which char type to use. So investigation is needed to find alternatives --- making everything a template would conflict with ability to compiler everything as shared library. I don't think we need a template param. Just something like 'boost::program_options::char_type', which is by default char, and can be changed. It's not like we have multiple command lines or something ;-) We could have some programs that use plain ASCII characters, and some programs that want to support Unicode filenames. We should thus still have support for both narrow and wide characters, and not just one character type. I think the point is that you hardly want both ascii and unicode in single program. In that case two versions of shared library can be built: for ascii and unicode, and you will link to the desired one. It's actually not necessary to add templates --- probably preprocessor will do. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Formal Review: Command Line Config library
Chuck Messenger wrote: Vladimir Prus wrote: Chuck Messenger wrote: Vladimir Prus wrote: Yep. This question was raised already. I think that making templates out of all classes is *a* solution, but I'm not sure it's *the* solution. The problem is that extensive template usage would prevent making library --- either shared or static. I think that would be a big downside. Why does that matter? The great majority of other Boost libraries are header-file-only. I think of .cpp components of Boost libraries as a sometimes-necessary evil, not as a desired feature. Becase header-file-only libraries have two problems --- they increase compilation times and they increase binary size. And you can't share the code between different applications. I think that's important practical aspect. In past, I was burned by overgeneralization --- almost all core classes in a program had template parameter. It had only one possible value, but I though different ones were possible. As the result, compilation time was terrible, and no new possible values for the template parameter became needed. And these days, I'm rather unhappy with compilation times of BGL... Perhaps you can do both: write the library with templates for a generalized string. Then, supply fast.cpp and fast.hpp (choose better names). Use a pimpl idiom in fast.hpp, so it doesn't need to include any template code. fast.cpp includes the templates, but needs to be compiled only once. That's a possible approach. But there are also at least two other: - using preprocessor to generate two version - using wstring internally with conversion on interface boundaries I think it's better to wait for Unicode users to formulate what's needed. It seems, for example, that the last approach would work better for me on Linux. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: command line parser review
Hi Tanton,
Tanton Gibbs wrote:
Since there have been a few emails bouncing around, I'd like to chime in
with my opinions on a few matters.
1. Static vs Shared
I would much prefer header files only instead of a shared library. Having
to deal with shared libraries are a pain on many systems (such as cygwin).
Using a header file is clean and easy -- therefore much preferred by me.
One of the biggest benefits to boost is that it is primarily header files
only. I don't even use the regex library because I can't get it to build
on Tru64.
I realize that header file is easy. But that approach will bit sooner or
later. It probably would be possible to supply alternative header-only
option, but that would be a lot of work. Need to find more opinions here.
BTW, if you have problems with shared libraries on cygwin, it's still
possible to add all source files from program_options to your project and
compile them?
2. redundant storage
I don't have a problem with you storing arguments in both
options_and_arguments as well as whatever variable I pass in. I realize
that one will be typed and the other string. If it is stored in a third
place as well, well that could be annoying, but I won't balk too
much...probably not good design though.
The true situation is: options are stored only in two places. Arguments are
indeed stored in third place to make 'cmdline' class more usable by itself.
I'm actually considering if 'cmdline' class should be moved out from public
interface, and if it happens, there will be no third place for anything.
3. custom parser
I realize that no one will find shrink-wrapped solutions to everything.
However, for a command line parser, I would hope that most common command
line styles would be shrink-wrapped. For example
/o --option -o -o value -o=value --option value --option=value -o val1
val2 val3 --option val1 val2 val3 -o val1 -o val2 -o val3
should all work right out of the box. Other than that, make 'em write a
custom parser :)
That was my opinion, too. BTW, all the styles above are supported.
Of course, that is assuming that by custom parser you mean write the
custom parsing function that can be used by your library.
Yes, sure.
4. I do like the idea of handler functions that could be called when the
parameter was passed in.
Technically, there's 'notify' function which can be used for that purpose.
In discussion with Pavol Droba we've decided that semantic processing
('notify' is part of it) must be a bit more clearly separated from
syntactic processing, but basically, that function will be retained.
5. As for exceptions vs return values. I don't really have a preference.
Often, you can get more information from exceptions than you can from
return
values. If that is the case then I fully support exceptions. If you're
not going to get back anything other than it failed, then return values
are probably the way to go.
The error message indeed carry more information than it failed. I can also
imagine cases where the kind of error matters.
6. wchar_t support.
I definitely see the need for this. I like the idea of a template
parameter. However, I wonder, like another poster, if you will ever need
both char and wchar_t support, in which case you may not need a template
parameter. The only question I have is if you will ever have the command
line in char and the config file in wchar_t...then you may need them both.
Oh... that's a good question! I'm starting to feel that unicode can't be
addressed in program_options alone. Some general solution is needed.
7. config file.
This is where I have the biggest problem. I think a config file library
should be in boost, but separate from a command line library. Perhaps the
two could interface through a similar facade, but I don't think they need
to
be intimately combined. As another poster pointed out, the command line
option and its associated config file or environmental parameter are often
very different in name.
I have some problems here, too --- the config_file class is too small be
become a separate library --- and was never intended to. I've no problem
with using separate config_file, provided it can be converted into
'options_and_arguments' class, which is the common interface for command
line and config file. However, I can't comment as what the separate config
file library can do.
8. I agree that multi-pass command line parsing is important. We eat
certain arguments and pass others to separate programs all of the time.
Could you clarify why the approach with separating option to your program
and options to another program by -- is not appropriate? I'd be willing
to put some though into this, but would like to understand the problem
first.
BTW, I have a use case (with program_options) where a single program accepts
two groups of command line options, which must be passed to different
applications. The problem was solved by declaring two groups of options as
Re: [boost] Re: Re: Formal Review: Command Line Config library
Pavol Droba wrote:
The only problem with current 'validator' is that it should validate
*string* and return the value. So, the example given by Tanton:
_1 = 1 _1 = 9)
would not really work --- the validator function is given a string. It's
probably possible to use 'notify' callback to do such kind of validation,
though. Or add another validator --- which is given converted value.
I see. However I think this is a little bit clumsy to use. I think it may
be better to strip validation from the conversion.
What I had in mind is an extension to po::parameter funtion to something
like
template typename T
*unspecified* po::parameterT(
string parameter_name,
T variable,
const boost::function1bool, T) validator );
so the framework would convert string parameter to a specified type and
then run the validator functor on the result to validate it.
I was actually thinking about splitting current validator into
interpreter, which converts string to value and validator proper. That
should allow to write
desc.add_options()
(compression, parameterint(n), compression quality).
validator(1 _1 _1 = 9)
;
With this feature in place, adding validator as additional argument to
'parameter' can be considered a convenience. (Now, there are 3 ideas for
additional arguments to 'parameter', so I can't decide right now).
One problem: the above would require implementation tricks. The value
extracted from string is stored in boost::any. Sure, you can't pass
boost::any to the lambda function above, so some means to recover the type
stored in any would be needed. I'm not yet sure this will be all that big
problem, though.
[...]
I mean something like %02.4f or something like that... it is just an
idea. If there would be a validation predicate as an argument, regex
library can be used to define regex predicate which would cover most of
the cases.
Ah... ok. Indeed --- the validator can do that already, and in case of
string validation, the current code will work.
That's nice. Can you post a piece of code as an example?
Attached is a complete example which uses regex library to validate option's
value. The format of value is fictional, but the main idea should be clear.
And there's example session:
bash-2.05b$ bin/gcc/debug/regex --help
Usage: regex [options]
Allowed options:
--help : produce a help screen
-v [ --version ] : print the version number
-m [ --magic ] arg : magic value (in NNN-NNN format)
bash-2.05b$ bin/gcc/debug/regex -m 123
invalid value
bash-2.05b$ bin/gcc/debug/regex -m 123-345
The magic is 345
I've also realized there are no examples for custom validator now, so this
code will most likely be added to the library.
Thanks,
Volodya
#include boost/program_options.hpp
#include boost/regex.hpp
using namespace boost;
using namespace boost::program_options;
#include iostream
using namespace std;
/* This validator makes sure that value is of form
XXX-XXX
where X are digits. It then converts the second group to a integer
value. This has no practical meaning, meant only to show how
regex can be used to validate values.
*/
void fancy_parameter_validator(boost::any a,
const std::vectorstd::string values)
{
static regex r(\\d\\d\\d-(\\d\\d\\d));
// Make sure no previous assignment to 'a' was made.
validators::check_first_occurence(a);
// Extract the first string from 'values'. If there is more than
// one string, it's an error, and exception will be thrown.
const string s = validators::get_single_string(values);
// Do regex match and convert the interesting part to
// int.
smatch match;
if (regex_match(s, match, r)) {
a = any(lexical_castint(match[1]));
} else {
throw validation_error(invalid value);
}
}
int main(int ac, const char **av)
{
try {
options_description desc(Allowed options);
desc.add_options()
(help, , produce a help screen)
(version,v, , print the version number)
(magic,m, arg, magic value (in NNN-NNN format)).
validator(fancy_parameter_validator)
;
options_and_arguments oa = parse_command_line(ac, av, desc);
variables_map vm;
store(oa, vm, desc);
if (oa.count(help)) {
cout Usage: regex [options]\n;
cout desc;
return 0;
}
if (oa.count(version)) {
cout Version 1.\n;
return 0;
}
if (oa.count(magic)) {
cout The magic is \ vm[magic].asint() \\n;
}
}
catch(exception e)
{
cout e.what() \n;
}
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: program_options lib: how to denote return values?
Chuck Messenger wrote: As for me, I'm a bit unsure about introducing new syntax. In this case, I'm not sure overloading of is 100% intuitive --- one can assume that value of magic is read from param result, for example. OK, then how about this: magic = desc.optionint(magic|value|magic value for program); val = desc.option(val||some value with a default, defValue); etc. (note that int is needed only in the first case, since there is no default value from which to infer the type). That's better. OTOH, it still does not fit well in current scheme. Now, everything can be configured using member functions of 'option_descirption' class. The 'parameter' function adds some convenience, but in effect just calls relevant methods internally. The syntax above requires very special support. If you like, the assignments could even be deferred (although I don't see the point of doing that). Can you clarify what's deferred? The above code, as I understand it, would only say that option val should be stored in variable val. The actual storing will happen after parsing. Or do you have something else in mind? - Volodya - Chuck ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Build V2, Milestone 3 released
Anthony Williams wrote: Vladimir Prus [EMAIL PROTECTED] writes: Anthony Williams wrote: Vladimir Prus [EMAIL PROTECTED] writes: Shame about the NT symlinks not supported yet errors... Hmm... I hope someone more knowledgeble about NT will implement them someday. I even don't known is there's command line tool to create them. Within an NTFS partition you can create hard links for files. You can also link directories within or across local drives, so c:/cdrom points to the contents of the CDROM drive, and c:/boost_current points to c:/libs/boost_1_30_0. I can provide code for doing the former; www.sysinternals.com provide a tool (with source code) for doing the latter (junction). I've looked at the latter now, and would be very interesting in code for the former --- since hard links for files more closely match Unix links semantics. The code below creates a file c:\target, and then creates a link to it called c:\link. Thanks! We'll try to add support for symlinks on NT using your code. I think this can happen before V2 is realeased. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CLA/Config file library opinion
Hi Gennadiy, Gennadiy Rozental wrote: This is not a review of the supplied library. I am not gonna discuss docs even though they are scarce. I almost don't mention implementation/code/ testing. I just want to express my opinion on design of the library. Thanks for taking the time to comment! I actually expected critical opinion from you, and while I don't think I can change your mind, it's still a good idea to answer your concerns for the benefit of other reviwvers. But two preliminary points: First, it's very sad that we both put time in different libraries for the same task. I'm not sure we could have come to a conclusion, but IIRC, you've decided to write your own after looking at 'cmdline' class from my library only --- the most basic and internal one --- and not at anything else. Had you drop an email saying what you don't like, we'd probably have a more pleasant situation. Second, I will not discuss what's right design and what's right programming style per se. Such discussions tend to have no resolution. Instead, I'll focus at relative benefits to user --- which is something more tangible. 1. Terminology Terminology chosen by author is confusing to me. In my understanding: term parameter - originated from 'formal parameter, formal description of the expected value term option - special case of parameter that describe parameters with boolean values term argument - originated from 'actual argument', actual value passed as expected value The way these terms are used in library does not seems to follow above definitions. I'm not claiming the definitions are perfect, but I do claim it's not 100% broken. For example, what opt in getopt stands for? The Options library by Brad Appleton http://www.enteract.com/~bradapp/ftp/src/libs/C++/Options.html and APR http://apr.apache.org/ Use the same definition of option, which is different from yours. I would say using option in different meaning can confuse a large user base. 2. Layered design. The task in hand indeed ask for the layered design. But design presented in library does not come close to what I understand under this term. Let's see what are the layers and their purpose a. First layer cmdline/config_file. It allows parsing argc/argv producing list of pairs of string. It does not know anything about description correct types and so on. The question is: why would I want in practice to use this layer standalone, instead of program options with all types defaulted to string? Why not hide this class into implementation details? Because you are not required to use this particual config_file class, for example. As I've mentioned in other posts, should you want to use xml config file, for example, you can write another config file parser, and add it without any trouble. b. Second layer declared in design is class options_and_arguments. What this class adds to the cmdline functionality (other than unnecessary copy of huge object - not that performance is that important, but still) and why it could not be implementation detail of the class cmdline unclear to me. Same concern here. Single options_and_argument is the class that all parsers return. It's a single uniform interface. It that interface is moved to cmdline, then... well... should be duplicate that interface (and implementation) in config_file? c. Third level declared is program options. Looks like the only usable layer to me. d. Finally variable_map - third place where actual argument are stored (Number of places where actual value is stored looks redundant). Why would I want to use this class if I need only CLA parsing unclear to me. Multi-source case discussed below. You don't *need* this class for parsing only CLA. However, this class is the interface for getting typed options. The 'options_and_arguments' class is simpler --- it deals only with strings. 3. Variety of different name/value syntaxes support Library struggle to support most used syntaxes for the CLA processing. I am not gonna say that any specific style is missing. Let's better see how this support is designed. class cmdline is responsible for all syntax related tasks. The only way to select non-default style is to provide some bitmask of desired styles in constructor (BTW, I did not see an example of usage custom style with variable map - is it possible?). Hmm... custom style has nothing to do with variables map. You specify custom style to command line parser, and varaibles map is created from results of parsing. As such, it's completely independent. This has many problems: a. Limit number of supported styles die to bitmap limitation The number of directly supported styles will always be limited. For all others, users will be compelled to write they code --be it a function, or a policy. b. Force same style for all parameters in command line (I could not define /h --my_long_param) Do
[boost] Re: Re: Re: Formal Review: Command Line Config library
Pavol Droba wrote: Ok, I think, I see now, where the point is. The framework is separated into two layers. L1: option level ( string and boost::any oriented, defined by option_description ) L2: typed-paramter level ( represented by po::parameter function ) L2 should work above the L1 as an optional feature Currenlty L1 is quite well defined, but L2 is lacking. I would like if L2 would be able to convert a string representation to given type, run the typed validation and store the value into local variable. Conversion and validation should be parametric with reasonable defaults. Also, I think that the conversion and validation should be separated. Conversion should deal with a format of a parameter, while the validation should check semantic properties of its value. I completely agree. Basically, this means splitting the current validator in two, as your describe above. Plus some polishing of interaction between 'convert'/'interprepter' -- for string-type conversion 'validator' -- for checking the value of desired type 'notifier' -- which does storing into local variables Important is, that L2 should be separated from L1. So L2 conversion and validation would be different from L1. Actually, L2 validation and conversion should plug into L1 as a custom validator. I hope this makes some sense. po::parameter ( aka L2 ) is quite close to the goal, but there are still some missing parts. Yep, that makes complete sense. By default, L1 simply converts strings from command line to strings inside variables_map. The converts/validators that come from L2 make it behave in more usefull way. Do you think those levels must be explicitly written down in docs? I've also realized there are no examples for custom validator now, so this code will most likely be added to the library. Thanks for the example. It should definitely become a part of the documentation. Consider it added. Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: program options - generic validator
Hi Neal, Neal D. Becker wrote: Why not a generic default validator? Good question! I think that I planned to define specialization for common types, like int and float in library sources, so that client code does not have to instantinate them. As it is now, there are only specialized version, not not generic one. Hmm.. that should be fixed. However, I must admit that I don't know how to declare primary template and then instantinate some of them in library source. I can't put explicit instantination in header. And if I put explicit specialization, then I'll have to write the body. Any suggestions? BTW, I know typeid (T).name() doesn't really work, but I'm not sure what would be better. For builtin types one can create a type trait which will return good name. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Formal Review: Command Line Config library
Chuck Messenger wrote: * Library-managed default values I think it good idea. Need to flesh some details a bit. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Library-Mana ged_Default_Values_-_Program_Options_Suggestion Replace default_value() with optional 3rd arg to parameter(); hardwired [...] is fine. OK, I think we've mostly agreed. See the wiki. * add_options() should be able to parse arguments (also, %args%) That's a bit controversial. I don't yet see the 100% right approach. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_ Should_Be_Able_To_Parse_Arguments_-_Program_Options_Suggestion I get your motivation. I'll think about implementation. * Adaptive formatting (first field width) See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Adaptive_For matting_-_First_Field_Width_-_Program_Options_Suggestion We can't ignore that looks matter. Ugly won't fly. The question is: what if first field width is larger than maximum width? What can we do? * program_name() and %progname% I'm unsure on both of them. See my comments on Wiki See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Program_Name _-_Program_Options_Suggestion Show an example of hardcoded program name. For example: options_description desc(Usage: my_program 1.0.1 args OPTIONS\n OPTIONS); * Unified exception class I think such class exists already. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Unified_Exce ption_Class_-_Program_Options_Suggestion OK, but change exception name from error to program_options_error I'm almost indiffirent and will be happy to leave this question to others. * Put add_options() ascii args first It's completely up to reviewers. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_ Should_Be_Able_To_Parse_Arguments_-_Program_Options_Suggestion * Mandatory options Good idea. Output formatting is the only issue with me. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Mandatory_Op tions_-_Program_Options_Suggestion I like your format. Great! We've agreed. * Optional option present parameter to add_options() I'd like to see some use cases before adding this feature. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Optional_Opt ion_Present_Parameter_To_Add_Options_-_Program_Options_Suggestion E.g., grep -f file -- we want file name, and pattern-in-file mode I understand your motivation now, and need only decide on exact interface. * add_options() should use references rather than pointers That's style issue, and I'm not partial. Let's hear other opinions. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Add_Options_ Should_Use_References_Rather_Than_Pointers_-_Program_Options_Suggestion I don't agree. Pointer for return value is C semantics. In C++, pointers denote optional values. Non-const references are for return values. Ehm... the pointer for return values rule is from TC++PL, IIRC. * User exception If you have practical need to them, I'll add them. See http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?User_Excepti on_-_Program_Options_Suggestion No - this was just a workaround for lack of integrated argument processing. OK. Thanks again for such a comprehensive review! - Volodya - Chuck ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: CVS status
Gennaro Prota wrote: I drop an idea: suppose that when there's a new commit the CVS informs, via e-mail, the penultimate people that had done a commit. This way I (the generic developer) can do the following: before doing any commit check out the whole repository (in order to have the newest state of everything), then _until I receive the informative mail_, I do keep my copy. When I receive the mail I know that the duty to keep the files is up to someone else. Of course that doesn't protect against failures of the last committor machine, but... As a further precaution we could advice for keeping a fresh checkout for at least one day, regardless of informative mails (provided that we can setup something similar). Thoughts? I think this is a bit more complicated that it should be. Why don't just create boost-wide commit emails mailing list? All changes will be reflected in archives, so in case of emergency you'll have all the data to replay missing commits. Of course, what happens if ml archive is destroyed too as the same time... but that's less likely. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: CVS status
Gennaro Prota wrote: I think this is a bit more complicated that it should be. Why don't just create boost-wide commit emails mailing list? Off-hand _this one_ seems more complicated, because it involves more people than necessary and forces to keep the diffs (though just for, say, a couple of days - longer than that, we have the daily backups). Actually, it does not involve any people: just create a new list on sourceforge and set up commit emails. Unless disk crashes, nobody is forced to even look at this list. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast problem
Kevlin Henney wrote: In article [EMAIL PROTECTED], Vladimir Prus [EMAIL PROTECTED] writes The principle of least astonishment can be applied in a different way. We all know that lexical cast uses streams, and stringstream ss( 1 ); int i; ss i; cout i \n; certainly works. It's surprising that lexical_castint( 1 ) does not work. This is argument by false analogy. If the above were to fail, eg a was the initialiser, it won't throw an exception. Unfortunately, I don't understand what you mean. What's the above and what's it? Yes, there is an underlying stringstream, but lexical_cast uses stringstream; it is not stringstream. The current model ensures that, unlike I/O streams, input and output are treated more symmetrically and various constraints, such as the full conversion of a buffered representation, are strongly enforced. Hm, where the current model comes from? The version in CVS was added during 1.30 preparation and it was expected to fix some known problems with the previous version. You now say about current model which emerged, and I don't see *anything* in docs about it. The docs, actually, don't say how spaces are handled, or that any changes were made to this part and that all input should be consumed. A quick inspection of its history reveals a move away from the looser I/O stream model of conversion. The original design was softer and more script-like in its tolerances, but the general needs that most users had were stricter. I've some problems with this reasoning: 1. I never seen posts which asked for this change of semantic and I'm not sure it's good in practice. 2. As I say in other post (http://article.gmane.org/gmane.comp.lib.boost.devel/19133), the change breaks conversions to user-defined classes. If you want the kind of behaviour described above, I suggest using -- wait for it -- std::stringstream, Using std::stringstream is not that convenient, for the reasons described in lexical_cast docs. or writing a trim function that cuts leading and trailing space characters. This would help in string-something conversion case, though I don't like extra efforts. BTW, I cannot find the test case for trailing space in lexical_case_test.cpp, and... the following works with gcc 3.2: ... Thanks for spotting this. That is missing, and the accommodation of that behaviour is legacy -- it is incompatible with the idea that full conversion only is supported, and the way that textual types are handled. I can say only that I'd be -1 on the change, because I don't see the practical need to it. Alas, it's not very helpfull as a debugging tool as it is. No, and that's because it is not primarily intended to be a debugging tool. The only resolution I can see that accommodates this in part, without running foul of reasonable constraints on exception types, is to use a fixed-size char array that truncates the residual buffer content if necessary. Hmm... why is this complexity is needed? Can't you just have an shared_ptrstd::string member in exception class, which the entire 'what' message. Yes, the required memory is unbounded, but copy ctor will never throw an exception. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Test monitor vs. unit test framework
I have quite a bunch of tests which use test execution monitor and look like
this
int test_main(int ac, char* av[])
{
test_a();
test_b();
}
and so on. There's another method, in which there's init_unit_test_suite
method, which returns a property initialized test_suite object.
What are the advandates of the second method, assuming all my tests will be
free-standing functions? Is there something that I loose by not switching to
that method? I'm really trying to understand if I should invest any time into
this.
TIA,
Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
James Curran wrote: Vladimir Prus wrote: The intent is to get/change the part of leaf name after the first dot. um.. After the FIRST dot or the LAST dot. In Win32, james.m.curran.txt the extention is txt, not m.curran.txt Certainly the last. My existing code uses the last dot, in fast, and I've just typed wrong. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [filesystem] new functions proposals
Jason House wrote: James Curran wrote: Vladimir Prus wrote: The intent is to get/change the part of leaf name after the first dot. um.. After the FIRST dot or the LAST dot. In Win32, james.m.curran.txt the extention is txt, not m.curran.txt Note too that on Windows/NTFS, names like 'c:/foo/bar.baz.blip:blat' are legal. The 'extension' is '.blip', not '.baz.blip' and not '.baz.blip:blat'. :blat ??? 1. I have no clue what that would mean I, too, had not clue about this until now. 2. Is there any handling of :blat in any way shape or form in the file system stuff? I don't remember seeing any description of that case... Does those alternate streams belong to filesystem library at all? For one thing, the ':' symbols is not allowed anywhere except for root name. For another thing, on all systems but NTFS, bar.baz.blip:blat would be considered as having blip:blat extension, and making the function behave differently on NTFS is confusing. Lastly, the 'extension' function is supposed to do only syntax transformation, but to tell if you're on Fat32 or NFTS you'd need to ask operating system... - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Sandbox iterator adaptors update
David Abrahams wrote:
I've a very basic question for now: how to I convert *rst files in
documentation to something nice-looking, like hmtl?
ReStructuredText:
http://docutils.sourceforge.net/README.html#quick-start
Use the html.py script in the tools/ directory
Thanks, it worked. I've some initial comments now.
1. The documentation seems incomplete. I can't find the description of methods
for Derived class of iterator_facade, for example.
2. What is the relation with new iterator categories. Am I supposed to pass
old categories as template parameters to facade/adapter.
3. The attached code does not compile with gcc 3.2, saying that:
/usr/include/c++/3.2/bits/stl_iterator_base_types.h:123: no type named `
iterator_category' in `class my_old_iterator'
The message is correct, but... I've explicitly specified iterator category
when declaring iterator adaptor. Am I doing something wrong?
TIA,
Volodya
#include boost/iterator.hpp
#include boost/iterator/iterator_adaptor.hpp
#include iostream
class my_old_iterator {
public:
my_old_iterator() : m_i(0) {}
void advance() { ++m_i; }
int current() { return m_i; }
bool eof() { return m_i == 10; }
private:
int m_i;
};
class adapted_iterator :
public boost::iterator_adaptor adapted_iterator, my_old_iterator, int,
std::forward_iterator_tag
{
public:
};
int main()
{
adapted_iterator i, e;
}___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Graph] Improved creation of visitors from functionobjects
Douglas Gregor wrote: On Thursday 17 April 2003 03:50 am, Vladimir Prus wrote: IOW, now specifying behaviour for event requires creating a new class, with event_filter typedef and operator(). You propose to pass lambda, immediately on dfs_visitor creation. I think this is indeed convenient. I've some concerns about efficiency, but why don't try? It's a little worse than just creating the new class with event_filter: you need to build up a cons-list out of std::pairs containing your visitor types. Yep, but that's the easy part of the game, IMO. The efficiency won't be any worse than using a bind object elsewhere in a program. The do_on_XXX functions merely augment the visitor list of dfs_visitor and return a new dfs_visitor object. This precisely what worries me -- bind might not be very efficient. I may be a overly concerned about efficiency at the moment --- recently wrote a graph algorithm in BGL which turned out to be 100 times slower that a simply-coded one :-( Not sure if this is BGL's fault or the problem with the algorithm, though. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BOOST_CHECK_EQUAL_COLLECTIONS proposal
I've just tried to use the above test tool, and see the following:
svertka.driver.cpp(127): error in test_svertka: test {result.begin(),
result.end()} == {result2, ...} failed [-431600044 != -78651042]
I think this message misses one thing: the position where mismatch occured. If
differing values are printed, it's natural to print position, too. Gennadiy,
how do you think?
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: BOOST_CHECK_EQUAL_COLLECTIONS proposal
Gennadiy Rozental wrote:
svertka.driver.cpp(127): error in test_svertka: test
{result.begin(), result.end()} == {result2, ...} failed [-431600044 !=
-78651042]
I think this message misses one thing: the position where mismatch
occured. If
differing values are printed, it's natural to print position, too.
Gennadiy,
how do you think?
I could probably add at position N after failed, though it would make
an comparisons implementation much more intricate.
On the first look, seems like eqaul_and_continue_impl should take extra
parameter --- number of element, with default value of 0. Am I missing
something?
- Volodya
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::any feature request
Hi Maxim, And here are the Intel VTune results (see the sources for details): CreationAssignment struct13383 27358 boost::any3846331870 TailoredAny 9151310717 TailoredAnyLoki::SmallObject3855110022 IOW, TailoredAny behaves much worse on creation in default configuration. It behaves much better on assignment, in tuned configuration. Hmm.. Looking at your implementation, I still have two questions that I've already raised: 1. Why don't you specify allocator during assignment/creating. Why lift it to template parameter for any? 2. What happens when you copy any with custom allocator into any with default allocator. In your code, the allocators are retained on copy. This has a problem I've described previously --- if any is created in some library, then it's created with default allocators and there's nothing you can do about it... which somewhat reduces the gains. And, BTW, did you run tests on more than one compiler. The small objects optimization might be implemented in runtime library already. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] iterator_adaptors question
I have a simple class, which three interesting methods: - current - advance - eof I had a custom wrapper which converts any class which such methods (and some typedefs) and now I want to use iterator adaptors library. What is the best approach? I can roll a new policy class, of course. But I think the above set of operation is quite handy when one wants to create a new input iterator. The wrapped class is also close to Generator, with added 'eof' method. So, I wonder, if I should strive to make something reusable, which can be added to the library? - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator_adaptors question
David Abrahams wrote: But I think the above set of operation is quite handy when one wants to create a new input iterator. The wrapped class is also close to Generator, with added 'eof' method. So, I wonder, if I should strive to make something reusable, which can be added to the library? Sure, great idea... but please take my suggestion and try it with the work in the sandbox. I hope that the current IA design will be completely replaced with the new (very different) one for 1.31, and it's important to have as many proofs-of-concept as possible to make sure we got the interface right. OK, I'll use the sandbox version. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::any feature request
Hi Doug,
Will I be able to write:
anyfast_allocator a;
values[10] = a;
?
IOW, I don't think your proposal provides any means to convert between
'any' with different allocators. And I'm not sure you can easily achieve
that
Sure you can. You just store a copy of the allocator along with the data
you are holding. The holders would look like this:
[...]
virtual holder* clone() = 0
{
holder* result = allocator.allocate(1);
new (result) holder(value, allocator);
return result;
}
Aha, that's what I was trying to say, but not very clearly. Yes, *this* will
work. But... it means that if you do
any a1;
anyfast_allocator a2 = a1;
Then value stored in a2 will be allocated using a1's allocator, not a2's.
Once any is created with a specific allocator, all copies will use the same
allocator, which is doubtful behaviour. In the example above, the
fast_allocator parameter has no effect at all.
Even if this behavior is desirable, you don't need to add template parameter
to 'any'. You can add template parameter to 'holder' only, and another
constructor, which allows to specify allocator.
- Volodya
virtual void destroy() = 0
{
Allocator allocator(this-allocator);
this-~holder();
allocator.deallocate(this);
}
};
This requires allocators to be CopyConstsructible, of course.
Doug
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::any feature request
Hi Maxim,
I think it would be great to make boost::any's memory allocation
strategy for value holder customizable. It would allow to use not only
global new operator, but any other special fast allocators like, for
example, Loki::SmallObject.
The changes are minor and would not break existing code.
All it takes is to change class name and:
struct use_default_allocator {};
//class any
templateclass A = use_default_allocator class any_ex
And change any_cast functions appropriately.
Say, I have
std::mapstd::string, boost::any values;
Will I be able to write:
anyfast_allocator a;
values[10] = a;
?
IOW, I don't think your proposal provides any means to convert between 'any'
with different allocators. And I'm not sure you can easily achieve that
I've measured performance using Intel VTune. The
any_exLoki::SmallObject was about twice as fast as any_ex with MS
VC++ 7 and Intel C++ 7.
On what testcase?
So, the hardcoded memory allocation strategy makes more harm then good
to boost::any. Changes would make boost::any more extensible and
reusable.
Unless there's a way to convert between different any's, the idea is
questionable. Say, a library uses 'any' in interface. It certainly uses
default allocator, and without conversion, will impose that default allocator
on client code. IOW, you cannot write
anyfast_allocator a = some_lib::get_value(foo);
- Volodya
P.S. And, BTW, it would be great to see the complete code that you propose (or
a diff to CVS HEAD).
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [test] BOOST_CHECK_THROW proposal
Hello, I'm just using BOOST_CHECK_THROW tool. It works ok, but in addition to exception type I'd like to test the value of 'what()', just to be sure. Is there any way. Would it be possible to add another tool, which checks both type and 'what()' content? TIA, Volodya P.S. I also think there is a couple of typos in docs for BOOST_CHECK_THROW: The tool executes the supplied statement and check that it throw the supplied exception. Should there be and checks that it throws, i.e. with extra s at the end of two words? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 still broken -- More lexical_cast
Terje Slettebø wrote: /home/boost/boost-regress/boost/boost/lexical_cast.hpp:173: syntax error before `;' Looking at the CVS, it appears the reason for this is that config/compiler/gcc.hpp no longer defines BOOST_NO_STRINGSTREAM, even though it should, at least for 2.95.x and below, as is shown with the above errors.. The change was done about a year ago, though, so it appears lexical_cast hasn't been working on g++ 2.95.x for a long time. I don't have much to say, but lexical_cast was broken just now. My code which was compiling a week ago and wasn't changed since now produces the same warning, after updating to RC_1_30_0. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken -- More lexical_cast
Gennaro Prota wrote: Ok. I've forwarded this to Kevlin. Maybe there's more than one problem here. I see that Vladimir talks about warnings while Jeff about errors. Also maybe it helps to see the exact condition to define BOOST_NO_STRINGSTREAM in config/stdlib/sgi.hpp, with the comment therein? Just trying to lend a hand... I'm sorry, warning in my post is typo. It should have been error, and the error message is precisely the same as previously reported. I just wanted to note that lexical_cast was not broken with gcc 2.95.4 until recently. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: filling in vertex_name_t property for adjacency_list
posted mailed Dieter Vrancken wrote: Ok. I'll try it again :) (sorry for the delayed reply, had some difficulties with my newsreader) I'm afraid the information you given is not enough, especially for folks without access to that specific compiler. It's much better to post (1) complete and simple example which fails to compile and (2) exact error messages. If you could try with CVS version, this would be excellent. What is this cvs version you are refering to? Please see http://www.boost.org/more/download.html#CVS It was pretty much the complete example. Here is it again. There's a big difference between 90% of the code and the 100%. I can paste the latter into emacs, run compilation and see the error immediately. Otherwise, I'll have to spot the problem in the code by carefully looking at it, which is harder. Therefore, I am much more likely to help if I see complete example. I'm sure this is the general rule. // declare the graph typedef adjacency_listsetS, vecS, directedS, vertex_name_t, no_property, graph_name_t, setS Graph; Graph g(v_names.size()); When I change this to: typedef adjacency_listsetS, vecS, directedS, propertyvertex_name_t, std::string, no_property, propertygraph_name_t, std::string, setS Graph; everything starts to work on g++-3.2. I think this must be the problem. If you really want all the error messages ... here is the complete output from the visual studio. I don't know if it's that helpful. Compiling... main.cpp c:\boost_1_29_0\boost\pending\detail\property.hpp(89) : error C2039: 'next_type' : is not a member of '`global namespace'' Uph... this specific error message looks plain wrong :-) HTH, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: filling in vertex_name_t property for adjacency_list
Dieter Vrancken wrote: Ok. I'll try it again :) (sorry for the delayed reply, had some difficulties with my newsreader) I'm afraid the information you given is not enough, especially for folks without access to that specific compiler. It's much better to post (1) complete and simple example which fails to compile and (2) exact error messages. If you could try with CVS version, this would be excellent. What is this cvs version you are refering to? Please see http://www.boost.org/more/download.html#CVS It was pretty much the complete example. Here is it again. There's a big difference between 90% of the code and the 100%. I can paste the latter into emacs, run compilation and see the error immediately. Otherwise, I'll have to spot the problem in the code by carefully looking at it, which is harder. Therefore, I am much more likely to help if I see complete example. I'm sure this is the general rule. // declare the graph typedef adjacency_listsetS, vecS, directedS, vertex_name_t, no_property, graph_name_t, setS Graph; Graph g(v_names.size()); When I change this to: typedef adjacency_listsetS, vecS, directedS, propertyvertex_name_t, std::string, no_property, propertygraph_name_t, std::string, setS Graph; everything starts to work on g++-3.2. I think this must be the problem. If you really want all the error messages ... here is the complete output from the visual studio. I don't know if it's that helpful. Compiling... main.cpp c:\boost_1_29_0\boost\pending\detail\property.hpp(89) : error C2039: 'next_type' : is not a member of '`global namespace'' Uph... this specific error message looks plain wrong :-) HTH, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost RPMS (Was: [boost] Outstanding patches and fixes)
David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Doesn't seem to be in the archives. It's from Neal D. Becker 10 Mar 2003. Here is the entire message: I really appreciate the boost rpms that have been made available. I hope we can improve one thing in the upcoming release. rpm -q --requires boost-python-devel boost-devel libpython-devel Unfortuantely, on RedHat it's called python-devel I hope there is some way to fix this. Since I never made a boost RPM, I don't think I'm the guy to address it. I believe that Malte Starostik is the right person for dealing with this issue. I'm pretty sure the different is naming is difference between Mandrake and Redhat, but have no idea how to fix it. And, while we're on it, I think it would be much better if RPM are officially available (i.e from sourceforge download page). Lastly, this issue is not release show-stopper: the *spec file which creates RPM is not in Boost CVS tree. Malte can make the changes when 1.30 is out. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
