Массив в классе на С++ и глюки в Linux

> ЗЫ: прога 100 процентов рабочая

Угу, конечно. valgrind в зубы и вперёд. Много интересного узнаете.

>>сегфолт при присваении нуля автоматической переменной это уже через чур...

где-то бьётся память 100%. Ищи в valgrind'e

я тут прежде чем писать уже много чего нового с valgridом узнал, а хуйня при вызовах осталась, делаешь объект статическим все ОК, делаешь указателем и пользуешь new сегфолт, меняешь местами порядот создания объектов все ОК, меняешь назад сегфолт. Вы если такой гений то поясните мне плиз следующее:

объект С использует объекта А и В. Объекты А и В друг от друга полностью независят => порядок их инициализации(создания) не имеет значения лишь бы они были создано до С. Теперь вопрос: Какого х..я в лине надо создавать сначало А (с массивом) а потом В и С???? (Если создашь сначала В а потом А и С то будешь ловить сегфолты и аварийные завершения в glibcе).

ЗЫ: я полагаю что если написанный на СТАНДАРТНОМ С++ КОД РАБОТАЕТ В FREEBSD ТО ОН ДОЛЖЕН РАБОТАТЬ И В LINUX естестно будучи скомпилиным в лине.

Держите себя в руках.

Ваш код содержит ошибку. Если вы её не видите, это не значит, что её нет. Если ваш код работает под FreeBSD, это не значит, что он корректный, это значит, что ошибка под FreeBSD не проявляется. Странно, что мне приходится это объяснять.

Вы говорите, что программа падает. Если вы скомпилируете её с отладочной информацией и запустите под valgrind-ом, вам будет показана причина падения, стектрейс и т.д. Думаю, разумнее всего будет, если вы объясните, почему эта информация вам не помогает.

> СТАНДАРТНОМ С++ КОД РАБОТАЕТ В FREEBSD ТО ОН ДОЛЖЕН РАБОТАТЬ И В LINUX

разрывы были?

> разрывы были?

баян и жопу уже порвали. Searching.. Seek and Destroy.

Судя по тому, что ты написал, ошибка проявляется при использовании libc из Linux (glibc). Убедись, что используешь стабильную версию glibc. Поищи в её багзилле что-нибудь подобное. Возможно, кто-то до тебя с этим уже сталкивался. Ну и, само собой, отлаживай программу. libc в разных системах разные, поэтому и ошибка не во всех реализациях проявляется. Но ошибка точно есть.

есть вот только в glibc линевом...

сообщения типа "glibc чего-то там corrupted" появляются как раз из-за битой памяти _у тебя_ в программе. Без кода тут сказать сложно (ком. тайна, ага), и всё что смогли уже посоветовали (valgrind).

> и положим он конструктором не инициализируется, делается это при его первом
> использовании в публичной функции интерфейса.

http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12

> и не весь можно выкладывать на публику ( 1 не все мое 2 ком тайна )

Тогда и ответы -- только за деньги.

Компоновка с объектным файлом, содержащим переменную - экземпляр класса, имеющий в качестве одного из членов большой массив, - действительно может изменить непредсказуемое поведение некорректной программы, в которой есть, скажем, обращение к неинициализированной памяти.

Например, есть ли у Вас в коде глобальные переменные, объявленные в одних файлах, обращение к которым происходит из других файлов (через объявление extern)? Являются ли эти переменные экземплярами классов с нетривиальными конструкторами? Если да, то возможны проблемы. Один из способов решения таких проблем - замена обращений по extern-ссылкам на вызов функций типа GetInstance с соответствующей реализацией (например, так: A& GetA(){static A a; return a;} - подойдет в случае однопоточного приложения вместо обращений к extern A theA;)

я тут тоже когда-то кричал что glibc глюкалово, а потом решил-таки валгринд запустить :). и, о чудо, нашёл ошибку :). Ищите, короче, дальше...