Thread: Which language to start with

In C++, you would use a vector and the .at member.

No, you would do that. I wouldn't. Not the at() member, at least.

Unfortunately, due to some people who thought it was wise to make it undefined to invoke [] for out-of-bounds, they are forcing us to keep a lot of unsafe code around if we don't want to go around it using things such as .at.
Sometimes I really don't know what they were thinking when they created it. And don't tell me if it was for C compability.
Safe code before unsafe code.

Originally Posted by Elysia

But we could argue that example is C.
In C++, you would use a vector and the .at member.
Preferably, also a safe iterator that can throw if you access out-of-bounds.
The standard library is sometimes just as unsafe as the C library.

It is VALID, compilable in C and C++ - and don't tell me that you use vector for every single array that you ever need? There are cases when vector is the right solution, there are others where an ordinary array is just fine.

It is very likely, in my mind, that a C++ book doesn't start with STL, but begins by teaching the basic concepts that are part of the basic C++ language first, then introduces C++. In my C++ book ["C++ for programmers" or some such], the first 6-7 chapters are about the basic language, only in chapter 7 (or 8?) does it get onto templates, and only after that does it get into STL.

Maybe I'm also not writing enough user-mode code tho' - I try to avoid code that allocates memory or adds overhead more than necessary.

--
Mats

Originally Posted by matsp

It is VALID, compilable in C and C++ - and don't tell me that you use vector for every single array that you ever need? There are cases when vector is the right solution, there are others where an ordinary array is just fine.

If an "array" is the right solution, then IMHO, there simply isn't a good standard container available. Plain "old arrays" are never the best solution unless you're looking for speed.

It is very likely, in my mind, that a C++ book doesn't start with STL, but begins by teaching the basic concepts that are part of the basic C++ language first, then introduces C++. In my C++ book ["C++ for programmers" or some such], the first 6-7 chapters are about the basic language, only in chapter 7 (or 8?) does it get onto templates, and only after that does it get into STL.

Of course, I wasn't intentionally implying that it would apply to all programs. Beginners typically always begins with C++/C and moves on to more real C++ later. But when they are full fledged programmers, they should be using C++ and not C++/C.

Originally Posted by matsp

Maybe I'm also not writing enough user-mode code tho' - I try to avoid code that allocates memory or adds overhead more than necessary.

Also this suggests to me that kernel mode really needs to overgo a rehaul. There should be no limit on memory to use and be scared of overhead. That makes code unsafe and that makes the OS crash.
Safe code before unsafe code, as I say.

It is VALID, compilable in C and C++ - and don't tell me that you use vector for every single array that you ever need? There are cases when vector is the right solution, there are others where an ordinary array is just fine.

If an "array" is the right solution, then IMHO, there simply isn't a good standard container available. Plain "old arrays" are never the best solution unless you're looking for speed.

std::tr1::array FTW!

TR1 seems to add a lot of new goodies, doesn't it?

But we could argue that example is C.
In C++, you would use a vector and the .at member.
Preferably, also a safe iterator that can throw if you access out-of-bounds.
The standard library is sometimes just as unsafe as the C library.

Personally I don't think any of the things you mentioned are what really define it as a C++ program. In fact those things all strike me as a Java-like C++ program. C++ has features such as operator overloading specifically so you can do myvector[i] and not myvector.at(i). When I first learned Java I thought it was ridiculous (and I still think so) that everything used the clunky CompareTo() function.

I also think that the "safety nets" which have been mentioned by various people that Java supplies are needless. How often do most n00bs end up using pointers anyways? When I took my first C++ course in high school, it was an entire year before I really handled a pointer, and by that time I had a solid grasp on the core of the language so when the time came around for me to learn pointers it wasn't a disaster. In terms of other things (such as array-out-of-bounds errors), it provides good learning experiences for people to go through some of those things.

In terms of the speed of Java compared to the speed of C++: the only thing I will say on that subject is that Netbeans is written in Java and that Netbeans is the slowest IDE I have ever seen in my life. Obviously a bad choice of language for that project in my opinion.

Originally Posted by Elysia

If an "array" is the right solution, then IMHO, there simply isn't a good standard container available. Plain "old arrays" are never the best solution unless you're looking for speed.

Yeah, well, I think we'll just agree to disagree on this one. There are plenty of places where an array is fine.

A very clear example is a constant array - they are known size at compile-time, and just gets very complicated if you have to set it up with vector instead,

Of course, I wasn't intentionally implying that it would apply to all programs. Beginners typically always begins with C++/C and moves on to more real C++ later. But when they are full fledged programmers, they should be using C++ and not C++/C.

But again, the WHOLE language is there to be used - whatever solves the problem in way of:
- correct
- maintainable
- sufficently efficient
should be allowed, don't you think?

Also this suggests to me that kernel mode really needs to overgo a rehaul. There should be no limit on memory to use and be scared of overhead. That makes code unsafe and that makes the OS crash.
Safe code before unsafe code, as I say.

If you wish to rewrite the entire OS, feel free. But it's a pretty huge task.

But there's nothing unsafe about arrays as such - it's only unsafe if you mess up how many elements are actually available in the array - and if you use names constants it can be checked (e.g. using asserts).

Also, as pointed out in other places, STL doesn't work particularly well across module boundaries (EXE->DLL or User->Kernel). So whilst it may be possible to come up with a class that does work across those boundaries, STL will not work - nor any other template libraries, AFAIK.

Have you ever written kernel code?

--
Mats

--
Mats

Originally Posted by DavidP

Personally I don't think any of the things you mentioned are what really define it as a C++ program. In fact those things all strike me as a Java-like C++ program. C++ has features such as operator overloading specifically so you can do myvector[i] and not myvector.at(i). When I first learned Java I thought it was ridiculous (and I still think so) that everything used the clunky CompareTo() function.

Absolutely. I can agree no less.
Unfortunately, some members who designed the library thought it fit to make the default index operator unsafe. So they are forcing us to use .at instead if we want a safe program.

I also think that the "safety nets" which have been mentioned by various people that Java supplies are needless. How often do most n00bs end up using pointers anyways? When I took my first C++ course in high school, it was an entire year before I really handled a pointer, and by that time I had a solid grasp on the core of the language so when the time came around for me to learn pointers it wasn't a disaster. In terms of other things (such as array-out-of-bounds errors), it provides good learning experiences for people to go through some of those things.

But, as you understand, just because you think your program is running right, one fine day, your program will crash. If we had a safety net, that would lessen the risk by a lot.
And it will create a safer environment, as well, because buffer overruns are a security risk.

Originally Posted by matsp

Yeah, well, I think we'll just agree to disagree on this one. There are plenty of places where an array is fine.

A very clear example is a constant array - they are known size at compile-time, and just gets very complicated if you have to set it up with vector instead,

The problem about vector is unable to initialize it well (but that should be solved in C++0x). Otherwise, even if constant, I would still think it's better with some kind of container, as a safety net or as to provide more functionality to arrays.
If used correctly, it can make the code more reusable, as well.

But again, the WHOLE language is there to be used - whatever solves the problem in way of:
- correct
- maintainable
- sufficently efficient
- sufficiently secure
should be allowed, don't you think?

I'd like to add another category, though.
Constant, non-container arrays fails the red line

If you wish to rewrite the entire OS, feel free. But it's a pretty huge task.

Yes, I'm sure this is why the current state of the kernel is as it is. To some extent, anyway.
It's a shame.

Have you ever written kernel code?

No, I'm afraid not. I'm used to user mode where there's plenty of memory and protection available.

Also note that I wouldn't recommend just std::vector. Obviously, and safe container is a viable choice in this matter. Std::vector is just one of many containers.

Originally Posted by Elysia

But, as you understand, just because you think your program is running right, one fine day, your program will crash. If we had a safety net, that would lessen the risk by a lot.
And it will create a safer environment, as well, because buffer overruns are a security risk.

Can I just point out that there are other ways to create a safety-net than to use C++?

--
Mats

Sure, the argument was for a safety-net within C++, should you use it.

That's an entirely different issue.

Originally Posted by manav

Well that basically applies to all the languages, Java, C++ or Python!
But newbies need to write small programs to get started! I found C++ version to be smaller, more clear, easy!

Every language allows you to "write small programs to get started". C++ is not smaller than any other language on that respect. You agree then code can be extended or simplified to some extent in all languages. So you can agree the size of the code is not a good measure of how easy the programming language is to learn.

The next one was performance. However performance is not in the mind of the apprentice when evaluating how easy a certain language is to learn or how easy it is to be taught.

Ultimately no language is easier to learn than some other language. This is probably most true for at least the mainstream languages; after all there's the fact they are indeed mainstream. You can hear a crowd of Java programmers swearing over how easy that programming language is, the same from Ruby, C, etc...

Every language presents the newcomer with its own set of challenges and simplifications. What can be asked instead is if some language is easy to learn or can be made easier to learn. I'd say there is a common knowledge around C++ that the language certainly can be improved towards minimizing the learning curve, which if it doesn't contrast with the idea C++ is an easy programming language to learn, at least provides a good case against it in court.

What is more important instead is that learning a programming language is a personal process that is dependent on many factors, some of them external and out of one's control. At the lowest level our own motivation, background, age and computer literacy can determine how easy a language is to learn. But invariably the method and quality of the teaching will have the strongest impact. Two different people can have completely opposite feelings about how easy C++ is to learn and possibly they are both right.

Finally, the same programming language can provide the apprentice with rather easy to acquire concepts and concepts that take a lifetime to master. C++ is no stranger to this since if at one hand you have procedural programming that is a rather easy to understand concept, somewhere along the line you'll meet object oriented programming which will take a good chunk of a programmer's life to master and generic programming which, despite being the most sexy thing, shouldn't ever been invented.

In fact, even at the lowest levels one can meet these apparent idiosyncrasies in the learning process. When learning C++, arrays, pointers and references all can be somewhat easy to acquire. But many, me included, stumble and fall flat on their faces once the keyword const is introduced in their context.

So to conclude... I dare you to prove some language is easier to learn than the next one

Most people I know who tried to learn Java (most of them after PHP) had a somewhat hard time grasping the reference semantics of the variables. (PHP 4 didn't use reference semantics.)

The language isn't without its traps.