lix/src/libutil/types.hh

#pragma once


#include "ref.hh"

#include <list>
#include <set>
#include <map>


namespace nix {

using std::list;
using std::set;
using std::vector;

typedef list<std::string> Strings;
typedef set<std::string> StringSet;
typedef std::map<std::string, std::string> StringMap;

/* Paths are just strings. */

typedef std::string Path;
typedef list<Path> Paths;
typedef set<Path> PathSet;


}
Use "#pragma once" to prevent repeated header file inclusion 2012-07-18 18:59:03 +00:00			`#pragma once`
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-04 21:06:23 +00:00
Include config.h before any other header "config.h" must be included first, because otherwise the compiler might not see the right value of _FILE_OFFSET_BITS. We've had this before; see 705868a8a96a10f70e629433cfffc2d5cd2703eb. In this case, GCC would compute a different address for ‘settings.useSubstitutes’ in misc.cc because of the off_t in ‘settings’. Reverts 3854fc9b42d16b810f62b64194b699033b03aaf1. http://hydra.nixos.org/build/3016700 2012-09-11 18:45:42 +00:00
Move ref<t> into a separate header 2016-02-23 12:53:31 +00:00			`#include "ref.hh"`

* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-04 21:06:23 +00:00			`#include <list>`
			`#include <set>`
Add a Config class to simplify adding configuration settings The typical use is to inherit Config and add Setting<T> members: class MyClass : private Config { Setting<int> foo{this, 123, "foo", "the number of foos to use"}; Setting<std::string> bar{this, "blabla", "bar", "the name of the bar"}; MyClass() : Config(readConfigFile("/etc/my-app.conf")) { std::cout << foo << "\n"; // will print 123 unless overriden } }; Currently, this is used by Store and its subclasses for store parameters. You now get a warning if you specify a non-existant store parameter in a store URI. 2017-04-13 13:55:38 +00:00			`#include <map>`
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-04 21:06:23 +00:00
Fix build on gcc < 4.7 2014-10-20 16:15:50 +00:00
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-04 21:06:23 +00:00			`namespace nix {`

			`using std::list;`
			`using std::set;`
			`using std::vector;`
Make fmt() non-recursive 2017-05-11 15:06:07 +00:00
all things error to error.hh 2020-04-24 20:57:51 +00:00			`typedef list<std::string> Strings;`
			`typedef set<std::string> StringSet;`
Add a Config class to simplify adding configuration settings The typical use is to inherit Config and add Setting<T> members: class MyClass : private Config { Setting<int> foo{this, 123, "foo", "the number of foos to use"}; Setting<std::string> bar{this, "blabla", "bar", "the name of the bar"}; MyClass() : Config(readConfigFile("/etc/my-app.conf")) { std::cout << foo << "\n"; // will print 123 unless overriden } }; Currently, this is used by Store and its subclasses for store parameters. You now get a warning if you specify a non-existant store parameter in a store URI. 2017-04-13 13:55:38 +00:00			`typedef std::map<std::string, std::string> StringMap;`
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-04 21:06:23 +00:00
			`/* Paths are just strings. */`
all things error to error.hh 2020-04-24 20:57:51 +00:00
			`typedef std::string Path;`
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-04 21:06:23 +00:00			`typedef list<Path> Paths;`
			`typedef set<Path> PathSet;`

Don't interpret strings as format strings Ludo reported this error: unexpected Nix daemon error: boost::too_few_args: format-string refered to more arguments than were passed coming from this line: printMsg(lvlError, run.program + ": " + string(err, 0, p)); The problem here is that the string ends up implicitly converted to a Boost format() object, so % characters are treated specially. I always assumed (wrongly) that strings are converted to a format object that outputs the string as-is. Since this assumption appears in several places that may be hard to grep for, I've added some C++ type hackery to ensures that the right thing happens. So you don't have to worry about % in statements like printMsg(lvlError, "foo: " + s); or throw Error("foo: " + s); 2014-03-28 15:59:26 +00:00
* Use a proper namespace. * Optimise header file usage a bit. * Compile the parser as C++. 2006-09-04 21:06:23 +00:00			`}`