Tonal

Автор не уточнил что именно он под С++ понимает. Ключевое слово finally есть в Borland C++ Builder и M$ С++/CLI. В Builder-е конструкция базируется именно над SEH-ем, и там как раз верно моё замечание про return. Как работает в M$ С++/CLI - я не разбирался. Но в любом случае не советовал бы делать return из finally введу неочевидности результата. :)

Ежели мне не изменяет мой склероз, то finally части в стандарте С++ нет, исключительно расширение M$. Причём return из finally останавливает раскрутку стека в случае наличия исключения. Т. е. я бы сильно не советовал так делать, бо изрядно неинтуитивное поведение. А вот return из try или catch - вполне понятная и удобная конструкция. :) За Objective-C - не в курсе, но для Delphi/Builder придерживался именно таких правил.

Все ответы не верны. В первом и втором случае у Вас нет «названий подразделений» которые требуются в заданиях. В третьем случае вы делаете необоснованное предположение об именах подразделений. Кроме того, либо вы допустили ошибку при прочтении и перепечатке заданий, либо она была в исходнике: по смыслу каждая таблица имеет 3 колонки. Для таблицы подразделений ORGANIZATION - это: * ORG_ID - уникальный ID подразделения (первичный ключ) * PARENT_ID - ID головного подразделения (вторичный ключ) * NAME - наименование организации Для таблицы сотрудников PERSON - это: * PERSON_ID - уникальный ID сотрудника (первичный ключ) * NAME - Имя сотрудника * ORG_ID - ID подразделения в котором работает сотрудник (вторичный ключ)

Открыть в LibreOffice, экспортировать как html/xhtml, выложить на сайт (возможно поправив вёрстку). Для других типов офисов и/или табличных процессоров по аналогии. :)

Человек, занимающийся наночастицами не знает матиматики и русского языка - оригинальненько. :)

Чота незаметно. :) http://www.google.com/trends/?q=c%2B%2B Добавь java и php: http://www.google.com/trends/?q=c%2B%2B,+j...date=all&sort=0 Наглядно видно общее снижение интереса. Причём интерес к java и php снижается быстрее чем к С++. Можно предположить, что при нынешнем тренде лет через 5 они сравняются. :)

Я за Python. :)

Есть такая игра на автобусных билетиках - "собери сотню". Между цифр номера билетика расставляются простые мат. операции и скобки чтобы в итоге получить 100. Правила можно варировать. Например можно или нет трактовать группу цифр как число, состав операций (включать степень или нет). Приятное упражнение при изучении нового языка. :)

C++, Pascal, Python, Haskell... Всё что угодно - какой лучше знаете. :)

Может проще в другой поток вынести? :)

Был бы повод... Да и повода то особо не требуется! :drink3:

любое кривое решение отличается от прямого тем, что порождает море проблем. всякие exit() и abort() затрудняют отладку/портирование/сопряжение с другим кодом/встраивание этого кода в качестве плагина. exit() и abort() это тоже палки-копалки доисторических времен, костыли из-за отсутсвия исключений и неудобства отработки глубоко расположенных ошибок. в современных программах не встречается. Так уже определись каким именно образом устанавливать код возврата из приложения. И языковый return retcode из main-а устаревший, и exit() библиотечный нелюб. :) А ежели говорить об исключениях, то что именно вернётся в систему при выбросе объекта? Большинство операционок ничего кроме int-а и не поймут. Кроме того, сама идея исключений - это обработка нештатных ситуаций, а окончить выполнение ранше может понадобится вполне штатно - зачем привликать для этого несвойственный механизм? что-то я это как-то проглядел. а можно пример? Variadic templates в C++0x. Слепить из этого кортеж - элементарно. В стандарт взяли кортежи из boost-а. По крайней мере в gcc давно оне. :) Они, кстати, тоже возвращают значение. Знаю. Но именно для win-довых gui-ёвин это значение наиболее часто игнорируют, да и выставляют не часто. :) Действительно - бред. char* - это тип данных в С/С++. юникод - стандарт кодирования символов к языкам С/С++ отношения не имеет. Т. е. преобразование между ними это как преобразование например сантиметров в int - может быть тривиально, а может требовать некоторых вычислений в зависимости от задачи. При минимально допустимом размере char в 8 бит мы вполне можем использовать utf-7 и utf-8 для оперирования с кодировкой unicode. Либо кодировать/декодировать самостоятельно опредилив используемое подмножество символов. Кроме того в ОС вполне может быть функция/функции для работы с аргументами не в char* или автоматической конвертации. В винде, например, есть функция winapi CommandLineToArgvW, а также специальная сигнатура для main: int _tmain(int argc, _TCHAR* argv[]) П. С. Ну и про «современные программы без ошибок» - спасибо, поржал. :)

В философии разработки С++ кроме выделенного были ещё несколько принципов - например добиваться максимальной совместимости с чистым С, где main обязан возвращать int. Т. е. поддерживать return errcode; всяко придётся. В последних стандартах и так послабление сделали - можно опускать return 0 в случае если это последняя инструкция в main и других return нет. Кроме того существует функция exit(res) и её аналоги для экстренного завершения минуя возврат из main. Про списки параметров мне гораздо больше импонирует решение с кортежами (туплами) чем с совмещением (перегрузкой) операторов. Кстати, в последних стандартах С++ кортежи входлят в STL и для их реализации как раз используется эллипс (шаблоны с переменным количеством параметров) :)

Видимо кроме Win-довых GUI-ёвин программ больше никаких не бывает? :) Да и коммандная строка не только в DOS-е живёт. Даже на винде полно суперудобных утилит не требующих гуйни. А уж о linux, и прочих bsd и говорить не приходится. И с unicod-ом в коммандной строке вполне просто работать. Особливо приимущество консоли проявляется когда пытаешся удалённо администрить сервера по слабым или ненадёжным каналам, да и на встроенные системы тоже непонятно зачем гуйню тащить. Так что и коммандная строка и коды возврата вполне насущная и общеупотребительная концепция. А на счёт того, нужно ли включать поддержку в сам язык или в библиотеки рантайма - так это на вкус и цвет. Вон в стандартном паскале, ввод/вывод (read/readln/write/writeln) тоже часть синтаксиса.

Без VS всё не просто, а очень просто: 1. Устанавливаем последний mingw-gcc 2. Прописываем путь к каталогу bin в системные пути 3. В любимом редакторе набираем текст проги в файл с исходником hello-w.cpp (я в Far-е небольшие пишу): 4. Компилируем: C:\mingw\work>g++ -Wall -ohello-w hello-w.cpp 5. Запускаем: C:\mingw\work>hello-w.exe Ежели в п3. в файл исходника вляпать ошибку, то после компиляции (п4) компилятор выдаст полный список претензий в консольное окно,а файла hello-w.exe не появится. Претензии (ошибки и предупреждения) нужно внимательно прочитать и исправить. Ежели что-то не ясно - запостить сюда вся выдачу компилятора и исходник. П. С. Да, кодировка исходного файла должна быть не unicode.