On 1/4/2016 10:25 AM, Russel Winder via Digitalmars-d wrote:
On Mon, 2016-01-04 at 01:44 -0800, Walter Bright via Digitalmars-d
wrote:
1. Make doing C++ style iostreams hard.
What is the problem with having the << and >> operators do input
output. Very object-oriented.
I'm surprised you'd ask. I thought this was well known.
1. ugly as hell
2. not exception safe
3. not thread safe
4. interleaved output in the middle of lines when writing to both stdout and
stderr
2..4 are caused by inability to encapsulate a sequence of these operations.
2. Prevent clever use of operator overloading and expression
templates to create
languages that look like D, but are NOT.
But it would be D. Boost.Sprint code may look like EBNF, but it is C++.
#define BEGIN {
#define END }
is still C++, too.
3. Work well when using operator overloading to implement arithmetic
types.
It is important that this works. But it should be possible to create an
operator algebra for any type: arithmetic types are a very small subset
of types used in computing.
What do you suggest when the operators and precedence of the desired algebraic
type simply do not map cleanly onto C++ operators and precedence grammar? Allow
users to define their own operators and redefine the precedence? Where is the
line that shouldn't be crossed?
I avoid regular expressions except when editing using ed, sed, or
emacs, so I cannot properly comment on the above. However I find
Boost.Sprint a very sensible way of using compile-time meta-object
protocols. You write a grammar in EBNF in the source code, and the
compiler writes the parser. Excellent use of internal DSL. And type
safe.
EBNF doesn't map onto C++ operators and precedence, either. It's still a hack:
https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_Form
With CFTE, the user can actually write actual EBNF.
