Printable View
I would like to produce five vectors via for-loop
so that i haveCode:for(int i =0; i<5; i++) {
vector<float> someVector_%d ;
}
Code:vector<float> someVector_0
vector<float> someVector_1
vector<float> someVector_2
vector<float> someVector_3
vector<float> someVector_4
What for ?
Your someVector_%d objects won't be accessible outside the loop because they have local scope.
Whatever you want to do with these, you can do with an array or vector of vector<float> s.
my only problem is to concatenate someVector_ with the integer in the for-loop, so that for instance I produce someVector_0
You'd better tell us what you really want to achieve. You cannot dynamically change identifier's name and what you are trying to do may come from dynamically typed language background.
You could use an array of vectors:
std::array<std::vector<float>>
But still, telling us what you want to achieve may be the best thing to do in the end.
You're asking the wrong question. Any time you want to have a bunch of different variables with an increasing number on the end of each subsequent one, then you should be using an array. I.e.:
Then instead of referring to e.g. someVector_2, you refer to someVector[2] in your code; although you'll most often find that you don't need to refer to specific array items, as you tend to use a loop to to anything with them.Code:vector<float> someVector[5];
Please don't teach newbies bad practices.
Anytime an array is to be used, they should be using C++-style arrays (ie std::array), and not C arrays.
Furthermore, if possible, they should be using the .at function and not the index operator to avoid having to think about out of bounds access.
The approach shown by iMalc is an alternative, not bad practice. Unlike the approach you recommend, it is also a practice guaranteed to be supported by all compilers/libraries.Quote:
Originally Posted by Elysia
std::array was only formally introduced into the standard in 2011, so is unlikely to be supported by compilers/libraries more than a year old, and it is not certain when it will be supported by more recent compilers. On the other hand, the approach suggested by iMalc has been supported by the first C++ standard in 1998.
Introduction of a new feature in a standard does not automatically render preceding features to be "bad practice". Your technique of nagging people who provide help to newbies is not the way to encourage the newer practices.
Providing an incomplete/incorrect example, as you did, will not encourage newer practices either. std::array has two template parameters, one of which is the size (which cannot subsequently be changed).
I consider it bad practice since the standard gave us a better way to do it, which means we should be using the better approach, if possible.Quote:
Originally Posted by grumpy
std::array was introduced in TR1, which was finalized 2007.Quote:
std::array was only formally introduced into the standard in 2011, so is unlikely to be supported by compilers/libraries more than a year old, and it is not certain when it will be supported by more recent compilers. On the other hand, the approach suggested by iMalc has been supported by the first C++ standard in 1998.
Of course it is bad practice to use unsafe features, libraries and code when you have the option to use newer, safer technology!Quote:
Introduction of a new feature in a standard does not automatically render preceding features to be "bad practice". Your technique of nagging people who provide help to newbies is not the way to encourage the newer practices.
Yes, I understand that you might not always be able to do so, but in this case, I think it is pretty clear that it should definitely be possible.
I am partly to blame for nagging and for nagging people to use C++11 features. But I also think iMalc is partly to blame here, too. Sure, you can use C arrays, but iMalc failed to specify the disadvantage of doing so and completely failed to mention std::array.
We cannot keep pushing older features onto newbies! C++ is a wonderful language, but it can be disastrous if used wrong, and that is partly why it has been viewed so negatively, I would think. We should teach newbies that C++ is not a low-level, ancient, relic language that you should only use for absolute maximum performance and embedded systems, but for other purposes too!
rray
That was a typo.Quote:
Providing an incomplete/incorrect example, as you did, will not encourage newer practices either. std::array has two template parameters, one of which is the size (which cannot subsequently be changed).
In retrospect, I should have written
std::array<std::vector<float>, 5> array;
// Use it like this:
array.at(N); // Where N is a number between 0 and 4.
And obviously the size cannot be changed later on - but that's no different from a C array. It's static.
TR1 was a set of proposed extensions to the standard. Although it was a standard, it was never formally a C++ standard. Features in it became part of the C++ standard in C++-11.Quote:
Originally Posted by Elysia
Life is not that simple in the real world. Good practice can involve disciplined and effective use of available features, avoiding misuse, etc. I've seen enough "bad practice" that involves misuse of ostensibly safe features coupled with over-confidence since "it is safe, isn't it, so I can do what I like without checking". Including, in some cases, with misuse of std::array.Quote:
Originally Posted by Elysia
There is also the inconvenient fact that std::array is just a wrapper that provides an alternative interface for a normal array anyway. It is designed as a means of convenience, not a safety mechanism. It can be used in safe ways, or unsafe ways.
My point exactly. Yes, C++-11 features are useful. Yes, they can be safer. They are not, however, a safety net. And they can still be misused.Quote:
Originally Posted by Elysia
Unfortunately, the intelligence and skill of the C++ standards committee - although considerable - is bounded and finite. In contrast, the propensity of programmers to misuse language features has no known upper bound.
I disagree. His post was immediately after your post that mentioned std::array. By your logic, you had the obligation to mention C-style arrays as well, so his post should not have been necessary. Such an argument cuts both ways.Quote:
Originally Posted by Elysia
However, in forums, we don't aim for completeness - because we can't - unless there is a particular reason to. We provide options and discussion, not definitive or complete descriptions of everything.
In my experience, the largest source of negative comments about C++ comes from advocates of other languages, which do things differently than C++. Some of those languages are still around and in common usage but, in most cases, C++ has grown while those languages have fallen away.Quote:
Originally Posted by Elysia
Describing features of language that newbies will encounter regularly when they look at code written by others - even code that is relatively recent - is hardly "pushing older features on newbies". Practically, a lot of newbies in industry cut their teeth by maintaining code written by others, not by writing their own brand-new code.
There are also plenty of legitimate criticisms of C++, including some written by the greats in the C++ world. Those have contributed to improvement of C++ over time.
We should teach C++ as a multi-paradigm language. Not a particular paradigm based solely on using the latest features, which is what I consider you are advocating. Such an approach is essentially locking developers into a ivory tower, since very few real-world developers can afford to limit their attention to the latest new feature sets.Quote:
Originally Posted by Elysia
I'm not alone in suggesting that. Recent teaching materials from people like Stroustrup do it too - although it is easier to take a staged approach to teaching when you can control the materials. A staged approach is not really practical in a forum with multiple independent contributors, but your approach of advocating the "latest, greatest, and allegedly safest while nagging those who provide alternatives" is not the answer to that problem.
You can nag Elysia as much as you want but he continues to fail to mention when he is using C++11 features (secretly) to this day, despite the fact that C++11 is not the default implementation any compiler I know uses. A practice I consider most harmful because people essentially end up not knowing what they're using. It will generate compiler errors that should be unnecessary, but the fact that a switch needs to be flipped is never mentioned by him. He leaves that responsibility to other people.
ok, consider the picture
I hope it makes the aim clearerCode:float x = 50.;
float y;
for(int ivector = 0; ivector<20; ivector++) {
vector<float> someVector_%d //my problem lies here
/* here i want to generate 20 vectors
vector<float> someVector_0
vector<float> someVector_1
vector<float> someVector_2
up to
vector<float> someVector_19
*/
for(int i = 0; i<1000; i++) {
y = x*i*ivector;
someVector_%d.push_back(y); //so this is what i want to do. %d is the current ivector in the loop . What I want to achieve is : concatenate someVector_ and %d
}
}
The point that has been made to you earlier in this thread is that instead of trying to do that (some kind of "variable variables" to borrow the term from PHP), create a container of vector<float> objects. This can be a vector of vector<float> objects, or if you are really fixed at 20 such vectors, then a fixed size array (whether a built-in array or std::array) will do.Quote:
Originally Posted by fclopez
It is just a restatement of the original question. There is no way in C++ to concatenate an integral value computed in a loop to a variable name, in order to create another variable name. Restating the problem does not make it solvable if it is not already solvable. C++ is not PHP, and cannot be used as if it is.Quote:
Originally Posted by fclopez
What you need to do is create an array (or a container) of vectors. There are various options.
or (using a naked array, like described by iMalc)Code:std::vector<std::vector<float> > someVector(20); // creates a vector containing 20 vectors.
for(int ivector = 0; ivector<20; ivector++)
{
for(int i = 0; i<1000; i++)
{
y = x*i*ivector;
someVector[ivector].push_back(y); // this is a functional equivalent of what you have described as someVector_%d.push_back(y)
// or, alternatively, someVector.at(ivector).push_back(y);
}
}
or using the std::array approach advocated as the bees knees by Elysia (although it relies on you having access to C++-11 compliant compiler)Code:std::vector<float> someVector[20]; // creates a array containing 20 vectors.
for(int ivector = 0; ivector<20; ivector++)
{
for(int i = 0; i<1000; i++)
{
y = x*i*ivector;
someVector[ivector].push_back(y); // this is a functional equivalent of what you have described as someVector_%d.push_back(y)
}
}
There are differences between these, and each technique has advantages and disadvantages.Code:std::array<std::vector<float>, 20> someVector; // creates a array containing 20 vectors.
for(int ivector = 0; ivector<20; ivector++)
{
for(int i = 0; i<1000; i++)
{
y = x*i*ivector;
someVector[ivector].push_back(y); // this is a functional equivalent of what you have described as someVector_%d.push_back(y)
// or, alternatively, someVector.at(ivector).push_back(y);
}
}
The first and second are supported by all versions of C++ (i.e. by the standard since 1998). The third method is not.
The first approach allows the number of vectors to be changed later, the second and third approaches do not.
The first and third approaches are considered "safer" by some if the someVector.at(ivector) is used instead of someVector[ivector] (assuming you know how to catch and recover from exceptions, as that is how the at() approach reports errors it detects). In comparison, the second approach is considered more dangerous (in the sense of robustness to programmer mistakes, such as making 20 vectors and accessing the 30th one). However, if used incorrectly, any of the approaches can yield invalid behaviour (writing over memory it shouldn't).
Thanks for the comprehensive suggestions.
How does one access an nth element of a vector in the array of vectors?
Code://say 100th element of ivector = 5
someVector[5][100]; // is this correct?
That would be correct. Remember that indices in C++ start at zero. So a vector or array with dimension n has elements with valid indices from 0 to n-1.
In your example, someVector[5] would correspond to the 6th vector<float> in someVector (0 is first, 1 is second, .... 5 is sixth). someVector[5][100] corresponds to the 101st float within someVector[5]. There is no check by a vector or array as to whether indices are valid, and it is the programmer's responsibility to ensure they are. Hence the use of the at() method which Elysia mentioned - that throws an exception at run time if given an invalid.
So don't do this
x[5] does not exist. Invoking x[5].push_back() invokes undefined behaviour according to the C++ standard. Practically, that often tromps some random area of memory, which results in a program crash. However, the compiler cannot check that .... it is the programmer's responsibility.Code:std::vector<std::vector<float> > x(5);
x[5].push_back(2.0f);
In addition to what has been said, I also simply disagree with both of those sentiments. Basically a "learn to float before you learn to swim" sort of argument.Quote:
Originally Posted by Elysia
I think that arguments for std::array are in general pretty weak. The cases where it is of significant benefit tend to be few and far between in reality.
std::string on the other hand adds a lot of useful functionality, and is worth knowing about sooner rather than later.
They should probably learn what it is that .at() is protecting them against, because they'll run into raw arrays pretty soon, and what they give up for that protection (*some* amount of performance and extra compilation time).
You've also worded your argument for .at() poorly, because no matter what you use, it isn't true that you can avoid having to think about out-of-bounds access, in most cases. I.e. if you have an off-by-one then the result is going to be an incorrect program either way. You're gonna have to think about it and get it right sooner or later.
But the point is, it was a standard, not just some compiler extension. Any compiler that implements TR1 supports it.Quote:
Originally Posted by grumpy
Anything can be misused. But the point is, it is harder to do so, and that is what we want. To catch more errors earlier.Quote:
Life is not that simple in the real world. Good practice can involve disciplined and effective use of available features, avoiding misuse, etc. I've seen enough "bad practice" that involves misuse of ostensibly safe features coupled with over-confidence since "it is safe, isn't it, so I can do what I like without checking". Including, in some cases, with misuse of std::array.
There is also the inconvenient fact that std::array is just a wrapper that provides an alternative interface for a normal array anyway. It is designed as a means of convenience, not a safety mechanism. It can be used in safe ways, or unsafe ways.
My point exactly. Yes, C++-11 features are useful. Yes, they can be safer. They are not, however, a safety net. And they can still be misused.
Unfortunately, the intelligence and skill of the C++ standards committee - although considerable - is bounded and finite. In contrast, the propensity of programmers to misuse language features has no known upper bound.
While we cannot teach newbies all good practices, don'ts and dos, we can at least provide some measures to help them become better programmers, by teaching them of security tools that exist (and refer them to use them by default).
std::array contains such a security feature, just like vector.
Never did it say it complemented the post. In my eyes, it seemed like it was completely disregarding it.Quote:
I disagree. His post was immediately after your post that mentioned std::array. By your logic, you had the obligation to mention C-style arrays as well, so his post should not have been necessary. Such an argument cuts both ways.
However, in forums, we don't aim for completeness - because we can't - unless there is a particular reason to. We provide options and discussion, not definitive or complete descriptions of everything.
Had there been some clause saying "In addition, there is this...", then I would have been satisfied (unless, of course, it mandated the use of such features of std::array if such an implementation is available).
We are just going to have to learn to disagree on this. Unless there is a particular reason why someone cannot use the latest and greatest, that is what we should teach, IMO.Quote:
I'm not alone in suggesting that. Recent teaching materials from people like Stroustrup do it too - although it is easier to take a staged approach to teaching when you can control the materials. A staged approach is not really practical in a forum with multiple independent contributors, but your approach of advocating the "latest, greatest, and allegedly safest while nagging those who provide alternatives" is not the answer to that problem.
Security comes before all, and a newbie should not have to be bothered with this until the time comes to delve into security in depth.
So you would rather skip std::array simply because it does not any significant benefits? This is a rather silly argument.Quote:
Originally Posted by iMalc
std::array have the iterator concept, size (at both run and compile time if constexpr is supported), and an optional check against out-of-bounds access.
You want to disregard all this and teach users C arrays, just so later they have to learn std::array (and likely using it by default later)?
Why not just teach them std::array from the beginning, and save all the trouble?
Yes! You should know these things. I am not against that. But you are going to have to remember that this is a topic of security. Security is all-important these days, and should be a formal subject anyone should learn, and not just bits and pieces. So I find this a very good topic to discuss when discussing security in-depth.Quote:
They should probably learn what it is that .at() is protecting them against, because they'll run into raw arrays pretty soon, and what they give up for that protection (*some* amount of performance and extra compilation time).
You've also worded your argument for .at() poorly, because no matter what you use, it isn't true that you can avoid having to think about out-of-bounds access, in most cases. I.e. if you have an off-by-one then the result is going to be an incorrect program either way. You're gonna have to think about it and get it right sooner or later.
Regardless, if the newbie does not know so much about security, I'd rather have them learn to use .at() than C-arrays with buffer overflows and out-of-bounds access.
If you want to teach them both worlds, go right ahead. I have no qualms. I simply want std::array to be mentioned as the preferred choice to reduce security risks and make C++ more like other modern languages that do bounds checking.
On modern computers, bounds checking is cheap. So, unless you really need the extra performance, you should make your program safer by using safer mechanisms. This is what I strongly believe.
If you did a survey of compilers after 2007, you would find that support of TR1 is relatively scarce.Quote:
Originally Posted by Elysia
Come off it. I've seen you do exactly the same thing after other people have posted. It is not unusual in forums for someone to answer the original question, without making reference to all preceding answers.Quote:
Originally Posted by Elysia
The particular reason I have is history. The C++ standard was in draft for about a decade before it was ratified in 1998. It wasn't until about 2003 (five years later) that any commercially available compiler supported more than 95% of all language or library features. And several vendors commenced development of their compilers in parallel with the standardisation activity (to the extent that compilers from at least three vendors were used as test cases for feasibility of language and library features, while the standard was in draft.Quote:
Originally Posted by Elysia
In fact, there is one language keyword (export) which has only ever been supported by two compiler products (and products derived from those). That feature is now deprecated, and has never been in common use. Imagine if someone kept haranguing people in forums to use "export" in the late 1990s .....
On that precedent, it is a fair bet that several C++-11 language or library features will not be supported by most compiler products for at least a couple of years (or 2015-2016 if we're pessimistic).
Teaching a language for which implementations (compilers and libraries) are not yet readily available is actually an effective way to discourage use of newer features. The error messages a compiler will emit if a particular feature is not supported, or only partially supported, tend to discourage using those features again. When implementations become readily available, you will find that experienced practitioners will tend to take up the newer features, and also encourage more use by novices.
So, you're characterising the .at() method of std::vector and std::array as a security feature? Its default action on a bounds violation (throwing an exception that, by default, causes program termination) might prevent instances of undefined behaviour. From a security standpoint, that is pretty weak. Security assurance generally encompasses preventing invalid accesses, but also providing continuity of correct service (which the default behaviour of .at() does not).Quote:
Originally Posted by Elysia
I would suggest advocating std::array because it is a recently introduced feature is an even sillier argument.Quote:
Originally Posted by Elysia
As I said above, that "optional check against out-of-bounds access" is pretty weak from a security perspective.Quote:
Originally Posted by Elysia
If you dig up articles by Andrei Alexandrescu, you will find all sorts of arguments that iterators in the C++ library should be deprecated, in favour of range-based design. He considers that all iterator types are fundamentally unsafe and that, while safe iterators have been written, they come at a high cost in terms of size (of code, or memory usage) and speed.
I don't think anyone has suggested disregarding std::array, except in your mind.Quote:
Originally Posted by Elysia
As a practitioner, I have considered using std::array in production code on a few occasions. Each time I have used something else (mostly in favour of other containers, but once in favour of a C-style array) because the benefits it offers are insignificant. The security benefits you claim are weak (at best) or an illusion that encourages complacency (at worst).
I would suggest the jury will remain out for some time on the question of whether developers - beginners or otherwise - will use std::array by default. The case, at present, is certainly not yet strong enough to justify it being a preferred choice. And your argument about its security benefits does not hold up.
Security comes before portability, in my mind (unless you otherwise have a good reason). Besides that, three major compilers already supports std::array and a whole lot more. That makes it enough to mention them to newbies. We cannot--must not--worry too much about what comes later for newbies. Maybe they have to maintain old code. Maybe they have to program embedded controllers. Maybe they will use the latest and greatest features in building programs.
We do not know, nor will we know. The choices are them to teach everything: the safe, the latest and greatest, the unsafe, or to teach one of the paths. And if we teach only one of them, I'd rather concentrate on correct, secure and latest and greatest. If anything, latest and greatest should become all the more relevant in coming years. I cannot mention all the paths or ways, nor can I be bothered to. So I am going to concentrate on the way I think is best. All I wanted from anyone else was to at least mention the latest and greatest instead of throwing newbies down a dangerous and perilous path. Feel free to disagree.
And again, any security is better than none. Even if .at() is pretty weak in a security standpoint, it still prevents buffer overflows and out-of-bounds reading.
So we are just going to have to learn to disagree.
I'm not fussed about you mentioning std::array where it fits, although I consider the premise of your endorsing it remains weak.
Your position strikes me as hypocritical. On one hand, you can't "be bothered to" mention alternatives to your preferred approach. On the other hand, you demand that everyone else give some form of honourable mention of your preferred approach, and have repeatedly nagged (in this and other threads) anyone who does not.
Demanding and nagging are different things.
If you don't like something, you speak up. If your view conflicts with others in such a way that you feel you must speak up in several threads, it comes off as nagging. Yes, I nag when I feel I don't agree with others views. This is a discussion forum, after all?
I don't demand. Everyone is free to take their own approach and have their own mind. I cannot--nor should--push my ideals onto others. I will never tell you to do this or that. But I can nag, and when I feel someone does something wrong, I sometimes do.
If the one I nag about do not agree, sometimes that one protects his/her own ideals, which leads to discussion. Like this one. Eventually, it ends either when parties agree or cannot agree. Regardless, it does tend to bring about different views of things, which might in itself be a good thing.
>> If you don't like something, you speak up.
Please take responsibility for the C++11 features you demonstrate in your posts. Because if C++11 support is not enabled, you will get errors, like I said. After that, I don't know what happens. Maybe newbies just assume that you don't know what you're talking about and they continue to use the "unsafe" alternatives, thanks to your negligent incompleteness. Mention that C++11 needs to be turned on in the compiler options and which options to flip. Since it's important to you, the easy thing to do would be to make it part of your signature: maybe go through the process on 2 or 3 kinds of compilers somewhere on the net and refer to that. I mean if you believe in something, it's the least you could do for newbies to allow them to actually use your advice.
>> If the one I nag about do not agree, sometimes that one protects his/her own ideals, which leads to discussion. Like this one.Quote:
Originally Posted by Security Now podcast #364, August 8, 2012
Most are unproductive. I'm don't believe in software engineering "ideals" because I'm jaded, but on top of that, these discussions usually end with nothing accomplished, nothing conceded, and nothing learned.
A fair advice. I will create SourceForge.net: Cpp11 - cpwiki, then fill it out as best I can, then refer to it in my signature.Quote:
Originally Posted by whiteflags
[const] pointers are [const_]iterators. They only lack reverse iterators which are less common.Quote:
Originally Posted by Elysia
The size of an array is always a constant.
The container makes these things more consistent with other containers, but it doesn't really add much over a plain array. Plain arrays one unfortunately needs to know about because you will always run into those.
Sure, I should perhaps use std::array more often than I do (which is hardly ever), but they don't realy add anything of value to me in most places I would use them. I do like the idea, but there are still barriers such as being stuck using certain other compilers for embedded devices etc, to me adopting it more fully.
I might have an array that simply is populated with say a filepath in one API method, and that then goes straight to another API two API calls, and that's all it is used for. I'm not even going to be looking at any of the contents with my own code etc. It's impossible to justify std::array in such a case; You gain nothing whatsoever. Lets get over this blanket rule idea of "use it every time by default". Use whichever is most appropriate for the task at hand. E.g. does it need to work with older compilers?
You know what, this is all at least convincing me to bring up std::array more than I do. I will try to mention both when it seems appropriate.Quote:
Yes! You should know these things. I am not against that. But you are going to have to remember that this is a topic of security. Security is all-important these days, and should be a formal subject anyone should learn, and not just bits and pieces. So I find this a very good topic to discuss when discussing security in-depth.
Regardless, if the newbie does not know so much about security, I'd rather have them learn to use .at() than C-arrays with buffer overflows and out-of-bounds access.
If you want to teach them both worlds, go right ahead. I have no qualms. I simply want std::array to be mentioned as the preferred choice to reduce security risks and make C++ more like other modern languages that do bounds checking.
On modern computers, bounds checking is cheap. So, unless you really need the extra performance, you should make your program safer by using safer mechanisms. This is what I strongly believe.
My thoughts for you are though that people will come around. You just need to give them time, and be gentle or you risk having them going the other way out of spite. Plant the seed of the idea, water it lightly every now and then, and let it grow on them.
Yes, the size is constant, but the problem is typically to find the size when you have to use it. The added risk of arrays decaying to pointers when passed to functions, making one unable to tell the size doesn't help very much.Quote:
Originally Posted by iMalc
Also, I don't know if this is a bug or intentional, but I have encountered some algorithms in the past where pointers won't work as iterators. std::array, implementing them properly, should work nicely with those.
All I am trying to say is that whenever you use an array, you should look over your options.Quote:
...I do like the idea, but there are still barriers such as being stuck using certain other compilers for embedded devices etc, to me adopting it more fully.
I might have an array that simply is populated with say a filepath in one API method, and that then goes straight to another API two API calls, and that's all it is used for. I'm not even going to be looking at any of the contents with my own code etc. It's impossible to justify std::array in such a case; You gain nothing whatsoever. Lets get over this blanket rule idea of "use it every time by default". Use whichever is most appropriate for the task at hand. E.g. does it need to work with older compilers?
Can you use std::array? If not, then fine, use C arrays.
If you can, then ask yourself: is it practical? If all it does is hinder development (as in your example above), then fine, use C arrays.
But if it doesn't make things worse--or better, if you gain something from it--then please, use it. It's there for a reason.
Sometimes one might also consider changing C arrays to std::array, too, if it gives sufficient benefits. But at least, if the above line holds true, then at least consider using them.
It is very difficult to know the mindset of someone on a forum. It is also very difficult for others to understand others mindsets. It's so easy to come off arrogant and demanding while in reality one is not. Were it in real life, reactions and body language could be used to distinguish these.Quote:
My thoughts for you are though that people will come around. You just need to give them time, and be gentle or you risk having them going the other way out of spite. Plant the seed of the idea, water it lightly every now and then, and let it grow on them.
I try my best to make comments on where I feel things need be added. I try to not sound demanding or insulting, but sometimes it's just hard...
So if anyone finds me arrogant, demanding or insulting, then know that I do not mean it, even though it may come off as such.
And sorry to anyone who thinks they've been insulted.
I might have to disagree with that. In this one thread I have learned more about std::array than I could have expected to (as I did not know if its existence beforehand). I learn alot from most of ya'lls (ya it says texas on my profile) discussions as each extremely opinionated senior programmer comes along and provides their own view on the topic at hand.Quote:
>> If the one I nag about do not agree, sometimes that one protects his/her own ideals, which leads to discussion. Like this one.
Most are unproductive. I'm don't believe in software engineering "ideals" because I'm jaded, but on top of that, these discussions usually end with nothing accomplished, nothing conceded, and nothing learned
If you expect to change someone's opinion then yea the discussion is pointless, but if the discussion is for showing new people who stumble on this thread the pros and cons to std::array I think that was achieved very well.
A bit offtopic ;), but pointers can be used as reverse iterators as well (reverse iterators are only wrappers around the regular ones shifted by 1).Quote:
Originally Posted by iMalc
Code:int array[5] = { 1, 2, 3, 4, 5 };
for (std::reverse_iterator<const int*> it(array + 5);
it != std::reverse_iterator<const int*>(array);
++it)
{
}
That's why you sometimes put an emoticon or something.Quote:
Originally Posted by Elysia
Then it suddenly gives a completely different feeling.
Am I right?
...Am I right? :)
You can't accuse someone of teaching bad practices and make it okay with a smilie. The only way to make it OK is to be right. I tell Elysia constantly to pick his battles.
I want to complicate the story some more. How does one write an array of array of vectors. Many thanks for the help!
F.
Quote:
Originally Posted by grumpy
What answer would you venture? Does it work? Why, or why not?Quote:
Originally Posted by fclopez
Code:
int iMax=50;
int jMax = 20;
const int kMax = 10;
int x =5;
int y;
vector<int> someVector[kMax]; // my problem is here....I want to create an array of array of vectors. How does one declare it???
for (int i =0; i<iMax; i++ {
for(int j = 0; j<jMax; j++) {
for(int k = 0; k <kMax; k++) {
y = k * j * i * x;
//then do push_back(y) here
}
}
}
How would you create an array of arrays of integers?
Code:
int iMax=50;
int jMax = 20;
const int kMax = 10;
int x =5;
int y;
vector<vector<vector<int>>> someVector(kMax); //no complains here
for (int i =0; i<iMax; i++) {
for(int j = 0; j<jMax; j++) {
for(int k = 0; k <kMax; k++) {
y = k * j * i * x;
someVector[i][j].push_back(y); //but it crashes here;
}
}
}
For any i, someVector[i] has 0 elements, which means that someVector[i][j] does not exist.
And the most outer one should be initialised to iMax, not kMax.
Code:const int iMax = 50;
const int jMax = 20;
const int kMax = 10;
int x = 5;
int y;
vector<vector<vector<int>>> someVector(iMax, vector<vector<int>>(jMax));
for (int i =0; i<iMax; i++) {
for(int j = 0; j<jMax; j++) {
for(int k = 0; k <kMax; k++) {
y = k * j * i * x;
someVector[i][j].push_back(y);
}
}
}
Thanks!Quote:
Originally Posted by kmdv
I am using my actual code. Say I would like to access what I just pushed back....
then access the elements count_at_thresholdCode:for(int ithresh=th_begin; ithresh<th_end+th_interval; ithresh = ithresh+th_interval) {
for(int ichan=chMin; ichan<chMax+1; ichan++) {
for(int ipos=0; ipos<npos; ipos++) {
sprintf(fname,"%s%d%s%s%s", fpath, ipos,file_pref, specifier,ext);
TH2F *h2_dummy=createScan(fname, th_begin, th_end, th_interval, nchans);
TH1F *h1_ichan = getCh(h2_dummy, ichan);
count_at_threshold = (int) h1_ichan->GetBinContent(h1_ichan->FindBin(ithresh));
delete h1_ichan;
delete h2_dummy;
vec_th.at(ithresh).at(ichan).push_back(count_at_threshold);
}
}
}
Code:int value;
int ithresh = 20;
int ipos = 0;
for(int ichan=chMin; ichan<chMax+1; ichan++) {
value = vec_th.at(ipos).at(ithresh).at(ichan); //problem here. How does one access the elements "count_at_threshold"
}
If you want to access what you have just pushed back, you can call `some_vector.back()`. But in the case of your second loop, instead of:
you might want:Code:vec_th.at(ipos).at(ithresh).at(ichan);
Code:vec_th.at(ithresh).at(ichan).at(ipos);
Thanks kmdv!Quote:
Originally Posted by kmdv
Following your suggestion
gives meCode:vec_th.at(ithresh).at(ichan).at(ipos);
So I modify a bit my code toCode:terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check
still gives meCode:int value;
for(int ichan=chMin; ichan<chMax+1; ichan++) {
for (int ipos=0; ipos<npos; ipos++) {
value = vec_th.at(ithresh-th).at(ichan).at(ipos);
}
}
//or even
int value;
for(int ichan=chMin; ichan<chMax+1; ichan++) {
for (int ipos=0; ipos<npos; ipos++) {
value = vec_th[ithresh][ichan][ipos];
}
}
Thanks in advance for the help!Code:terminate called after throwing an instance of 'std::out_of_range'
what(): vector::_M_range_check
What about using a debugger? You access a non-existent vector element, that's all.
There are some possibilities which you have to check on your own:
I would consider using assertions + operator[] http://www.cplusplus.com/reference/cassert/assert/.Code:
assert(ithresh - th < vec_th.size());
int value;
for(int ichan=chMin; ichan<chMax+1; ichan++) // It may be: `ichan < chMax`, but it depends on chMax
{
assert(ichan < vec_th[ithresh-th].size());
for (int ipos=0; ipos<npos; ipos++)
{
assert(ipos < vec_th[ithresh-th][ichan].size());
value = vec_th[ithresh-th][ichan][ipos]; // Ensure that `ithresh >= th`
}
}
Unless there is a reason why one must not use exceptions, I don't see why you have to make life harder for yourself.Quote:
Originally Posted by kmdv
Btw, what are these functions createScan and getCh which returns stuff you must delete? Is there a reason you must delete the returned result? Can you rewrite them so that you don't have to call delete? If so, you should do so.
I think it is pretty obvious that in his case, an attempt to access vector out of its range is a pure programming error.Quote:
Originally Posted by Elysia
Every language has different ways and tools for solving different problems, and C++ is not one of those like Java where obvious programming errors are reported via exceptions.
Whether it is harder... it depends; messages generated by assertions usually carry a little more information than std::out_of_range.
I agree that it's a programming error, but what I disagree on is that you have to teach newbies:
You know, you could make an out-of-bounds access here, therefore you must create an assert that checks that you're not doing an OOB access.
And newbies go: "WHAAAAAT? Why won't I just get an error? Why do I have to create some magic statement just because I'm accessing an array?"
Yes, asserts are very nice and yes, I agree, they should be used to protect against programming errors, but in this case, IMHO, it's just making things worse. We should not have to teach newbies what OOB access is. It should just "work" out of the box. Leave OOB to security courses.
Also, getting asserts right are more complicated than using at and relying on the exceptions to report the error. Most testing facilities tend to fail tests if an unexpected exception is thrown (which is a good thing™) and debuggers typically have the power to break on an unexpected exception.
I think most newbies would get the assert wrong, anyway, making it pointless.
If you can't get boolean logic your career in programming is short lived.
Oh, the boolean part is easy. The rest isn't.
If your point is that in this particular exercise for this particular newbie, the .at() member function is a better choice than assertions, then I agree - all his exception handling is probably one handler printing the error and exiting the program, so it's perfectly fine to leave it for another exercise. However, I don't agree if this is a part of his (even first) application he wants to deploy.Quote:
Originally Posted by Elysia
o_OQuote:
Originally Posted by Elysia
Since when are assertions "harder to get right" than handling exceptions?
Please show me at least one newbie who is able to properly code a member function which modifies two STL containers at a time and provides strong exception guarantee. Newbies are taught that exception handling is a great way for error reporting. As a result they think of it as a brilliant mechanism, making assumptions that their functions have strong exception guarantee (without knowing this term), leaving everything without proper handling, and then continuing execution of their program to "retry something".
The problem in reporting programming errors via exceptions is that you can accidentally catch such exceptions, and continue execution. You catch "std::out_of_range" and you think "WTF, what a stupid user entered a bad index!?".
Assertions cause immediate termination and will never change your exception guarantees.
If that's the case, then he/she wouldn't (shouldn't) be a newbie anymore.Quote:
Originally Posted by kmdv
If you are going to deploy an application, then you should at least be versed in security, which opens another can of worms of real world problems. In real life, there is never one solution. There are always multiple solutions, and which one is the best depends on the circumstances.
I meant that it's harder to get manual bounds checking right than simply using a member function that's part of a library.Quote:
o_O
Since when are assertions "harder to get right" than handling exceptions?
Please show me at least one newbie who is able to properly code a member function which modifies two STL containers at a time and provides strong exception guarantee. Newbies are taught that exception handling is a great way for error reporting. As a result they think of it as a brilliant mechanism, making assumptions that their functions have strong exception guarantee (without knowing this term), leaving everything without proper handling, and then continuing execution of their program to "retry something".
The problem in reporting programming errors via exceptions is that you can accidentally catch such exceptions, and continue execution. You catch "std::out_of_range" and you think "WTF, what a stupid user entered a bad index!?".
Assertions cause immediate termination and will never change your exception guarantees.
Also, while asserts are nice, they do have a drawback. Assume that you have some long-running operation and you interact with the program meanwhile. Suddenly, you violate a precondition. Should the program crash because of an assert? I sure hope not!
The line between where asserts are good and bad and where exceptions are good and bad aren't easy to know. I would take any exception caught with a grain of salt because it could come from anywhere, even programming errors.