Методы работы с текстом.
CString sWord = "word";
и обращаюсь к буквам как
dc.TextOut(x, y, sWord[0]);
а в VC7 так не получается, как можно работать с отдельными буквами слова.
т.е. я не хочу разбивать слово на отдельные компоненты типа ... = {"w", "o", "r", "d"};
вот например такой код (точнее просто смысл кода):
CString letter = "w";
for(int i = 0; i<4; i++)
{
if(sWord == letter)
MessagwBox("The letter is enable", "Congratulations!!!", MB_OK);
break;
}
расскажите подробнее пожалуйста, у меня часто такие вопросы возникают, тольком поговорить нескем.
Конечно нет, но если я сначала хочу сформировать общую строку без вывода её в поток? Format(...)
Не понял вопроса.
Интересно было посмотреть как при программировании под Win для использования оконных процедур использовать потоки?
А что мешает?
Чем программирование под Win отличается от других?
ПыСы. Кстати, а void* кстати прикольная штучка если уметь ею пользоваться...
Хреновая это штука, как ни крути.
Без неё можно и нужно обходиться.
Если хочешь поспорить, приведи пример, когда без void* не обойтись.
Если хочешь поспорить, приведи пример, когда без void* не обойтись.
А можно вопрос??
Как лучше??:
void main(void)
{
.......
}
или
main()
{
.......
return 0;
}
А можно вопрос??
Как лучше??:
void main(void)
{
.......
}
или
main()
{
.......
return 0;
}
int main()
{
........
return 0;
}
А что мешает?
Чем программирование под Win отличается от других?
Я честно не знаю как с помощью потоков вывести что то в окно, в Edit, например. И вообще как тут можно использовать потоки? просвяти
Хреновая это штука, как ни крути.
Без неё можно и нужно обходиться.
Если хочешь поспорить, приведи пример, когда без void* не обойтись.
Наличие указателя определенного типа предполагает известную организацию памяти, на которую он ссылается. Но в некоторых случаях фрагмент программы " не должен знать" или просто не имеет достаточной информации о структуре данных в этой области. Тогда указатель должен пониматься как адрес памяти как таковой, с неопределенной организацией и неизвестной размерностью указуемой переменной. Такой указатель можно присваивать, передавать в качестве параметра и результата функции, но операции косвенного обращения и адресной арифметики с ним недопустимы.
Пример
Функция malloc возвращает адрес зарезервированной области динамической памяти в виде указателя void*. Это означает, что функцией выделяется память как таковая, безотносительно к размещаемым в ней переменным.
Пример
Функция malloc возвращает адрес зарезервированной области динамической памяти в виде указателя void*. Это означает, что функцией выделяется память как таковая, безотносительно к размещаемым в ней переменным.
вы меня извините, но здесь вроде С++ обсуждается? тогда пример с malloc некорректен. сам товарищ Страуструп рекомендовал использовать вместо malloc - new
вы меня извините, но здесь вроде С++ обсуждается? тогда пример с malloc некорректен. сам товарищ Страуструп рекомендовал использовать вместо malloc - new
Я бы не всегда доверял "товарищу Страуструпу" потому что new и delete некорректно работают с памятью и сейчас от них отказываются
Наличие указателя определенного типа предполагает известную организацию памяти, на которую он ссылается. Но в некоторых случаях фрагмент программы " не должен знать" или просто не имеет достаточной информации о структуре данных в этой области. Тогда указатель должен пониматься как адрес памяти как таковой, с неопределенной организацией и неизвестной размерностью указуемой переменной. Такой указатель можно присваивать, передавать в качестве параметра и результата функции, но операции косвенного обращения и адресной арифметики с ним недопустимы.
Извини, но здесь очевиден твой пробел в фундаментальных понятиях ООП. Ты знаком с таким понятиями, как "инкапсуляция", "интерфейс", ну и чуть сложнее - "принцип Парнаса" ?
Попробуй изучить и ты поймешь, что все написанное чуть выше легко и более корректно организуется без void*.
Пример
Функция malloc возвращает адрес зарезервированной области динамической памяти в виде указателя void*. Это означает, что функцией выделяется память как таковая, безотносительно к размещаемым в ней переменным.
malloc - это не С++, а С.
В С++ не бывает "памяти как таковой", т.к. в этом языке любая сущность имеет свой тип, такова концепция.
Я бы не всегда доверял "товарищу Страуструпу" потому что new и delete некорректно работают с памятью и сейчас от них отказываются
:D :D :D
Без слов...
Я думаю, дальнейший спор бесполезен.
Я бы не всегда доверял "товарищу Страуструпу" потому что [color=red]new и delete некорректно работают с памятью[/color] и сейчас от них отказываются
:o
с чьей?
песня "что то с памятью моей стало" это про new & delete?
Я бы не всегда доверял "товарищу Страуструпу" потому что new и delete некорректно работают с памятью и сейчас от них отказываются
А, конечно, поэтому в С# все определяется только при помощи new: массивы, екземпляры классов, типы и все прочее только через new.
Я бы хотел увидеть как ты перепишешь без new такой код C#:
Thread myThread = new Thread(new ThreadStart(myProc));
гы-гы.
Извини, но здесь очевиден твой пробел в фундаментальных понятиях ООП. Ты знаком с таким понятиями, как "инкапсуляция", "интерфейс", ну и чуть сложнее - "принцип Парнаса" ?
Попробуй изучить и ты поймешь, что все написанное чуть выше легко и более корректно организуется без void*.
я не утверждал, что без void* нельзя обойтись, просто привел пример его использования
:D :D :D
Без слов...
Я думаю, дальнейший спор бесполезен.
А ты попробуй в течение достаточно большого промежутка времени использовать new и delete. Посмотри, что будет с памятью, хотя утечек не будет
я не утверждал, что без void* нельзя обойтись, просто привел пример его использования
Я достаточно вкрадчиво объяснил, что пример бессмысленный в рамках концепции ООП.
А ты попробуй в течение достаточно большого промежутка времени использовать new и delete. Посмотри, что будет с памятью, хотя утечек не будет
А что будет?
Дефрагментация? Так это проблема менеджера памяти, а не new/delete, и в равной степени проявится при использовании malloc.
Может что-то ещё? Просвяти.
Я достаточно вкрадчиво объяснил, что пример бессмысленный в рамках концепции ООП.
А что будет?
Дефрагментация? Так это проблема менеджера памяти, а не new/delete, и в равной степени проявится при использовании malloc.
Может что-то ещё? Просвяти.
Одна и таже задача при использовании new/delete вылетает через промежуток времени, а при использовании malloc она работает сутками.
Это я не в защиту malloc, раньше всегда использовал new/delete, но при написании одной задачи столкнулся с такой проблемой
Security Note Ensure that format specification strings are not user-defined. For example, consider a program that prompts the user to enter his name and stores the input in a string variable called name. To print name, do not do this:
printf( name ); // Danger! If name contains "%s", program will crash
Instead, do this:
printf( "%s", name );
... на тему безопасности типов
Одна и таже задача при использовании new/delete вылетает через промежуток времени, а при использовании malloc она работает сутками.
Это я не в защиту malloc, раньше всегда использовал new/delete, но при написании одной задачи столкнулся с такой проблемой
А при чем тут new?
Проблема не в нем, а в его использовании. В этом я уверен.
Говоря грубо: не в инструменте дело, а в кривости рук.
Одна и таже задача при использовании new/delete вылетает через промежуток времени, а при использовании malloc она работает сутками.
Это я не в защиту malloc, раньше всегда использовал new/delete, но при написании одной задачи столкнулся с такой проблемой
Скорее всего данная ситуация в твоей программе вообще никак не связана с распределением памяти.
А при чем тут new?
Проблема не в нем, а в его использовании. В этом я уверен.
Говоря грубо: не в инструменте дело, а в кривости рук.
Интересно, как можно написать иначе?
char *str = new char[80];
...
delete[] str;
Интересно, как можно написать иначе?
char *str = new char[80];
...
delete[] str;
А ты уверен, что проблема именно в этом выделении памяти?
А ты уверен, что проблема вообще в выделении памяти, а не в работе с выделенной памятью?
Извини, но спор здесь совершенно бесполезный.
Создается впечатление, что для тебя new и malloc - что-то из области вуду. Нечто необъяснимое...
А ты уверен, что проблема именно в этом выделении памяти?
А ты уверен, что проблема вообще в выделении памяти, а не в работе с выделенной памятью?
Извини, но спор здесь совершенно бесполезный.
Создается впечатление, что для тебя new и malloc - что-то из области вуду. Нечто необъяснимое...
Проблема не выделении памяти, а в её освобождении. И вообще мы очень отошли от темы вопроса
Проблема не выделении памяти, а в её освобождении. И вообще мы очень отошли от темы вопроса
Не получаешь ли ты случайно сообщение "DAMAGE: ...." ?
Если ты не знаешь в чем проблема, то надо очень аккуратно высказываться о её причинах.
Поверь, выражение "потому что new и delete некорректно работают с памятью и сейчас от них отказываются" звучит КРАЙНЕ ГЛУПО. Ты даже не можешь представить на сколько глупо...
P.S. На всякий случай: никого не хотел обидеть.
Проблема не выделении памяти, а в её освобождении. И вообще мы очень отошли от темы вопроса
А что с освобождением то. Здесь нет ничего сверхестественного. Можна ее даже не высвобождать явным вызовом delete'a, а использовать сборщик мусора. Как например работает фреймворк в С#. Ничего не изменяется от метода освобождения памяти. Так как освобожденеи памяти - это, грубо говоря, указание того, что при следующем выделении память данный блок можно будет заново использовать. Другое дело выделение памяти. При выделении памяти уже могут быть разные реализации, но все мне изввестные просто находят найбольший свободный блок памяти и оттуда выделяют память. То-есть если у тебя идет выделение памяти небольшими, недолгоживущими кусками, то возможно память быстро дефрагментируется. Но new, насколько я знаю, ничем не отличается от malloc, в плане выделения памяти.
Если я че-то сморозил, пусть меня поправят...
А что с освобождением то. Здесь нет ничего сверхестественного. Можна ее даже не высвобождать явным вызовом delete'a, а использовать сборщик мусора. Как например работает фреймворк в С#. Ничего не изменяется от метода освобождения памяти. Так как освобожденеи памяти - это, грубо говоря, указание того, что при следующем выделении память данный блок можно будет заново использовать. Другое дело выделение памяти. При выделении памяти уже могут быть разные реализации, но все мне изввестные просто находят найбольший свободный блок памяти и оттуда выделяют память. То-есть если у тебя идет выделение памяти небольшими, недолгоживущими кусками, то возможно память быстро дефрагментируется. Но new, насколько я знаю, ничем не отличается от malloc, в плане выделения памяти.
Если я че-то сморозил, пусть меня поправят...
Что-то ты начинаешь в одну кучу все мешать...
Какой сборшик мусора в С++ ?
Что-то ты начинаешь в одну кучу все мешать...
Какой сборшик мусора в С++ ?
Я вот против сборщика мусора даже в Java. Замедляет работу программы в самые неожиданные и неподходящие моменты. Лучше уж самому все контролировать, или использовать готовые шаблоны кода.
Я вот против сборщика мусора даже в Java. Замедляет работу программы в самые неожиданные и неподходящие моменты. Лучше уж самому все контролировать, или использовать готовые шаблоны кода.
И вообще долой С++ и сборщики мусора. Даешь компилятор Java прямо в код x86!!!!?????
ИМХО:
программирование - есть создание программ
программы есть среда работы пользователя...
и если делать сборщик мусора который типа за тобой "подчищает", так это программа для программиста который будет пользователем программистом и т.д. парадокс какой-то, господа.
Народ, я по поводу сборщика мусора...
ИМХО:
программирование - есть создание программ
программы есть среда работы пользователя...
и если делать сборщик мусора который типа за тобой "подчищает", так это программа для программиста который будет пользователем программистом и т.д. парадокс какой-то, господа.
У тебя неверное представление о сборщике мусора.
Ознакомься:
http://rsdn.ru/article/dotnet/GCnet.xml
Я про выделение и освобождение памяти. Утечка памяти это другое
Перед тем как сесть программировать сначала разберитесь в архитектуре компьютера
Я про выделение и освобождение памяти. Утечка памяти это другое
мда.... это что юмор такой ? :))))))))))
мда.... это что юмор такой ? :))))))))))
Странно... полтора года у меня стоит 256м памяти. Прочитав пост про утечку памяти решил перепроверить. Оказалась все равно 256м. Вот Intel клевые материнские платы делает, проблема утечки памяти в них решена полностью и безповоротно. На правах рекламы.
Что-то ты начинаешь в одну кучу все мешать...
Какой сборшик мусора в С++ ?
А я не про С++, я про C#. В С++ нет сборщика мусора, я знаю, поэтому там и необходимо память освобождать явным вызовом delete'a. В отличие от С#. Я не могу понять, почему никто не использует в С++ такой сборщик, есть ведь для C# сборщик, прописаный в фреймворке, что мешает прописать аналогичный для С++? Ведь теоретически это возможно.
Странно... полтора года у меня стоит 256м памяти. Прочитав пост про утечку памяти решил перепроверить. Оказалась все равно 256м. Вот Intel клевые материнские платы делает, проблема утечки памяти в них решена полностью и безповоротно. На правах рекламы.
Поэтому, все кто выбрал АМД, со старта сакс, у них такого контроля нет, и через некоторое время им необходимо покупать новую память. :D
Поэтому, все кто выбрал АМД, со старта сакс, у них такого контроля нет, и через некоторое время им необходимо покупать новую память. :D
убей себя! у меня AMD64. и памяти как был гиг, так и остался... так шо - ффтопку интел :)
А я не про С++, я про C#. В С++ нет сборщика мусора, я знаю, поэтому там и необходимо память освобождать явным вызовом delete'a. В отличие от С#. Я не могу понять, почему никто не использует в С++ такой сборщик, есть ведь для C# сборщик, прописаный в фреймворке, что мешает прописать аналогичный для С++? Ведь теоретически это возможно.
Для начала определимся что делает сборщик мусора в C# и его особенности (подправьте меня если я не прав, т.к. я не специалист в C#):
1) выявляет "мертвые объекты", т.е. объекты на которые никто нессылается;
2) дефрагментирует память;
3) работает в параллельном потоке;
4) должен располагать информацией о всех используемых типах и их структурах, т.к. просматривает поля структур, которые являются указателями, и к тому же перемещает структуры в процессе дефрагментации.
Из этого видно, что сам язык С++ не предполагает наличие механизмов сборки мусора, но никто не мешает тебе использовать умные указатели и создать свой менеджер памяти, который в купе с умными указателями будет выполнять туже самую работу, что производит сборщик мусора в C#.
Но IMHO в полном аналоге сборщика мусора в С++ нет особой необходимости, кроме того это сильно усложнит и замедлит работу программы.
Достаточно ограничится умными указателями и иногда (например при частом создании удалении небольших объектов, что приводит обычно к сильной дефрагментации) написанием своего менеджера памяти.
Для начала определимся что делает сборщик мусора в C# и его особенности (подправьте меня если я не прав, т.к. я не специалист в C#):
1) выявляет "мертвые объекты", т.е. объекты на которые никто нессылается;
2) дефрагментирует память;
3) работает в параллельном потоке;
4) должен располагать информацией о всех используемых типах и их структурах, т.к. просматривает поля структур, которые являются указателями, и к тому же перемещает структуры в процессе дефрагментации.
Да нет, тут ты, прав. По-крайней мере, я себе это представляю практически так же.
Из этого видно, что сам язык С++ не предполагает наличие механизмов сборки мусора, но никто не мешает тебе использовать умные указатели и создать свой менеджер памяти, который в купе с умными указателями будет выполнять туже самую работу, что производит сборщик мусора в C#.
Но IMHO в полном аналоге сборщика мусора в С++ нет особой необходимости, кроме того это сильно усложнит и замедлит работу программы.
Достаточно ограничится умными указателями и иногда (например при частом создании удалении небольших объектов, что приводит обычно к сильной дефрагментации) написанием своего менеджера памяти.
Язык не предполагает? Тогда, насколько я понимаю, ни один язык не предполагает. А в случае с C#,VB,J# и иже с ними всю грязную работу делает фреймфорк. Почему же не возложить на него такую же задачу для С++ кода? По-моему программу это не усложнит, ведь не надо будет дописывать ни строчки лишнего кода, зато предотвратит утечки памяти, поскольку ненужная память будет освобождаться сборщиком.
Что касается скорости, я согласен, работа программы замедлится, но я не думаю что существенно. Приведу пример: примеры DirectX из сдкашки написаные на С#, работают где-то на 30% медленнее, чем аналогичные на С++. Но в случае этих примеров фреймворк занимается не только сборкой мусора.
убей себя! у меня AMD64. и памяти как был гиг, так и остался... так шо - ффтопку интел :)
Так ты утилиту от АМД юзаешь! Они выпустили специальную утилитку, которая показывает неправильный размер ОЗУ, причем загружается еще до биоса. Надо поставитиь патч от Интел :D :D :D
Язык не предполагает? Тогда, насколько я понимаю, ни один язык не предполагает. А в случае с C#,VB,J# и иже с ними всю грязную работу делает фреймфорк. Почему же не возложить на него такую же задачу для С++ кода?
Потому что у С++ нет фреймворка как у перечисленных тобой языков. Есть моды С++ (managed C++, CLI), у которых он есть, но у классического С++ такового нет.
По-моему программу это не усложнит, ведь не надо будет дописывать ни строчки лишнего кода, зато предотвратит утечки памяти, поскольку ненужная память будет освобождаться сборщиком.
Если тебе нужен сборщик только для этого, юзай смартпоинтеры, они получше будут.
Что касается скорости, я согласен, работа программы замедлится, но я не думаю что существенно.
Ты писал многопоточные приложения? Представь теперь себе работу по синхронизации использования ВСЕЙ памяти и всех объектов, расположенных в этой памяти, включая стек.
А это только половина дела.
Потому что у С++ нет фреймворка как у перечисленных тобой языков. Есть моды С++ (managed C++, CLI), у которых он есть, но у классического С++ такового нет.
У классического VB тоже не было фреймворка. Но добавили ведь...
Ты писал многопоточные приложения? Представь теперь себе работу по синхронизации использования ВСЕЙ памяти и всех объектов, расположенных в этой памяти, включая стек.
А это только половина дела.
Трудно представить задачу, для которой это понадобится. Но в этом случае, ИМХО, лучше использовать процессы а не потоки, то-есть переложить работу на плечи ОС. Может я и не прав, надо будет проверить.
У классического VB тоже не было фреймворка. Но добавили ведь...
VB must die. Помнится как то переполненный энтузиазма засел изучать С#. Однако через пару страничек увидев какую то конструкцию в нем а-ля VB послал нафиг C#, Билл Гейтса и заодно весь .NET Framework сразу всех версий.
Трудно представить задачу, для которой это понадобится. Но в этом случае, ИМХО, лучше использовать процессы а не потоки, то-есть переложить работу на плечи ОС. Может я и не прав, надо будет проверить.
...
Представь себе задачу написания проги в которой в реальном режиме времени надо отображать летящую на тебя ракету. И тут врубился garbage collector.... или пошел своп......
VB must die. Помнится как то переполненный энтузиазма засел изучать С#. Однако через пару страничек увидев какую то конструкцию в нем а-ля VB послал нафиг C#, Билл Гейтса и заодно весь .NET Framework сразу всех версий.
Угу, конечно. Пошли еще сразу и SQL сервак, и винду и все продукты мелкомягких. И пиши туеву хучу задач ручками в 10 раз медленней, чем на C#.
Представь себе задачу написания проги в которой в реальном режиме времени надо отображать летящую на тебя ракету. И тут врубился garbage collector.... или пошел своп......
Насколько я знаю, проги для управления полетамии ракет пишут не на С++ или C#, а на Ada. Так как этот язык является самым защищенным. К тому же вычисления проводятся на суперкомпах, у которых озу (дай бог мне столько в домашнем компе иметь). Короче им там не надо свопить. И мощности позволяют делать сбор мусора, если на то пошло. Короче это не является реальной задачей, о которой говорил Green.