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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#147631

On 06/11/2019 01:57, Thiago Adams wrote:
> 
> 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.

The complexity in a programming problem is a constant.  You can solve it 
in the C way with a large number of simple steps, which introduces extra 
complexity in making sure they all work together. You can solve it with 
fewer step in a higher level language, which introduces extra complexity 
to the language.  The overall complexity remains constant.

-- 
Ian.

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

#147633

On 05/11/2019 21:34, Ian Collins wrote:
> On 06/11/2019 01:57, Thiago Adams wrote:
>>
>> 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.
> 
> The complexity in a programming problem is a constant.  You can solve it 
> in the C way with a large number of simple steps, which introduces extra 
> complexity in making sure they all work together. You can solve it with 
> fewer step in a higher level language, which introduces extra complexity 
> to the language.  The overall complexity remains constant.

A lot of the complexity in C++ appears to me gratuitous.

Even when it isn't, a considerable amount is exposed to the compiler 
(ie. each time it runs, it has to process library source code to 
implement features which in another language are compiled once)

In addition that extra complexity is exposed to the user, because when 
they gets some minor thing wrong, it doesn't directly report that thing, 
but reports instead the error that it invokes in the complex library code.

Advocates for the language like to pretend that it is for experts.

(To illustrate my points:

(1) Basic's PRINT X has to be written as:

     std::cout << X << std::endl;

(2) See what happens when you inadvertently type this instead:

     std::cout >> X >> std::endl;

)

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

#147636

On 06/11/2019 11:16, Bart wrote:
> On 05/11/2019 21:34, Ian Collins wrote:
>> On 06/11/2019 01:57, Thiago Adams wrote:
>>>
>>> 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.
>>
>> The complexity in a programming problem is a constant.  You can solve it
>> in the C way with a large number of simple steps, which introduces extra
>> complexity in making sure they all work together. You can solve it with
>> fewer step in a higher level language, which introduces extra complexity
>> to the language.  The overall complexity remains constant.
> 
> A lot of the complexity in C++ appears to me gratuitous.

You say that about a lot of things.

> Even when it isn't, a considerable amount is exposed to the compiler
> (ie. each time it runs, it has to process library source code to
> implement features which in another language are compiled once)

So?

Even the most basic C++ feature, automatic object destruction, greatly 
simplifies and automates resource management which has to be handled 
manually in C.

> In addition that extra complexity is exposed to the user, because when
> they gets some minor thing wrong, it doesn't directly report that thing,
> but reports instead the error that it invokes in the complex library code.

Some, much is built in.  Compilers aren't psychic, if you use a library 
function incorrectly, the compiler will tell you that you have used it 
incorrectly.

> Advocates for the language like to pretend that it is for experts.

I don't, often I'd claim the opposite.  Creating and using a dynamically 
expandable robust array or string in C is much more of an "expert" 
problem than it is in C++.

-- 
Ian.

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

#147639

On 05/11/2019 22:34, Ian Collins wrote:
> On 06/11/2019 11:16, Bart wrote:

>>
>> A lot of the complexity in C++ appears to me gratuitous.
> 
> You say that about a lot of things.

Maybe it is true about a lot of things! (Eg. auto-conf scripts.)

>> Even when it isn't, a considerable amount is exposed to the compiler
>> (ie. each time it runs, it has to process library source code to
>> implement features which in another language are compiled once)
> 
> So?

So it makes the process cumbersome.

> Some, much is built in.  Compilers aren't psychic, if you use a library 
> function incorrectly, the compiler will tell you that you have used it 
> incorrectly.

But for features which you may not even know is a library function? I 
don't actually know which bit of C++ is implemented in a library, and 
which part is a built-in core feature.

>> Advocates for the language like to pretend that it is for experts.
> 
> I don't, often I'd claim the opposite.  Creating and using a dynamically 
> expandable robust array or string in C is much more of an "expert" 
> problem than it is in C++.

This is a fragment I came across today:

    for (auto i=0; ....)

I assumed i takes its type from the zero, and wondered what would happen 
here:

    #include <iostream>

    int main() {
        for (auto i=0; i<=5000000000; i+=100000000) {
              std::cout << i << std::endl;
        }
    }

And I was right: i has type i32, and it will wrap or generate UB. Not 
what you intended anyway. That 'auto' gives a false sense of security. A 
compiler may report something given enough options, but apparently not 
if the limit is a i64 variable.

BTW what happened to "_" separators for those long constants which I 
thought C++ had? Neither my g++ nor rextester seems to like them.

I mentioned something about getting basic features right in an earlier 
post, a lot of languages don't, yet do have esoteric ones.

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

#147640

On 06/11/2019 12:12, Bart wrote:
> On 05/11/2019 22:34, Ian Collins wrote:
>> On 06/11/2019 11:16, Bart wrote:
> 
>>>
>>> A lot of the complexity in C++ appears to me gratuitous.
>>
>> You say that about a lot of things.
> 
> Maybe it is true about a lot of things! (Eg. auto-conf scripts.)
> 
>>> Even when it isn't, a considerable amount is exposed to the compiler
>>> (ie. each time it runs, it has to process library source code to
>>> implement features which in another language are compiled once)
>>
>> So?
> 
> So it makes the process cumbersome.

To whom?

>> Some, much is built in.  Compilers aren't psychic, if you use a library
>> function incorrectly, the compiler will tell you that you have used it
>> incorrectly.
> 
> But for features which you may not even know is a library function? I
> don't actually know which bit of C++ is implemented in a library, and
> which part is a built-in core feature.

It's no different to C, if you need to include a library header, it's in 
a library!

>>> Advocates for the language like to pretend that it is for experts.
>>
>> I don't, often I'd claim the opposite.  Creating and using a dynamically
>> expandable robust array or string in C is much more of an "expert"
>> problem than it is in C++.
> 
> This is a fragment I came across today:
> 
>      for (auto i=0; ....)
> 
> I assumed i takes its type from the zero, 

You assumed wrong.

> BTW what happened to "_" separators for those long constants which I
> thought C++ had? Neither my g++ nor rextester seems to like them.

Nothing.  The digit separator is '.

> I mentioned something about getting basic features right in an earlier
> post, a lot of languages don't, yet do have esoteric ones.

Congratulations on googling a flaw in auto type deduction.

How about the "expert" problem I mentioned?  I assume it doesn't fit 
your narrative.

--
Ian.

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

#147656

On 06/11/2019 00:12, Bart wrote:
> On 05/11/2019 22:34, Ian Collins wrote:
>> On 06/11/2019 11:16, Bart wrote:
> 
>>>
>>> A lot of the complexity in C++ appears to me gratuitous.
>>
>> You say that about a lot of things.
> 
> Maybe it is true about a lot of things! (Eg. auto-conf scripts.)

<https://en.wikipedia.org/wiki/Whataboutism>

> 
>>> Even when it isn't, a considerable amount is exposed to the compiler
>>> (ie. each time it runs, it has to process library source code to
>>> implement features which in another language are compiled once)
>>
>> So?
> 
> So it makes the process cumbersome.
> 
>> Some, much is built in.  Compilers aren't psychic, if you use a
>> library function incorrectly, the compiler will tell you that you have
>> used it incorrectly.
> 
> But for features which you may not even know is a library function? I
> don't actually know which bit of C++ is implemented in a library, and
> which part is a built-in core feature.

You know little about C++, yet feel qualified to tell people what a
terrible language it is and what its problems are?

It's fine to look at a language and say "that doesn't look like the sort
of language I want to learn and use - it's not a language for me".  For
anything beyond that, you simply don't know enough to judge.  (Here's a
clue for you - when lots of other people manage to use a language or
tool successfully, and you don't, maybe the problem is /not/ with the
language or tool.)

> 
>>> Advocates for the language like to pretend that it is for experts.
>>
>> I don't, often I'd claim the opposite.  Creating and using a
>> dynamically expandable robust array or string in C is much more of an
>> "expert" problem than it is in C++.
> 
> This is a fragment I came across today:
> 
>    for (auto i=0; ....)
> 
> I assumed i takes its type from the zero, and wondered what would happen
> here:
> 
>    #include <iostream>
> 
>    int main() {
>        for (auto i=0; i<=5000000000; i+=100000000) {
>              std::cout << i << std::endl;
>        }
>    }
> 
> And I was right: i has type i32, and it will wrap or generate UB. Not
> what you intended anyway. That 'auto' gives a false sense of security. A
> compiler may report something given enough options, but apparently not
> if the limit is a i64 variable.

"auto" has its uses and its weaknesses, like every other feature in
programming.  The trick is to learn the programming language and how to
use it.

> 
> BTW what happened to "_" separators for those long constants which I
> thought C++ had? Neither my g++ nor rextester seems to like them.

You are confused - the C++ digit separator is '.

> 
> I mentioned something about getting basic features right in an earlier
> post, a lot of languages don't, yet do have esoteric ones.
> 

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

#147657

>     int main() {
>         for (auto i=0; i<=5000000000; i+=100000000) {
>               std::cout << i << std::endl;
>         }
>     }

Even in C there are language-features which can be mis-used; but this
doesn't mean that there's a proper use for them. auto in a for-loop
doesn't make sense for me because it hides the type, f.e. in a range
-based for-loop.
But auto is necessary for declaring template-lambdas by name (and not
just as a parameter). And you need it when you have a return-type that
is decuced from other template-parameters.

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

#147654

> (To illustrate my points:
> (1) Basic's PRINT X has to be written as:
>      std::cout << X << std::endl;
> (2) See what happens when you inadvertently type this instead:
>      std::cout >> X >> std::endl;

You get an error-message that there isn't any operator >> defined
on std::ostream.

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

#147660

On 06/11/2019 09:02, Bonita Montero wrote:
>> (To illustrate my points:
>> (1) Basic's PRINT X has to be written as:
>>      std::cout << X << std::endl;
>> (2) See what happens when you inadvertently type this instead:
>>      std::cout >> X >> std::endl;
> 
> You get an error-message that there isn't any operator >> defined
> on std::ostream.
> 

I might do but I can't see it because I get 80+ lines of output that 
scrolls off the top of my console window.

That's on g++ 8.1.0. On MSVC on rextester.com, I get:

source_file.cpp(6): error C2784: 'std::basic_istream<_Elem,_Traits> 
&std::operator >>(std::basic_istream<_Elem,_Traits> &&,_Ty &)': could 
not deduce template argument for 'std::basic_istream<_Elem,_Traits> &&' 
from 'std::ostream'
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE\istream(1106): note: see declaration of 'std::operator >>'
source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
&std::operator >>(std::basic_istream<char,_Traits> &,unsigned char &)': 
could not deduce template argument for 'std::basic_istream<char,_Traits> 
&' from 'std::ostream'
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE\istream(1096): note: see declaration of 'std::operator >>'
source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
&std::operator >>(std::basic_istream<char,_Traits> &,unsigned char *)': 
could not deduce template argument for 'std::basic_istream<char,_Traits> 
&' from 'std::ostream'
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE\istream(1089): note: see declaration of 'std::operator >>'
source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
&std::operator >>(std::basic_istream<char,_Traits> &,signed char &)': 
could not deduce template argument for 'std::basic_istream<char,_Traits> 
&' from 'std::ostream'
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE\istream(1082): note: see declaration of 'std::operator >>'
source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
&std::operator >>(std::basic_istream<char,_Traits> &,signed char *)': 
could not deduce template argument for 'std::basic_istream<char,_Traits> 
&' from 'std::ostream'
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE\istream(1075): note: see declaration of 'std::operator >>'
source_file.cpp(6): error C2784: 'std::basic_istream<_Elem,_Traits> 
&std::operator >>(std::basic_istream<_Elem,_Traits> &,_Elem &)': could 
not deduce template argument for 'std::basic_istream<_Elem,_Traits> &' 
from 'std::ostream'
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE\istream(1050): note: see declaration of 'std::operator >>'
source_file.cpp(6): error C2784: 'std::basic_istream<_Elem,_Traits> 
&std::operator >>(std::basic_istream<_Elem,_Traits> &,_Elem *)': could 
not deduce template argument for 'std::basic_istream<_Elem,_Traits> &' 
from 'std::ostream'
C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\INCLUDE\istream(1008): note: see declaration of 'std::operator >>'
source_file.cpp(6): error C2676: binary '>>': 'std::ostream' does not 
define this operator or a conversion to a type acceptable to the 
predefined operator
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x64

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

#147665

On Wednesday, November 6, 2019 at 7:43:21 AM UTC-3, Bart wrote:
> On 06/11/2019 09:02, Bonita Montero wrote:
> >> (To illustrate my points:
> >> (1) Basic's PRINT X has to be written as:
> >>      std::cout << X << std::endl;
> >> (2) See what happens when you inadvertently type this instead:
> >>      std::cout >> X >> std::endl;
> > 
> > You get an error-message that there isn't any operator >> defined
> > on std::ostream.
> > 
> 
> I might do but I can't see it because I get 80+ lines of output that 
> scrolls off the top of my console window.
> 
> That's on g++ 8.1.0. On MSVC on rextester.com, I get:
> 
> source_file.cpp(6): error C2784: 'std::basic_istream<_Elem,_Traits> 
> &std::operator >>(std::basic_istream<_Elem,_Traits> &&,_Ty &)': could 
> not deduce template argument for 'std::basic_istream<_Elem,_Traits> &&' 
> from 'std::ostream'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\istream(1106): note: see declaration of 'std::operator >>'
> source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
> &std::operator >>(std::basic_istream<char,_Traits> &,unsigned char &)': 
> could not deduce template argument for 'std::basic_istream<char,_Traits> 
> &' from 'std::ostream'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\istream(1096): note: see declaration of 'std::operator >>'
> source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
> &std::operator >>(std::basic_istream<char,_Traits> &,unsigned char *)': 
> could not deduce template argument for 'std::basic_istream<char,_Traits> 
> &' from 'std::ostream'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\istream(1089): note: see declaration of 'std::operator >>'
> source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
> &std::operator >>(std::basic_istream<char,_Traits> &,signed char &)': 
> could not deduce template argument for 'std::basic_istream<char,_Traits> 
> &' from 'std::ostream'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\istream(1082): note: see declaration of 'std::operator >>'
> source_file.cpp(6): error C2784: 'std::basic_istream<char,_Traits> 
> &std::operator >>(std::basic_istream<char,_Traits> &,signed char *)': 
> could not deduce template argument for 'std::basic_istream<char,_Traits> 
> &' from 'std::ostream'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\istream(1075): note: see declaration of 'std::operator >>'
> source_file.cpp(6): error C2784: 'std::basic_istream<_Elem,_Traits> 
> &std::operator >>(std::basic_istream<_Elem,_Traits> &,_Elem &)': could 
> not deduce template argument for 'std::basic_istream<_Elem,_Traits> &' 
> from 'std::ostream'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\istream(1050): note: see declaration of 'std::operator >>'
> source_file.cpp(6): error C2784: 'std::basic_istream<_Elem,_Traits> 
> &std::operator >>(std::basic_istream<_Elem,_Traits> &,_Elem *)': could 
> not deduce template argument for 'std::basic_istream<_Elem,_Traits> &' 
> from 'std::ostream'
> C:\Program Files (x86)\Microsoft Visual Studio 
> 14.0\VC\INCLUDE\istream(1008): note: see declaration of 'std::operator >>'
> source_file.cpp(6): error C2676: binary '>>': 'std::ostream' does not 
> define this operator or a conversion to a type acceptable to the 
> predefined operator
> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23506 for x64

When a function is overloaded and the compiler doesn't find any
match it prints all possibilities.
If we had function overload in C we also would have this kind of 
situation.
The error is difficult to read in this case because of the 
templates.

Comparing with _Generic, in case we don't find a match it says
one error message:

error: ‘_Generic’ selector of type ‘type’ is not compatible with 
any association.

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

#147666

For this code:

#include <iostream>

using namespace std;

int main()
{
     cout >> "hello world" >> endl;
}

I get only a single error:

error C2676: binary '>>': 'std::ostream' does not define this operator
or a conversion to a type acceptable to the predefined operator

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

#147811

Ian Collins <ian-news@hotmail.com> writes:

> On 06/11/2019 01:57, Thiago Adams wrote:
>
>> 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.
>
> The complexity in a programming problem is a constant.  You can solve
> it in the C way with a large number of simple steps, which introduces
> extra complexity in making sure they all work together.  You can solve
> it with fewer step in a higher level language, which introduces extra
> complexity to the language.  The overall complexity remains constant.

Mother Goose comes to comp.lang.c.

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

#147846

On 09/11/2019 18:03, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
>> On 06/11/2019 01:57, Thiago Adams wrote:
>>
>>> 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.
>>
>> The complexity in a programming problem is a constant.  You can solve
>> it in the C way with a large number of simple steps, which introduces
>> extra complexity in making sure they all work together.  You can solve
>> it with fewer step in a higher level language, which introduces extra
>> complexity to the language.  The overall complexity remains constant.
> 
> Mother Goose comes to comp.lang.c.
> 

I assume by your recent tone that you have been smoking something...

Take a concrete example: resource management.

In C resource management is transparent but manual, the programmer has 
to track what has been allocated and know when to free it.  This, along 
with the opportunity for error, gets quite complex when a resource is 
shared, especially between threads.

In C++, adding some extra complexity in the language (constructors and 
automatic object destruction) removes the complexity and the 
opportunities for error from the user code.

The code is still doing the same work and may well compile down to 
equivalent assembler.  The overall complexity remains constant.

-- 
Ian.

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

#148205

Ian Collins <ian-news@hotmail.com> writes:

> On 09/11/2019 18:03, Tim Rentsch wrote:
>
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> On 06/11/2019 01:57, Thiago Adams wrote:
>>>
>>>> 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.
>>>
>>> The complexity in a programming problem is a constant.  You can solve
>>> it in the C way with a large number of simple steps, which introduces
>>> extra complexity in making sure they all work together.  You can solve
>>> it with fewer step in a higher level language, which introduces extra
>>> complexity to the language.  The overall complexity remains constant.
>>
>> Mother Goose comes to comp.lang.c.
>
> I assume by your recent tone that you have been smoking something...

Ahh, and here we have another ad hominem remark.  When one
doesn't have either the facts or the law on their side, all
that's left is attacking the character of one's opponent.

> Take a concrete example:  resource management.
>
> In C resource management is transparent but manual, the programmer has
> to track what has been allocated and know when to free it.  This,
> along with the opportunity for error, gets quite complex when a
> resource is shared, especially between threads.
>
> In C++, adding some extra complexity in the language (constructors and
> automatic object destruction) removes the complexity and the
> opportunities for error from the user code.
>
> The code is still doing the same work and may well compile down to
> equivalent assembler.  The overall complexity remains constant.

Two problems:  this assumes complexity is a scalar, which it
isn't, and that it is simply additive, which it also isn't.

Furthermore it ignores the cost of all the other complexity in
C++ that must be paid whether the program needs it or not.  Very
few programs, if any, need all of the complex features that C++
provides.  I think it was Tony Hoare who pointed out that a
programming language shouldn't the union of all features needed
by any program, but rather the intersection of features needed
in every program.  Otherwise essentially every program is paying
a complexity cost for some unneeded features.

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

#148279

On 29/11/2019 01:35, Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
> 
>> On 09/11/2019 18:03, Tim Rentsch wrote:
>>
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>
>>>> On 06/11/2019 01:57, Thiago Adams wrote:
>>>>
>>>>> 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.
>>>>
>>>> The complexity in a programming problem is a constant.  You can solve
>>>> it in the C way with a large number of simple steps, which introduces
>>>> extra complexity in making sure they all work together.  You can solve
>>>> it with fewer step in a higher level language, which introduces extra
>>>> complexity to the language.  The overall complexity remains constant.
>>>
>>> Mother Goose comes to comp.lang.c.
>>
>> I assume by your recent tone that you have been smoking something...
> 
> Ahh, and here we have another ad hominem remark.  When one
> doesn't have either the facts or the law on their side, all
> that's left is attacking the character of one's opponent.

Again - do not complain when people respond to your ad hominem remarks
with ad hominem remarks.  If you want people to respond politely, be
polite yourself.  (I won't be repeating this again - either you
understand, or you do not.)

> 
>> Take a concrete example:  resource management.
>>
>> In C resource management is transparent but manual, the programmer has
>> to track what has been allocated and know when to free it.  This,
>> along with the opportunity for error, gets quite complex when a
>> resource is shared, especially between threads.
>>
>> In C++, adding some extra complexity in the language (constructors and
>> automatic object destruction) removes the complexity and the
>> opportunities for error from the user code.
>>
>> The code is still doing the same work and may well compile down to
>> equivalent assembler.  The overall complexity remains constant.
> 
> Two problems:  this assumes complexity is a scalar, which it
> isn't, and that it is simply additive, which it also isn't.
> 

Complexity is not a simple or well-defined concept.  It is unreasonable
to suggest that it is exactly "constant", or to suggest it is or is not
additive, without first defining it rigorously and finding a way to
quantify it.

However, it /is/ reasonable to say it can be moved around a bit,
increased and decreased, split up, and handled in different ways.  It
that may increase or decrease the total complexity (however that may be
defined), but at least it will give you modular parts where each has
clearly lower complexity.

> Furthermore it ignores the cost of all the other complexity in
> C++ that must be paid whether the program needs it or not.  Very
> few programs, if any, need all of the complex features that C++
> provides.  

Very few, if any, /use/ the complex features of C++.

The C++ language is designed to be "zero extra cost" - if you don't need
a feature, you should not pay for it either in terms of understanding
the language, writing the source code, or at run-time size and speed.
It does not met that aim, but it comes reasonably close in many ways.

Thus you can make classes, use RAII for resource control, have
unique_ptr's for memory handling, store data in std::vectors, work with
std::string - all without ever writing or seeing the word "template", or
understanding rvalue references, or getting your head around
"enable_if".  Many of C++'s more complex features exist primarily so
that the standard library (and other libraries) can be written, so that
application code writers can get efficient code without having to
understand these complexities.

It doesn't always work out, of course, but that is an aim.

> I think it was Tony Hoare who pointed out that a
> programming language shouldn't the union of all features needed
> by any program, but rather the intersection of features needed
> in every program.  Otherwise essentially every program is paying
> a complexity cost for some unneeded features.
> 

It was indeed Tony Hoare who said that.

And if you look at the progression of the C++ language, rarely is
something added to the core language if it could alternatively be put in
the library.  Core language changes are added if they significantly ease
programming, or if they allow more useful (or more efficient) library code.

As an example, C99 added support for complex numbers to the language.
It is part of the language, whether you use them or not - even though
only a very tiny percentage of programs use them.  C++ did not put them
in the language - they put them in a library.

But you can't take features out of a language and retain backwards
compatibility.  C and C++ both suffer from that - and users pay the
costs as well as benefiting.

In every programming language, except perhaps Bart's personal language
for his personal use, every programmer and every program pays something
in complexity costs for features they don't need.

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

#148280

On Friday, November 29, 2019 at 8:41:29 AM UTC-3, David Brown wrote:
...
> Thus you can make classes, use RAII for resource control, have
> unique_ptr's for memory handling, store data in std::vectors, work with
> std::string - all without ever writing or seeing the word "template", or
> understanding rvalue references, or getting your head around
> "enable_if".  Many of C++'s more complex features exist primarily so
> that the standard library (and other libraries) can be written, so that
> application code writers can get efficient code without having to
> understand these complexities.

Recently, a beginner colleague of mine call me saying:

"Please look at this error..."

The error was really big. 

I don't remember the details, but we had an object used included 
in some container.

Like this:

class X {
    int i;
};


int main() {
    std::vector<X> v;
    X x;
    v.push_back(x);
}
    
and he was adding a new member at X.

class Y {int i;};

class X {
    unique_ptr<Y> sp; // <- Like this
    int i;
};

Then the program stop to compile. 
If you put this example online (which is much smaller than the real 
case) we have these errors:

In file included from /usr/include/x86_64-linux-gnu/c++/6/bits/c++allocator.h:33:0,
                 from /usr/include/c++/6/bits/allocator.h:46,
                 from /usr/include/c++/6/string:41,
                 from /usr/include/c++/6/bits/locale_classes.h:40,
                 from /usr/include/c++/6/bits/ios_base.h:41,
                 from /usr/include/c++/6/ios:42,
                 from /usr/include/c++/6/ostream:38,
                 from /usr/include/c++/6/iostream:39,
                 from main.cpp:9:
/usr/include/c++/6/ext/new_allocator.h: In instantiation of ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up = X; _Args = {const X&}; _Tp = X]’:
/usr/include/c++/6/bits/alloc_traits.h:475:4:   required from ‘static void std::allocator_traits<std::allocator<_CharT> >::construct(std::allocator_traits<std::allocator<_CharT> >::allocator_type&, _Up*, _Args&& ...) [with _Up = X; _Args = {const X&}; _Tp = X; std::allocator_traits<std::allocator<_CharT> >::allocator_type = std::allocator<X>]’
/usr/include/c++/6/bits/stl_vector.h:918:30:   required from ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = X; _Alloc = std::allocator<X>; std::vector<_Tp, _Alloc>::value_type = X]’
<span class="error_line" onclick="ide.gotoLine('main.cpp',28)">main.cpp:28:18</span>:   required from here
/usr/include/c++/6/ext/new_allocator.h:120:4: error: use of deleted function ‘X::X(const X&)’
  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
main.cpp:17:7: note: ‘X::X(const X&)’ is implicitly deleted because the default definition would be ill-formed:
 class X
       ^
main.cpp:17:7: error: use of deleted function ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = Y; _Dp = std::default_delete]’
In file included from /usr/include/c++/6/memory:81:0,
                 from main.cpp:11:
/usr/include/c++/6/bits/unique_ptr.h:361:7: note: declared here
       unique_ptr(const unique_ptr&) = delete;
       ^~~~~~~~~~



As we can see, just adding a unique_ptr give us an error that requires
a lot of knowledge about the language to fix it, or at least, understand
why it is not working.
He was not trying to use advanced c++ features.

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

#148281

On 29/11/2019 12:08, Thiago Adams wrote:
> On Friday, November 29, 2019 at 8:41:29 AM UTC-3, David Brown wrote:
> ...
>> Thus you can make classes, use RAII for resource control, have
>> unique_ptr's for memory handling, store data in std::vectors, work with
>> std::string - all without ever writing or seeing the word "template", or
>> understanding rvalue references, or getting your head around
>> "enable_if".  Many of C++'s more complex features exist primarily so
>> that the standard library (and other libraries) can be written, so that
>> application code writers can get efficient code without having to
>> understand these complexities.
> 
> Recently, a beginner colleague of mine call me saying:
> 
> "Please look at this error..."
> 
> The error was really big.
> 
> I don't remember the details, but we had an object used included
> in some container.
> 
> Like this:
> 
> class X {
>      int i;
> };
> 
> 
> int main() {
>      std::vector<X> v;
>      X x;
>      v.push_back(x);
> }
>      
> and he was adding a new member at X.
> 
> class Y {int i;};
> 
> class X {
>      unique_ptr<Y> sp; // <- Like this
>      int i;
> };
> 
> Then the program stop to compile.
> If you put this example online (which is much smaller than the real
> case) we have these errors:
> 
> In file included from /usr/include/x86_64-linux-gnu/c++/6/bits/c++allocator.h:33:0,
>                   from /usr/include/c++/6/bits/allocator.h:46,
>                   from /usr/include/c++/6/string:41,
>                   from /usr/include/c++/6/bits/locale_classes.h:40,
>                   from /usr/include/c++/6/bits/ios_base.h:41,
>                   from /usr/include/c++/6/ios:42,
>                   from /usr/include/c++/6/ostream:38,
>                   from /usr/include/c++/6/iostream:39,

>                   from main.cpp:9:

....

> As we can see, just adding a unique_ptr give us an error that requires
> a lot of knowledge about the language to fix it, or at least, understand
> why it is not working.
> He was not trying to use advanced c++ features.

This is a point I sometimes make.

Because these features are implemented in user-code (ie. code written in 
C++ rather then being part of the language proper), then error messages 
tend to be in terms of violations that are invoked within those large 
libraries.

And those are going to be meaningless to someone who only knows about 
how to use a feature, not how it's implemented.

Perhaps what is needed is yet another set of features that ring-fence 
such libraries, which trap any compiler errors, and turn them into a set 
of friendlier, more relevant messages.

Or perhaps not...

(I'm actually working on something related, implementing features 
equivalent to std::vector and std::string, but built-in. Those 
implementations are also largely aided by libraries written in the same 
language. But the libraries are pre-compiled and pre-tested.

No compiler error that arises out of the misuse of 'vector' or 'string' 
will refer to its implementation code, but only directly in terms of how 
they ought to be used.

Now, here, I don't use techniques such as templates which require all 
that implementation code to be recompiled, with user-types plugged in, 
and where any errors will expose matters that should not anyway be public.

This is what needs to be addressed, and not by even more layers of 
complexity either.)

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

#148292

On Friday, November 29, 2019 at 10:02:23 AM UTC-3, Bart wrote:
> On 29/11/2019 12:08, Thiago Adams wrote:
> > On Friday, November 29, 2019 at 8:41:29 AM UTC-3, David Brown wrote:
> > ...
> >> Thus you can make classes, use RAII for resource control, have
> >> unique_ptr's for memory handling, store data in std::vectors, work with
> >> std::string - all without ever writing or seeing the word "template", or
> >> understanding rvalue references, or getting your head around
> >> "enable_if".  Many of C++'s more complex features exist primarily so
> >> that the standard library (and other libraries) can be written, so that
> >> application code writers can get efficient code without having to
> >> understand these complexities.
> > 
> > Recently, a beginner colleague of mine call me saying:
> > 
> > "Please look at this error..."
> > 
> > The error was really big.
> > 
> > I don't remember the details, but we had an object used included
> > in some container.
> > 
> > Like this:
> > 
> > class X {
> >      int i;
> > };
> > 
> > 
> > int main() {
> >      std::vector<X> v;
> >      X x;
> >      v.push_back(x);
> > }
> >      
> > and he was adding a new member at X.
> > 
> > class Y {int i;};
> > 
> > class X {
> >      unique_ptr<Y> sp; // <- Like this
> >      int i;
> > };
> > 
> > Then the program stop to compile.
> > If you put this example online (which is much smaller than the real
> > case) we have these errors:
> > 
> > In file included from /usr/include/x86_64-linux-gnu/c++/6/bits/c++allocator.h:33:0,
> >                   from /usr/include/c++/6/bits/allocator.h:46,
> >                   from /usr/include/c++/6/string:41,
> >                   from /usr/include/c++/6/bits/locale_classes.h:40,
> >                   from /usr/include/c++/6/bits/ios_base.h:41,
> >                   from /usr/include/c++/6/ios:42,
> >                   from /usr/include/c++/6/ostream:38,
> >                   from /usr/include/c++/6/iostream:39,
> 
> >                   from main.cpp:9:
> 
> ....
> 
> > As we can see, just adding a unique_ptr give us an error that requires
> > a lot of knowledge about the language to fix it, or at least, understand
> > why it is not working.
> > He was not trying to use advanced c++ features.
> 
> This is a point I sometimes make.
> 
> Because these features are implemented in user-code (ie. code written in 
> C++ rather then being part of the language proper), then error messages 
> tend to be in terms of violations that are invoked within those large 
> libraries.
> 
> And those are going to be meaningless to someone who only knows about 
> how to use a feature, not how it's implemented.

Exactly.
 
> Perhaps what is needed is yet another set of features that ring-fence 
> such libraries, which trap any compiler errors, and turn them into a set 
> of friendlier, more relevant messages.
> 
> Or perhaps not...
> (I'm actually working on something related, implementing features 
> equivalent to std::vector and std::string, but built-in. Those 
> implementations are also largely aided by libraries written in the same 
> language. But the libraries are pre-compiled and pre-tested.
> 
> No compiler error that arises out of the misuse of 'vector' or 'string' 
> will refer to its implementation code, but only directly in terms of how 
> they ought to be used.
> 
> Now, here, I don't use techniques such as templates which require all 
> that implementation code to be recompiled, with user-types plugged in, 
> and where any errors will expose matters that should not anyway be public.
> 
> This is what needs to be addressed, and not by even more layers of 
> complexity either.)

Are you trying to add string as extension to C or in our other language?

string type exists in every high level language - there is nothing
to invent here just copy Swift, Kotlin etc..

c string, or a sequence of char* terminated with 0, is part of 
the C language and it is compatible with string literals.


On the other hand, C++ tried to expand the type system by library.
It didn't changed the string literal like other high languages did.

When I use C++ I don't consider std::string or smart pointer as a type
that represents strings or pointers, instead I consider both as 
container of 1 element - This is what they really are.

In C++, std::string, vector, and smart pointers are trying to mimic 
original types overloading operators but they are never 100% compatible
with the original types. 

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

#148297

On 29/11/2019 14:43, Thiago Adams wrote:
> On Friday, November 29, 2019 at 10:02:23 AM UTC-3, Bart wrote:

>> (I'm actually working on something related, implementing features
>> equivalent to std::vector and std::string, but built-in. Those
>> implementations are also largely aided by libraries written in the same
>> language. But the libraries are pre-compiled and pre-tested.
>>
>> No compiler error that arises out of the misuse of 'vector' or 'string'
>> will refer to its implementation code, but only directly in terms of how
>> they ought to be used.
>>
>> Now, here, I don't use techniques such as templates which require all
>> that implementation code to be recompiled, with user-types plugged in,
>> and where any errors will expose matters that should not anyway be public.
>>
>> This is what needs to be addressed, and not by even more layers of
>> complexity either.)
> 
> Are you trying to add string as extension to C or in our other language?

In the non-C one.


> string type exists in every high level language - there is nothing
> to invent here just copy Swift, Kotlin etc..

Adding high-level string types to a low-level language is tricky.

I did manage it earlier this year, but abandoned it as the approach was 
too complex to scale to other high level types, which had extra problems.

Now I'm trying to introduce a single dynamic type, one that provides not 
only the same high-level facilities for strings, but also for lists 
(mixed types), arrays (same types), dicts, sets, big-nums and so on.

The implementation won't be fast, but it will be a starting point, and 
will make it easy to code things in the low-level language when 
performance doesn't matter (UI and interactive code for example, or for 
scripting), without having to use a separate language.

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

#148282

On 29/11/2019 13:08, Thiago Adams wrote:
> On Friday, November 29, 2019 at 8:41:29 AM UTC-3, David Brown wrote:
> ...
>> Thus you can make classes, use RAII for resource control, have
>> unique_ptr's for memory handling, store data in std::vectors, work with
>> std::string - all without ever writing or seeing the word "template", or
>> understanding rvalue references, or getting your head around
>> "enable_if".  Many of C++'s more complex features exist primarily so
>> that the standard library (and other libraries) can be written, so that
>> application code writers can get efficient code without having to
>> understand these complexities.
> 
> Recently, a beginner colleague of mine call me saying:
> 
> "Please look at this error..."
> 
> The error was really big. 
> 
> I don't remember the details, but we had an object used included 
> in some container.
> 
> Like this:
> 
> class X {
>     int i;
> };
> 
> 
> int main() {
>     std::vector<X> v;
>     X x;
>     v.push_back(x);
> }
>     
> and he was adding a new member at X.
> 
> class Y {int i;};
> 
> class X {
>     unique_ptr<Y> sp; // <- Like this
>     int i;
> };
> 
> Then the program stop to compile. 
> If you put this example online (which is much smaller than the real 
> case) we have these errors:
> 
> In file included from /usr/include/x86_64-linux-gnu/c++/6/bits/c++allocator.h:33:0,
>                  from /usr/include/c++/6/bits/allocator.h:46,
>                  from /usr/include/c++/6/string:41,
>                  from /usr/include/c++/6/bits/locale_classes.h:40,
>                  from /usr/include/c++/6/bits/ios_base.h:41,
>                  from /usr/include/c++/6/ios:42,
>                  from /usr/include/c++/6/ostream:38,
>                  from /usr/include/c++/6/iostream:39,
>                  from main.cpp:9:
> /usr/include/c++/6/ext/new_allocator.h: In instantiation of ‘void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up = X; _Args = {const X&}; _Tp = X]’:
> /usr/include/c++/6/bits/alloc_traits.h:475:4:   required from ‘static void std::allocator_traits<std::allocator<_CharT> >::construct(std::allocator_traits<std::allocator<_CharT> >::allocator_type&, _Up*, _Args&& ...) [with _Up = X; _Args = {const X&}; _Tp = X; std::allocator_traits<std::allocator<_CharT> >::allocator_type = std::allocator<X>]’
> /usr/include/c++/6/bits/stl_vector.h:918:30:   required from ‘void std::vector<_Tp, _Alloc>::push_back(const value_type&) [with _Tp = X; _Alloc = std::allocator<X>; std::vector<_Tp, _Alloc>::value_type = X]’
> <span class="error_line" onclick="ide.gotoLine('main.cpp',28)">main.cpp:28:18</span>:   required from here
> /usr/include/c++/6/ext/new_allocator.h:120:4: error: use of deleted function ‘X::X(const X&)’
>   { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }
>     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> main.cpp:17:7: note: ‘X::X(const X&)’ is implicitly deleted because the default definition would be ill-formed:
>  class X
>        ^
> main.cpp:17:7: error: use of deleted function ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with _Tp = Y; _Dp = std::default_delete]’
> In file included from /usr/include/c++/6/memory:81:0,
>                  from main.cpp:11:
> /usr/include/c++/6/bits/unique_ptr.h:361:7: note: declared here
>        unique_ptr(const unique_ptr&) = delete;
>        ^~~~~~~~~~
> 
> 
> 
> As we can see, just adding a unique_ptr give us an error that requires
> a lot of knowledge about the language to fix it, or at least, understand
> why it is not working.
> He was not trying to use advanced c++ features.
> 

Error messages from code that uses templates can be a challenge, that is
unfortunately true.  Compilers are getting better at this (gcc's
messages improved a lot after people pointed out that clang did a much
better job).  But there is a lot of scope for improvement.

The conflict here is that having a "unique_ptr" means you can't copy the
object - the pointer is unique.  And "push_back" puts a copy of the
object in the vector.  The error message "note: ‘X::X(const X&)’ is
implicitly deleted because the default definition would be ill-formed"
tells you this.

But it would be nice if the error messages could omit all the parts
about allocators.  When you use a template that has default parameters,
and leave these parameters unchanged, there is no benefit in mentioning
them in the messages.

I have filed a gcc bug report asking for improved messages here.  I
don't know if it is realistic or not, but filing a report is the way to
find out.

<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727>

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web