Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

"Modern C++ for C Programmers: part 1"

75 views
Skip to first unread message

Lynn McGuire

unread,
Jun 26, 2018, 10:01:38 PM6/26/18
to
"Modern C++ for C Programmers: part 1"
https://ds9a.nl/articles/posts/c++-1/

Lynn

Richard Bos

unread,
Jun 30, 2018, 6:32:16 AM6/30/18
to
Lynn McGuire <lynnmc...@gmail.com> wrote:

> "Modern C++ for C Programmers: part 1"
> https://ds9a.nl/articles/posts/c++-1/

Does it give me a reason why I should bother?

No, a _real_ reason, not "it's so much better" or "it's so much more
'powerful'"? Something that isn't propaganda, but which applies to _me_?



Then I won't bother.

Richard

Öö Tiib

unread,
Jul 2, 2018, 2:11:41 AM7/2/18
to
On Saturday, 30 June 2018 13:32:16 UTC+3, Richard Bos wrote:
> Lynn McGuire <lynnmc...@gmail.com> wrote:
>
> > "Modern C++ for C Programmers: part 1"
> > https://ds9a.nl/articles/posts/c++-1/
>
> Does it give me a reason why I should bother?

It says that std::sort sorts array of 100 million integers 40% faster than
qsort.

> No, a _real_ reason, not "it's so much better" or "it's so much more
> 'powerful'"? Something that isn't propaganda, but which applies to _me_?

No. You likely don't need to sort array of 100 million integers. Besides,
we can always hand-write sorting algorithm for each platform targeted
that is bit faster than std::sort for sorting each array that we need
to sort.

> Then I won't bother.

Great.

Thiago Adams

unread,
Jul 4, 2018, 8:34:54 AM7/4/18
to
On Monday, July 2, 2018 at 3:11:41 AM UTC-3, Öö Tiib wrote:
> On Saturday, 30 June 2018 13:32:16 UTC+3, Richard Bos wrote:
> > Lynn McGuire wrote:
> >
> > > "Modern C++ for C Programmers: part 1"
> > > https://ds9a.nl/articles/posts/c++-1/


I think the opposite topic also would be good:

"C for Modern C++ Programmers"

The reason is because C programming is about
patterns and techniques trying to archive simplicity
and performance in a much more "flat" and direct design.
Too much abstractions or too generic code creates a
different problem from the original one and some modern
C++ programmers are going on this path.

Even if your C++ looks nice it may require a lot a concepts
and specific c++ compiler mechanics knowledge.
When the tool is too hard to operate and gives you a lot
of options it also can become dangerous or unpractical to learn
/teach and use.

That said, I think the challenged in C++ is keep the code
"flat" and not try to be too clever and abstract.

Also, when improving existing code, in C or C++ 03, it can
generate a messy in the code base having many styles of modern and
old code at the same source especially in features that have two
ways to write equivalent code (e.g enum X enum class / using X typedef / auto func() X int func() / nullptr X NULL ...)





Thiago Adams

unread,
Jul 4, 2018, 2:24:32 PM7/4/18
to
On Wednesday, July 4, 2018 at 9:34:54 AM UTC-3, Thiago Adams wrote:
[...]
> Even if your C++ looks nice it may require a lot a concepts
> and specific c++ compiler mechanics knowledge.
> When the tool is too hard to operate and gives you a lot
> of options it also can become dangerous or unpractical to learn
> /teach and use.

This is a sample of "compiler mechanics knowledge" to work
with C++.

http://ibob.github.io/blog/2018/07/03/compiler-generated-move/





Bo Persson

unread,
Jul 4, 2018, 4:10:00 PM7/4/18
to
So to have a dynamic array of structs storing generic function objects
holding lambdas, all with its own variable set of data values, you might
have to know what you are doing.

And the code ends up being this advanced:

struct simple_struct
{
simple_struct() = default;
simple_struct(simple_struct&&) = default;
simple_struct(const simple_struct&) = delete;

std::function<void(int)> func;
std::vector<int> data; // call func with each element in data
std::unique_ptr<complex_struct> more_data;
};



Now, how do you do this in C?



Bo Persson

Thiago Adams

unread,
Jul 4, 2018, 5:16:50 PM7/4/18
to
I think in C (or in C++ using less abstractions)
it is hard to give the answer without to
know all the details. For instance, is really
necessary to have variable capture inside func? If not,
a simple function pointer works.
Is necessary resize the data after creation? If not,
a simple pointer and size is enough. Sometimes just
a pointer with zero-ended is also an option.
Is data size something small that we could make fixed
size and avoid allocations?
The concept of move in C would be just a normal copy
and the programmer knows that the ownership has been
transferred.

To make the solution more direct or more "flat" sometimes
is important to ask more questions and restrict the scope.

0 new messages