To go with Go or C/C++?

[Bo Persson]

Tinxx skrev 2013-05-02 13:30:

I think I start with learning C and play around with C calling Lua and vice versa. Maybe some DI framework for C where the configuration definition language is Lua. Might have been done a zillion times before, but it's for fun and learning and you first have to be able to walk before you want to fly. Knowing plain C is always useful, because C++ is sometimes an overkill or not the appropriate choice. Then I do some socket programming with zeromq.org first with C and later with C++. This way I can slowly fight my way up at the pace I have time in my spare time.

Right, if you want to learn both C and C++ (and Lua), just do that.

We are just saying that learning one doesn't help much in learning the
next one, because you will also have to unlearn what you just learned.
So the order is of less importance.


Bo Persson

 

[Stefan Ram]

The problem is that you have to forget A LOT of C, like
printf and scanf

There are indeed some experienced C++ programmers
who prefer to use C-style I/O in C++.

C string handling
pointers and arrays
pass-by-pointer instead of pass-by-reference

Even in C++, one writes:

int main(int argc, char* argv[])

, which requires to understand meaning and encoding
(NUL-termination of char-*-strings) of argv,
including pass-by-pointer and arrays.

that << and >> are some odd bit shifting instead of I/O operators

Even a C++ programmer needs to understand ((1<<14)|(1<<2)).

How much time have we lost after learning all this?

C is the most popular language according to Tiobe.
Twice as popular as C++, which is declining in popularity.
How is learning the most popular and most influential
language a loss of time?

 

[Rui Maciel]

We are just saying that learning one doesn't help much in learning the
next one, because you will also have to unlearn what you just learned.

Nonsense.


Rui Maciel

 

[Rui Maciel]

The problem is that you have to forget A LOT of C

Nonsense.


Rui Maciel

 

[Bo Persson]

Stefan Ram skrev 2013-05-02 18:49:

C is the most popular language according to Tiobe.
Twice as popular as C++, which is declining in popularity.
How is learning the most popular and most influential
language a loss of time?

Popularity according to Tiobe is the language producing most noise on
the Internet. Arguably it is the one that is hardest to use that
produces the most questions.

If you WANT to learn "the most popular language", just do that. If it is
just a prerequisite for learning the other language, it is a waste of
your time.


If I want to learn to ride a bicycle, I wouldn't start with a unicycle
just because it looks easier.



Bo Persson

 

[Bo Persson]

Scott Lurndal skrev 2013-05-02 19:06:

Why? It all still works in C++. That's a benefit.

No, it's a big disadvantage because C++ has better tools for this. Why
not learn them first?

Try

std::string s = t;

over

char * s = malloc(strlen(t) + 1);
strcpy(s, t);

// and much later:

free(s);

and guess which is easier to learn (without missing the meaning of the
+1, or forgetting the free).

And here you are joking, right? Or do you truely think that bit shifting
and C++ don't mix?

No, but I believe a new student shouldn't START there. You can learn
that later, if and when you need it.


Bo Persson

 

[James Kanze]

C is much easier to learn then C++.

I would argue about that. Learning all of the formal aspects of
the language, yes. But knowing all of the formal aspects of the
language doesn't mean that you know how to write robust,
maintainable programs in it. And it's a lot easier to write
robust, maintainable programs in C++ than in C.

 

[James Kanze]

Am 01.05.2013 21:37, schrieb Victor Bazarov:

C++ is a complicated language and learning C++ right from the
start might be too difficult and the learning curve may be too
steep for the novice. So it's educational meaningful to learn
the basic concepts of C which also apply C++ also first.

Learning C right is more difficult than learning C++ right.
Writing efficient, robust, maintainable applications in C is
very, very difficult.

 

[James Kanze]

Stefan Ram skrev 2013-05-02 18:49:

If I want to learn to ride a bicycle, I wouldn't start with a unicycle
just because it looks easier.

Beautiful. The analogy is perfect: C is a unicycle, C++
a bicycle, and Java a tricycle.

 

[Stefan Ram]

maintainable programs in it. And it's a lot easier to write
robust, maintainable programs in C++ than in C.

I am not sure about this. For example, exceptions introduce
so many hidden paths into a seemingly simple piece of code
in C++.

http://www.gotw.ca/gotw/020.htm

In C, one can write

if( f = fopen( "file", "r" )){ use( f ); close( f ); }

, i.e., apply the well-established style of structured
programming. Without exception, we do not need no RAII,
we can assert that »close« will be executed iff the file
was opened successfully.

 

[James Kanze]

"Picking up enough C++ to start doing good (or harm) in any field does

"Learn C first because you need a magnitude of time less to learn.
Then learn C++ ..."

Think this makes sense as already said earlier.

Except that it's totally false. It takes more time to learn to
write working programs in C than in C++.

Once saw some C++ code which was full with "extern C"
statements. Doing plain C++ without any C is not a reality.

In the sense that the OS you're running on might have some parts
written in C (although most modern OS's are mainly C++), yes.
In the sense that C++ uses curly braces (instead of BEGIN and
END), and C used them first, yes. Otherwise, no. I'm currently
working on 500KL application, and there are very few places
where we use extern "C", most of the people working on the
application never see them, and they're only there so that
applications which use a C API (like Excel or Python) can call
into us.

 

[Tobias Müller]

char * s = malloc(strlen(t) + 1);

// Don't forget error handling:
if (s == NULL)
{
/* handle error */
}

strcpy(s, t);

// But usually you just use:
char* s = strdup(t);
// it's not standard but easy to define yourself
// if not already present in libc

Tobi

 

[Stefan Ram]

We can (and probably would) do the same in C++. A missing file isn't
necessarily an exceptional situation.

The point is that »use« might throw,
not that »fopen« might throw.

Now if it were an exceptional situation and the open was part
of a group of resource allocations, C code would have to
include had written clean up code

»close« /is/ the clean-up code here.

and quite likely a "goto error".

That is not structured programming, but I wanted to show
structured programming.

 

[Tinxx]

"C'est what? Linux is 100% C, NTOSKERNEL is 100% C. The UI for
Windows, and many applications are C++, but the kernel (i.e. the OS)
is all C."

Yeah, it depends whether your C program needs to compile with a plain C compiler like Lua. Because Lua does so, it exists on almost any platform for which a C compiler exists. Otherwise, I could also use C++ as a modern C. Use C++ streams instead of sprintf, etc. Problem is that C has not even modules. I can do without classes (classes as in OOP). But even without modules (as in Modula-II) makes it really hard. You would do something like a struct and all functions that act on it are in the same file and receive the struct as the first parameter. This is actually what Go is doing. It is a modern C in many ways.

" In C, one can write
if( f = fopen( "file", "r" )){ use( f ); close( f ); }"

Yes, Go does the same thing: no exceptions and checking an error code. For the above sample this seems suitable. But no exceptions at all can get effortful (endless return cascades where the error is returned). But maybe for "low-level programming" this makes sense.

Go seems to me to be designed as a modern C. And I think they did things well in many ways. But no link libraries at all, no exceptions. That's a bit strange. And the tooling and industry support is really weak. Will stick toC or C++ and after 5 years or so have a look how Go has been doing. The investment in C or C++ won't be lost anyway.

Cheers, Tinxx

 

[Tony]

it's a lot easier to write
robust, maintainable programs in C++ than in C.

But do you really think that is enough? That's the C++ brochure? Stepped in
what?

(rhetorically)

 

[Tony]

I am not sure about this. For example, exceptions introduce
so many hidden paths into a seemingly simple piece of code
in C++.

http://www.gotw.ca/gotw/020.htm

In C, one can write

if( f = fopen( "file", "r" )){ use( f ); close( f ); }

, i.e., apply the well-established style of structured
programming. Without exception, we do not need no RAII,
we can assert that »close« will be executed iff the file
was opened successfully.

That pattern is valid, but to be limited to only that one is, well, a
limitation. I.e., it is constraining. (Not to feed Kanze's "all the expressivity
of C++" spiel though!). The lure of a C++ approach in the above kind of code is
that you can implement an abstraction once and eliminate a potential error of
omission at every place where such code is required, thereby making the program
more robust. If you want the C code above to be robust in all the places you put
it, you have to have a code generator create it, because the programmer is apt
to screw it up, and you're not going to get any compiler help with that bug
either.

 

[Tony]

Learning C right is more difficult than learning C++ right.
Writing efficient, robust, maintainable applications in C is
very, very difficult.

C++ is like one of those rocket "motorcycles" used for land speed records at the
Bonneville salt flats: you better know what you are doing when piloting one of
those things, and you may end up crashing and burning anyway. Very perilous.

 

[Tony]

Beautiful. The analogy is perfect: C is a unicycle, C++
a bicycle, and Java a tricycle.

Not even close: the cycles are examples of simple elegance whereas C++ is a mire
of complexity. Somehow, C++ is able to move, but you'd be hard-pressed to
identify which one of those round turning things is a wheel or if it has any
actual wheels at all! A circus act? A freak show? Are 10 clowns carrying
unicycles going to jump out of the old jalopy now? Ya never really know with
C++... it could happen!

 

[Tony]

Nonsense.

It's not nonsense. While unlearning ability varies with each individual, there
is time and effort required beyond what is required for learning to do something
"right" from the get go.

 

[Shriramana Sharma]

D is surely much more complete than Go,

Thanks for prompting me to look into D. It looks very interesting. C++ is great, lots of great software is written in it, but it's also a great big cave with lots of surprises. Looks like D might be quite useful for my purposes. Thanks again.

Shriramana.