1# Inputs and Parsing 2 3Assuming that the [grammar rules](Rules-and-Grammars.md) are ready, and the [actions and states](Actions-and-States.md) prepared, performing a parsing run consists of two steps: 4 51. Constructing an *input* class that represents the to-be-parsed data. 62. Calling a PEGTL *parse* function with the input (and any states). 7 8```c++ 9using namespace tao::pegtl; 10 11struct my_grammar : ...; 12 13template< typename Rule > 14struct my_actions {}; 15 16// Specialisations of my_actions as required... 17 18bool my_parse( const std::string& filename, my_state& state ) 19{ 20 file_input in( filename ); 21 return parse< my_grammar, my_actions >( in, state ); 22} 23``` 24 25In the context of PEGTL input classes and positions there is usually an additional (i.e. beyond indicating or supplying the to-be-parsed data) string parameter `source` that identifies where the to-be-parsed data comes from. 26For example when parsing a file with one of the appropriate included input classes, the filename is automatically used as `source` so that it will appear in exceptions and error messages. 27In other cases the `source` parameter needs to be explicitly passed to the input's constructor. 28 29All classes and functions on this page are in namespace `tao::pegtl`. 30 31## Contents 32 33* [Tracking Mode](#tracking-mode) 34* [Line Ending](#line-ending) 35* [Source](#source) 36* [File Input](#file-input) 37* [Memory Input](#memory-input) 38* [String Input](#string-input) 39* [Stream Inputs](#stream-inputs) 40* [Argument Input](#argument-input) 41* [Parse Function](#parse-function) 42* [Nested Parsing](#nested-parsing) 43* [Incremental Input](#incremental-input) 44 * [Buffer Size](#buffer-size) 45 * [Discard Buffer](#discard-buffer) 46 * [Custom Rules](#custom-rules) 47 * [Custom Readers](#custom-readers) 48 * [Buffer Details](#buffer-details) 49* [Error Reporting](#error-reporting) 50* [Deduction Guides](#deduction-guides) 51 52## Tracking Mode 53 54Some input classes allow a choice of tracking mode, or whether the `byte`, `line` and `column` counters are continuously updated during a parsing run with `tracking_mode::eager`, or only calculated on-demand in `position()` by scanning the complete input again with `tracking_mode::lazy`. 55 56Lazy tracking is recommended when the position is used very infrequently, for example only in the case of throwing a `parse_error`. 57 58Eager tracking is recommended when the position is used frequently and/or in non-exceptional cases, for example when annotating every AST node with the line number. 59 60## Line Ending 61 62All input classes allow the choice of which line endings should be recognised by the `eol` and `eolf` rules, and used for line counting. 63The supported line endings are `cr`, a single carriage-return/`"\r"`/`0x0d` character as used on classic Mac OS, `lf`, a single line-feed/`"\n"`/`0x0a` as used on Unix, Linux, Mac OS X and macOS, and `crlf`, a sequence of both as used on MS-DOS and Windows. 64 65The default template parameter for all input classes is `eol::lf_crlf` which recognises both Unix and MS-DOS line endings. 66The supplied alternatives are `eol::cr`, `eol::lf`, `eol::crlf` and `eol::cr_crlf`. 67 68## Source 69 70Some input classes allow a choice of how to store the source parameter, with the default being a `std::string`. 71When creating many instances of an input class, it can be changed to a non-owning `const char*` to optimise away the memory allocation performed by `std::string`. 72 73## File Input 74 75The classes `file_input<>`, `read_input<>` and, on supported platforms, `mmap_input<>`, can be used to parse the contents of a file. 76 77* `read_input<>` uses C "stdio" facilities to read the file. 78* `mmap_input<>` uses `mmap(2)` on POSIX compliant systems or `MapViewOfFile()` on Windows. 79* `file_input<>` is derived from `mmap_input<>` when available, and `read_input<>` otherwise, inheriting the respective constructors. 80 81They immediately make available the complete contents of the file; `read_input<>` reads the entire file upon construction. 82 83The constructors that take a `FILE*` argument take ownership of the file pointer, i.e. they `fclose()` it in the destructor. 84 85```c++ 86template< tracking_mode P = tracking_mode::eager, typename Eol = eol::lf_crlf > 87struct read_input 88{ 89 explicit read_input( const std::filesystem::path& path ); 90 read_input( const std::filesystem::path& path, const std::string& source ); 91 92 read_input( FILE* file, const std::filesystem::path& path ); 93 read_input( FILE* file, const std::filesystem::path& path, const std::string& source ); 94}; 95 96template< tracking_mode P = tracking_mode::eager, typename Eol = eol::lf_crlf > 97struct mmap_input 98{ 99 explicit mmap_input( const std::filesystem::path& path ); 100 mmap_input( const std::filesystem::path& path, const std::string& source ); 101}; 102 103template< tracking_mode P = tracking_mode::eager, typename Eol = eol::lf_crlf > 104using file_input = mmap_input< P, Eol >; // Or read_input when no mmap_input available. 105``` 106 107## Memory Input 108 109The class `memory_input<>` can be used to parse existing contiguous blocks of memory like the contents of a `std::string`. 110The input **neither copies the data nor takes ownership, it only keeps pointers**. 111The various constructors accept the to-be-parsed data in different formats. 112The `source` parameter is required for all constructors to disambiguate the different overloads. 113If you don't want to specify a source just use the empty string (`""`). 114 115The constructors that only takes a `const char* begin` for the data uses `std::strlen()` to determine the length. 116It will therefore *only* work correctly with data that is terminated with a 0-byte (and does not contain embedded 0-bytes, which are otherwise fine). 117 118The constructors that take additional `byte`, `line` and `column` arguments initialise the internal counters with the supplied values, rather than the defaults of `0`, `1` and `1`. 119 120```c++ 121template< tracking_mode P = tracking_mode::eager, typename Eol = eol::lf_crlf, typename Source = std::string > 122class memory_input 123{ 124 template< typename T > 125 memory_input( const internal::iterator& iter, const char* end, T&& source ) noexcept(...); 126 127 template< typename T > 128 memory_input( const char* begin, const char* end, T&& source ) noexcept(...); 129 130 template< typename T > 131 memory_input( const char* begin, const std::size_t size, T&& source ) noexcept(...); 132 133 template< typename T > 134 memory_input( const std::string& string, T&& source ) noexcept(...); 135 136 template< typename T > 137 memory_input( const char* begin, T&& source ) noexcept(...); 138 139 template< typename T > 140 memory_input( const char* begin, const char* end, T&& source, 141 const std::size_t byte, const std::size_t line, const std::size_t column ) noexcept(...); 142}; 143``` 144 145### Examples 146 147###### Example 1 148 149```c++ 150memory_input in1( "this is the input to parse", "" ); 151``` 152 153Construct a `memory_input` with default tracking mode, default end-of-line mode (accepting Unix and MS-DOS line endings), and default source storage. 154As there are only two parameters, the 5th overload from above is choosen. 155The data to parse is given directly as a string literal which is not copied. 156As no pointer to the end or the size of the input is given, the length of the data to be parsed will be determined by calling `strlen` on the pointer passed as the first parameter. 157The source is the empty string. 158 159###### Example 2 160 161```c++ 162struct packet 163{ 164 // ... 165 const std::array< char >& buffer() const noexcept; 166 std::string identifier() const; 167 // ... 168}; 169 170packet p = ...; // some UDP packet class 171 172memory_input< tracking_mode::lazy, eol::crlf > in2( p.buffer().begin(), p.buffer().end(), p.identifier() ); 173``` 174 175Consider a UDP packet that was received and should be parsed. 176Construct a `memory_input` with lazy tracking mode, MS-DOS end-of-line mode (accepting only MS-DOS line endings), and default source storage. 177This example chooses the second overload from above. 178The data to parse is given as two `const char*` pointers (as the data is not null-terminated) and is, of course, not copied. 179Consider the source to be an identifier for the packet that was received, e.g. a string constructed from the timestamp, the source IP/port, the interface it was received on, a sequence number, or similar information. 180Note that this example shows why the source parameter is necessary to disambiguate the overloads. 181If the source would be optional (defaulted), the signature of this overload would also match the first example and therefore be ambiguous. 182 183### Additional Remarks 184 185Note that `noexcept(...)` is a conditional noexcept-specification, depending on whether the construction of the source stored in the class can throw given the perfectly-forwarded parameter `source`. Technically, it is implemented as `noexcept( std::is_nothrow_constructible< Source, T&& >::value )`. 186 187With the default `Source` type of `std::string`, the `source` parameter to the constructors is usually a `const char*` or (any reference to) a `std::string`, but anything that can be used to construct a `std::string` will work. When `Source` is set to `const char*` then only a `const char *` (or something that can implicitly be converted to one) will work. 188 189The implementation of the constructors is different than shown. 190They should be used "as if" this was the actual signature. 191 192## String Input 193 194The class `string_input<>` can also be used to parse a `std::string`. 195Unlike class `memory_input<>`, this class stores a copied (or moved) version of the data for which it takes ownership. 196 197```c++ 198template< tracking_mode P = tracking_mode::eager, typename Eol = eol::lf_crlf, typename Source = std::string > 199class string_input 200{ 201 template< typename V, typename T > 202 string_input( V&& data, T&& source ) noexcept(...); 203 204 template< typename V, typename T > 205 string_input( V&& data, T&& source, 206 const std::size_t byte, const std::size_t line, const std::size_t column ) noexcept(...); 207}; 208``` 209 210### Example 211 212```c++ 213std::string content(); // returns the content 214 215string_input in1( content(), "from_content" ); 216``` 217 218Construct a `string_input` with default tracking mode, default end-of-line mode (accepting Unix and MS-DOS line endings), and default source storage. 219The data returned from calling `content()` is copied into the input. 220The source is `from_content`. 221 222### Additional Remarks 223 224Note that the implementation of the constructors is different than shown. 225They should be used "as if" this was the actual signature. 226 227## Stream Inputs 228 229The classes `cstream_input<>` and `istream_input<>` can be used to parse data from C-streams (`std::FILE*`) and C++-streams (`std::istream`), respectively. 230Unlike the file inputs above, they internally use `buffer_input<>` and therefore do *not* read the complete stream upon construction. 231 232They all have a single constructor that takes a stream, the maximum buffer size, and the name of the source. 233Note that these classes only keep a pointer/reference to the stream and do **not** take ownership; in particular `cstream_input<>` does **not** call `std::close()`. 234 235See [Incremental Input](#incremental-input) for details on the `maximum` argument, and how to use the mandatory [discard facilities](#discard-buffer). 236 237```c++ 238template< typename Eol = eol::lf_crlf > 239struct cstream_input 240{ 241 cstream_input( std::FILE* stream, const std::size_t maximum, const char* source ); 242 cstream_input( std::FILE* stream, const std::size_t maximum, const std::string& source ); 243}; 244 245template< typename Eol = eol::lf_crlf > 246struct istream_input 247{ 248 istream_input( std::istream& stream, const std::size_t maximum, const char* source ); 249 istream_input( std::istream& stream, const std::size_t maximum, const std::string& source ); 250}; 251``` 252 253Note that the implementation of the constructors is different than shown. 254They should be used "as if" this was the actual signature. 255 256## Argument Input 257 258The class `argv_input<>` can be used to parse a string passed from the command line. 259 260```c++ 261template< tracking_mode P = tracking_mode::eager, typename Eol = eol::lf_crlf > 262class argv_input 263{ 264 argv_input( char** argv, const std::size_t n ); 265 argv_input( char** argv, const std::size_t n, const char* source ); 266 argv_input( char** argv, const std::size_t n, const std::string& source ); 267}; 268``` 269 270If no `source` is given, the source is set to `"argv[N]"` where N is the string representation of `n`. 271 272Note that the implementation of the constructors is different than shown. 273They should be used "as if" this was the actual signature. 274 275## Parse Function 276 277The parse functions accept the following template parameters and arguments: 278 279- The [`Rule` class](Rules-and-Grammars.md) represents the top-level parsing rule of the grammar and is mandatory. 280- The [`Action<>` class template](Actions-and-States.md) is required to actually do something during a parsing run. 281- The [`Control<>` class template](Control-and-Debug.md) is only required for grammar debugging or some advanced uses. 282- The [`States`](Actions-and-States.md#changing-states) are the types of the objects that are passed to all actions and control hooks. 283 284Additionally, two enumeration values can be used to control the behaviour: 285 286- The `apply_mode` which can also be set to `nothing` in order to disable action invocations, just like the `disable<>` rule does. 287- The `rewind_mode` which can also be set to `dontcare` in order to not require rewinding of the input on local failure, a micro optimisation. 288 289The result of a parsing run, i.e. an invocation of `tao::pegtl::parse()`, can be either 290 291- *success*, a return value of `true`, 292- *local failure*, a return value of `false`, 293- *global failure*, an exception of type `tao::pegtl::parse_error`, or 294- any other exception thrown by the input class or an action function. 295 296```c++ 297template< typename Rule, 298 template< typename... > class Action = nothing, 299 template< typename... > class Control = normal, 300 apply_mode A = apply_mode::action, 301 rewind_mode M = rewind_mode::required, 302 typename ParseInput, 303 typename... States > 304bool parse( ParseInput& in, 305 States&&... st ); 306``` 307 308## Nested Parsing 309 310Nested parsing refers to an (inner) parsing run that is performed "in the middle of" another (outer) parsing run, for example when one file "includes" another file. 311 312The difference to the regular `tao::pegtl::parse()` function is that `tao::pegtl::parse_nested()` takes care of adding to the `std::vector` of `tao::pegtl::position` objects in the exception class `tao::pegtl::parse_error`. 313This allows generating error messages of the form "error in file F1 line L1 included from file F2 line L2...". 314 315Calling `parse_nested()` requires one additional argument compared to `parse()`, the input from the outer parsing run as first argument. 316Everything else remains the same. 317 318```c++ 319template< typename Rule, 320 template< typename... > class Action = nothing, 321 template< typename... > class Control = normal, 322 apply_mode A = apply_mode::action, 323 rewind_mode M = rewind_mode::required, 324 typename OuterInput, 325 typename ParseInput, 326 typename... States > 327bool parse_nested( const OuterInput& oi, 328 ParseInput& in, 329 States&&... st ); 330``` 331 332## Incremental Input 333 334The PEGTL is designed and optimised for parsing single contiguous blocks of memory like a memory-mapped file or the contents of a `std::string`. 335In cases where the data does not fit into memory, or other reasons prevent parsing the data as single memory block, an *incremental* input can be used. 336 337This allows parsing with only (small) portions of the input in a memory buffer at any single time. 338The buffer is filled automatically, however the [*discard* facilities](#discard-buffer) must be used to regularly flush the buffer and make space for a new portion of input data. 339 340The [stream inputs](#stream-inputs) are ready-to-use input classes for C++-style and C-style streams. 341Apart from having to use the [discard facilities](#discard-buffer), and some extra care when implementing [custom rules](#custom-rules), they can be used just like any other [input class](Inputs-and-Parsing.md). 342 343### Buffer Size 344 345The [stream inputs](#stream-inputs), and all other inputs based on `buffer_input<>`, contain a buffer that is allocated in the constructor. 346The buffer capacity is the sum of a *maximum* value and a *chunk* size. 347 348The maximum value is passed to the constructor as function argument, the chunk size is a (rarely changed) template parameter. 349The required buffer capacity depends on the grammar, the actions, *and* the input data. 350 351The buffer must be able to hold 352 353* any and all data for look-ahead performed by the grammar, 354* any and all data for back-tracking performed by the grammar, 355* any and all data for actions' [`apply()`](Actions-and-States.md#apply) (not [`apply0()`](Actions-and-States.md#apply0)). 356 357For example consider an excerpt from the JSON grammar from `include/tao/pegtl/contrib/json.hpp`. 358 359```c++ 360struct xdigit : abnf::HEXDIG {}; 361struct unicode : list< seq< one< 'u' >, rep< 4, must< xdigit > > >, one< '\\' > > {}; 362struct escaped_char : one< '"', '\\', '/', 'b', 'f', 'n', 'r', 't' > {}; 363struct escaped : sor< escaped_char, unicode > {}; 364struct unescaped : utf8::range< 0x20, 0x10FFFF > {}; 365struct char_ : if_then_else< one< '\\' >, must< escaped >, unescaped > {}; 366 367struct string_content : until< at< one< '"' > >, must< char_ > > {}; 368struct string : seq< one< '"' >, must< string_content >, any > 369{ 370 using content = string_content; 371}; 372``` 373 374The rule `string_content` matches JSON strings as they occur in a JSON document. 375If an action with `apply()` (rather than `apply0()`) is attached to the `string_content` rule, the buffer capacity is an upper bound on the length of the JSON strings that can be processed. 376 377If the actions are only attached to say `unescaped`, `escaped_char` and `rep< 4, must< xdigit > >`, the latter because it, too, occurs in an (implicit, inside of `list`) unbounded loop, then the JSON strings are processed unescaped-character-by-unescaped-character and escape-sequence-by-escape-sequence. 378As long as the buffer is [discarded](#discard-buffer) frequently, like after every unescaped character and every single escape sequence, a buffer capacity as small as 8 or 12 should suffice for parsing arbitrarily long JSON strings. 379 380Note that the [`eof`](Rule-Reference.md#eof) rule requires at least one byte of free buffer space when there is no unconsumed data in the buffer. 381 382### Discard Buffer 383 384To prevent the buffer from overflowing, the `discard()` member function of class `buffer_input<>` must be called regularly. 385 386**Discarding invalidates all pointers to the input's data and MUST NOT be used where backtracking to before the discard might occur AND/OR nested within a rule for which an action with input can be called.** 387 388Calling `discard()` on a non-buffered input is an empty method and will be optimised away completely. 389 390Usually you don't call `discard()` manually. Instead, one of the two following methods might be used. 391 392#### Via Rules 393 394The [`discard`](Rule-Reference#discard) rule behaves just like the [`success`](Rule-Reference.md#success) rule but calls the discard function on the input before returning `true`. 395 396#### Via Actions 397 398The `tao::pegtl::discard_input`, `tao::pegtl::discard_input_on_success` and `tao::pegtl::discard_input_on_failure` [actions](Actions-and-States.md) can be used to discard input non-intrusively, i.e. without changing the grammar like with the [`discard`](Rule-Reference.md#discard) rule. 399 400These actions are used in the usual way, by deriving a custom action class template specialisation from them. 401In the case of `discard_input`, the input is discarded unconditionally after every match attempt of the rule that the action is attached to. 402As `discard_input` is based on the `match()` method, it is unaffected by enabling or disabling actions (which only applies to the `apply`/`apply0`-methods). 403 404The other two variants behave as implied by their respective names, keeping in mind that "failure" is to be understood as "local failure" (false), no discard is performed on global failure (exception). 405Similarly "unconditional" is wrt. success or local failure, not global failure. 406 407```c++ 408template<> 409struct my_action< R > 410 : tao::pegtl::discard_input 411{ 412 // It is safe to implement apply() here if appropriate: 413 // discard() will be called by discard_input's match() 414 // only _after_ calling this action's apply(). 415}; 416``` 417 418In practice, since the "must"-rules like `must<>` and `if_must<>` inhibit backtracking, they can be good indicators of where to perform a discard. 419For example consider again this rule from the JSON grammar from `include/tao/pegtl/contrib/json.hpp`. 420 421```c++ 422struct unicode : list< seq< one< 'u' >, rep< 4, must< xdigit > > >, one< '\\' > > {}; 423``` 424 425The `xdigit` rule is within a `must`, wherefore we know that no backtracking is possible, so we could discard after `xdigit` or `must< xdigit >`. 426However then we can't attach an action with [`apply()`](Actions-and-States.md#apply) to the `rep< 4, ... >` since we would be discarding after every single digit. 427This is not ideal, it would be more efficient to process all four xdigits in a single action invocation. 428 429Looking close we can see that backtracking to before the `rep<>` is actually impossible because once the `list<>` has successfully matched `seq< one< 'u' >, rep< 4, must< xdigit > > >` it will never go back. 430It will attempt to match another backslash, the list item separator, and if successful loop to the `seq<>`, but once the next character is a `'u'`, the `must<>` in the `rep` seals the deal, there is no way to not complete the next list entry. 431 432Therefore we can safely attach an action to the `rep<>` that processes the four xdigits and then discards the input. 433 434```c++ 435template<> 436struct my_action< rep< 4, must< xdigit > > 437 : tao::pegtl::discard_input 438{ 439 template< typename ActionInput > 440 static void apply( const ActionInput& in, /* the states */ ) 441 { 442 assert( in.size() == 4 ); 443 // process the 4 xdigits 444 } 445}; 446``` 447 448Another good candidate in the JSON grammar to discard after is the `tao::pegtl::json::value` rule... 449 450### Custom Rules 451 452All incremental inputs included with the library and documented here are based on `buffer_input<>`. 453A custom rule that is compatible with incremental inputs needs to pay attention to the `amount` argument in the input's interface. 454Unlike the inputs based on `memory_input<>`, the `size( amount )` and `end( amount )` member functions do not ignore the `amount` argument, and the `require( amount )` member function is not a complete dummy. 455 456```c++ 457template< ... > 458class buffer_input 459{ 460 bool empty(); 461 std::size_t size( const std::size_t amount ); 462 const char* end( const std::size_t amount ); 463 void require( const std::size_t amount ); 464 ... 465}; 466``` 467 468The `require( amount )` member function tells the input to make available at least `amount` unconsumed bytes of input data. 469It is not normally called directly unless there is good reason to prefetch some data. 470 471The `empty()`, `size( amount )` and `end( amount )` member functions call `require( amount )`, or, in the case of `empty()`, `require( 1 )`. 472The `amount` parameter should be understood as a parsing rule wishing to inspect and consume *up to* `amount` bytes of input. 473 474A custom rule must make sure to use appropriate values of `amount`. 475For examples of how the `amount` is set by parsing rules please search for `in.size` in `include/tao/pegtl/internal/`. 476 477### Custom Readers 478 479An incremental input consists of `buffer_input<>` together with a *reader*, a class or function that is used by the buffer input to fill the buffer. 480 481The buffer input is a class template with multiple template parameters. 482 483```c++ 484template< typename Reader, 485 typename Eol = eol::lf_crlf, 486 typename Source = std::string, 487 std::size_t Chunk = 64 > 488class buffer_input; 489``` 490 491The `Eol` and `Source` parameters are like for the other [input classes](Inputs-and-Parsing.md#memory-input). 492The `Chunk` parameter is explained below in detail. 493The `Reader` can be anything that can be called like the following wrapper. 494 495```c++ 496std::function< std::size_t( char* buffer, const std::size_t length ) > 497``` 498 499The arguments and return value are similar to other `read()`-style functions, a request to read `length` bytes into the memory pointed to by `buffer` that returns the number of bytes actually read. 500Reaching the end of the input MUST be the only reason for the reader to return zero. 501The reader might be called again after returning zero, with the expectation of returning zero again. 502 503Note that `buffer_input<>` consumes the first two arguments to its constructor for the *source* and *maximum*, and uses perfect forwarding to pass everything else to the constructor of the embedded instance of `Reader`. 504 505For examples of how to implement readers please look at `istream_reader.hpp` and `cstream_reader.hpp` in `include/tao/pegtl/internal/`. 506 507### Buffer Details 508 509The buffer input's `Chunk` template parameter is actually used in multiple places. 510 5111. The `maximum` buffer capacity passed by the user is incremented by `Chunk`. 5122. A discard does nothing when there are less than `Chunk` bytes of consumed buffered data. 5133. The buffer input requests at least `Chunk` bytes from the reader if there is enough space. 514 515Note that the first and second point go hand-in-hand, in order to optimise away some discards, the buffer must be extended in order to guarantee that at least `maximum` bytes can be buffered after a call to discard, even when it does nothing. The third point is simply an optimisation to call the reader less frequently. 516 517## Error Reporting 518 519When reporting an error, one often wants to print the complete line from the input where the error occurred and a marker at the position where the error is found within that line. 520To support this, the `memory_input<>` class has member functions `at( p )`, `begin_of_line( p )`, `end_of_line( p )` and `line_at( p )` which take a `tao::pegtl::position` as parameter. 521The first three functions return a `const char*` to position `p`, the begin-of-line before `p`, or the end-of-line after `p` (or the end of the input if the input is not terminated by an end-of-line), respectively. 522For convenience, `line_at( p )` returns a `std::string_view` with the complete line around `p`. 523Example usage: 524 525```c++ 526// create input 'in' here... 527try { 528 // call parse on the input 'in' here... 529} 530catch( const parse_error& e ) { 531 const auto p = e.positions().front(); 532 std::cerr << e.what() << std::endl 533 << in.line_at( p ) << '\n' 534 << std::setw( p.column ) << '^' << std::endl; 535} 536``` 537 538All input classes based on `memory_input<>` support the above, while all classes based on `buffer_input<>` are unable to supply the same functionality as previous input might have been discarded already. 539Trying to call any of those functions on `buffer_input<>`-based instances will lead to a compile error. 540 541## Deduction Guides 542 543All input classes support [deduction guides](https://en.cppreference.com/w/cpp/language/class_template_argument_deduction), e.g. instead of `file_input<> in( "filename.txt" )` one can use `file_input in( "filename.txt" )`. 544 545Copyright (c) 2014-2020 Dr. Colin Hirsch and Daniel Frey 546