What Makes C++ "Hard"?

Go To Last Post
186 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Greetings -

 

I realize that this is an open-ended question and I hope that it does not descend into a "flame war" because I really am interested in this.

 

Hypothesis: Many see C++ as a difficult language. Example, Cliff recently wrote (Multi-File C++ #21):

 

I've only been doing C++ for about 5 years now, give it another 5 and I may finally "get it"

 I see a couple of top-level possibilities:

 

1. The complexity of the language, itself

 

2. Poor teaching about the language (Johan, excepted!)

 

3. Poor understanding of the language by those who try to use it.

 

My hunch is that all 3 play a role. If the language, itself, is the biggest part of it (items 2 & 3 would appear to be driven by item 1), what is it about the language?

 

1A - Many users come from C background, and some things have to be unlearned

 

1B - There is often more than one "right" way to accomplish a task (but that is true of C, also).

 

1C - There are techniques that seem superficially similar but are enough different to cause problems (pass-by-reference vs pointers comes to mind)

 

1D - The whole Class structure and the idea of "instances"

 

1E - Inheritance

 

1F - The idea that some things can be "private" and others "public"

 

1G - The fact that ALL of the above are together in a single language (but VisualBasic and XOJO have most of these attributes and are not generally considered "difficult")

 

I would like to hear from folks who ARE C++ users: what have been YOUR stumbling blocks to effective use of the language? And, folks who have tried and given up: what caused you to give up (beyond the generic "Its just too hard").

 

Lets keep it civil!

 

Cheers,

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim,

 

for now I choose to stay away from posting in this thread. I could easily have a lot to rant about, but I'm sure I could absolutely kill all other participation in it by rambling away as I often do.. ;-)

 

Rest assured that I will follow/read the activity here. Having been a teacher of programming languages I am always interested in how "the learner at the other end" thinks and feels.

 

My staying away from posting might change if I find pure errors, or "blatant misconceptions".

 

As you where, Gentlemen!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Johan,

 

Totally understand your position. My interest is how "us mere mortals" deal/have dealt with it. I am sure that you will have some useful input, once some comments have accumulated.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sat. Jul 8, 2017 - 05:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
I would like to hear from folks who ARE C++ users: what have been YOUR stumbling blocks to effective use of the language? And, folks who have tried and given up: what caused you to give up (beyond the generic "Its just too hard")....
I am a C++ user when a project absolutely requires it. Otherwise, I have found and try to promote labor saving alternatives.

- John

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And, what would those "labor saving alternatives" be? What about C++ pushes you to find labor saving alternatives?

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sat. Jul 8, 2017 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll get back to this. I have quite a lot to say but not really practical using a mobile while I'm out walking a cat! I need QWERTY,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who told you a language is hard if it takes 10 years to learn it?

 

JW (the C-hater -- I guess it makes me then C++ hater++)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jan, BRILLIANT link! Says it all really.
.
Oh and I'm intrigued he recommends Python as a first language. Couldn't agree more. Wish it had been around when I started!

Last Edited: Sat. Jul 8, 2017 - 07:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, this thread sounds promising, I'm trying to learn C++ myself. Not only is the language itself much more complex and powerful than C, but it's standard library is also much more complex than the one from C. So there is a lot to learn and this can be discouraging.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggest that you should start with Arduino.   e.g. ready-made libraries and class methods.

 

You don't need to know much more than how to write simple expressions and statements.

Acquire familiarity with building examples,   adapting for your project.

Ask questions with your "code" or complete Arduino project.

 

If you want to learn C++ from scratch,   follow complete Tutorials on a PC.    Dig a big hole and bury your Arduino until you have finished the course.

 

I am surprised that any course would "start" with templates.     I would expect to learn how to use expressions, loops,  library class methods,  ... before you ever write any class of your own.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Clarification: My motive for starting this thread was to try to find out where others have problems so that I would know where to focus a bit more energy. Second motive was an attempt to NOT become discouraged, knowing that others also have problems.

 

That said, if you really prefer another language that has comparable power to C++, it would be really interesting to know what the differences are, that makes Language (whatever) easier (to learn, to use) than Language C++. Again, please keep it civil. I an NOT asking which one is "better". What I AM asking is about the "features" of C++ that make it challenging compared to other languages of comparable capability. Or, maybe visa versa! This fits with my initial motives because A/B comparisons help to clarify where the real problems are.

 

For example, I could see someone writing: C++ is hard because it shares so much with C (and sometimes it is hard to keep track of which feature goes with which language). But, what makes it easier to learn is that it shares so much with C.

 

Thanks, everyone!

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Sat. Jul 8, 2017 - 09:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm at the point where I only futz with Arduino and assembler, and assembler only for AVRs that cost less than a dollar.  Arduino is C++ with extensions and downloadable libraries.  In brief:

 

The libraries provide a way to interact the host AVR with all the various peripherals, sensors, and break-out boards available.  The main() code is split into two sections: the setup() and the loop().  This is called the '.ino' file and is where the user interface is developed.

 

An include statement for a header file "#include myNewToy.h" gets placed at the very beginning of the code.  This calls the .cpp file of the same name as the header file and compiles the source code of the library.  To use this library, the programmer calls the constructor method and instanciates an object in SRAM for the class that is defined in the .h header file.  This gives the strange code line:

MYNEWTOY someNewToy  myNewToy;   An object 'someNewToy' of class MYNEWTOY as be created in SRAM using the class constructor myNewToy(). 

 

At this point, in the .ino file,  the programmer can call methods that are defined in the class such as:  someNewToy.init();   These methods are for the device, peripheral, or sensor described in the library .h  and  .cpp  only.  The presentation, manipulation, and storage of data from the device is done by the .ino cover program.   Standard topics in C++ study like inheritance, overloading, perverse polymophisim and likenot are written into the library source code, should the author be up to it.   Ordinary programmers who are trying to get a microcontroller to do something useful to them can ignore these topics until they have advanced to the point where these topics need to be mastered.

 

-- I think that the problem with C++ books is that the authors are trying to scale the language from student test programs to big corporation info-systems.  C++ can do this in theory, but this should not be attempted in books for beginners.  But the authors always do that.  Another thing is that C++ book authors always assume that C++ learners already have a solid background in programming C or some other procedural language.  But Arduino users are often "the soldering iron has two ends-one is hot" type of beginners.  They don't need a discussion of inheritance, overloading, perverse polymophisim to get some LCD screen to print "ON" when a switch is pushed.

 

   My two-cents worth in electronics/computer programming these days is: if no one is paying you to master a topic, and you don't need to technically master a topic to get your vision into your application, then only learn a brief overview of the specific topic.  This goes contrary to the 20th century technical ideal of learn a lot about everything.  But there is too much technology in the modern age to follow this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if no one is paying you to master a topic, and you don't need to technically master a topic

Yep, and that's even more to the point if the government is subsidizing your living with a pension...... devil

 

I'm starting to do just fun projects now, no need to destroy more brain cells than necessary.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have no intention of trying to "master the topic". I do, however, want to be able to do a bit more than follow a recipe!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One problem seems to be that C++ was designed to be lots of things, to different people, sort of  like PL/1.  (PL/1 was supposed to replace ForTran AND COBOL, but I'm pretty sure the programs produced by the ex-fortran programmers looked a lot different from the programs written by the ex-cobol programmers!)

 

That means that it supports multiple STYLES of programming, and there seems to be no end of people that are certain that your style is "NOT REAL C++."

This is especially true for embedded programming vs "big computer" programming.  For example, dynamic memory allocation (and the assumption that there is lots of memory to allocate) seems to be very "core" to a lot of C++ (or Java, or Python, or most any "object oriented" programming language), while there are large numbers of embedded programmers who think that it should NEVER be used.

 

I think Arduino did a reasonably good job of using some C++ concepts for an embedded environment, but I'm pretty sure that there are C++ programmers that are just APPALLED at some of the inconsistencies, design choices, and cavalier switching back-and-forth between C and C++ ("Why is Serial an object, but a PIN isn't?!"  "Why is "Serial", part of the top-level user API, NOT of a consistent type?")

 

There's a "half-joke" I sometimes make about being able to write C code in a dozen different (non-C) languages  (at least I forgot fortran!)

 

One observation I had is that C++ has some really strong advantages when you have "objects" that contain large amounts of compile-time initialized data.  This doesn't show up too much when programming microcontrollers, but if you ever contemplate setting up a a Windows GUI, with buttons and menus and such, in plain C, you might have a lightbulb go off...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't find surprising that C++ could take a decade to master. For example, I think I have a pretty good grasp of C, but then, when I realize this is possible:

 

int main() {
	if (*main == &main) (********main)();
}

... I think: "Much to learn, you still have."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Q. What Makes C++ "Hard"?

A. Because it was designed by Computer Scientists and not programmers.

 

Q.What Makes C++ "Hard"?

A. Because it was designed by committee.

 

Q. What Makes C++ "Hard"?

A. Because someone decided that OOP was a 'Good Thing' and what with C being the most popular programming language and all it was decided that C had to embrace OOP.

 

Q. What Makes C++ "Hard"?

A. Because for people programming microcontrollers it makes little sense to use it.

 

 

Michael Barr in his book 'Programming Embedded Systems in C and C++' has a section in the appendices called 'Limiting the Impact of C++'. If you dig around you can find a PDF of the book online. That section is an interesting read.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I'll break in..

Brian Fairchild wrote:
Michael Barr in his book 'Programming Embedded Systems in C and C++' has a section in the appendices called 'Limiting the Impact of C++'. If you dig around you can find a PDF of the book online. That section is an interesting read.

 

Not very "interesting" really. 2.5 pages where he essentially says

 

- Most OO features comes at no or a very reasonable cost

- Exceptions and Run Time Type Information comes with a (for small embedded systems) substantial cost

- Templates comes with a prohibitive cost - this is just wrong. Templates comes with no extra cost as compared to you yourself writing duplicate almost identical functions or classes

 

The whole treaty on 'Limiting the impact of C++' is less than 2.5 pages. The part about what to stay away from is one paragraph. The book is 18 years old. In this section Brian refers to is a sidebar about "Embedded C++", a 'standard' that never took off and now essentially a very dead thing.

 

Brian Fairchild wrote:
Because for people programming microcontrollers it makes little sense to use it.

I wonder what the people in the Arduino community would say about that..?

 

That's my take on Barr's treaty. I'll try to stay away again, so that us "politrucks" won't run over all you others..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

you might have a light bulb go off...

So is this an OOPs moment?? surprise devil

 

http://footage.framepool.com/shotimg/qf/688959735-chauffe-eclater-eclat-de-verre-filament-courant-electrique.jpg

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Q. What Makes C++ "Hard"?

A. Because it was designed by Computer Scientists and not programmers.

A. Because it was designed by committee.

 Just because C++ is a huge language will lots of computer-science-y features added by committees, doesn't mean that you have to be an expert with ALL of it to be an effective C++ programmer...  (as is true of every other language.  Some pieces of languages shouldn't be used very often.  Others shouldn't be used with each other.  Still others can be badly mis-used if you aren't careful.  (Hmm.  I think I'd hire someone whom I was convinced wouldn't misuse features over someone who liked to use all the features all the time.  I had a classmate in college who proudly proclaimed on his resume that he had used seven different programs to generate it.  Shudder.  And there are the assembly language programmers that like to set up a set of macros that rename the typical opcodes to their preferred names ("goto" for the unconditional jump, for example.)  Just ... no.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have often thought plain old 1970s era C was the perfect language.  It amuses me when others say that it is hard to learn.   I suspect a lot of that comes from the teaching notion that advanced things must be hard to learn.  A sort of circular logic that becomes self re-enforcing. 

 

The problem with computer language mutability is the need for a measurable number in work groups.  Why strong type defining is preferred by those who need to manage projects.  C++ is a perfect example of this.  It really needs a team of programmers and a top down design to implement the objects and structures.  Why C++ works in the processing/arduino environment.  The heavy lifting is done by the team.  The rest is like filling in the pages of a coloring book, or connect the dots drawing.

 

The other factor is the cost of the toolset.  I would often get frustrated that as a hobby programmer,  That I could not afford the current visual studio or library set.  Even Apple charged quite a bit for developer tools and different library sets. Often when I wanted to play about with something,  I had the wrong library revision.  This lead to my disdain for makefiles and other script and build tools.   I got even more frustrated with high level programming when I was attempting to move some of my C programs from mac OS 7/9 to mac OSX objective C.  That there was no simple way to access a pointer to an object by casting to it directly.  That one has to inherit the app structure to get the frameworks in which to attach things to.

 

I personally learned to program (rather than code) some 40+ years ago in the mid to late 1970s.  So I tend prefer a bottom up approach which is great for a single programmer.  I also have never been able to unlearn that pointers are ints and that ints are not 12 or 24 bits plus a bunch of flags.  Ironically I never had DEC hardware to program.  I did however have a lot of books to learn from.

 

The AVR became for me the perfect embedded environment as the ASM instruction set is pretty much pure C primitives.  I think there really are only something like 7 instruction concepts, that once learned allows one to program anything.  As I was first a sales support rep for a retailer (in the early pre-IBM PC 10980s)  I tended to program for fun on evenings and weekends.  I then went in to QA so still continued to program after hours.  This lead me to be more of a trial and error programmer.  I also took to reverse engineering other code to see how it worked, attempts to run Posix code on early OS 7 era mac's, not to mention porting windows programs to mac.

 

As for scripting chance would have it, that I learned postscript in the 1990s while working at apple.  I can lash something out in that language faster than other scripting tools.  Were I starting over it would probably be Python.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I wasn't sure if my thoughts on this thread would make any difference, until these two sentences came up:

 

Brian Fairchild wrote:
Q. What Makes C++ "Hard"? A. Because for people programming microcontrollers it makes little sense to use it.

 

JohanEkdahl wrote:
I wonder what the people in the Arduino community would say about that..?

 

.......AH HAH!

 

The programming language IMNSCFO is as hard as you make it out to be based on what you learned first.  And in Johans reply to Brians observation, most Arduino users may not be programmers to begin with, just hobbyists who never moved past a 40-in-1 Radio Shack kit.  Then Arduino hit the stage and now there is something for the average schmoe.  And since it is C++ based and the target audience does not have much...if any experience programming then C++ is what they are learning as their first language.  So it's NATIVE much like their spoken language.  We have seen in threads here Arduino users that want to move over to the "other side" as some call it get frustrated with the C conventions.  It also has to do with how much effort one puts into the learning, and how open the mind is to it as well.  Forget what you know, as it will only get in the way.

 

I started with assembler, and had a tough time learning the basics of C, to which I am still learning....10 years for me would be a good realistic goal to be proficient enough that I wont second guess myself so much.  Same thing applies to whatever language you are learning, be it spoken or programming.  I would put a caveat that for some, learning another language may be quite easy, to others a struggle.

 

Cheers,

Jim

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One of the real "smart moves" with the Arduino programming system is that they (generally) do not call it C++. That seems to make it much easier, right there.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, finally sat in front of QWERTY. So the thread started when I suggested C++ would take 10 years to learn. Let me put a bit of context around that remark.

 

I started programming about 40 years ago (well OK, a bit longer but in that ball park). For the first 5..10 years it was mainly a mix of BASIC (as most "home computers" had in those days) and the native assembler (because limited performance meant that you soon found that you needed to "delve into the guts" to get any kind of performance).

 

I then went to university and did (principally) 3 years of Pascal. (With experience of a few other things like FORTRAN, Algol68, etc). Pascal is a nice language and it teaches you structure, modularisation, strong types and so on.

 

When I started to work professionally it was supporting Z80 based home computers so everything I then did was back to BASIC (Dartmouth style) and Z80 Asm. Again I found I could achieve most using the assembler and concentrated on that. This carried over into subsequent Z80 based designs we made. We then started to make 8086 based "IBM compatibles" so in the absence of any sensible language (I don't count "GW Basic") I used MASM 86 to program most .com and .exe in 8086 assembler.

 

Finally colleagues working on non-PC projects in which they used C introduced me to the use of C. I guess that was the early to mid 90's. So 25..30 years ago. Slowly but surely I self-taught myself C. After 25+ years I think I now have a pretty fair grasp of C. As I have used almost every one of them at some point I have a good memory for pretty much everything in standard C library and know pretty much everything that <stdio.h>, <stdlib.h>, <math.h> and so on have to offer.

 

Similarly after all this time I think I know pretty much all the possible syntax available in C. I have read the whole of K&R about 3 or 4 times and I think, at various times, I have read pretty much everything contained in the ISO C99 standard. Having said all that I would say that about once a month there is a thread on Freaks (or a question I see on Stack Overflow or similar) that adds something new I still did not know about C.

 

But on the whole I think any one individual could carry the "whole of C" in their head (basically an encyclopedic knowledge of K&R) after maybe a couple of years of study and perhaps another couple of years of putting theory into practice. This is nice because it not only means you can carry the "whole toolbox" around in your head but it also means that given pretty much any piece of C code (except perhaps that which has been deliberately obfuscated) you can read and understand almost any code any other C engineer has written. After 4..5 years you could do this "competently", after a decade or two you could do it at expert level.

 

Then we come to C++. Where to start? As other recent threads have shown, even if you take just the "core" language facilities you are talking about fairly heavy books stretching over 1,000+ pages just to cover the "basics". (compare to C - my ANSI K&R has 261 pages before you reach the index). So even the core in C++ is 4 times more complex. To reach the point where you can read and perhaps even write using every tool in that particular box is bound to take you 3..4 times as long as it does for C. But that rather misses the point that C++ isn't really just about the "syntax". It's more about shifting your whole approach to design and implementation to make the best use of the modularisation it imposes. That aspect is far more difficult to grasp (for a dyed-in-the-wool C/Asm programmer) than just learning the convoluted syntax of the language. I may never be able to shake off my C programmer approach to design. Young people who do C++ first and are not tainted by C will find this much easier. Knowing C really is a barrier to getting the most from C++ (I see this in my young colleagues all the time!)

 

But it does not stop at this core either. For one thing C++ is a "moving target". It's very much a language still under development and there have been massive changes to the core at C++98, C++03, C++11, C++14, C++17 - you may start to spot a pattern there! So every 3 years there's a whole new bunch of stuff to add to your understanding. Also books consequently go "out of date" fairly rapidly. If you pick a book at Amazon is it 98, 03, 11, 14, 17 ? If you are lucky the author may have provided updates.

 

But as well as the core syntax there's also the question of library support. The libstdc++ is huge compared to libc. Sure you still have all your strcpy() and memcmp()s if you want them but you now have queue, array, vector, string, istream, ostream, etc etc. If you just take even one of those who can (off the top of their head) remember the syntax for iterating a vector for example? if you said:

  for (std::vector<int>::iterator it = myvector.begin() ; it != myvector.end(); ++it)
    std::cout << ' ' << *it;

then well remembered!! But this is my point. I would suggest (certainly for anyone over 50 anyway!) there is now so much in the C++ Standard Library to be able to remember every method and every syntax without having to search and look things up every time. This also means you are often going to hit syntax when reading someone else's  code where your first thought is "what in the name of all that is holy is going on here?". You simply cannot carry the whole toolbox around in your head any more.

 

I spend a lot of my life not writing clean/new code but adapting existing code which may have been written by any one of about 50,000 C++ programmers in our company using any part of C++ so I may need to recognize anything that some very advanced C++ programmer may have used. In fact some programmer's seem to go out of their way not to write simple/clean solutions but to declare "look at me, see how clever I am, see this hugely obscure syntax I know about that you have probably never seen in your life, aren't I clever in being able to needlessly shoehorn it in to this?".

 

Oh and things don't stop there. I just checked a Boost directory I have:

 

 

So a fairly out of date copy of Boost is 5.4GB (true some of that is binary libs and tests) So if you are reading code where the C++ author has used additional facilities like Boost there's potentially 1,000's and 1,000's of other things you need to know about to be able to read the code. That tree contains 11,552 .hpp files for goodness sake!!

 

In fact the more I think about this the more I think there is no hope left in my lifetime to get to a point of having a reasonable familiarity of everything in C++. My comment about another 5 years is a huge under-estimate. I think all you can hope for is to get a good understanding of the core and be ready to just look other stuff up as you come to it.

 

It tickles me to see Amin asking for a summary of all this on 10 pages - no hope.

Last Edited: Mon. Jul 10, 2017 - 10:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am terrified by Jim's approach. There is no way that I could absorb C++ like that.
.
However, learning how to use Arduino libraries and writing simple sketches is VERY practical.
.
There is no point in knowing everything. Comfort and familiarity with common features and problems is adequate.
You might want to extend an existing library class. Or handle some hardware. In which case you study these particular aspects.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

So what we really need is C++-.

 

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I am terrified by Jim's approach.

Which Jim?

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need to know all of Java.   Or all of C++.  Or any language.    You DO need to know how to find documentation,  read it,  learn to use Libraries.

 

On the other hand,   C is small and absorbable.    But I still need to check the occasional syntax.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

But arguably you do need to know the whole of C++ to read and maintain the code of others. I'd say it is still daily I read pieces of C++ and see syntax/operation I don't recognise. I spend half my life on Stack Overflow looking things up! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
You DO need to know how to find documentation,  read it

The awareness that this is even necessary - let alone the ability to actually do it - seem to be sorely lacking these days ...

 

frown

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes,  but you live in a different Universe to Jim.

 

Jim has his own projects and code.    He does not need to worry about video processing.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
you live in a different Universe to Jim.

Who? And which Jim?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

West Coast Jim,  Andy and I all live in a different Universe to Cliff.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Well, since all "politrucks" but me are in anyway.. ;-)

Brian Fairchild wrote:
So what we really need is C++-.

You already got it. It's C++. Use what you want, need or are told to use. Don't use the rest.

 

If you need to enforce your subset, e.g. to control the JavaScript youngsters with their baseball caps backwards, then the document you need to write is called a "coding standard".

 

Most all of you advice against dynamic memory allocation in C in small embedded systems. Is that an argument for needing a C-? Of-course not.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Mon. Jul 10, 2017 - 01:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Most all of you advise against dynamic memory allocation in C in small embedded systems. Is that an argument for needing a C-? Of-course not.

+1

 

and many 'C' coding standards also advise against using various other language features; popular choices include

  • goto
  • trigraphs
  • ternary operator
  • the "optionality" of braces

 

 

(go on - who had to look up "trigraph" and/or "ternary operator" ... ? wink )

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(go on - who had to look up "trigraph" and/or "ternary operator" ... ? wink )

 

I refuse to answer :-)  but what's "optionality" of braces?

 

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
(go on - who had to look up "trigraph" and/or "ternary operator"
Presumably those who haven't been doing C for 10+ years? ;-)

 

I guess a more pertinent question is "go on - who has ever actually USED trigraphs"?

 

(I'm pretty sure we all use ternary and probably quite regularly).

 

BTW my understanding of trigraphs was that they were for those who had limited keyboards without all the punctuation symbols - surely, since IBM AT (1986 was it?) and the 105/106 key keyboard that has not been the case for a VERY long time.

Last Edited: Mon. Jul 10, 2017 - 02:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BTW my understanding of trigraphs was that they were for those who had limited keyboards without all the punctuation symbols - surely, since IBM AT (1986 was it?) and the 105/106 key keyboard that has not been the case for a VERY long time.

I think it was IBM that blocked the removal of trigraphs from C++14 at least (think they're planning to remove them in C++17...)

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wek3 wrote:
what's "optionality" of braces?

I made the word up.

 

But what I mean is that 'C' allows, for example,

if( condition ) statement;

whereas many coding standards insist that you use braces:

if( condition ) {
    statement 
}

 

 

clawson wrote:
"go on - who has ever actually USED trigraphs"?

I think I may have ...

 

Or it might be that I just got caught-out by them?

 

my understanding of trigraphs was that they were for those who had limited keyboards without all the punctuation symbols

Yes - that is my understanding.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> many coding standards insist that you use braces

 

Ah, I see. Thanks, Andy.

 

Jan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If you just take even one of those who can (off the top of their head) remember the syntax for iterating a vector for example? if you said:

 

for (std::vector::iterator it = myvector.begin() ; it != myvector.end(); ++it) std::cout << ' ' << *it;

 

then well remembered!!

 

One of the things I observe from people learning new stuff (and that I suppose I myself do) is not "systemizing" things, or trying to "see the/a system".  Without a "system" there is no place to hang up those pieces of concrete knowledge and details. And you'll have a hard time..

 

For most all programming languages there is such a system, and once you start to see it things get much easier. Now, "knowing" you Cliff, I'm surprised that the iterator for-loop setup is a problem. I can see for a newcomer to the language that it might be hard to see, but isn't the below similarity rather obvious??

 

 

Assuming start() and end() are rather obvious names, what is left as perhaps "clunky" is the

std::vector<int>::iterator

which is

  • In the std namespace (that's "bog standard", so not hard to remember, eh?)
  • the class vector (good descriptive name there!)
  • which happens to be a template class <> (as all the standard collection classes are) so we must tell that it is int's that are in the vector, and finally
  • get the inner class iterator from that (another well chosen name, IMO).

 

Any active C++ user with a few weeks or months under the belt knows that you refer to things inside a namespace with :: . (And since a class by definition is a namespace we get a hold of the inner class using the same mechanism.)

 

If you try to learn C++ without looking for "the system(s) that makes up the skeleton of the language" then I can understand that it is intriguing, overwhelming and very frustrating. But IMO that goes for any programming language. Some have little structure and system - sometimes because not much is needed (assembler) sometimes it's just a hack (I'll stick my neck out and say BASIC).

 

And for those that have not been taught the concepts (*) of collections and iterators there is of-course little point and even smaller probability that they will just memorize the syntax.

 


 

It was well observed somewhere above that C++ tries to cater for many uses. One single use case probably will not use the whole language repertoire, perhaps even not a majority of it! 

 

C++ also caters for many "paradigms", one of them being "Object Orientation". Others are e.g. our good old "procedural" (just plain old "functions and data"), "functional" (especially with the introduction of lambda expressions), meta-programming (relying on C++ templates) ...

 

You don't need to take all that in! But I argue that you will be well served by taking in

- Some non-OO stuff that is really good. Function overloading is one such thing.

- The basic Object Oriented features. At least "tiers one and two" : Encapsulation and Inheritance. I'd vote for Inheritance also.

- As I've pointed out elsewhere templates are often an alternative to error prone and hard-to-control function style macros.

 

All this is for small embedded systems, resource-challenged and running "on the metal".

 

(As soon as we move to a system that might be hosted, but at least is not severely challenged for memory (one of the "larger" ATmegas or SAM Ds for example) I might very well use parts of the std library, e.g. collections and iterators. Possibly also algorithms, e.g. sorting or searching.)

 


(*) - "Concepts". Now there's  a word you cant use in its general meaning for much longer when discussing C++!

 

One problem with the language is so big is that it "steals" many general/generic words and give them very specific meanings. I just have "a bunch of data". "Collection"? Nope, taken. I want to talk about some flow of code with someone. "Algorithm"? Dangerous, since there are such in the std namespace. Etc.. 

 

The things that is around the corner is ... "concepts". Not quite clear on it yet, but it seems to be a way to put constraints on e.g. templates so that they fulfill certain "meta-properties". The run'o'the'mill example seems to be 'comparable'.

 


 

Anyway... It's a huge language. And it's growing.

 

C++17 was "frozen" this spring. Next up is C++20. Bjarne, Herb Sutter and the others seems to have spare time, but it looks like Scott Meyers gave up or just got tired.. (When will GCC support D for AVRs? ;-) )

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Now, "knowing" you Cliff, I'm surprised that the iterator for-loop setup is a problem.
More than anything it's probably remembering that the two methods involved are begin() and end() in fact!

 

I wasn't citing this example per se - just that there are 10,000's of things like this you need to remember to be able to either freely write this stuff or to understand what's going on in code you come across and try to read.

JohanEkdahl wrote:
which happens to be a template class <>
I think most of the "hard bits" I come across are use of templates. I understand the concept but there's something about the syntax that floors me most times.
JohanEkdahl wrote:
One single use case probably will not use the whole language repertoire, perhaps even not a majority of it!
Just did a "dir *.cpp /s" on one of our active source trees:

and for .h:

So a combined total of about 150 Megabytes of source. I'd say there's quite a lot of potential for a lot of the aspects of C++ to have been used there. (and that was ONE project tree).

 

Here's another one (actually perhaps one that I spend more time "engineering"), .cpp:

and the .h for that:

(so ~220MB of source).

 

These are projects written by 200..300 (perhaps more?) engineers so there's the potential the for every last type of C++ craziness to have been used at some point!

 

I could find 50 more projects of similar size without trying to hard.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope that casual readers, if there are any, don't get turned off by all this because I find it very enlightening. From several angles:

 

1. Seasoned programmers admitting that they have "trouble" with some of the features. That makes it much easier for us mortals who struggle with even the basics. 

 

2. There appear to be points where the experienced folks don't agree, to varying degrees, on how something does work, should work, is used, and so forth. This must certainly be one of the things that makes C++ "hard".

 

3. There are a number of features that the basic tutorials do not even attempt to explain, or explain incompletely, or introduce without much explanation, at all. So far, in the cplusplus.com tutorial, templates are one of those. Without this discussion, I would not have even known that this is the case!

 

4. The discussion has provided a great insight (to me, at least) into the challenges of learning even the basic concepts of C++. For that, I thank everyone who has contributed. My goal, as I think I wrote above, is to learn it well enough to be able to a little ways beyond cookbook coding. I have no illusions about expert level coding. My future life is not long enough for that, I fear :) And, I have too many projects in the pipeline to devote all my time and mental capacity to such an endeavor!

 

I am puzzled, a bit, though, about this "different universe" (item #31).

 

Cheers and Very Best Wishes,

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Mon. Jul 10, 2017 - 06:03 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What makes C++ so difficult (at least for beginers)? According to the Kate Gregory, it's C. If you start teaching some 5days introduction into the C++, whenever you mention pointers, index operator and so on, you have to take a looooong introduction into the C part of C++. And understanding pointers is not so easy.

 

Whole CppCon 2015: Kate Gregory “Stop Teaching C" video: https://www.youtube.com/watch?v=YnWhqhNdYyk

 

It doesn't mean you don't have to learn poiners and some difficult stuff, but you don't have to do it at the start.

 

 

BTW: I already knew what digraphs and trigraphs are, but never used it (except for the check if they're really working).

Computers don't make errors - What they do they do on purpose.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
3. There are a number of features that the basic tutorials do not even attempt to explain

Surely, that is in the very nature of basic tutorials?

 

A "basic" tutorial is, by definition, one which does not cover the "advanced" stuff!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For those of us who are new at it, I find it really hard to tell what IS basic and what is "advanced". As introduced in the tutorial, templates seem like an eminently sensible idea but as I see the discussions above, it appears that the implementation is MUCH more challenging. Until this discussion, I could not tell if it is a basic feature or not! Vectors and iterators were things I had not even heard about (yet) so I put those in the "advanced" bin right away. Just like trigraphs and ternary operators in C (!) [Saw ternary operators used in FatFS and had to look them up to understand what the code was doing - first and probably last use].

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
I find it really hard to tell what IS basic and what is "advanced"

 

Yes.

 

That is why I repeat - over and over - this "firsts list:

 

Non Object-Oriented stuff:

- Function overloading

- References (v/s pointers)

 

The two first of the three pillars of Object Orientation: 

- Encapsulation, aka plain old classes.

- Inheritance.

- Polymorphism, aka "virtual functions.

 

And the "plain old classes" in itself is a biggie! (E.g we haven't started talking about the Copy Constructor yet, but it is important. And there's more..)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And that list is where I am putting my energy. 

 

Thank you for the enthusiasm that you have added to this. And, your patience! 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
For those of us who are new at it, I find it really hard to tell what IS basic and what is "advanced".

Also not specific to C++

 

Witness the number of beginners here trying to start out on a USB project ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
Seasoned programmers admitting that they have "trouble" with some of the features.

Any day I work with C++, I look things up. It's normal.

 

ka7ehk wrote:
There appear to be points where the experienced folks don't agree, to varying degrees, on how something does work, should work, is used, and so forth.

This is true for all programming languages I know and have used for the last 25 to 30 years. I certainly is true for C. And for e.g. Java and C#.

 

clawson wrote:
More than anything it's probably remembering that the two methods involved are begin() and end() in fact!

When memory fails the IDE/editor should remember. "Intellisense"/autocomplete.. (I've been doing Java lately, and C# before that, and the first thing you do when you're not sure of the name of a method, or if it even exists, is to type <variablename><period> and then start scrolling and browsing the list..)

 

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Pages