C++

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

The word size varies with the architecture / processor, some 80x86 architectures have 16 bit word sizes not all. It is therefore not really helpful or accurate in general to talk in word sizes unless you are in an architecture / processor specific context.

Therefore in modern IA-64 architecture a IEEE double precision floating point coresponds to just one word ! Its the IEEE standard thats most relevant to the CPUs FPU really, the machine word is not that relevant.

Its a common misconception that a word is 16 bits so I can see why you said that but its not a good habit to get into, easier to talk in bytes or bits really.

Again this is perhaps nit picking, but compiler type sizes do change from one platform /architecture to another so to write portable C/C++ its an important topic.

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

What you're claiming is that the definition of a 'word' is generally undefined. It isn't. The claims made my various manfacturers is irrelevant to the generally accepted definition as quoted in the wikipedia link. I think where you are getting confused is what manufacturers define as a 'word' at the assembly code level, whereby your pointed-to definition in wikipedia

holds, because in assembly language a word can have an unfixed meaning. The terms '32-bit word' and '64-bit word' do fly around an awful lot, but this should not be confused with the actual definition that a 'word' is two bytes (16-bits).

Hopefully I've clarified where you are getting confused.

 

Its normally the size of a register, but could also be the width of the databus, or the size of a pointer in most systems. Depending what you read the Intel arch and Microsoft sometimes defines it as always 16 bits probably for backward compatibility. If you consider the larger context all architectures/processors (not just PC) you will see this is a peculiarity.

Theres even the 8088 which was a weird 8/16 bit hybird.

http://msdn.microsoft.com/en-us/library/ms952405.aspx

You will find references stating word size as everything from 16 / 32 / 64 bit for common 80x86 processors.

It really is a confused concept on the 80x86 platform so thats why I reccomend avoiding using the term where possible.

 

You're being vendor-specific again completely ignoring the point of my last post. Ignoring the use of the term 'word' is akin to ignoring the use of the term 'bit' or 'byte'. For instance with harddrives quoted capacities are normally to the base 10 rather than base 2. Should we argue about that as well?

You are maddeningly stubborn, determined to stick to what you believe to be right rather than what is right. You want the last word? Here, take it. If you wish to continue start another thread instead of hijacking this one with your stubborn ego!

 

Actually this is wrong its a sign bit for the mantissa and Excess 127 (in single precision) for exponent, my original point was people should understand the different ways of encoding numbers in binary in general including signed number representations .

 

Hope I find you all well below is a bit of code

vector <int> vec(3,100)

vec.push_back(200);
cout <<"Vector Size:" << vec.size() << endl;
cout <<"First Element:" << vec.front() << endl;

programe prints

vector size: 1
First Element: 200

trying to get my head round the maths on this, as the book says "push_back(value)
adds an element to the end of the vector containing a specified value.

it seems to me if vector size = 1 it has removed 2 vectors if the original vector was 3.
where am i going wrong.

 

Code:

#include <iostream>
#include <vector>
#include <algorithm>
#include <functional>
using namespace std;

template<class TYPE> struct print : public unary_function<TYPE, void> {   
    void operator() (TYPE& n) 
    { 
        cout << n << " "; 
    } 
};

int main()
{
    vector<int> vec(3, 100);

    cout << "Vector Size:" << vec.size() << endl;

    vec.push_back(200); 

    cout << "Vector Size:" << vec.size() << endl;

    cout << "First Element:" << vec.front() << endl;

    cout << "Vector Size:" << vec.size() << endl;

    for_each(vec.begin(), vec.end(), print<int>());

    return 0;
}

PRINTS :-

Code:

Vector Size:3
Vector Size:4
First Element:100
Vector Size:4
100 100 100 200

This is as expected.

vector <int> vec(3,100); // Creates vector filled with 3 100's eg [100,100,100]
vec.push_back(200); // Adds an element eg [100,100,100,200]
vec.front(); // peak at first element, does not remove !

The reason the datastructure is designed this way is because its implementation is generally based on a resizeable/relocatable block of memory, basically an ordinary array underneath with some logic to control when to malloc/realloc.

 

Well, for this line of code

Code:

vector <int> vec(3,100);

You are actually creating...

Code:

int vec[] = {100, 100, 100};

Can you see this?

Here is the code to show this...

Code:

#include <iostream>
#include <vector>
using namespace std;

int main()
{
	vector <int> vec(3,100);

	for(int i = 0; i < 3; i++)
		cout << "vec[" << i << "] = " << vec[i] << endl; 

	return 0;
}

When you 'push_back()' the size should increase by one element (as you know)...

Code:

#include <iostream>
#include <vector>
using namespace std;

int main()
{
	vector <int> vec(3,100);

	for(int i = 0; i < 3; i++)
		cout << "vec[" << i << "] = " << vec[i] << endl; 

	cout << "vec.size = " << vec.size() << endl;	// Number of vector elements.

	vec.push_back(200);

	cout << "vec.size = " << vec.size() << endl;	// Number of vector elements.

	for(int i = 0; i < 4; i++)
		cout << "vec[" << i << "] = " << vec[i] << endl;

	return 0;
}

Voila!

I have no idea why you would be losing your first three elements (unless you pop_back() three times first!). Feel free to post your code.

[edit]
Forgot to explain vec.front(), but that has been already done.
[/edit]

 

here it is Heading Employing vector arrays

#include <vector>
#include <iostream>
using namespace std;

int main()
{
vector <int> vec(3,100);
cout <<"Vector Size:" << vec.size() << endl;
cout <<"Is Empty:"<<vec.empty() << endl;
cout <<"First Element:"<< vec.at(0) << endl;

vec.pop_back();
cout <<"Vector Size:"<< vec.size() << endl;
cout <<"Final Element:"<< vec.back() <<endl;

vec.clear();
cout <<"Vector Size:"<< vec.size() << endl;

vec.push_back(200);
cout <<"Vector Size:" << vec.size() << endl;
cout <<"First Element:" << vec.front() << endl;

return 0;
}

I can work out all but this last bit. vec.front fine thats easy. I expect push_back is simple to.
if vector size (3,100) gives a value of 3 that make sence, push_back(200).

OH does that mean it pushes back to value to 100 from 300 then adds an element to make it 200.
is that how it works.

 

And your problem was...

Code:

vec.clear();

That 'deletes' your vector.

Get rid of that line of code to see everything as normal.

 

pop_back(), 'Pops' a value off the back of the container.

It removes the last element from the collection and returns it.

http://www.cplusplus.com/reference/stl/vector/pop_back.html

and yes clear() erases all elements from a vector and calls each elements destructor.

http://www.cplusplus.com/reference/stl/vector/clear.html

Its designed to reclaim memory and potentially allow a vector variable to be reused.

empty() is a status check function to determine if container has no elements.

 

Nope, have a read of the code I posted two posts ago. It's cleaner. What you are doing is only manipulating the vector and not the values contained within.

 

Thats much clearer, The vec.clear() was confusing the situation. On to declaring constants now, well tomorrow night.

 

"GOT IT" i was thinking vec (3,100) went 1=100, 2=200, 3=300, just ran your code and noticed 1=100 2=100 3=100 push back added an element making a fourth element with a value of 200. Im going to have a dance round the floor now.

 

Spot-on, mate! Top marks!

So now you probably understand from earlier that

Code:

vec.front();

is actually

Code:

vec[0];

which is 100.

 

vector <int> vec(3,100); // Creates vector filled with 3 100's eg [100,100,100]
vec.push_back(200); // Adds an element eg [100,100,100,200]
vec.front(); // peak at first element, does not remove !

The reason the datastructure is designed this way is because its implementation is generally based on a resizeable/relocatable block of memory, basically an ordinary array underneath with some logic to control when to malloc/realloc.[/QUOTE]

Hi dmarsh26
with a clear head I can now see how it works. When it says add elememt i was literally adding ie 100 + 100=200 +100 = 300 you can see where i was going wrong it was only when i ran mathmatix code i could see the fourth element, Now looking at your example I can see its exactly the same with the fourth element = a value of 200, I feel this is a big piece of the puzzel that has now been put i place on how compilers work. Also it show you how my brain can take me of in the wrong direction. Thanks for sticking with me.

its like you said in one of the earlier threads got to think like the compiler.

 

Still cock_a_hoot that was A very big penny that droped into place last night.
as I mentioned to Dmarsh26 it was only when I ran that code of yours and wondered where did that 4th line come from.then I could see the program running and all the values were 100 and that push_back (200) was simply lumped on the end with a value of 200 and yes all the other vectors fell into place then.You two should write a book.

long way to go yet but at least its comming together now.

Cheers Martin

 

That's what I love about C++, when you learn something you get a feeling of euphoria! It can become a little addictive as well.

I have made a couple of very minor contributions so far to a couple of books released on games develeopment. Potential for writing a book is something that has been mentioned to me a lot of times because I am a very good teacher and make quite complex issues seem simple - probably because they usually are as simple as I explain them.

As long as you bare in mind that you will get there in the end. In learning C++ it will have its highs and lows, and you will eventually come across concepts that you will have to discover for yourself as no-one can teach them to you, nor any book clearly explain them. All you have to do is hang in there!

 

Have you thought of taking a class in the lab partners section,same goes to Dmarsh26.Hec why not include Hbroomhall, worth a thought. You know ill be the first to sign up. suppose the problem would be which language to go with.

I have no doubt you are right about that, but im pretty good at handerling stress.

 

Hey,

I did some C++ at Uni a while back as part of an Electronics degree, definitely still a beginner tho! I'm currently studying up again to brush up and expand my programming skills. This thread's becoming part of that study. Thanks!

But looking through here: vectors? :hhhmmm This is the first time I've seen them. It seems to me they're essentially just arrays with some bells and whistles. What's the point of them? What functionality do they add? What can I do with a vector that I can't do better (i.e. more directly) with an array?