Wednesday, June 14, 2017

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

rami18 <coco@coco.com>: Jun 14 12:32PM -0400

Hello..
 
 
I am thinking writing a compiler that includes a Virtual machine , it
will support Threads with an efficient Threadpool that is NUMA-aware and
NUMA efficient, and its memory manager will be scalable and with very
little memory fragmentation and it will support calling Dynamic Link
Libraries, and it will support my synchronization object Library and it
will support much more..
 
And i was thinking more if i need or not a Just-In-Time Compiler, or
can i simply support calling binary code of Dynamic Link Libraries ?
 
But i have come accross the basic idea of a Just-In-Time Compiler, here
it is:
 
http://nullprogram.com/blog/2015/03/19/
 
 
Thank you,
Amine Moulay Ramdane.
Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Jun 14 01:18AM +0200

Am 13.06.2017 um 09:23 schrieb Juha Nieminen:
 
> So I suppose C++11 did *not* add garbage collection to the language.
 
C++11 defines all the necessary pointer traits required for GC, as well
as several specific functions and templates for controlling a garbage
collector (e.g. std::declare_reachable). It is possible to write
programs and template libraries in C++11, which will still behave
correctly when used in a runtime environment with GC.
 
C++11 does not require a specific compiler implementation to actually
provide a garbage collector, though.
 
Hergen
Juha Nieminen <nospam@thanks.invalid>: Jun 14 07:14AM

> C++11 does not require a specific compiler implementation to actually
> provide a garbage collector, though.
 
That's my point.
 
It's not required by the standard, and to my knowledge none of the major
compilers implement it.
 
Since you can't rely on compilers supporting garbage collection, you can't
write portable code making that assumption. Or, as it happens to be in
practice, even non-portable code, because the support just isn't there.
At least not without using some third-party library.
Juha Nieminen <nospam@thanks.invalid>: Jun 14 07:23AM

> You can find a discussion of your argument here: <url:
> https://en.wikipedia.org/wiki/Straw_man>.
 
I'm getting really tired of your arrogant attitude. Maybe you'll want
to tone it down if you want to have civil discussions with people.
 
How exactly is what I said a straw man argument? If you allocate something
with 'new', you'll have to make sure it gets destroyed with a correspondent
'delete' (by either writing it yourself, or having some class do it for
you, like eg. unique_ptr). That was true in 2011, and it's still true
today, in 2017. That fact hasn't changed an iota.
 
C++11 doesn't have any more support for garbage collection than C++98
has for export templates. In fact, it has even less. Export templates
were a requirement of the C++98 standard; it's just that no major
compiler implemented it (and thus no compiler was standard-compliant).
Garbage collection isn't even a requirement in C++11, so compilers
having no support doesn't technically mean they aren't standard-
compliant.
 
Saying "C++11 added support for garbage collection" is, at the very
least, highly misleading. It makes it sound like you don't need to
worry about deleting what you allocate anymore. Just allocate and
forget, the garbage collector (which is "supported by C++11") will
take care of it.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 10:25AM +0200

On 14-Jun-17 9:23 AM, Juha Nieminen wrote:
>> https://en.wikipedia.org/wiki/Straw_man>.
 
> I'm getting really tired of your arrogant attitude. Maybe you'll want
> to tone it down if you want to have civil discussions with people.
 
How about toning down both the ad hominem attacks, the strawman
arguments, and the counter-factual assertions?
 
By "toning down" I mean /less/ of it, not just weaker versions.
 
 
[snip]
 
> Saying "C++11 added support for garbage collection" is, at the very
> least, highly misleading.
 
Look at the section titled "Garbage collector support": <url:
http://en.cppreference.com/w/cpp/memory>.
 
You can use your browser's find functionality to find that very quickly,
as an alternative to scrolling down.
 
Earlier I referred you to the C++ standard, which also calls it that.
 
 
> worry about deleting what you allocate anymore. Just allocate and
> forget, the garbage collector (which is "supported by C++11") will
> take care of it.
 
May I suggest you context some committee members about your strong
disagreement with what the garbage collection support is called?
 
Write up a proposal.
 
Find someone or some group of committee members to champion it.
 
 
Cheers & hth.,
 
- Alf
Hergen Lehmann <hlehmann.expires.5-11@snafu.de>: Jun 14 11:51AM +0200

Am 14.06.2017 um 09:14 schrieb Juha Nieminen:
 
 
> That's my point.
 
> It's not required by the standard, and to my knowledge none of the major
> compilers implement it.
 
GC is more of a runtime environment feature than a compiler feature. If
it was implemented by the compiler itself, you could no longer link
against modules written in other languages.
 
And when it comes to the runtime environment, there are always language
features you can't really use in a certain environment. For example, you
likely won't be able to use IO streams and C++-style concurrency on
small embedded systems, even when cross-compiling with clang or gcc. You
will have a hard time using some of the legacy C99 features (e.g.
sprintf and strftime) on Windows systems, where their implementation
traditionally defies the standard.
 
> Since you can't rely on compilers supporting garbage collection, you can't
> write portable code making that assumption.
 
You can, as long as you are using smart pointers as you should do.
The garbage collector interface is only of relevance when implementing
low-level algorithms like within the STL itself.
 
Hergen
Bo Persson <bop@gmb.dk>: Jun 14 01:13PM +0200

On 2017-06-14 09:14, Juha Nieminen wrote:
> write portable code making that assumption. Or, as it happens to be in
> practice, even non-portable code, because the support just isn't there.
> At least not without using some third-party library.
 
The standard doesn't guarantee any specific size of the available memory
for dynamic allocations. So how do you write portable programs in the
first place, garbage collected or not?
 
 
Bo Persson
"Öö Tiib" <ootiib@hot.ee>: Jun 14 09:27AM -0700

On Wednesday, 14 June 2017 10:15:05 UTC+3, Juha Nieminen wrote:
 
> That's my point.
 
> It's not required by the standard, and to my knowledge none of the major
> compilers implement it.
 
All major compiler's have features that are needed for implementing GC.
So it is library thing not compiler thing.
 
> write portable code making that assumption. Or, as it happens to be in
> practice, even non-portable code, because the support just isn't there.
> At least not without using some third-party library.
 
Adding GC to standard library would be doable. It is just that no one
bothers. Seems that ref counting is more popular right now than GC and
so some would ref count even with GC and so since C++ is no-one's
property it is up to fans of GC. ;-)
rami18 <coco@coco.com>: Jun 14 12:24PM -0400

Hello..
 
 
I am thinking writing a compiler that includes a Virtual machine , it
will support Threads with an efficient Threadpool that is NUMA-aware and
NUMA efficient, and its memory manager will be scalable and very little
memory fragmentation and it will support calling Dynamic Link
Libraries, and it will support much more..
 
And i was thinking more if i need or not a Just-In-Time Compiler, or
can i simply support calling binary code of Dynamic Link Libraries ?
 
But i have come accross the basic idea of a Just-In-Time Compiler, here
it is:
 
http://nullprogram.com/blog/2015/03/19/
 
 
Thank you,
Amine Moulay Ramdane.
"Öö Tiib" <ootiib@hot.ee>: Jun 14 01:27AM -0700

On Tuesday, 13 June 2017 00:46:55 UTC+3, Alf P. Steinbach wrote:
 
> … to explicitly indicate the expected pointer-ness of the foo() result,
> or else I'd have to use the operator notation; i.e., that `auto` is by
> far not as powerful as template function argument deduction. :(
 
I likely misunderstand the essence of that annoyance. May be that
because raw pointers are rare in code or may be because the
motivating code above reminds me about 'std::auto_ptr' (that was
quite bad trap). ;)
 
So ... did you want to embed following static_assert (invisibly or
less visibly)?
 
auto const p = foo();
static_assert(std::is_pointer<decltype(p)>::value
, "p must be raw pointer");
 
For me it feels fine to make noise about something being required
to be a raw pointer like that (if it is important).
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 10:34AM +0200

On 14-Jun-17 10:27 AM, Öö Tiib wrote:
> , "p must be raw pointer");
 
> For me it feels fine to make noise about something being required
> to be a raw pointer like that (if it is important).
 
The `static_assert` is good for the compiler.
 
But it's IMO not so good for the human: one has to read it and analyze
it, rather than just see it.
 
Well that could be alleviated via a macro, but. :)
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Jun 14 08:51AM -0700

On Wednesday, 14 June 2017 11:34:32 UTC+3, Alf P. Steinbach wrote:
 
> The `static_assert` is good for the compiler.
 
> But it's IMO not so good for the human: one has to read it and analyze
> it, rather than just see it.
 
The point of static_assert is to fail fast and when failing then get clear
explanation with zero run-time cost. Most of asserts and static_asserts
and other debug checks I usually skip when reading code unless I have
issue related to those checks being too harsh or feeble.
Blocks of such checks are often sizable part of code base i mature project
but provide no functionality just check sanity of code.
 
> Well that could be alleviated via a macro, but. :)
 
Hmm ... macros have been, yes, good for producing debugging-related
code since majority of available reflection in C++ (like __FILE__, __LINE__
and __FUNCTION__) have been macros. Reflection is sometimes needed
for to be able to fail more clearly.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 02:31AM +0200

On 14-Jun-17 1:10 AM, Mr Flibble wrote:
> types do. The object substitutability you speak of only applies to
> objects of related types and it is the behaviours as defined by those
> types that is important not the objects themselves.
 
You have trolled, successfully, and you have also demonstrated that you
are not familiar with the subject area, and unable to adjust. What more
do you want?
 
 
Cheers!
 
- Alf
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 13 08:05PM -0500


> You have trolled, successfully, and you have also demonstrated that you
> are not familiar with the subject area, and unable to adjust. What more
> do you want?
 
Oh I think I have fully demonstrated my knowledge of LSP (see my initial
reply); it is you who seems to be confused/unsure about the subject what
with you going on about constructors and object lifetimes and such which
have nothing to do with LSP per se.
 
/Flibble
Tim Rentsch <txr@alumni.caltech.edu>: Jun 13 08:07PM -0700


>> He isn't giving an argument;
 
> He certainly gives that impression: an assertion followed by apparent
> (but irrelevant) argument.
 
I don't take the sentences after the semicolon as an argument,
but just an elaboration of the previous characterization (ie, the
word "Nonsense").
 
>> he is simply making a statement.
 
> That too.
 
I don't know what you mean by this statement. The two cases I am
trying to distinguish are mutually exclusive. They can't both be
true.
 
 
> I have, because in 2012 I started on a blog article series on the
> Liskov Substution Principle, <url:
> https://alfps.wordpress.com/2012/03/11/liskovs-substitution-principle-in-c/>.
 
Okay. AFAICS what you say in there agrees with what I said and
what I understand the Wikipedia page to be saying.
 
> articles. :( It also interfered with doing things to get reawarded my
> Microsoft Most Valued Professional award. It's reawarded each year: I
> only got the first. :(
 
I'm sorry to hear that. It sounds like it was a very hard time. :(
 
 
>>>> but what he is saying is essentially correct.
 
> Yes, as you will note I told you that what he wrote after the
> semicolon, was essentially correct, and irrelevant.
 
Ahh, I didn't understand before what you meant in the earlier
comment. As I understand things, I believe what Mr Flibble was
saying is relevant to (some of) your earlier comments, so I don't
know why you think what he said was irrelevant, or what it was
irrelevant to. To me it does look quite relevant to your
statement upthread.
 
> defeats some position, when that position has never been argued by
> anyone else. It's a known, named, fallacy. It's called a Straw Man
> argument.
 
I don't know why you would say this. He was responding to your
statement that the LSP is about the behavior of objects. (His
quoting cut off just before the word "objects" but I thought it
was clear from context that this is what he was responding to.
Also the word "objects" was there in the posting he was
responding to.)
 
 
>> His statement agrees with how Wikipedia describes the term.
 
> I rather doubt that the Wikipedia article on nonsense agrees with
> Leigh's position.
 
As I read what is said on the Wikipedia page on the LSP, and what
Mr Flibble (or Leigh if that is his name) has said in his
responses, what he is saying agrees with what the Wikipedia page
says about the LSP (and which is also consistent with what you
wrote in the blog entry, to the extent of what I saw there).
 
 
 
>> In any case my comment was only about the definition of
>> the LSP, and wasn't meant to say anything about constructors.
 
> Yes, I believe that. :-)
 
I'm at a loss to understand what has prompted the tone of your
response here. I've been making an effort to be cordial and
helpful, and it seems like your response is somewhat boiling over
to be rude and dismissive. I don't want to get in the middle
of some sort of conflict of personalities; my comments are only
about the statements that have been made, not about the people
who made them. I hope you can see that.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 05:23AM +0200

On 14-Jun-17 5:07 AM, Tim Rentsch wrote:
 
> I'm at a loss to understand what has prompted the tone of your
> response here.
 
No you're not.
 
- Alf
Christian Gollwitzer <auriocus@gmx.de>: Jun 14 09:31AM +0200

Am 14.06.17 um 05:23 schrieb Alf P. Steinbach:
 
>> I'm at a loss to understand what has prompted the tone of your
>> response here.
 
> No you're not.
 
Has your news account been hacked?
 
Christian
Christian Gollwitzer <auriocus@gmx.de>: Jun 14 09:32AM +0200

Am 14.06.17 um 02:31 schrieb Alf P. Steinbach:
 
> You have trolled, successfully, and you have also demonstrated that you
> are not familiar with the subject area, and unable to adjust. What more
> do you want?
 
Jerry, is it you?
 
Christian
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 14 10:30AM +0200

On 14-Jun-17 9:31 AM, Christian Gollwitzer wrote:
>>> response here.
 
>> No you're not.
 
> Has your news account been hacked?
 
Nope. Tim is intentionally supporting a trolling effort. The very same
paragraph he describes as nonsense in this sub-thread, he responded to
in a meaningful way, understanding it completely, in another sub-thread.
 
And when I pointed that out to him he /continued/. That
self-contradiction and failure to address it when mentioned, means that
he's non truthful here about not understanding anything, and I called
him out on that
 
I have enough with the silly attacks from the ungrateful Juha, they
annoy me sufficiently, I don't have to take this shit.
 
 
Cheers!,
 
- Alf
Tim Rentsch <txr@alumni.caltech.edu>: Jun 14 06:32AM -0700

>> aspect of Timer behavior, ie, to deliberately break the LSP.
 
> The peculiarity though, and I think it is, is that I can change many
> aspect of a class's behaviour, except those in its constructor
 
I am guessing you meant destructor there rather than constructor.
If so then I agree - AFAICT there is no way (short of some sort
of extra-linguistic trickery, or placement new, etc) to avoid the
base class destructor being called. And "peculiarity" does
indeed seem appropriate.
 
> does anything...
 
> But this is a fire-and-forget class that I use for testing code-speed,
> so all that seemed a bit much.
 
Yeah. I'm surprised that C++ doesn't provide some way to avoid
calling a base class destructor, especially since it seems like
it comes up often enough (appearing on stackoverflow and lots
of other places).
 
> LSP. My CancellableTimer can be used anywhere a Timer can be used, but
> the fact that I used a reference not a pointer added constraints that
> should have been a mere implementation detail.
 
I'm pretty sure my description of LSP agrees with how it was
defined in the Liskov and Wing paper. The thing about LSP is that
it is quite stringent: subtypes can provide stronger guarantees,
but never weaker guarantees. For LSP to hold, it isn't enough
that a derived class object be usable anywhere a base class object
can be - it also must provide the same behavior that the base
class object would. The point of using a CancellableTimer is to
change some aspect of a Timer's behavior (ie, so as not to update
the referenced data), which violates what LSP requires.
Tim Rentsch <txr@alumni.caltech.edu>: Jun 14 08:15AM -0700

> self-contradiction and failure to address it when mentioned, means
> that he's non truthful here about not understanding anything, and I
> called him out on that
 
In case anyone is still reading this, let me say for the record
that I don't consider Mr Flibble's posting that started all this
off to be trolling. He was making a reasonable statement in
response to a statement made by Alf. It happens that I agree
with his statement, but whether one agrees with it or not I think
it was a reasonable followup to Alf's posting.
 
Let me also say that my two followups to which Alf referred were
consistent with each other. If someone thinks otherwise then
they have not understood my intended meaning. I am happy to
discuss all this in a calm and rational way, if anyone is still
interested. I don't understand why Alf is having the reaction
that he is, and unfortunately that seems to preclude further
useful discussion. So for now I expect to have no more to say on
the subject, unless something happens to change that.
woodbrian77@gmail.com: Jun 14 07:24AM -0700

I've been making steady progress the past few months here:
 
https://github.com/Ebenezer-group/onwards
 
With "I've been working on the railroad" playing in the background,
I ask for some ideas on how to improve my repo. Thank you in
advance.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
"Öö Tiib" <ootiib@hot.ee>: Jun 14 12:43AM -0700

On Monday, 12 June 2017 22:41:47 UTC+3, JiiPee wrote:
> those are selected the ones which are in a particular game. A player can
> be removed from the game even in the middle of the game. And all of the
> functionalities use the same Player class.
 
On such case you could make it so that "player" must be always in
something "game-like". For example if it leaves some real "chess game"
then it is some "idle-list" or in "lobby" that follows interface rules of "game".
Reason is that "one to 0..many" relation can be much more convenient than
"0..1 to 0..many" relation.
 
> variables like the title of the player and the name of the player can
> possibly be modified even without being in a game (just modifying the
> players database).
 
I still don't understand it fully but what it sounds like is that
there is possibility also that the "points" are not really part of "player".
May be these are part of "score"? That "score" would then be record
that is in "0..many to one" relation with "game" and "0..many to one"
relation with player. Think about it bit deeper. Getting those entities
and relations right is quite important for making software successfully.

> does not need to be in any game at that moment. Also logically speaking
> so. If you modify a certain database -players name, why would it need to
> be in a game?
 
Yes but that sounds like unnaturally generic state. As analogy imagine a
"shop" that is in state of modifying "customer"s data. What is going on?
Some hacky violation of abstraction layers. Shops "advertize", "make offers",
"sell goods" etc not "modify data".
JiiPee <no@notvalid.com>: Jun 14 12:53PM +0100

On 14/06/2017 08:43, Öö Tiib wrote:
> then it is some "idle-list" or in "lobby" that follows interface rules of "game".
> Reason is that "one to 0..many" relation can be much more convenient than
> "0..1 to 0..many" relation.
 
I got a bit exited about what others suggested about shared pointer,
which might do the job. But I think about this idea as well.
 
>> players database).
> I still don't understand it fully but what it sounds like is that
> there is possibility also that the "points" are not really part of "player".
 
The player class contains variable:
class Player
{
private:
int points;
};
so it is fixed part of it. Its the points the player gets in one/current
game. Its there (currently) only for the purpose of the current game.
 
> May be these are part of "score"? That "score" would then be record
 
ye could call is score.... i just named it points. But the same thing:
its the score/points in the current running game (if the player in it).
 
> "shop" that is in state of modifying "customer"s data. What is going on?
> Some hacky violation of abstraction layers. Shops "advertize", "make offers",
> "sell goods" etc not "modify data".
 
sure if its not logical I ll change it. I ll think about this...
But a good topic to discuss, after I think about it.
Well it works pretty well like it is, but always good to make things
more logical.
Juha Nieminen <nospam@thanks.invalid>: Jun 14 07:37AM

> Why not std::vector<const char *> ?
 
If the source consists of static string literals, another more efficient
option is using std::initializer_list<const char*> instead. In this
situation it kind of works like std::vector, except that it doesn't
need to allocate any additional memory (it simply contains a pointer
and a size, or possibly two pointers, which point to the static
data.) As a bonus, you get a nicer initialization syntax.
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)