Sunday, August 14, 2016

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

ram@zedat.fu-berlin.de (Stefan Ram): Aug 14 04:19PM

>The problem is how can I give values to Values[i].d?
 
I think this came up before here recently: You might
read into an array and then reinterpret-cast it to the
same type just with »const«.
 
Or placement-new the objects into the array and
pass the value to the constructor of each object?
 
Or have a class with a setter and a getter, but
the setter will stop to work after its first use?
Or even have a »seal()« call to disable the setter?
bleachbot <bleachbot@httrack.com>: Aug 14 09:50PM +0200

bleachbot <bleachbot@httrack.com>: Aug 14 10:22PM +0200

bleachbot <bleachbot@httrack.com>: Aug 14 10:42PM +0200

bleachbot <bleachbot@httrack.com>: Aug 14 11:18PM +0200

Ramine <ramine@1.1>: Aug 14 05:18PM -0400

Hello...
 
He is my final words about Transactional memory...
 
As you have seen me reasonning more precisely about Transactional memory
, i hope you have get my ideas about it, so here is more
clearly my final words about Transactional memory:
 
1- Transactional memory have good characteristic on the safety side,
since it avoid race conditions and deadlocks, so then it is
best suited for composability.
 
2- But Transactional memory is poorer on performance than Locks,
beacause if the serial part is more bigger you will get more
chance to get conflicts, but since transactions must wrap the
serial part and the parallel part to get more safety and avoids
race conditions, so the Transactional memory is not best suited
on the performance characteristic, i think that Locks are faster
and this has surfaced clearly from my logical inference of this
post and my previous posts.
 
3- So from [2] above, Transactional memory is not best suited
for realtime critical systems when you want to guaranty a decent
performance that locks can guaranty, so locks are the best
on the performance characteristic.
 
Hope you have followed my reasonning and my logical inference
and you have understood them well.
 
 
Thank you,
Amine Moulay Ramdane.
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 07:06PM +0200

Le 14/08/2016 à 17:23, Manfred a écrit :
> this confirms the complexity of the language, IMHO. Meaning that the
> original cleanliness of the language risks to get polluted by newer
> "improvements"
 
Exactly the point I am trying to make.
 
Interactions between each new "feature" with old features, added to
things that were already wrong (the ambiguity between 0 as an integer
and 0 as a null pointer) that weren't fixed but now reachy new places
where they can bite the unaware.
 
What I want to say is this:
 
C++ is reaching the point where only a machine can follow the extremely
complex rule's interaction.
 
Programmers can't follow and when they use the language they CAN'T
foresee exactly what will happen.
 
The example I gave is just 12 lines of C++!
 
It is not the sheer size of the example, it is just that humans can't
follow the rules!
 
jacob
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 08:58PM +0200

Le 12/08/2016 à 18:59, Richard a écrit :
 
> Getting back to the example code, my takeaway is two-fold:
 
> 1) It's been a well known problem that overloading functions for a pointer
> type and an integer type leads to surprises.
 
Yes. And what about fixing THOSE problems BEFORE adding new features?
 
 
> Is NULL an integer or is
> it a pointer?
 
Zero is zero, and a zero pointer points to the first available memory
location. It is useful to make this (easy to test) location a convention
for meaning:
 
1) This pointer has no value yet, or
 
2) its value was destroyed, or
 
3) it means "not found", when you call a search function.
 
> It depends on the implementation.
 
Maybe there are more use cases but let's keep those three use cases.
Then, the standard should give SIMPLE rules what is NULL in which context.
 
Problem is, that C++ has becomed plagued with ambiguity, since automatic
generated code is issued on behalf of the programmer.
 
This feature can be used, but also abused, it is a matter of measure.
The golden rule is that the language should be able to be parsed by a
qualified reader in a short period of time. Rules should be easy to
grasp and their number should be reduced to a minimum.
 
There are too many interacting constructs that come to be added to the
language, complexifying even more a complex situation. Let's STOP.
 
I have a solution:
 
Let's make the compiler itself PROGRAMMABLE. Let's design a simpler
language but with a programmable compiler where it is easy to write new
constructs without complexifying the whole language.
 
Conceptually then, a compiler is a source of syntactic and grammatical
EVENTS.
 
The automata starts in the null state, and its state is governed by the
text written in the source code.
 
A series of events is generated by the compiler. For instance:
 
Start struct declaration
End struct declaration
 
Constructors / Destructors belong here.
 
Start statement
End Statement
 
A profiler could subscribe to those events, and generate code to measure
the time the processor spent executing that statement
 
A debugger could generate code to be passed control if doing single
stepping.
 
 
Start function/method definition
End function/method definition
 
And many other events the compiler user can meaningfully use in the
application they are writing. Lambdas? Of course. If you need them
you use one of the language libraries around. Those libraries subscribe
to compiler events and generate code for you to do lamndas, and many
other quite interesting software constructs.
 
The core language stays fixed, the text is portable. Libraries are less
portable, and sophisticated software constructs have a price. But it is
again the user that decides if he wants the extra complexity of writing
and mainting that kind of code. New features are introduced individually
in some installations and people gain experience using them.
 
After some years of usage and if the authors want it, libraries would
enter the Boost library and become semi-official, with lambdas, regular
expressions, closures, what have you. This language libraries would hang
their code in specific events generated by the compiler and would write
either:
 
Core language to be compiled, inserted into the text stream at the call
point
 
or
 
Assembler to be inserted at the exact point of the event firing into the
object code stream.
 
Maybe more on this later
 
This is one of the
> reasons why nullptr/nullptr_t was added to the language. Overloading
> on both of these types as the only difference in the signature is
> going to be surprising unless you static_cast<> appropriately.
 
Of course. It is impossible for the automata to disambiguate the two
meanings since it has no notion of "meaning". It is the programmer
that gives any meaning here, and in this case it could be required.
 
Ian Collins <ian-news@hotmail.com>: Aug 15 07:23AM +1200

On 08/15/16 03:23 AM, Manfred wrote:
> appear not to be irrelevant (my gcc always outputs X! by the way), this
> confirms the complexity of the language, IMHO. Meaning that the original
> cleanliness of the language risks to get polluted by newer "improvements"
 
Which compilers are they?
 
--
Ian
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 14 09:08PM +0100

On Sun, 14 Aug 2016 19:06:15 +0200
 
> The example I gave is just 12 lines of C++!
 
> It is not the sheer size of the example, it is just that humans can't
> follow the rules!
 
Every language has its corner cases. It is a necessary consequence of
writing rules.
 
Your example is highly artificial. No one in their right minds would
write code of that kind for a meaningful purpose, and I am certainly not
going to spend the time reaching a view about which of the views
expressed is correct (although I thought your original appeal to
authority in the guise of "the chief developper of clang (sic)" somewhat
amusing).
 
You are a long standing poster to this group perennially making posts
adverse to C++. That's fine, you have your axe to grind and you are
entitled to your opinion. C is your preferred language. Stick to it.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 14 09:28PM +0100

On Sun, 14 Aug 2016 20:58:24 +0200
jacob navia <jacob@jacob.remcomp.fr> wr
> Let's make the compiler itself PROGRAMMABLE. Let's design a simpler
> language but with a programmable compiler where it is easy to write
> new constructs without complexifying the whole language.
 
There is already a language group which will do that for you, namely
the lisps. I prefer the scheme dialect, which has hygienic macros. It
is there: instead of your talking, get coding. I will trade macros with
you if you really want.
 
C++ is not a homoiconic language, and it is pointless complexifying it
to try to make it so. Neither for that matter is C, whose macro system
is totally pathetic. C++ has to carry the C baggage with it, for
better or for worse (mainly for worse).
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 10:52PM +0200

Le 14/08/2016 à 22:08, Chris Vine a écrit :
 
> Every language has its corner cases. It is a necessary consequence of
> writing rules.
 
True. But most language programmers can identify those corner cases and
answer a simple answer to them.
 
Too many rules to learn but heart provoke languages that are obese.
 
Obsesity is a consequence of a lack of restrain.
 
> expressed is correct (although I thought your original appeal to
> authority in the guise of "the chief developper of clang (sic)" somewhat
> amusing).
 
Yes the whole is very amusing. I get a kick with all that for sure.
 
And that guy is a nobody of course. And the fact that he says (and a
user in this discussion proved) that there is a problem with the rules
it is of no importance since:
 
> You are a long standing poster to this group perennially making posts
> adverse to C++.
 
Yes, I think the complexity of that language that I have to maintain is
a horror. Fortunately it exists of course, I am not against c++ since it
as source of revenue for me.
 
But sometimes I post in this group because I see the whole boat go into
such extremes that is... yes, amusing. That is the right word.
 
That's fine, you have your axe to grind and you are
> entitled to your opinion. C is your preferred language. Stick to it.
 
Of course I will stick to it. There is no question about that. But at
work I should maintain those horrors you see?
 
I have to understand why that crashes now when I recompiled the code
without changing anything. Then I *have* to know c++ and I start
sometimes talks in this group.
 
I even try to impromve my c++ skills by looking at c++ conferences,
videos, etc. And I presented that case brought by the speaker for the
clang group in that conference. Of course he is wrong, he is a nobody,
and he is not a lead developer but a beginner saying nonsense.
 
In any case that guy knows MUCH MORE c++ than me
 
:-)
 
jacob
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 14 09:55PM +0100

On Sun, 14 Aug 2016 22:52:02 +0200
> [drivel snipped]
 
You are still missing the point. Your example is highly artificial.
No one in their right minds would write code of that kind for a
meaningful purpose, and I am certainly not going to spend the time
reaching a view about which of the views expressed is correct.
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 11:08PM +0200

Le 14/08/2016 à 22:55, Chris Vine a écrit :
> jacob navia <jacob@jacob.remcomp.fr> wrote:
>> [drivel snipped]
 
> You are still missing the point. Your example is highly artificial.
 
 
Of course not!!!!!!!
 
That is a condensate of a problem that will appear in a huge program
where conceptually those 12 lines are dispersed in several different
files across several classes and templates and what have you!!!!!
 
> No one in their right minds would write code of that kind for a
> meaningful purpose,
 
THAT IS A MINIMAL EXAMPLE OF THE PROBLEM MAN!
 
Please turn on the brain before posting!
 
 
A "minimal example" in compiler parlance, is a very small code snippet
that highlights a problem that could be dispersed in several different
locations!
 
> and I am certainly not going to spend the time
> reaching a view about which of the views expressed is correct.
 
Of course not. If you do not feel like not doing it do not do it!
 
But then just keep silent since you have nothing to say and the only
thing that you can say is that I am just speaking
 
"drivel"
 
that can be ignored, without engaging a single argument or technical point
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 14 10:15PM +0100

On Sun, 14 Aug 2016 23:08:05 +0200
jacob navi
> THAT IS A MINIMAL EXAMPLE OF THE PROBLEM MAN!
 
Hot air. It isn't a problem.
 
I'll call you. Give me real code you might actually want to write for
a meaningful purpose where this is a live issue. Post it to a pasting
service if you think that would be better. If you could explain what
result you were expecting and why it didn't deliver it, and how it
relates to the code you posted, that would help also.
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 11:17PM +0200

Le 14/08/2016 à 22:28, Chris Vine a écrit :
> There is already a language group which will do that for you, namely
> the lisps. I prefer the scheme dialect, which has hygienic macros.
 
Macros are expanded in their position in the program text. They aren't
called automatically by the compiler system when an EVENT (syntactic or
similar) fires.
 
Is like the signal/slot paradigm in windows programming. You are just
not even understanding the change that means a stream of compiler EVENTS
where you can change the language by adding special syntax and ad hoc
syntax within an application context. I mentioned several examples in my
post.
 
To all that you have nothing to say. It suffices to say:
 
<quote>
C++ is not a homoiconic language, and it is pointless complexifying it
to try to make it so.
<end quote>
 
Then we have the situation where many constructs like lambdas, closures,
and other lisp features are added to the *whole* language instead of
being part of a LIBRARY!
 
There is then a monolithic compiler and an increasing unreadable
language that emerges.
 
The concept of language LIBRARIES where a adapted syntax and code
generation are unified in a standard context and added to some users and
tested for years without being IMPOSED to all users of the language!
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 09:35PM +0200

Le 14/08/2016 à 17:32, Mr Flibble a écrit :
> C++ is a complicated language? No shit. Have you only just realized this?
 
No, since quite a long time actually.
 
> C++ was complicated before C++98 so imagine how complicated it is now.
 
I do not need to imagine it. Just look at it.
 
> However, paradoxically, C++'s complexity can result in simpler C++
> PROGRAMS which is a GOOD THING (tm).
 
Yes, but the problem is brittleness. Without continuous maintenance any
small thing that changes and unrelated code to the point of failure
could go wrong.
 
Finding the point of failure becomes extremely complex for the unaware
maintenance programmer.
 
For instance (in another message) you say that
 
<quote>
My new GUI library "neoGFX" doesn't use signals and slots as signals and
slots are an old solution to an old problem. Instead all we need to do is:
 
button1.clicked([](){...});
 
<end quote>
 
Are you sure? The new syntax does really replace neatly the code for
slots/signals? An object (a button) that sends signals was an analogy
quite easy to follow.
 
What does the new syntax bring to the code actually? Because apart for
being very small, it looks very unreadable to me.
 
Of course I am not a C++ head but I would prefer the old slot/signal
framework. It is a proven analogy, many libraries use it, and code
written like that has a KNOWN structure, callbacks, etc. Yours is a new
way of doing the same thing, what can be very clever but for the
maintenance programmer is yet another pain in the ass really.
 
Sorry but I couldn't resist
 
:-)
 
 
 
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 09:10PM +0100

On 14/08/2016 20:35, jacob navia wrote:
> maintenance programmer is yet another pain in the ass really.
 
> Sorry but I couldn't resist
 
> :-)
 
If you have a problem with C++ lambdas then I am sorry but modern C++ is
simply not your cup of tea so you should try another language.
 
/Flibble
jacob navia <jacob@jacob.remcomp.fr>: Aug 14 10:39PM +0200

Le 14/08/2016 à 22:10, Mr Flibble a écrit :
> If you have a problem with C++ lambdas then I am sorry but modern C++ is
> simply not your cup of tea so you should try another language.
 
I am just insunuating very perfidiously your honor that the "old"
signal/slot paradigm is a better idea for a windowing system as your
extremely complicated syntax.
 
It assumes the existence of a button OBJECT that sends signals to
subscribers. This is the base of many windowing systems and is a well
known paradigm.
 
You did not show any code and I think that the new syntax doesn't bring
anything new or innovative but does the same thing in a more complicated
way.
 
Specifically I asked what your new syntax brings for the application (in
this case a windowing system).
 
Please argue man, instead of throwing around completely empty sentences like
 
<quote>
modern C++ is simply not your cup of tea so you should try another language.
<end quote>
 
"Modern C++ is like that" you say. As the signal slot paradigm that is
working since years perfectly is suddenly "old" and must be replaced by
"modern" constructs that are smaller, and more complicated to read.
 
You did NOT answer why this new construct is in any way better than the
"old". The only thing that you said is that is an "old problem". Well
yes, hanging code an events is the essence of event oriented
programming, and that is in use since ages.
 
And this is a typical case where this fanatism of the "new" and the
piling up of new and newer stuff that nobody follows any more.
 
I am still waiting for an answer:
 
WHAT IS THE ADANTAGE of the new syntax in terms of software engineering?
 
(Besides being more incomprehensible)
 
Thanks in advance for your explanations.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 14 10:01PM +0100

On 14/08/2016 21:39, jacob navia wrote:
 
> WHAT IS THE ADANTAGE of the new syntax in terms of software engineering?
 
> (Besides being more incomprehensible)
 
> Thanks in advance for your explanations.
 
My solution with lambdas is actually simpler than signals and slots.
 
I can only repeat my earlier reply: if you find C++ lambdas too
complicated then I suggest you use a different programming language.
 
/Flibble
David Brown <david.brown@hesbynett.no>: Aug 14 11:13PM +0200

On 14/08/16 23:01, Mr Flibble wrote:
 
 
> I can only repeat my earlier reply: if you find C++ lambdas too
> complicated then I suggest you use a different programming language.
 
> /Flibble
 
It is worth noting that in languages that have had lambdas for longer
than C++, such as Python and Javascript, lambdas are a very popular way
to handle events such as button presses. The don't handle every
possibility, but for a good many common cases they work very well.
 
So IMHO, using lambdas as the base for event systems in a new gui
framework is a good idea, demonstrated by experience in other frameworks
and other languages.
Ramine <ramine@1.1>: Aug 14 04:42PM -0400

Hello.....
 
 
You have seen me in my previous post reasonning about Trasactional memory..
 
But there is still another big problem with Transactional memory..
 
The problem is with realtime critical systems, to be able
to use Transactional memory in realtime crtitical systems, you
have to be able to calculate precisely the latency and the throghuput,
but since in transactional memory you can get conflicts that can
get you in the worst case performances that are not good, so
transactional memory is not best suited for realtime critical systems
that wants to optimise more the performance and guaranty a scaling that
is decent, so here comes again the way of locks that can get you a more
decent performance with a more predictable performance that scales more,
so locks are best suited for realtime critical systems when the
characteristic of performance is taken alone.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Aug 14 04:22PM -0400

Hello,
 
 
I must be precise in my reasonning about Transactional memory..
 
To avoid race conditions the transactions must wrap the parallel
part and the serial part.
 
And if the serial part of the transactions is more smaller you can
get a conflict and this will get you a poor performance.
 
But if the serial part is small , so the chance to get a conflict is
small, so Transactional memory works best and scales best with smaller
serial parts.
 
So Transactional memory since it avoids race conditions and deadlocks
is the right tool for applications that scales well and that have
smaller serial parts.
 
Locks are best suited for more bigger serial parts.
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: Aug 14 03:50PM -0400

Hello.....
 
 
I have read that Transactional memory avoids race conditions
and deadlock etc.
 
But i have thought about Transactional memory and i think
there is a big problem with it, because if you want to avoid
race conditions, the transaction must wrap a bigger part including
the parallel part and the serial part, but this way has its big problem
and is not good, because if there is a conflict on
the serial part, the transactions will roolback and will be run serially
and this will get you a poor performance that look like the serial
performance, but to avoid this big problem with transactional memory you
have to make the transaction small and avoids to include a maximum of
the parallel part, but this way is a big problem and
is not good, because you can risk to include race conditions that
will ressemble the problem that you get with the way of using locks.
 
 
So transactional memory in my humble opinion is not the right tool.
 
 
 
 
Thank you,
Amine Moulay Ramdane.
Joseph Hesse <joeh@gmail.com>: Aug 14 11:01AM -0500

This is a simplification of my problem.
The array Values in class Algorithm will be populated by the constructor
reading from a data file.
Once the array Values is populated it never changes, hence the const in
"const int d;"
The problem is how can I give values to Values[i].d?
I probably have a bad design, nevertheless in the non-simplified version
it reflects the real problem.
 
Thank you, Joe
 
==========================================================
#include <iostream>
#include <string>
using namespace std;
 
class Data
{
private:
const int d;
// ...
public:
Data () : d(0) {} // so we don't have junk in d
// ...
 
friend class Algorithm;
};
 
class Algorithm
{
private:
Data Values[100]; // no need to use vector since 100 will never change
// ...
public:
// ctor opens data file and reads ints into Values[i].d
Algorithm(const string & DataFile); // code not shown
// ...
};
==========================================================
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)