DaWei

For one thing, you can only refer to it with a pointer, not by its actual memory location (which is what the 'name' of an array represents). The compiler does a nice job of simulation. When you refer directly to an array, the array location and a pointer to the array location are often treated similarly. This is an illusion, for your ostensible benefit, as you will see if you refer to the emitted machine code. You might wish to see my tutorial, the sections, "Confustoids", and "What is NOT a pointer".

EDIT: For another thing, if you look at your own example of a "2D array", above, you will see that it is no such thing. It is not contiguous. You cannot derive the address of a given row arithmetically from the origin.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Narue

climbnorth, I appreciate your enthusiasm in convincing Dietrich to use vectors. My teammates at work were most amused.

__________________
Even if the voices aren't real, they have some pretty good ideas.

climbnorth

Do you have something against me??

I am just mentioning what I like to use and how I use it to accomplish my goals when using an array. My comment about resizing (what I considered to be) an array was posted to be constructive. If you know a better way- please share so we can all learn something. If you know what is wrong with what I had posted, please explain (thats why I started reading this forum, not to be ridiculed over array semantics).


DaWei-

If you could, please elaborate on your comment:

I am used to writing these 2D arrays the way that I had mentioned. I am not sure what you mean that I can not derive the address arithmetically. So far, I have not run into problems.. where would I run into problem? I am not sure what you meant. From your article:

This lends to the belief that, since I can reference these memory locations using the syntax: blah[i][j] then, isn't this an arithmetic operation?

I am still unsure where my fault is.. if you can, please point out explicitly where my fault is- I am very confused now what is wrong with this code.

Also, if it is within the scope of this thread, please also elaborate on the difference between an array and memory allocated and referenced as an array. If you can, please exlain how the offset to the memory is calculated (register names, etc) because I was wondering this and did not find any info online.

DaWei

You cannot address the array you demonstrated in your earlier post with the notation, "array [i][j]." That's one reason it isn't a true array.

The comment regarding the reversal of array notation has noting to do with the subject at hand.

When you fuck up, do not whine when corrected (except to your mama). Narue has nothing against you but your tendency to expose your ignorance while proclaiming that another person (Piz) is mistaken. You are the mistaken one.

This is the C++ forum. If you care to push the beauties of plain, vanilla C, there is a forum for that.

If you care to document your beliefs rationally, feel free to do so.

I will not comply with the request in your last paragraph in this thread. Ask your questions explicitly in a new thread. I did address that issue in the tutorial, but it seems as if I have gained a reputation as "cryptic".

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

climbnorth

In response to:

I have started a new thread in C forum to discuss the validity of my implementation. For those who are interested, I have implemented my previous example of what I call, a 2D array.

grumpy

As a matter of fact, the the notation "array[i][j]" has a valid meaning in climbnorth's example. It just does something different from an actual 2D array.

As Narue said, a pointer can be used to simulate an array i.e. the language treats a pointer as equivalent to an array in some contexts.

An actual (as opposed to simulated) array has contiguous elements. So, if v is an array it's elements are placed one after the other in memory (i.e. v[i] is immediately after v[i-1] in memory). This notion carries over to 2D arrays, except that a 2D array is actually a contiguous array of 1D arrays.

The example given by climbnorth does not have that property. Instead, an array of pointers is dynamically allocated (and the address of that array of pointers is stored in a pointer to a pointer). Each pointer in that array is then assigned to a dynamically allocated array. Because of this, it simulates a 2D array (in the sense that elements can be accessed by the notation array[i][j]). However, it is no a 2D array, because the individual 1D arrays (accessed by the notation array[i]) are not contiguous.

In the end;

1) climbnorth, your example has some properties that make it act like a 2D array, but it is not a 2D array because it's elements are not contiguous. Your example is a method sometimes used in C to simulate a 2D array. It works in C++, but is rarely used in C++ because the C++ library supports a vector type. That's, incidentally, the reason Narue was amused by your post: you gave a response that would be expected from someone who (in her words) came "to C++ from a ten year bender in C".

2) DaWei, you were correct in pointing out that climbnorth's example is not an array, but mistaken in the statement that it's elements cannot be accessed using the "array[i][j]" notation.

3) Narue is probably chuckling at the way this thread has gone. :beard:


In C++, a std::vector<std::vector<int> > is an easier way to simulate a 2D array.

DaWei

See my apology in the C thread . I am currently slapping my wrist with a ruler, just like the nuns used to do, because I hate giving misinformation.

__________________
Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code.
Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

Narue

>Do you have something against me??
No.

>If you know a better way- please share so we can all learn something.
I know a better way, and I've already shared it. Use a vector to avoid the joy of managing memory for a dynamic array.

>If you know what is wrong with what I had posted
There's nothing wrong with your logic when certain assumptions are in place. Since this is the C++ forum I'll let slide the fact that you cast the return value of malloc, but I'll question why you're using malloc in the first place. Shall we continue?

>blah[i] = (char*)malloc(sizeof(char) * lengthofstring);
First, sizeof(char) is always 1. Also, unless lengthofstring includes room for the null character, your code has a bug.

>memset(blah[i], 0, sizeof(char) * lengthofstring);
>memcpy(blah[i], sourcestring, sizeof(char) * lengthofstring);
So you're copying the same string into every row of the array? That's somewhat odd, and I'm wondering why you use a memset/memcpy combo when strcpy does the same thing with less overhead (assuming lengthofstring is the same as strlen(sourcestring)+1). I'll assume you did it this way because you're not accounting for the null character when you allocate memory.

>please also elaborate on the difference between an array and memory allocated and referenced as an array
http://elf.torek.net/torek/c/index.html

__________________
Even if the voices aren't real, they have some pretty good ideas.

Seif

imo stick with vectors, as the overhead is negligible benefiting from lower developing and debuging time. Although double pointers are an alternative option to vectors, (and in all fairness I have also used a similar method before in applications that required dynamic arrays), the learning curve is a lot steeper imo, aswell as being very error prone.

climbnorth

Seif:
I agree, it is a nice luxury to use vectors, but like I had mentioned (and mention several times below) I was using this as an example. This example was posed as an alternate method that some people may like to understand but are still a little shakey on the detail of how this is implemented. I also feel this understanding is essential for people who are still uncertain how to use pointers- and this type of usage will help.

Narue:
I feel you have misinformed people in your previous set of comments. Also, please stop trying to "retaliate" because you think I'm wrong. I feel it is only confusing people since you keep trying to find flaws in my comments and examples. Below I comment on the damaging statemnts made regarding my examples:

There is nothing wrong with casting the return value of malloc, and in most cases- this is required. In most cases the compiler complains that it does not know what type of pointer this is. Since malloc returns a value of type (void*) which is a generic pointer (its size depends on the machine you are working with. ie: IA32 will have 32bit wide pointer. IA64 will be 64 bit wide) it should be cast when assigning to a pointer. C is part of the C++ language. C++ has often been described as a federation of languages which includes C. Anything you can do in C is ok for use with C++.

Here is an example in the spirit of my previous examples, this time using "dynamic binding":


sizeof(char) may always be 1, but this is an example of best practices. Also, when reading code, code examples, etc- you must assume that a label such as "lengthofstring" is intended to represent the length of the string.

I believe it a good habit to set your memory to null first before using it. Also, memcpy is more efficient then strcpy and is safer. This is because strcpy will blindly attempt to copy a string. If its too big- uh oh, you overwrote your buffer- and guess what, its not null-terminated. memcpy requires that you specify the size. Also, since memcpy is not directly tied to strings, you can use it to copy whatever- lets say, you cared about the rest of the world and wanted to copy multibyte characters, such as UTC-16 or UTC-32. Then, you are copying 2 bytes or even 4 bytes for each character. You would have to use a different function than strcpy to do this.

I carefully chose the name "lengthofstring" so there would be no confusion for what the value represented. Also, no one should assume this number to be negative or 0. Also, as I had previously mentioned: if there is a code example that makes it obvious what different labels represnt, do not assume that they contents are malformed or incorrect. This may impede your understanding of the example.

For those of you interested, this article is interesting- but unfortunately does not answer the question that I had raised. This article does discuss strings, arrays, dynamically allocated arrays, and more. This article as well as the one written by Dawei, are both good reads for people who are interested how arrays address their contents, or what the difference between an array and a pointer is (and more).