Where can I begin learning C/C++?

[Heater]

plugwash,

Expected by who though? that is the question.

I was thinking of these people: WG21 (ISO C++ Committee): https://isocpp.org/wiki/faq/wg21 The people, starting with Bjarne Stroustrup who have invested a large part of their lives into creating C++.

When Stroustrup added classes to C he obviously had a desire to be able to program in a particular way using classes and objects which was not easy or even possible to do in C. He had created a new tool and had some vision as to how people should use it.

Similarly when templates were added to C++ enabling generic and meta programming.

Similarly with the algorithms of the STL aimed at a promoting a more declarative style of programming rather than endlessly rewriting variations of the "for" loop.

All these new features have come to C++ with the intention that they are used. Used to enable easier programming, better correctness, better performance and so on.

Many of those features have come with the intention that they displace use of older features for better, more robust ones. For example use of new/delete is now discouraged, auto_ptr is obsolete, STL algorithms are preferred over "for" loops, etc, etc,

In short C++ today is a very different language than it was twenty years ago.

As far as I can tell today there is a lack of books and tutorials for beginners that focus on that "new C++". Beginners are faced with a bewildering number of older materials. Or newer books that explore features in a very advanced way.

Perhaps it's just not possible. Back in the day Scott Meyers was the source of such books, he seems to have bailed on C++ due to it's excessive complexity!

[sal55]

plugwash,

Expected by who though? that is the question.

I was thinking of these people: WG21 (ISO C++ Committee): https://isocpp.org/wiki/faq/wg21 The people, starting with Bjarne Stroustrup who have invested a large part of their lives into creating C++.

When Stroustrup added classes to C he obviously had a desire to be able to program in a particular way using classes and objects which was not easy or even possible to do in C. He had created a new tool and had some vision as to how people should use it.

Similarly when templates were added to C++ enabling generic and meta programming.

This is where I disagree with this whole 'language building' aspect of C++. Classes, templates, meta-classes (whatever they are) and so on are not in themselves useful, but are needed to achieve an end, such as near first-class handling of dynamic strings and arrays.

Yet the humblest script language already has those built in, without needing any classes. (And dynamic types gives you generics for free.)

Each time you use a feature like the vector class in C++, you have to recompile the implementation code for it. All the machinery needed to give the things you really want to use, is exposed. It makes for a far more complex and cumbersome language, with frightful syntax. And undecipherable error messages, even if you leave out one comma, that go on for pages.

Hardly a beginners' language, even if they can do a good job of dressing it up, such as on Arduino. Actually, it's hardly a language for anyone, IMO.

(I've tried the Arduino IDE; I found there are 5 processing stages (on a PC) in order to get a source program into the device. The first stage coverts the friendly source code you type in, into actual C++. The next 4 involving compiling that, then invoking some hefty 0.8MB utilitities to convert the result into suitable binary formats, and to upload it via USB. This is where I lost interest as I couldn't control that process.)

[dsyleixa123]

Arduino IS NOT C++, it USES C++, providing a high level-API for a convenient way to use different MCUs (AVR, SAM, SAMD, ESP) also by non-professional pogrammers (by help of Go and java IDE "processings"):
https://arduinohistory.github.io/
http://people.interactionivrea.org/h.ba ... ow_res.pdf
the "hefty 0.8MB utilitities" are basically C and C++ libs (for MCU cores and Arduino C++ classes), and Arduino does not forbid you to write your own completely correct and valid C++ code, there is no wizardry about it.
This approach makes Arduino an ideal base for beginners to learn C and C ++ by doing 8)

[sal55]

Arduino IS NOT C++, it USES C++, providing a high level-API for a convenient way to use different MCUs (AVR, SAM, SAMD, ESP) also by non-professional pogrammers (by help of Go and java IDE "processings"):
https://arduinohistory.github.io/
http://people.interactionivrea.org/h.ba ... ow_res.pdf
the "hefty 0.8MB utilitities" are basically C and C++ libs (for MCU cores and Arduino C++ classes), and Arduino does not forbid you to write your own completely correct and valid C++ code, there is no wizardry about it.
This approach makes Arduino an ideal base for beginners to learn C and C ++ by doing 8)

The two I had in mind (looking in my Arduino directory) would be objcopy.exe or objdump.exe, possibly both.

(I remember working in a placement in the 1970s using an ICL mainframe, where one of the biggest programs that you could run, 'TKB' which was some sort of complicated linker, took up 750KB, most of the memory available for this time-sharing system. These utilities for converting a few hundred bytes of object code and sending it to a microprocessor, are bigger than that. Being around computing a long time gives you a useful sense of perspective!)

And I think everyone knows that Arduino is not C++, but you have to use C++ to program it in a HLL, unless there are alternatives that I don't know about. The 260MB Arduino directory includes g++.exe. Such a small device limits the size of program you can write, so 'build times' may not be significant, but having to use C++ grates if you are not a fan of that language.

[dsyleixa123]

what do you mean by "such a small device"?
Arduino supports really small AVRs with 16MHz/2.5 kB RAM, but also really big ones (ARM Cortex-M4 with Floating Point Unit, or ESP32) up to 180MHz/1M Flash/256K RAM and perhaps more (feat. stdio.h, RTOS, std::thread 8) ), and anything in between.
Of course most MCU C/C++ libs are down-sized for MCUs, not having all the complete POSIX lbs for Linux. Anyway, it's enough to learn about C/C++.

[sal55]

what do you mean by "such a small device"?
Arduino supports really small AVRs with 16MHz/2.5 kB RAM, but also really big ones (ARM Cortex-M4 with Floating Point Unit, or ESP32) up to 180MHz/1M Flash/256K RAM and perhaps more (feat. stdio.h, RTOS, std::thread 8) ), and anything in between.
Of course most MCU C/C++ libs are down-sized for MCUs, not having all the complete POSIX lbs for Linux. Anyway, it's enough to learn about C/C++.

OK, I associated Arduino with the AVR. I don't know it also works with other processors.

The AVR processor I played with I think had 32KB RAM.

[Heater]

jcyr,

Citations please...

Well that is the topic of discussion here. The lack of up to date books, tutorials and other guides for modern C++. If I knew of any I would cite them

For now the statement I made is born out of watching all the presentations at CppCon for the past two or three years. Many of which discuss the topic of programming in "modern" C++ and how it should be introduced to beginners in C++.

If you watch here: https://www.youtube.com/user/CppCon/playlists you will find a lot of talk about how: new/delete is now discouraged, auto_ptr is obsolete, STL algorithms are preferred over "for" loops, etc, etc,...

They are the people designing and implementing all this new stuff in C++ and that is what they have in mind.

Sadly they no longer have guys like Scott Meyers to produce new books such materials to go with it.

[dsyleixa123]

OK, I associated Arduino with the AVR. I don't know it also works with other processors.
The AVR processor I played with I think had 32KB RAM.

It's actually one of the biggest advantages of Arduino: 1 highlevel API which fits all boards by providing tons of different cores.

[Heater]

jcyr,

I don't think the implementation of new features explicitly discourages the use of old ones.

Certainly the designers and implementers of the new features have exactly that in mind.

For example: In the old days we created objects with "new" and then had to remember to use "delete" to avoid memory leaks. If you were clever you created some kind of "smart pointer" that did reference counting so that new and delete were taken care of automatically by your smart pointer. No more memory leak mistakes.

At some point that practice got standardized with auto_ptr, use of new/delete was discouraged.

Later came shared_ptr, unique_ptr, whatever_ptr when it was realized that auto_ptr was not very good. Use of auto_ptr is discouraged.

There are many other examples of discouraged C++ usage. See the CppCon presentations.

It is a valuable aspect of C++ that everything that has ever been supported, still is!

That is very true. They go out of their way to ensure backwards compatibility so that old code does not break. Whilst at the same time encouraging adoption of new facilities and dropping old ones for new code.

It goes so far as being able to correctly compile pure C code.

Almost. C++ does not support the variable length arrays of C and likely never will, it's a broken miss-feature. And a bunch of other stuff: https://en.wikipedia.org/wiki/Compatibi ... t_not_in_C++

[Heater]

jcyr,

I'm pretty sure you will find that C++ smart pointers do not do any extra allocations on the heap. They exist on the stack and get passed around like other plain old data. There are no extra calls to constructors and destructors for them. In fact I think unique_ptr get's compiled down to just a normal pointer value anyway. As such the performance hit is zero.

They are there if you need them and experience shows that you don't need much of a big code base or many people working on it before the ownership of data gets very vague and it's hard to figure out when one can delete what. Result: use after free or memory leak bugs to find. Or race conditions in threaded programs which can get very hard to find.

You get to choose your poison.

Yep.

There is enough rope in C++ to hang yourself a hundred different ways everyday. I have yet to find the best rope

[jachaney]

Herb Schildt! A Beginner's Guide to C++.
Good examples, great structure, and wonderful coverage of overloading, and class structure.

Use Code:Blocks for an IDE, and start with a simple console application for the "hello, world!" I can be installed easily using `sudo apt-get install codeblocks`

Look up GTK+ documentation for making GUI based applications. I use the 2.0 version and downloaded the development libraries with `sudo apt-get install libgtk2.0-dev`. Then added `pkg-config --cflags gtk+-2.0` to the include path, and `pkg-config --libs gtk+-2.0` to the additional libraries.

[plugwash]

I'm pretty sure you will find that C++ smart pointers do not do any extra allocations on the heap.

That depends on what type of smart pointer you are talking about and how you create it.

unique_ptr and the deprecated auto_ptr do just exist on the stack. shared_ptr on the other hand needs a "control block" stored on the heap. If you use make_shared then most implementations will allocate a single memory block for both the control block and the pointed-to object. If you make a shared_ptr from an existing pointer then the control block will be allocated seperately on the heap.

They exist on the stack and get passed around like other plain old data.

Smart pointers do have constructors and destructors and hence can't generally be passed and returned in registers.

shared/weak pointers also have the overhead of incrementing and decrementing reference counts.

[charels]

I don't get why people try to scare off others from c++ because of its depth. It is deep but not any more complex than lots of other languages if you don't think to yourself that you "have" to use all of its features.

If you just focus on this it really isn't that bad and you can still do a lot of things:

- Global variables
- Local Variables
- Functions
- while loops
- for loops
- variables (int,string,bool,float)
- Comparisons (if 5 <10 do something)
- importing

This is almost identical in all languages, so why not just learn it in C++? This is like 80% of coding anyways I could probably write our instruments entire software other than the GUI with just these features, will it be good? no. But I could still do it.

[Heater]

charels,

I don't get why people try to scare off others from c++ because of its depth.

I do it because C++ scares me. And I have been using it for twenty years.

When we teach children to swim we start them in the shallow pool. Why do we do that? We could just throw them in the deep end and walk away. After all, they don't need to use all that water underneath them do they?

On the other hand I tend to agree. Presented in the right way and with appropriate guidance C++ is as easy to teach beginners as any other.

Which is nicely demonstrated, with comparison to other languages, here: Patrice Roy “C++ as a First Language... Really?” https://www.youtube.com/watch?v=AyhPigwhwbk

At the end of the day, it's not the depth of C++ that scares me. If you see a feature you don't understand in some source you can generally find out. What scares me is it's failure modes, often silent, unpredictable, deadly. Hard to find and rectify therefore expensive.

[sal55]

At the end of the day, it's not the depth of C++ that scares me. If you see a feature you don't understand in some source you can generally find out. What scares me is it's failure modes, often silent, unpredictable, deadly. Hard to find and rectify therefore expensive.

It is all the massive complex machinery just below the surface that scares me. This a C++ hello world program:

Code: Select all

#include <iostream>

int main()
{
    std::cout << "Hello, world!\n";
}

Seems innocuous enough, after you accept the peculiar way you have to do output. But look what happens when you type >> instead of << (scroll through):

Code: Select all

Error(s):
source_file.cpp(7): 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(7): 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(7): 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(7): 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(7): 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(7): 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(7): 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(7): error C2676: binary '>>': 'std::ostream' does not define this operator or a conversion to a type acceptable to the predefined operator

That was from MSVC; using g++ you get (again scroll through to see the extent):

Code: Select all

Error(s):
source_file.cpp: In function ‘int main()’:
source_file.cpp:7:15: error: no match for ‘operator>>’ (operand types are ‘std::ostream {aka std::basic_ostream<char>}’ and ‘const char [15]’)
     std::cout >> "Hello, world!\n";
               ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:924:5: note: candidate: template<class _CharT, class _Traits, class _Tp> std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&&, _Tp&)
     operator>>(basic_istream<_CharT, _Traits>&& __is, _Tp& __x)
     ^
/usr/include/c++/5/istream:924:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<_CharT, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:808:5: note: candidate: template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, signed char*)
     operator>>(basic_istream<char, _Traits>& __in, signed char* __s)
     ^
/usr/include/c++/5/istream:808:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<char, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:803:5: note: candidate: template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, unsigned char*)
     operator>>(basic_istream<char, _Traits>& __in, unsigned char* __s)
     ^
/usr/include/c++/5/istream:803:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<char, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:761:5: note: candidate: template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, signed char&)
     operator>>(basic_istream<char, _Traits>& __in, signed char& __c)
     ^
/usr/include/c++/5/istream:761:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<char, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:

And this is for a very simple error where you can easily see what might be wrong. It's just the error messages that are impenetrable. The reason is that it is not reporting directly on the error in the source, but an error that is generated when it tries to compile the implementation code for 'cout' and '<<' and '>>', which is in C++ also, and which will not make sense to anyone unfamiliar with what is inside and can only see what they themselves have written.

This is a big problem with using meta-programming to implement language features that ought to be built-in.

This language should not be let anyway near a beginner. (I only saw a few bits of the video you posted; did it show what to do about impossibly long-winded and arcane error messages when you get something wrong?)

[Heater]

That is a good point. The eruption of C++ error messages can be overwhelming even for the experienced.

I have been playing with Rust recently. It also has polymorphism and meta-program via a sophisticated macro system. Despite that Rust's error messages are amazingly succinct and helpful, even offering suggestions to fix the problem that actually work. It's kind of fun having a chat with the Rust compiler as you fumble around trying to get something to compile.

I think the Rust guys have the perspective that failure is the normal case so the language design had better try and make that as least unpleasant as possible. They even refer to it as "ergonomics" in language design.

[Paeryn]

It is all the massive complex machinery just below the surface that scares me. This a C++ hello world program:

Code: Select all

#include <iostream>

int main()
{
    std::cout << "Hello, world!\n";
}

Seems innocuous enough, after you accept the peculiar way you have to do output. But look what happens when you type >> instead of << (scroll through):

Code: Select all

Error(s):
source_file.cpp(7): 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(7): 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(7): 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(7): 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(7): 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(7): 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(7): 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(7): error C2676: binary '>>': 'std::ostream' does not define this operator or a conversion to a type acceptable to the predefined operator

That was from MSVC; using g++ you get (again scroll through to see the extent):

Code: Select all

Error(s):
source_file.cpp: In function ‘int main()’:
source_file.cpp:7:15: error: no match for ‘operator>>’ (operand types are ‘std::ostream {aka std::basic_ostream<char>}’ and ‘const char [15]’)
     std::cout >> "Hello, world!\n";
               ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:924:5: note: candidate: template<class _CharT, class _Traits, class _Tp> std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&&, _Tp&)
     operator>>(basic_istream<_CharT, _Traits>&& __is, _Tp& __x)
     ^
/usr/include/c++/5/istream:924:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<_CharT, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:808:5: note: candidate: template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, signed char*)
     operator>>(basic_istream<char, _Traits>& __in, signed char* __s)
     ^
/usr/include/c++/5/istream:808:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<char, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:803:5: note: candidate: template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, unsigned char*)
     operator>>(basic_istream<char, _Traits>& __in, unsigned char* __s)
     ^
/usr/include/c++/5/istream:803:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<char, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:
/usr/include/c++/5/istream:761:5: note: candidate: template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, signed char&)
     operator>>(basic_istream<char, _Traits>& __in, signed char& __c)
     ^
/usr/include/c++/5/istream:761:5: note:   template argument deduction/substitution failed:
source_file.cpp:7:18: note:   ‘std::ostream {aka std::basic_ostream<char>}’ is not derived from ‘std::basic_istream<char, _Traits>’
     std::cout >> "Hello, world!\n";
                  ^
In file included from /usr/include/c++/5/iostream:40:0,
                 from source_file.cpp:3:

And this is for a very simple error where you can easily see what might be wrong. It's just the error messages that are impenetrable. The reason is that it is not reporting directly on the error in the source, but an error that is generated when it tries to compile the implementation code for 'cout' and '<<' and '>>', which is in C++ also, and which will not make sense to anyone unfamiliar with what is inside and can only see what they themselves have written.

They both do report on the error in the source :-

MSVC looks to list the error as it tried to expand the templates and finally shows you the error in your source code.

G++ lists the error in your source code first and then shows you how it tried to expand the templates.

MSVC makes it easier to see as the error in your source code is the last thing printed and so is likely to still be on-screen without having to scroll up.

G++ makes it easier to read sequentially as the error is closer to the command line used. By the way, g++9 produces clearer error reports than 5 (writing this on my phone so I can't copy-paste its output).

They print the expansions as they show the exact error the compiler found when expanding the templates.

[jahboater]

g++ 9.2 gives:-

Code: Select all

$ g++ try.cpp
try.cpp: In function 'int main()':
try.cpp:5:12: error: no match for 'operator>>' (operand types are 'std::ostream' {aka 'std::basic_ostream<char>'} and 'const char [15]')
    5 |  std::cout >> "Hello, world!\n";
      |  ~~~~~~~~~ ^~ ~~~~~~~~~~~~~~~~~
      |       |       |
      |       |       const char [15]
      |       std::ostream {aka std::basic_ostream<char>}
In file included from /usr/local/include/c++/9.2.0/string:56,
                 from /usr/local/include/c++/9.2.0/bits/locale_classes.h:40,
                 from /usr/local/include/c++/9.2.0/bits/ios_base.h:41,
                 from /usr/local/include/c++/9.2.0/ios:42,
                 from /usr/local/include/c++/9.2.0/ostream:38,
                 from /usr/local/include/c++/9.2.0/iostream:39,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/bits/basic_string.tcc:1466:5: note: candidate: 'template<class _CharT, class _Traits, class _Alloc> std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&)'
 1466 |     operator>>(basic_istream<_CharT, _Traits>& __in,
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/bits/basic_string.tcc:1466:5: note:   template argument deduction/substitution failed:
try.cpp:5:15: note:   'std::ostream' {aka 'std::basic_ostream<char>'} is not derived from 'std::basic_istream<_CharT, _Traits>'
    5 |  std::cout >> "Hello, world!\n";
      |               ^~~~~~~~~~~~~~~~~
In file included from /usr/local/include/c++/9.2.0/istream:991,
                 from /usr/local/include/c++/9.2.0/iostream:40,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/bits/istream.tcc:931:5: note: candidate: 'template<class _CharT, class _Traits> std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT&)'
  931 |     operator>>(basic_istream<_CharT, _Traits>& __in, _CharT& __c)
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/bits/istream.tcc:931:5: note:   template argument deduction/substitution failed:
try.cpp:5:15: note:   'std::ostream' {aka 'std::basic_ostream<char>'} is not derived from 'std::basic_istream<_CharT, _Traits>'
    5 |  std::cout >> "Hello, world!\n";
      |               ^~~~~~~~~~~~~~~~~
In file included from /usr/local/include/c++/9.2.0/iostream:40,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/istream:756:5: note: candidate: 'template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, unsigned char&)'
  756 |     operator>>(basic_istream<char, _Traits>& __in, unsigned char& __c)
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/istream:756:5: note:   template argument deduction/substitution failed:
try.cpp:5:15: note:   'std::ostream' {aka 'std::basic_ostream<char>'} is not derived from 'std::basic_istream<char, _Traits>'
    5 |  std::cout >> "Hello, world!\n";
      |               ^~~~~~~~~~~~~~~~~
In file included from /usr/local/include/c++/9.2.0/iostream:40,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/istream:761:5: note: candidate: 'template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, signed char&)'
  761 |     operator>>(basic_istream<char, _Traits>& __in, signed char& __c)
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/istream:761:5: note:   template argument deduction/substitution failed:
try.cpp:5:15: note:   'std::ostream' {aka 'std::basic_ostream<char>'} is not derived from 'std::basic_istream<char, _Traits>'
    5 |  std::cout >> "Hello, world!\n";
      |               ^~~~~~~~~~~~~~~~~
In file included from /usr/local/include/c++/9.2.0/istream:991,
                 from /usr/local/include/c++/9.2.0/iostream:40,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/bits/istream.tcc:963:5: note: candidate: 'template<class _CharT2, class _Traits2> std::basic_istream<_CharT, _Traits>& std::operator>>(std::basic_istream<_CharT, _Traits>&, _CharT2*)'
  963 |     operator>>(basic_istream<_CharT, _Traits>& __in, _CharT* __s)
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/bits/istream.tcc:963:5: note:   template argument deduction/substitution failed:
try.cpp:5:15: note:   'std::ostream' {aka 'std::basic_ostream<char>'} is not derived from 'std::basic_istream<_CharT, _Traits>'
    5 |  std::cout >> "Hello, world!\n";
      |               ^~~~~~~~~~~~~~~~~
In file included from /usr/local/include/c++/9.2.0/iostream:40,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/istream:803:5: note: candidate: 'template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, unsigned char*)'
  803 |     operator>>(basic_istream<char, _Traits>& __in, unsigned char* __s)
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/istream:803:5: note:   template argument deduction/substitution failed:
try.cpp:5:15: note:   'std::ostream' {aka 'std::basic_ostream<char>'} is not derived from 'std::basic_istream<char, _Traits>'
    5 |  std::cout >> "Hello, world!\n";
      |               ^~~~~~~~~~~~~~~~~
In file included from /usr/local/include/c++/9.2.0/iostream:40,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/istream:808:5: note: candidate: 'template<class _Traits> std::basic_istream<char, _Traits>& std::operator>>(std::basic_istream<char, _Traits>&, signed char*)'
  808 |     operator>>(basic_istream<char, _Traits>& __in, signed char* __s)
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/istream:808:5: note:   template argument deduction/substitution failed:
try.cpp:5:15: note:   'std::ostream' {aka 'std::basic_ostream<char>'} is not derived from 'std::basic_istream<char, _Traits>'
    5 |  std::cout >> "Hello, world!\n";
      |               ^~~~~~~~~~~~~~~~~
In file included from /usr/local/include/c++/9.2.0/iostream:40,
                 from try.cpp:1:
/usr/local/include/c++/9.2.0/istream:980:5: note: candidate: 'template<class _Istream, class _Tp> typename std::enable_if<std::__and_<std::__not_<std::is_lvalue_reference<_Tp> >, std::__is_convertible_to_basic_istream<_Istream>, std::__is_extractable<typename std::__is_convertible_to_basic_istream<_Tp>::__istream_type, _Tp&&, void> >::value, typename std::__is_convertible_to_basic_istream<_Tp>::__istream_type>::type std::operator>>(_Istream&&, _Tp&&)'
  980 |     operator>>(_Istream&& __is, _Tp&& __x)
      |     ^~~~~~~~
/usr/local/include/c++/9.2.0/istream:980:5: note:   template argument deduction/substitution failed:
/usr/local/include/c++/9.2.0/istream: In substitution of 'template<class _Istream, class _Tp> typename std::enable_if<std::__and_<std::__not_<std::is_lvalue_reference<_Tp> >, std::__is_convertible_to_basic_istream<_Istream>, std::__is_extractable<typename std::__is_convertible_to_basic_istream<_Tp>::__istream_type, _Tp&&, void> >::value, typename std::__is_convertible_to_basic_istream<_Tp>::__istream_type>::type std::operator>>(_Istream&&, _Tp&&) [with _Istream = std::basic_ostream<char>&; _Tp = const char (&)[15]]':
try.cpp:5:15:   required from here
/usr/local/include/c++/9.2.0/istream:980:5: error: no type named 'type' in 'struct std::enable_if<false, void>'
$ 

[Heater]

Finally the world catches up with me!

Towards the end of last century I was contracted to build a program to translate the file format of one electronics design package to the format of another. Of course I had to detect errors in the input and produce appropriate messages. I thought it would be neat to point out where the error is exactly, like so:

Code: Select all

foo = 123
------^
Error XXX, filename: blabla, line: 123: colum: 7

The client company thought I had been frivolous is adding that unspecified feature and discussed asking me to remove it!

It's nice to see gcc catching up with me 25 years later

Seems GCC got the idea from the Rust which does it really nicely:

Code: Select all

$ cat temp.rs
fn main () {
    println!("Hello world);
}

$ rustc temp.rs
error: unterminated double quote string
 --> temp.rs:2:14
  |
2 |       println!("Hello world);
  |  ______________^
3 | | }
4 | |
  | |_^

error: aborting due to previous error

Here it shows where it detected the error when it discovered mismatched braces, but then points back to where you actually forgot to close the string.

Which looks even better with the colour highlighting they use.

[Paeryn]

I take it you held your ground, especially if you had already implemented it!

GCC has been printing a caret showing the start position of the error on the line for quite a while but it used to be just that. I think it was in 6 that they added tildes with it to highlight the extent of the error rather than just the character where it happened.

They've improved the error reports in GCC at lot, but I agree Rust has very good error reports, I think that was important to them from the start.

[ejolson]

Here it shows where it detected the error when it discovered mismatched braces, but then points back to where you actually forgot to close the string.

Which looks even better with the colour highlighting they use.

Is there any way to turn off all that ASCII art? It's filling my screen and causing the error messages to scroll off the top.

[Heater]

ejolson,

Is there any way to turn off all that ASCII art? It's filling my screen and causing the error messages to scroll off the top.

Yes, don't write any errors in your source code

I find that ASCII art very useful when the borrow checker is indicating what I incorrectly borrowed and from where. I don't often get masses of errors, probably because I chip away slowly, hitting "cargo check" after every couple of lines I add...

Turns out there is a github issue and discussion about your request:
https://github.com/rust-lang/rust/issues/27189

With some work arounds to trim down the number of errors for now.

[jahboater]

Is there any way to turn off all that ASCII art? It's filling my screen and causing the error messages to scroll off the top.

Not the same, but you can reduce the amount of error message output from gcc:

Code: Select all

$ g++ -Werror -Wfatal-errors try.cpp
try.cpp: In function 'int main()':
try.cpp:5:12: error: no match for 'operator>>' (operand types are 'std::ostream' {aka 'std::basic_ostream<char>'} and 'const char [15]')
    5 |  std::cout >> "Hello, world!\n";
      |  ~~~~~~~~~ ^~ ~~~~~~~~~~~~~~~~~
      |       |       |
      |       |       const char [15]
      |       std::ostream {aka std::basic_ostream<char>}
compilation terminated due to -Wfatal-errors.
$ 

[sal55]

Is there any way to turn off all that ASCII art? It's filling my screen and causing the error messages to scroll off the top.

Not the same, but you can reduce the amount of error message output from gcc:

Code: Select all

$ g++ -Werror -Wfatal-errors try.cpp

Yes, gcc takes the Build-Your-Own-Compiler approach by having to micro-manage every aspect of its behaviour via command line options, even down to refining the exact language you want to compile and whether some features should be allowed or not.

I've used gcc for C, and the output you get can be very unhelpful in terms of the quantity. There might be an actual error report but then hundreds of harmless warnings. But the error message, if any, has scrolled off the top of the screen. So did it compile successfully or not? Often the only hint is whether there is a delay after all the output, indicating that it is proceeding with the next stages rather than aborting, but there is no final message. You have to resort to scrolling the window, or capturing the output and scanning for errors, or capturing its return code, or even checking for whether a new executable exists!

So gcc itself is decidedly not beginner-friendly.

My own compilers are rather simple: there are no warnings, only hard errors. And they will show the first error and then stop. Then you can fix that one and try again (the compiler generates an info file that is picked up by my editor to take you straight to the error line in the right file). Since you have to fix one error at a time, why not show one error at a time? One error would often results in dozens of follow-up ones anyway if the compiler attempts to proceed.

We're not batch-compiling programs overnight anymore so that you have fix as much as possible to avoid wasting another day! Compilers, even gcc, are quick enough now, at least for the initial error-detecting phases, to just run them repeatedly. Quicker than perusing 18,000 lines of warnings anyway (which is what I've had on a 30,000 line input).

As for the error in my C++ example, that's not possible in any of my languages because it uses a sane means to do output ('print "Hello"), which is another obvious way of being more friendly. (Note that C++ can also make use of C's 'printf'-style functions to do output, also avoiding using the ugly std::cout and <<, but then you have to contend with 'format codes', which tells the compiler you are printing an integer, of a particular size and type, information it actually already knows.)

[Heater]

sal55,

Why do you insist on bashing on GCC for rather dubious reasons? GCC is a very fine C/C++ compiler.

Sure it has billions of options. I amost never use most of them, outside -Wall, 03, -o. It's great that they are there when you need them in some odd situation, otherwise the task would be impossible.

As shown above, modern versions have far better error messages.

If you are ignoring those hundreds of warnings you are doing the wrong thing. One should ensure there are no warnings. Fix them first! Trust me, they may look harmless but in the long run you will save a lot of bug hunting by not having them in the first place.

It's odd you should say GCC is not beginner friendly, thousands of Arduino users learn with it every day.

My own compilers ...

Ah, now I know why the bashing, you have created your own. Jolly good I say. What is it, where is it, can we use it? Does it produce code for x86, ARM, RISC V, and WASM? I need all of that from the same source just now.

I agree about the cout << thing. It's a damn ugly and verbose syntax, it's also amazingly slow to use if you need a lot of output. It should be taken out the back and shot.

prinf() takes a bit of getting used to for beginners, but it does a lot more than just "information it actually already knows already", like format things to your liking.