rudvil, знаешь.. есть такая замечательная хренька.. массив... где потомками a являтся a[2*i]-левый и a[2*i+1]-правый (нумерация с 1).. так оно сильно быстрее работает.
>>Хотя в глубине души что-то мне подсказывает что это не самый хороший вариант. Это самый хороший вариант.. поверь) а если не хочешь верить - сравни время работы такой имплементации и со структурками
А ты знаешь, для чего используются такие структуры данных как список, деревья? Ты будешь каждый раз перевыделять память как только у тебя массив закончится? Не говоря уже о понятности и читабельности кода. Попробовать можно только лишь с той целью, чтобы убедиться, что так делать не нужно. При написании интерпретаторов, компиляторов используются такая структура данных как map(хэш-таблица, ассоциативный массив), реализованная в виде бинарного дерева поиска, как правило использующая для балансировки алгоритм красно-черных деревьев. Надеюсь не сильно запутал, но структуры данных нужно знать. Это основа.
Нет не запутал) У меня тоже сомнения возникли насчет массива т.к. я не думаю что тот-же php или python используют массив)))
Нашел, что посоветовать, наверное, ты решил проблему разработчиков за последние лет 30, вот только нихрена не решил, не надо такой ереси советовать. Полностью согласен. RB деревья активно используются и не зря, они относительно баллансированы, да и этот вид структуры данных имеет важное свойство - он, сцуко сортированный Хотя, видя, какие тут советы дают (обычно складывается впечатление, что их дают не программеры, а какие-то трактористы), этот пост мне понравился - все основательно и правильно. Ты все правильно почувствовал, такие подходы, как совет с массивами - это глупа провокация, сделанная человеком, который, судя по всему не много смыслит в данной предметной области.
ну, уважаемые мастера, прошу - посмотрите сколько будет хотя бы СОЗДАВАТЬСЯ, ну например, простейшее дерево отрезков, реализованное с указателями на структурки, и сравните с массивом. а как я понял, вопрошающий строит дерево для синтаксического анализа и вычисления выражений, а хеш-таблицы, друзья мои, используются для определения ключевых слов языка, и потому к вышеозначенной проблеме не имеют никакого отношения... если уж использовать аналогию с машинами, то я вижу такой диалог: тс:как поменять колесо? мне кажется надо снять все - чтоб машина была в равновесии, поставить её на кирпичи, потом найти нормальное колесо и потом поставить все обратно я:нет, возьми запаску, сними одно - не упадёт машина на домкрате - и поставь запаску вы: нет, не надо так делать, а чтобы поменять масло, надо сделать то-то и то-то, это конечно сложно, но ты должен это знать. >>Нашел, что посоветовать, наверное, ты решил проблему разработчиков за последние лет 30 вообще-то её уже лет 30 назад решили и активно используют... а изменять размер массива - непонятно, почему сразу не выделить один достаточной длины.
Абсолютно верно, теперь я в сомнениях... что мне лучше подойдёт. Видимо нужно спросить у того кто хоть раз серьезно занимался интерпретатором и узнать что будет лучше работать т.к. тут похоже обе стороны правы)
rudvil, я ж предлагаю - посмотри и проверь) работать будут и способ со структурками, и способ с массивом. но способ со структурками а) жрёт больше памяти и б) медленней работает. И в этом нетрудно убедиться - напиши и так и так - всяко на своей шкуре лучше запоминается..
Вспоминается фраза: "Сержант Петренко дал предупредительный выстрел в воздух и не попал". Достаточная длина - это сколько? Не припоминаете проблему порога 640Кб оперативной памяти в ДОС? А проблему 2000-го года? А самую распространенную ошибку/уязвимость программных продуктов - переполнение буффера? Не бывает "достаточной" длины массива. Разве что, он будет выделяться динамически, а при переполнении будет делать expand. Далее, вы так и не сказали, что именно будет хранится в "тройках" массива в вашем чудо-решении. Если это будут просто слова, то приведите, пожалуйста хотя бы следующие алгоритмы, которые обычно предоставляются интерфейсом: 1. Обход дерева 2. Минимальный элемент 3. Максимальный элемент 4. Удаление элемента Если же это будут структуры, то нападки на нерациональность решения традиционными деревьями - это несколько даже некультурно
Есть статический метод класса: Code: LONG WINAPI CMyWindow::WndProc(HWND hwnd, UINT Message, WPARAM wparam, LPARAM lparam) { switch(Message) { case WM_DESTROY: PostQuitMessage(0); break; case WM_COMMAND: switch(wparam) { case IDR_BTN_LOAD_FILE: //вот тут надо открыть OpenFileDialog break; } break; default: return DefWindowProc(hwnd, Message, wparam, lparam); } return 0; } Но как открыть open file dialog и записать результат в переменную объекта класса?
юзай апишку GetOpenFileNameA из comdlg32.dll OPENFILENAMEA f; GetOpenFileNameA(&f); её дается указатель на структуру OPENFILENAMEA и в ней все параметра заданы. А в результат в этойже структуре сможешь найти имя файла который выбран (lpstrFile) и потом через strcpy скопирвовать себе для дальшейшего использования
ss88, а) если человек строит дерево для вычисления выражения, то по-любому ему надо для каждого выражения создавать новое дерево. теперь сравните затраты на перезаписывание или удаление своего дерева и (хотел сказать моего) нормального. б) достаточной длиной для выражения является количество элементов в выражении в) по поводу досовских килобайт: в.1) у нас не дос в.2) +8 байт на каждую структурку - два указателя - это типа нормально? г)по поводу >>приведите, пожалуйста хотя бы следующие алгоритмы, которые обычно предоставляются интерфейсом г.1) в случае данной проблемы я мало понимаю, зачем тут они нужны г.2) пожалуйста - для элемента массива с индексом i - предок i div 2, потомки: 2i и 2i+1 (кстати для такой замечательной функции, как предок, в вашу структуру надо добавить ещё и адрес предка. ещё+4*n байт...)
