No, you would do that. I wouldn't. Not the at() member, at least.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.In C++, you would use a vector and the .at member.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.
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
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
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.
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.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.
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.std::tr1::array FTW!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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.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.
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.
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,
But again, the WHOLE language is there to be used - whatever solves the problem in way of: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.
- correct
- maintainable
- sufficently efficient
should be allowed, don't you think?
If you wish to rewrite the entire OS, feel free. But it's a pretty huge task.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.
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
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
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.
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.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.
And it will create a safer environment, as well, because buffer overruns are a security risk.
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.
I'd like to add another category, though.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?
Constant, non-container arrays fails the red line
Yes, I'm sure this is why the current state of the kernel is as it is. To some extent, anyway.If you wish to rewrite the entire OS, feel free. But it's a pretty huge task.
It's a shame.
No, I'm afraid not. I'm used to user mode where there's plenty of memory and protection available.Have you ever written kernel code?
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.
Only if by safe you mean 'I can be a bloody retard and not stay aware of what Im doing in my application'. So you lose track of the size of your arrays and index into a 'safe' array, which instead of crashing and letting you know you wrote sloppy code, proceeds to act like nothings wrong until 6 months after deployment your customers want to know why their databases are trashed and grew 5000%.
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
Last edited by Mario F.; 05-14-2008 at 09:14 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law