Friday, March 23, 2018

Digest for comp.lang.c++@googlegroups.com - 17 updates in 5 topics

Ian Collins <ian-news@hotmail.com>: Mar 24 09:23AM +1300

On 03/22/2018 11:53 AM, Richard wrote:
>> excellent IDE.
 
> I've had very positive experiences with CLion on linux. I haven't
> tried VS code on linux, though. Does it have any refactoring support?
 
It does have refactoring support across a range of languages. I haven't
tried it myself, but I am tempted to give it a go based on feedback from
my colleagues.
 
--
Ian.
Vir Campestris <vir.campestris@invalid.invalid>: Mar 23 09:20PM

On 21/03/2018 22:57, Mr Flibble wrote:
 
> Alf is talking bollocks as usual.  Of course trailing return type is to
> be used rarely not routinely.
 
Alf rarely talks bollocks. But...
 
In this case however I agree with you. I'm working in a codebase that's
evolved over years - parts of it predate C++ entirely - and the leading
return value syntax was all that was available. So it's used everywhere.
 
Changing a few functions to a different syntax would mean breaking the
house style, and would require a slight interruption in my chain of
thought every time I met one.
 
I also avoid auto. If I see this variable auto foo I have to move the
mouse onto it to let the IDE have a think and tell me what it really is.
Which is slower than just declaring it properly. Sometimes of course
(type of a lambda for example) auto is unavoidable.
 
Andy
legalize+jeeves@mail.xmission.com (Richard): Mar 23 10:30PM

[Please do not mail me a copy of your followup]
 
Vir Campestris <vir.campestris@invalid.invalid> spake the secret code
 
>Changing a few functions to a different syntax would mean breaking the
>house style, and would require a slight interruption in my chain of
>thought every time I met one.
 
There is a use case for trailing return type but it has to do with
template functions where the return type depends on the types of the
arguments, e.g.
 
template <typename T, typename T>
auto add(T t, U u) -> decltype(t + u)
{
return t + u;
}
 
...other than those specific use cases for which it was intended, I
find the arguments for trailing return type unconvincing. It's extra
tokens to express trailing return type (generally a bad idea IMO) and
in all the years that C++ has been around "leading return types!"
hasn't been a community complaint. Adopting it wholesale is a
solution in search of a problem IMO. Appealling to Herb Sutter
doesn't convince me; he's not a god, he's a human being with an
opinion. I'm not persuaded by his arguments.
 
The case where trailing return type (e.g. above) is convenient and
useful are generally few and far between in any typical codebase, so
it doesn't make sense to flip the whole world upside down to conform
to these rare cases "for the sake of consistency".
 
This is why I say that I feel Alf's use of trailing return type feels
gratuitous and on any team is more likely to yield friction than
clarity when reading code.
 
My team's coding guidelines says to avoid auto unless it makes the
code easier to read, e.g.
std::vector<std::map<std::string,std::string>>::const_iterator is way
too verbose and auto is preferable here.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Ian Collins <ian-news@hotmail.com>: Mar 24 11:52AM +1300

On 03/24/2018 11:30 AM, Richard wrote:
> }
 
> ....other than those specific use cases for which it was intended, I
> find the arguments for trailing return type unconvincing.
 
Even in this case the trailing return is superfluous under C++ >= 14
rules :)
 
> code easier to read, e.g.
> std::vector<std::map<std::string,std::string>>::const_iterator is way
> too verbose and auto is preferable here.
 
Pretty much the same here, the iterator example is one where both auto
variables and trailing return types would be okay, but I still get some
push back with the trailing return usage...
 
--
Ian
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Mar 23 11:43AM -0700

Does anybody have any tools they use that are similar in ability
to compile and debug C++ projects, but do so faster than Visual
Studio?
 
I'm waiting about 1 second between single steps in source code.
I remote connected to a foreign server and it was faster there
over our LAN than it is here locally when I debug this particular
process.
 
In the alternative, does anybody have any ideas on how to make
Visual Studio 2015 or later go faster in debugging? It has a
great IDE, and edit-and-continue is excellent, but single-step
speed is slow enough I'm looking for another tool. If I can
correct my setup here so it goes faster, I'll be happy to try
these tools.
 
--
Rick C. Hodgin
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Mar 22 11:06PM -0700

On 3/22/2018 5:37 PM, Chris M. Thomasson wrote:
>> alignment provided by FastFlow allocators.
 
> That is a pretty bad design wrt using Michael&Scott like CAS-based
> queues, or any queue that needs deferred reclamation. Not good.
 
The distributed part is okay, but the CAS based queue deferred crap can
be dropped completely.
 
Bo Persson <bop@gmb.dk>: Mar 23 05:35PM +0100

On 2018-03-22 23:04, computer45 wrote:
 
> Mine "is" scalable , its throughput scales "linearly" with more cores
> and more threads. And it can be easily configured to be waitfree or
> lockfree or blocking.
 
So it might improve our understanding if you included a link to *your*
thesis, where all this is thoroughly explained.
 
 
 
Bo Persson
amoremessana@gmail.com: Mar 22 11:16PM -0700

On Friday, March 16, 2018 at 12:40:28 PM UTC+5:45, Christian Gollwitzer wrote:
> https://en.wikipedia.org/wiki/Virtual_function
> http://www.cplusplus.com/doc/tutorial/polymorphism/
 
> Christian
 
 
Thank you so much. These did help me develop a clearer theory in my head.
amoremessana@gmail.com: Mar 22 11:16PM -0700

On Saturday, March 17, 2018 at 3:57:01 AM UTC+5:45, bitrex wrote:
> a function that does something cool but it's the weekend and you don't
> really feel much like writing code so currently you can only kinda
> imagine it in your head
 
 
Thank you so much.
amoremessana@gmail.com: Mar 22 11:17PM -0700

On Friday, March 16, 2018 at 9:28:45 PM UTC+5:45, red floyd wrote:
> On 03/15/2018 10:05 PM, amoremessana@gmail.com wrote:
> > What are virtual functions? Could you please give an example?
 
> What textbook are you using that does not discuss them?
 
 
It's not the textbook does not discuss virtual functions. I just don't seem to be able to apply it in practical code.
amoremessana@gmail.com: Mar 22 11:20PM -0700

On Saturday, March 17, 2018 at 3:57:01 AM UTC+5:45, bitrex wrote:
> a function that does something cool but it's the weekend and you don't
> really feel much like writing code so currently you can only kinda
> imagine it in your head
 
Thank you so much.
James Kuyper <jameskuyper@verizon.net>: Mar 23 06:36AM -0400

>>> What are virtual functions? Could you please give an example?
 
>> What textbook are you using that does not discuss them?
 
> It's not the textbook does not discuss virtual functions. I just don't seem to be able to apply it in practical code.
 
What happens when you try to apply it in practical code? A specific
example would be helpful.
legalize+jeeves@mail.xmission.com (Richard): Mar 23 04:01PM

[Please do not mail me a copy of your followup]
 
amoremessana@gmail.com spake the secret code
 
>It's not the textbook does not discuss virtual functions. I just don't
>seem to be able to apply it in practical code.
 
I'd summarize it as: virtual functions are useful when you have
generic operations that apply to categories of objects, but each
object within the category has slightly different ways of
accomplishing the operation.
 
The classic example is a GUI framework containing a class hierarchy of
widgets. In other words there is some base class "Widget" and the
individual widget types derive from that:
 
class Widget { /* .... */ };
class CheckBox : public Widget { /* ... */ };
class ListBox : public Widget { /* ... */ };
class TextBox : public Widget { /* ... */ };
 
We want to draw widgets on the screen. Each widget does this slightly
differently:
 
- Checkbox widgets draw a little box with or without the check mark to
indicate the checked or unchecked state
- List box widgets draw the list of items. Selected items are drawn
with some sort of visual highlight to indicate the selection.
- Text box widgets draw the editable area in a distinct manner to
differentiate it from the background and render any text inside that
area.
- and so-on
 
From the perspective of a client of a widget, we don't care how it
draws. Most of the time, we don't even care what kind of widget it
is; we just want it to draw itself on the screen. So we typically
hold the widgets on a dialog as pointers to the base and invoke
the draw operation on the widgets through a pointer to the base:
 
class Widget {
public:
virtual void draw() = 0; // might not be abstract, depends on the design
/* .... */
};
class CheckBox : public Widget {
public:
void draw() override { /* draw CheckBox */ }
/* ... */
};
etc.
 
class Dialog
{
public:
// here, a Dialog is just holds a bag of Widgets. It is not a
// Widget itself (this is a design choice), so its draw is not
// virtual.
void draw()
{
for (auto w : m_widgets)
{
w->draw();
}
}
 
/* ... */
 
private:
std::vector<std::unique_ptr<Widget>> m_widgets;
};
 
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
wyniijj@gmail.com: Mar 23 01:19AM -0700

James R. Kuyper於 2018年3月23日星期五 UTC+8上午6時00分45秒寫道：
> mathematical formulas", and many uses of complex numbers don't involve
> calculations where those issues would be a problem.
 
> Does std::complex<T> address the same issue in any way, and if so, how?
 
[The Standard C++](old) I can refer says little about std::complex except
a list of basic protocols and semantic.
CX_LIMITED_RANGE pragma seems to me is for use before the birth of cabs()
...complex functions.
James Kuyper <jameskuyper@verizon.net>: Mar 23 06:31AM -0400


>> Does std::complex<T> address the same issue in any way, and if so, how?
 
> [The Standard C++](old) I can refer says little about std::complex except
> a list of basic protocols and semantic.
 
Which version of standard C++ are you referring to as "old"? I'm
primarily interested in what it says in the current version of the
standard, which I believe is C++2017. I use, as my reference for
C++2017, n4567.pdf, which was the last freely available draft version of
the standard before it became official.
I agree that the description of <complex> in section 26.4 does not seem
to address this question at all. In particular, I could not find any
occurrence of the words "overflow" or "underflow" or the string
"infinit" anywhere in that section. However, I wanted to find out if I
had missed something that's relevant.
 
> CX_LIMITED_RANGE pragma seems to me is for use before the birth of cabs()
> ...complex functions.
 
I've no idea what you mean by that. CX_LIMITED_RANGE was added to the C
standard in C99, the same version of the standard that added full
support for complex numbers, including complex function in <math.h> such
as cabs. CX_LIMITED_RANGE applies to arithmetic operations involving
complex values, and only to such operations.
wyniijj@gmail.com: Mar 23 06:31AM -0700

James Kuyper於 2018年3月23日星期五 UTC+8下午6時31分32秒寫道：
> support for complex numbers, including complex function in <math.h> such
> as cabs. CX_LIMITED_RANGE applies to arithmetic operations involving
> complex values, and only to such operations.
 
.....
I briefly checked n4859.pdf, no mention of CX_LIMITED_RANGE, nor related
things. The link might be useful:
https://stackoverflow.com/questions/42045291/does-icc-satisfy-c99-specs-for-multiplication-of-complex-numbers
James Kuyper <jameskuyper@verizon.net>: Mar 23 11:29AM -0400

>> had missed something that's relevant....
> I briefly checked n4859.pdf, no mention of CX_LIMITED_RANGE, nor related
> things.
 
Yes, I know that - checking to see whether C++ provided the same pragma
was one of the first things I did. I looked for something else in the
C++ standard that addresses the same issue that CX_LIMITED_RANGE
addresses for C. I didn't find anything, but I was hoping that someone
might point out something I'd missed.
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)