what do you think about this?

[alelvb]

Hello groupers,
I have a curiosity I'd like to be answered.

wouldn't it be great if C++ could give to the programmer the disposal
of wildcard operator such that it could be substituted by any user
(oportunaly) defined character symbol?

for example in physics there exist many different kind of product
symbols for vector products, namely

∙ dot product U+2219
× cross product U+2A2F
∧ wedge product U+2227
⊗ tensor product U+2297

suppose I could overload this generic wildcard operator giving it one of
the symbols above.
Wouldn't be nice writing something like:


[return type] wildcard_operator(wchar_t op_symbol, Vector a, Vector, b)
{
// operator implementation
}

and use it usually:

Vector v = a ∧ b;


instead of the traditional explicit call:

Vector v = a.wedge_product(b);

??

Thank you,
alessandro

[Jorgen Grahn]

It was proposed back in the 1980s, and Stroustrup describes in his
"Design and Evolution of C++" book (11.6.2) why it was rejected.
I can't summarize it ... one problem was giving associativity and
precendence for such operators.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Sam]

alelvb writes:

> Hello groupers,
> I have a curiosity I'd like to be answered.
>
> wouldn't it be great if C++ could give to the programmer the disposal
> of wildcard operator such that it could be substituted by any user
> (oportunaly) defined character symbol?
>
> for example in physics there exist many different kind of product symbols
> for vector products, namely
>
> ∙ dot product U+2219
> × cross product U+2A2F
> ∧ wedge product U+2227
> ⊗ tensor product U+2297
>
> suppose I could overload this generic wildcard operator giving it one of the
> symbols above.
> Wouldn't be nice writing something like:
>
>
> [return type] wildcard_operator(wchar_t op_symbol, Vector a, Vector, b)
> {
> // operator implementation
> }
>
> and use it usually:
>
> Vector v = a ∧ b;

This look very similar to ^, which is perfectly overloadable:

class Foo{};

Foo operator^(const Foo &, const Foo &)
{
return Foo{};
}

And then write

Foo a = b ^ c;

For the dot and cross product you can overload + and *, and so on.

That's as much as you can do, within the existing boundaries of C++.

[Paavo Helde]

On 22.03.2020 21:38, alelvb wrote:
> Hello groupers,
> I have a curiosity I'd like to be answered.
>
> wouldn't it be great if C++ could give to the programmer the disposal
> of wildcard operator such that it could be substituted by any user
> (oportunaly) defined character symbol?
>
> for example in physics there exist many different kind of product
> symbols for vector products, namely
>
> ∙ dot product U+2219
> × cross product U+2A2F
> ∧ wedge product U+2227
> ⊗ tensor product U+2297
>
> suppose I could overload this generic wildcard operator giving it one of
> the symbols above.
> Wouldn't be nice writing something like:
>
>
> [return type] wildcard_operator(wchar_t op_symbol, Vector a, Vector, b)

Why not just operator⊗()?

And yes, maybe in 50 years, when Unicode has become universally adopted,
this thing could be standardized (the 25-30 years so far have shown
mixed results). Too bad all the code will be generated by AI bots by
that time...

[Melzzzzz]

On 2020-03-22, Paavo Helde <myfir...@osa.pri.ee> wrote:
> mixed results). Too bad all the code will be generated by AI bots by
> that time...

Nope, on current computers, impossible. Unless someone figures out how brain works by then.

>
>


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[alelvb]

Il 22/03/20 21:36, Jorgen Grahn ha scritto:

> It was proposed back in the 1980s, and Stroustrup describes in his
> "Design and Evolution of C++" book (11.6.2) why it was rejected.
> I can't summarize it ... one problem was giving associativity and
> precendence for such operators.
>
> /Jorgen
>

I see, but it sounded to me as a great boos to the language.
Mr Stroustrup knows his child better than anyone else, so if
He decided not to give it this feature there must have been
serious problems concerned with it.

Thank you for your reply.

alessandro

[alelvb]

Il 22/03/20 22:27, Sam ha scritto:

> This look very similar to ^, which is perfectly overloadable:
>
> class Foo{};
>
> Foo operator^(const Foo &, const Foo &)
> {
>     return Foo{};
> }
>
> And then write
>
> Foo a = b ^ c;
>
> For the dot and cross product you can overload + and *, and so on.
>
> That's as much as you can do, within the existing boundaries of C++.
>

In this specific case you are right, but in other cases there is not a
correlation between standard C++ operators and the symbols required.

thank you for your reply,

alessandro

[alelvb]

Il 22/03/20 23:00, Paavo Helde ha scritto:

> Why not just operator⊗()?
>
> And yes, maybe in 50 years, when Unicode has become universally adopted,
> this thing could be standardized (the 25-30 years so far have shown
> mixed results). Too bad all the code will be generated by AI bots by
> that time...

I didn't imagine that this expression could be used with the
hypothetical user defined symbol.
I'm just a lover of computer programming, self made, but with few
technical knowledge; but I like to spend my spare time playing with a
compiler and a text editor (or with an IDE that helps with the debuging).

[James Kuyper]

Stroustrup is not perfect, and I'm sure he'd be the first to admit it.
He didn't think of everything the first time around - many aspects of
how C++ does and should work did not become clear until long after a
large number of people started using it. Especially after C++ became
standardized, many problems with C++ have been detected and solved by
people other than him. Therefore, don't read too much into the fact that
he didn't provide a given feature. "Design and Evolution of C++" gives a
very detailed explanation of it's title subject, and is much more
authoritative than any guesses you might make based upon simply noticing
the absence of a feature.

[cda...@gmail.com]

This wouldn't work because the tensor product works on the vector components and not the vector themselves. Remember, vectors are invariant under a change of basis.

[alelvb]

Il 23/03/20 14:16, cda...@gmail.com ha scritto:

I'm sorry; what I wanted to do was just to illustrate my idea,
maybe the wedge product of two vectors is not a vector as I wrote.

what I'm sure it is correct is:

double dp = a ∙ b; // dot product

I hope that regardless to my mistake and ignorance, it was clear what I
meant.

[alelvb]

Il 23/03/20 14:06, James Kuyper ha scritto:

OK, clear.

But do you think my idea is so absurd?
Do you think that it would be (if one day this feature is added to the
language) unseful?

[James Kuyper]

Unless and until the C++ standard is modified to mandate support for
unicode source files (the supported unicode encodings could still be
implementation-defined), your idea isn't even feasible. If such a change
did ever occur, your proposal would become feasible, but I'm not sure it
would be a good idea. Your proposal would make C++ an even more
confusing language to read than it currently is.

[David Brown]

One thing that can be done today, and doesn't involve hard-to-type,
hard-to-read unicode symbols, is a syntax like:

v1 = a *wedge* b;
v2 = a *dot* b;

[Öö Tiib]

Using / it looks passable. Unfortunately it involves some
bloat code, tools are somewhat confused, it may stop some
optimizations of compiler and diagnostics on case of typo in
expression can be also quite confusing. So wedge(a, b),
dot(a, b), a.wedge(b) and/or a.dot(b) keep being the winners
today.

[David Brown]

I'd stick to * for multiplication, since these are multiplication
operations. It might not make sense to have the same name for different
operations in this case, but it could do for other types - for
arithmetic types you might have *sat*, +sat+, -sat- for saturating
operations.

> Unfortunately it involves some
> bloat code, tools are somewhat confused, it may stop some
> optimizations of compiler and diagnostics on case of typo in
> expression can be also quite confusing. So wedge(a, b),
> dot(a, b), a.wedge(b) and/or a.dot(b) keep being the winners
> today.
>

I am not saying this is the best way to express the OP's requirements -
I am saying it is an option to consider. If he has more complex
expressions, then an infix operator can make things a lot easier.
That's a judgement we must leave up to the OP.

Compilers and other tools should not be confused here - it's just
classes and friend functions. You do need to define an extra helper
class, but it's worth a little bloat in the definition if you find the
results neater.

[Öö Tiib]

Compilers and other tools are software and the software often does not
understand what kooky intentions the humans have. Some code editors
for example "helpfully" format it like a * wedge * b when copy-pasting
it.

[Bonita Montero]

There are good reasons why operator overloading is used very sparsely.
To add to that, that code would only become more incomprehensible would
be stupid.

[alelvb]

Il 23/03/20 16:38, James Kuyper ha scritto:

I do think that if one is confused by the code, that happens because
he or she doesn't have the same mastering on the subject than the
author of that code. Take me, for example.
I asked some time ago for an help here in the newsgroup
to solve a problem related with a chemical formula parser.

Well I tried to read the code sent me in a message but I have not still
come out of the darkness...
That code is full of things I don't know (but it solved at half my problem).
Anyway, it doesn't use any operator overloading nor tricky symbols, and
it is still obscure. So you are only partly right.

The problem with my idea was the choice of the unicode symbols?

What you write about the Unicode supporting is noteworthy.
I use only ASCII characters because I have not well understood how
to handle unicode char literals or strings.

If an operator can be overloaded, it could save some typing
without adding more complexity and it could improve readability.

In my example with Vectors, writing:

Vector v1 {1, 0, 3},
v2 {2, 1, -1};

double dp = v1 * v2;

it highlights that in some way I'm performing some operation on the
vectors related to the multiplication.

If I write instead:

double dp = v1.dot(v2);

you should go to read the dot function code to guess the same
information. Of course, to be more clear, I could have written

double dp = v1.dotProduct(v2);

but I had typed +10 characters instead of simply 1.
If operator overloading would be harmful it would have been banned from
the language or it could had not even been added like happens in other
OO languages.

One could argument that the same symbol could be used with different
kinds of operands and so overloaded multiple times, leading to
confusion, but if the code is at hand that argumentation is only provoking.

[Paavo Helde]

On 23.03.2020 23:36, alelvb wrote:
> The problem with my idea was the choice of the unicode symbols?

Yep.

> What you write about the Unicode supporting is noteworthy.
> I use only ASCII characters because I have not well understood how
> to handle unicode char literals or strings.

Well, your initial proposal was containing Unicode symbols:

> Wouldn't be nice writing something like:

> [...]

> and use it usually:
>
> Vector v = a ∧ b;

The '∧' in the above line is U+2227, very much Unicode, despite the fact
that it looks much like the ASCII '^' (the obfuscated C++ contest people
would rejoice!)

[Mr Flibble]

The reason why we restrict the language symbols to ASCII is quite simple: most of us have keyboards that only have ASCII symbol keys. Now stop being a lemon.

/Flibble

--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin

“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who doesn’t believe in any God the most. Oh, no..wait.. that never happens.” – Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."

[David Brown]

On 23/03/2020 23:27, Mr Flibble wrote:
> On 23/03/2020 22:20, Paavo Helde wrote:
>> On 23.03.2020 23:36, alelvb wrote:
>>> The problem with my idea was the choice of the unicode symbols?
>>
>> Yep.
>>
>>> What you write about the Unicode supporting is noteworthy.
>>> I use only ASCII characters because I have not well understood how
>>> to handle unicode char literals or strings.
>>
>> Well, your initial proposal was containing Unicode symbols:
>>
>>  > Wouldn't be nice writing something like:
>>  > [...]
>>  > and use it usually:
>>  >
>>  > Vector v = a ∧ b;
>>
>> The '∧' in the above line is U+2227, very much Unicode, despite the
>> fact that it looks much like the ASCII '^' (the obfuscated C++ contest
>> people would rejoice!)
>
> The reason why we restrict the language symbols to ASCII is quite
> simple: most of us have keyboards that only have ASCII symbol keys. Now
> stop being a lemon.
>

Not quite - most of us have keyboards with different symbols, where
ASCII symbols form the common subset. I am confident that I have more
non-ASCII symbols than you (for Norwegian letters), but I expect you
have § ¤ £ € at the very least. Those are common enough and
distinguishable enough that they could reasonably be allowed in a
programming language. They are also supported in many 8-bit code pages
(and therefore in most fonts).

Beyond that, it's hard to get an agreement. *nix users typically have
easy access to a fair number of extra letters and symbols, but it would
be silly to write code that is hard work with on Windows.

[Ian Collins]

Not on a "standard" US keyboard you don't! I get fed up copy and
pasting £ when chatting to friends back home!

--
Ian.

[alelvb]

Il 23/03/20 23:20, Paavo Helde ha scritto:

> On 23.03.2020 23:36, alelvb wrote:
>> The problem with my idea was the choice of the unicode symbols?
>
> Yep.
>
>> What you write about the Unicode supporting is noteworthy.
>> I use only ASCII characters because I have not well understood how
>> to handle unicode char literals or strings.
>
> Well, your initial proposal was containing Unicode symbols:
>
> > Wouldn't be nice writing something like:
> > [...]
> > and use it usually:
> >
> > Vector v = a ∧ b;
>

Mine was just a proposal to know what do you all (here on the newsgroup)
do think about it.

I had that idea and I wanted to know how expert people like you
would have taken it as a point for reflection.

Thank you,

alessandro

[Melzzzzz]

On 2020-03-24, David Brown <david...@hesbynett.no> wrote:
> On 23/03/2020 23:27, Mr Flibble wrote:
>> On 23/03/2020 22:20, Paavo Helde wrote:
>>> On 23.03.2020 23:36, alelvb wrote:
>>>> The problem with my idea was the choice of the unicode symbols?
>>>
>>> Yep.
>>>
>>>> What you write about the Unicode supporting is noteworthy.
>>>> I use only ASCII characters because I have not well understood how
>>>> to handle unicode char literals or strings.
>>>
>>> Well, your initial proposal was containing Unicode symbols:
>>>
>>>  > Wouldn't be nice writing something like:
>>>  > [...]
>>>  > and use it usually:
>>>  >
>>>  > Vector v = a ∧ b;
>>>
>>> The '∧' in the above line is U+2227, very much Unicode, despite the
>>> fact that it looks much like the ASCII '^' (the obfuscated C++ contest
>>> people would rejoice!)
>>
>> The reason why we restrict the language symbols to ASCII is quite
>> simple: most of us have keyboards that only have ASCII symbol keys. Now
>> stop being a lemon.
>>
>
> Not quite - most of us have keyboards with different symbols, where
> ASCII symbols form the common subset. I am confident that I have more
> non-ASCII symbols than you (for Norwegian letters), but I expect you
> have § ¤ £ € at the very least.

I don't have them. US ASCII keyboard...

[David Brown]

You don't even have § and ¤ ? (I don't think £ or € would make
particularly nice symbols anyway.)

[James Kuyper]

On 3/24/20 4:44 AM, David Brown wrote:
...

> Not quite - most of us have keyboards with different symbols, where
> ASCII symbols form the common subset. I am confident that I have more
> non-ASCII symbols than you (for Norwegian letters), but I expect you
> have § ¤ £ € at the very least.

My keyboard has the following keys:

`1234567890-=
qwertyuiop[]\
asdfghjkl;'
zxcvbnm,./

And this is what I get with the shift key:

~!@#$%^&*()_+
QWEWRTYUIOP{}|
ASDFGHJKL:"
ZXCVBNM<>?

If your keyboard has the four characters you mentioned, then unless your
keyboard has more keys than mine, it probably doesn't have all of the
characters I've listed.

[Paavo Helde]

My US-ASCII keyboard has also AltGr key, which I can easily use to
generate:

¡²³¤€¼½¾‘’¥×äåé®þüúíóö«»¬ø¶´æ©ñµç¿

[alelvb]

Il 24/03/20 13:09, David Brown ha scritto:

I think that the problem is not if a keyboard has the sign or symbol on
it, but how can I get it.

I use Linux with a keyboard layout set to "no dead keys" that includes
a lot o signs pressing a key together with ALT, CTRL, SHIFT or a
combination of them.

Anway both Windows and Linux have a character palette application from
which it is possible to pick "special" characters.

Possibilities to break the tradition are widespread nowadays.

Thank you,

alessandro

[David Brown]

I have all of these, but I have alt-gr instead of shift to make a few of
them.

I have:

|1234567890+\
qwertyuiopå¨
asdfghjkløæ'
<zxcvbnm,.-

then with shift:

§!"#¤%&/()=?`
QWERTYUIOPÅ^
ASDFGHJKLØÆ*
>ZXCVBNM;:_

then with alt+gr (right-hand alt):

¦¡@£$½¥{[]}±´
@ł€®þ←↓→œπ"~
ªßðđŋħ ĸł'^˝
½«»©“”nµ¸…–

then with shift alt+gr:

¶¹²³¼‰⅝÷«»°¿¬
ΩŁ¢™Þ¥↑ıŒΠ°ˇ
º§ÐªŊĦ̛&Ł˝ˇ×
<>©‘’Nº˛·—

On Windows, you don't get all of these alt-gr keys. You do get:

@£$[]{}€'~

Some of the keys are "dead keys", for accents - it's easy to type éñöç
and the like.

And with Linux compose key, all sorts of new symbols are possible, such
as ÷±⅔₂™œ


I thought even US keyboards had § and ¤. I guess you are more limited
than I thought.

[James Kuyper]

On Tuesday, March 24, 2020 at 10:22:39 AM UTC-4, David Brown wrote:
...

> And with Linux compose key, all sorts of new symbols are possible, such
> as ÷±⅔₂™œ

I posted my message from a Linux system, so I should be able to do that
- but I was unaware of that capability, I've checked online for a
description of that feature - it seems that my compose key should be
shift-right Alt, but I couldn't get that to work as described. It says
that "compose-key ~ a" should produce an a with an umlaut over it. When
I type "shift right-alt ~" it brings up a selector from which I can
choose which of the currently open windows to switch to.

[Melzzzzz]

Nope, I don't. Perhaps if I bought Serbian keyboard I would, but I
bought US ASCII as I am used to.

[Ralf Goertz]

Am Tue, 24 Mar 2020 08:25:27 -0700 (PDT)
schrieb James Kuyper <james...@alumni.caltech.edu>:

Hm here "shift right-alt ~" results in ¯. If you use kde there is an
input device section in systemsettings5. Under Advanced you can specify
which should be the compose key. It's probably best to do it there
instead of globally which might be what the online description refered
to. If (under layouts) you add a map then you can also use the preview
to look at what you have. I guess that gnome has a similar program.

[Keith Thompson]

Ian Collins <ian-...@hotmail.com> writes:
> On 24/03/2020 21:44, David Brown wrote:

[...]

>> Not quite - most of us have keyboards with different symbols, where
>> ASCII symbols form the common subset. I am confident that I have more
>> non-ASCII symbols than you (for Norwegian letters), but I expect you
>> have § ¤ £ € at the very least. Those are common enough and
>> distinguishable enough that they could reasonably be allowed in a
>> programming language. They are also supported in many 8-bit code pages
>> (and therefore in most fonts).
>
> Not on a "standard" US keyboard you don't! I get fed up copy and
> pasting £ when chatting to friends back home!

Indeed. A typical US computer keyboard has exactly zero non-ASCII
printable characters. (Remember that the 'A' in "ASCII" stands for
"American".) There are generally ways to enter non-ASCII characters,
but they vary with the operating system and application. Typing a £
symbol, for example is at least an order of magnitude more difficult
than typing a # symbol (unless you can copy-and-paste it).

It's often possible to configure other layouts, but the keycap symbols
are still strictly ASCII.

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> I have all of these, but I have alt-gr instead of shift to make a few
> of them.

I have an "Alt Gr" key on my keyboard (Windows laptop), but it doesn't
appear to do anything useful. There might be a way to make it work, but
I'm not sufficiently motivated at the moment to look into it.

The problem, I think, is either that there's no standard for entering
characters that don't appear directly on the keyboard, or there are far
too many standards.

[...]

> I thought even US keyboards had § and ¤. I guess you are more limited
> than I thought.

I suggest doing an image search for US keyboard layouts.

[Paavo Helde]

On 24.03.2020 11:00, Ian Collins wrote:
>
> Not on a "standard" US keyboard you don't! I get fed up copy and
> pasting £ when chatting to friends back home!

If you have a desktop keyboard with numeric keypad on the right, then in
Windows one should be able to enter £ with Alt-0163. Not sure how
universal this is.

Recently I was surprised I still have alt keycodes for öäü in my muscle
memory from 30 years back, and they still worked!

[David Brown]

The compose key is not normally enabled by default on Linux systems
(AFAIK). I remember keyboards from Sun Stations at university having a
dedicated compose key, but there isn't one on normal PC-style keyboards.

So you configure it in your keyboard settings for your desktop, with a
wide choice of keys. I always make it the "Scroll Lock" key, since that
is perhaps the most unused I have.

[David Brown]

On 24/03/2020 21:41, Keith Thompson wrote:
> David Brown <david...@hesbynett.no> writes:
> [...]
>> I have all of these, but I have alt-gr instead of shift to make a few
>> of them.
>
> I have an "Alt Gr" key on my keyboard (Windows laptop), but it doesn't
> appear to do anything useful. There might be a way to make it work, but
> I'm not sufficiently motivated at the moment to look into it.

I think, but am not sure, that it is usually considered the same as Alt
on keyboard layouts which don't have a third symbol on keys. (For
example, my "7" key has "/" with shift and "{" with alt-gr, all marked
on the keyboard.)

On Linux systems you have multiple choices of layouts as well as the
default. So for US keyboards, as well as the standard "English (US)" I
see "US, alternative international", "US, international with dead keys",
"US, with euro on 5". I'm guessing that for some of these, alt-gr would
give access to more symbols. Then there are a range of other options
you can set if you want.

It is, as you say, a matter of motivation. If you need extra letters or
symbols on a regular basis, the support is there. Clearly, people who
regularly use a significantly different language will generally use
alternative keyboard layouts. But I find that there are a few symbols
and letters that turn up in my common usage, in addition to the obvious
need for Norwegian letters when I write in Norwegian. I like to be able
to write "100 µF capacitor", "I²C bus", and spell naïve properly.

>
> The problem, I think, is either that there's no standard for entering
> characters that don't appear directly on the keyboard, or there are far
> too many standards.

The compose key is perhaps the nearest that exists to a standard, having
existed for at least 30 years, but it is not enabled by default on Linux
systems (IME) and is not supported at all on Windows. So no, not much
of a standard!

>
> [...]
>> I thought even US keyboards had § and ¤. I guess you are more limited
>> than I thought.
>
> I suggest doing an image search for US keyboard layouts.
>

No need, now! (I should perhaps have done so earlier.)

[Keith Thompson]

David Brown <david...@hesbynett.no> writes:
[...]

> On Linux systems you have multiple choices of layouts as well as the
> default. So for US keyboards, as well as the standard "English (US)"
> I see "US, alternative international", "US, international with dead
> keys", "US, with euro on 5". I'm guessing that for some of these,
> alt-gr would give access to more symbols. Then there are a range of
> other options you can set if you want.

[...]

I just now noticed that my keyboard has a Euro symbol on the 5 key,
to the right of the 5. (The key above R and T, not the one on the
numeric keypad). In a few minutes of searching, I haven't found
a way to get it to send an actual Euro symbol.

€ (don't ask what I had to do to get that symbol).

The point, I suppose, is that support for non-ASCII characters on
US keyboards is so poor that any change to C++ that requires entry
of such characters is going to be a non-starter for the foreseeable
future. I can *display* a lot of Unicode characters with no problem
(which wasn't always the case), but entering them is a lot harder.

[alelvb]

Il 23/03/20 16:52, David Brown ha scritto:

> On 22/03/2020 20:38, alelvb wrote:
>> Hello groupers,
>> I have a curiosity I'd like to be answered.
>>
>> wouldn't it be great if C++ could give to the programmer the disposal
>> of wildcard operator such that it could be substituted by any user
>> (oportunaly) defined character symbol?
>>
>> for example in physics there exist many different kind of product
>> symbols for vector products, namely
>>
>> ∙   dot product      U+2219
>> ×   cross product    U+2A2F
>> ∧   wedge product    U+2227
>> ⊗   tensor product   U+2297
>>
>> suppose I could overload this generic wildcard operator giving it one
>> of the symbols above.

>> Wouldn't be nice writing something like:
>>
>>

>> [return type] wildcard_operator(wchar_t op_symbol, Vector a, Vector, b)
>> {
>>      // operator implementation
>> }
>>

>> and use it usually:
>>
>> Vector v = a ∧ b;
>>
>>

>> instead of the traditional explicit call:
>>
>> Vector v = a.wedge_product(b);
>>
>
> One thing that can be done today, and doesn't involve hard-to-type,
> hard-to-read unicode symbols, is a syntax like:
>
>     v1 = a *wedge* b;
>     v2 = a *dot* b;

Is this a particular use of macro substitution? How can I do that?

thank you,

alessandro

[Christian Gollwitzer]

Am 27.03.20 um 14:51 schrieb alelvb:

>> One thing that can be done today, and doesn't involve hard-to-type,
>> hard-to-read unicode symbols, is a syntax like:
>>
>>      v1 = a *wedge* b;
>>      v2 = a *dot* b;
>
> Is this a particular use of macro substitution? How can I do that?

It's an optical trick. It is just a multiplication by three objects, a
times wedge times b. If you define "wedge" as an instance of a suitable
object, and overload the multiplication operator on it, you can get this
to compile to your wedge product.

Christian

[David Brown]

Here is a simple example, with a "Vect" of three doubles and an
imaginary operation "*wedge*" that takes two Vects and returns a new
Vect. The details of the operation don't matter - that's your job!

First, a simple class and operation with traditional function-like
syntax for using the operation:

class Vect {
private :
double vs_[3];
friend Vect wedge_product(const Vect &a, const Vect &b);
};

Vect wedge_product(const Vect &a, const Vect &b);

Vect test1(const Vect &a, const Vect &b, const Vect &c) {
Vect ab = wedge_product(a, b);
Vect abc = wedge_product(ab, c);
return abc;
}

Then we make a class for the "wedge" object. This has no data or
operations in itself - it exists just to provide overloads to the *
operator, and to hold an intermediary proxy class Wedge::ProductHelper.
This class holds a reference to a Vect and exists to provide another
overload to the * operator, this time passing its reference and the
other operand on to the real wedge_product function:

class Wedge {
class ProductHelper {
public:
const Vect& v_;
ProductHelper(const Vect& v) : v_(v) {}
};
friend Vect operator*(Wedge::ProductHelper w, const Vect& a);
friend Wedge::ProductHelper operator*(const Vect& a, Wedge);
};
const Wedge wedge;


inline Vect operator*(Wedge::ProductHelper w, const Vect& a) {
return wedge_product(a, w.v_);
}
inline Wedge::ProductHelper operator*(const Vect &a, Wedge) {
return Wedge::ProductHelper(a);
}


Now we can use the code like this:

Vect test2(const Vect &a, const Vect &b, const Vect &c) {
return a *wedge* b *wedge* c;
}


As far as the language is concerned, this is handled by taking "a" and
the "wedge" object and applying operator *, giving a
Wedge::ProductHelper that holds "a". This is is then used as a parameter
to another operator * along with b, and that overload leads to a call of
the real function wedge_product, returning a new vector ("ab" from the
first test function). The process is then run again to multiply in "c".


Your challenge now is:

1) Get all the boiler-plate in templates.
2) Make sure everything that can be hidden from public use, is hidden.
3) Turn it all into expression templates for run-time efficiency.