нельзя изменять ключ у существующего элемента(тем более у типа first есть модификатор const, поэтому без явного приведения типов твой код не скомпилируется), у тебя код не правильный с точки зрения логики и стандарта, VC++ тут не причём.

Сообщение отредактировал DEADHUNT - 31.1.2011, 16:22

Ну я ж не из головы его выдумал. Естественно неправильный. Попробую найти в исходниках где так делал (если найду - на тот момент я не использовал системы контроля версий)...

не нужно искать. Вполне возможно, что тебе просто запомнилось что-то не так (наверняка эмоции били через край ). Я же попробовал - компилятор не пропускает. Вряд ли у тебя была другая версия студии

Сообщение отредактировал Алексей1153 - 31.1.2011, 18:08

ничо вы тут холивары развели
а я поддержу мнение Rocky, не в смысле, что я за Qt (я просто с ним не работаю), а против MFC. из моего многолетнего опыта программирования (профессионально и для себя) я поняла, что те, кто писал MFC, видимо, никогда ею не пользовались сами. иначе они бы давно поправили то море багов и недочётов (да даже просто банальных глупостей!), которое там имелось, имеется и, видимо, так и будет существовать до конца мелкософта.
ну и как системный программист, конечно же, я предпочитаю линюкс. и я ещё раз в этом убедилась, написав тут недавно по работе драйвер под семёрку: мелкософт зарывается в индусский говнокод. и он повсюду. он не только в MFC, он даже в самих основах системы. там полно багов, нестыковок и нелогичных ни с какой точки зрения решений. в общем, удовольствия для программиста мало, а для юзера - нестабильность, лишние деньги и необходимость приобретать неоправданно мощное железо. единственное, за счёт чего держится мелкософт - за счёт распространённости и того, что под них написано много прикладного ПО, чисто исторически. но уже идёт процесс: сторонние фирмы начали присматриваться к линюксу и писать свои софтины под него. если мелкософт не перестанет писать говнокод - они окончательно забредут в тупик и лопнут. видимо, поэтому Гейтс отошёл от дел и перевёл свои сбережения в туристический бизнес.

Iron Bug,

ну это твоё личное право. Но вот любопытно, как связано написание драйверов и глюки MFC ?

Про производительность - это опять загибон. Как напишешь - так и будет тормозить. У меня не тормозит

Iron Bug, спасибо =)

Да, насчет std::map я погорячился... Ну а вот это как?

std::set<int> test_set;
test_set.insert(0);
test_set.insert(1);
test_set.insert(2);
test_set.insert(3);
test_set.insert(4);

std::set<int>::iterator itTest1 = test_set.find(2);
if (itTest1 != test_set.end()) *itTest1 = 7;

std::set<int>::iterator itTest2 = test_set.find(7);
if (itTest2 != test_set.end()) 
{
    //вот сюда мы не попадем
    qDebug() << *itTest2;
}

Сообщение отредактировал Rocky - 31.1.2011, 19:38

напиши комментарии - я не знаю, что должно произойти (этим классом не доводилось пользоваться)

Сообщение отредактировал Алексей1153 - 31.1.2011, 19:44

В смысле? К чему писать? Там же итак коммент есть....

std::set - ассоциативный массив (коллекция). В нем ни в коем случае нельзя изменять данные напрямую. К чему это приводит я там коммент оставил... По названиям ф-й думаю если работаешь с std::map должно быть понятно.

std::map я понимаю, что такое ключ - тоже.


почитал МСДН, вижу, что ты неправильно работаешь с классом:



may not - значит не нужно, но не запрещено.
must delete old values - обязательно должен удалить старое значение, а потом только insert elements with new values

И это, кстати, не ассоциативный массив, а просто набор уникальных элементов, отсортированных по предикату

Сообщение отредактировал Алексей1153 - 31.1.2011, 20:00

Так блин... Я знаю что это неправильно. Но почему nmake такое пропускает даже ворнинга не выдает???? Я знаю это сейчас, а по началу были очень большие грабли.


Извини не удержусь.... капитан очевидность )))))))))))))))))))))))))))))))) Я ж специально привел неправильный пример чтобы показать, что компилятор мелкомягких допускает такие вещи....
Это должно быть forbidden. gcc ведь ругается на такие конструкции.
И более того, чтобы понимать почему это должно быть forbidden нужно понимать как вообще устроен std::set


-----
UPD


Создал тестовый MFC/SDI проект. VS 2008. Открыл в ресурсах диалоговое окно "About - IDD_ABOUTBOX". Перетащил мышью на форму кнопку. У нее идентификатор IDC_BUTTON1. Файл test2.cpp:

void Ctest2App::OnAppAbout()
{
    CAboutDlg aboutDlg;
    CWnd *pWnd = aboutDlg.GetDlgItem(IDC_BUTTON1); //вот тут ошибка (пока не понятно почему)
    pWnd->SetWindowTextW(_T("bla-bla-bla"));          //и вот тут ошибка (потому что pWnd  == NULL)
    aboutDlg.DoModal();
}

Почему так??? Я ведь создал экземпляр класса. Я ожидаю, что получу доступ ко всем его открытым методам/членам. Так почему же ошибка???? Ах, вспомнил. Дело в том, что нужно помнить, что вызов CDialog::DoModal() инициирует вызов функции CDialog::OnInitDialog(), в котором и создаются элементы управления этого диалогового окна. Таким образом, чтобы инициализировать элементы управления диалогового окна, единственное где я могу это сделать - только из самого окна. Нужно писать функцию Init(), которую вызывать сразу после создания экземпляра класса, в нее передавать нужные параметры классу. Но в самой Init() еще нельзя выводить эти данные в элементы управления, потому что CDialog::OnInitDialog() еще не был вызван. Таким образом, даже если мне эти данные и нафиг не нужны потом, я должен их сохранять в мемберах. Вот одно это уже убивает. Если здесь есть обходной путь, расскажи пожалуйста... Я честно не знаю. =)

Сообщение отредактировал Rocky - 31.1.2011, 21:01