Friday, March 27, 2020

Digest for comp.lang.c++@googlegroups.com - 25 updates in 7 topics

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Mar 26 06:02PM -0700

On 3/26/2020 3:58 AM, David Brown wrote:
> not required to be in memory - though a compiler is certainly free to
> interpret the fence more generally and use it for ordering result1.
 
> Making result1 volatile /will/ force the desired order.
 
[...]
 
Right. The memory fence can be optimized away because it has no other
atomic operations to synchronize with. There needs to be a
std::atomic<T> around somewhere to sync with.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 27 12:21AM -0400

On 3/26/20 5:42 PM, David Brown wrote:
...
> C and C++ have always had the "as if" rule and the concept of observable
> behaviour - and time is not observable. Any re-arrangements that don't
> affect the observable behaviour are allowed.
 
C has had the "least requirements" clause ever since it was first
standardized - but the term "observable behavior" wasn't used in
connection with those requirements until C2011. The actual requirements
imposed by C were essentially the same as those imposed by C++, but C++
defined a convenient term for discussing those requirements, while C
didn't. The C++ standard remains much clearer than the C standard with
respect to the role that observable behavior plays in judging the
conformance of an implementation.
 
I've lost my copies of the oldest versions of the C++ standard, but as I
remember it, it has defined the term "observable behavior" ever since it
was first standardized - but early versions of the standard had a
different definition of that term than current ones.
 
The oldest draft of the standard that I have is n2723.pdf (2008?). It
says "The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O functions."
The "least requirements" clause was not connected to the term
"observable behavior" in that version.
The next oldest draft version I have is n3035.pdf (2010?). In that
version, the connection between the "least requirements" and "observable
behavior" is essentially the same as in the current standard.
"Öö Tiib" <ootiib@hot.ee>: Mar 27 01:03AM -0700

On Thursday, 26 March 2020 23:57:59 UTC+2, David Brown wrote:
 
> > Unless they *deprecate* and *break* the volatile as they seemingly
> > plan to.
 
> Did you read the paper linked (P1152r4) ?
 
Yes, like I did read the paper where they deprecated constexpr detection
compile time. It is typical programmer does not know what programmer is
doing lie following with taking away the essential tool.
 
> which doesn't exist. This removes a significant foot-gun and removes
> unintuitive corner cases from the languages.
> """
 
Basically it is saying that C++17 library was implemented
volatile-incorrect in implementations and so lets remove volatile
as fix. Lets take away the possibility that someone may have something
implemented volatile-correctly at all.
 
 
> Did you look at the votes? The solid majority of the working groups
> were in favour. Do you think they /all/ forgot that people use C++ in
> embedded programming?
 
Popular votes in this world have left me always indifferent. And those
are votes of wormtongues counted. They certainly *know* that now
embedded programming in C++ is double tedious if not impossible.
 
> Can you give an example of a use of volatile that you think is good,
> solid programming practice in pre-C++20 but is not deprecated? At
> worst, you have to write "x = x + 1;" instead of "x++;".
 
Basically I read it that instead of member functions of volatile unions
I now have to use inline assembler again since it will be more readable
than C++, even if it is somehow possible to write in C++ at all (should
invest tens of man-days into research). And with next standard they most
likely break even that "somehow".
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 27 09:47AM +0100

On 27.03.2020 05:21, James Kuyper wrote:
> remember it, it has defined the term "observable behavior" ever since it
> was first standardized - but early versions of the standard had a
> different definition of that term than current ones.
 
C++98 §1.9/6:
 
"The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O functions"
 
C++17 §4.6/7 (via final draft N4659):
 
"The least requirements on a conforming implementation are:
— Accesses through volatile glvalues are evaluated strictly according to
the rules of the abstract machine.
— At program termination, all data written into files shall be identical
to one of the possible results that execution of the program according
to the abstract semantics would have produced.
— The input and output dynamics of interactive devices shall take place
in such a fashion that prompting output is actually delivered before a
program waits for input. What constitutes an interactive device is
implementation-defined.
These collectively are referred to as the /observable behavior/ of the
program"
 
 
> The next oldest draft version I have is n3035.pdf (2010?). In that
> version, the connection between the "least requirements" and "observable
> behavior" is essentially the same as in the current standard.
 
- Alf
David Brown <david.brown@hesbynett.no>: Mar 27 12:22PM +0100

On 27/03/2020 09:03, Öö Tiib wrote:
 
>> Did you read the paper linked (P1152r4) ?
 
> Yes, like I did read the paper where they deprecated constexpr detection
> compile time.
 
That must be a different paper. I could not find a reference to
anything relevant in a quick search.
 
> It is typical programmer does not know what programmer is
> doing lie following with taking away the essential tool.
 
As I couldn't find a paper on "deprecated constexpr detection", I can't
comment on it. But AFAICS the "deprecate volatile" paper stands on its
own - and should be judged on its own. It makes no sense to me to say
it must be a bad thing to deprecate complex volatile uses just because
you didn't like a paper on deprecating constexpr detection.
 
> volatile-incorrect in implementations and so lets remove volatile
> as fix. Lets take away the possibility that someone may have something
> implemented volatile-correctly at all.
 
No one is removing or deprecating volatile.
 
Simple volatile usage is almost invariably compiled correctly, so that
the object code does exactly what the programmer expected. Complex
cases are riddled with compiler bugs, programmer confusion and
misunderstanding, underspecification in the standards, and alternative
implementations that are each arguably correct. The change in C++20 has
nothing to do with the C++17 library - it is nothing more nor less than
an admission that complex volatile usage is ripe with errors,
unnecessary in practice, and thus should be removed from the language.
 
 
> Popular votes in this world have left me always indifferent. And those
> are votes of wormtongues counted. They certainly *know* that now
> embedded programming in C++ is double tedious if not impossible.
 
You really think the C++ standards groups are /deliberately/ and
/knowingly/ sabotaging the language for its use in low-level
programming? That is real tin-foil hat stuff.
 
> than C++, even if it is somehow possible to write in C++ at all (should
> invest tens of man-days into research). And with next standard they most
> likely break even that "somehow".
 
All you have to do is make sure your volatile accesses are simple and
explicit.
 
If you think your current code is deprecated by the new standard, please
show a small example. If I am wrong here, I would like to know about it!
"Öö Tiib" <ootiib@hot.ee>: Mar 27 07:58AM -0700

On Friday, 27 March 2020 13:22:19 UTC+2, David Brown wrote:
> own - and should be judged on its own. It makes no sense to me to say
> it must be a bad thing to deprecate complex volatile uses just because
> you didn't like a paper on deprecating constexpr detection.
 
Paper is that removal of deprecated legacy exception specifications.
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html>
Basically that:
<https://timsong-cpp.github.io/cppwp/n4140/expr.unary.noexcept>
notice "unless the call is a constant expression"
Was changed to that:
<https://eel.is/c++draft/expr.unary.noexcept>
notice link to [except.spec] that does not anymore say
that constant expressions can not be "potentially throwing".
Typical work of wormtongues.
 
> nothing to do with the C++17 library - it is nothing more nor less than
> an admission that complex volatile usage is ripe with errors,
> unnecessary in practice, and thus should be removed from the language.
 
Yes, and so we should use assembler to write device drivers.
 
 
> You really think the C++ standards groups are /deliberately/ and
> /knowingly/ sabotaging the language for its use in low-level
> programming? That is real tin-foil hat stuff.
 
What else explanation there is? Useless tool is useless tool.
Who made it useless weren't morons, so they made it specially.
 
 
> explicit.
 
> If you think your current code is deprecated by the new standard, please
> show a small example. If I am wrong here, I would like to know about it!
 
Basically I can not imagine how to write any device driver in C++ without
volatile member functions nor operators. Say VGA compatible text mode
driver?
 
Basically we have to use old stinky C macros that reinterpret cast
constant uint values to volatile pointer values on every step and
then do arithmetic with those in large blob functions. Happen to have
whole array of such peripherals? Be explicit and copy paste, no way
to have volatile objects. And perhaps that reinterpret_cast is
undefined behavior as well.
Strong pressure seemed to be to screw up std::atomic as well.
Meanwhile not all implementations have <stdatomic.h> of C yet as it
is C11.
 
Macro assembler or perhaps C (if they do not trash that as well)
remain the viable options.
David Brown <david.brown@hesbynett.no>: Mar 27 04:56PM +0100

On 27/03/2020 15:58, Öö Tiib wrote:
> notice link to [except.spec] that does not anymore say
> that constant expressions can not be "potentially throwing".
> Typical work of wormtongues.
 
This is getting a little out of my depth here, so I hope someone will
chime in if I'm wrong. But how could a constant expression be
potentially throwing? I can't see anything here that has changed except
that the terms have been made a little more general.
 
 
>> an admission that complex volatile usage is ripe with errors,
>> unnecessary in practice, and thus should be removed from the language.
 
> Yes, and so we should use assembler to write device drivers.
 
Do you think that complex, unreliable, under-specified volatile
expressions were needed to write device drivers? I certainly don't.
Low-level coding is my main job (mainly in C, but that makes no
difference here). I use "volatile" regularly. There is nothing in the
changes to volatile in C++20 that I dislike or that would cause any
hardship in my coding.
 
> is C11.
 
> Macro assembler or perhaps C (if they do not trash that as well)
> remain the viable options.
 
I am seeing a great deal of anger and fear here, and very little
rational thought or explanation. That is not like you. I am still
waiting for concrete examples - not another claim about how this will
make low-level programming impossible, but a simple real example.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 27 09:53AM -0700

On Friday, March 27, 2020 at 10:58:56 AM UTC-4, Öö Tiib wrote:
> On Friday, 27 March 2020 13:22:19 UTC+2, David Brown wrote:
> > On 27/03/2020 09:03, Öö Tiib wrote:
...
> > you didn't like a paper on deprecating constexpr detection.
 
> Paper is that removal of deprecated legacy exception specifications.
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html>
 
What does that have to do with "deprecating constexpr detection [at]
compile time"? There are seven occurrences of "constexpr" in that paper
- none of them involve making it deprecated. Also, what connection do
you see between this paper and "volatile". There's only one occurrence
of "volatile" in that paper, and it doesn't seem to have anything to do
with what you're complaining about.
 
> <https://eel.is/c++draft/expr.unary.noexcept>
> notice link to [except.spec] that does not anymore say
> that constant expressions can not be "potentially throwing".
 
As david said, how could something that meets the requirements to be
described as a "constant expression" be also "potentially throwing"?
 
> Typical work of wormtongues.
 
Removing redundant specification is the "work of wormtongues"? In that
case, maybe we need more of them on the committee.
 
...
> > an admission that complex volatile usage is ripe with errors,
> > unnecessary in practice, and thus should be removed from the language.
 
> Yes, and so we should use assembler to write device drivers.
 
Can you give a specific example of code that used to be permitted, which
will now be deprecated,as a result of which we'll be forced to use
assembler instead?
 
...
> > > Popular votes in this world have left me always indifferent. And those
 
Keep in mind that this isn't a simple popularity contest. These are
votes of experts serving on the C++ committee. These are people who
either implement C++ or use it (roughly equal numbers of each); either
way, they are sufficiently interested in C++ to volunteer to spend
their free time (unpaid) to work to make it better. Why would such want
to destroy C++? They might destroy it unintentionally, but why would
they do it deliberately, as you claim?
 
...
> > programming? That is real tin-foil hat stuff.
 
> What else explanation there is? Useless tool is useless tool.
> Who made it useless weren't morons, so they made it specially.
 
One alternative explanation is that you do as bad a job of reading
English as you do of writing it (which seems quite plausible), and as a
result you've misunderstood something about the paper you're complaining
about, that made you incorrectly think a useful tool was actually
useless. If you could provide a simple example of code that you think
would become deprecated if that paper is approved, that would go a long
way toward figuring out what you've misunderstood (if you're wrong), or
what we've misunderstood (if you're right).
 
...
> > show a small example. If I am wrong here, I would like to know about it!
 
> Basically I can not imagine how to write any device driver in C++ without
> volatile member functions nor operators. Say VGA compatible text mode
 
Please give a specific example of a volatile member function or operator
that you think is deprecated by that paper.
 
...
> Basically we have to use old stinky C macros that reinterpret cast
> constant uint values to volatile pointer values on every step and
> then do arithmetic with those in large blob functions.
 
Please provide an example of currently permitted C++ code that would
have to be replaced by such C macros if that paper is approved.
 
Note: if you do provide an example, I expect the immediate response will
be "Why in the world do you think such code will be deprecated by that
paper?". Therefore, it would save everyone some time if you would
accompany each example with a citation of the specific words from that
paper which left you with the impression that it would deprecate that
example.
"Öö Tiib" <ootiib@hot.ee>: Mar 27 09:59AM -0700

On Friday, 27 March 2020 17:56:48 UTC+2, David Brown wrote:
> chime in if I'm wrong. But how could a constant expression be
> potentially throwing? I can't see anything here that has changed except
> that the terms have been made a little more general.
 
Standard does not say anymore that it cannot be potentially throwing so
it can. Look that:
 
#include <iostream>
 
constexpr int foo(int x) {return x;}
 
int main()
{
std::cout << (noexcept(foo(42)) ? "constant expressions can not throw\n"
: "constant expressions may throw\n");
}
 
Demo <http://coliru.stacked-crooked.com/a/7503ebfcc2474e7b>
 
The program does not even say when compiled in -std=c++14 mode anymore
that "constant expressions can not throw" yet it did few versions
of gcc ago.
So these are some rather strong forces behind requirement that constant
expressions *should* be throwing.
 
 
> difference here). I use "volatile" regularly. There is nothing in the
> changes to volatile in C++20 that I dislike or that would cause any
> hardship in my coding.
 
But it is understandable if you do not write device drivers in C++.
You do not consider how C++ features could be used to make those
handier so you perhaps see no difference.
 
> rational thought or explanation. That is not like you. I am still
> waiting for concrete examples - not another claim about how this will
> make low-level programming impossible, but a simple real example.
 
I can't give code since I am not sole owner of it. There are compilers
on what it works like was specified by standards. The ongoing events
however remove point of considering open sourcing such code. So why
should I be happy?
"Öö Tiib" <ootiib@hot.ee>: Mar 27 10:16AM -0700

On Friday, 27 March 2020 18:53:47 UTC+2, James Kuyper wrote:
 
> Removing redundant specification is the "work of wormtongues"? In that
> case, maybe we need more of them on the committee.
 
I replied to David Brown. It is not about debate here who debates better,
call that is a constant expression is noexcept(false) since C++17.
Both gcc and clang have made it so and rejected to repair:
https://bugs.llvm.org/show_bug.cgi?id=15481
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87603
David Brown <david.brown@hesbynett.no>: Mar 27 06:59PM +0100

On 27/03/2020 17:59, Öö Tiib wrote:
> of gcc ago.
> So these are some rather strong forces behind requirement that constant
> expressions *should* be throwing.
 
This is either a mistake in the way it is defined (these things happen -
the C++ standards folks are not infallible), or intentional. If it is
intentional, there will be a reason behind it - perhaps it is because
constexpr functions /can/ throw (when evaluated at run-time), and people
prefer that noexcept() returns consistent values even if that is
pessimistic. Maybe there are other reasons. But I severely doubt that
there is someone sitting in a chair, stroking his cat and saying, "How
shall we cause trouble for people? Especially those that dare to use
C++ for low-level programming? I know, we'll make changes to noexcept()
- that will get them!". (Forgetting, of course, that for a lot of
low-level and embedded work exceptions are disabled.)
 
 
 
 
> But it is understandable if you do not write device drivers in C++.
> You do not consider how C++ features could be used to make those
> handier so you perhaps see no difference.
 
So show me!
 
> on what it works like was specified by standards. The ongoing events
> however remove point of considering open sourcing such code. So why
> should I be happy?
 
I don't want a section of a commercial program. I want a simple, short
example case.
Frederick Gotham <cauldwell.thomas@gmail.com>: Mar 27 02:58AM -0700

On Thursday, March 26, 2020 at 3:50:28 PM UTC, Öö Tiib wrote:
 
> > I thought that the method defined in the base class would be found and called? Do I need to use "using" here in the derived class?
 
> Yes. Or to make all overloads in base class virtual.
> Otherwise hiding takes place.
 
 
I tried making it virtual in the base class but it still fails to compile. I'm using GCC 7.4.0.
 
Try it there on your own compiler.
Bo Persson <bo@bo-persson.se>: Mar 27 11:33AM +0100

On 2020-03-27 at 10:58, Frederick Gotham wrote:
>> Otherwise hiding takes place.
 
> I tried making it virtual in the base class but it still fails to compile. I'm using GCC 7.4.0.
 
> Try it there on your own compiler.
 
Making "it" virtual is not enough. *All* overloads must be present in
the base class, otherwise declarations in an inner scope (derived class)
hide names in outer scopes (base class).
 
This is the same mechanism as for names inside functions and namespaces.
Inner declarations of a name hide all declarations of the same name from
outer scopes.
 
 
Bo Persson
Cholo Lennon <chololennon@hotmail.com>: Mar 27 02:53PM -0300

On 26/3/20 12:48, Öö Tiib wrote:
 
> That bear trap into what everyone must fall is there
> because C++ is designed to *hate* novices.
 
I totally agree with you
 
--
Cholo Lennon
Bs.As.
ARG
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 27 04:09PM +0100

Someone (I don't recall who) in a recent thread complained about US
keyboards lacking e.g. British pound signs.
 
I have a Norwegian keyboard, which lacks Norwegian quote signs, and many
other symbols I use.
 
At first I just copied these symbols from the web, or specified them
numerically. Then I started on a keyboard helper thing in C++, for
Windows. But in the end I just put the most used symbols in a text file,
which I switch to whenever I need a symbol.
 
The text file is not super-convenient, in fact it often conflicts with
other use of the clipboard. But it works. A semi-practical solution.
 
Herewith, the current version:
 
-----------------------------------------------------------------------
«»
"" ❝❞
『』
– — ' •
… ⋯ ⋮ * † ‡
← ↑ → ↓ ↔ ↕ ↖ ↗ ↘ ↙ ◁ ▷ ◂ ◀ ▶ ▸ ⍅ ⍆ ➲
© ® ™ ° ′ ″ µ
− × ⋅ ÷ Σ π √ ≤ ≥ ≈ ∪ ∩ ± ⌈⌉ 𝜋
⇐ ⇔ ⇒ ≡ ¬
☺ ☻ 😃 😒 ⚡
1ˢᵗ, 2ⁿᵈ, 3ʳᵈ, 4ᵗʰ, 6ᵗᵉ
Super xᵃ xᵇ xᶜ xᵈ xᵉ xᶠ xᵍ xʰ xⁱ xʲ xᵏ xˡ xᵐ xⁿ xᵒ xᵖ xʳ xˢ xᵗ xᵘ xᵛ xʷ
xˣ xʸ xᶻ
Super x⁰ x¹ x² x³ x⁴ x⁵ x⁶ x⁷ x⁸ x⁹ x' x⁺ x⁻ x⁼ x⁽ x⁾
Sub x₀ x₁ x₂ x₃ x₄ x₅ x₆ x₇ x₈ x₉ xᵢ
½ ¼ ¾
 
Soft hyphen ­
Non-breakable space [ ]
Non-breakable hyphen [‑]
 
news: 📰
movie: 🎥
music: 🎵
angry: 😠
propaganda: 🐷
idioti: 懵
question: ❓
exclamation: ❗️
 
/‾‾ File ‾‾\
-----------------------------------------------------------------------
 
- Alf (off-topic writer's mode)
David Brown <david.brown@hesbynett.no>: Mar 27 05:42PM +0100

On 27/03/2020 16:09, Alf P. Steinbach wrote:
> Someone (I don't recall who) in a recent thread complained about US
> keyboards lacking e.g. British pound signs.
 
I guess you might mean me - but I wasn't complaining about it, I was
merely surprised that the standard US keyboard layout doesn't have at
least ¤ and §.
 
 
> I have a Norwegian keyboard, which lacks Norwegian quote signs, and many
> other symbols I use.
 
You mean « and » ? They have kind of gone out of fashion in modern
Norwegian, but perhaps that's just laziness of the modern generation
using keyboards without the symbols.
 
> numerically. Then I started on a keyboard helper thing in C++, for
> Windows. But in the end I just put the most used symbols in a text file,
> which I switch to whenever I need a symbol.
 
I recommend switching to Linux. For me, these are AltGr + z and AltGr +
x. Many of the more useful (to me) symbols you have on the list are
available as AltGr combinations, and a fair number of the others are
available with the Compose key.
 
A good word processor will handle quotation marks automatically, as will
LaTeX (with the right setup and packages).
 
A lot of the symbols in your list are only likely to be useful in
documents written with a word processor, LaTeX, HTML, markdown, etc.
 
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 23 05:19AM

> particular HDC (handle to device context), if I recall correctly.
> Depending on how it was created such handle must be destroyed by a
> corresponding function, but the type does not encode that.
 
Problem with win32 API is because it uses DWORD integer and recently,
DWORD_PTR so you must use reinterpret_cast :(
 
--
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 <alelvb@inwind.it>: Mar 27 02:51PM +0100

Il 23/03/20 16:52, David Brown ha scritto:
> 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 <auriocus@gmx.de>: Mar 27 03:47PM +0100

Am 27.03.20 um 14:51 schrieb alelvb:
 
>>      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 <david.brown@hesbynett.no>: Mar 27 03:57PM +0100

On 27/03/2020 14:51, alelvb wrote:
 
> Is this a particular use of macro substitution? How can I do that?
 
> thank you,
 
> alessandro
 
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.
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 22 10:04PM

> 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
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 22 03:11AM

> Is it a good idea to use auto -return value with all class member
> function, or use the return type?
 
No, auto is not good for that. In haskell, one writes
funtion signatures for all functions, only for local
functions signature is not needed. That's just convention
and makes better compiler errors.
 
 
--
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
Melzzzzz <Melzzzzz@zzzzz.com>: Mar 22 04:16AM

> For anything more complex than a trivial getter I would do without auto
> and use some typedefs or aliases to reduce the clutter instead.
 
This.
 
--
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
JiiPee <no@notvalid.com>: Mar 22 08:22PM

Ok so most answers say that better to type the type and not use auto. I
was also thinking that might be better, so I think I ll go with this as
well.
James Kuyper <jameskuyper@alumni.caltech.edu>: Mar 27 12:33AM -0400

On 3/26/20 3:51 PM, Frederick Gotham wrote:
...
> Is there any translation firm which is held in particularly high regard for translating technical papers (e.g. to do with mathematics or computing).
 
This newsgroup has readers all around the world. Do you care which
country(s) the translation firm operates in? If so, you should specify
your preferences.
 
I recommend getting prepared for some sticker shock when looking for a
highly regarded technical translating firm. Such firms tend to charge
correspondingly high prices. In your first message you said "I'm hoping
to purchase a package deal for all 6 languages which won't leave me too
much out of pocket." If your budget is sufficiently small that you're
worrying about such things, you probably can't afford a "highly
regarded" firm - you should set your target a little lower than that.
 
I have no recommendations of my own - the only translator I know
personally could handle your need for a Russian translation, but I've
never actually used her services, so I can't vouch for how good she is.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.

No comments: