Saturday, December 16, 2017

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

Lynn McGuire <lynnmcguire5@gmail.com>: Dec 15 09:42PM -0600

"The 7 Most In-Demand Programming Languages of 2018"

http://www.codingdojo.com/blog/7-most-in-demand-programming-languages-of-2018/
 
Huh, using job postings to determine language usage. I am not sure
about the validity of that.
 
Lynn
Vir Campestris <vir.campestris@invalid.invalid>: Dec 16 04:50PM

On 16/12/2017 03:42, Lynn McGuire wrote:
 
> http://www.codingdojo.com/blog/7-most-in-demand-programming-languages-of-2018/
 
> Huh, using job postings to determine language usage.  I am not sure
> about the validity of that.
 
I wouldn't be. But they are using job postings to determine _demand_
which seems pretty reasonable.
 
Andy
Jerry Stuckle <jstucklex@attglobal.net>: Dec 16 06:08PM -0500

On 12/15/2017 10:42 PM, Lynn McGuire wrote:
 
> Huh, using job postings to determine language usage.  I am not sure
> about the validity of that.
 
> Lynn
 
Not valid at all. Job postings favor jobs with high turnover rates.
Stable jobs don't rate very high in such a survey.
 
For instance, IBM estimates over two billion lines of COBOL code are
written every year. But these are typically mainframe jobs where
programmers often spend their entire career with the same company or
government. You don't see that very much on any of the languages listed.
 
But it does show which languages have lots of short-term positions and
other reasons people don't stay.
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
JiiPee <no@notvalid.com>: Dec 16 12:16PM

On 16/12/2017 10:54, Stefan Ram wrote:
> http://en.cppreference.com/w/cpp/language/pimpl
> http://wiki.c2.com/?PimplIdiom
> http://www.cppsamples.com/common-tasks/pimpl.html
 
yes I know pimpl idea, but I was wondering should *all* private raw
variables be behind pimpl? Because I see classes where they use pimpl
but only part of the private variables are put there.
"Öö Tiib" <ootiib@hot.ee>: Dec 16 06:29AM -0800

On Saturday, 16 December 2017 00:07:19 UTC+2, JiiPee wrote:
 
> Is this a good idea to have all private data hidden in another class so
> that Game class cannot get direct access to its variables?
 
On general case if some complexity is added without purpose then it
is not good idea but over-engineering. Is there purpose? What
it is? What problems it solves?
JiiPee <no@notvalid.com>: Dec 16 04:43PM

On 16/12/2017 14:29, Öö Tiib wrote:
> On general case if some complexity is added without purpose then it
> is not good idea but over-engineering. Is there purpose? What
> it is? What problems it solves?
 
But do we always know the future? so it would be ready there if needed
like that in the future?
"Öö Tiib" <ootiib@hot.ee>: Dec 16 10:05AM -0800

On Saturday, 16 December 2017 18:43:32 UTC+2, JiiPee wrote:
> > it is? What problems it solves?
 
> But do we always know the future? so it would be ready there if needed
> like that in the future?
 
You answered to questions with questions. That indicates you do not
have answers. We can't make software to solve problems that we can't
even describe right now. So ... describe the problem.
 
As for your questions ... adding complexity because of future (that we
don't know) violates YAGNI principle and KISS principle.
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
https://en.wikipedia.org/wiki/KISS_principle
Additionally it is better to leave FUD about future to politicians
and other liars.
https://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt
Real Troll <real.troll@trolls.com>: Dec 16 12:30PM -0400

Slides in pdf format:
<https://msdnshared.blob.core.windows.net/media/2017/09/CppConTalk_2017_share.pdf>
 
YouTube Video:
 
<https://www.youtube.com/watch?v=jsdn3kXFVdA&feature=youtu.be>
 
Blog:
<https://blogs.msdn.microsoft.com/vcblog/2017/09/26/16905/?utm_source=vs_developer_news&utm_medium=referral>
Thiago Adams <thiago.adams@gmail.com>: Dec 15 06:28PM -0800

On Friday, December 15, 2017 at 6:09:55 PM UTC-2, Paavo Helde wrote:
> problems).
 
> If mixed-style code means more reliable and maintainable code than
> non-mixed old-style, then it's better, not worse.
 
If you are trying to create more reliable and maintainable
code mixing styles (updating partially enuns or null for instance)
then you have opposite forces in your source code, because more styles
means more complex code and more difficult to read.
 
In case you have a new junior colleague, he will ask. "Why the code
sometimes have 0 or NULL or null_ptr? What is the difference between enum
and enum class? When I use one or other?"
 
The ideal code would have only null_ptr and the junior college would
never ask the difference and the complexity would be hidden.
 
 
The other opposite force for new style is the question.
"should I make my code incompatible with C only by this enum class?"
 
When you start to make your code incompatible with C, then adding
one more incompatibility is not a problem because your code
is already incompatible.
 
"I am using a enum class so I will use more C++ 11 14 17 features."
 
C++ 17 or C++ 20 or "modern C++" doesn't look C anymore.
 
We should ask yourselves.
What is the point in to have a language compatible with C if
the language is completely different?
Ian Collins <ian-news@hotmail.com>: Dec 16 03:44PM +1300

On 12/16/2017 03:28 PM, Thiago Adams wrote:
> code mixing styles (updating partially enuns or null for instance)
> then you have opposite forces in your source code, because more styles
> means more complex code and more difficult to read.
 
All code bases evolve over time. Would you have us keep to the features
available when a decades old code base started?
 
> In case you have a new junior colleague, he will ask. "Why the code
> sometimes have 0 or NULL or null_ptr? What is the difference between enum
> and enum class? When I use one or other?"
 
He will be told to use nullptr (no underscore) for all new code.
 
> The ideal code would have only null_ptr and the junior college would
> never ask the difference and the complexity would be hidden.
 
Clang modernise may take care of that, if I recall correctly.
 
> The other opposite force for new style is the question.
> "should I make my code incompatible with C only by this enum class?"
 
As soon as you introduce an c++ feature that doesn't exist in C you
break compatibility. The new stuff is no different.
 
--
Ian.
Thiago Adams <thiago.adams@gmail.com>: Dec 15 07:34PM -0800

On Saturday, December 16, 2017 at 12:45:08 AM UTC-2, Ian Collins wrote:
> > means more complex code and more difficult to read.
 
> All code bases evolve over time. Would you have us keep to the features
> available when a decades old code base started?
 
I work in 3 different C++ codebases.
One very large from 1999 that still in development. This codebase has
,for instance, a macro for the equivalent of static assert and a macro
for the equivalent of deleted constructor and operator =. This is
for windows and we don´t have a refactoring tool.
 
 
Other medium-small started in 2012 and other medium-small
started in 2015.
 
In 2012 the implementation of C++ 11 in visual studio was limited.
I have used lambdas with copy capture where move capture would be
much better but they were not available at time. Then I had to
use shared_ptr to copy data into lambdas and the refactoring to fix
that would change a lot of code to use unique_ptr with move capture.
 
Considering that we don't have a way to update in one step the
codebase I am planing to keep the code in the same style of when
it was created.
Sometimes this is not only a matter of compiler, but I changed
my style along the years and I use the same policy.
 
 
> > sometimes have 0 or NULL or null_ptr? What is the difference between enum
> > and enum class? When I use one or other?"
 
> He will be told to use nullptr (no underscore) for all new code.
 
Yes nullptr, thanks.
 
> > "should I make my code incompatible with C only by this enum class?"
 
> As soon as you introduce an c++ feature that doesn't exist in C you
> break compatibility. The new stuff is no different.
 
In this case the code has some expiration time.
This code is good until C++ 17.
 
I admire the stability of C code, and the C++ code is changing
very fast. Faster than the codebases that uses C++.
Source code started in 2000 was very stable for one decade.
Then C++ changed a lot in 2011 until now.
Projects started in 2011-2013 were suffering of lack of compiler support
at least in windows.
C++ 17, maybe modules and concepts and maybe new STL will create
a completely new style. If you start a project today and then
in two years when the product is version 1.2 and modules where
variable your codebase will look old and deprecated.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 16 11:18AM


> If you use a vector with the default allocator, and you don't use
> reserve then you can create fragmentation.
> For embedded systems the first option is not use dynamic allocation.
 
And the reason you snipped "I wouldn't use the default allocator" from
my post you replied to is?
 
/Flibble
 
--
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates
a world that is so full of injustice and pain. That's what I would say."
ram@zedat.fu-berlin.de (Stefan Ram): Dec 16 10:54AM

>Is this a good idea to have all private data hidden in another class so
>that Game class cannot get direct access to its variables?
 
http://en.cppreference.com/w/cpp/language/pimpl
http://wiki.c2.com/?PimplIdiom
http://www.cppsamples.com/common-tasks/pimpl.html
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

1 comment:

rohanjoshi said...

May I consider your ideas you are offered to your post. They are really convincing and will certainly work. Thanks for the post.
swift programming language

September 20, 2018 at 1:01 AM

Post a Comment

Subscribe to: Post Comments (Atom)