Pomosht!!!!
11 отговора
530 прегледа
Pomosht!!!!
Predvaritelno se izvinjavam che vi zanimavam s moite moje bi glupavi problemi, no nali vse pak nikoj ne se e rodil nauchen, a i veche neznam kakvo da pravia - taka de glavata mi shte Eksploadira!!!
Ta pravia edno glupavo neshto s Visual C++, programkata triabva da otvaria textovi fajlove i da pravi malkite bukvi golemi. Az izbiram za bazov klas CEditView, no kogato stigna do praveneto na malkite bukvi golemi neshtata zatsikliat. Idejata mi e da kopiram sadarjanieto na fajla v CString obekt i ottam veche si ima gotovi funksii. Problemat e che iavno az ne pravia neshto kakto triabva, primerno kato kod minava prez kompilatora, no kogato go izpalnia ot prilojenieto garmi grozno s Grum i Triasak.
Molia vi pomognete!!!
Ako problemat vi se struva prekaleno elementaren izviniavajte no az vse pak nesum programist, predvaritelno blagodaria na vsichki!!!!!!!
Ta pravia edno glupavo neshto s Visual C++, programkata triabva da otvaria textovi fajlove i da pravi malkite bukvi golemi. Az izbiram za bazov klas CEditView, no kogato stigna do praveneto na malkite bukvi golemi neshtata zatsikliat. Idejata mi e da kopiram sadarjanieto na fajla v CString obekt i ottam veche si ima gotovi funksii. Problemat e che iavno az ne pravia neshto kakto triabva, primerno kato kod minava prez kompilatora, no kogato go izpalnia ot prilojenieto garmi grozno s Grum i Triasak.
Molia vi pomognete!!!
Ako problemat vi se struva prekaleno elementaren izviniavajte no az vse pak nesum programist, predvaritelno blagodaria na vsichki!!!!!!!
в отговор на neProgramist
#2
Re: Pomosht!!!!
Не съществуват елементарни проблеми. Просто има лошо дефинирани задачи. Тук едва ли някой ще може да ти помогне по въпроса, без да си постнал нито един байт от кода. Та никой не може да намери грешка, без да знае къде да я търси. Хайде ако си имаш и друга работа, първо я свърши нея, и като решиш да пишеш тук, пиши както трябва.
в отговор на neProgramist
#3
пробвай така
CFile f;
f.Open("fajl",CFile::modeRead);
char *b=new char[f.GetLength()+1];
f.Read(b,f.GetLength());
b[f.GetLength()]=0;
f.Close();
CString str=b;
str.MakeLower();
delete b;
f.Open("fajl",CFile::modeRead);
char *b=new char[f.GetLength()+1];
f.Read(b,f.GetLength());
b[f.GetLength()]=0;
f.Close();
CString str=b;
str.MakeLower();
delete b;
Re: пробвай така
То че е прост, прост е, ама така караш хората да свикват да си delete-ват масивите без скоби... та, утре ще вземат и масиви от класове така да си ги delete-ват и ще се чудят защо не става :)
Пък и като не слагаш скоби, е напълно в реда на нещата ако компилаторът реши да генерира код, който флашва биоса, форматира харда, запълва RAM-а с рожденната дата на Бил Гейтс по модул 256, и т.н., и никой не може да се оплаква, тъй като стандартът си казва, че това е "undefined behaviour".
Пък и като не слагаш скоби, е напълно в реда на нещата ако компилаторът реши да генерира код, който флашва биоса, форматира харда, запълва RAM-а с рожденната дата на Бил Гейтс по модул 256, и т.н., и никой не може да се оплаква, тъй като стандартът си казва, че това е "undefined behaviour".
:) брех да му се невиди!
кой ме е метнал? :)))
както и да е. мисля че явно писачите на компилатори са взели широкоразпространеното заблуждение предвид и са направили delete да търка размера на цялата заета от указателя памет. всъщност то като се замислиш заемането и освобождаването на памет от самата ос си го прави така. аз все пак седнах и си направих експеримент да проверя дали се освобождава заетата памет - оказа се че се освобождава, т.е. указател взет преди new delete и след това е с една и съща стойност. обаче като се замисля съм имал случай когато клас без деструктор прави проблем при delete без []. сега не успях да възпроизведа ситуацията - не ми направи проблем. ще го почопля пак:)
както и да е. мисля че явно писачите на компилатори са взели широкоразпространеното заблуждение предвид и са направили delete да търка размера на цялата заета от указателя памет. всъщност то като се замислиш заемането и освобождаването на памет от самата ос си го прави така. аз все пак седнах и си направих експеримент да проверя дали се освобождава заетата памет - оказа се че се освобождава, т.е. указател взет преди new delete и след това е с една и съща стойност. обаче като се замисля съм имал случай когато клас без деструктор прави проблем при delete без []. сега не успях да възпроизведа ситуацията - не ми направи проблем. ще го почопля пак:)
в отговор на Potencialen emigrant
#10
Re: :) брех да му се невиди!
не бе, с три флоата да му се невиди! ама може да бъркам нещо - сега не можах да го възпроизведа.
Re: :) „q„‚„u„‡ „t„p „}„… „ѓ„u „~„u„r„y„t„y!
w link-a koito postnah, kato se porowi malko chowek ima sywsem tochno obiasnenie zashto se polzwa delete i delete [] :)
[16.12] Can I drop the [] when deleteing array of some built-in type (char, int, etc)?
No!
Sometimes programmers think that the [] in the delete[] p only exists so the compiler will call the appropriate destructors for all elements in the array. Because of this reasoning, they assume that an array of some built-in type such as char or int can be deleted without the []. E.g., they assume the following is valid code:
void userCode(int n)
{
char* p = new char[n];
...
delete p; // ERROR! Should be delete[] p !
}
But the above code is wrong, and it can cause a disaster at runtime. In particular, the code that's called for delete p is operator delete(void*), but the code that's called for delete[] p is operator delete[](void*). The default behavior for the latter is to call the former, but users are allowed to replace the latter with a different behavior (in which case they would normally also replace the corresponding new code in operator new[](size_t)). If they replaced the delete[] code so it wasn't compatible with the delete code, and you called the wrong one (i.e., if you said delete p rather than delete[] p), you could end up with a disaster at runtime.
[16.12] Can I drop the [] when deleteing array of some built-in type (char, int, etc)?
No!
Sometimes programmers think that the [] in the delete[] p only exists so the compiler will call the appropriate destructors for all elements in the array. Because of this reasoning, they assume that an array of some built-in type such as char or int can be deleted without the []. E.g., they assume the following is valid code:
void userCode(int n)
{
char* p = new char[n];
...
delete p; // ERROR! Should be delete[] p !
}
But the above code is wrong, and it can cause a disaster at runtime. In particular, the code that's called for delete p is operator delete(void*), but the code that's called for delete[] p is operator delete[](void*). The default behavior for the latter is to call the former, but users are allowed to replace the latter with a different behavior (in which case they would normally also replace the corresponding new code in operator new[](size_t)). If they replaced the delete[] code so it wasn't compatible with the delete code, and you called the wrong one (i.e., if you said delete p rather than delete[] p), you could end up with a disaster at runtime.