Wednesday, June 24, 2015

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

David Brown <david.brown@hesbynett.no>: Jun 24 09:30AM +0200

On 23/06/15 23:26, Richard wrote:
> <JbSdnWA9G5G1XBTInZ2dnUU78L2dnZ2d@brightview.co.uk> thusly:
 
>> VS is an IDE. I can't find anything nearly as good on Linux.
 
> Try CLion. It's the first viable competitor I've seen to VS so far.
 
What does CLion give you that Eclipse does not? I had a little look at
their website, and it appeared to be a reasonable enough IDE - but I saw
nothing to make me think that it stood out in any way.
scott@slp53.sl.home (Scott Lurndal): Jun 24 01:06PM

>found myself being more productive at navigating through and
>manipulating my code. The only thing that's come close to being that
>productive is CLion and it barely just came out.
 
I cannot argue with your experience. I can, however, rejoice
that I need never work in a Windows shop.
legalize+jeeves@mail.xmission.com (Richard): Jun 24 06:37PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
 
>What does CLion give you that Eclipse does not? I had a little look at
>their website, and it appeared to be a reasonable enough IDE - but I saw
>nothing to make me think that it stood out in any way.
 
I've not attempted Eclipse for C++ development, but I did give it a try
for about a month doing Java development. I found it very frustrating.
Every member of my team that was using eclipse was using a slightly
different bundle of eclipse. None of the regular eclipse users could
explain to me how to fix any of the problems I was encountering, none
of them could explain to me how the IDE worked from a conceptual level,
and if they did have solutions to a problem, each person had a
different solution because they were all using a different "eclipse".
Most of the time their explanation (when they had one) went like this:
"I don't know why it does that, but here's the hammer I use to beat it
back down". Of course, their hammers didn't work on the bundle of
eclipse that I had downloaded.
 
After about a month of frustration, I decided to try out IntelliJ.
WOW. The difference was night and day. Suddenly, I didn't have to
fight with the IDE anymore, I could just work on my code and get things
done. Yes, the key bindings were different from what I was used to
(Visual Studio), but after learning the default key bindings I found I
was just as productive on Java code in IntelliJ as I was in C++ with
Visual Studio. Even better, IntelliJ had very good refactoring, code
navigation support and "quick fixes" for things that it noticed about
my code using static analysis. About the only thing I missed from VS
was its window docking system. The one in IntelliJ is not very
intuitive for me and isn't as easy to configure as Visual Studio.
 
Why am I mentioning all this? Because IntelliJ is the IDE foundation
on which all other IDEs from JetBrains are built. CLion is an
IntelliJ-based IDE. The default keyboard shortcut scheme is the same,
the docking window system is the same, the preferences and settings
system is the same, etc. CLion provides quite a good bit of
refactoring support and the refactorings are well implemented and
reliable. They have scored the highest score on my refactoring test
suite for Rename, for instance.
<https://github.com/LegalizeAdulthood/refactor-test-suite>
 
I've used CLion on linux for several months before their final release
and I've continued to use it since. I mostly do my clang contributions
on linux using CLion.
 
About the only advantage Eclipse has over CLion is that it's free.
However, the increased productivity with CLion more than makes up for
its cost, unless you don't value your time very highly. There was a
point in my life where I had more time than money and I probably would
have chosen Eclipse myself at that point. However, now I'm in the
reverse situations: I'm more limited by time than money, so my time is
very precious to me. I wouldn't want to do any unix C++ development
work with anything but CLion at this point. Although it currently
requires CMake for its project system, they are working on supporting
other project systems (probably something Makefile based) in future
releases. The productivity gains are enough that I'd be willing to
convert my build to CMake *just* to use CLion.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
legalize+jeeves@mail.xmission.com (Richard): Jun 24 06:45PM

[Please do not mail me a copy of your followup]
 
Noob <root@127.0.0.1> spake the secret code
 
>> [Please do not mail me a copy of your followup]
 
>Well, I may just have to start mailing you a copy of all my
>Usenet followups.
 
My KILL file has plenty of room and so does my procmail filter.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
David Brown <david.brown@hesbynett.no>: Jun 24 10:57PM +0200

On 24/06/15 20:37, Richard wrote:
> other project systems (probably something Makefile based) in future
> releases. The productivity gains are enough that I'd be willing to
> convert my build to CMake *just* to use CLion.
 
Thanks for writing that.
 
I can't answer for Java - I have never worked with Java development. I
am only thinking of C and C++ here.
 
When I first used eclipse, a good number of years ago, I found it slow,
clunky, and hard to figure out. It has improved a great deal since then
(helped also by faster computers with more memory). There are a few
things I find painful, such as updates - but I rarely feel the need to
update it anyway.
 
I can't relate to the problems you have been having with Eclipse - I
simply haven't seen that kind of frustration. I find it works well for
my C and C++ work (mostly C), and I can navigate fairly quickly through
the code. I haven't had much use for refactoring, so I don't know how
Eclipse's refactoring compares to other IDEs. But it does a good job of
editing, makes good suggestions for completing identifiers, is helpful
in formatting, checks and corrects my spelling, and quickly marks
potential errors in the code. It also works well with makefiles (I
almost always work with external makefiles, not the IDE's project
manager) and interprets the error messages from the compiler. Debugging
also works well enough, connecting to my embedded systems using openocd
or other proxies and interfaces.
 
I also use Eclipse for Python development and LaTeX documentation. It
is important to me to be able to have multiple copies of the IDE open at
the same time, with different workspaces - Eclipse handles that without
problem.
JiiPee <no@notvalid.com>: Jun 25 12:16AM +0100

On 13/06/2015 10:32, Christian Gollwitzer wrote:
 
> private:
> int value = 5;
> };
 
A bit better would be :
 
int value{5};
 
?
With int it does not make difference but with an class it might.
JiiPee <no@notvalid.com>: Jun 25 12:18AM +0100

On 13/06/2015 18:33, Noob wrote:
> 40 methods
> };
 
> Would it still look simple then?
 
40 methods in a class ? :) maybe a bit too much... there should be only
a few in a class normally?
woodbrian77@gmail.com: Jun 24 03:35PM -0700

Greetings to Alf.
 
By the grace of G-d, I'm able to devote more time than ever now
to the C++ Middleware Writer. So your thoughts on topics in this
thread are appreciated.
 
I've been thinking about changing things in my middle tier.
Currently I use a file to store the time of the most recent
update to a group of files. When a request from the front
tier arrives, I take the following steps:
 
open a file
read from the file
lseek back to beginning of file
write to the file
close the file
 
The first two of those steps happen prior to forwarding
the request from the middle to the back tier. The last
three steps happen after the middle tier has received
the reply from the back tier.
 
I've thought about an optimization where I'd cache open
file descriptors in a container and then do a lookup on
the container. That would eliminate the need for all
but the first open and all the closes.
 
I'm not very big on IDE's, but the file I'm talking about
is a little analogous to a project file. It's kind of a
meta file though about the project file and not the
project file. So basically a change to the name of the
file I'm talking about would cause my middle tier to have
some dangling data. That's not too big of a deal. If the
server ran for a few weeks it might accumulate a little.
 
I don't think my middle tier would handle it very well if
you changed the name of the file from A to B and then back
to A. It could handle going from A to B, but I think it
would have a problem with going back to A. So while this
sort of change is tempting from an efficiency perspective,
I'm not sure if it's worth it. The approach I currently
have works fine if you want to do an A to B to A change.
Thoughts on this? Thanks in advance.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Paul N <gw7rib@aol.com>: Jun 23 04:35PM -0700

On Monday, 22 June 2015 22:43:11 UTC+1, Paul wrote:
> Thanks for the explanations.
 
> Paul
 
I found a tutorial about linked lists at http://www.panix.com/~elflord/cpp/list_howto/ It's unintentionally quite funny, as he starts off by saying that most textbooks make a terrible mess of linked links, and gives examples, but later finds he has painted himself into a corner and comments of his own code that "the ugliness of this is noted"! The code may also be a bit old-fashioned nowadays. Nevertheless, it covers a lot of the details in depth and is worth reading.
alf.p.steinbach@gmail.com: Jun 23 08:02PM -0700

On Wednesday, June 24, 2015 at 1:11:22 AM UTC+2, Paul N wrote:
> On Monday, 22 June 2015 23:00:12 UTC+1, alf.p.s...@gmail.com wrote:
> > ...
> You say that "the copy constructor has to initialize various members. This is work that the copy assignment operator doesn't have to do." but your code means that the copy assignment operator goes through all that the copy constructor does and all that the destructor does. Is it assumed that the neatness of the code and the ease of making it exception-safe outweighs any possible run-time inefficiency?
 
Yes.
 
For many types there will not be any significant run-time cost anyway, but with a linked list there may for example be a dummy header node which has to be established at construction but not for assignment. And in that situation the copy-swap idiom for assignment will have an extra dynamic allocation, which can be significant. So in the end, if there is a speed problem and this code is suspected of being the culprit, the first rule of optimization is to measure.
 
So, one may choose to not implement copy assignment in terms of copy construction, for efficiency. But that's as far as one should go, IMHO. I have had to maintain code where copy construction was implemented in terms of copy assignment, i.e. the other way around, and it was ... unpleasant. The problems start manifesting themselves when the classes are inherited from.
 
So, summing up, the compiler's generated assignment operator is a nice default, but it can leave the object in a partially changed state when some copying throws an exception; the copy-swap idiom is a nice simple exception safe alternative when the compiler's default doesn't do; a more direct assignment implementation can be reasonable depending on efficiency requirements and measurements,;and doing the opposite of the idiomatic way, namely expressing construction in terms of assignment, can/will be problematic and costly.
 
Cheers & hth.,
 
- Alf
Paul <pepstein5@gmail.com>: Jun 24 12:37AM -0700

On Wednesday, June 24, 2015 at 12:35:29 AM UTC+1, Paul N wrote:
> > Thanks for the explanations.
 
> > Paul
 
> I found a tutorial about linked lists at http://www.panix.com/~elflord/cpp/list_howto/ It's unintentionally quite funny, as he starts off by saying that most textbooks make a terrible mess of linked links, and gives examples, but later finds he has painted himself into a corner and comments of his own code that "the ugliness of this is noted"! The code may also be a bit old-fashioned nowadays. Nevertheless, it covers a lot of the details in depth and is worth reading.
 
Thanks. I like it that it covers templates, something that's left out of most accounts. It's particularly important because many programmer-interview questions say things like "how would you reverse a linked list?" To my mind, any answer that doesn't generalize using templates is a weak one.
 
Paul
legalize+jeeves@mail.xmission.com (Richard): Jun 24 06:52PM

[Please do not mail me a copy of your followup]
 
Paul N <gw7rib@aol.com> spake the secret code
 
>> Paul
 
>I found a tutorial about linked lists at
>http://www.panix.com/~elflord/cpp/list_howto/
 
The main disadvantage of a list or map is that it pummels the cache
because the data doesn't retain memory locality.
 
Try this short video from Bjarne Stroustrup:
<https://www.youtube.com/watch?v=YQs6IC-vgmo>
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Juha Nieminen <nospam@thanks.invalid>: Jun 24 01:00PM

> For some, the lesson is that 'using namespace std;' at file scope is a
> bad idea. I could go either way depending on the coding standards of
> whatever group I'm working in at the time.
 
I really can't understand the obsession that people have with
(ab)using "using namespace std;"
 
It doesn't make the code easier to read and understand, but on the
contrary. Brevity does *not* increase readability and comprehensibility.
In fact, meticulously using the "std::" prefix everywhere increases
readability (you can more quikcly see with a quick scan where standard
library functions and types are being used, and even if you don't know
what something does, you know where to look.)
 
Perhaps the *only* exception is with some very particular generic code,
which needs to use it for functionality reasons (rather than saving you
typing five characters). For example like:
 
template<typename Value_t>
Value_t doSomeCalculation(Value_t value)
{
using std::sin; using std::cos;
return sin(value) * cos(value);
}
 
(This is so that the function can be used with custom types with its
own sin() and cos() functions defined.)
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
gwowen <gwowen@gmail.com>: Jun 24 07:23AM -0700

On Tuesday, June 23, 2015 at 12:54:59 AM UTC+1, Lynn McGuire wrote:
 
> > Valuable lesson learned!
 
> Which is? We wrote a lot of our C++ code before std:: was used in MS VC++.
 
Don't include <tuple>
Lynn McGuire <lmc@winsim.com>: Jun 24 12:34PM -0500

On 6/24/2015 8:00 AM, Juha Nieminen wrote:
> }
 
> (This is so that the function can be used with custom types with its
> own sin() and cos() functions defined.)
 
I do not disagree. It is just with 650K lines of C++ code, it is difficult to add.
 
At the time, we probably had 500K lines of C++ code. We had to switch compilers and that was an unforeseen problem. Someday, we
will remove the using and add the std:: all over the place, we have been actually doing so for all new code in the last ten years.
 
Lynn
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 24 05:10PM +0100

On 23/06/2015 03:08, alf.p.steinbach@gmail.com wrote:
 
Talk about being anal-retentive...
 
> auto main() -> int
 
int main()
 
/Flibble
Maria Martin <maria.martin@codingame.com>: Jun 24 02:33AM -0700

Hi everyone!
 
On June 27th, "Code of the Rings", an online coding battle will launch. It's Free & open to all. You will have 24 hours to code and optimize your solution to a puzzle.
 
What will be exciting and fun is that it will be VERY EASY to start and to get something that works, but complex to produce the most efficient code... Over the 24 hours, you will be able to submit your code as much as you like, whenever you like. No restrictions, no obligation :)
 
Registration is open: http://www.codingame.com/challenge/code-of-the-rings
 
- Duration: 24 hours ; 1 game to solve
- Participation is 100% online and free
- Over 23 coding languages to choose from including C++
- Prizes to win, and 25+ t-shirts
- Apply to sponsoring companies offering jobs and internships International Leaderboard + Leaderboard by University
 
Please, feel free to share the information and your feedback are more than welcome :)
 
Hope to see you there and keep coding!
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: