| детерминизм в выделении памяти | |
 | От: | D_Tony | |
| Дата: | 27.05.08 10:44 |
| Итак, уважаемые товарищи программисты. Созрел один простенький вопросец. Есть куски кода, в которых происходит выделение памяти под объекты, которые потом хряняться в std::map<> списках. Так вот т.к. хранение происходит по указателю на вновь созданный объект — то при разных запусках (в том числе и для дебагга) получается что некоторые куски кода при обращении к этим map структурам получают не всегда один и тот же объект их них. именно по тому что изменился указатель на этот объект и теперь он ну, к примеру не 2 в списке а аж 10. В итоге программа может упасть. Интересует реально рабочий выход из этого положения. Прошу учесть что указатели на сами объекты в корне поменять не можем. Это оооочень сверх солидная переработка кода, а в некоторых местах и просто по лицензии мы ничего изменить не можем((( Нужен какой-то общий наверное механизм выделения памяти, что ли. Чтоб гарантировать что каждый раз созданные объекты попадали в std::map в одинаковой последовательности... Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! |
| Re: детерминизм в выделении памяти | |
 | От: | Аноним 647 | |
| Дата: | 27.05.08 10:59 |
| Здравствуйте, D_Tony, Вы писали: D_T>Итак, уважаемые товарищи программисты. Созрел один простенький вопросец. D_T>Есть куски кода, в которых происходит выделение памяти под объекты, которые потом хряняться в std::map<> списках. D_T>Так вот т.к. хранение происходит по указателю на вновь созданный объект — то при разных запусках (в том числе и для дебагга) D_T>получается что некоторые куски кода при обращении к этим map структурам получают не всегда один и тот же объект их них. D_T>именно по тому что изменился указатель на этот объект и теперь он ну, к примеру не 2 в списке а аж 10. D_T>В итоге программа может упасть. D_T>Интересует реально рабочий выход из этого положения. Прошу учесть что указатели на сами объекты в корне поменять не можем. D_T>Это оооочень сверх солидная переработка кода, а в некоторых местах и просто по лицензии мы ничего изменить не можем((( D_T>Нужен какой-то общий наверное механизм выделения памяти, что ли. Чтоб гарантировать что каждый раз созданные объекты D_T>попадали в std::map в одинаковой последовательности... D_T>Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! Я правильно понял, что вы храните указатели на объекты, хранящиеся в std::map? Если да, то это бред полный, проектировщику поотрывать руки и другие части тела. Решение навскидку — хранить указатели на указатели в таблице и обращаться к ним. Адреса указателей в таблице постоянные, сами указатели естественно меняются в зависимости от содержимого map-а. |
| Re: детерминизм в выделении памяти | |
 | От: | Erop | |
| Дата: | 27.05.08 11:35 |
| Здравствуйте, D_Tony, Вы писали: D_T>Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! переопределите operator new/delete у того, указатели на что вы храниет в мапе. И, например, преаллокируйте большой пребольшой буффер, откуда по одному и кусайте... Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском |
| Re[2]: детерминизм в выделении памяти | |
| От: | D_Tony | |
| Дата: | 27.05.08 11:37 |
| Здравствуйте, Аноним, Вы писали: А>Здравствуйте, D_Tony, Вы писали: ..... А>Я правильно понял, что вы храните указатели на объекты, хранящиеся в std::map? Если да, то это бред полный, проектировщику поотрывать руки и другие части тела. Решение навскидку — хранить указатели на указатели в таблице и обращаться к ним. Адреса указателей в таблице постоянные, сами указатели естественно меняются в зависимости от содержимого map-а. Ну что имеем то и имеем, так что давайте договоримся что ничего даже виртуально вырывать не будем.. Ибо не до того.... Указатели на указатели, хм... псевдокод: где-то динамически определяется? что вызывать надо по порядку: A * a = new A(); еще где-то: B * b = new B(); и еще где-то: C * c = new C(); сохраняем: std::map<insert(Val_type(stringA, &a))>; std::map<insert(Val_type(stringB, &b))>; std::map<insert(Val_type(stringC, &c))>; И этот код работает при первом запуске. все ОК. все по порядку... а теперь перезагрузка... что то случилось и и и ..... вызовы конструкторов изменились C * c = new C(); A * a = new A(); B * b = new B(); а засовываю я все так же — по мере создания объектов!! std::map<insert(Val_type(stringC, &с))>; std::map<insert(Val_type(stringA, &a))>; std::map<insert(Val_type(stringB, &b))>; Так в чем выигрыш??? К тому же не хотелось бы еще и стуктуры раздувать.. еще мапы, еще указатели.... P.S. когда я про динамику создания говорю — считайте, что есть где-то код, который говорит, что надо ему объекты такие то и такие-то. создай их.. но он не говорит что их надо вот по такому порядку создавать. но вот хранить я должен их как то детерминировано!! Ибо иначе потом проблем не оберешься = Вот эту проблему и я прошу решить))) |
| Re[2]: детерминизм в выделении памяти | |
 | От: | Сергей Мухин | |
| Дата: | 27.05.08 11:38 | ||
| Оценка: |  | ||
| Здравствуйте, Erop, Вы писали: D_T>>Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! E>переопределите operator new/delete у того, указатели на что вы храниет в мапе. И, например, преаллокируйте большой пребольшой буффер, откуда по одному и кусайте... а когда он закончится — застрелитесь  --- С уважением, Сергей Мухин |
| Re: детерминизм в выделении памяти | |
 | От: | Кодт модератор | |
| Дата: | 27.05.08 11:38 | ||
| Оценка: | 2 (2) +2 | ||
| Здравствуйте, D_Tony, Вы писали: D_T>Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! Рефакторинг по телефону — это новое слово в полёте человеческой мысли. К сожалению, из твоего описания проблемы ещё нельзя понять, как её решать: какие именно куски кода могут меняться, а какие запрещено трогать. Поэтому придётся дать теоретические выкладки. 1. Оторвать руки тому коду, который жёстко привязан к порядку следования элементов в контейнере. — дополнительные естественно-упорядоченные контейнеры (там, где нужно локально поработать с естественным порядком) — двойная буферизация (там, где изменение контейнера происходит реентерабельно) 2. Определить отношение порядка над объектами, а не над указателями; это отношение должно быть стабильно (не меняться от запуска к запуску), например, каждому объекту присваивается глобально-уникальный номер — GUID или просто последовательный счётчик. И указать это отношение для map'ов, хранящих объекты по указателям. 3. Вместо указателей использовать хэндлы. Обеспечить корреляцию между порядком вызова и значением хэндла. 4. Завести аллокатор для этих объектов, обеспечивающий корреляцию между порядком вызова и значением указателя; перегрузить для объектов операторы new и delete. Но я думаю, что любые фокусы с указателями напрочь разбиваются о тот факт, что каждый запуск программы может происходить по разным путям, и поэтому нумерация объектов от запуска к запуску будет сбиваться. Будет продуктивно, если ты расскажешь, в каких конкретно местах у тебя возникают проблемы; покажешь фрагменты кода; уточнишь, что из них можно переделать, а что нет. ... << RSDN@Home 1.2.0 alpha rev. 655>>  Перекуём баги на фичи! |
| Re[2]: детерминизм в выделении памяти | |
| От: | D_Tony | |
| Дата: | 27.05.08 11:41 | ||
| Оценка: | -2 | ||
| Здравствуйте, Erop, Вы писали: E>Здравствуйте, D_Tony, Вы писали: D_T>>Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! E>переопределите operator new/delete у того, указатели на что вы храниет в мапе. И, например, преаллокируйте большой пребольшой буффер, откуда по одному и кусайте... Простите, что спрашиваю, но почему "например"?? Вы еще варианты решения проблемы знаете?? Я ведь прошу "реально проверенные" примеры.. Честно — нет времени пробовать то или это.... Есть 2 суток чтоб решить эту проблему... А дома еще дети, жена, не хотелось бы не вылезать с работы, чтоб потом "Скова дорогой, Скова!!!!" |
| Re[3]: детерминизм в выделении памяти | |
| От: | Сергей Мухин | |
| Дата: | 27.05.08 11:44 | ||
| Оценка: | +2 | ||
| Здравствуйте, D_Tony, Вы писали: D_T>Здравствуйте, Erop, Вы писали: E>>Здравствуйте, D_Tony, Вы писали: D_T>>>Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! E>>переопределите operator new/delete у того, указатели на что вы храниет в мапе. И, например, преаллокируйте большой пребольшой буффер, откуда по одному и кусайте... D_T>Простите, что спрашиваю, но почему "например"?? Вы еще варианты решения проблемы знаете?? D_T>Я ведь прошу "реально проверенные" примеры.. Честно — нет времени пробовать то или это.... т.к. Вы, вместо спасибо Erop'у за участие, предлагаете ему проверить и сидеть на работе вместо Вас? Отлично! D_T>Есть 2 суток чтоб решить эту проблему... А дома еще дети, жена, не хотелось бы не вылезать с работы, чтоб D_T>потом "Скова дорогой, Скова!!!!" --- С уважением, Сергей Мухин |
| Re[4]: детерминизм в выделении памяти | |
| От: | D_Tony | |
| Дата: | 27.05.08 11:51 |
| Здравствуйте, Сергей Мухин, Вы писали: СМ>Здравствуйте, D_Tony, Вы писали: D_T>>Здравствуйте, Erop, Вы писали: E>>>Здравствуйте, D_Tony, Вы писали: D_T>>>>Теоретические выкладк плиз не предлагать — тока рабочие варианты!!!! проверенные вами же!! E>>>переопределите operator new/delete у того, указатели на что вы храниет в мапе. И, например, преаллокируйте большой пребольшой буффер, откуда по одному и кусайте... D_T>>Простите, что спрашиваю, но почему "например"?? Вы еще варианты решения проблемы знаете?? D_T>>Я ведь прошу "реально проверенные" примеры.. Честно — нет времени пробовать то или это.... СМ>т.к. Вы, вместо спасибо Erop'у за участие, предлагаете ему проверить и сидеть на работе вместо Вас? Отлично! D_T>>Есть 2 суток чтоб решить эту проблему... А дома еще дети, жена, не хотелось бы не вылезать с работы, чтоб D_T>>потом "Скова дорогой, Скова!!!!" Господи, можно подумать у Вас никогда не было ситуаций, когда голова не варит толком, а по задницу вас "толкают" И в итоге даже по-русски не всегда понятно говоришь... Я своей фразой НЕ хотел кого-либо обидеть, я лишь заметил, что раз человек "например" слово использовал, то "наверное" он что-то еще имел в виду. а раз так — то почему он выдал этот вариант? и если он в курсе некоторых вариантов — то это теоретические или практические варанты???? Я тут много полезного узнал из форума, но это полезное именно было потому что практически было подкреплено примерами и пояснениями.. Теорий в любой книге хватает.. тока вот область применения очень хромает.... А по поводу самого совета — вы и сами его больное место указали... |
| Re[3]: детерминизм в выделении памяти | |
 | От: | Bell | |
| Дата: | 27.05.08 11:57 | ||
| Оценка: | 1 (1) +1 | ||
| Здравствуйте, D_Tony, Вы писали: D_T>Здравствуйте, Аноним, Вы писали: А>>Здравствуйте, D_Tony, Вы писали: D_T>..... А>>Я правильно понял, что вы храните указатели на объекты, хранящиеся в std::map? Если да, то это бред полный, проектировщику поотрывать руки и другие части тела. Решение навскидку — хранить указатели на указатели в таблице и обращаться к ним. Адреса указателей в таблице постоянные, сами D_T>указатели естественно меняются в зависимости от содержимого map-а. D_T>Ну что имеем то и имеем, так что давайте договоримся что ничего даже виртуально вырывать не будем.. Ибо не до того.... D_T>Указатели на указатели, хм... D_T>псевдокод: D_T>где-то динамически определяется? что вызывать надо по порядку: D_T>A * a = new A(); D_T>еще где-то: D_T>B * b = new B(); D_T>и еще где-то: D_T>C * c = new C(); D_T>сохраняем: D_T>std::map<insert(Val_type(stringA, &a))>; D_T>std::map<insert(Val_type(stringB, &b))>; D_T>std::map<insert(Val_type(stringC, &c))>; Это что за синтаксис?! Вообще пока мало что понятно. Если нужна реальная помощь — подготовь минимальный пример, из которого было бы видно — что есть, что должно получаться, что получается на самом деле. ЗЫ В качестве ключа std::map не используется ли случайно const char* ? Любите книгу — источник знаний (с) М.Горький |
| Re[2]: детерминизм в выделении памяти | |
| От: | D_Tony | |
| Дата: | 27.05.08 12:05 |
| Здравствуйте, Кодт, Вы писали: К>Здравствуйте, D_Tony, Вы писали: К>Рефакторинг по телефону — это новое слово в полёте человеческой мысли. К>К сожалению, из твоего описания проблемы ещё нельзя понять, как её решать: какие именно куски кода могут меняться, а какие запрещено трогать. К>Поэтому придётся дать теоретические выкладки. К>1. Оторвать руки тому коду, который жёстко привязан к порядку следования элементов в контейнере. К>- дополнительные естественно-упорядоченные контейнеры (там, где нужно локально поработать с естественным порядком) К>- двойная буферизация (там, где изменение контейнера происходит реентерабельно) К>2. Определить отношение порядка над объектами, а не над указателями; это отношение должно быть стабильно (не меняться от запуска к запуску), например, каждому объекту присваивается глобально-уникальный номер — GUID или просто последовательный счётчик. К>И указать это отношение для map'ов, хранящих объекты по указателям. К>3. Вместо указателей использовать хэндлы. Обеспечить корреляцию между порядком вызова и значением хэндла. К>4. Завести аллокатор для этих объектов, обеспечивающий корреляцию между порядком вызова и значением указателя; перегрузить для объектов операторы new и delete. К>Но я думаю, что любые фокусы с указателями напрочь разбиваются о тот факт, что каждый запуск программы может происходить по разным путям, и поэтому нумерация объектов от запуска к запуску будет сбиваться. К> К>Будет продуктивно, если ты расскажешь, в каких конкретно местах у тебя возникают проблемы; покажешь фрагменты кода; уточнишь, что из них можно переделать, а что нет. Ну новое-это просто позабытое старое))) Попробуем по порядку.. Начнем с конца))) Примеры — это туговато... ибо есть некая концепция "ошибки" по идее.. А ее локальные места толком не укажешь, если тока Вы не согласитесь пол листинга по емейлу получить и почитать его и поужасаться... Я уже писал — в очень сжатой форме — есть "фабрика", которая генерит объекты, которые потом расходятся по коду. и на основе уже их создаются другие.. Так вот в тот момент когда перво-объекты оказались созданы и помещаются для хранения в мапы нужно и задать какие-то правила помещения.. ибо это основная причина последующих "гос-переворотов" в поведении программы.. Поведением фабрики мы управлять не можем совсем... может тока милостиво получать объекты.... поэтому я думаю тут 4 способ пригодится-хотя явно уточнение нужно.. 2 способ явно рушится от факта, что из фабрики объекты недетермнированно выходят.. 3 способ... Простите, а КАК?? и как настчет того факта что объекты генеряться тысячами и удаляются и ищутся... 1 способ — походу самая большая трабла — в этой фабрике... но ее мы "не видим и не слышим" . она святая))) |
| Re[5]: Дык телепаты-то в отпуске... :) | |
| От: | Erop | |
| Дата: | 27.05.08 12:12 |
| Здравствуйте, D_Tony, Вы писали: D_T>А по поводу самого совета — вы и сами его больное место указали... Тогда выкладывай подробности. Потому что пока что не понятно что надо и какие есть ограничения... Если я правильно понял, что нужно чтобы адреса аллокируемых объектов некоего типа всегда возрастали с номером аллокации, то у вас нет никакого выхода, кроме как сделать большой пребольшой буфер и кусать и молиться, чтобы не кончился... А если цель не в этом, то тогда в чём? И что ещё залицензия за такая, которая заставляет вас так странно храниить объекты?  Я бы, например, поменял сравнивалку в std::map (это параметр шаблона), чтобы сравнивались не указатели а сами объекты, а в объекты добавил бы параметр "номер аллокации". Либо научился бы по указателю определять номаер аллокации, если layout объектов менять нельзя. Но что там у тебя можно, а что нет -- бог весть? Телепаты действительно в отпуске... Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском |
| Re[3]: детерминизм в выделении памяти | |
| От: | Erop | |
| Дата: | 27.05.08 12:20 |
| Здравствуйте, D_Tony, Вы писали: D_T>3 способ... Простите, а КАК?? и как настчет того факта что объекты генеряться тысячами и удаляются и ищутся... Ну заводишь свой умный указатель, для которого заводишь отношение порядка как тебе нравится. Полученные из фабрики объекты тут же заворачиваешь в эти указатели, и уже именно эти умные указатели хранишь в мапах и прочих местах... Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском |
| Re[6]: Дык телепаты-то в отпуске... :) | |
| От: | D_Tony | |
| Дата: | 27.05.08 12:29 |
| Здравствуйте, Erop, Вы писали: E>Здравствуйте, D_Tony, Вы писали: D_T>>А по поводу самого совета — вы и сами его больное место указали... E>Тогда выкладывай подробности. Потому что пока что не понятно что надо и какие есть ограничения... E>Если я правильно понял, что нужно чтобы адреса аллокируемых объектов некоего типа всегда возрастали с номером аллокации, то у вас нет никакого выхода, кроме как сделать большой пребольшой буфер и кусать и молиться, чтобы не кончился... E>А если цель не в этом, то тогда в чём? E>И что ещё залицензия за такая, которая заставляет вас так странно храниить объекты? E>Я бы, например, поменял сравнивалку в std::map (это параметр шаблона), чтобы сравнивались не указатели а сами объекты, а в объекты добавил бы параметр "номер аллокации". Либо научился бы по указателю определять номаер аллокации, если layout объектов менять нельзя. E>Но что там у тебя можно, а что нет -- бог весть? Телепаты действительно в отпуске... Да, нет, похоже есть зачатки телепа у Вас)))) И неплохие!!! Да, мне надо чтоб "адреса аллокируемых объектов некоего типа всегда возрастали с номером аллокации".. лицензия закрытая, межкорпоративная... Что именно обрабатывается — ну вот представьте квадрат... его вы можете сохранить как последовательность точка1 — точка2 — точка3 — точка4. И потом рисовать.. и обрабатывать... а можно точка1+пара{ребро_вниз, ребро-вправо}, точка2+пара{ребро_влево, ребро-вниз}, точка3+пара{ребро_влево, ребро-вверх}, точка4+пара{ребро_вправо, ребро-ввверх}. С тем чтоб хранить сразу все составляющие квадрата.. И проще обрабатывать было... Так вот эти пары я и получаю... Но как самостоятельные объекты.... (ребро_влево=ребро-вниз)=(ребро_влево=ребро-вверх) Узнали про какие пары я тут пример привел?? Да, про пары для точек 2 и 3.. Но они могут прийти и (ребро-вниз=ребро_влево)=(ребро-вверх=ребро_влево) Да, для целей рисования я всегда квадрат нарисую, но для анализа мне важно, чтоб пара (ребро_влево, ребро-вниз) всегда тока так и сохрянялось = хотя не важно как оно пришло... Вот это и надо решить |
| Re[7]: Дык телепаты-то в отпуске... :) | |
| От: | Erop | |
| Дата: | 27.05.08 12:59 |
| Здравствуйте, D_Tony, Вы писали: D_T>Да, нет, похоже есть зачатки телепа у Вас)))) И неплохие!!! D_T>Да, мне надо чтоб "адреса аллокируемых объектов некоего типа всегда возрастали с номером аллокации".. D_T>лицензия закрытая, межкорпоративная... При чём тут это? Это лицензия на что? D_T>Вот это и надо решить Что за точки там или рёбра не важно. Важно другое, какой код и как широко можно менять? Можешь ли ты заменить указатель на эти свои фабричные объекты на другой тип? Вернее так, что мешает заменить этот указатель на другой тип? Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском |
| Re[3]: детерминизм в выделении памяти | |
| От: | Кодт модератор | |
| Дата: | 27.05.08 13:16 |
| Здравствуйте, D_Tony, Вы писали: К>>Будет продуктивно, если ты расскажешь, в каких конкретно местах у тебя возникают проблемы; покажешь фрагменты кода; уточнишь, что из них можно переделать, а что нет. D_T>Ну новое-это просто позабытое старое))) D_T>Попробуем по порядку.. Начнем с конца))) Примеры — это туговато... ибо есть некая концепция "ошибки" по идее.. А ее локальные места толком не укажешь, если тока Вы не согласитесь пол листинга по емейлу получить и почитать его и поужасаться... D_T>Я уже писал — в очень сжатой форме — есть "фабрика", которая генерит объекты, которые потом расходятся по коду. и на основе уже их создаются другие.. Так вот в тот момент когда перво-объекты оказались созданы и помещаются для хранения в мапы нужно и задать какие-то правила помещения.. ибо это основная причина последующих "гос-переворотов" в поведении программы.. D_T>Поведением фабрики мы управлять не можем совсем... может тока милостиво получать объекты.... D_T>поэтому я думаю тут 4 способ пригодится-хотя явно уточнение нужно.. D_T>2 способ явно рушится от факта, что из фабрики объекты недетермнированно выходят.. D_T>3 способ... Простите, а КАК?? и как настчет того факта что объекты генеряться тысячами и удаляются и ищутся... D_T>1 способ — походу самая большая трабла — в этой фабрике... но ее мы "не видим и не слышим" . она святая))) Ещё раз: — в каких конкретно местах у тебя возникают проблемы; — покажешь фрагменты кода; — уточнишь, что из них можно переделать, а что нет. Хотя бы объявление типа объектов можно было привести, а? Если фабрику трогать нельзя, то нельзя менять ни структуру объекта, ни сигнатуру фабрики (забываем про хэндлы), ни способ размещения (забываем про аллокатор). Логично? Логично. Ставим точку. Следовательно: Нужно переделать весь код, который был по глупости завязан на мифический правильный порядок создания объектов. И это будет, вообще-то, самое правильное решение. Может быть, остаётся лазейка — определить отношение порядка над объектами и пропатчить все map'ы:
Если же над объектами невозможно ввести устойчивый порядок — то тебе придётся смириться с неизбежностью глубокой переделки. Ибо вотще. ... << RSDN@Home 1.2.0 alpha rev. 655>> Перекуём баги на фичи! |
| Re[7]: Дык телепаты-то в отпуске... :) | |
| От: | Кодт модератор | |
| Дата: | 27.05.08 13:16 | ||
| Оценка: | +1 | ||
| Здравствуйте, D_Tony, Вы писали: D_T>Что именно обрабатывается — ну вот представьте квадрат... его вы можете сохранить как последовательность точка1 — точка2 — точка3 — точка4. И потом рисовать.. и обрабатывать... D_T>а можно точка1+пара{ребро_вниз, ребро-вправо}, точка2+пара{ребро_влево, ребро-вниз}, точка3+пара{ребро_влево, ребро-вверх}, точка4+пара{ребро_вправо, ребро-ввверх}. С тем чтоб хранить сразу все составляющие квадрата.. И проще обрабатывать было... D_T>Так вот эти пары я и получаю... Но как самостоятельные объекты.... (ребро_влево=ребро-вниз)=(ребро_влево=ребро-вверх) D_T>Узнали про какие пары я тут пример привел?? Да, про пары для точек 2 и 3.. Но они могут прийти и (ребро-вниз=ребро_влево)=(ребро-вверх=ребро_влево) D_T>Да, для целей рисования я всегда квадрат нарисую, но для анализа мне важно, чтоб пара (ребро_влево, ребро-вниз) всегда тока так и сохрянялось = хотя не важно как оно пришло... D_T>Вот это и надо решить А нафига хранить многоугольник в ассоциативном контейнере, так сказать, вповалку? Храни в векторе, и будет тебе щасте. Если же быстрый поиск вершины многоугольника в большом многоугольнике — частая задача, то используй многоиндексный контейнер — например, boost::multi_index. Для квадратов же сойдёт и линейный поиск по массиву. Да и на памяти, и скорости размещения/доступа здорово сэкономишь. ... << RSDN@Home 1.2.0 alpha rev. 655>> Перекуём баги на фичи! |
| Re: детерминизм в выделении памяти | |
 | От: | EyeOfHell | |
| Дата: | 27.05.08 13:42 |
В вопросе и комментариях не совсем понятно, как Вы определяете, какой объект созданный фабрикой в какой позиции map должен находиться.
Что такое stringA, stringB, stringC? Как Вы их связываете с объектами, которые вам предоставляет фабрика? Опять же, не совсем понятно что Вы подрозумеваете под позицией. Насколько я знаю, map — это ассоциативный массив, в котором хранится список элементов вида имя-значение. При этом последовательности хранения элементов вторична — доступ к нужным как раз по имени и происходит. Если Вам необходимо при получении объекта запихнуть его так, чтобы он в цикле элементов map был в N-й позиции: берете текущее количество элементов в map, если оно меньше N — добавляете нужное количество "пустых" элементов, затем добавляете Ваш элемент, он будет N-ным. Если количество элементов больше N — значит туда уже добавлены "пустые", просто меняете в N-м "пустом" элементе значение value на адрес добавляемого объекта. stringA, stringB, stringC — по вкусу. Если то что я написал Выше является бредом — значит Вы что-то недостаточно ясно написали . Опишите получше, попробую помочь. |
| Re[7]: Дык телепаты-то в отпуске... :) | |
| От: | EyeOfHell | |
| Дата: | 27.05.08 13:52 |
И в чем проблема?
добавил разметку — Кодт |