Tuesday, July 4, 2017

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

Christiano <christiano@engineer.com>: Jul 04 07:11PM -0300

The book PPP2[1] presents the following code, Page 620 (2nd edition, fourth print):
 
Link* Link::insert(Link* n) // insert n before this object; return n
{
if (n==nullptr) return this;
if (this==nullptr) return n;
n–>succ = this; // this object comes after n
if (prev) prev–>succ = n;
n–>prev = prev; // this object's predecessor becomes n's predecessor
prev = n; // n becomes this object's predecessor
return n;
}
 
What interested me in this code was exactly this part:
 
if (this==nullptr) return n;
 
So I searched about "null comparing this" using search engine.
 
This website..
https://www.viva64.com/en/b/0226/
...says:
"First of all according to the C++ standard (it follows from the paragraph 5.2.5/3 of the standard ISO/IEC 14882:2003(E)), calling any nonstatic
method of any class through a null-pointer leads to undefined behavior. "
 
But the ISO/IEC 14882:2003, § 5.2.5.3 says:
If E1 has the type "pointer to class X," then the expression E1->E2 is converted to the equivalent form
(*(E1)).E2; the remainder of 5.2.5 will address only the first option (dot) [59] . Abbreviating object-
expression.id-expression as E1.E2, then the type and lvalue properties of this expression are determined as
follows. In the remainder of 5.2.5, cq represents either const or the absence of const; vq represents
either volatile or the absence of volatile. cv represents an arbitrary set of cv-qualifiers, as defined
in 3.9.3.
[59] Note that if E1 has the type "pointer to class X", then (*(E1)) is an lvalue.
 
That is, the standard does not say exactly "calling any nonstatic method of any class through a null-pointer leads to undefined behavior".
And (*(E1)) being a lvalue when E1 is null is not a problem IF THE PROGRAMMER IS AWARE OF WHAT HE IS DOING.
 
What I'm trying to say is exactly:
 
The "Comparing 'this' Pointer to Null as an undefined behavior" is a MYTH which is not based on Standard.
 
You can see this myth in several websites:
https://www.google.com/#q=this+null+c%2B%2B
 
Following this reasoning, Stroustrup is correct, g++ is correct [2], and Clang is correct [3].
And the standard shouldn't forbid it because it has been used correctly for a long time without problems so that it would be much fairer to be
interpreted as a technique.
 
What do you think about it? Please comment if you disagree or agree and the reason.
 
[1] http://stroustrup.com/Programming/
 
[2] testing test.cpp (code bellow) using g++
$ g++ test.cpp -std=c++11
$ ./a.out
Test
$
 
[3] testing test.cpp (code bellow) using clang
$ CC test.cpp -std=c++11
$ ./a.out
Test
$
 
///////// test.cpp: /////////////
 
#include <iostream>
 
using namespace std;
 
struct X
{
void f()
{
cout << "Test" << endl;
 
}
};
 
int main()
{
X *x = nullptr;
 
x->f();
 
return 0;
}
/////////----------- eof
Marcel Mueller <news.5.maazl@spamgourmet.org>: Jul 04 10:52PM +0200

The following code demonstrates the issue:
 
 
#include <stdio.h>
 
template <typename ...A>
struct MsgTemplate
{ int ID;
const char* Text;
};
 
// works
constexpr const struct
{ const MsgTemplate<const char*> SOMETHING_WENT_WRONG =
{ 1001, "Something went wrong: %s" };
// more templates ...
} Templates;
 
 
struct MyClass
{
// does not work
constexpr static const struct
{ const MsgTemplate<const char*> SOMETHING_WENT_WRONG =
{ 1001, "Something went wrong: %s" };
// more templates ...
} Templates;
};
 
template <typename ...A>
inline void Message(const MsgTemplate<A...>& tpl, A... a)
{ printf("Message %i: ", tpl.ID);
printf(tpl.Text, a...);
putchar('\n');
}
 
int main()
{
Message(Templates.SOMETHING_WENT_WRONG, "some details");
Message(MyClass::Templates.SOMETHING_WENT_WRONG, "some details");
return 0;
}
 
 
While ::Templates works as expected MyClass::Templates does not compile.
 
gcc complains:
 
test9.cpp:22:5: error: constexpr static data member 'Templates' must
have an initializer
} Templates;
 
 
I tried several variants, with a (trivial) constexpr constructor, with
an initializer and so on but nothing worked.
 
What is missing?
 
 
Marcel
Dombo <dombo@disposable.invalid>: Jul 04 06:43PM +0200

Op 03-Jul-17 om 21:58 schreef Öö Tiib:
> Usually automatic variable or direct data member, 'std::optional',
> 'std::array', 'std::vector' or 'std::make_unique' are better, safer and
> more efficient to use at that spot.
 
Let me rephrase the question (see the post I was replying to); why
prefer malloc() over 'new'?
 
I rarely use 'new' in C++ code and I cannot remember that last time I
used malloc() in C++ code, so I wonder why someone would ask how to use
malloc() in a C++ newsgroup?
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 04 07:31PM +0100

On Tue, 4 Jul 2017 18:43:18 +0200
Dombo <dombo@disposable.invalid> wrote:
[snip]
> Let me rephrase the question (see the post I was replying to); why
> prefer malloc() over 'new'?
 
I generally use malloc() when I want uninitialized memory, say in which
objects are to be constructed with placement new. You could use
operator new instead, or even the new[] expression with an array of char
[1], but malloc() seems more "normal" to me.
 
Chris
 
[1] The effect would certainly be the same as malloc() for operator new.
I think the same is true of the new[] expression in that I think that
has to be aligned for any fundamental type, but I would need to look it
up to be sure.
rami18 <coco@coco.com>: Jul 04 10:18AM -0400

Hello,
 
 
So from now on i will not post in this forum.
 
 
Thank you,
Amine Moulay Ramdane.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 04 08:06AM -0700

On Tuesday, July 4, 2017 at 10:18:33 AM UTC-4, rami18 wrote:
> So from now on i will not post in this forum.
 
You've said that so many times, Amine. My suggestion is you stop saying
it and just start doing it, because you're demonstrating by your actions
that your words actually mean nothing. Show people by solid actions, and
not just hollow words.
 
Thank you,
Rick C. Hodgin
rami18 <coco@coco.com>: Jul 04 08:45AM -0400

Hello....
 
 
Read this:
 
PERT (The program evaluation and review technique) for Delphi and
Freepascal was updated to version 1.2..
 
 
I have just taken a look at the following statistical PERT:
 
https://www.pluralsight.com/blog/it-ops/statistical-pert-estimates
 
And i think you don't need it, because i have just added the following
function to my PERT library:
 
function InvNormalDist(const Mean, StdDev, PVal: Extended; const Less:
Boolean): Extended;
 
For InvNormalDist(), you pass the best estimate of completion time to
Mean, and you pass the critical path standard deviation to StdDev, and
you will get the probabilities of the value PVal, and when Less is TRUE,
you will obtain a cumulative probability, so you don't need statistical
PERT, please look at my test1.pas example inside the zip file that shows
how to use my PERT library,
 
Also my PERT library uses a CPM algorithm that uses Topological sorting
to render CPM a linear-time algorithm for finding the critical path of
the project, so it's fast.
 
And i have also included a 32 bit and 64 bit windows executables called
PERT32.exe and PERT64.exe (that take the file, with a the file format
that i specified above, as an argument) inside the zip, it is a very
powerful tool, you need to compile CPM.java with compile.bat before
running them.
 
Now my PERT library is more professional.
 
You can download the new version 1.2 of my PERT library from:
 
https://sites.google.com/site/aminer68/pert-the-program-evaluation-and-review-technique-for-delphi-and-freepascal
 
 
Thank you,
Amine Moulay Ramdane.
rami18 <coco@coco.com>: Jul 04 08:45AM -0400

Hello,
 
 
I have posted here because i have also included a 32 bit and 64 bit
windows executables called PERT32.exe and PERT64.exe (that take the
file, with a the file format that i have specified , as an argument)
inside the zip, it is a very powerful tool.
 
 
 
Thank you,
Amnine Moulay Ramdane.
rami18 <coco@coco.com>: Jul 04 09:20AM -0400

Hello..........
 
I correct:
 
function InvNormalDist(const Mean, StdDev, PVal: Extended; const Less:
Boolean): Extended;
 
For InvNormalDist(), you pass the best estimate of completion time to
Mean, and you pass the critical path standard deviation to StdDev, and
you will get the length of the critical path of the probability PVal,
and when Less is TRUE, you will obtain a cumulative probability.
 
You can download the new version 1.21 of my PERT library from:
 
https://sites.google.com/site/aminer68/pert-the-program-evaluation-and-review-technique-for-delphi-and-freepascal
 
 
Thank you,
Amine Moulay Ramdane.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 04 03:11PM +0100

On Tue, 4 Jul 2017 08:45:55 -0400
> windows executables called PERT32.exe and PERT64.exe (that take the
> file, with a the file format that i have specified , as an argument)
> inside the zip, it is a very powerful tool.
 
You have previously been asked to go away. Why cannot you do as you
are asked?
 
This newsgroup is concerned with C++. It is not concerned with windows
binaries. You are completely off topic.
 
I have previously also explained to you that you are a hopeless fuckwit.
Apart from the fact that your posting has nothing to do with C++, which
is bad enough, having to correct it two days running shows that your
code is worthless crap which no one is ever going to use.
rami18 <coco@coco.com>: Jul 04 10:17AM -0400

Hello,
 
 
So from now on i will not post in this forum.
 
 
Thank you,
Amine Moulay Ramdane.
bruce56@topmail.co.nz: Jul 04 02:27AM -0700

On Monday, June 12, 2017 at 10:16:32 PM UTC+8, David Brown wrote:
> Linux or Windows). Versions of icc are on the godbolt site, which
> suggests that at least those versions could be freely used (or Mr.
> Godbolt should probably disable them).
 
You can find compiler tar files occasionally on university or supercomputer
websites, if you know the filename to search for. Doesn't imply that they
are free - you still need a license file or serial number to activate.
"Öö Tiib" <ootiib@hot.ee>: Jul 03 04:32PM -0700

On Tuesday, 4 July 2017 00:04:22 UTC+3, peter koch wrote:
> complex.hpp, (the struct) complex_tio.hpp (std::stream functions
> including parsing) and complex_gui.hpp (includes gui-code). This is not
> a bad solution, I think, but I would like to also hear YOUR opinion. ;-)
 
Your "complex" sounds like something whose nature is entirely undisclosed
so you seem to hope that there is silver bullet that covers everything?
There are no silver bullet solutions so do how you please, but I can sure
tell how I organize those.
 
When I need to stream objects "Whatever" to/from somewhere then I typically
make those constructible from and convertible to streamable format/document
class that I use in project, for example JSON. That capability means 2
functions to declare so I would likely declare those in "Whatever.h".
Same we can say about streaming it directly (have operator<< for ostream
and operator>> for istream). Your situation may be different ... or why
to have separate header for 2 function declarations?
 
About GUI however I consider every view or widget as separate class and
see those quite non-tightly related to each other and to data class
they represent.
For example if there is "list item", "table cell", "tool tip"
and "edit dialog" that represent "Whatever" in one or other part of GUI
then I would most likely have separate header ("WhateverListItem.h",
"WhateverTableCell.h", "WhateverToolTip.h" and "WhateverEditDialog.h") for
each of those and possibly in separate directories (and even modules)
from "Whatever.h" and each other. Again your situation may be different
and even GUI concept may be different, how can I know.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 04 03:17AM +0200

On 03-Jul-17 11:04 PM, peter koch wrote:
 
> This structure is fully streamable, so you can both stream it out
> (which is more or less trivial) and stream it in (which is
> non-trivial, requiring a parser - implemented in boost::spirit).
 
Yout way of presenting this is as if you think of the serialization
functionality as very strongly connected to, or even part of, the class.
 
That's the way I think of it too.
 
 
> Complex can also be dispalyed on a GUI. Again, the code is rather
> complex and heavily templated.
 
I think of that as separate /client/ code.
 
 
> including parsing) and complex_gui.hpp (includes gui-code). This is
> not a bad solution, I think, but I would like to also hear YOUR
> opinion. ;-)
 
The serialization functionality can be useful in the GUI code. The GUI
functionality cannot reasonably be useful in the serialization code. So
these functional areas are not, IMO, on an equal footing.
 
So I would not put the GUI code (a view?) along with the rest.
 
I would split view and model also wrt. to projects file/directory
structure, with serialization as part of the model, and try to ensure
that the model supplies all the info & functionality that the view needs
to present it, edit it, whatever.
 
 
Cheers & hth., (just my 2c)
 
- Alf
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)