Это не вопрос, а скорее крик души.
Месяца два с половиной, в свободное от работы время, мучаю проект. И вот, похоже, настал конец терпению.
Чем больше разбираюсь в этом коде, тем больше хренею (другое слово не подберешь).
Яркий пример того, как не надо писать.
По порядку:

1. Видимо, все знание автора об отличиях С от С++ сводится к наличию единственного класса, единственный экземпляр которого инстанцирован в структуру(!), что само по себе нормально, за исключением того вопроса на фига это там было нужно, для меня так и
осталось загадкой.

2. Догадайтесь как обстоят дела с выделением памяти? Именно, незабвенный malloc. По некоторому стечению обстоятельств, функций free я обнаружил меньше :\

3. С потоками такая же напряженнка, как и с выделением new. #include <stdio.h> и точка, нафиг нам стримы?

4. Собственно от чего я сегодня опупел - static-функции вне класса. Честно сознаюсь, никогда так не извращался, посему тот факт, что я её фиг увижу за пределами единицы трансляции поверг меня в уныние. Нэймспейсы, видимо, отменили специально для "аффтара". Для чего это вообще делалось, так и не понял.

5. Об RTTI тоже автору ничего не известно. Следствие - около полусотни варнингов об опасном присваивании при компиляции.

6. Никакого намека на STL. Я, конечно, рад что в программе так классно реализованы операции с массивами, массивами указателей, массивами указателей на указатели, указателями на массивы указателей на указатели. Но, блин, чтоб выбрать элемент по имени,
мне перебор прикажете делать?

7. Отдельная песня - это имена переменных и функций. Ни один шпион не догадается. Если комменты не прочитает. Вот только комменты в .h, а нужно работать с реализацией.
Вот как вы думаете, зачем нужен следующий код:
void stdexitcls(char s, float pt, float sl, int bth)
{ sexord=1; sexi=s; sexpt=ptt(pt); sexsl=ptt(sl); sexbrs=bth; };
Вот я тоже не телепат. Смотрим объявление, например:
char sexi; // standard exit id
Вот ведь, блин, а я уж было подумал... Оказывается sexi и отношения к сексу не имеет, разве что церебральному.

8. Вернёмся к классу. Убедившись, что править что-то в этом коде сродни подвигам Геракла, вместе взятым есессно, решил воспользоваться одним из базовых столпов ООП - полиморфизмом. Унаследовал класс, написал свою реализацию нужных мне методов, а вот не переопределенные методы вдруг перестали работать. Удивительно? А мне нет. Те члены класса, которыми они пользуются были объявлены в приватной секции, а совсем не protected.

Блин, по скромной оценке кода больше тысячи строк... Как дальше с этим работать просто загадка тысячелетия. Но если назвался груздем...

Были ли у вас такие подлянки? Как мне дальше разгребать?

С чем я встречался:
9. Переопределение оператора new/delete -- руки отрывать.
10. switch на 10 вариантов.
11. Функции принимающие 10 (да-да, 10) параметров.

Если там всего 1000 строк лучше переписать к чертям собачьим, такое и рефакторить низзя.

Ну это я сильно поскромничал, 1000 строк - это только та часть, с которой я работаю, даже, наверное 1500-2000 будет точнее, остальное было скомпилено в либы и благопулучно забыто. Общее количество строк в проекте (только .cpp и .с файлы, без учета хидеров) 14 225. Если это дело реверсить, то придется поднимать всё. А мой неокрепший организм такого мазохизма не вынесет...



Фунция, на которой я споткнулся в п.4 принимает 13 параметров.


Здесь я натыкался на switch из 25-27 вариантов, хотя ИМХО это не страшно. Если задача отправить мессагу об ошибке, то самый приемлимый вариант.

Пинать. Аффатру явно забыли сообщить что имена переменных можно делать из >6 символов и читабельными




+1
Верни это на ту помойку из которой..... на родину вообщем.






а как же map<ErrorID, string> и exception::what()?

Посыпаю голову

ЗЫ кстати, exception отсутствует, зато есть глобальная функция FatalError. С однозначной реакцией умереть нафик, даже если это не нужно.

если ты разгребаешь opensource код, то это типичная ситуация
а вообще, хочется всем пожелать побольше внимания уделять комментариям !!!

Что делать:
если исходный код работает правильно, лучше его не трогать, а написать свой фасад или адаптер. Причем сначала спроектировать интерфейс, не глядя в это г., а потом попробовать реализовать его.

Если неправильно - забыть про него совсем и переписать.

Часто на работе сталкиваюсь с такими комментариями одного товарища:
1. // Пока не конец.
2. // В массив.
3. // Составляем запрос.
4. // Всё...

и т.д. И ни одного толкового комментария. Лучше вобще их не писать тогда .

Работает правильно.


Вот это я и делаю, но в процессе приходится выяснять логику, тут и начинается свистопляска.


Очень ценное замечание. Спасибо, так и поступлю.


14 тыс строк?

Не факт, что в результате будет столько же.
Но поскольку

то, конечно, лучше не трогать, не смотря на

А кому сейчас легко?

Earnest, а если надо что-то изменить в поведение этой функции? А рефакторинг провести нереально?

Мы живем не в идеальном мире, рефакторинг нужно проводить только когда его нужно проводить а не просто потому-что так хочеться (ну если конечно, у тебя это не хобби)

Есть прикольная книженция о том, как желательно оформлять исходный код программ.
Вот только не нашел как тут файлик присоеденить, так что если кому нужна (она небольшая *.doc),
могу скинуть или выложить где скажите

, а файл ресурсов?

, иногда в *.dll для независимости от клиента приходиться писать и больше, так что это в зависимости от задачи, на мой взгляд;

12) Hard Code (сообщения, числа и.т.д.);
13) Non Const Global Variable (просто бесит что вместо стека используется глобальная свалка - функциональное программирование);
14) Memory Leak (только стратегия владения и сборка мусора);
15) Native Implementation Dependence (бесит, когда пишут код зависимый от реализации);

Это сообщение отредактировал(а) np9mi7 - 21.3.2006, 13:38

насчет всего того что код предыдущего кодера иногда писан через одно место:
вопрос какая задача стояла у программиста предыдущего кодa.
Oбычно интересный проект - пайлот, когда заказчик еще сам не знает чего надо досконально,
и описывает задачу в процессе реализации. также возможны подводные камни которые без опыта обнаружатся тоже в процессе реализации. можно не взять такой заказ, а можно взять.
когда берешь, имеет место быть шанс плохого дезайна.

есть конечно тривиальные задачи, которые не нужно "разрабатывать" - взял шаблон и шаблонь.
но не всегда.

но ногами писАть, согласен - нехорошо!

Это сообщение отредактировал(а) bilbobagginz - 21.3.2006, 15:03

А чем собс-но плох malloc? В случае, когда используются нетривиальные объекты (с конструктором, деструктором), и требуется перевыделение памяти с сохранением данных (realloc), использование new и delete – явно не самое удачное решение.

А как ты собрался вызывать коструктор из маллока?

Хотя, конечно, в данном случае new и delete не особо нужны - классов то все равно нет.

1. (Как сказали выше) Ничего не знает про конструкторы\деструкторы
2. Для malloca нет smart pointer-ов



Самое лучшее решен ие в таком случае - std::vector, но никак не realloc

Ясное дело, конструктор вызывается отдельно.


И что? Самому сложно добавить их вызов?


Не велика потеря. При желании можно написать свои.


Чем же оно самое лучшее? Быcтрей работает что ли (во всех ситуациях)?

Что??? Явный вызов конструктора по указателю? Ты на каком языке пишешь?


Да ты что, это же мое любимое занятие - делать работу за компилятора.


А причем тут умные указатели? Для них просто перегружают некоторые операции,
но совсем не обязательно перегружать new и delete.



Лучшее - не значит самое быстрое. А то бы все писали на Си и Асме.

Ну, да. А что тут, собс-но, смущает?


Ну, макросы ещё вроде бы никто не отменял:


Правда, чтобы эта штуковина заработала внутри шаблонов, придётся ещё повозиться :-‎)


В некоторых ситуациях быстрота существенна.

Это сообщение отредактировал(а) UnrealMan - 31.3.2006, 19:00

Велосепидисты вперед!


Еще раз вперед


А что знают макросы про области видимости и пространства имен?

То же, что и new :-‎) Ну, и? Это типа повод использовать везде и всюду std::vector?

Я-то, в общем-то, не выдвигаю здесь тезис в духе «malloc рулит, всё остальное голимый отстой», а только спрашиваю, почему само по себе использование malloc (независимо от того, какая задача решается) вызывает этакое презрение.

Потому, что для new все уже написано.

Потому, что предрассудки всё это :-‎)

Это не предрассудки. Это деньги. За последний год я ни разу не написал delete или delete[]. Умные указатели\STL рулят

Примитивно это как-то – выискивать некий самый лучший способ на все случаи жизни. Всё зависит от требований задачи. И вот уж как не надо писать код, так это без учёта этих самых требований, руководствуясь только лишь мыслью «а у меня уже есть самый-самый крутой способ, я буду с превеликим благоговением молиться на него и использовать везде во всех своих программах».

Да вот как раз не выискивать лучшие способы примитивно, только не на все случаи жизни, а на большую их часть. Если меня устраивает быстродействие new/delete, то почему я должет отказываться от них? Но в любом случае malloc - не лучшее решение, правильнее будет перегрузить new/delete. В любом случае, для использования malloc должны быть очень веские причины и вряд ли в том г. про которое говорил Ignat они были (кроме плохого знания С++).

P.S. 2UnrealMan А на счет явного вызова конструктора - признаю, не знал. Просто никогда не доводилось пользоваться. Решил проверить первым попавшимся под руку компилером - это был 6-й Билдер. Билдер дал по рукам.
После твоего поста:



попробовал еще раз - на этот раз в VC6. Все прошло в лучшем виде. Правду говорят - Билдер это зло.

Отказываться от new и delete я и не призываю. Да и к быстродействию самих по себе new/delete я никаких претензий не имею – собс-но, если я чего не путаю, они вызывают те же malloc и free, а потому по скорости работают одинаково. Хотя есть и функции, которые работают пошустрей, например, AllocMemory и FreeMemory (bhsupp.dll). Однако ж я не вижу причин полного отказа от malloc.


Обоснования этой правильности?


Ну прям очень. Один и тот же результат (в отношении тривиальных объектов без конструкторов), но new всё равно лучше! :-‎) В это надо просто уверовать...


А как ты в builder'е пробовал-то вызывать конструктор? Так:
pointer->Class() или так:
pointer->Class::Class() ?

Это сообщение отредактировал(а) UnrealMan - 2.4.2006, 12:08

На практике все же new и delete работают насколько медленнее. Можно для проверки написать тест, но в любом случае эта разница будет совсем небольшая. Здесь все зависит от компилятора.



А я не вижу причин его использования. Если конечно мы пишем на С++, а не на С.

Imho, это разговор в никуда - как всегда договоримся, что malloc рулит (что надо еще доказать), но только в 0,0001% случаях, а в остальном использование malloc'а - пережиток времен С. В итоге и те и другие будут правы, а кто выделял память malloc'ом так и будут это делать. Пора тему закрывать.



Да и так и эдак - Builder не знает метода Class().
В VC6 второй вызов работает как надо, можно даже не через указатель а напрямую.
Но все это imho нужно не более, чем какой-нибудь const_cast. Кто-нить им хоть раз пользовался?

Ну вы блин даете. Кто же так конструктор класса вызывает, а? Где это так написано?

Если vc компилит это ещё не значит что правильно.

 
Зато есть большая разница в скорости (десятки раз) выделения разных объёмов памяти (так сказать, камешек в огород std::‎). Причём вся эта разница красуется на интервале малых объёмов (где-то до 1кБ).


:-‎) Дык, эт я методом тыка нашёл сей способ :-‎) Впрочем, я ожидал, что он может оказаться непереносимым.

Кстати, как этому void *operator new(size_t, void *) соответствующий delete прописать? (а то мой компилятор ругается, а я уже не помню, как это дело улаживается)  

Это сообщение отредактировал(а) UnrealMan - 3.6.2006, 09:18

А он не нужен

Да вроде как желателен:


MSVC++6.0: warning C4291: 'void *__cdecl operator new(unsigned int,void *)' : no matching operator delete found; memory will not be freed if initialization throws an exception

Для каждой формы new (т.е. набора дополнительных аргументов) должна быть соответствующая форма delete (c тем же набором дополнительных аргументов). Для того редкого случая, когда исключение будет возбуждено сразу после благополучного выделения памяти (т.е. в конструкторе). Что, собственно, и написано в предупреждении.
Странно, что компилятор не предоставляет стандартный размещающий delete (тогда как размещающий new есть). Возможно, это "особенности" VC 6. Но теоретически никто не мешает написать размещающий delete (он просто ничего не делает). Или просто забить на предупреждение (отклбючив его, чтобы не травмировать психику).

Что-то какой-то жёсткий флуд пошёл, а ведь так забавно всё начиналось...

Ignat, я, видимо, в этих вопросах избалован больше Такой долбанутости как смвыше не встречал (недавно во всяком случае). Поэтому приходится обращать внимание на такое (надо ж на что-то ругаться):




Я бы поправил - глобальное переопределение. Переопределение этих операторов в каком-либо классе для меня даже приятно До определённой поры, конечно.


А вот это - да. Плохо, значит, продумано, раз такие функции приходится создавать.

Ага, CreateWindowEx в топку: она юзает 12 параметров :-)


Вопрос был в том, как её правильно прописать (чтоб предупреждение убралось).


Это сообщение отредактировал(а) UnrealMan - 11.4.2006, 14:49

Ага... Именно в топку.
Значительная часть виндового апи была унаследована от 16-битных приложений и оставлена для совместимости. Правда, вышеупомяннутая функция к ним не относится. Но почему передача параметров не была организована структурой - не понятно.

Ох задело не удержался.

На мой взгляд людям, которые без супер-пупер везких причин используют такие пережитки прошлого, как malloc(), а уж тем более явно вызывают конструктор класса, необходимо как можно скорее прижечь раскаленной качергой то место, которое у нех почему-то чешется.
Я считаю, что если ты один делаешь программу для себя, то можешь хоть всю ее из макросов сделать в одном .cpp файле, не написав ни одного коментария.
Но если ты пишешь программу не один, если ее объем достаточно большой, если твой код в будущем кому-то придется использовать, так буть добр действуй по общепринятым правилам.

А теперь по теме. Лично меня больше всего бесит в чужом коде это псевдо крутые программерские фишки типа макросов или жуткого сокращения кода.

P.S. для общего развития - чем плох switch на 10 вариантов?

Смотря в какой ситуации он используется.

А что не понятно? Форма записи - так сказано - такие же аргуметны, как у new, только вместо первого size_t (у new) должен быть void* (удаляемый указатель). Внутри (в твоем случае) может ничего не делать. А просто для "убрать предупреждение" достаточно #pragma - т.к. (в твоем случае) никакой утечки памяти произойти не может...
Добавлено @ 12:09

В первую очередь, плохо-читабельность и плохо-сопровождаемость.
Даже если на каждый case будет просто вызов функции, этот switch уже плохо-обозрим. И почему бы его сразу не заменить на явную таблицу функций?

Вот и я не смог удеражться от высказываний.
Ignat, - тебе просто не повезло, а что касается 14тыс строк - а так ли это много? Это всего лишь 280 страниц в стреднем. И обижаться на программиста нет смысла, так как сейчас действительно программистов используют "в темную", ставя не реальные сроки и не раскрывая того, что требуется. Вообще-то говоря путь есть, он прописан все в тех же ГОСТах, а именно, надо сформировать пакет следующих документов(примерный пакет):
1) технические требования
2) провести дополнительные исследования по результатам которых сформировать техническое задание
3) по техническому заданию сформировать план - график работ

И проблем не будет! Но! Попробуй объясни заказчику, что именно так и только так он будет знать конкретные сроки(хотя они сразу же и возрастут, так как по тех заданию можно составить реалистичный, а не оптимистичный план).
А тот программист в чём то прав. Сейчас его нет и без него программа не получает дальнейшего правильного развития. Я так понимаю, что на его коде основана база проекта, а вот на эту базу ты делаешь "довески". и деньги сейчас получаешь именно ты . А тот кто делал базу отдыхает. Если спросишь его доволен ли он работой у твоих работодателей, что получишь в ответ? Да и вообще он может специально сидел пару недель и вычищал все комментарии
Я думаю, что вообще в наше время просто необходимо иметь программу, которая не только вычищат комментарии, но и переименовывает функции, например CreateBiilGates(int sex, int nationalnost) в Rl92384jk12324(int uioew89342kj,int sdf83sdf2087). Кстати, кто нибудь делал такую?

Погугли на предмет обфускаторов. Много можно найти.

Вообще-то это прямой саботаж и обман работодателя. Сданная работа - это не только exe (возможно с документацией), но и приличный код. Уж во всяком случае без преднамеренной порчи. И не надо оправдывать эту пакость тем, что тебе мало платят - ищи, в конце концов, другую работу. Любая халтура - она тебя прежде всего портит.

Уже давно пробовал – предупреждение не исчезает.


Да я в курсе, но, по-моему, такое «убирание» предупреждений не есть хороший стиль программирования.


Чем же это плохочитабельно? И какова предлагаемая альтернатива?

За такое ты рискуешь получить "очень хорошие" рекомендации. Только солибной фирме ты так не сможешь нагадить. SVN\MS SS умеют выдергивать старые версии.
Добавлено @ 22:45

Виртуальные функции. Пример(пишу прямо тут, поэтому не обессудьте):
Добавлено @ 22:48
Далее, потребовалось добавить новый метод Draw. Код становится таким
Добавлено @ 22:51
Видишь switch-и плодятся! А теперь добавь еще один тип фигуры - треугольник. Во скольких местах тебе необходимо править код? Уже в двух, причем в реальном коде эти два(а ты уверен, что два? Ты все switch-и нашел? ) метода могут быть не рядом в одном файле, а в разных файлах\библиотеках

Насчет альтернативы и сопровождаемости DeadSoul уже написал. А плохо-читаемость из-за плохо-обозримости. "Хорошая" функция должна занимать не более пол-страницы, чтобы с одного взгляда можно было понять, что она делает. И делать она должна что-то одно. Мне же приходилось видеть функции со switch'ами страниц на 20. Вот счастье-то, когда что-то поправить нужно. Сразу чувствуешь себя ассенизатором: надеваешь прищепку на нос, рукавицы по локоть и ныряешь в это. Мне лично в таких случаях сразу хочется кого-нибудь убить.

Оно все верно, когда вы изначально обговорили вопросы об авторсте. Плюс если вы сразу же знали, что от вас требовалось, а когда работа выполняется без четкого задания и вы за нее принимались, точно будучи уверенными, что пишете самокат, а в итоге от вас потребовалось написать аэрокосмичесую станцию, то... Вообщем, не очень хочется отдавать исходники, вот после того как зарегистрировать права, - можно, но и то только если очень попросят или об этом сразу была договоренность 

Добавлено @ 14:14 
 - главное, чтобы глюков не было   , надёжность - главное! 

Как ты думаешь насколько сложно получить контракт человеку, пишущему прекрасный код, но имеющему отвратные рекомендации?! 

DeadSoul, да думаю, что даже полегче будет, чем тому, кто имеет великолепные рекомендации, но продукты которого периодически глючат. 

Ты очень здорово ошибаешься.
Работодателю более важна надежность и порядочность сотрудника (другими словами - лояльность), чем его программисские таланты. Конечно, полный лох никому не нужен. Но и самый разотличный программист, если он может выкинуть какой-нибудь фортель в описываемом духе - тоже.

 

Ну если он опытный программист, то еще лучше =)))


А по теме: найти хорошее место работы при хороших проф. качествах и кол-ве смены рабочих мест, превышающих 7 в течение пяти лет, представляется сомнительным. 

Таких людей называют "Летуны" 

 и тогда то вот работодатель и заключает договор или контракт, в котором всё обговорено, а если контракта на бумаге нет, и ты понимаешь, что начиная писать, как я и говорил ранее "самокат", в итоге пишешь уже аэрокосмолет, то в таких фертелях ничего зазорного на мой взгляд нет. Да, платят то вот как за самокат   Но думаю, что про это хватит. Просто сотрудник должен не чувствовать себя обманутым, а лучше защищённым и довольным, тогда этого не будет. А про хорошие качества мои как программиста ничего сказать большего, чем в подписи не могу. Лично я могу выезжать лишь за счёт общей культуры проектирования(и то это моя субъективная оценка самого себя  ) 

Может и глупый вопрос, но я тут заметил, что, в основном, люди здесь, вместо того, чтобы преодпределить область имен using namespace std, просто постоянно делают разрешение видимости, типа std::cout и т.д.
Это такой стиль (у Страуструпа в книге такой), или же в этом есть какой-то определенный смысл? 

Смысл - не вносить идентификаторы из пространства имен std в глобальное пространство имен 

Дополню:  "using namespace x" может привести к кофликту имен: допустим в твоем контексте есть имя Y. Неважно, откуда оно взялось: это может быть локальный символ или нечто из другого пространства имен (введенное директивой using). Если в пространстве имен x тоже определено имя Y, то каждый раз при использовании Y в нашем контексте будем получать стоны компилятора о неоднозначности.

Поэтому общий принцип такой: в заголовочных файлах вообще стараемся избегать директив using (даже using "конкретный символ", using namespace же запрещаем под страхом смерти). Чем шире используется заголовочных файл, тем сильнее избегаем.
Внутри cpp-файлов и тем более внутри функций - вполне допустимо, можно поступать так как в данном контексте удобно.  

Кто-то грозился книгу выслать... [email protected].  Сп.

Ткните пальцем в тот пост. В противном случае, ваше сообщение - оффтоп.

http://forum.vingrad.ru/topic-87958/0.html#   -    фот: Дата 21.3.2006, 13:19. UnixBeginner
 Я бы тоже хотел эту книгу:  "formail1 @ gala.net" (без пробелов)

Нас в институте учат сокращать код с if, else например, вот так-


до
 

Интересно, речь случайно не об этой  книге?

Возможно и об этой... интересно было бы почитать что-либо о стандартах программирования.. в частности на с++.

Я б убил за это... Читать потом невозможно, а стандарты форматирования существуют не для компилятора, а для человека. Пиши лучше так:

bsa, а я за перенос скобок бы убил  

Ты имеешь в виду перенос открывающей скобки на строчку оператора? Дело вкуса   

bsa, да, но я этого жутко не люблю - потому что нельзя пробежаться глазами вертикально вниз от одной скобки к другой, чтобы найти конец и начало блока быстро. Приходится читать код  А так можно было бы машинально. На мой взгляд такой стиль - экономия места, а без переноса - читабельность

Не надо писать вот так (перл новичка в С++, раньше писавшего на яве):

Подскажите пожалуйста! Как получить доступ к данным в строках "ComboBox". Цикл такой: 


Заранее спасибо.

Привет всем умным и знающим я тут с таким вапросам как мне научится рязыку С++ ? дайте какие нибуть прожки несерьёзные плиз 

Начни с указателей, они пригодятся тебе: http://forum.vingrad.ru/topic-60932.html
А так советую, купи книжку Страуструпа, третье издание, специальное. Хорошая книга.

Народ, да вы чего ? K&R рулит   
Кто-нибудь пытался прочитать код Vim ?! Не знаю, лично для меня даже libaal и kernel/sched.c проще читать.
Там это, когда переносят скобку на следующую строку - не видно к какому оператору скобка да плюс читаете _две_ строчки вместо одной. А блоки (в нормальном коде) тупо по отступам видно.

Насчет глобальных переменных. Ну и чего плохого в том, что будет глобальная структура со всеми настройками проги ? Лучше разбить на десяток объектов со своими свойствами, каждый из которых отвечает за свою функциональность ? А потом х.з. где у тебя "глубина дерева"................. Нет, _я_ конечно, найду... Тем же "бобиком", но................. Зачем ВЕЗДЕ И ВСЯ пихать классы ?! Хорошо научили что-ли, надо пользовать ?

Насчет классов. Лично меня убивает когда прогу начинают с класса... В смысле CSpace (типа - космос), а потом вниз до функции "найти символ". (где моя "муха" ?! )

<Ы>
Встречал разное... В том же Vim (наболело  ) дофига и больше макросов и #ifdef'ов (проверяющих архитектуру !). Полное отсутствие документации (по коду) или хотябы описания структуры или еще чего-нить (!).

А я бы убивал тех, кто пишет на Haskell или "D", чесслово ! Вот тока винтовку достану