new operator

This is a discussion on new operator within the C++ Programming forums, part of the General Programming Boards category; 1. How come that changing the size of the memory allocated new char(256); the size of the file wont change? ...

  1. #1
    Registered User
    Join Date
    Dec 2007
    Posts
    790

    new operator

    1. How come that changing the size of the memory allocated new char(256);
    the size of the file wont change?
    2. Why do we need to clear it with memset, when i write "world" to it and print it
    hello is no longer there. Looks like it clears itself.

    Code:
    #include <iostream>
    #include <windows.h>
    
    using namespace std;
    char *buffer = new char(256);
    
    int main()
    {
        strcpy(buffer, "hello");
        cout << buffer << "\n";
        strcpy(buffer, "world");
        cout << buffer << "\n";
        memset(buffer, 0, 256);
        cout << buffer << "\n";
        delete buffer;
        return 0;
    }
    Compiler MSVC++ 2013 with Code::Blocks.

  2. #2
    and the Hat of Guessing tabstop's Avatar
    Join Date
    Nov 2007
    Posts
    14,185
    1. Which file, your program file? Your program file doesn't contain the memory inside of it -- it contains the instructions to go get the memory when the program is run.

    2. strcpy will overwrite the first six characters of your buffer.

    3. That assumes that your buffer contains six characters in the first place, which I don't believe it does. Are you sure you don't mean "new char[256]" (and consequently "delete[] buffer") instead? Right now, you are getting one char, with the value 256.

  3. #3
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,554
    I would suggest you use std::string instead of char.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,302
    Quote Originally Posted by tabstop View Post
    3. That assumes that your buffer contains six characters in the first place, which I don't believe it does. Are you sure you don't mean "new char[256]" (and consequently "delete[] buffer") instead? Right now, you are getting one char, with the value 256.
    Yeah except that a char probably wont hold 256 (0x100), so it'll actually hold 0 (0x00) instead.

    std::string seconded.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  5. #5
    Registered User
    Join Date
    Dec 2007
    Posts
    790
    Thanks, i go with string instead then.
    Compiler MSVC++ 2013 with Code::Blocks.

  6. #6
    Registered User
    Join Date
    Dec 2007
    Posts
    790
    So is it ok to replace this:

    Code:
    char *buffer = new char[256];
    
    while(..)
    {
    memset(buffer, 0, length);
    
    operation on buffer;
    ...
    }
    delete[] buffer;

    with this:

    Code:
    string buffer ;
    
    while(..)
    {
    operation on buffer;
    ...
    ...
    }
    Or do i need to clear std::string too everytime?
    Compiler MSVC++ 2013 with Code::Blocks.

  7. #7
    The larch
    Join Date
    May 2006
    Posts
    3,573
    If you want an empty string for each iteration and the logic doesn't ensure that the string ends up being empty by the end of the loop, then naturally you should clear it. For that there is the clear() method.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  8. #8
    Registered User
    Join Date
    Dec 2007
    Posts
    790
    Thank you Anon!

    But if i should use a char* in a function i should go through all this transformation so i wonder if there is any good for using string?

    Code:
    string str; 
    char buf[256];
    strcpy(buf, str.c_str());
    Last edited by Ducky; 08-06-2009 at 11:41 AM.
    Compiler MSVC++ 2013 with Code::Blocks.

  9. #9
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> But if i should use a char* in a function

    What function do you need a char* for? If it is one of your functions, you should change it to use strings. If it is from another library, then are you sure it doesn't need const char* ?

  10. #10
    Registered User
    Join Date
    Dec 2007
    Posts
    790
    Its recv(), it takes a char*

    Is it worth it to use string with it?

    Code:
    int recv(
      __in   SOCKET s,
      __out  char *buf,
      __in   int len,
      __in   int flags
    );
    Compiler MSVC++ 2013 with Code::Blocks.

  11. #11
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,660
    Quote Originally Posted by Ducky
    Is it worth it to use string with it?
    You may want to consider using a std::vector<char> instead, at least until it is guaranteed that the pointer returned by &str[0], where str is a std::string, points to the first character of a contiguous array of characters. (There is such a guarantee if str was a std::vector<char> instead.)
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #12
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    If you use std::vector<char>, don't forget to call resize() on the vector before you call recv().
    bit∙hub [bit-huhb] n. A source and destination for information.

  13. #13
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> Its recv()

    Ok, that is one of the few instances where it makes sense to not use string. char buf[256] or std::vector<char> buf(256) would both be appropriate.

    What you use for the rest of your program depends on what you're doing, though. If you're manipulating the data as a string, I'd still convert to and from string and only use the character array when working with send and recv. If you're not doing much, then maybe it's ok to use the array the whole time.

    Note that for recv, you don't need to copy the string into the buffer using strcpy, because recv fills the buffer. And for send, you shouldn't need to use strcpy either, since c_str() should work. (Note: I don't remember if send takes a char* or const char*. If it takes only a char*, then you'd have to use strcpy or a const_cast.)

  14. #14
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    611
    Quote Originally Posted by laserlight View Post
    You may want to consider using a std::vector<char> instead, at least until it is guaranteed that the pointer returned by &str[0], where str is a std::string, points to the first character of a contiguous array of characters.
    Didn't we go through this last time?

    Quote Originally Posted by http://herbsutter.wordpress.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/
    However, current ISO C++ does require &str[0] to cough up a pointer to contiguous string data (but not necessarily null-terminated!)
    &(str[0]) (21.3.1.4) == &(str.data()[0]) (21.3.6.3)== &(ptr to array[0]) == ptr to array

  15. #15
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,660
    Quote Originally Posted by adeyblue
    Didn't we go through this last time?
    Yes, we did. I cannot recall the exact outcome of that conversation, but I did not go away convinced that Sutter is correct on this point. I believe it had something to do with ambiguity in the text of C++03. What I am convinced by is that there is no point debating as this will be fixed in the next version of the C++ standard, and for now one should play safe rather than sorry.

    EDIT:
    Ah yes, I remember now. The problem is that data() returns a const charT*, hence defining the non-const version of operator[] in terms of data() is illogical, but it is precisely that version of operator[] that is in question here.
    Last edited by laserlight; 08-06-2009 at 12:58 PM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Smart pointer class
    By Elysia in forum C++ Programming
    Replies: 63
    Last Post: 11-03-2007, 07:05 AM
  2. Screwy Linker Error - VC2005
    By Tonto in forum C++ Programming
    Replies: 5
    Last Post: 06-19-2007, 02:39 PM
  3. Operator Overloading (Bug, or error in code?)
    By QuietWhistler in forum C++ Programming
    Replies: 2
    Last Post: 01-25-2006, 07:38 AM
  4. C++ Operator Overloading help
    By Bartosz in forum C++ Programming
    Replies: 2
    Last Post: 08-17-2005, 12:55 PM
  5. operator overloading and dynamic memory program
    By jlmac2001 in forum C++ Programming
    Replies: 3
    Last Post: 04-06-2003, 11:51 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21