Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #147593 > unrolled thread

Is this kosher wrt Generic?

Back to article view | Back to comp.lang.c

Contents

  Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-04 22:55 -0800
    Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 08:12 +0100
      Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 03:52 -0800
        Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 13:12 +0100
          Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 04:24 -0800
            Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 13:33 +0100
              Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 04:57 -0800
                Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:08 +0100
                  Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 05:21 -0800
                    Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:27 +0100
                      Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 05:42 -0800
                        Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:51 +0100
                          Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 14:49 +0000
                            Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 15:53 +0100
                              Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 15:59 +0000
                                Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 17:11 +0100
                                  Re: Is this kosher wrt Generic? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 09:19 -0800
                            Re: Is this kosher wrt Generic? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-05 07:00 -0800
                              Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-05 16:30 +0100
                    Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 15:31 +0100
                Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-06 10:34 +1300
                  Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 22:16 +0000
                    Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-06 11:34 +1300
                      Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-05 23:12 +0000
                        Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-06 12:29 +1300
                        Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-06 10:17 +0100
                        Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 10:56 +0100
                    Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 10:02 +0100
                      Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-06 10:43 +0000
                        Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 04:56 -0800
                        Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 14:05 +0100
                  Re: Is this kosher wrt Generic? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 21:03 -0800
                    Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-11-10 08:45 +1300
                      Re: Is this kosher wrt Generic? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 16:35 -0800
                        Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-29 12:41 +0100
                          Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-29 04:08 -0800
                            Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-29 13:01 +0000
                              Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-29 06:43 -0800
                                Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-29 17:31 +0000
                            Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-29 14:31 +0100
                            Re: Is this kosher wrt Generic? Öö Tiib <ootiib@hot.ee> - 2019-11-30 13:16 -0800
                              Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-12-02 03:31 -0800
                                Re: Is this kosher wrt Generic? Öö Tiib <ootiib@hot.ee> - 2019-12-02 23:30 -0800
                        Re: Is this kosher wrt Generic? Ian Collins <ian-news@hotmail.com> - 2019-12-01 12:10 +1300
                          Re: Is this kosher wrt Generic? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 09:35 -0800
                Re: Is this kosher wrt Generic? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-05 22:49 +0000
              Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 05:12 -0800
                Re: Is this kosher wrt Generic? Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 14:20 +0100
      Re: Is this kosher wrt Generic? guinness.tony@gmail.com - 2019-11-05 16:19 -0800
      Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-06 00:06 -0800
    Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-05 03:19 -0800
      Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-05 22:38 -0800
        Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 04:50 -0800
          Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 05:32 -0800
            Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 05:56 -0800
              Re: Is this kosher wrt Generic? Bart <bc@freeuk.com> - 2019-11-06 14:26 +0000
                Re: Is this kosher wrt Generic? Thiago Adams <thiago.adams@gmail.com> - 2019-11-06 09:04 -0800
                Re: Is this kosher wrt Generic? David Brown <david.brown@hesbynett.no> - 2019-11-06 22:45 +0100
                  Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-29 14:35 -0800
                    Re: Is this kosher wrt Generic? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-29 23:23 +0000
                      Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-29 19:08 -0800
                      Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-29 19:12 -0800
                        Re: Is this kosher wrt Generic? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-30 10:44 +0000
              Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 23:21 -0800
              Re: Is this kosher wrt Generic? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 23:22 -0800

Page 1 of 4  [1] 2 3 4  Next page →

#147593 — Is this kosher wrt Generic?

An experiment:
_________________________________
#include <stdio.h>


struct foo_0
{
      unsigned int blah0;
};

struct foo_1
{
      unsigned int blah0;
      unsigned int blah1;
};


void foo_0(struct foo_0* self, int a, int b)
{
      printf("foo_0(%p, blah0: %u, %u, %u)\n",
             (void*)self, self->blah0, a, b);
}

void foo_1(struct foo_1* self, int a, int b)
{
      printf("foo_1(%p, blah0: %u, blah1: %u, %u, %u)\n",
             (void*)self, self->blah0, self->blah1, a, b);
}


#define foo(a, ...) \
      (_Generic((a),   \
          struct foo_0*: foo_0, \
          struct foo_1*: foo_1 \
      )((a), __VA_ARGS__))


int main(void)
{
      struct foo_0 f0 = { 1 };
      struct foo_1 f1 = { 2, 3 };

      foo(&f0, 4, 5); // Calls foo_0
      foo(&f1, 4, 5); // Calls foo_1

      return 0;
}
_________________________________

foo seems pretty nice to me. :^)

[toc] | [next] | [standalone]

#147594

Forget generic programming in C; that't ultimatively ugly!

[toc] | [prev] | [next] | [standalone]

#147597

On Tuesday, November 5, 2019 at 5:12:08 AM UTC-2, Bonita Montero wrote:
> Forget generic programming in C; that't ultimatively ugly!

This feature replaces c++ function overloading. 
The problem in to add function overloading in C, is that this make 
the compiler much more complicated because it has to add a lot of 
rules about type deduction. 

Instead of saying that C is ugly you could try to understand better 
what is behind C language. After this, you can compare with C++ and 
also try to improve C.

[toc] | [prev] | [next] | [standalone]

#147598

> The problem in to add function overloading in C, is that this make
> the compiler much more complicated because it has to add a lot of
> rules about type deduction.

Use C++.

> Instead of saying that C is ugly you could try to understand better
> what is behind C language. ...

The simplicity-paradigma o C isn't modern.

[toc] | [prev] | [next] | [standalone]

#147599

On Tuesday, November 5, 2019 at 10:12:14 AM UTC-2, Bonita Montero wrote:
> > The problem in to add function overloading in C, is that this make
> > the compiler much more complicated because it has to add a lot of
> > rules about type deduction.
> 
> Use C++.
> 
> > Instead of saying that C is ugly you could try to understand better
> > what is behind C language. ...
> 
> The simplicity-paradigma o C isn't modern.

In my view, simplicity is always modern.

Some of my favorite quotes.

"Simplicity is a great virtue but it requires hard work to 
achieve it and education to appreciate it. And to make matters 
worse: complexity sells better.”
― Edsger Wybe Dijkstra

The only thing I would change in this quote is instead of "education
to appreciate it" I would put "experience to appreciate it".

"Complexity sells better" works until some point. C++ has passed 
this point and it complexity is playing against it.


"Simplicity is prerequisite for reliability."
― Edsger W. Dijkstra

[toc] | [prev] | [next] | [standalone]

#147600

>> The simplicity-paradigma o C isn't modern.

> In my view, simplicity is always modern.

When a language has a simplicity that leads to error-prone programming
and implementing a problem takes much more work than in other languages,
this language isn't appropriate.

> "Complexity sells better" works until some point. C++ has
> passed this point and it complexity is playing against it.

C++ is of course not appropriate for beginners, but you
don't need to be a top-developer to handle toe language.

[toc] | [prev] | [next] | [standalone]

#147601

On Tuesday, November 5, 2019 at 10:33:50 AM UTC-2, Bonita Montero wrote:
> >> The simplicity-paradigma o C isn't modern.
> 
> > In my view, simplicity is always modern.
> 
> When a language has a simplicity that leads to error-prone programming
> and implementing a problem takes much more work than in other languages,
> this language isn't appropriate.

When a language becomes too complex, it creates drag for the 
programmers. It removes the focus from the problem and put
it in a language. You don't learn how to solve problems or 
algorithms you learn how to deal with the language details.
This is not a good investment of your time, because when you have 
experience you will see that C can solve the problems for you in 
a much simpler way.
When I watch C++ conferences like cppcon, people are talking about
C++ performance problems or C++ pitfalls or about new features that
will bring new performance problem and pitfalls for the next year.
Do you know what I think nowadays? I don't have any of these problems
because they just doesn't exist in C. 

C is dangerous but it is simple. When you know the tool you 
know exactly what the compiler is doing and you know from a long 
time what is important to do and check. How to deal with the 
details.

C++ is complex and nobody knows happens under the hood. This is why
site that shows the compiler output are so useful nowadays for C++ 
community.

C is not perfect and C++ is not so bad. Personally I wish I could 
select some features from both and add some extra ones.
This is why I created my own C front end.








 

[toc] | [prev] | [next] | [standalone]

#147602

> When a language becomes too complex, it creates drag for the
> programmers. It removes the focus from the problem and put
> it in a language.

That's not true. More features don't make a language harder to handle,
i.e. it would take more time to solve an issue. In C++ you sometimes
fiddle around with some language-features because you find some new
details, but the language and the standdard-lib is so powerful that
it takes usually much less time than to do the same thing in C and
it's less error-prone.

> When I watch C++ conferences like cppcon, people are talking about
> C++ performance problems or C++ pitfalls or about new features that
> will bring new performance problem and pitfalls for the next year.

There are some pifalls, but the most discussed pitfalls don't have a
practical relevance.

> C is dangerous but it is simple.

It's frustrating to program in C because even simple things take a
lot of time. And whereas in C it's harder to understand the syntax
and semantics of the language than in C, in C it's extremely easy
to shoot you in the foot at runtime.

> C++ is complex and nobody knows happens under the hood.

That's not true. The core-language language-features are designed
for simplicity except some complex implementation-details for RTTI
and exception-handling.
The standard-library might be internally more complex, f.e. you don't
know a std::map<K, V> internally works, but that's not a drawback but
a feature, since you can be sure that it is implemented as efficient
as the semantics allows.

[toc] | [prev] | [next] | [standalone]

#147605

On Tuesday, November 5, 2019 at 11:08:55 AM UTC-2, Bonita Montero wrote:
> > When a language becomes too complex, it creates drag for the
> > programmers. It removes the focus from the problem and put
> > it in a language.
> 
> That's not true. More features don't make a language harder to handle,
> i.e. it would take more time to solve an issue. In C++ you sometimes
> fiddle around with some language-features because you find some new
> details, but the language and the standdard-lib is so powerful that
> it takes usually much less time than to do the same thing in C and
> it's less error-prone.

I can select some compiler errors from C++ that can keep a beginner 
busy for hours. This is drag. 
Some parametric containers and algorithms of C++ can save time. 
This is true.
 
> > When I watch C++ conferences like cppcon, people are talking about
> > C++ performance problems or C++ pitfalls or about new features that
> > will bring new performance problem and pitfalls for the next year.
> 
> There are some pifalls, but the most discussed pitfalls don't have a
> practical relevance.
> 
> > C is dangerous but it is simple.
> 
> It's frustrating to program in C because even simple things take a
> lot of time. And whereas in C it's harder to understand the syntax
> and semantics of the language than in C, in C it's extremely easy
> to shoot you in the foot at runtime.

Maybe you are trying to use C in the same way of C++. 
 
> > C++ is complex and nobody knows happens under the hood.
> 
> That's not true. The core-language language-features are designed
> for simplicity except some complex implementation-details for RTTI
> and exception-handling.
> The standard-library might be internally more complex, f.e. you don't
> know a std::map<K, V> internally works, but that's not a drawback but
> a feature, since you can be sure that it is implemented as efficient
> as the semantics allows.

Have you seen this?
CppCon 2019: Chandler Carruth “There Are No Zero-cost Abstractions”
https://youtu.be/rHIkrotSwcc

Chandler Carruth  shows a optimization problem from a very simple 
unique_ptr that should disappear completely but this is not.

[toc] | [prev] | [next] | [standalone]

#147606

> I can select some compiler errors from C++ that can keep a beginner
> busy for hours. This is drag.

Of course C++ is nothing for beginners.
But C isn't also. Whereas it is hard for a beginner to understand
C++ it's hard in C to write programs that are beyond simplicity.

>> It's frustrating to program in C because even simple things take a
>> lot of time. And whereas in C it's harder to understand the syntax
>> and semantics of the language than in C, in C it's extremely easy
>> to shoot you in the foot at runtime.

> Maybe you are trying to use C in the same way of C++.

That's not possible,

> Have you seen this?
> CppCon 2019: Chandler Carruth “There Are No Zero-cost Abstractions”
> https://youtu.be/rHIkrotSwcc
> Chandler Carruth  shows a optimization problem from a very simple
> unique_ptr that should disappear completely but this is not.

Such issues are rare and personally I've not many problems managing
them.

[toc] | [prev] | [next] | [standalone]

#147607

On Tuesday, November 5, 2019 at 11:27:58 AM UTC-2, Bonita Montero wrote:
> > I can select some compiler errors from C++ that can keep a beginner
> > busy for hours. This is drag.
> 
> Of course C++ is nothing for beginners.
> But C isn't also. Whereas it is hard for a beginner to understand
> C++ it's hard in C to write programs that are beyond simplicity.

My advice. Let's the beginners use std::string end std::vector and
std::map in one peace of code that is not so important. 
Meanwhile teach C and how to program in general.

 
> >> It's frustrating to program in C because even simple things take a
> >> lot of time. And whereas in C it's harder to understand the syntax
> >> and semantics of the language than in C, in C it's extremely easy
> >> to shoot you in the foot at runtime.
> 
> > Maybe you are trying to use C in the same way of C++.
> 
> That's not possible,
> 
> > Have you seen this?
> > CppCon 2019: Chandler Carruth “There Are No Zero-cost Abstractions”
> > https://youtu.be/rHIkrotSwcc
> > Chandler Carruth  shows a optimization problem from a very simple
> > unique_ptr that should disappear completely but this is not.
> 
> Such issues are rare and personally I've not many problems managing
> them.

Even when the c++ is not good it is faster. The computers are so faster
nowadays and the c++ alternatives are slow. No one notices.

But if you want something faster, use C.

[toc] | [prev] | [next] | [standalone]

#147608

>> Of course C++ is nothing for beginners.
>> But C isn't also. Whereas it is hard for a beginner to understand
>> C++ it's hard in C to write programs that are beyond simplicity.

> My advice. Let's the beginners use std::string end std::vector
> and std::map in one peace of code that is not so important.
> Meanwhile teach C and how to program in general.

I don't deny that C++ is hard to handle for beginners. But C++ isn't
a beginners language. But with C it's also hard for a beginner to solve
problems that are beyond simplicity.

> Even when the c++ is not good it is faster.

Not much.

[toc] | [prev] | [next] | [standalone]

#147610

On 05/11/2019 13:51, Bonita Montero wrote:
>>> Of course C++ is nothing for beginners.
>>> But C isn't also. Whereas it is hard for a beginner to understand
>>> C++ it's hard in C to write programs that are beyond simplicity.
> 
>> My advice. Let's the beginners use std::string end std::vector
>> and std::map in one peace of code that is not so important.
>> Meanwhile teach C and how to program in general.
> 
> I don't deny that C++ is hard to handle for beginners. But C++ isn't
> a beginners language.

It isn't a language for anybody. It is just too complex even for 
experienced coders. Actually when you have more experience, you 
appreciate simplicity and clean code more.

IMO it isn't even a proper language, just a collection of 
language-building features, and the results are poor (like trying to 
extend C using macros). That's something than many languages just can't 
resist (eg. Rust, Nim with their advanced meta-programming).

C and like languages (eg. mine) work because there is a place still for 
low level languages (which might be used, for example, to implement 
higher level ones, or they are quick to build, their compilers can be 
small etc).

My own take on such a language is not much higher level than C (it has, 
for example, modules) but is full of small features that make everyday 
coding more convenient, and very for beginners too.

I'd wager that:

* Very few of them are in C++ ready-to-use

* If they are, they would use clunky, overwhelming syntax that defeats 
the purpose

* If they aren't, they can probably be hacked together with C++'s 
afore-mentioned features, but with the same problems with syntax


(I'd list some but here they'd be off-topic.)

[toc] | [prev] | [next] | [standalone]

#147611

>> I don't deny that C++ is hard to handle for beginners. But C++ isn't
>> a beginners language.

> It isn't a language for anybody. It is just too complex even for 
> experienced coders. Actually when you have more experience, you 
> appreciate simplicity and clean code more.

I'm using C++ since 1993 and I don't have many problems with it.

> C and like languages (eg. mine) work because there is a place still
> for  low level languages (which might be used, for example, to implement 
> higher level ones, or they are quick to build, their compilers can be 
> small etc).

When you are skilled enough to manage C++ you can implement code in less
time in C++ than in C and it's more robust.

[toc] | [prev] | [next] | [standalone]

#147617

On 05/11/2019 14:53, Bonita Montero wrote:
>>> I don't deny that C++ is hard to handle for beginners. But C++ isn't
>>> a beginners language.
> 
>> It isn't a language for anybody. It is just too complex even for 
>> experienced coders. Actually when you have more experience, you 
>> appreciate simplicity and clean code more.
> 
> I'm using C++ since 1993 and I don't have many problems with it.
> 
>> C and like languages (eg. mine) work because there is a place still
>> for  low level languages (which might be used, for example, to 
>> implement higher level ones, or they are quick to build, their 
>> compilers can be small etc).
> 
> When you are skilled enough to manage C++ you can implement code in less
> time in C++ than in C and it's more robust.

But is it readable? It is readable to anyone else?

People have their own preference for different mixes of languages, my 
own is to use a low-level static/compiled language in combination with a 
higher-level dynamic/interpreted one.

Both are simple. Both compile near-instantly. Both avoid as much 
possible macros and meta-programming (features are built-in rather than 
implemented via low-level language facilities).

I first came across C++ in 1990s, and wondered what all that OOP stuff 
was all about; what could it do for me?

The first examples I saw I think were something to do with first-class 
handling of strings and arrays. Something I'd already been using for 
years in my script language!

Yes, C++ would normally generate faster programs. But if a simple, 
clean, easy to write script language was as fast as C++, who would use 
C++? No one. The trick is to get the balance right so as to code in the 
easy language as much as possible.

You don't need to write 100% of code in the hard one, but C++ seems to 
want to take over everything.

[toc] | [prev] | [next] | [standalone]

#147619

>> When you are skilled enough to manage C++ you can implement
>> code in less time in C++ than in C and it's more robust.

> But is it readable? It is readable to anyone else?

With C you write a lot of code for a small amout of work. In C++ it's
the opposite way. C++'s complexity goes into the depth whereas in C
because of the lot of code you have much breadth. In this sense I
think C++ is a better choice when you know the language haf-way.

> I first came across C++ in 1990s, and wondered what all that
> OOP stuff  was all about; what could it do for me?

OOP gives better structuring and is partitially self-documenting
(f.e. because of public and private methods).

> The first examples I saw I think were something to do with first-class 
> handling of strings and arrays. Something I'd already been using for 
> years in my script language!

Scripting-languages are high-level by nature and therefore have more
convenience.

> Yes, C++ would normally generate faster programs. But if a simple, 
> clean, easy to write script language was as fast as C++, ...

https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/python3-gpp.html


> who would se  C++? No one. The trick is to get the balance
> right so as to code in the easy language as much as possible.

Of course C++ is suitable for things small scripts are writren in.

[toc] | [prev] | [next] | [standalone]

#147626

On Tuesday, 5 November 2019 16:12:08 UTC, Bonita Montero  wrote:
> 
> > I first came across C++ in 1990s, and wondered what all that
> > OOP stuff  was all about; what could it do for me?
> 
> OOP gives better structuring and is partitially self-documenting
> (f.e. because of public and private methods).
> 
A lot of people are now much more sceptical about object-based
programming than they were. It can be done well or badly. One of the
best uses I've seen was in 3DS Max. But it is a 3D drawing package,
the elements in the scene are virtual objects, and naturally lend
themselves to that approach. Where the objects represent abstractions
such as "employee list view manager", the approach works less 
successfully.

[toc] | [prev] | [next] | [standalone]

#147612

On Tuesday, 5 November 2019 14:49:35 UTC, Bart  wrote:
> On 05/11/2019 13:51, Bonita Montero wrote:
> >>> Of course C++ is nothing for beginners.
> >>> But C isn't also. Whereas it is hard for a beginner to understand
> >>> C++ it's hard in C to write programs that are beyond simplicity.
> > 
> >> My advice. Let's the beginners use std::string end std::vector
> >> and std::map in one peace of code that is not so important.
> >> Meanwhile teach C and how to program in general.
> > 
> > I don't deny that C++ is hard to handle for beginners. But C++ isn't
> > a beginners language.
> 
> It isn't a language for anybody. It is just too complex even for 
> experienced coders. Actually when you have more experience, you 
> appreciate simplicity and clean code more.
> 
Most people use a subset of the language. That leads to C++ with very
different flavours. It could be template-heavy, it could use a lot
of lambdas, it could rely heavily on Boost.

That leads to integration and team management problems.

[toc] | [prev] | [next] | [standalone]

#147613

On 05/11/2019 16:00, Malcolm McLean wrote:
> On Tuesday, 5 November 2019 14:49:35 UTC, Bart  wrote:
>> On 05/11/2019 13:51, Bonita Montero wrote:
>>>>> Of course C++ is nothing for beginners.
>>>>> But C isn't also. Whereas it is hard for a beginner to understand
>>>>> C++ it's hard in C to write programs that are beyond simplicity.
>>>
>>>> My advice. Let's the beginners use std::string end std::vector
>>>> and std::map in one peace of code that is not so important.
>>>> Meanwhile teach C and how to program in general.
>>>
>>> I don't deny that C++ is hard to handle for beginners. But C++ isn't
>>> a beginners language.
>>
>> It isn't a language for anybody. It is just too complex even for 
>> experienced coders. Actually when you have more experience, you 
>> appreciate simplicity and clean code more.
>>
> Most people use a subset of the language. That leads to C++ with very
> different flavours. It could be template-heavy, it could use a lot
> of lambdas, it could rely heavily on Boost.
> 
> That leads to integration and team management problems.
> 

Alternatively, you can say it leads to different people working with
different parts of the code - and that's a good thing.  The skills you
need for making reusable libraries, or low-level code, or efficient
utility code, or gui application code, are all different.  With C++, you
can remain within the one language and handle these - it covers a far
wider range of coding needs than any other language.

You are right that people typically use only a subset of the language.
 That applies to all languages, but more so for bigger languages.
(Stand up if you think Python is an easy language to learn.  Sit down
again if you have used metaclasses.  Sit down if you have created
generators, decorators, and asynchronous code.)  And that is absolutely
fine - you don't need to be an expert on everything.

If this leads to integration and team management problems, then the
problem lies with the team management.  (Usually the programmers will
get blamed for the problems, of course - but it is management's fault.)

[toc] | [prev] | [next] | [standalone]

#147609

> Chandler Carruth  shows a optimization problem from a very simple
> unique_ptr that should disappear completely but this is not.

What stupid things is he doing with unique_ptrs?
You don't pass them as temporaries in this way. It's better to

void foo( unique_ptr<string> str )!

With this function you can only do something like this:

#include <iostream>
#include <memory>

using namespace std;

void foo( unique_ptr<string> str )
{
     cout << *str << endl;
}

int main()
{
     foo( unique_ptr<strign>( new string( "hello world" ) ) );
}

But this absolutely doesn't make sense because the string would
die at the same point where the unique_ptr dies.
So you could simply pass a temporary string object as well:

void foo( unique_ptr<string> str )!

With this function you can only do something like this:

#include <iostream>
#include <memory>

using namespace std;

void foo( string const &str )
{
     cout << str << endl;
}

int main()
{
     foo( string( "hello world" ) );
}

unique_ptrs are usually kept in a central place and normal pointers
whose lifetime are shorter than that of the unique_ptr are passed
around.

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web