Friday, July 3, 2020

Digest for comp.lang.c++@googlegroups.com - 18 updates in 1 topic

Juha Nieminen <nospam@thanks.invalid>: Jul 03 06:53AM

> In a quick look through the C++ standard, I don't see a formal
> definition of "instantiate".
 
Which actually makes that other guy's attempt at nitpicking about the
definition of the word even mor ridiculous, given that there's no
official definition. It's especially ridiculous that he tries to
allude to the English language for this, given that no English
dictionary defines "instantiate" in terms of a particular programming
language like C++.
 
I would argue that pretty much universally it's agreed that when a type
is "instantiated" it means that now some concrete values corresponding to
that abstract type exist in memory somewhere (where they can be eg read,
or a pointer/reference can be created that points to them).
 
(Of course in the case of templates the word "instantiate" has a slightly
different meaning, as you point out is used in the standard as well.
Although, even in this case it's not *that* dissimilar: An abstract
declaration of types and/or code is made concrete, usually by instantiating
types types and/or code in the first sense above, so they become actual
data that ends up in memory somewhere.)
 
I don't think anybody makes the distinction of eg. "instantiating a class"
into data that ends up somewhere in the executable binary file itself,
or at runtime in a manner that ends up somewhere on the heap or stack.
In both situations "instantiating" is merely the act of creating actual
concrete values that reside somewhere, from an abstract type (or code)
declaration.
"Öö Tiib" <ootiib@hot.ee>: Jul 03 01:46AM -0700

> >to cite from where are you getting your definition as answer. So I
> >diagnosed you as a piece of offal based on that.
 
> *yawn* Someone wake me up when the record changes. Zzzzzz....
 
Correction. Piece of drowsy offal.
"Öö Tiib" <ootiib@hot.ee>: Jul 03 04:18AM -0700

On Friday, 3 July 2020 00:12:15 UTC+3, Keith Thompson wrote:
> definition of "instantiate". It does use the word, but usually in
> reference to templates. Do you have a specific citation of the word
> "instantiate" being used this way?
 
"Instantiation" used about objects in C++ has to be informal
simplification. It perhaps originates from programming language
like Java where there is only one kind of storage (not four),
constness of objects is not language feature, compile time
processing is not language feature, end of life-time of object is
never under control of programmer, storage can never be reused,
objects have to be always initialised in same step of allocation
of storage and so on. In C++ it is cheap way for troll like boltar
to confuse all discussion into nonsense with argument that there
is some kind of special formal meaning of it.
boltar@nowhere.co.uk: Jul 03 11:22AM

On Thu, 2 Jul 2020 21:55:02 +0100
 
>> of it existing in the code even before an object has been created from it.
 
>When you instantiate a class you make an object of that class.
 
>Sometimes this is done at compile time.
 
No, it isn't. Unless you think the binary comes with its own heap and stack.
Go disassemble one and have a look.
boltar@nowhere.co.uk: Jul 03 11:22AM

On Fri, 3 Jul 2020 01:46:00 -0700 (PDT)
>> >diagnosed you as a piece of offal based on that.
 
>> *yawn* Someone wake me up when the record changes. Zzzzzz....
 
>Correction. Piece of drowsy offal.
 
I've been called a lot worse by people far better at insults than you.
boltar@nowhere.co.uk: Jul 03 11:28AM

On Fri, 3 Jul 2020 04:18:21 -0700 (PDT)
>of storage and so on. In C++ it is cheap way for troll like boltar
>to confuse all discussion into nonsense with argument that there
>is some kind of special formal meaning of it.
 
Ah ok, I'm a troll for not agreeing with you and Mr Fin. So if there's no
formal meaning then you one can use any meaning one wants so therefor this
discussion is over. Right?
already5chosen@yahoo.com: Jul 03 04:46AM -0700


> Ah ok, I'm a troll for not agreeing with you and Mr Fin. So if there's no
> formal meaning then you one can use any meaning one wants so therefor this
> discussion is over. Right?
 
As originator of the thread I do think that the faster this particular branch of discussion is over, the better for most of us.
"Öö Tiib" <ootiib@hot.ee>: Jul 03 04:52AM -0700


> Ah ok, I'm a troll for not agreeing with you and Mr Fin. So if there's no
> formal meaning then you one can use any meaning one wants so therefor this
> discussion is over. Right?
 
Bullshit. I did not use nor argue about any meaning of it. You claimed
it has meaning: "instantiation means run time creation" and you failed
to show from what dictionary or standard that garbage come from.
boltar@nowhere.co.uk: Jul 03 11:55AM

On Fri, 3 Jul 2020 04:52:47 -0700 (PDT)
 
>Bullshit. I did not use nor argue about any meaning of it. You claimed
>it has meaning: "instantiation means run time creation" and you failed
>to show from what dictionary or standard that garbage come from.
 
So you're not arguing over the meaning of it but my definition is apparently
"garbage". I'll let you go and have a little think about how you managed to
contradict yourself there. Well done.
"Öö Tiib" <ootiib@hot.ee>: Jul 03 04:59AM -0700


> So you're not arguing over the meaning of it but my definition is apparently
> "garbage". I'll let you go and have a little think about how you managed to
> contradict yourself there. Well done.
 
Everything utterly groundless is garbage. And utter groundlessness is
shown by your failure to provide any ground.
Paavo Helde <eesnimi@osa.pri.ee>: Jul 03 06:52PM +0300


>> Sometimes this is done at compile time.
 
> No, it isn't. Unless you think the binary comes with its own heap and stack.
> Go disassemble one and have a look.
 
I think we have figured out this many years ago. An object in C++ is a
region of memory. This means it has an address and size.
 
As soon as the binary image is loaded into the process address space,
any region in it which corresponds to a C++ object obtains a memory
address, so by then it's an object there. Loading the binary into memory
is a run-time activity (esp. with dynamically loaded libs), so this even
matches boltar's definition.
 
And no, heap and stack are not the only places where C++ objects can reside.
boltar@nowhere.co.uk: Jul 03 03:58PM

On Fri, 3 Jul 2020 04:59:06 -0700 (PDT)
>> contradict yourself there. Well done.
 
>Everything utterly groundless is garbage. And utter groundlessness is
>shown by your failure to provide any ground.
 
I can lend you a nice spade to help you dig that hole even deeper if you like.
boltar@nowhere.co.uk: Jul 03 04:06PM

On Fri, 3 Jul 2020 18:52:57 +0300
>is a run-time activity (esp. with dynamically loaded libs), so this even
>matches boltar's definition.
 
>And no, heap and stack are not the only places where C++ objects can reside.
 
Sure, you could hide them away in shared memory or somewhere similar but the
point is they do NOT exist in the binary. The class definition is NOT an object
and instantiating the process does not create any objects until instantiation
code has been run whether its explicit user code or compiler generated start up.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 03 07:32PM +0100

On Fri, 3 Jul 2020 11:22:45 +0000 (UTC)
boltboy wrote:
 
> >> *yawn* Someone wake me up when the record changes. Zzzzzz....
 
> >Correction. Piece of drowsy offal.
 
> I've been called a lot worse by people far better at insults than you.
 
I think most people already realized that.
Juha Nieminen <nospam@thanks.invalid>: Jul 03 07:22PM


>>Everything utterly groundless is garbage. And utter groundlessness is
>>shown by your failure to provide any ground.
 
> I can lend you a nice spade to help you dig that hole even deeper if you like.
 
I just love your projection there. It's quite clear that this isn't
the first time you have got yourself into this kind of situation,
and you have learned from your previous battles the concepts and
terminology that people use against you, and now you are just
throwing those same terms against others because you think that
if they work against you, surely they will work against others
if you use them.
 
Words, expressions and accusations have a meaning, and if you use them
in a context that doesn't apply, it just makes you sound foolish.
 
Perhaps some time in the future, ten or twenty years from now, when
you have grown and wisened up a bit, you'll understand that it's
better even for your own sake to just concede when you make an error
rather than trying stubborningly and uselessly to win the argument
at any cost. Perhaps you'll understand that not only is it useless,
but in fact detrimental for your own reputation to try to win an
empty victory at any cost, over such a trivial thing as the meaning
of a word.
 
You know why they make a comparison between a flamewar and the special
olympics?
Juha Nieminen <nospam@thanks.invalid>: Jul 03 07:26PM

> point is they do NOT exist in the binary. The class definition is NOT an object
> and instantiating the process does not create any objects until instantiation
> code has been run whether its explicit user code or compiler generated start up.
 
How many conditions are you going to add for this personal definition
of yours?
 
I noticed earlier that you didn't answer my question. Is this
instantiating a class or not?
 
static const MyClass obj;
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 03 12:58PM -0700

On 7/3/2020 12:26 PM, Juha Nieminen wrote:
 
> I noticed earlier that you didn't answer my question. Is this
> instantiating a class or not?
 
> static const MyClass obj;
 
Check this out... I need a static node to use its address for the wait
state of special atomic stack experiment. This node needs to be able to
have its address taken... Here is the code. It should work, it calls a
constructor. Any thoughts?
 
_____________________________
#include <iostream>
#include <atomic>
#include <thread>
 
 
struct user_payload
{
int m_foo;
 
user_payload(int foo) : m_foo(foo) {}
 
user_payload(const user_payload& rhs) : m_foo(rhs.m_foo) {}
 
void process()
{
std::cout << this << "->user_payload::process() " << m_foo << "\n";
std::this_thread::yield();
}
};
 
 
namespace ct
{
 
static struct node* node_wait_next(node*);
 
struct node
{
std::atomic<node*> m_next;
user_payload m_payload;
 
 
node(user_payload const& payload) : m_next(nullptr),
m_payload(payload)
{
std::cout << this << "->node::node()" << "\n";
}
 
~node()
{
std::cout << this << "->node::~node()" << "\n";
}
 
 
static void process(node* head)
{
node* cur = head;
 
while (cur)
{
// user processing first!
cur->m_payload.process();
 
// now, we see if we need to wait...
node* next = node_wait_next(cur);
 
delete cur;
 
cur = next;
}
}
};
 
 
static node g_special_wait_node(0);
 
 
#define CT_SPECIAL (&ct::g_special_wait_node)
 
 
node* node_wait_next(node* n)
{
node* next = nullptr;
while ((next = n->m_next.load(std::memory_order_relaxed))
== CT_SPECIAL) std::this_thread::yield();
return next;
}
 
struct stack
{
std::atomic<node*> m_head;
 
stack() : m_head(nullptr) {}
 
void push(node* n)
{
n->m_next.store(CT_SPECIAL, std::memory_order_relaxed);
node* prev = m_head.exchange(n, std::memory_order_release);
n->m_next.store(prev, std::memory_order_relaxed);
}
 
 
node* flush()
{
return m_head.exchange(nullptr, std::memory_order_acquire);
}
};
}
 
 
int main()
{
std::cout << "\nCT_SPECIAL = " << CT_SPECIAL << "\n\n";
 
{
ct::stack alist;
 
alist.push(new ct::node(789));
alist.push(new ct::node(456));
alist.push(new ct::node(123));
 
ct::node* work = alist.flush();
 
ct::node::process(work);
 
 
alist.push(new ct::node(321));
alist.push(new ct::node(654));
alist.push(new ct::node(987));
 
work = alist.flush();
 
ct::node::process(work);
}
 
return 0;
}
_____________________________
 
 
Does it work for you?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 03 11:56PM +0100


> So you're not arguing over the meaning of it but my definition is apparently
> "garbage". I'll let you go and have a little think about how you managed to
> contradict yourself there. Well done.
 
An object is an instantiation of a type, e.g.
 
int i = 42; // i is an object being instantiation (i.e. an instance) of the type int.
 
/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."
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: