Ubound

Wow, its unbelievable that C++ was invented by one man single handedly!!! Just UNBELIEVABLE!! He must be a Genious!! And have all the free time in the world. Because that stuff takes time to come up with and even after years and years, the original C++ s still used world wide and covers just about anything u can imagine. Wowowowowow.

There are 64-bit versions of Win2k and XP, for the Alpha processor. New versions are created for the IA-64 architecture.

On IA-64, int is 4 bytes, long is 4 bytes, long long (or _int64) is 8 bytes, pointers are 8 bytes. short 2 bytes, char 1 byte, wchar_t 2 bytes. float 4 bytes, double 8 bytes. Can't think of any other type.

I thought they ditched Alpha support after NT4 (which runs on Alpha).

CB: Is there support for a long double? The SGs have a 128-bit float type :)

Some CPU/OS/runtime library combinations support long double as an 80-bit floating point number, but not all.

And I'm pretty sure that Win2k exists in an Alpha version.

I'm pretty new to C++, but I've been using the following. If I should not be, please someone tell me why:

Code:

---

#include <iostream.h>

void main(){
        int myArray[35];
        cout << sizeof(myArray) / sizeof(myArray[0]);

}

---

Quote:

---

Originally posted by Cawas
What about plain C?

#define isn't to work on pre-compiler only? I think this wouldn't work in plain C...

Can someone help me here? :D

---

N/M I just saw this post. I'm sorry.

You shouldn't be using it because the use of this snippet is exactly zero.

Then how do I write a for loop (sorry, as I said, I'm pretty new) where I iterate through all the elements of the array?

In the past, I would get the upper bounds like I just posted and then

for(int i = 0; i < (sizeof(myArray) / sizeof(myArray[0])); i++) codeHere;

for(int i = 0; i < yourKnownUpperBound; ++i)


There is no reason why you shouldn't know the upper bound of the array.

Quote:

---

Originally posted by Lord_Rat
Then how do I write a for loop (sorry, as I said, I'm pretty new) where I iterate through all the elements of the array?

In the past, I would get the upper bounds like I just posted and then

for(int i = 0; i < (sizeof(myArray) / sizeof(myArray[0])); i++) codeHere;

---

This doesn't work always. I think this idea was the first one given here... Take a look on page 1.

As long as I remember, the problem is when u use bi-dimensional array (like myArray[][])

Have to correct myself, there is no Win2k for the Alpha.

Quote:

---

This doesn't work always. I think this idea was the first one given here... Take a look on page 1.

As long as I remember, the problem is when u use bi-dimensional array (like myArray[][])

---

I saw that post only after I posted. I missed it the first time around. However, for the record, it does work on multidimensional arrays. Take the following for example:

Code:

---

#include <iostream.h>

void main(){
        int myArray[35];
        cout << sizeof(myArray) / sizeof(myArray[0]) <<"\n";

        int notherArray[10][20];
        cout << "dimension 1 of notherArray: " << sizeof(notherArray) / sizeof(notherArray[0]) << "\n";
        cout << "dimension 2 of notherArray: " << sizeof(notherArray[0]) / sizeof(notherArray[0][0]) << "\n";
}

---

Quote:

---

There is no reason why you shouldn't know the upper bound of the array.

---

I disagree.

Before I make my point, allow me to qualify my statement. I know Assembler (console, not GUI), Java, VB6 and VB.Net.

In the latter three, you can get the upper bound of an array automatically through Array.Length or UBound(Array).

My disagreement stems from the following points.

In order to know the size of an array without programmatically determining it requires that you keep a global variable (at least one with the same scope as the array) that keeps track of the array elements in which you will need to constantly modify that variable if you modify the size of your array.

This leads to code that is less easy to read, code that is more prone to error, and usually slower code as well. Slower because in the instance when I use an array that is dynamically sized, I usually do a large number of sizing and resizing during execution of my code. After all of that is done, I need to know the final size of my array. At that time, it is not going to change further. It is there I determine the size of the array.

If I had to store the array size as I resized and also resize, rather than resizing only, each iteration through the loop has more steps than necessary.

Sure, I'm aware that under normal operation, the speed difference would not be significant, but I'm currently using C++ to optimize some of my slower loops in VB.Net, where I currently have a working DirectX8 graphics engine. I want every piece of speed I can get. I would do it in Assembler, except for the fact that I have not been able to successfully link Assembler to DirectX.

Ok, if you can get the upper bound through some function, where is it being stored? When you change the array something must *still* be kept up to date.

PS: <iostream> and int main() :)

bla bla bla bla

Code:

---

#include <vecotor>
using std::vector;

vector<int> intArray;

intArray.push_back(1);
intArray.pop_back();

---

Quote:

---

I disagree.

---

I do too.

Quote:

---

Before I make my point, allow me to qualify my statement. I know Assembler (console, not GUI), Java, VB6 and VB.Net.

---

Ok, I know assembler, C, C++, Java, VB, Perl, JavaScript, PHP, Pascal and Delphi.

Quote:

---

In the latter three, you can get the upper bound of an array automatically through Array.Length or UBound(Array).

My disagreement stems from the following points.

In order to know the size of an array without programmatically determining it requires that you keep a global variable (at least one with the same scope as the array) that keeps track of the array elements in which you will need to constantly modify that variable if you modify the size of your array.

---

So do those languages internally.

Quote:

---

This leads to code that is less easy to read,

---

Not if you give those variables good names. Where is the difference between
UBound(arr)
and
UBoundOfArr
?

Quote:

---

code that is more prone to error,

---

Why?

Quote:

---

and usually slower code as well. Slower because in the instance when I use an array that is dynamically sized, I usually do a large number of sizing and resizing during execution of my code. After all of that is done, I need to know the final size of my array. At that time, it is not going to change further. It is there I determine the size of the array.

---

Do you really want to know how VB handles arrays? It's not pretty, and it's terribly slow.
And resizing arrays often is always a bad idea, it is a sure way to waste time.

Quote:

---

If I had to store the array size as I resized and also resize, rather than resizing only, each iteration through the loop has more steps than necessary.

---

The problem of VB is that it is very likely that a seemingly innocent code line takes eons to execute.

Quote:

---

Sure, I'm aware that under normal operation, the speed difference would not be significant, but I'm currently using C++ to optimize some of my slower loops in VB.Net, where I currently have a working DirectX8 graphics engine. I want every piece of speed I can get. I would do it in Assembler, except for the fact that I have not been able to successfully link Assembler to DirectX.

---

You have chosen the right language to optimize.

I want to add that I once translated array-heavy VB code to C, it ran about 30 times faster...

how do you keep track of arrays in asm? And dont u have to keep the size around? I understand that asm is low level language so im guessing it doesnt encapsulate anything for you... so since you brag about asm and vb encapsulating things for you, how does asm do it, im curios to know.

Also, there are loads of c++ classes that take care of this, CornedBee was right, C/C++ is the language u want to optimize on.. unless you wanna go all the way assembly.

Having said all that, I want to tell you something... VB6, VB.Net and Java are all high level languages. This just means that all the code in these languages are done for you inside a big fat wrapper. So you wouldnt know anyways. And finally, If you dont want the solution mentioned, vector is a very nice wrapper for dynamic arrays. But dont stop there, there are tons more... STL

If thats not enough, build your own linked list class or an expanding array class.

BTW Parksie, Server Error in your sig :)

Now, for practical purposes, let's compare C and VB code.

Code:

---

int iSizeOfArray;
int *arArray;

iSizeOfArray = GetDataLength();
arArray = new int[iSizeOfArray];

GetData(arArray, iSizeOfArray);

for(int i=0; i < iSizeOfArray; ++i)
{
  if(arArray[i] == -1)
  {
    delete[] arArray;
    iSizeOfArray = GetOtherDataLenght();
    arArray = new int[iSizeOfArray];
    GetOtherData(arArray, iSizeOfArray);
  }
}

---

VB Code:

Dim arArray() As Long
Dim i As Integer
 
ReDim arArray(1 to GetDataLength)
 
GetData arArray
 
For i = 1 to UBound(arArray)
  If(arArray(i) = -1)
    ReDim arArray(1 to GetOtherDataLength
    GetOtherData arArray
  End If
Next i

The loop body is just there to show that arArray is not necessarily constant.

What this little example shows us it that if UBound somehow calculated the size of the array the VB loop would be infinitly slower as it had to calculate it again and again, once for every iteration!
It only looks it up now, so there's no real difference. Where's the disadvantage of C++?

erm sorry but ur mixing vb and c code..

He said that ASM is the only language that does not keep track.

Here's pseudo-asm of the two loops I posted:
C++

Code:

---

; iSizeOfArray = GetDataLength()
call GetDataLenght
push eax
; arArray = new int[iSizeOfArray];
mov ecx, 4
mul ecx
push eax
call 'operator new[]'
add esp, 4
push eax
; GetData(arArray, iSizeOfArray);
mov edx, DWORD PTR [esp+4]
push edx
push eax
call GetData
add esp, 8
pop ebx
pop edx
; for(int i=0; i < iSizeOfArray; ++i)
xor ecx, ecx
restart:
cmp ecx, edx
jge end
; if(arArray[i] == -1)
mov eax, DWORD PTR [ebx+4*ecx]
cmp eax, FFFFFFFFh ; -1
jne update
; delete[] arArray;
push ecx ; only i needs to be preserved
push ebx
call 'operator delete[]'
add esp, 4
; iSizeOfArray = GetOtherDataLength()
call GetOtherDataLength
; arArray = new int[iSizeOfArray];
push eax
mov ecx, 4
mul ecx
push eax
call 'operator new[]'
add esp, 4
push eax
; GetOtherData(arArray, iSizeOfArray);
mov edx, DWORD PTR [esp+4]
push edx
push eax
call GetOtherData
add esp, 8
pop ebx
pop edx
pop ecx
update:
inc ecx
end:

---

Here's the VB, as it seems realistic

Code:

---

; assume a pointer to the internal array
; structure of arArray is stored in ebx
; ReDim arArray(1 to GetDataLength)
push ebx
call GetDataLength
mov ebx, DWORD PTR [esp]
push eax
push ebx
call ReDim
add esp, 8
; GetData arArray;
mov eax, DWORD PTR [esp]
push eax
call GetData
add esp, 4
pop ebx
; For i = 1 to UBound(arArray)
mov ecx, 1
restart:
push ecx
push ebx
push ebx
call UBound
add esp, 4
pop ebx
pop ecx
cmp ecx, eax
jg end
; If(arArray(i) = -1)
push ebx
push ecx
push ecx
push ebx
call GetAt
add esp, 8
pop ecx
pop ebx
cmp eax, FFFFFFFFh ; -1
jne update
; ReDim arArray(1 to GetOtherDataLength)
push ebx
push ecx
call GetOtherDataLength
push eax
mov eax, DWORD PTR [esp+8]
push eax
call ReDim
add esp, 8
mov eax, DWORD PTR [esp+4]
push eax
call GetOtherData
add esp, 4
pop ecx
pop ebx
update:
inc ecx
end:

---

The C++ is a little longer, but the instructions are simple. And there is no call inside the loop that is executed every time!

Why?

how did u get this asm? did you go and manually write all this or are you using a tool?

[edit]

Quote:

---

why

---

No semicolon in vbcode
[/edit]

I'm a living compiler :D

Quote:

---

Originally posted by MoMad
No semicolon in vbcode

---

Right, thanks, it's the habit of all other languages.

Quote:

---

Originally posted by CornedBee
Not if you give those variables good names. Where is the difference between
UBound(arr)
and
UBoundOfArr
?

---

The difference is that you would not need the line at all. If you HAD to have the line, then I totally agree.

Quote:

---

Why [Does the code run slower and it is more error prone]?

---

Extra execution.
If the developer is savvy with the language, the error prone part will probably not be a big deal. He'll see an error in the compiler and immediate smack himself if he did something dumb. My point, however, was that having more code leads to more opportunity to screw up. (A problem that can be applied anywhere).

Quote:

---

Do you really want to know how VB handles arrays? It's not pretty, and it's terribly slow.
And resizing arrays often is always a bad idea, it is a sure way to waste time.

---

Yup. If you can't help it though, you have to do it. I just preferred to do it faster. The reason I can't know the size is that I use the DirectX functions to create my geometry. These functions size and resize my arrays for me. The don't, however, tell me the new size of the array. For the most part, they expect you are just going to 'stick' it in to a new DirectX function...

Quote:

---

The problem of VB is that it is very likely that a seemingly innocent code line takes eons to execute.

---

Hence my disallusionment and eventual dissatisfaction with the language in general. However, I still have projects started in VB that I'm going to finish.

Quote:

---

You have chosen the right language to optimize.

---

:D

Quote:

---

I want to add that I once translated array-heavy VB code to C, it ran about 30 times faster...

---

Which is definitely my intent.

Keep in mind, that I was just pointing out that I disagree that it is always necessary to keep track of your array sizes when you can programmatically determine them. :)

I think this comes down to the same discussions people have about curly brace positioning.

Is it like this{

or like this
{

Some people feel one way, some others. I just wanted to make sure there were no implications that I weren't aware of. I have found (so far) that there aren't; and to also offer my solution for those who may be looking for it.

In closing, I don't think it's practical to expect that we are going to both feel the same way, and I think it's fair to admit that we both have very valid and practical points, therefore, I offer a truce. Let's agree to disagree.

Can I agree with myself that this thread should *really* be left to sleep, and maybe draw its pension :D

Quote:

---

Keep in mind, that I was just pointing out that I disagree that it is always necessary to keep track of your array sizes when you can programmatically determine them. :)

---

Depends whether you want the speed. For strings, especially (I'm dropping into C not C++ here...), I rarely pass the length around unless there are embedded NULLs. If you need the length then strlen() can handle it. Obviously, if you were in a loop you'd cache the length first, but then abandon it.

However, if you have a block of *binary* data, there is no way to detect the length without storing it as well.

So, everyone's right in a sense, it just depends what you use it for.

Agree parksie.

Just one question left:

Quote:

---

The reason I can't know the size is that I use the DirectX functions to create my geometry.

---

What functions would that be?