is it a bad idea to start with c++

[thecodewall]

When you start learning programming its really hard. But there's a lot of programming books for newbie or tutorials. For me its C++, you can download the tutorial lesson here as your guide.


http://codewall.blogspot.com

[stereoMatching]

Can you post part of the book where he makes that claim? I'm interested to hear it.

It is in item 23
whatever, in some cases, iostream may faster than stdio.h
but they are not general cases

[Disch]

It is in item 23

I meant an excerpt. I don't have a copy of the book around.

whatever, in some cases, iostream may faster than stdio.h
but they are not general cases

I fail to see how cstdio could be faster in most cases. It seems like only edge cases where it might be faster (but even that I don't see).

If you're talking about string formating (printf vs. cout), printf has added overhead of having to parse a format string at runtime, whereas cout has no such work to do. Although I suppose that sending format params via << overloads constitutes additional function calls which may have some overhead (assuming they're not inlined)

And if you're talking about basic I/O (fread vs. fstream::read) I fail to see how there could be any substantial difference either way. If anything the overhead involved in dereferencing a FILE pointer could be avoided with fstream whereas there's no way around it with fread. So even there I see iostream being ever-so-slightly faster.

Although I suppose it's all implementation dependent.

Maybe some implementations of cstdio are faster than some implementations of iostream. But there's no reason that has to be the case.

[lionishy]

Disch>I meant an excerpt.

Quotation:

As an example, consider the iostream and stdio libraries, both of which should be available to every C++ programmer. The iostream library has several advantages over its C counterpart. It's type-safe, for example, and it's extensible. In terms of efficiency, however, the iostream library generally suffers in comparison with stdio, because stdio usually results in executables that are both smaller and faster than those arising from iostreams.

#ifdef STDIO
#include <stdio.h>
#else
#include <iostream>
#include <iomanip>
using namespace std;
#endif

const int VALUES = 30000; // # of values to read/write
int main(){
     double d;
     for (int n = 1; n <= VALUES; ++n) {
     #ifdef STDIO
         scanf("%lf", &d);
         printf("%10.5f", d);
   
     #else

         cin >> d;
         cout << setw(10) // set field width
         << setprecision(5) // set decimal places
         << setiosflags(ios::showpoint) // keep trailing 0s
         << setiosflags(ios::fixed) // use these settings
         << d;
     #endif

         if (n % 5 == 0) {
         #ifdef STDIO
             printf("\n");

         #else

             cout << '\n';
         #endif
         }
     }
     return 0;
}

I have run this program on several combinations of machines, operating systems, and compilers, and in every case the stdio version has been faster. Sometimes it's been only a little faster (about 20%), sometimes it's been substantially faster (nearly 200%), but I've never come across an iostream implementation that was as fast as the corresponding stdio implementation.

Meyers, More Effective C++

[rapidcoder]

Most people would recommend an easier language as the first one, but I think it's just fine to learn C++ first. It will certainly provide you with a much better understanding of how computers work than if you went straight to a higher level language.

I think it was true about 20 years ago. Now C and C++ hardly reflect the model how computers work. The physical model of computation used by modern CPUs differ greatly from how you code even in some pretty low level laguage like C. Pointers don't point to physical memory addresses. Instructions are not processed sequentially. Both branches of "if" are taken simultaneously. The same instructions don't take the same numbers of cycles. And so on, and so on. There are so many levels of "magic" below, that you cannot claim you understand how computers work, if you only know C or C++. You only know some simplified model of it. Just the same as if you were programming Python or Java, except the Python's or Java's model are even simpler.

If you want to know how computers work, you should study first analogue, then digital electronics, computer architecture and finally some assembly language. So you should probably start from getting yourself an oscilloscope and multimeter instead of PC.

Regarding the original question:
I think it is more important to learn some general concepts like assignment, iteration, function call, recursion, type, compositions and inheritance, some common data structures like hashmaps, higher-kinded functions, currying, pattern matching, generic and higher-kinded types, exceptions, streams etc. For this a single language is probably not enough, however, I don't think C++ is the best one - it has just too many things that are not needed at all to be a successful application programmer, and it natively supports too few of that general programming concepts (or the support for many is only partial - recursion, ok you can do it, but tail recursion is practically useless).

[filipe]

I didn't mean to imply knowing C++ will teach you exactly how computers work. I was thinking about things like memory management, raw arrays, pointers/references, how strings are stored, and so on.

[rapidcoder]

I was thinking about things like memory management, raw arrays, pointers/references, how strings are stored, and so on.

Agreed, but I don't think all these things are really required to be a productive programmer (= to create code that works well, has acceptable performance and is maintainable). On the other hand, knowing them, without actually knowing how hardware works, is scaringly little to be a programmer that can get 100% of performance from the machine.

[Celebrinbor1]

My suggestion may sound strange but I found this extremely helpful when learning the basics of c++. I found that learning how to use excel's more advanced functions (logic stuff like if then else and calling cells for variables, etc) and how to program a ti84 calculator first really helped me learn c++ as those two tools are almost idiot proof and have numerous parallels to c++ and other programming languages.

[stereoMatching]

I don't think all these things are really required to be a productive programmer

It is all depend on your application
sometimes you can't work well without them

[rapidcoder]

sometimes you can't work well without them

Yes, sometimes. But I miss a proper garbage collection or modularity support more often than appreciate the ability to do pointer arithmetic (which happens once per 10000 lines or less). I think that a newbie to programming would understand it even better.

BTW, here is an interesting article on how to learn programming, and what to learn: http://norvig.com/21-days.html

Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).

[Disch]

@ lionishy:

Interesting.

I'll check this out more when I get back from work.

It looks like the overhead from all the function calls might be slowing the iostream approach down. I bet with fewer modifiers the iostream approach would be faster, so there's probably a point where it's a tradeoff.

In any event I'll run my own tests and whatnot when I get home and report back.

[ladykrimson]

I wish I had taken C/C++ before I took Java....