nullptr problem.

[kevinkim]

1. I am watching the dynamic memory part of the tutorial. one of examples in the chapter includes keyword nullptr, and it occurs error.

here's my code :

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

int main(){
    int i,n,*p;
    cout<<"Type the number you would like to type : ";
    cin>>i;
    p=new(nothrow)int[i];
    if (p==nullptr)
    cout << "Error : memory could not be allocated";
    else{for(n=0;n<i;n++){cout<<"Enter number: ";
    cin>>p[n];}
    cout<< "You have entered : ";
    for(n=0;n<i;n++)cout<<p[n]<<", ";
    delete[]p;}
    cin.get();}

I erased keyword nullptr and wrote 0 instead, but it was as same.
So I eventually copied and pasted the whole example in the chapter to my compiler window, and it still says the same error.
"nullptr is not declared" "first use in this function"

2. One more question, I always write cin.get() to stay the console window so that I can see the result with enough time (otherwise it just disappears right after it appears.)
It works normally when I tested it without any other lines but only cin.get(); in the body of main function. but it doesn't work in the code above. I erased all the error parts to figure out what's is the problem, the code is :

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

int main(){
    int i,n,*p;
    cout<<"Type the number you would like to type : ";
    cin>>i;
    p=new(nothrow)int[i];
   for(n=0;n<i;n++){cout<<"Enter number: ";
    cin>>p[n];3
    cout<< "You have entered : ";
    for(n=0;n<i;n++)cout<<p[n]<<", ";
    delete[]p;}
    cin.get();}

the console window gets disappeared just after its execution. why is that?

[MiiNiPaa]

"nullptr is not declared" "first use in this function"

Turn on C++11. The ways to do so are different depending on compiler/IDE you are using

new(nothrow) absymal. You should not use non-trivial variants of new unless you know how they work and what are imlications of their use.

In particular, checking if memory was allocated is useless on modern OS with virtual memory addressing.

I always write cin.get() to stay the console window

.get() is not suited to keep window open.
Actually you should not manually try to keep wndow open: let it work like it should work. In particular, command line applications should be launched from command line. And any IDE worth using provides a way to keep window open even without explicit code tricks. Again, IDE dependand, I cannot help without knowing what IDE ara you using.

[kevinkim]

1 - I used to use visual studio but I changed it to DEV-C++ 4.9.9.2 for license problem. and I found it is much lighter.

2 - Actually I am just doing what the tutorial tells me to do. do you think I better to skip the part about new(nothrow) and new ?

3 - How can I turn on C++11? if my new IDE is not good enough to use and doesn't provide C++11 and function to keep console window open, please recommend me good one.

4 - checking if memory was allocated is useless on modern OS
better I skip dynamic memory chapter in the tutorial? cuz it seems that it is all for the chapter to subscribe how to check if so and how to handle the memory efficiently.

[Ericool]

simply replace nullptr by NULL until you configure the IDE to c++11 .
For new placement it is not useless , it is just that you are not there yet.
Simply remove#include<new> and (nothrow)

[MiiNiPaa]

DEV-C++ 4.9.9.2

It is ancient. Bloodshed DevC++ is superseded by Orwell Dev C++ (v. 5.11 right now).
http://sourceforge.net/projects/orwelldevcpp

Also you can use Code::Blocks (some tuning to replace bundled MinGW with proper is needed) or switch to Visual Studio 2015 Community: good and free IDE+compiler for Windows.

better I skip dynamic memory chapter in the tutorial?

Manual memory management is something that everyone strives to avoid, but it is still nessesary to know how it is done. Your tutorial seem to follow outdated approach to learning (C extension approach) so skipping this part might give you problems later. You can still read it, just throw away null pointers checks and replace nothrow new with normal new.

On the other hand there is a great chance that that tutorial does not teach inportant parts of modern C++. Like exceptions. I sugges to find another tutorial (either to replace current one or to complement it) which would be more in tune with current C++ standard.

[oelgazzar]

cin.get() takes '\n' character as an inpute so the console no longer prompts the user for input and so it closes ..
A solution to that:

cin.get();
cin.get();

[MiiNiPaa]

A solution to that:

Which will fail if there is a space at the end of input or returned in sequence character. Or something else happens.
I repeat: .get() is not suited to keep window open; you should not manually try to keep wndow open: let it work like it should work

Your IDE should keep the window for you. Outside of IDE programs should be run from command line. Keep your program behavior as it would be expected by user (which means let it behave the same way as absolute majority of programs created by competent programmers behave)

[kevinkim]

MiiNiPaa// Thank you for telling me now version of C++, I am currently in the school, and I will try that on my laptop in my home later : )


By the way, the tutorial I am doing is the one on this site. I REALLY don't want

to learn an obslete tutorial, I just thought the tutorial on this site is just most

standard and trustworthy because it is the most popular site for C++ users as I

know. would you please suggest me some new and simple lesson that I can

just play as a regular C++ user right after finishing that? without some

problem like being obslete knowledge or wrong etc.

oelgazzar, MiiNiPaa, ericool// Thanks for advice, both of you : ) I will just let the IDE do that when I find out how to with the new IDE

[MiiNiPaa]

Most online tutorials suffer from being no up to date. I would suggest book C++ Primer by Stanley Lippman and Barbara Moo (not C++ primer plus). Alternatively the Programming: Principles and Practice Using C++ by Stroustrup is the good book by language creator.

[dhayden]

In particular, checking if memory was allocated is useless on modern OS with virtual memory addressing.

Please explain. Memory is always limited, even when you can allocate the entire disk to virtual memory.

More importantly, a lot of code runs on machines with limited hardware. Think cell phones.

[LB]

@dhayden: what, other than exit the program/task with an error, could you want to do with the knowledge that memory allocation failed? That's a problem that only the user can fix.

[MiiNiPaa]

Please explain.

size_t GB = 1024 * 1024 * 1024;

char* c = new char[20 * GB];

I doubt anyone has 20 gygabytes of memory on their PC, but this line is not guaranteed to throw/return a null pointer. Often allocation succeeds, but accesses result in program termination (or creation of 20GB pagefile)

c[0] = 100; //Might work
c[1 * GB] = 50; //And this might lead to termination 

More importantly, a lot of code runs on machines with limited hardware.

Sure. Lets teach to code without dynamic allocation altogether (and without standard library as result) as embedded programming often cannot afford it (and sometimes it is impossible to dynamically allocate at all) and forbid exceptions because realtime applications do not use them.

Many tools in C++ are there for those who actually needs them/ They are not for general use and certainly not for beginners.

[kevinkim]

Thank you all !!

[dhayden]

LB and MiiNiPaa, I think we're actually of like minds regarding checking for out-of-memory conditions. I was confused because I interpretted MiiNiPaa's statement about "modern OS with virtual memory" to mean "as opposed to an older OS."

In my work, we check for low memory conditions at various safe places in the code. If memory is low then we shutdown and restart the process. This works when the process handles a stream of requests, some of which require a lot of dynamic memory. Since we're running on UNIX-based systems, once a process allocates a lot of memory it's pretty much guaranteed to hang on to it until terminated. So if a request pushed the amount of allocated memory above some threshold, we restart, which drops the memory footprint until the next really big request comes in.

The only way I know of to handle an out-of-memory condition is to allocate a block of memory when the program starts. Borland recommended this in the days of Turbo-C. If you run out of memory, then free the block and cleanly shut down the process. The idea is that the freed block will provide enough room for any dynamic allocation that is needed while shutting down. Of course the hard part is knowing how big that block should be.

what, other than exit the program/task with an error, could you want to do with the knowledge that memory allocation failed?

You could try to save the user's work.

c[0] = 100; //Might work
c[1 * GB] = 50; //And this might lead to termination  

I remember when IBM changed AIX to behave this way. malloc() basically always succeeded, but if the OS couldn't map the page to the process when you tried to access it, the process would just crash. The backlash was huge because it meant that there was no way to detect an out of memory condition. There were huge debated about what a non-null return from malloc() should mean and I thought they actually added something to the C standard to say that the memory had to be accessible.

In any case, for anyone who is still reading, I think the lesson is this: if you run out of memory, you are DOOMED. :)

[LB]

dhayden wrote:

Since we're running on UNIX-based systems, once a process allocates a lot of memory it's pretty much guaranteed to hang on to it until terminated. So if a request pushed the amount of allocated memory above some threshold, we restart, which drops the memory footprint until the next really big request comes in.

This sounds like memory leak to me - if the memory were not leaked then it would be re-used by your further allocations, would it not?

dhayden wrote:

You could try to save the user's work.

That is what destructors already do during stack unwinding, is it not? The default should be to save the user's work, and in order to not save the user's work you'd have to explicitly call a function.

In general though I'm not very experienced in this area because I've never had to write a program that needed to work in such a scenario.

[dhayden]

This sounds like memory leak to me - if the memory were not leaked then it would be re-used by your further allocations, would it not?

Yes it will be reused, but now you have a huge amount of unused free space on the heap. That space is taking up room in the swap partition. Ideally we'd like to give it back to the OS, but in UNIX systems, that's hard. For processes, it's easier to just have them shut down and restart with a smaller footprint.

It also true that some of our programs use this as a way to get around memory leaks, but obviously none of that code is mine :) :) :).