Здравствуйте, NikeByNike, Вы писали:

NBN>Ты о чём? DesC?
NBN>А почему именно void*, что мешало обычные указатели использовать?

обычные тоже были. речь идет о буфферах данных неизвестного типа — то что по сети приходило, перед передачей в машину состояний.

Здравствуйте, Left2, Вы писали:

NBN>>Я тоже писал, под ту же портянку платформ. Ничего не мешает тебе так же использовать самописные ливы или вообще отказаться от исключений в логике программы.

L>Главная проблема не в том чтобы отказаться от исключений — главное чтобы ливы не полезли из симбиан API. То бишь, в итоге всё уприается в мегавраппер над всем симбиан API.

А это по любому надо для кроссплатформенных разработок

Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, Cyberax, Вы писали:

KP>>>мне кажется, стоит поработать над методиками изучения. работать с Emacs можно после 2-3 дней его изучения и расппечатывания шпаргалки.
C>>Чем мне эти шпаргалки помогут, если у меня не работает нормально отладчик в нем? Хоткеи я и так прекрасно могу запомнить.
L>Может, для начала следует научиться писать код так, чтобы не было необходимости в отладчике?

Кстати, возьму на вооружение прием. Как скажут, что 'а вот гавно у вас редактор в студии', так я сразу отвечу 'а слабо программировать так, чтоб не пользоваться редактором'? А, а??? Воооот...

З.Ы. Лично я оченна радовался (давненько) когда увидел KDevelop (это были первые версии). В нем и справка была на МСДН похожая, вся такая интегрированная, гипертекстовая (ага, не юникс-вей, зато очень удобно). Правда КДевелоп почему-то падал постоянно.

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, machine3000, Вы писали:

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

KP>Лично мне не важно, понятен ли интерфейс любому, кто видит его в первые. Важно понятен ли он мне и насколько удобен в использовании. На данный момент, возможности которые предоставляет Emacs превосходят возможности VS и мне этого достаточно для выбора редактора кода. Хотя сам начинал с VS и тоже был очень доволен предоставляемыми возможностями редактирования. Только вот постепенно изобили окон стало раздражать, лазить за мышкой стало лень, а настроить все полностью на клавиатуру в студии довольно проблематично.

а я все мечтаю освоить этого каркардила. только работаю под винду. на линукс не пишу ничего. вот выйду на пенсию и тогда...

кстати, если ставить его версию под винду, то как он поможет мне в разработке? его ж можно будет использовать только как редактор или отладка тоже будет работать? он перекроет по возможностям VS 2005 ?

карандаш?

Здравствуйте, Sergey, Вы писали:

>> Ну ткни что ли неуча в какой-нить FM, где, к примеру, сказано, как в студии моментально перепрыгнуть на парный открывающий/закрывающий символ? В виме — % (подозреваю, что для этого таки есть какая-то особенно извращенная распальцовка, да вот не нашел нигде)

S>Ctrl+]

Заметьте, что когда отвечают по существу, то дискуссия в под-ветке прекращается, а так только вопли везде, что студия не умеет то, не умеет это...

А в общем, то чего она не умеет, так может оно и даром не надо? Это как с Неуловимым Джо.

Особым ценителям в руки дается встроенный макроязык (ну, бейсик, а что?).

Здравствуйте, sc, Вы писали:

sc>Здравствуйте, AndrewJD, Вы писали:

AJD>>Здравствуйте, kaa.python, Вы писали:

KP>>>легче один раз освоить один кроссплатформенный радактор и больше не заморачиваться на средства. много раз обращал внимание на то, что чем выше уровень разработчика, тем меньше для него значит в чем писать код.

AJD>>Настоящие перцы в блокноте (или аналоге) код пишут.

sc>А самые настоящие в copy con hello_world.cpp
sc>Тоже столкнулся несколько лет назад с проблемой нормальной IDE, именно IDE, а не редактор кода, на юникс/линукс.
sc>До сих пор вопрос открыт По сравнению с VS все остальное отстой. Но приходиться жрать этот чертов кактус

KDevelop не то? (сам на него даааавно смотрел)

Здравствуйте, Anatolix, Вы писали:

A>Это к чему сказано? И как это подтверждает или опровергает тезисы выше по стеку?

Я только читать начал, а тут стэкъ оверфлоф.

WH>При наличии общего опыта и светлой головы освоить линукс или что либо другое не составляет труда. Вобще.

Это другой вопрос. Это вопрос о том, а нужен ли конкретный опыт работы, тем более на senior позицию.

Тут всякие разные обстоятельства бывают. Может быть, например, "бесптичье", когда ищут-ищут полгода Senior Linux C++ (а не PHP/Perl) программиста (а не сисадмина), да не могут. Тут да, любую мало-мальски светлую голову возьмешь.

А может быть ровно иначе. А именно — открывается проект под Линукс (пусть даже и порт с виндов), и нужен "линуксист" для дачи старта проекту. Тогда нужен готовый линуксный гуру.

Кроме того. Светлые головы как правило в команде уже есть, их светлость уже проверена, потому, если устроит "светлая голова общего назначения" — лучше перевести на этот участок имеющуюся, а не собеседовать не пойми кого.

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

R>Все равно все работает на одном и том-же железе, везде одинаковый код, одинаковые механизмы страничной адресации, одинаковый стандартный С++.

...одинаковые сокеты и особенно select, одинаковый асинхронный ввод-вывод, одинаковые сетевые стеки, одинаковый UI, одинаковые threads, одинаковое управление процессами, одинаковый XML парсер... gcc у нас тоже абсолютно одинаков с микрософтным CL

И главное — одинаковые типичные паттерны решения конкретных программистских задач всегда и во всем одинаковые.

R>В винде их склеили так, а в линухе немного иначе и что? Заполнить эти пробелы можно за относительно небольшое время.

...после нескольких отчаянных криков "помогите-у-меня не работает" сюда на RSDN

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

R>Спроры про среду разработки считаю маразмом — среднеиндустриальные показатели числа строк кода на человека < 100 строк в день.

...давайте теперь это количество снизим еще более неудобным для данного человека редактором.

C>Собственно, после работы с GDB я понял, почему люди считают отладочную печать лучше, чем использование отладчика. Просто она действительно намного удобнее GDB.

Тот же WinDbg, вид сбоку, только _все_ команды называются там иначе, чем в WinDbg.

Вывод: у человека, который уже привык к GDB, будет совсем иное мнение о его удобстве.

WH>А если этот Вася автор сторонней либы? И живет этот Вася на другом конце планеты?
WH>1)Только не надо гнуть пальци и говорить что сейчас мы это поделье быстреньке перепишем.
WH>2)Или найдем что-то лучше.
WH>1)Не реально. Ибо там ну очень много написано. И переписывать это ооочень долго.
WH>2)Эта поделка лучшее из того что доступно.

Угу. Типичный срок — полгода. В коробочном софте это необходимость, в "точечных" решениях конкретному кастомеру на конкретную площадку — безумие.

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

Здравствуйте, Maxim S. Shatskih, Вы писали:

не надо драматизировать — разница меньше чем между с++ и дотнет

и потом только идиот наймет только (или по большей части) виндузятников на юниховый проект
но соотншение 1 виндузятник на 2 линуховедов вполне нормально и позволит не наступать на грабли

Можно рассчитывать только на 1 вещь
-при полностью корректных данных на входе, скорее всего все работает

на что рассчитывать нельзя
-для многопоточных приложений никаких гарантий нет
-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
-при некорректных данных на входе никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по анализу данных
-в нештатных ситуациях никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке нештатных ситуаций
-написать юнит-тесты на отказ оборудования чисто физически проблематично, т.к. требует работы с железом\системными функциями через интерфейс(здравствуй куча врапперов). не говоря уж о том что код должен быть строго транзакционным (прощай vector\deque)


Если тов WolfHound действительно имеет дело с кластерами (я имел с ними дело всего пару лет и в довольно скромных масштабах) то он имеет полный объем гемора с последними пунктами.
И я с ним согласен т.к. на моей памяти был случай когда мы огребли больше всего проблемм из-за покртыой тестами маленькой либы которая страдала всеми описанными недостатками (кроме работы с оборудованием)

Здравствуйте, landerhigh, Вы писали:

L>Интересно отметить, что Ваше непонимание того, в чем реальная польза UT, растет в определенном смысле из "интергрированного отладчика". А что, действительно велик соблазн по-быстрому набросать код, расставить брякпоинты, пройтись по коду с парой входных значений и посмотреть, получили ли то, что хотели. Только вот Вы забываете, что компьютер — это такая машина для автоматизации рутины. Юнит-тесты помогают автоматизировать то, что Вы привыкли делать руками в "интегрированном отладчике", причем несмотря на необходимость писать дополнительный код теста, размер которого порой на порядок превышает тестируемый код, экономия времени и прочих ресурсов вроде нервов в итоге окзаывается колоссальной.

Правильный подход ИМХО — это Юнит-тесты + интегрированный отладчик. Как раз при прогоне юнит-теста вылетает исключение и мы тут же начинаем смотреть стек, переменные и т.п. в "интергрированном отладчике".

В общем не "unit tests vs отладчик", а "unit tests + отладчик".

WH>В том что тут было высказано мнение что Linux это что-то особенное... меж тем изучение линукса ничем не отличатся от изучения MFC или какой либо иной библиотеки.

Т.е. нет разницы между платформой и библиотекой?

Совершенно неверно.

Библиотеку можно учить _не всю_. Я от MFC брал то, что мне нужно, и не пользовался ничем другим.

С платформой так не выйдет. Делаешь вроде то же самое, что под виндами, а работает иначе.

Я уж не говорю про билд-платформу, ее поддержка тоже есть немалый труд.

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

R>Можно рассчитывать только на 1 вещь
R>-при полностью корректных данных на входе, скорее всего все работает

R>на что рассчитывать нельзя
R>-для многопоточных приложений никаких гарантий нет
R>-при корректных но не предусмотреных тестами данных никаких гарантий нет и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке специфическог юзкейса
R>-при некорректных данных на входе никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по анализу данных
R>-в нештатных ситуациях никаких гарантий нет — и анализ покрытия н юниттесты не скажут вам об этом если нет кода по обработке нештатных ситуаций
R>-написать юнит-тесты на отказ оборудования чисто физически проблематично, т.к. требует работы с железом\системными функциями через интерфейс(здравствуй куча врапперов). не говоря уж о том что код должен быть строго транзакционным (прощай vector\deque)

+1

Великолепный пост о том, чем плохи юнит-тесты, а значит, и test-driven development.

Я сам использую юнит-тесты только там, где цена баги крайне высока. Т.е., если там будет баг, то я упыхаюсь его вылавливать.

Пример: у меня было свое AVL tree, еще под ядро НТ4. По сей день есть. Все обвешано юнит-тестами.

С многонитевостью, кстати, довольно просто. Юнит-тестируется _под локами_, т.е. там, где все всегда однонитево. Потом юнит-тестированный код окружается локом — и вперед.

Зависимость от данных на входе у того когда тоже была слабая. Что там AVL tree структур из 2 чисел — менятся могут только 2 числа. Вот был бы это парсер...

Здравствуйте, Андрей Хропов, Вы писали:


АХ>Правильный подход ИМХО — это Юнит-тесты + интегрированный отладчик. Как раз при прогоне юнит-теста вылетает исключение и мы тут же начинаем смотреть стек, переменные и т.п. в "интергрированном отладчике".
АХ>В общем не "unit tests vs отладчик", а "unit tests + отладчик".
Так я о чем и говорю. Только у меня на последних трех проектах второе слагаемое в выражении "unit test + отладчик" постоянно норовило сократиться

Здравствуйте, trophim, Вы писали:

T>карандаш?

Гугль отменили?

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, landerhigh, Вы писали:

AJD>>>Если для документирования, а-ля doxygen, то это все шоткатами генерится, включая имя и параметры. А еще зачем?
L>>Банально в блоке \code..\endcode написать пример использования.

AJD>Обычно я этот кусок кода беру уже из готового рабочего примера, поэтому необходимость как-то не возникает
Увы, не всегда возможно.