[stl] отрицательный размер у multimap
по какой причине могло такое случиться?D.N.A.
Код давай
4000 строк устроит? --- хоть сам писал,
пока что часа 4 убил на поиск ошибки,
но по коду ее искать пока не решился.
и вам бы не посоветовал.
но если других предложений не будет, то скорее всего этим и кончится.
да и вообще --- все-таки интересно:
как это multimap создался так, что размер его левый, а вот элементы в порядке.
на сколько мне представсяется, то в multimap не должно быть таких глюков ----
вожможно лишь то, что я где-то с указателями намудил и
что-то левое записал по адресу, где size хранится, тогда и size может быть левым.
а может есть еще какие варианты?
он тебя нахуй послал
> а может есть еще какие варианты?
возьми какой-нибудь шаманский бубен типа valgrind, например
4000 строк устроит?
Типа "из песни слов не выкинешь"?
И ещё, можно поинтересоваться, каким образом ты определил, что он "отрицательный"? (size_t всё-таки)
отрицательный это не совсем правильно --- согласен, правильее сказать что он ебанутый какой-то.
вот уже как год примерно size_type этих multimap-ов я считал long-ом и повода усомниться в этом не было, и проверять мне это не хочется. Но факт то что элементов в этом мапе 80 и то что другой мап, у котороко из 54, по printf("%d",...) выводит 54.
Да еще можно прибавить то, что size_t есть unassigned integral type, так что, если бы значение было бы 80,
то при %d выводилось бы тоже число 80 (по-моему или я не прав?).
вот, а выводится число -127893643 (ну примерно )
Так может ты этот multimap по ошибке чем-нибудь затираешь?
я об этом писал
всем спасибо
unassigned integral type
Ну вот, а ты спрашиваешь почему он не 80 -- он же unassigned!
Оставить комментарий
SCIF32
сам multimap непустой ----в форе выводятся его элементы --- где-то порядка 80, но size от него
отрицательный.
может кто подскажет, по какой причине могло такое случиться?
может ли это зависеть от способа заполнения?