Tuesday, October 11, 2016

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

bleachbot <bleachbot@httrack.com>: Oct 11 07:08PM +0200

bleachbot <bleachbot@httrack.com>: Oct 11 07:10PM +0200

bleachbot <bleachbot@httrack.com>: Oct 11 07:19PM +0200

Ramine <ramine@1.1>: Oct 11 01:19PM -0400

Hello..........
 
 
Universal Scalability Law program
 
 
Author: Amine Moulay Ramdane.
 
Email: aminer@videotron.ca
 
 
Description:
 
This program analyzes system performance data with the Universal
Scalability Law.
 
 
You can download it from and read about it from here
 
https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Oct 11 01:10PM -0400

Hello......
 
 
C++ synchronization objects library
 
 
Author: Amine Moulay Ramdane
 
Email: aminer@videotron.ca
 
Description:
 
This library contains 9 synchronization objects, first one is my
scalable SeqlockX that is a variant of Seqlock that eliminates the
weakness of Seqlock that is "livelock"of the readers when there is more
writers, and second is my scalable MLock that is a scalable
lock , and third is my SemaMonitor that combines all characteristics
of a semaphore and an eventcount and also a windows
Manual-reset event and also a windows Auto-reset event, and fourth
is my scalable DRWLock that is a scalable reader-writer lock that is
starvation-free and it does spin-wait, and five is is my scalable
DRWLockX that is a scalable reader-writer lock that is
starvation-free and it doesn't spin-wait, but it waits on the Event
objects and my SemaMonitor, so it is energy efficient, and six one is
my scalable asymmetric DRWLock that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the
reader side, so it look like RCU, and it is fast. This scalable
Asymmetric Distributed Reader-Writer Mutex is FIFO fair on the
writer side and FIFO fair on the reader side and of course it is
starvation-free and it does spin-wait, and seven one is my scalable
asymmetric DRWLockX that doesn't use any atomic operations
and/or StoreLoad style memory barriers on the reader side, so it
look like RCU, and it is fast. This scalable Asymmetric Distributed
Reader-Writer Mutex is FIFO fair on the writer side and FIFO fair on the
reader side and of course it is starvation-free, and it does not
spin-wait, but it waits on Event objects and my SemaMonitor, so it
is energy efficient, and eight is my LW_Asym_RWLockX that is a
lightweight scalable Asymmetric Reader-Writer Mutex that uses a technic
that looks like Seqlock without looping on the reader side
like Seqlock, and this has permited the reader side to be costless,
it is FIFO fair on the writer side and FIFO fair on the reader side and
it is of course Starvation-free and it does spin-wait, and nine is my
Asym_RWLockX, a lightweight scalable Asymmetric Reader-Writer Mutex that
uses a technic that looks like Seqlock without looping
on the reader side like Seqlock, and this has permited the reader
side to be costless, it is FIFO fair on the writer side and FIFO fair on
the reader side and it is of course Starvation-free and it does not
spin-wait, but waits on my SemaMonitor, so it is energy efficient.
 
My scalable Asymmetric Reader-Writer Mutex calls the windows
FlushProcessWriteBuffers() just one time, but my scalable
Asymmetric Distributed Reader-Writer Mutex calls
FlushProcessWriteBuffers() many times.
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
I have implemented my inventions with FreePascal and Delphi compilers
that don't reorder loads and stores even with compiler optimization, and
this is less error prone than C++ that follows a relaxed memory model
when compiled with optimization, so i have finally compiled my
algorithms implementations with FreePascal into Dynamic Link Libraries
that are used by C++ in a form of my C++ Object Synchronization Library.
 
If you take a look at the zip file , you will notice that it contains
the DLLs Object pascal source codes, to compile those dynamic link
libraries source codes you will have to download my SemaMonitor Object
pascal source code and my SeqlockX Object pascal source code and my
scalable MLock Object pascal source code and my scalable DRWLock Object
pascal source code from here:
 
https://sites.google.com/site/aminer68/
 
I have compiled and included the 32 bit and 64 bit windows Dynamic Link
libraries inside the zip file, if you want to compile the dynamic link
libraries for Unix and Linux and OSX on (x86) , please download the
source codes of my SemaMonitor and my scalable SeqlockX and my scalable
MLock and my scalable DRWLock and compile them yourself.
 
My SemaMonitor of my C++ synchronization objects library is
easy to use, it combines all characteristics of a semaphore and an
eventcount and also a windows Manual-reset event and also a windows
Auto-reset event, here is its C++ interface:
 
class SemaMonitor{
SemaMonitor(bool state, long1 InitialCount1=0,long1
MaximumCount1=INFINITE);
~SemaMonitor();
 
void wait(signed long mstime=INFINITE);
void signal();
void signal_all();
void signal(long1 nbr);
void setSignal();
void resetSignal();
long2 WaitersBlocked();
};
 
So when you set the first parameter that is state of the constructor to
true. it will add the characteristic of a Semaphore to the to the
Eventcount, so the signal will not be lost if the threads are not
waiting for the SemaMonitor objects, but when you set the first
parameter of the construtor to false, it will not behave like a
Semaphore because if the threads are not waiting for the SemaCondvar or
SemaMonitor the signal will be lost..
 
the parameters InitialCount1 and MaximumCount1 is the semaphore
InitialCount and MaximumCount.
 
The wait() method is for the threads to wait on the SemaMonitor
object for the signal to be signaled.
 
and the signal() method will signal one time a waiting thread on the
SemaMonitor object.
 
the signal_all() method will signal all the waiting threads on the
SemaMonitor object.
 
the signal(long2 nbr) method will signal nbr number of waiting threads
 
the setSignal() and resetSignal() methods behave like the windows Event
object's methods that are setEvent() and resetEvent().
 
and WaitersBlocked() will return the number of waiting threads on
the SemaMonitor object.
 
As you have noticed my SemaMonitor is a powerful synchronization object.
 
Please read the readme files inside the zip file to know more about them..
 
Here is my new invention that is my new algorithm:
 
I have invented a new algorithm of my scalable Asymmetric Distributed
Reader-Writer Mutex, and this one is costless on the reader side, this
one doesn't use any atomic operations and/or StoreLoad style memory
barriers on the reader side, my new algorithm has
added a technic that looks like Seqlock, but this technic doesn't
loop as Seqlock. Here is my algorithm:
 
On the reader side we have this:
 
--
procedure TRWLOCK.RLock(var myid:integer);
 
var myid1:integer;
id:long;
begin
 
 
myid1:=0;
id:=FCount5^.fcount5;
if (id mod 2)=0
then FCount1^[myid1].fcount1:=1
else FCount1^[myid1].fcount1:=2;
if ((FCount3^.fcount3=0) and (id=FCount5^.fcount5) and
(FCount1^[myid1].fcount1=1))
then
else
begin
LockedExchangeAdd(nbr^.nbr,1);
if FCount1^[myid1].fcount1=2
then LockedExchangeAdd(FCount1^[myid1].fcount1,-2)
else if FCount1^[myid1].fcount1=1
then LockedExchangeAdd(FCount1^[myid1].fcount1,-1);
event2.wait;
LockedExchangeAdd(FCount1^[myid1].fcount1,1);
LockedExchangeAdd(nbr^.nbr,-1);
end;
end;
--
 
The writer side will increment FCount5^.fcount5 like does
a Seqlock, and the reader side will grap a copy of FCount5^.fcount5
and copy it on the id variable, if (id modula 2) is equal to zero
that means the writer side has not modified yet Fcount3^.fcount3,
and the reader side will test again if FCount3^.fcount3 equal 0, and
if id=FCount5^.fcount5 didn't change and if FCount1^[myid1].fcount1 that
we have assigned before didn't change and that means that we are sure
that the writer side will block on FCount1^[myid1].fcount1 equal 1.
 
And notice with me that i am not looping like in Seqlock.
 
And the rest of my algorithm is easy to understand.
 
This technic that looks like Seqlock without looping like Seqlock
will allow us to be sure that although the x86 architecture will reorder
the loads of the inside reader critical section , the loads
inside the reader critical section will not go beyond the load of
FCount5^.fcount5 and this will allow my algorithm to work correctly.
 
My algorithm is FIFO fair on the writer side and FIFO fair on the
Reader side , and of course it is Starvation-free, and it is
suitable for realtime critical systems.
 
My Asym_RWLockX and LW_Asym_RWLockX algorithms work the same.
 
You will find the source code of my new algorithm here:
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
It is the version 2 that is my own algorithm.
 
and you can download the source code of my Asym_RWLockX and
LW_Asym_RWLockX algorithms that work the same from here:
 
https://sites.google.com/site/aminer68/scalable-rwlock
 
Language: GNU C++ and Visual C++ and C++Builder
 
Operating Systems: Windows, Linux, Unix and Mac OS X on (x86)
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Oct 11 01:08PM -0400

Hello...
 
 
Scalable Parallel C++ Conjugate Gradient Linear System Solver
Library version 1.53
 
 
Author: Amine Moulay Ramdane
 
Description:
 
This library contains a Scalable Parallel implementation of
Conjugate Gradient Dense Linear System Solver library that is
NUMA-aware and cache-aware, and it contains also a Scalable
Parallel implementation of Conjugate Gradient Sparse Linear
System Solver library that is cache-aware.
 
Please download the zip file and read the readme file inside the zip
to know how to use it.
 
Language: GNU C++ and Visual C++ and C++Builder
 
 
You can download it from:
 
https://sites.google.com/site/aminer68/scalable-parallel-c-conjugate-gradient-linear-system-solver-library
 
 
Thank you,
Amine Moulay Ramdane.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 04:43AM -0700

Did you know you are an eternal being? And that you will go on
after you leave this world? What's on the other side? What will it
be like?
 
We see this world today and we shudder to think about an eternity
lived in something similar. Hate, disease, war, unknowns, variations,
it all adds up to a quagmire of uncertainty day by day.
 
Well rest assured. Our future is not like that. The world here exists
this way because of sin. Disobedience to God allowed sin to enter
in, and it's been destroying ever since. But God did not leave us, or
forsake us despite our sin. He stepped into our world to rescue us,
to secure a real future in the proper (sin-free) form.
 
Jesus is our rescuer. He was born as a man, under our same laws
so that He could save us. He was born of a virgin, so He didn't have
any sin. He lived a sin-free life and God arranged it so He would
go to the cross innocent, so He could take on our sin and die, and in
that way our sin would die with Him, setting us free from sin, restoring
us to eternal life.
 
Jesus came into this world to rescue us. He loves us, wants to forgive
us of our sin, and asks us to come to Him and say, "Jesus, forgive my
sin." All who do are forgiven and immediately pass from death to
life, being completely changed from within in that selfsame moment.
 
After asking forgiveness of sin from Jesus, no longer are we the same.
Our thinking changes. Our wants and wishes change. We are literal new
creations. Though still here in the same body, our innermost parts,
the invisible parts of our core, they are all changed, made shiny and
new by Jesus Christ, His gift to us. Unmerited. Undeserved. It is simply
His pleasure to give us forgiveness.
 
Eternity will come to all people after death. For those who aren't forgiven
of their sin, judgment awaits you for the sin you've committed, and
with judgment ... condemnation.
 
All people are guilty of some sin, and all people need to be forgiven.
Jesus is willing to forgive all people, and He forgives all who come
to Him asking forgiveness. He will forgive you right now. All you have
to do is ask Him.
 
Come to Jesus and ask forgiveness for your sin, and begin your life anew
knowing that when you leave this world you will be in Heaven, with God,
safe and secure forever. It is the most weight-on-the-chest lifting
experience you'll ever know. Real freedom. Real inner change.
 
I love you. It's why I teach you these things. But Jesus loves you more.
 
Best regards,
Rick C. Hodgin
Wouter van Ooijen <wouter@voti.nl>: Oct 11 05:24PM +0200

Op 11-Oct-16 om 1:43 PM schreef Rick C. Hodgin:
> Did you know you are an eternal being?
 
Yuk! I am not a static constexpr, I am a run-time object with limited
lifetime and a well-defined a destructor.
 
W
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 08:35AM -0700

On Tuesday, October 11, 2016 at 11:25:02 AM UTC-4, Wouter van Ooijen wrote:
> > Did you know you are an eternal being?
 
> Yuk! I am not a static constexpr, I am a run-time object with limited
> lifetime and a well-defined a destructor.
 
That's where you're headed today.
 
Jesus Christ has the ability to change your fate. All you have to do is
come to Him and ask Him to forgive your sin. He supernaturally changes
you (a miracle of God, just like the miracle of your first birth, by the
way).
 
Best regards,
Rick C. Hodgin
Jerry Stuckle <jstucklex@attglobal.net>: Oct 11 12:31PM -0400

On 10/11/2016 11:24 AM, Wouter van Ooijen wrote:
 
> Yuk! I am not a static constexpr, I am a run-time object with limited
> lifetime and a well-defined a destructor.
 
> W
 
One thing about it. There may or may not be eternal life. But having
to put up with Rick's continued proselytizing makes life seem eternal!
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 09:44AM -0700

On Tuesday, October 11, 2016 at 7:47:26 AM UTC-4, Rick C. Hodgin wrote:
> safe and secure forever. It is the most weight-on-the-chest lifting
> experience you'll ever know. Real freedom. Real inner change.
 
> I love you. It's why I teach you these things. But Jesus loves you more.
 
There is an active enemy at work in this world. He works by injecting
thoughts, emotions, feelings, into our flesh. These come in the form
of teachings from high places, our leaders actions, and down to the
levels of personal interaction between people. Some forms are obvious
like addiction, depression, road rage. Others are more subtle and are
easily categorized as just "people being people" by many.
 
That enemy wants you to believe he doesn't exist, and that there aren't
spiritual influences in this world. He wants you to think it's all
just flesh and it isn't tied to anything more, or that there isn't
anything beyond this world, that evolution produced us, and we will
just wink out when our time is up.
 
It's a lie. It's a lie given by a heinous enemy of God who is trying
to prevent you from being freed from the sin he's trapped you in, so
that you can be restored to the glorious and beautiful eternal beings
God original created you to be.
 
Jesus Christ has come to make it possible. He takes your sin away so
you are without sin before a Holy God, restored rightly unto Him,
alive forevermore.
 
We are made in the image and likeness of God, and we will live on in
eternity like the angels ... if Jesus Christ takes away our sin. If
He doesn't take away our sin, we will live on in eternity in the fires
of Hell, contained in our sin for all time, never able to influence
another minute aspect of His universe as by our unchecked sin-loving
desires.
 
Jesus Christ literally saves people from Hell. All who call upon His
name asking forgiveness are saved. Be one of them. Live on in eternity
in a body like the angels that never tires, never hungers, never thirsts,
but is beautiful and always operating at peak efficiency, in God's great
and glorious Kingdom where love and joy abound forever.
 
It sounds like a "And they lived happily ever after" story ... but it's
even more than that, as there are some things in Heaven we can't even
talk about here, but they await all who are saved:
 
http://biblehub.com/kjv/2_corinthians/12-4.htm
 
4 How that he was caught up into paradise [the third Heaven], and
heard unspeakable words, which it is not lawful for a man to utter.
 
The first Heaven is the air. The second is space and everything visible.
But there's a third Heaven which we cannot see, and it is of such a kind
that the things spoken there cannot even be uttered lawfully by a man.
 
Glorious things await on the other side of death for all who are in Jesus
Christ. But for those who are not in Him, forgiven by Him, then their
sin remains upon them and they are lost forever to the fires and torments
of Hell.
 
Best regards,
Rick C. Hodgin
woodbrian77@gmail.com: Oct 10 06:11PM -0700

On Monday, October 10, 2016 at 5:57:20 PM UTC-5, Rick C. Hodgin wrote:
 
> http://biblehub.com/kjv/1_corinthians/10-24.htm
 
> 24 Let no man seek his own, but
> every man another's wealth.
 
The King James Version is poetic and all, but
isn't that great in my opinion. The New American
Standard Bible translates that last verse like this:
 
"Let no one seek his own good, but that of his neighbor."
 
And I think writing it as:
 
Let no one only seek his own good, but that of his neighbor.
 
may be close to the intent.
 
 
Brian
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 10 06:41PM -0700

On 10/9/2016 6:07 PM, Rick C. Hodgin wrote:
 
> Profit isn't bad. A purposed pursuit of profit without labor is bad.
> And it's something different if you're handed wealth. Such unexpected
> gifts are to be uses to help God's people, to employ, gift, etc.
 
Damn it Rick! Okay... The next time somebody hands you wealth, give some
to everybody on this group!
woodbrian77@gmail.com: Oct 10 06:46PM -0700

On Monday, October 10, 2016 at 8:41:53 PM UTC-5, Chris M. Thomasson wrote:
 
 
Chris, please don't swear here.
 
Brian
Ebenezer Enterprises - Sheep may safely graze.
http://webEbenezer.net
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 10 06:53PM -0700

> On Monday, October 10, 2016 at 8:41:53 PM UTC-5, Chris M. Thomasson wrote:
 
> Chris, please don't swear here.
 
Ummm, the word _damn_ actually offends you? Wow. Just, wow.
"Chris M. Thomasson" <invalid@invalid.invalid>: Oct 10 07:02PM -0700

On 10/10/2016 6:41 PM, Chris M. Thomasson wrote:
 
>> Profit isn't bad. A purposed pursuit of profit without labor is bad.
>> And it's something different if you're handed wealth. Such unexpected
>> gifts are to be uses to help God's people, to employ, gift, etc.
 
Now wait a minute here... You are saying that I can only pay employees
with "unexpected gifts", or else I will go to Hell?
 
 
 
Melzzzzz <mel@zzzzz.com>: Oct 11 04:02AM +0200

On Mon, 10 Oct 2016 18:53:25 -0700
> > wrote:
 
> > Chris, please don't swear here.
 
> Ummm, the word _damn_ actually offends you? Wow. Just, wow.
 
God does not like such ;)
 
 
--
press any key to continue or any other to quit
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Oct 11 05:03AM -0700

On Monday, October 10, 2016 at 10:02:14 PM UTC-4, Chris M. Thomasson wrote:
> >> gifts are to be uses to help God's people, to employ, gift, etc.
 
> Now wait a minute here... You are saying that I can only pay employees
> with "unexpected gifts", or else I will go to Hell?
 
Chris, if you want to know the truth ... pursue the truth. You are
demonstrating yourself to be an individual who doesn't seek the truth,
either purposefully so as to mock my posts and mock God, or because
you simply are not seeking the truth and therefore honestly do not
understand.
 
In both cases I advise you: seek the truth. Approach the material
with an inquisitive mind. Consider what it says, ponder on it before
you react. If you press in and ask questions within your mind, God
will know you are doing this and He will give you those answers.
Some will come immediately, or shortly thereafter. Others might need
to be revealed to you differently, and something will happen in your
life some hours or days later where you'll be in a circumstance where
it will then make sense to you.
 
Be patient. God moves with purpose, deliberately, with a plan. Satan
moves upon our emotions, our feelings, our flesh, trying to get us to
respond in the moment. You can remember this by the example God gave
us: weeds grow up quickly, but are useless weeds. True plants, true
fruit, true vegetables, those that are good for eating full of vitamins
and minerals, these take time to grow. They require cultivation, to
keep the weeds away, protection from the wild animals which come to
eat them up. It is the same with God's word. Give it that same type
of attention, protecting it from the weeds, protecting it from the wild
animals that will come to consume it (unholy people, false teachings,
false doctrines), and you will be on your path.
 
In short: Dig deep in your thinking on the things of God, and be patient.
 
Best regards,
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 11 05:49AM +0200


> For now I took OO Tiib's advice to use std::queue. That
> resulted in an 80 byte reduction in the size of the executable.
 
Wow! :-o
 
 
Cheers!,
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Oct 11 06:08AM

> It's also much more efficient to delete items from the beginning or
> middle of std::deque than std::vector.
 
From the beginning sure, of course. But from the middle? It requires as
many operations as with std::vector. If there are differences, I don't
think they are so big.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 11 09:10AM +0200

On 11.10.2016 08:08, Juha Nieminen wrote:
 
> From the beginning sure, of course. But from the middle? It requires as
> many operations as with std::vector. If there are differences, I don't
> think they are so big.
 
In the formal, yes, but reportedly a typical std::deque implementation
uses a sequence of blocks of items. Only the items within a block then
need to be shifted. Not all items till the end of the item sequence.
 
E.g. see <url:
http://stackoverflow.com/questions/5728359/stl-internals-deque-implementation>
 
I am not sure how constant time [] access is provided with this
implementation. That's an interesting question that maybe can be
answered by inspecting some source code. Now that I think of it. ;-)
 
The standard's requirements instead makes it seem more like a cursor gap
array, with the gap fixed to be between end and beginning.
 
With a cursor gap there's no problem providing constant time [] access,
and your "requires as many operations as with std::vector" would be true
also for the in-practice.
 
 
Cheers & hth.,
 
- Alf
mark <mark@invalid.invalid>: Oct 11 02:02PM +0200

On 2016-10-11 09:10, Alf P. Steinbach wrote:
> need to be shifted. Not all items till the end of the item sequence.
 
> E.g. see <url:
> http://stackoverflow.com/questions/5728359/stl-internals-deque-implementation>
 
"Only the items within a block then need to be shifted." Which deque
implementation is capable of that? I haven't seen any. All the ones I
have looked at use arrays of fixed-size buckets and shift everything
either to the front or the back on insertion. None have buckets with a
variable number of items (except front and back bucket).
"Öö Tiib" <ootiib@hot.ee>: Oct 10 04:46PM -0700

On Tuesday, 11 October 2016 00:20:38 UTC+3, Juha Nieminen wrote:
 
> In practice the need is so exceedingly rare that it just doesn't make
> sense to always use the more cumbersome syntax just so that the 0.01%
> of cases where it's actually needed would fit.
 
Is it really more cumbersome on 99.99% of cases?
 
In practice if member functions returns something at all then it
is often object of some nested type or typedef. Lot of the member
functions are not defined inline. Such definition will actually have
slightly less stutter while declaration will have more:
 
// class
class Holder
{
using Value = int; // or whatever other nested type
// ...
Value getter(); // less bloat
auto taker()->Value; // more bloat
};
 
// stutter bloat
Holder::Value Holder::getter() { return 41; }
 
// no stutter
auto Holder::taker()->Value { return 42; }
 
I don't like it that much anyway ... but perhaps it is because I'm
getting old.
 
 
> (Also, how many of those trailing return type examples are such that
> it wouldn't work with just the 'auto' return type without explicitly
> specifying the trailing type, as per C++14?)
 
That variant wastes my time. I want to see some type not to conclude it
out from body.
Juha Nieminen <nospam@thanks.invalid>: Oct 11 06:05AM

>> specifying the trailing type, as per C++14?)
 
> That variant wastes my time. I want to see some type not to conclude it
> out from body.
 
I would say that if you are using an 'auto' return type, then the actual
type doesn't matter.
 
Also, C++17 will allow the return type to actually be variable, and
depend on the parameter types.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
"Öö Tiib" <ootiib@hot.ee>: Oct 11 03:55AM -0700

On Tuesday, 11 October 2016 09:05:41 UTC+3, Juha Nieminen wrote:
> > out from body.
 
> I would say that if you are using an 'auto' return type, then the actual
> type doesn't matter.
 
When type of what a function returns does not matter? To me it usually
matters (if the function matters at all). Why it returns it if it does not
matter what it is?

I think about that 'auto' in function declaration as 'function' keyword
of Ada (as opposed to 'void' that can be imagined as 'procedure'
keyword of Ada).
 
 
> Also, C++17 will allow the return type to actually be variable, and
> depend on the parameter types.
 
It is possible that there won't ever be C++17 and also no one knows
what it will be. C++14 already did bring more damage than benefits.
Currently it seems that in committee are left only saboteurs from
companies like Apple, Oracle, Google, Microsoft, Amazon and IBM
that try to screw with it to each other. Perhaps we should boycott
those companies.
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)