DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 37

Thread: multiple choice questions in string and array

  1. #16
    Join Date
    Oct 2005
    Location
    Maady
    Posts
    1,819
    No I haven't tested it, I just suggested to be an error like that; and your example doesn't give an error. I'm just asking logically why we have such option ?
    if the standards transform the argument array to a pointer so why we have this form, I mean it doesn't have a sense to put Arr[SomeInt] in the arguments of the function so why it exists ? my previous answers was just based on what I see logically true, maybe I'm wrong in something, but I give my reasons ...
    and here is what I think about this :
    for example if I pass A[50] to a function that have p[100] as argument, the compiler should accept this -if we talk about an array of 100 elemnts- but maybe [not sure] the solution of this for the compiler is to make the p as pointer to A .. and this affected the other problem when it's less than the specified size. or is there any other needs to declare a function like that ??
    Programmer&Cracker CS
    MyBlog:Blog.Amahdy.com
    MyWebsite:www.Amahdy.com

  2. #17
    Join Date
    Dec 2003
    Posts
    3,366
    I will double check but I am fairly sure that if you make

    foo(int x[100]) and send it
    int d[150];
    foo(d);

    you get
    error: cannot convert int[150] to int[100]

  3. #18
    Join Date
    Mar 2007
    Location
    Bangalore, India
    Posts
    247
    Please let me know which compiler you use. I used GCC version 3.4.5 (Mingw). It doesn't send any errors. And if you do sizeof(x) in the function foo, you will get the size of a pointer.

  4. #19
    Join Date
    Dec 2003
    Posts
    3,366
    It no longer errors on this, so you were right. Im using net 2005. The last time I tried this was a very long time ago, and it would give that error.

  5. #20
    Join Date
    Mar 2007
    Location
    Bangalore, India
    Posts
    247
    So that must have been a pre-standards compiler. I don't know when exactly the standards came out, and am too lazy to look it up, but it was some time in 1995 if I am right.

  6. #21
    Join Date
    Nov 2003
    Posts
    4,118
    It's not just the "new C++ standard". It has been like since the early days of C. Arrays decay into pointers when they are used as function arguments. When using arrays, you should always include a second parameter that indicates the size of the array.
    Danny Kalev

  7. #22
    Join Date
    Mar 2007
    Location
    Bangalore, India
    Posts
    247
    In C, yes, but I have reasons to believe (Borland's Turbo C++ - use the same code, will work for C, won't for C++) that that behaviour was not enforced on earlier C++ compilers. So it was part of the C standard earlier itself.

  8. #23
    Join Date
    Nov 2003
    Posts
    4,118
    [QUOTE=jonnin]I will double check but I am fairly sure that if you make

    foo(int x[100]) and send it
    int d[150];
    foo(d);

    you get
    error: cannot convert int[150] to int[100][/QUOTE
    That's right, but it works only when the definition of d is in scope, and is visible to the compiler. If d is declared in a different scope and decays into int*, all hope is lost. A similar problem will arise if d is dynamically allocated.
    Last edited by Danny; 11-20-2007 at 11:00 AM.
    Danny Kalev

  9. #24
    Join Date
    Dec 2003
    Posts
    3,366
    Ah that explains it. I always use (int *x) because of various compiler issues in the past.

  10. #25
    Join Date
    Mar 2007
    Location
    Bangalore, India
    Posts
    247
    Quote Originally Posted by Danny
    That's right, but it works only when the definition of d is in scope, and is visible to the compiler. If d is declared in a different scope and decays into int*, all hope is lost. A similar problem will arise if d is dynamically allocated.
    I am afraid that it is not the case. A definition of a function taking an array will always decay into one taking a pointer. If that was true, the following code wouldn't compile:
    Code:
    #include <iostream>
    
    using namespace std;
    
    int main()
    {
      void foo(int x[100]);
      int d[150];
      foo(d);
      cout<<d[110]<<endl;
      return 0;
    }
    
    void foo(int x[100])
    {
      x[110] = 123;
    }
    But it compiles and runs correctly. When you send an array, they always go as a pointer. If you still don't believe, try the following:

    Code:
    #include <iostream>
    
    using namespace std;
    
    int main()
    {
      void foo(int x[100]);
      int d[150];
      foo(d);
      cout<<d[110]<<endl;
      return 0;
    }
    
    void foo(int x[100])
    {
      ++x;
      x[109] = 123;
    
    }
    Note the ++x and assignment to x[109] in foo(). Even this will compile and run correctly, proving that x is treated EXACTLY like a pointer, not even a const pointer.

    Again, I used g++ version 3.4.5 (mingw). Old compilers might not behave like this. In fact, will not. I remember using some old gcc and it threw me a warning because I did not give the size of the array in a function definition that took an array. But it is no longer the case. It complies without complain for new compilers.

  11. #26
    Join Date
    Oct 2005
    Location
    Maady
    Posts
    1,819
    Ok again the question so why do you think we have such formal expression ?
    why it exists ?
    as I said before the compiler SHOULD accept passing a[50] to an argument as p[100] , is it for this only case that the declaration of an array in the arguments is transformed to pointer or why we need it in the language ? and is there an advantage for this transformation or it's just like other bugs that haven't been solved yet ?
    Programmer&Cracker CS
    MyBlog:Blog.Amahdy.com
    MyWebsite:www.Amahdy.com

  12. #27
    Join Date
    Oct 2005
    Location
    Maady
    Posts
    1,819
    Sorry I don't mean bug exactly, I mean something that we can't solve so we put it like that -just for now- ..

  13. #28
    Join Date
    Nov 2003
    Posts
    4,118
    Quote Originally Posted by jonnin
    Im sure you know this but you can resize a dynamic array, if you go back to C, using realloc. This is probably what the STL vectors do deep inside (or the assembly version to do the same). This is terribly slow, I never found a use for it because it is such a brute force operation, and I don't like that vectors do it behind your back (you have to keep an eye on them and manage them to prevent this penalty).

    And yes, I was giving the wrong answers intentionally just to make a point.
    STL vectors are smarter than that. They grow exponentially, so it's not the case that every new element will cause a reallocation. In some cases, the vector can also be given clues in advance, and thus preallocate sufficient storage in advance.
    Danny Kalev

  14. #29
    Join Date
    Dec 2003
    Posts
    3,366
    right, I always try to pre-allocate them and force them to behave more like arrays than not for the deep code. Its the act of resizing (however it is done) that I try to avoid at all costs.

  15. #30
    Join Date
    Mar 2007
    Location
    Bangalore, India
    Posts
    247
    Quote Originally Posted by Amahdy
    Ok again the question so why do you think we have such formal expression ?
    why it exists ?
    as I said before the compiler SHOULD accept passing a[50] to an argument as p[100] , is it for this only case that the declaration of an array in the arguments is transformed to pointer or why we need it in the language ? and is there an advantage for this transformation or it's just like other bugs that haven't been solved yet ?
    The thing is, if you want to copy an array by value, it will take time proportional to O(n), and it may be complicated. (Assume that what we pass is an array or arrays! But if we make it a pointer, the problem is more or less solved (of course we have our 'problem' here). An array will become a pointer, an array of arrays will become a pointer to an array, an array of array of array will become a pointer to an array of arrays and so on.

    Maybe it is the easy way out. I seriously don't know why they did it instead of not allowing such a construct, but probably they wanted to not compromise readability. The point is not that code written like this is always readable, but that we CAN make it more readable. And the more you learn C++, even more complicated code becomes readable (and you'll tend to use them).

Similar Threads

  1. string array in c++
    By emeric in forum C++
    Replies: 11
    Last Post: 07-16-2007, 09:36 PM
  2. verify local admin
    By Patrick Comeau in forum VB Classic
    Replies: 6
    Last Post: 03-22-2001, 11:50 PM
  3. SafeArrayCopy SLOWER than iterating string array!
    By Mark Alexander Bertenshaw in forum VB Classic
    Replies: 10
    Last Post: 06-16-2000, 05:34 AM
  4. SafeArrayCopy SLOWER than iterating string array!
    By Mark Alexander Bertenshaw in forum VB Classic
    Replies: 0
    Last Post: 06-12-2000, 08:15 PM
  5. Trying to print a PDF File from VB
    By Kunal Sharma in forum VB Classic
    Replies: 2
    Last Post: 04-25-2000, 03:45 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center