форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Программирование под UNIX (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Си или Си ++?"
Сообщение от Андрей (??) on 05-Авг-04, 14:25  (MSK)
Вопрос к гуру. Скажите в чём разница с и с++? Меня интересуют не особенности языка типа классы, и т.д., а отличие производительности программ, что выбрать для написания приложения, почему пользуются си если есть си++, велика ли разница производительности объектов и процедурного программирования? Искал в гугле по словам : производительность си и си++, на тему сравнения почти ничего ничего не нашёл:(. Если кто в этом вопросе разбирается - не сочтите за труд, расскажите, или ссылку дайте, буду очень признателен.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Си или Си ++?"
Сообщение от Vladislav Lazarenko on 05-Авг-04, 14:36  (MSK)
>Вопрос к гуру. Скажите в чём разница с и с++? >Меня интересуют не особенности языка типа классы, и т.д., а отличие производительности >программ, что выбрать для написания приложения, почему пользуются си если есть >си++, велика ли разница производительности объектов и процедурного программирования? Искал в >гугле по словам : производительность си и си++, на тему сравнения >почти ничего ничего не нашёл:(. Если кто в этом вопросе разбирается >- не сочтите за труд, расскажите, или ссылку дайте, буду очень >признателен. Каждой задаче свое решение. Сейчас как в мире OpenSource так и в коммерческом мире на Си новые проекты начинают редко ... В чем разница ? А в чем разница между веткой и тарелкой ? Единственное, что общее у си и си++ это то, что тарелка поддерживает всю функциональность ветки .. не более.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Си или Си ++?"
	Сообщение от Андрей (??) on 05-Авг-04, 16:48  (MSK)
	>Единственное, что общее у си и си++ это то, что тарелка поддерживает >всю функциональность ветки .. не более. Объяснил, конечно, классно, только нет аргументов никаких, в твоё обьяснение можно только верить(или не верить), но всё равно спасибо. Если найдёшь время, кинь ссылку какую нить по теме(если есть), буду благодарен.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	6. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 05-Авг-04, 16:57  (MSK)
	> >>Единственное, что общее у си и си++ это то, что тарелка поддерживает >>всю функциональность ветки .. не более. > >Объяснил, конечно, классно, только нет аргументов никаких, в твоё обьяснение можно только >верить(или не верить), но всё равно спасибо. Если найдёшь время, кинь >ссылку какую нить по теме(если есть), буду благодарен. Вы совершенно правы, сударь. Учитесь, браться мои, думайте, читайте: http://david.tribble.com/text/cdiffs.htm http://staff.bath.ac.uk/ensdnj/c_course/handout4/node1.html http://www.faqs.org/qa/qa-117.html P.S.: http://www.google.com/search?q=difference+between+c+and+c++&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8 Good luck!
		Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Си или Си ++?"
Сообщение от ihor on 05-Авг-04, 14:51  (MSK)
советую прочитать "Практику программирования" Б. Кернигана и Р. Пайка, там этому вопросу удулено достаточно внимания, причём эта проблема анализирется с разных сторон. + http://www.devlib.org/Programming/Languages/Comparison_and_Review/index.php + http://www.google.com/search?hl=en&lr=&ie=UTF-8&q=c#+java+c+++c+performance+comparison&btnG=Search
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Си или Си ++?"
	Сообщение от Андрей (??) on 05-Авг-04, 16:52  (MSK)
	>советую прочитать "Практику программирования" Б. Кернигана и Р. Пайка, >там этому вопросу удулено достаточно внимания, причём эта проблема анализирется с разных Где бы раздобыть книжку эту? мож есть в электронном виде? или ссылка?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	7. "Си или Си ++?"
	Сообщение от ihor on 05-Авг-04, 17:11  (MSK)
	я читал её в "бумажном" виде, она была выпущена в Росии в 2001 г. http://www.ozon.ru/context/detail/id/938233?partner=academic6
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	8. "Си или Си ++?"
	Сообщение от Андрей (??) on 05-Авг-04, 17:59  (MSK)
	нашёл книгу в бумажном виде, но где про это написано, расскажи что помнишь, пожалуйста. Спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	9. "Си или Си ++?"
	Сообщение от ihor on 05-Авг-04, 18:14  (MSK)
	тут вся соль в том, что авторы реализовали программу на разных языках и потом оценивали размер полученого кода, время потраченое на создание и скорость работы самиъ программ, причём с использованием разных библиотек и компиляторов. чтобы сделать сознательный выбор между C и С++, стоит прочитать главы, начиная с той где идёт реализация Маркова. скорость выполнения конечной программы -- это ещё не всё, да и она зависит от множетва факторов. важно учитывать ещё стоимость разработки  (в твоём случае это выльется во время, потраченное на придумывание/поиск/понимание алгоритмов, изучение предметной области и описание этой области (планирование и моделирование структур данных) в рамках выбраного языка, написание, отладку, переписывание и т.д. программы), потенциальное количество ошибок, кот. будут (и останутся после отладки) в твоей программе, наличие или отсутствие необходимых библиотек, доступность средств разработки и т.д. в любом случае, если хочешь писать хорошие программы, советую прочитать всё -- книга очень хорошая.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	10. "Си или Си ++?"
	Сообщение от Андрей (??) on 05-Авг-04, 18:22  (MSK)
	Спасибо, обязательно прочитаю.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Си или Си ++?"
	Сообщение от Андрей (??) on 05-Авг-04, 16:56  (MSK)
	Спасибо.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	11. "Си или Си ++?"
	Сообщение от dimus (ok) on 09-Авг-04, 10:30  (MSK)
	В мире не существует идеальных языков программирование - каждый в чем-то хорош, а в чем-то плох. И говорить о том, что один язык лучше или хуже другого нельзя, если не указываем ЦЕЛЕЙ, в которых он используется. Более конкретно, по С и С++: Вообще, с технической точки зрения, программа на С++ всегда будет чуть-чуть медленнее, чем программа на С, так как в С++ в функцию класса передается дополнительный параметр - this. Однако, и в этом я убедился на своем опыте, программа на С++ будет содержать гораздо меньше глюков, если конечно у программиста руки приделаны куда надо и тем концом :) Отсюда вывод: пиши логику работы на С++, а критичные по скорости функции на С или ассемблере. Этим ты добьешся наилучшего результата и по скорости, и по безглючности
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	12. "Си или Си ++?"
	Сообщение от Андрей (??) on 09-Авг-04, 11:41  (MSK)
	Спасибо, очень интересно. Это почти полностью совпадает с моим мнением, только непонятно, весь механизм обьектно-ориентированного пограммирования(имеется ввиду замедление, связанное с ним) сводится только к передаче this?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	13. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 09-Авг-04, 12:35  (MSK)
	>В мире не существует идеальных языков программирование - каждый в чем-то хорош, >а в чем-то плох. И говорить о том, что один язык >лучше или хуже другого нельзя, если не указываем ЦЕЛЕЙ, в которых >он используется. >Более конкретно, по С и С++: >Вообще, с технической точки зрения, программа на С++ всегда будет чуть-чуть медленнее, >чем программа на С, так как в С++ в функцию класса >передается дополнительный параметр - this. Однако, и в этом я убедился >на своем опыте, программа на С++ будет содержать гораздо меньше глюков, >если конечно у программиста руки приделаны куда надо и тем концом >:) Отсюда вывод: пиши логику работы на С++, а критичные по >скорости функции на С или ассемблере. Этим ты добьешся наилучшего результата >и по скорости, и по безглючности С чего ты взял ? :) Да, при организации класса в метод передается this как указатель на структуру данных, при точно таком же дизайне структур данных в Си ты будешь передавать указатель на структуру в функцию, которая работает с ней. Никакого замедления работы тут не будет. Единственное, что будет чуть-чуть замедлять программу - это вызов виртуальных функций, но ты этого не заметишь, всего-то на несколько тактов процессора больше. К тому же в C++ есть шаблоны, компилируется только тот код, который нужен, в Си такого нет, к примеру на MFC программа будет горазндо тяжелее, чем на  WTL ... (и MFC и WTL - это конечно Си++, но суть в шаблонах и не шаблонах)) В программах на СИ++ намного легче разобраться благодаря таким вещам к примеру, как визуальное моделирование, что к Си ну никак не прикрутишь. Как пример можно использовать Rational Rose (UML ...) Ну или поговорить к примеру о пространствах имен, enum в си так засоряет программу .. что хоть стреляйся. Если взять во внимание то, что Си++ включает в себя всю функциональность Си, то можно утверждать, что Си++ лучше Си, независимо от задачи. Конечно, если вам ничего больше, чем есть в си не нужно, можете использовать си++ без возможностей си++, а можно и си ...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	14. "Си или Си ++?"
	Сообщение от Андрей (??) on 10-Авг-04, 15:11  (MSK)
	Правильно ли я понял? Смысл вышесказанного(в контексте скорости, конечно) - программа на си++ медленнее чем программа на си за счёт использования виртуальных функций? И только ли виртуальные функции замедляют работу, или есть ещё что-то?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	15. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 10-Авг-04, 15:24  (MSK)
	>Правильно ли я понял? > >Смысл вышесказанного(в контексте скорости, конечно) - программа на си++ медленнее чем программа >на си за счёт использования виртуальных функций? > >И только ли виртуальные функции замедляют работу, или есть ещё что-то? В работе программы - да. Но это не особенности C++, ты можешь не использовать виртуальные функции, а можешь использовать, а вот в Си этого сделать просто нельзя. Если тебе интересно, то на Си++ программа будет работать быстрее ещё и потому, что алгоритмы стандартной библиотеки реализованы гораздо лучше, чем в Си. Взять к примеру qsort из Си и std::sort в Cи++. Что касается старта программы, тут могут быть нн пару миллисекунд задержки, связанные с очень длинными именами функций в .so библиотеках, написанных на C++. Но в соображениях скорости это мелочи, важно то, что .so на C++ занимают гораздо больше места, чем на Си. Ещё один minus Си++ в том, что методы линковки не стандартизированы. Вы не можете использовать со своим компилятором библиотеки, собраные другим компилятором... Быть может когда-то исправят, будем надеяться на ANSI... Надеюсь, что я не ущемил Си программистов, которым я тоже являюсь и был на нейтральной стороне. Спасибо за внимание))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	16. "Си или Си ++?"
	Сообщение от Андрей (??) on 10-Авг-04, 15:28  (MSK)
	>Надеюсь, что я не ущемил Си программистов, которым я тоже являюсь и >был на нейтральной стороне. > >Спасибо за внимание)) Думаю не ущемил (сужу по себе). Спасибо за столь интересный и аргументированный ответ. С уважением, Андрей.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	23. "Си или Си ++?"
	Сообщение от Андрей (??) on 12-Авг-04, 10:46  (MSK)
	>>Правильно ли я понял? >> >>Смысл вышесказанного(в контексте скорости, конечно) - программа на си++ медленнее чем программа >>на си за счёт использования виртуальных функций? >> >>И только ли виртуальные функции замедляют работу, или есть ещё что-то? > >В работе программы - да. Но это не особенности C++, ты можешь >не использовать виртуальные функции, а можешь использовать, а вот в Си >этого сделать просто нельзя. >Если тебе интересно, то на Си++ программа будет работать быстрее ещё и >потому, что алгоритмы стандартной библиотеки реализованы гораздо лучше, чем в Си. Сейчас читаю книгу Кернигана и Пайка. Так вот, там есть некоторое расхождение с твоими словами, точнее время выполнения программы с цепями Маркова на Си всего 0.30 секунд, а на Си++ 1.5, т.е. в 5 раз больше. Это никак не вяжется с тем, что ты сказал про скорость. Или есть подводные камни? Единственное обьяснение, которое приходит в голову, (если верить твоим словам), возможно, в силу возраста, видимо, в 2000 году компиляторы Си были совершеннее компиляторов Си++. Есть ли другое обьяснение? Может ли быть что прграммы на С++ в 5 раз медленнее чем на Си? ???????????????????
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	25. "Си или Си ++?"
	Сообщение от ihor on 12-Авг-04, 11:29  (MSK)
	прочитай дальше, там есть ответ.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	17. "Си или Си ++?"
	Сообщение от dimus (??) on 11-Авг-04, 15:28  (MSK)
	>С чего ты взял ? :) Да, при организации класса в метод >передается this как указатель на структуру данных, при точно таком же >дизайне структур данных в Си ты будешь передавать указатель на структуру >в функцию, которая работает с ней. Никакого замедления работы тут не >будет. А кто сказал, что дизайн на Си будет совпадать с дизайном на С++ >... можно утверждать, что Си++ лучше Си, независимо от задачи. Это не соответствует действительности.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	18. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 11-Авг-04, 15:49  (MSK)
	> >>С чего ты взял ? :) Да, при организации класса в метод >>передается this как указатель на структуру данных, при точно таком же >>дизайне структур данных в Си ты будешь передавать указатель на структуру >>в функцию, которая работает с ней. Никакого замедления работы тут не >>будет. > >А кто сказал, что дизайн на Си будет совпадать с дизайном на >С++ > Вы очень сильно не правы, относительно. Уточню. Дизайн не программы в целом, а дизайн структуры данных. Я лишь опровергаю ваше не совсем мудрое высказывание по поводу того, что Си++ медленее из за того, что в методы класса передается скрытый параметр this. Полная чушь! Чушь, чушь и ещё раз чушь! Объясняю популярно: Для Си: Пусть будет структура A и множество функций proc_a_1, proc_a_2 к примеру, такой дизайн... и чтобы что-то делать с этой структурой нужно будет передавать этим функциям указатель на неё. struct A {   int a, b, c; }; void proc_a_1(A *data) { ... } void proc_a_2(A *data) { ... } Для Си++: Вместо струткуры - это класс, простой класс ...  Функции стают методами этого класса (метод класса в си++ не имеет физического адреса, так что размер класса А будет таким же, как размер структуры А). Из пирмера кода ниже вы видите, что методам не передаются никаких папаметров кроме скрытого this, замедляющего программу.... Чем он замедляет ? Тут this, а в си  - A*. В чем проблема ? Я имел в виду именно этот дизайн. Ты тут лишь прав в том, что Си и Си++ - разные вещи, и дизайн программ отличается. class A {   public:    A() { }    ~A() { }     void proc_1() { ... }     void proc_2() { ... }   private:    int a, b, c; }; Как вывод - функциональность та же, но у Си++ другой синтаксис, более удобный, более открытый для интеграции и т.д. >>... можно утверждать, что Си++ лучше Си, независимо от задачи. > >Это не соответствует действительности. Чем ты это аргументируешь ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	19. "Си или Си ++?"
	Сообщение от Андрей (??) on 11-Авг-04, 16:13  (MSK)
	>>... можно утверждать, что Си++ лучше Си, независимо от задачи. > >Это не соответствует действительности. Почему ты так думаешь?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

20. "Си или Си ++ для того чтобы написать ОСь?!"
Сообщение от Lamr on 11-Авг-04, 17:23  (MSK)
Надо уметь писать и на том, и на другом. В любом случае разумный выбор можно сделать только понимая, какие механизмы ты используешь. Иначе получается религия и флуд. А мне вот интересно, почему весь FreeBSD написан на Си? Казалось бы, вот бы где развернуться могучей программистской мысли! Спроектировать удобные классы для сложнейших структур данных, которыми оперирует ядро! Написать легко модифицируемый код! Может это наследие тяжёлого бесклассового прошлого?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	21. "Си или Си ++ для того чтобы написать ОСь?!"
	Сообщение от Vladislav Lazarenko on 11-Авг-04, 17:29  (MSK)
	>Надо уметь писать и на том, и на другом. >В любом случае разумный выбор можно сделать только понимая, какие механизмы ты >используешь. Иначе получается религия и флуд. > Ты прав, я программист одной из ведущий украинский компаний, по долгу службы пишу на многих языках, не только на Си и Си++, хотя профессия у меня "Unix C++ SWE". Надеюсь мне можно высказывать тут свои скромные мысли ? >А мне вот интересно, почему весь FreeBSD написан на Си? >Казалось бы, вот бы где развернуться могучей программистской мысли! >Спроектировать удобные классы для сложнейших структур данных, которыми оперирует ядро! >Написать легко модифицируемый код! >Может это наследие тяжёлого бесклассового прошлого? Ты совершенно прав, это исторический фактор. К чему переписывать прекрасно работающий продукт с одного языка на другой ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	22. "Си или Си ++ для того чтобы написать ОСь?!"
	Сообщение от Lamr on 11-Авг-04, 20:00  (MSK)
	> Надеюсь мне можно высказывать тут >свои скромные мысли ? нет-нет, я не про вас, я советую начинающему. Надо программировать на всём. Тем более, что как писал Сам: "любая программа из книги Кернигана и Ритчи является программой на C++" >Ты совершенно прав, это исторический фактор. К чему переписывать прекрасно ра >с одного языка на другой ? Ну, линус вон написал заново 100 раз написанное - и ничего плохого. Не бедствует я бы сказал.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	26. "Си или Си ++ для того чтобы написать ОСь?!"
	Сообщение от Vladislav Lazarenko on 12-Авг-04, 11:34  (MSK)
	>> Надеюсь мне можно высказывать тут >>свои скромные мысли ? > >нет-нет, я не про вас, я советую начинающему. Надо программировать на всём. > >Тем более, что как писал Сам: >"любая программа из книги Кернигана и Ритчи является программой на C++" > >>Ты совершенно прав, это исторический фактор. К чему переписывать прекрасно ра >>с одного языка на другой ? > >Ну, линус вон написал заново 100 раз написанное - и ничего плохого. > >Не бедствует я бы сказал. Ну Торвальдс конечно уникальный человек, но он ничего не переписывал заново)) Он с нуля ... Да и С++ тогда не был так развит, а Линус чуть ли не на ассемблере ваял. Почитай его книгу "Just for fun!" :-)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	28. "Си или Си ++ для того чтобы написать ОСь?!"
	Сообщение от Lamr on 12-Авг-04, 12:24  (MSK)
	>с нуля ...   Не с нуля, а с minix >Да и С++ тогда не был так развит,   В 1993 году я читал Струструпа в уже русском переводе.   А первый компилятор появился, если не ошибаюсь, в 1987 году >а Линус чуть ли не на ассемблере ваял. Почитай его книгу >"Just for fun!" :-) Да не буду я читать "Винни-Пух и все,все,все" Годы уже не те
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	29. "Си или Си ++ для того чтобы написать ОСь?!"
	Сообщение от Vladislav Lazarenko on 12-Авг-04, 12:27  (MSK)
	>>с нуля ... >  Не с нуля, а с minix Minix была коммерческой ОС, если я не ошибаюсь и воровать Линус не стал, он просто изучал её .. и книгу Танненбауна кажется, а писал с нулика) >>Да и С++ тогда не был так развит, >  В 1993 году я читал Струструпа в уже русском переводе. > >  А первый компилятор появился, если не ошибаюсь, в 1987 году Первый компилятор и теперешний компилятор немного отличаются, не так ли ? :) > > >>а Линус чуть ли не на ассемблере ваял. Почитай его книгу >>"Just for fun!" :-) > > Да не буду я читать "Винни-Пух и все,все,все" > Годы уже не те А я наверное в душе молод, было очень интересно почитать по дороге на работу.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

24. "Си или Си ++?"
Сообщение от Андрей (??) on 12-Авг-04, 10:51  (MSK)
> Можно утверждать, что С++ лучше чем С независимо от задачи. Сейчас читаю книгу Кернигана и Пайка. Так вот, там есть некоторое расхождение с твоими словами, точнее время выполнения программы с цепями Маркова на Си всего 0.30 секунд, а на Си++ 1.5, т.е. в 5 раз больше. Это никак не вяжется с тем, что ты сказал про скорость. Или есть подводные камни? Единственное обьяснение, которое приходит в голову, (если верить твоим словам насчёт замедления за счёт длинных имён и виртуальных функций), возможно, в силу возраста, видимо, в 2000 году компиляторы Си были совершеннее компиляторов Си++. Есть ли другое обьяснение? Может ли быть что прграммы на С++ в 5 раз медленнее чем на Си? ???????????????????
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	27. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 12-Авг-04, 11:45  (MSK)
	>> Можно утверждать, что С++ лучше чем С независимо от задачи. > > Сейчас читаю книгу Кернигана и Пайка. Так вот, там есть некоторое >расхождение с твоими словами, точнее > >время выполнения программы с цепями Маркова на Си всего 0.30 секунд, а >на Си++ 1.5, т.е. в 5 раз больше. Это никак не >вяжется с тем, что ты сказал про скорость. Или есть подводные >камни? Единственное обьяснение, которое приходит в голову, (если верить твоим словам >насчёт замедления за счёт длинных имён и виртуальных функций), возможно, в >силу возраста, видимо, в 2000 году компиляторы Си были совершеннее компиляторов >Си++. > >Есть ли другое обьяснение? >Может ли быть что прграммы на С++ в 5 раз медленнее чем >на Си? > >??????????????????? Проблема в компиляторе, на тот момент, когда писали эту книгу (не помню какой год, сорри) Си++ был мало развит. В свое время я перечитал все самые лучшие книги о Си++, потом форумы .. на том и остановились. Профессиональным программистам не советую читать книги о Си++, потому что они на значительную часть отстают от настоящего времени ... Но профи в моем совете и не нуждаются, а начинающим советую читать все :)) Если бы СИ++ в 5 раз медленее работал, он бы не вышел на такой высокий уровень, хочу заметить, в коммерческих разработках Си не приветствуется, он является тяжестью прошлого, от которого постепенно избавляются.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	30. "Си или Си ++?"
	Сообщение от dimus (??) on 13-Авг-04, 08:30  (MSK)
	Уважаемый Владислав. Я не являюсь программистом крутой украинской компании, я просто люблю программировать и люблю разбираться, как работают программы. В своих исследованиях я обнаружил много фактов, которые сильно расходятся с Вашим уважаемым мнением Крутого Программиста на С++. Вы тут высказывались насчет передачи структур в функции. Так вот, уважаемый сэр, в С++, хотите вы или нет, а в любую НЕСТАТИЧЕСКУЮ функцию-член класса будет передан указатель this. Казалось бы пустяк, всего лишь пара push/pop. Но если этот   "пустяк" засунуть в цикл, то очень скоро обнаружится, что такой цикл работает несколько медленнее, чем хотелось бы. А на С мне самому решать, стоит ли что-то куда-то передовать. Например, я могу использовать глобальные структуры, раз уж Вам так приспичело работать с ними, и вообще ничего не передавать в функции. Естественно, что это будет довольно коряво, но _В_НЕКОТОРЫХК_СЛУЧАЯХ_ это будет работать просто прекрасно и очень быстро. Я сам по возможности использую С++, так как мне он очень нравится, однако как я уже говорил в первом сообщении, всякому языку свое место и время. Да, программу целиком, особенно если она большая, гораздо лучше писать на С++, чем на С - и код будет понятнее, и сопровождать его будет легче. Однако критичные по скорости фрагменты надо писать с использованием либо функций в стиле С, либо, что еще лучше, на ассемблере. С++ там не место. Как я уже писал выше, он больше подходит для организации логики программы. В заключение, уважаемый сэр, я расскажу Вам сказочку, которая правда была на самом деле, но абсолютно не стыкуется с Вашими высказываниями насчет скорости программ. Правда, речь там пойдет об Object Pascal, но если Вы потрудитесь взглянуть на ассемблерный листинг, то увидете, что различие не так уж велико. Так вот, один мой друг, очень большой любитель компьютерной графики и программирования, имел очень старый 486 компьютер c ISA видеокартой. Он на Object Pascal написал некую графическую программу, которая рисовала на экране трехмерные объекты. (Важное замечание: дело было под ДОС, и там, естественно, не было ни OpenGL, ни DirectX) Производительность программы его не удовлетворила. Он переписал критичные участки кода на ассемблере. Производительность выросла в три раза. Но и это его не удовлетворило. Мой друг заново переписал эти фрагменты, на этот раз выйдя на уровень портов ввода/вывода и проведя оптимизацию на уровне инструкций. Производительность возросла в семь раз, что очень огорчило моего друга, так как по расчетам она должна была вырасти до более больших значений. Расследование показало, что причиной такого разрыва стало упирание в предел пропускной способности для шины ISA. Мораль: 1) КАЖДОМУ ЯЗЫКУ СВОЕ МЕСТО И ВРЕМЯ. УНИВЕРСАЛЬНЫХ ЯЗЫКОВ НЕ СУЩЕСТВУЕТ. 2) ХОРОШИЙ ПРОГРАММИСТ ЛУЧШЕ ХОРОШЕГО КОМПИЛЯТОРА ЗНАЕТ, КАК УЛУЧШИТЬ СВОЮ ПРОГРАММУ С уважением, Димус
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	31. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 13-Авг-04, 13:12  (MSK)
	>Уважаемый Владислав. Я не являюсь программистом крутой украинской компании, я просто люблю >программировать и люблю разбираться, как работают программы. В своих исследованиях я >обнаружил много фактов, которые сильно расходятся с Вашим уважаемым мнением Крутого >Программиста на С++. Вы тут высказывались насчет передачи структур в функции. >Так вот, уважаемый сэр, в С++, хотите вы или нет, а >в любую НЕСТАТИЧЕСКУЮ функцию-член класса будет передан указатель this. Казалось бы >пустяк, всего лишь пара push/pop. Но если этот   "пустяк" >засунуть в цикл, то очень скоро обнаружится, что такой цикл работает >несколько медленнее, чем хотелось бы. А на С мне самому решать, >стоит ли что-то куда-то передовать. Например, я могу использовать глобальные структуры, >раз уж Вам так приспичело работать с ними, и вообще ничего >не передавать в функции. Естественно, что это будет довольно коряво, но >_В_НЕКОТОРЫХК_СЛУЧАЯХ_ это будет работать просто прекрасно и очень быстро. Димус, ты прав, но что ты мне доказываешь? Я не отрицаю, что класс - это набор функций работы со структурой, поэтому this будет передаваться ВСЕГДА в качестве указателя на эту структуру, если вы используете класс, вы уже соглашаетесь с этим, производительность от этого не падает, потому что вам так и надо! >Я сам по возможности использую С++, так как мне он очень нравится, однако >как я уже говорил в первом сообщении, всякому языку свое место >и время. Да, программу целиком, особенно если она большая, гораздо лучше >писать на С++, чем на С - и код будет понятнее, >и сопровождать его будет легче. Однако критичные по скорости фрагменты надо >писать с использованием либо функций в стиле С, либо, что еще >лучше, на ассемблере. С++ там не место. Как я уже писал >выше, он больше подходит для организации логики программы. По техническим характеристикам си++ - лишь абстракция, в основе лежит Си. что такое объектно ориентированное программирование ? Цитирую: Объектно-ориентированое программирование - это техника для программирования, парадигма для написания хороших решений для ряда проблем. Если термин "объектно-ориентированый язык программирования" означает что угодно, он должен подразумевать язык программиирования, механизм, который хорошо поддерживает объектно-ориенитрованый стиьл программирования. (c) Бьярн Страуструп Не более и не менее. Уже давно практикуется, что Си исходники компилируются Си++ компилятором. Ещё раз повторяю, что Си++ не медленее Си, он просто расширяет его функционалдьные возможности. P.S.: по пофоду НЕСТАТИЧЕСКУЮ функцию, ты не прав :) В Си++ static гораздо шире используется, чем в Си, но this никогда не передается скрытым параметром в функцию, только в метод. >В заключение, уважаемый сэр, я расскажу Вам сказочку, которая правда была на >самом деле, но абсолютно не стыкуется с Вашими высказываниями насчет скорости >программ. Правда, речь там пойдет об Object Pascal, но если Вы >потрудитесь взглянуть на ассемблерный листинг, то увидете, что различие не так >уж велико. Так вот, один мой друг, очень большой любитель компьютерной >графики и программирования, имел очень старый 486 компьютер c ISA видеокартой. >Он на Object Pascal написал некую графическую программу, которая рисовала на >экране трехмерные объекты. (Важное замечание: дело было под ДОС, и там, >естественно, не было ни OpenGL, ни DirectX) Производительность программы его не >удовлетворила. Он переписал критичные участки кода на ассемблере. Производительность выросла в >три раза. Но и это его не удовлетворило. Мой друг заново >переписал эти фрагменты, на этот раз выйдя на уровень портов ввода/вывода >и проведя оптимизацию на уровне инструкций. Производительность возросла в семь раз, >что очень огорчило моего друга, так как по расчетам она должна >была вырасти до более больших значений. Расследование показало, что причиной такого >разрыва стало упирание в предел пропускной способности для шины ISA. > >Мораль: >1) КАЖДОМУ ЯЗЫКУ СВОЕ МЕСТО И ВРЕМЯ. УНИВЕРСАЛЬНЫХ ЯЗЫКОВ НЕ СУЩЕСТВУЕТ. >2) ХОРОШИЙ ПРОГРАММИСТ ЛУЧШЕ ХОРОШЕГО КОМПИЛЯТОРА ЗНАЕТ, КАК УЛУЧШИТЬ СВОЮ ПРОГРАММУ > >С уважением, Димус А я расскажу сказку, как дед насрал в коляску. Мораль: грубо, зато не в тему ... Как, в принципе, и твоя сказка. Если у тебя есть технические доказательства, приводи их здесь, а сказки рассказывать не надо, под дос ещё мы не писали) Извините))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	32. "Си или Си ++?"
	Сообщение от proff (??) on 15-Авг-04, 00:42  (MSK)
	IMHO главное не на ЧЕМ писать программы, а КАК думать, перед тем как их писать. После того, как крепко подумаешь, может вполне оказаться, что писать ничего не нужно, т.к. уже все написано, отлажено и оформлено в прекраснейший код под BSD-лицензией. Си я люблю и стараюсь повсеместно (подчеркиваю, где это уместно) использовать потому, что на него ПРЕКРАСНО ложится FSA-логика. FSA -- Finite State Machine -- Конечный Автомат. После того, как задача представляется в виде FSA -- его (автомата) поведение, определяемое графом переходов, ВЕЛИКОЛЕПНО оптимизируется, опираясь на формальный математический базис, интуитивно (IMHO не для всех) понятный настолько же, насколько понятен реляционный подход к структурированию данных. К сожалению, из-за своей идеологической особенности (IMHO не каждому просто), FSA подход не получил столь широкое распространение, как, например, объектно-ориентированный. Но тем не менее, есть области, которые не могут себе позволить игнорировать его существование. Что за области? Критичные к ресурсам и времени выполнения. Например, ядра, серверные процессы, etc. Кто-то спрашивал, почему ядро *BSD на си? Да потому что думали его авторы в терминах FSA, вот по этому и на си. А по другому и думать не могли, иначе у них бы ничего не получилось.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	33. "Си или Си ++?"
	Сообщение от Lamr on 15-Авг-04, 21:52  (MSK)
	>IMHO главное не на ЧЕМ писать программы, а КАК думать, перед тем   Не КАК писать проограммы, а ЧЕМ думать, когда их пишешь :-))) >оформлено в прекраснейший код под BSD-лицензией.   Красивую песню хочеться спеть самому. Но кроме желания надо ещё возможность. Времени на песни, к сожалению, нет. Надо зарабатывать на жизнь. >Си я люблю и стараюсь повсеместно (подчеркиваю, где это уместно) >использовать потому, что на него ПРЕКРАСНО ложится FSA-логика.    Так меня очень удивляют подобные сабжу треда вопросы. Парень думает, что сэкономит время, направив усилия по нашим советам. Нихрена у него не выйдет!  А когда научиться программить, перестанет их задавать  :-))) >Критичные к ресурсам и времени выполнения. Например, ядра, серверные процессы, etc.   да, C++ из-за некоторой избыточности немного уступает C в экономичности потребления машинных ресурсов. Но, во-первых, уступает ненамного,  давая взамен мощнейшие механизмы типа обработки исключений etc,  во-вторых - сделает код более модернизируемым. Сейчас мало кто, кроме нескольких десятков гуру, сможет там разобраться настолько, чтобы безболезненно его править. >Кто-то спрашивал, почему ядро *BSD на си?    Я >по другому и думать не могли, иначе у них бы ничего >не получилось.   Ну, начал за здравие, кончил за упокой!   Да почему не получилось бы?   Описать свойства конечного автомата можно и на Прологе
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	34. "Си или Си ++?"
	Сообщение от proff (??) on 15-Авг-04, 23:35  (MSK)
	>  Не КАК писать проограммы, а ЧЕМ думать, когда их пишешь IMHO именно не ЧЕМ думать, а КАК. ЧЕМ -- место, куда едят; оно есть у каждого. а вот КАК -- абсолютно нет. КАК думать, т.е. качество мыслей -- ответ на многие, многие вопросы. Перед тем как задавать вопрос "Це или Це++?", спроси себя, в какой парадигме я думаю, представляю задачу, провожу ее декомпозицию, и скорее всего сам собой отпадет вопрос "что выбрать?". На каком языке писать -- будет уже понятно. >  Красивую песню хочеться спеть самому. Но кроме желания надо ещё >возможность. Времени на песни, к сожалению, нет. Надо зарабатывать на жизнь. Профессиональный программист, который не занимается стратегическим планированием своих знаний, не многого стоит. Знать где взять то, что не знаешь -- многое знать. Ответы на эти вопросы на работе искать нужно, за те самые деньги, которые платить радободатель, т.к. это ЯВЛЯЕТСЯ частью работы профессионала -- актуализировать свои знания и планировать свою карьеру. >   Так меня очень удивляют подобные сабжу треда вопросы. Парень >думает, что сэкономит время, направив усилия по нашим советам. Нихрена у >него не выйдет!  А когда научиться программить, перестанет их задавать > :-))) IMHO не стоит за парня судить -- а может этот треп, это наше брюзжание ему сэкономит время? Просится, конечно, сказать, что нет, но тем не менее... А может и не только ему? ;-) > >>Критичные к ресурсам и времени выполнения. Например, ядра, серверные процессы, etc. > >  да, C++ из-за некоторой избыточности немного уступает C в экономичности >потребления машинных ресурсов. Но, во-первых, уступает ненамного,  давая взамен мощнейшие >механизмы типа обработки исключений etc,  во-вторых - сделает код более >модернизируемым. Сейчас мало кто, кроме нескольких десятков гуру, сможет там разобраться >настолько, чтобы безболезненно его править. IMHO опять в разговор вмешались штампы. ;-( Дело не в том, что он "чуть чуть избыточней", или "имеет неявный параметр this", или "имеет ориентированные на большие проекты фичи" или еще что. Не в ЭТОМ дело. Не стоит лаять не на то дерево, говоря об этом. Все ЭТО -- несущественные детали. Настолько несущественные, что ими, IMHO, можно пренебречь, как пренебрегают бесконечным рядом числа ПИ. Речь о том, что Си плюс плюсы, Жабы и проч. мега-языки -- НЕ СПОСОБСТВУЮТ росту профессионализма разработчиков в области динамичного мышления. Вот ЭТО -- главное. Все остальное -- несущественный треп, который идет по сценарию тех, кто затеял спектакль со снижением стоимости разработки ПО путем понижения требований к профессионализму разработчиков. Да, это тот самый вездеССущий Copy+Paste Programming с целью снижения влияния человеческого фактора. ЭТО политика, в которой совершенно не учитываются мнения сведущих [в технических вопросах] людей. Типа мы тут в Москве накидаем квадратиков в розе [Rational Rose], а там в Бангалоре пусть макаки текст [программ] вколачивают. И пусть за все платит юзер -- он и так попал, так пусть попадет еще плотнее, нам то что? >>по другому и думать не могли, иначе у них бы ничего >>не получилось. > >  Ну, начал за здравие, кончил за упокой! >  Да почему не получилось бы? >  Описать свойства конечного автомата можно и на Прологе Не получилось потому что *BSD -- это UNIX, а си -- это кровеносная система, которая позволяет ему жить. UNIX живет в терминах си. Си был создан, чтобы на нем написать UNIX и именно по этому UNIX на нем и написан. ЗЫ: точнее переписать; для тех, кто не в курсе, сначала UNIX был написан на ассемблере
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	35. "Си или Си ++?"
	Сообщение от Vycheslaw on 16-Авг-04, 12:32  (MSK)
	Все проще.... С++ появился тогда когда пошла мода ООП Одному недоумку надо было написать ученую работу... Что бы получить ученое звание вот и придумал ООП. Остальные недоумки подхвалили эту идею. По сути проку от ООП ни какого ... запудривание мозгов не более. Куда больше проку от низходящего и восходящего программирования. Вообще на каком языке писать глупый вопрос, важно как писать. Еще важнее в чем писать (интерфейс,библиотеки и т.п.)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	36. "Си или Си ++?"
	Сообщение от klalafuda on 16-Авг-04, 12:50  (MSK)
	>Все проще.... >С++ появился тогда когда пошла мода ООП >Одному недоумку надо было написать ученую работу... >Что бы получить ученое звание вот и придумал ООП. >Остальные недоумки подхвалили эту идею. >По сути проку от ООП ни какого ... запудривание мозгов не более. я так понимаю, недоумок в данном случае - это Гради Буч ? // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	40. "Си или Си ++?"
	Сообщение от Soldier (??) on 17-Авг-04, 10:20  (MSK)
	Ндя. >Все проще.... >С++ появился тогда когда пошла мода ООП >Одному недоумку надо было написать ученую работу... >Что бы получить ученое звание вот и придумал ООП. Если этот человек недоумок, то вы тогда просто дебил. Извините конечно, на  самом деле я не считаю вас дебилом, но я не сомневаюсь, что IQ у этого "недоумка" на порядок выше вашего. >Остальные недоумки подхвалили эту идею. >По сути проку от ООП ни какого ... запудривание мозгов не более. > Точно, вот и мне запудрили блин, можно сказать зомбировали :))) >Куда больше проку от низходящего и восходящего программирования. Ну это наверное только для "доумков" :))) >Вообще на каком языке писать >глупый вопрос, важно как писать. >Еще важнее в чем писать (интерфейс,библиотеки и т.п.) Ага. Только на чем писать тут вроде никто не спрашивал - вопрос был в разнице между C и С++, но допустим, кто-то задал этот "глупый" вопрос и теперь мы его перезададим в соответсвии с вашими пожеланиями... Получаем: "Вопрос к гуру:" "Как писать программы? В чем писать, какой интерфейс использовать? " Вы считаете так оно звучит умнее?  :)))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	46. "Си или Си ++?"
	Сообщение от Vycheslaw on 18-Авг-04, 09:08  (MSK)
	> >Если этот человек недоумок, то вы тогда просто дебил. Извините конечно, >на  самом деле я не считаю вас дебилом, но я не >сомневаюсь, что IQ у этого >"недоумка" на порядок выше вашего. Объясните дебилу как ООП вам помогло на практике или продемонстрируйте преимущества ООП перед процедурным программированием. >>Вообще на каком языке писать >>глупый вопрос, важно как писать. >>Еще важнее в чем писать (интерфейс,библиотеки и т.п.) > >Ага. Только на чем писать тут вроде никто не спрашивал - вопрос >был в >разнице между C и С++, Начем писать читается между строк. Поясняют для тех людей у кого IQ высокий
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	49. "Си или Си ++?"
	Сообщение от Soldier (??) on 18-Авг-04, 10:33  (MSK)
	>Объясните дебилу как ООП вам помогло на практике >или продемонстрируйте преимущества ООП перед процедурным программированием. Вы помоему так увлеклись читкой между строк, что некоторые строки просто забыли прочитать:) Я ж дальше написал, что не считаю вас дебилом. И демонстрировать что-то должны как раз вы, а не я, поскольку я ни где и не утверждаю, что ООП cool, а все остальное sucks. Конечно  все зависит от задачи.  Хорошо, поробую :) Мне кажется, что ООП имеет преимущество когда имеем дело с большим количеством сходных,  но все таки в чем то отличающихся объектов. Классический пример - создание оболочки, типа TurboVision. Там имеем дело с большим количеством визуальных элементов, у которых  довольно много общего. Упрощено: создается базовый класс, у остальных переписываюися методы  handleevent, draw, getdata, setdata и т.д.. Далее заводится некое хранилище объектов и далее   совсем просто: получаем event, вызываем метод handleevent  каждого объекта и все. И никаких проблем  с созданием и вставкой новых визуальных компонентов. Мне такой подход. показался более удачным, чем мои предыдущие выкрутасы с C - код (source) стал гораздо более понятным и компактным. Быстродействие? Ну не заметит в данном случае простой человек разницу  даже между 0.001 и  0.000000000001 секунды. >Поясняют для тех людей у кого IQ высокий Это для кого? Для недоумка, придумавшего ООП? :) Знаете, в 30-летнем возрасте называть другого человека недоумком, при этом не будучи с ним знакомым  лично...   Ну как то несолидно, а?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	41. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 17-Авг-04, 10:23  (MSK)
	>Все проще.... >С++ появился тогда когда пошла мода ООП >Одному недоумку надо было написать ученую работу... >Что бы получить ученое звание вот и придумал ООП. >Остальные недоумки подхвалили эту идею. >По сути проку от ООП ни какого ... запудривание мозгов не более. > >Куда больше проку от низходящего и восходящего программирования. > >Вообще на каком языке писать >глупый вопрос, важно как писать. >Еще важнее в чем писать (интерфейс,библиотеки и т.п.) Мальчик, тебе интернет недавно провели, да ? Как ты узнал об этом сайте ? Кнопочку нашел на сайте порно картинок ? Я так и думал. Уйди отсюда.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	47. "Си или Си ++?"
	Сообщение от Vycheslaw on 18-Авг-04, 09:14  (MSK)
	>Мальчик, тебе интернет недавно провели, да ? Как ты узнал об этом >сайте ? Кнопочку нашел на сайте порно картинок ? Я так Да простит меня модератор. Мальчку 30 лет. Постоянный доступ к интернету более 4 лет. До это пользовался FIDO. Как узнал о сате через гуглю. К сожалению на данный сайт нет линков с порно сайтов. >и думал. Уйди отсюда. Обоснуйте почему должен уйти отсюда?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	48. "Си или Си ++?"
	Сообщение от Vycheslaw on 18-Авг-04, 09:15  (MSK)
	>Мальчик, тебе интернет недавно провели, да ? Как ты узнал об этом >сайте ? Кнопочку нашел на сайте порно картинок ? Я так Да простит меня модератор. Мальчку 30 лет. Постоянный доступ к интернету более 4 лет. До это пользовался FIDO. Как узнал о сате через гуглю. К сожалению на данный сайт нет линков с порно сайтов. >и думал. Уйди отсюда. Обоснуйте почему должен уйти отсюда?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	50. "Си или Си ++?"
	Сообщение от SergeiZz on 18-Авг-04, 13:20  (MSK)
	> >>Мальчик, тебе интернет недавно провели, да ? Как ты узнал об этом >>сайте ? Кнопочку нашел на сайте порно картинок ? Я так > >Да простит меня модератор. >Мальчку 30 лет. >Постоянный доступ к интернету более 4 лет. До это пользовался FIDO. >Как узнал о сате через гуглю. К сожалению на данный сайт нет >линков >с порно сайтов. >>и думал. Уйди отсюда. >Обоснуйте почему должен уйти отсюда? Вы не найдёте здесь того, чего ищите. Вам действительно больше подойдёт FIDO, нежели этот сайт. Стиль Ваших комментариев к проблеме "C или C++" именно фидошный, а не здешний. Только и всего. Это совет, а не ругань в Ваш адрес, поимите правильно.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	51. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 18-Авг-04, 13:22  (MSK)
	SergeiZz, respect! -- wbr, SnaiL
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	52. "Си или Си ++?"
	Сообщение от SergeiZz on 18-Авг-04, 13:32  (MSK)
	>SergeiZz, respect! > >-- wbr, SnaiL Thanks.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	37. "Си или Си ++?"
	Сообщение от Андрей (??) on 16-Авг-04, 14:22  (MSK)
	>ЗЫ: точнее переписать; для тех, кто не в курсе, сначала UNIX был >написан на ассемблере   Насколько мне известно, Unix был почти полностью написан на си (из 13 000 строк 800 на ассемблере - остальные на си). Откуда информация (для тех, кто не знает), что он был на ассемблере?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	38. "Си или Си ++?"
	Сообщение от proff (??) on 16-Авг-04, 15:54  (MSK)
	>>ЗЫ: точнее переписать; для тех, кто не в курсе, сначала UNIX был >>написан на ассемблере > >  Насколько мне известно, Unix был почти полностью написан на си >(из 13 000 строк 800 на ассемблере - остальные на си). >Откуда информация (для тех, кто не знает), что он был на >ассемблере? в то время как только появился UNIX, программы такого класса писали как правило на ассемблере. перенесение UNIX'а на си -- было очень рискованным шагом, который вызвал шквал критики. от такой трансформации UNIX стал пухлее и медленнее порядка трети. но это был осознаный шаг, который позволил ему быть портируемым на другие машины и понимаемым в университетской среде. насколько этот шаг был удачным -- судить нам по его более чем 30 летней истории. по этому я исказал, что UNIX был на си ПЕРЕПИСАН.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	39. "Си или Си ++?"
	Сообщение от Vycheslaw on 17-Авг-04, 07:16  (MSK)
	>в то время как только появился UNIX, программы такого класса писали как >правило на ассемблере. перенесение UNIX'а на си -- было очень рискованным >шагом, который вызвал шквал критики. > >от такой трансформации UNIX стал пухлее и медленнее порядка трети. но это >был осознаный шаг, который позволил ему быть портируемым на другие машины >и понимаемым в университетской среде. >насколько этот шаг был удачным -- судить нам по его более чем >30 летней истории. > >по этому я исказал, что UNIX был на си ПЕРЕПИСАН. Согласен с автором что си портить проще. Плюс время потраченное на разработку. Но как говоритья за все надо платить и как результат снижение производительности И потом кто сказал что в юниксе нет асемблера он был и еще долгое время отстанется тонкие места как писали так и будут писать на нем самом Более скажу в винде тоже самое. Мощь железа диктует быть асемблеру или нет.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

42. "Си или Си ++?"
Сообщение от Lamr on 17-Авг-04, 11:33  (MSK)
>Вопрос к гуру. Скажите в чём разница с и с++?   Господа!   Тема рискует занять первые места в рейтинге сайта.   Если не хотим, чтобы ни в чём не повинные люди читали наш флуд, надо закрываться. >что выбрать для написания приложения это зависит от задачи, которую решаете. У Страуструпа всё описано в самом начале. В любом случае правильный выбор вы сможете сделать только опираясь на собственный опыт. >почему пользуются си если есть си++,   Чтобы дураки спрашивали :-)   Другой цели особой нету :-))) > велика ли разница производительности объектов и процедурного программирования?   Нет.   Вы легко можете поставить самостоятельные опыты. Нарисуйте простой цикл на 100тыс. оборотов скажем копирования строки символов (в C++ для этого есть string) и сравните. Best Regards
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	43. "Си или Си ++?"
	Сообщение от proff (??) on 17-Авг-04, 21:09  (MSK)
	>  Тема рискует занять первые места в рейтинге сайта. >  Если не хотим, чтобы ни в чём не повинные люди >читали наш флуд, надо закрываться. ну и пусть занимает! поговорить о принципах -- важнейшая тема! не так ли? не принципы ли определяют наше бытие? > >>что выбрать для написания приложения > > это зависит от задачи, которую решаете. У Страуструпа всё описано в >самом начале. > В любом случае правильный выбор вы сможете сделать только опираясь на >собственный опыт. когда речь заходит о Це++ -- Страуструп тут не причем. точно так же, как Керниган и Ричи не причем, когда говорят о UNIX. их огромнейшая заслуга в том, что они начали спектакль. а вот как в нем "принимают" участие другие актеры, которые сейчас правят балом -- это не их "заслуга". они свое дело сделали. СПАСИБО ИМ ЗА ЭТО. >  Чтобы дураки спрашивали :-) >  Другой цели особой нету :-))) если вы написали это после четвертой пива -- то эта шутка не прошла. если нет -- я затрудняюсь ответить. скорее всего вы просто не можете думать ни в какой другой системе координат, кроме ООП. > >> велика ли разница производительности объектов и процедурного программирования? > >  Нет. >  Вы легко можете поставить самостоятельные опыты. Нарисуйте простой цикл на >100тыс. оборотов скажем копирования строки символов (в C++ для этого есть >string) и сравните. это полная чушь: аналог измусоленного до отвращения теста -- "HELO WORLD" на Java, который сравнивают по производительности с ЦЕ++. и получают ответ, не получить который не могут. производительность ОПРЕДЕЛЯЕТСЯ подходом к проектированию. инструментом же она определяется примерно в той же степени, в какой определяется скорость автомобиля моторным маслом. как я писал выше -- мега-языки типа ЦЕ++ и еще более худшие последователи, не способствуют развитию динамичного мышления. в отсутствии его (мышления) динамики все беды и проблемы, а не в ЦЕ++...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	44. "Си или Си ++?"
	Сообщение от Soldier (??) on 17-Авг-04, 22:30  (MSK)
	>как я писал выше -- мега-языки типа ЦЕ++ и еще более худшие >последователи, не способствуют развитию динамичного мышления. в отсутствии его (мышления) динамики >все беды и проблемы, а не в ЦЕ++... Вот чувствую, что мысль интересная, но ухватить никак не могу. Поэтому, если не затруднит, по-подробней, что вы понимаете по научным термином "динамическое мышление" и как "мега-языки типа ЦЕ++ и еще более худшие последователи"  не способствует его развитию.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	45. "Си или Си ++?"
	Сообщение от klalafuda on 17-Авг-04, 22:51  (MSK)
	[garbage snipped] >как я писал выше -- мега-языки типа ЦЕ++ и еще более худшие >последователи, не способствуют развитию динамичного мышления. в отсутствии его (мышления) динамики >все беды и проблемы, а не в ЦЕ++... извините, а можно как-то разумно это аргументировать ? например, ссылки на статьи уважаемых людей, проводимые исследования, работы и пр. ну или же своими словами но лучше конечно спокойно, без лишних эмоций. коротко, точно, емко и по существу. ps: написание предложений в верхнем регистре и свободное владение такими непростыми словосочетаниями как "динамическое мышление" еще не для всех является признаком однозначной неоспоримости написанного. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	55. "Си или Си ++?"
	Сообщение от proff (??) on 18-Авг-04, 15:07  (MSK)
	>извините, а можно как-то разумно это аргументировать ? например, ссылки на статьи >уважаемых людей, проводимые исследования, работы и пр. ну или же своими >словами но лучше конечно спокойно, без лишних эмоций. коротко, точно, емко >и по существу. > >ps: написание предложений в верхнем регистре и свободное владение такими непростыми словосочетаниями >как "динамическое мышление" еще не для всех является признаком однозначной неоспоримости >написанного. 2klalafuda&Soldier: ОК, коротко, точно, емко и по существу, как просил klalafuda. (только мне совершенно не понятно, как коротко, т.е. тезисно, может быть емко, да и к тому же, тем более, точно. это все равно что сказать "хотим маленькую, быструю, сверхмасштабируемую и чрезвычайно настраиваемую программу". наверное, возможно ублажить столь ортогональные "хотения". но как-то не тривиально для среднестатистического разума. далее. большими буквами написаны слова, на которых автор хотел заострить внимание. сложные слоовсочетания -- по просьбе читателей -- обосновываются.) динамичное мышление - мышление, не скованное стереотипами. я использовал это словосочетание без коментариев, потому что мне казалось, что оно интуитивно понятно. ошибся, был не прав, исправляюсь ;-) КАК мега-языки НЕ СПОСОБСТВУЮТ развитию динамичного мышления можно прочитать у многих авторов. я бы порекомендовал вот этих: 1. Ф.Брукс: "Мифический человеко-месяц", 2. Э.Йордан: "Смертельный марш", 3. К.К.Вальтух: "Информационная теория стоимости", 4. С.Г.Кара-Мурза: "Идеология и мать ее наука", 5. А.Коуберн: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения", 6. Р.Пёрсиг: "Субъекты, объекты, данные и ценности. О связи науки и исскуства", 7. Э.Дийкстра: Статьи и притчи. Особенно статьи "Ремесленник или ученый?" и "Два взгляда на программирование", 8. Э.Дийкстра: "Дисциплина программирования". все это, за исключением п.п. 3 и 4, можно найти в инете в электронном виде. (я бы порекомендовал еще с десяток книжец, но хотя бы прочите эти восемь -- это будет уже прорыв) далее по вопросам господ klalafuda&Soldier: как совершенно справедливо (IMHO) и неоднократно отмечал Эдсгер Дийкстра, программирование, это не наука (научить можно не любого), но и не ремесло (огромный пласт отчуждаемых знаний). т.е. программирование -- это программирование. и именно это его свойство (IMHO) является тем самым "тонким" местом, о которое сломано так много копий (научить, да что там, просто объяснить можно далеко НЕ КАЖДОМУ). при этом под "научить можно" многоуважаемый профессор Дийкстра имел ввиду не "Copy+Paste Programming", а достаточно высокий уровень профессионализма, который, перефразируя его слова, доступен далеко не всем.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	56. "Си или Си ++?"
	Сообщение от klalafuda on 18-Авг-04, 15:24  (MSK)
	> >(только мне совершенно не понятно, как коротко, т.е. тезисно, может быть емко, >да и к тому же, тем более, точно. вода - мокрая > это все равно >что сказать "хотим маленькую, быструю, сверхмасштабируемую и чрезвычайно настраиваемую программу". а в чем проблемы ? по заданному направлению - пожалуйста. >динамичное мышление - мышление, не скованное стереотипами. с не навязывает стереотипов, в то время как с++ навязывает ? можно пример. >КАК мега-языки НЕ СПОСОБСТВУЮТ развитию динамичного мышления можно прочитать у многих авторов. >я бы порекомендовал вот этих: >1. Ф.Брукс: "Мифический человеко-месяц", >2. Э.Йордан: "Смертельный марш", >3. К.К.Вальтух: "Информационная теория стоимости", >4. С.Г.Кара-Мурза: "Идеология и мать ее наука", >5. А.Коуберн: "Люди как нелинейные и наиболее важные компоненты в создании программного >обеспечения", >6. Р.Пёрсиг: "Субъекты, объекты, данные и ценности. О связи науки и исскуства", >7. Э.Дийкстра: Статьи и притчи. Особенно статьи "Ремесленник или ученый?" и "Два >взгляда на программирование", >8. Э.Дийкстра: "Дисциплина программирования". что-то читал, что-то нет. остановимся скажем на Бруксе. хорошая книга. веселая. действительно есть в сети в приличном русском переводе. кто хочет тот найдет. можно попросить ссылку (номер страницы) из данной книги, относящуюся к сковыванию мышления стереотипами, навязываемыми языком высокого уровня ? >как совершенно справедливо (IMHO) и неоднократно отмечал Эдсгер Дийкстра, программирование, это не >наука (научить можно не любого), но и не ремесло (огромный пласт >отчуждаемых знаний). т.е. программирование -- это программирование. и именно это его >свойство (IMHO) является тем самым "тонким" местом, о которое сломано так >много копий (научить, да что там, просто объяснить можно далеко НЕ >КАЖДОМУ). на днях тут пробегала ссылка на русский перевод статьи Дейкстры по поводу "HLL is Myth && Evil" хотя трактовка не столь координальна и отнюдь не о вреде high level languages как таковых. при всем уважении к профессору, лично мне конкретная статья показалась более чем легковесной. хотя это лишь одна из его статей.. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	57. "Си или Си ++?"
	Сообщение от SergeiZz on 18-Авг-04, 15:51  (MSK)
	>>КАК мега-языки НЕ СПОСОБСТВУЮТ развитию динамичного мышления можно прочитать у многих авторов. >>я бы порекомендовал вот этих: >>1. Ф.Брукс: "Мифический человеко-месяц", >>2. Э.Йордан: "Смертельный марш", >>3. К.К.Вальтух: "Информационная теория стоимости", >>4. С.Г.Кара-Мурза: "Идеология и мать ее наука", >>5. А.Коуберн: "Люди как нелинейные и наиболее важные компоненты в создании программного >>обеспечения", >>6. Р.Пёрсиг: "Субъекты, объекты, данные и ценности. О связи науки и исскуства", >>7. Э.Дийкстра: Статьи и притчи. Особенно статьи "Ремесленник или ученый?" и "Два >>взгляда на программирование", >>8. Э.Дийкстра: "Дисциплина программирования". У меня те же вопросы, что и у klalafuda. Поэтому и недоумения похожи. Список литературы весьма тенденциозен, согласен, но хотелось бы или поточнее (если не на конкретные высказывания, то на мысли), или услышать от Вас подробнее, чем раньше. Если я слишком абстрактно выражаюсь, то назовите самую главную на Ваш взгляд причину, в силу которой "мега-языки НЕ СПОСОБСТВУЮТ развитию динамичного мышления".
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	58. "Си или Си ++?"
	Сообщение от proff (??) on 18-Авг-04, 16:10  (MSK)
	>вода - мокрая а остальные свойства воды? их у нее КРАЙНЕ не мало... > >> это все равно >>что сказать "хотим маленькую, быструю, сверхмасштабируемую и чрезвычайно настраиваемую программу". > >а в чем проблемы ? по заданному направлению - пожалуйста. О! вы сразу же ограничиваете постановку задачи рамками! но мы то говорим о принципах -- рамки -- самые широкие. поэтому проблемы ставятся в самом широком контексте. следовательно одновременно коротко, четко и емко -- если мы не говорим в одном словаре -- не реально -- т.е. если говорить коротко, значит будет или не четко или не емко, а скорее всего и так и так. > >что-то читал, что-то нет. остановимся скажем на Бруксе. хорошая книга. веселая. действительно >есть в сети в приличном русском переводе. кто хочет тот найдет. >можно попросить ссылку (номер страницы) из данной книги, относящуюся к сковыванию >мышления стереотипами, навязываемыми языком высокого уровня ? у Брукса нет ни одной страницы со словами типа "С++ -- это плохо/хорошо". он пишет о другом. он пишет о том, что правильно иметь собственную башку на плечах, не загаженную различными идеологиями. когда я говорил о том, что мега-языки типа ЦЕ++ и более современные (Delphi, Java, C#) чему-то там не способствуют, я имел ввиду не то что они плохи как инструменты (я ими сам пользуюсь), а то, что они предоставляют слишком совершенные способы избежать трудностей. и именно этот факт является (при всей его положительности) тем самым тормозом, который "не позволяет" среднестатистическому программеру расти вне стереотипов, навеянных технологией. пример: опрашиваю у себя в конторе, куда я недавно пришел, ЦЕ++ программеров, находящихся на лучшем счету. какие вы, коллеги, знаете способы организации параллельных вычислений? они говорят, е-мое -- это ж как два пальца -- multithreading и все дела. и все спрашиваю? они говорят -- ну конечно, это ж cool! во-первых, почему cool -- не понятно? это ж не чикса на картинке. и во-вторых, почему ВСЕ? это далеко не все. это просто один из вариантов. не более и не менее. ну и в-третьих, самое главное, где вопрос "а какова задача?" > >на днях тут пробегала ссылка на русский перевод статьи Дейкстры по поводу >"HLL is Myth && Evil" хотя трактовка не столь координальна и >отнюдь не о вреде high level languages как таковых. при всем >уважении к профессору, лично мне конкретная статья показалась более чем легковесной. >хотя это лишь одна из его статей.. > уважаемый klalafuda -- речь не о вреде high level languages. ставить вопрос так -- равнозначно становится на сторону противников исторических изменений, которые называют прогрессом. т.е. все, начиная с ABS, сотовых телефонов и заканчивая мягкой туалетной бумагой -- гнобить, как подпорки, ухудшаюшие возможную душевную красоту. я лично -- не сторонник такого подхода. и тот же ЦЕ++ -- я не гноблю, я говорю лишь о том, что он (как, например, и АБС -- но это уже другая тема) не способствует расширению кругозора, а его-то как раз нужно расширять самым решительным образом. и вот как раз совершенство мега-языков этому не способствует. поэтому множество линивых людей этим не занимаются. <цитата> совершенство -- виновник застоя. </цитата>
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	59. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 18-Авг-04, 16:25  (MSK)
	Совершенство - виновник застоя, но нет ничего совершенного. Си++ намного совершенне Си, это безспорно. Рассмотрим сапу и мотыгу. В данном случае мотыга - это Си, а Си++ - сапа. Мы выходим на прополку, обрабатывать картошку (сложнейшую задачу). Вы, proff, не любите застой, стремясь к развитию своего динамического или как Вы там сказали мышления, к совершенству, берете в руку мотыгу. Я же беру сапу, я могу делать все так же, как Вы, а могу и большее, сапа лучше заточена. Мотыгой можно крутить, вертеть, как вы хотите, Вы добьетесь того же, что и я .. Картошка будет обработана. Но в некоторых местах сорняк не убран, а засыпан землею, вы вспотели, устали, потрачено слишком много усилий... Я мог бы устать так же как Вы, но устал меньше Вас, хотя и больше чем вот тот тракторист, обрабатывающий картошку плугом, C++ не совершенен, но дает больше возможностей использовать себя, свои навыки... P.S.: Delphi - это новый мега-язык последователь Цэ++ ? Цэ++ и Delphi - это то, на чем ты пишешь, я же пишу на C++.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	61. "Си или Си ++?"
	Сообщение от proff (ok) on 18-Авг-04, 16:56  (MSK)
	2Vladislav Lazarenko: 1. на "ты" мы с вами не переходили. 2. судя по тексту вашего поста, вы не поняли о чем идет речь. 3. вам лично мне более добавить нечего. если говорить о моем опыте программирования, то: 1. на Delphi я последний раз писал в 1999 году. 2. на С++ последний раз писал в 2001 году. 3. на С я в качестве хобби пишу небольшие проги для *BSD по сей день. 4. профессионально (т.е. за деньги) перестал кодировать с конца 2001 года, когда перешел в разряд архитекторов (проектировщиков) и консультантов. 5. считаю самым трудным языком (из всех мне известных) программирования -- русский, т.к. программы на русском языке, т.е. логически связанные непротиворечивые тексты, создавать мне лично труднее всего. слишком широки возможности и многогранны альтернативы.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	62. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 18-Авг-04, 17:00  (MSK)
	>2Vladislav Lazarenko: >1. на "ты" мы с вами не переходили. >2. судя по тексту вашего поста, вы не поняли о чем идет >речь. >3. вам лично мне более добавить нечего. > >если говорить о моем опыте программирования, то: >1. на Delphi я последний раз писал в 1999 году. >2. на С++ последний раз писал в 2001 году. >3. на С я в качестве хобби пишу небольшие проги для *BSD >по сей день. >4. профессионально (т.е. за деньги) перестал кодировать с конца 2001 года, когда >перешел в разряд архитекторов (проектировщиков) и консультантов. >5. считаю самым трудным языком (из всех мне известных) программирования -- русский, >т.к. программы на русском языке, т.е. логически связанные непротиворечивые тексты, создавать >мне лично труднее всего. слишком широки возможности и многогранны альтернативы. Отлично, я рад за тебя и поступаю так, как хочу. Отстаивая позиции языка си как архитектор, скажи, какие средства ты используешь, чтобы спроектировать программу на си? P.S.: Delphi да и вообще Borland - крайне неприемлимый solution в крупных американских проетках.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	63. "Си или Си ++?"
	Сообщение от klalafuda on 18-Авг-04, 17:13  (MSK)
	>>вода - мокрая >а остальные свойства воды? их у нее КРАЙНЕ не мало... ну и что ? ---cut--- только мне совершенно не понятно, как коротко, т.е. тезисно, может быть емко, да и к тому же, тем более, точно. ---cut--- постановка задачи: "дать короткое, тезисное, емкое и точное определение" точка. вас чем-то не устраивает приведенное решение? >>а в чем проблемы ? по заданному направлению - пожалуйста. >О! вы сразу же ограничиваете постановку задачи рамками! ---cut--- "хотим маленькую, быструю, сверхмасштабируемую и чрезвычайно настраиваемую программу". ---cut--- как вариант решения: штатный syslogd. вас оно чем-то не устраивает в свете поставленной вами задачи? о пункте "не ограниченную никакими рамками" речи не шло бо глупо это. > но мы то говорим >о принципах -- рамки -- самые широкие. поэтому проблемы ставятся в >самом широком контексте. следовательно одновременно коротко, четко и емко -- если >мы не говорим в одном словаре -- не реально -- т.е. >если говорить коротко, значит будет или не четко или не емко, >а скорее всего и так и так. мы говорим именно об этом: ---cut--- как я писал выше -- мега-языки типа ЦЕ++ и еще более худшие последователи, не способствуют развитию динамичного мышления. ---cut--- ни больше ни меньше. >у Брукса нет ни одной страницы со словами типа "С++ -- это >плохо/хорошо". >он пишет о другом. он пишет о том, что правильно иметь собственную >башку на плечах, не загаженную различными идеологиями. согласен, Брукс писал несколько о другом и уж заведомо не о "C vs C++". тогда причем тут Брукс ? в свете обсуждаемой темы. >когда я говорил о том, что мега-языки типа ЦЕ++ и более современные >(Delphi, Java, C#) чему-то там не способствуют, я имел ввиду не >то что они плохи как инструменты (я ими сам пользуюсь), а >то, что они предоставляют слишком совершенные способы избежать трудностей. > и именно >этот факт является (при всей его положительности) тем самым тормозом, который >"не позволяет" среднестатистическому программеру расти вне стереотипов, навеянных технологией. > >пример: >опрашиваю у себя в конторе, куда я недавно пришел, ЦЕ++ программеров, находящихся >на лучшем счету. какие вы, коллеги, знаете способы организации параллельных вычислений? >они говорят, е-мое -- это ж как два пальца -- multithreading >и все дела. и все спрашиваю? они говорят -- ну конечно, >это ж cool! > >во-первых, почему cool -- не понятно? это ж не чикса на картинке. >и во-вторых, почему ВСЕ? это далеко не все. это просто один >из вариантов. не более и не менее. ну и в-третьих, самое >главное, где вопрос "а какова задача?" но причем тут C и С++? пример мягко говоря неубедительный и к обсуждаемой теме имеет весьма отдаленное отношение. >я лично -- не сторонник такого подхода. и тот же ЦЕ++ -- я не гноблю, я говорю лишь о том, что он (как, например, и АБС -- но это уже другая тема) не способствует расширению кругозора, отлично. конкретный вопрос - почему? почему именно C++ и именно не способствует? > а его-то как раз нужно расширять самым решительным образом. и вот как раз совершенство мега-языков этому не способствует. простите, какой именно кругозор вы собираетесь расширять, что этому так вредят HLL? // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	69. "Си или Си ++?"
	Сообщение от proff (??) on 18-Авг-04, 18:50  (MSK)
	>>>вода - мокрая >>а остальные свойства воды? их у нее КРАЙНЕ не мало... > >ну и что ? приборы > >согласен, Брукс писал несколько о другом и уж заведомо не о "C >vs C++". тогда причем тут Брукс ? в свете обсуждаемой темы. > заголовок треда давно перестал быть отражением тем, в нем поднимаемых. лично я изначальное сравнение языков не проводил. речь шла о мировоззрении -- назовем его принципами, или как-то еще -- это не важно. такая широкая постановка вопроса могла бы закончится конструктивно -- обоюдоприемлемым обсуждением каких-то проблем, в случае оперирования в одном словаре. но в силу различных причин, словарь у каждого постера оказывается своим. и кроме как привести кусок кода, как это сделал Lamr -- для подавляющего большинства -- это верх конкретики -- ничего не остается делать. а код уже приведен, следовательно "все сказано". т.е. получается, что: 1. народ в этом треде (и я в том числе) может мыслить только в своем множестве стереотипов (башне из слоновой кости) 2. нет желания (а может и возможности) подумать, что есть и другие взгляды (стереотипы), возможно более интересные 3. разговоры, более абстрактные, чем текст на HLL -- не прокатывают 4. > /dev/null < /dev/zero -- вечный кайф > >но причем тут C и С++? пример мягко говоря неубедительный и к >обсуждаемой теме имеет весьма отдаленное отношение. > притом, что "язык формирует сознание". > >отлично. конкретный вопрос - почему? >почему именно C++ и именно не способствует? > потому что программист знает только: 1. синтаксис С++ 2. STL 3. какие-то свои и третьесторонние либы и больше ему ничего не нужно знать но этого категорически мало для того, чтобы стать профи. постоянные разнообразнейшие тренировки -- это критерий успеха. боец никогда не станет лучшим, если он будет долбить только одну грушу. нужны разносторонние соперники. > >простите, какой именно кругозор вы собираетесь расширять, что этому так вредят HLL? > я написал НЕ СПОСОБСТВУЮТ. перечитайте еще раз. каждый звук этих слов. это важно для понимания. ;-)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	72. "Си или Си ++?"
	Сообщение от klalafuda on 18-Авг-04, 19:45  (MSK)
	>заголовок треда давно перестал быть отражением тем, в нем поднимаемых. может, стоит тогда начать другую тему? чтобы заголовок не вводил в нездоровое заблуждение. назовем ее "о вечном или просто треп". >речь шла о мировоззрении -- назовем его принципами, или как-то еще -- >это не важно. >такая широкая постановка вопроса могла бы закончится конструктивно -- обоюдоприемлемым обсуждением каких-то >проблем, в случае оперирования в одном словаре. но в силу различных >причин, словарь у каждого постера оказывается своим. и кроме как привести тогда цели обсуждения? доказать, что при разработке ПО нужно думать головой? так это и ежу понятно. что нужно читать умные книжки и продвигаться вперед etc etc? всеми руками за. хотя еж опять же в курсе. >кусок кода, как это сделал Lamr -- для подавляющего большинства -- >это верх конкретики -- ничего не остается делать. а код уже >приведен, следовательно "все сказано". printf("Hello, world!") в большом цикле? он, очевидно, пошутил, а вы все так всерьез. >>но причем тут C и С++? пример мягко говоря неубедительный и к >>обсуждаемой теме имеет весьма отдаленное отношение. > >притом, что "язык формирует сознание". ну это у кого как. я предпочитаю сознательно выбирать язык от задачи, хотя, конечно, есть некоторые предпочтения. ну и что? мне так нравится. а кому-то нет. от этого на языке как классе мы поставим клеймо? >>отлично. конкретный вопрос - почему? >>почему именно C++ и именно не способствует? > >потому что программист знает только: >1. синтаксис С++ >2. STL >3. какие-то свои и третьесторонние либы >и больше ему ничего не нужно знать я так понимаю, это ключевые аргументы? что программисты - дураки в массе своей и весьма посредственно образованные люди? не согласен. или вы не встречали умных программистов? но даже если не встречали, это еще ровным счетом ничего не доказывает. >но этого категорически мало для того, чтобы стать профи. >постоянные разнообразнейшие тренировки -- это критерий успеха. боец никогда не станет лучшим, >если он будет долбить только одну грушу. нужны разносторонние соперники. отличная мысль! главное, оригинальная. наверное я дурак, что не понял всей красоты и естественности логики, которая приведет меня от нее к пониманию, что HLL отупляет людей. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	73. "Си или Си ++?"
	Сообщение от proff (??) on 18-Авг-04, 21:24  (MSK)
	>может, стоит тогда начать другую тему? чтобы заголовок не вводил в нездоровое >заблуждение. назовем ее "о вечном или просто треп". > в самом начале своих постов я так и писал: ТРЕП. видно это затерлось в памяти как неинтересное... > >тогда цели обсуждения? доказать, что при разработке ПО нужно думать головой? так >это и ежу понятно. что нужно читать умные книжки и продвигаться >вперед etc etc? всеми руками за. хотя еж опять же в >курсе. моя цель обсуждения -- обмен мнениями. что преследуют другие участники треда -- не знаю. > >printf("Hello, world!") в большом цикле? он, очевидно, пошутил, а вы все так >всерьез. > это был стеб. >>притом, что "язык формирует сознание". > >ну это у кого как. я предпочитаю сознательно выбирать язык от задачи, >хотя, конечно, есть некоторые предпочтения. ну и что? мне так нравится. >а кому-то нет. от этого на языке как классе мы поставим >клеймо? 0. не у кого как, а у всех; научно доказанная истина, 1. клеймо ставить не будем; думаю мы выше этого, 2. предпочтений не быть не может. противное -- лукавство. > >>>отлично. конкретный вопрос - почему? >>>почему именно C++ и именно не способствует? >> >>потому что программист знает только: >>1. синтаксис С++ >>2. STL >>3. какие-то свои и третьесторонние либы >>и больше ему ничего не нужно знать > >я так понимаю, это ключевые аргументы? что программисты - дураки в массе >своей и весьма посредственно образованные люди? не согласен. или вы не >встречали умных программистов? но даже если не встречали, это еще ровным >счетом ничего не доказывает. а вы с кем общаетесь? с бухгалтером чтоли? (нескромно так "про умных программистов"). по поводу общей массы -- именно это я и хотел сказать -- посредственность, Copy+Paste Programming. и говорю это не потому что от кого-то услышал/прочел, а потому что в этом цеху почти с десяток лет работаю и ничего кроме информационных систем делать по большому счету не умею (по этому, возможно, и работаю там до сих пор)... и если вы, уважаемый, представляете из себя интерес, то это не благодаря, а скорее вопреки С++. потому что у вас есть жажда новых знаний и рубежей. если бы этой нестерпимой жажды не было, как это обычно случается, были бы вы посредственностью как и многие, многие программисты. обновите в памяти "Два взгляда на программирование" Дийкстры. может быть станет понятно о чем я.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	74. "Си или Си ++?"
	Сообщение от Soldier (??) on 19-Авг-04, 09:02  (MSK)
	> в самом начале своих постов я так и писал: ТРЕП. видно это затерлось в памяти как неинтересное. Да, просмотрел, к сожалению. >моя цель обсуждения -- обмен мнениями. А по-моему вам то ли просто поговорить не с кем, то ли старые собеседники надоели :))) Слов умных много, а вот логики... Взять хотя бы ваше определение динамического мышления. Я, например, считаю, что мышление само по себе процесс динамический, потому и просил уточнить, что вы под этим словосочетанием понимаете. Оказывается, в вашем понимании это "мышление не скованное стереотипами". Но как вы сами писали выше, любое мышление, даже ваше, скованно в той или иной степени этими самыми стереотипам. Но тогда получается, что динамическое мышление, как таковое, сама по себе вещь невозможная.  А если динамическое мышление невозможно, то как его вообще можно затормозить? Чушь конечно. Но все ваше высказывания на мой взгляд такая же чушь (хотя может не дорос я), но обернутая в более красивые фразы (консультант все таки). Насчет вопроса, который вы задали неким ведущим программистам. Я не понимаю, а что вы хотели услышать? Вы и вопрос наверное задали в такой форме, чтоб получить нужный вам ответ. По моему это все равно, что подойти к человеку на улице и спросить - а чем вы разожгете костер, услышать ответ, что спичками или зажигалкой, и с довольным видом констатировать: у человека отсутствует  динамическое мышление - огонь  ведь можно разжечь  высеченной из камня искрой или сфокусировав солнечные лучи через лупу или еще каким нибудь способом, который нам подскажет наше сверх динамическое мышление. Ну и мое мнение, насчет всяких тормозов - дело тут не в С++ или C,  а просто в природе человеческой. То что вы сказали об С, С++ и МЕГА-ЯЗЫКАХ относительно мышления, можно сказать практически обо всем. И пример Владислава  насчет сапы и мотыги, как мне кажется, очень даже в тему. Ладно, всем всего наилучшего, кто как хочет, а я покидаю эту ветку.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	75. "Си или Си ++?"
	Сообщение от ihor on 19-Авг-04, 09:57  (MSK)
	> Оказывается, в вашем понимании это "мышление не скованное стереотипами". > Но как вы сами писали выше, любое мышление, даже ваше, скованно в той > > или иной степени этими самыми стереотипам. Но тогда получается, что > > > динамическое мышление, как таковое, сама по себе вещь > невозможная. возможная. и то, что от стереотипов никуда не деться тоже правда. динамика в том и состоит, чтобы постоянно сбрасывать (пытаться избавиться) от того набора, с которым я , напрмер, живу. в результате освобождается место, которое моментально заполняется новым набором. по большому счёту, я думаю, что это происходит таким образом потому, что наше восприятие, способность рассуждать построена на сравнениях с образцами. т.е. для того чтобы что-то увидеть и сказать: "это - корова", нужно иметь в голове шаблон этой самой коровы. затем, когда мы видим нечто, мы сравниваем это с разнообразными шаблонами, кот. у нас есть и выбираем наиболее подходящий вариант. зрение я привёл только для примера, по-моему, так-же работает и всё остальное. вот и получается, что у человека всегда есть море шаблонов (и от этого никуда не детьяс), но человек способен учиться, т.е. неким образом этот набор изменять. плохо, если человек останавливается, и говорит: "мне больше ничего не нужно менять. у меня уже есть самый совершенный набор шаблонов." в природе эволюция идёт таким-же образом. нет видов идеальных. есть виды, кот. хорошо приспособлены к определённым условиям. но беда в том (а может, счастье), что условия постоянно меняются, ничто вокруг на месте не стоит. а значит, миг наилучшего соответствия вида условиям очень короткий. дальше этот вид начинанает всё хуже и хуже соотв. миру, в котором он живёт и его вытесняют другие. я биология взял только в качестве примера, т.к. тоже самое верно и для социальной жизни, функционирования разнообразных систем и т.д. одним словом - "волновая природа мира". или как говорят китайцы - Инь и Ян.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	76. "Си или Си ++?"
	Сообщение от proff (??) on 19-Авг-04, 11:57  (MSK)
	2Soldier: самое простое, но в то же время не самое умное -- хлопнуть дверью, сказав что все в комнате идиоты. это первое. второе -- я говорил про ДИНАМИЧНОЕ мышление, а не про ДИНАМИЧЕСКОЕ. IMHO весьма разные вещи. а самое главное, я подводил именно к борьбе с собственными стереотипами, к работе над собой, над тем "как правильно думать" или "как принимать наилучшие решения". и я рад, что мне удалось это сделать -- довести разговор до кульминации. в разговор включились люди, которые думают похожим образом. я извиняюсь перед теми, кто счел мой треп сравнением Си с Си++ и проч. я не об этом писал. вы сами это придумали, глядя в мой текст. т.е. по сути это ваша неправота. но тем не менее я извиняюсь перед вами за ваше потерянное время, потому что текст -- мой. я так делаю, потому что уважаю читателя, какую бы подготовку он не имел.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	81. "Си или Си ++?"
	Сообщение от Soldier (??) on 20-Авг-04, 07:32  (MSK)
	>самое простое, но в то же время не самое умное -- хлопнуть >дверью, сказав что все в комнате идиоты. mailto: soldier70@mail.ru
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	53. "Си или Си ++?"
	Сообщение от SergeiZz on 18-Авг-04, 14:41  (MSK)
	>>  Тема рискует занять первые места в рейтинге сайта. >>  Если не хотим, чтобы ни в чём не повинные люди >>читали наш флуд, надо закрываться. > >ну и пусть занимает! Псле 130-150 сообщений на этом сайте вымрет практически любой поток, так что терпеть осталось не долго. >поговорить о принципах -- важнейшая тема! не так ли? Полностью с Вами согласен. Могу дого говорить на тему, но не стану... >как я писал выше -- мега-языки типа ЦЕ++ и еще более худшие >последователи, не способствуют развитию динамичного мышления. в отсутствии его (мышления) динамики >все беды и проблемы, а не в ЦЕ++... Не хочу сильно ругаться сгоряча, хотя подозреваю одну Вашу проблему. Напишите подробнее -- эта тема действительно интересна и думаю не только нам.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	54. "Си или Си ++?"
	Сообщение от Lamr on 18-Авг-04, 15:00  (MSK)
	>когда речь заходит о Це++ -- Страуструп тут не причем. точно так   поздравляю! приехали. А куда он делся?   К вашему сведению он ещё не умер и продолжает работать в AT&T   И развивать и стандартизировать C++. >как в нем "принимают" участие другие актеры, которые сейчас правят балом    ну, это наверное вы и ваши товарищи?    очень хотелось бы познакомиться с вашими разработками :-))    Это наверное как минимум новое слово в IT-индустрии :-)) >если вы написали это после четвертой пива -- то эта шутка не >прошла.   прошу прощения за грубость >последователи, не способствуют развитию динамичного мышления. в отсутствии его (мышления) динамики С++ НЕ ОТРИЦАЕТ ни структурное программирование, ни мышление, ни сам Си. C++ ДОПОЛНЯЕТ Си новыми конструкциями, которыми вас никто не заставляет пользоваться, если динамика мышления не позволяет.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

60. "Си или Си ++?"
Сообщение от Arifolth (ok) on 18-Авг-04, 16:38  (MSK)
дааа тред скоро так распухнет что его некуда будет деть =)) самое главное - ни конца ни края не видно =) лично я считаю что для некоторых небольших задач подходит C для задач поглобальнее - C++ а вообще, судари, о вкусах ни спорят... сколько людей - столько мнений
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	64. "Си или Си ++?"
	Сообщение от Lamr on 18-Авг-04, 18:13  (MSK)
	>дааа >тред скоро так распухнет что его некуда будет деть =))    Вообще-то чел попросил конкретно данные сравнительного тестирования на потребляемые ресурсы прог на Си и таких же прог на С++.   Видимо ни у кого из выступавших здесь таких данных нет.   У меня нету тоже, да и некогда этим заниматься.   Из любопытства я написал и скомпилировал HELLO,WORLD на 10тыс итераций    Получилось 4317 байт на Си и 5012 байт на C++.    time a.out показывает    на Си  - 47 сотых секунды    на С++ - 58 сотых секунды    (среднее после 3-4 запусков)    gcc 2.95.4 --------------------------------------- #include <stdio.h> int main() { int i; for(i=10000; i>0; i--) printf("Hello, world\n"); } ----------------------------------------- #include <iostream> int main() { int i; for(i=10000; i>0; i--) cout << "Hello, world" << endl; } ----------------------------------------------- Может, спасибо кто скажет, я на эту байду целый час драгоценный потратил :-)))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	65. "Си или Си ++?"
	Сообщение от Андрей (??) on 18-Авг-04, 18:16  (MSK)
	> Может, спасибо кто скажет, я на эту байду целый час драгоценный >потратил > > :-))) Спасибо. :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	66. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 18-Авг-04, 18:20  (MSK)
	>>дааа >>тред скоро так распухнет что его некуда будет деть =)) > >   Вообще-то чел попросил конкретно данные сравнительного тестирования на потребляемые >ресурсы прог на Си и таких же прог на С++. >  Видимо ни у кого из выступавших здесь таких данных нет. > >  У меня нету тоже, да и некогда этим заниматься. >  Из любопытства я написал и скомпилировал HELLO,WORLD на 10тыс итераций > >   Получилось 4317 байт на Си и 5012 байт на >C++. >   time a.out показывает >   на Си  - 47 сотых секунды >   на С++ - 58 сотых секунды >   (среднее после 3-4 запусков) >   gcc 2.95.4 >--------------------------------------- >#include <stdio.h> >int >main() >{ > int i; > > for(i=10000; i>0; i--) >  printf("Hello, world\n"); >} >----------------------------------------- >#include <iostream> > >int >main() >{ > int i; > > for(i=10000; i>0; i--) >  cout << "Hello, world" << endl; >} >----------------------------------------------- > > Может, спасибо кто скажет, я на эту байду целый час драгоценный >потратил > > :-))) А я пасиба не скажу, потмоу что ввод-вывод Си++ библиотеки часто оказывается медленей, чем чистой Си. В этом плане там нагородили, и, часто, никто из Си++ программистов iostream не использует. К тому же это очень зависит от версии STL, которую ты используешь. Идея конечно хорошая, но тут весь прикол в имплиминтации. Чисто на Си++ имплементация сишного ввода-вывода не была бы хуже. К примеру, это все равно, что сравнивать производительность языка Си и Си++ в парсинге XML базы данных, используя совершенно разные библиотеки. WBR.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	67. "Си или Си ++?"
	Сообщение от klalafuda on 18-Авг-04, 18:25  (MSK)
	>А я пасиба не скажу, потмоу что ввод-вывод Си++ библиотеки часто оказывается >медленей, чем чистой Си. В этом плане там нагородили, и, часто, >никто из Си++ программистов iostream не использует. К тому же это >очень зависит от версии STL, которую ты используешь. Идея конечно хорошая, >но тут весь прикол в имплиминтации. Чисто на Си++ имплементация сишного >ввода-вывода не была бы хуже. К примеру, это все равно, что >сравнивать производительность языка Си и Си++ в парсинге XML базы данных, >используя совершенно разные библиотеки. пардон, а смысл использовать в С++ какие-то неродные библиотеки? вы и память тогда выделять будете через malloc() ? помесь C && C++ похожа на помесь ежика с ужом и на порядок худе, чем взятые оба вместе и по отдельности. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	68. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 18-Авг-04, 18:38  (MSK)
	>пардон, а смысл использовать в С++ какие-то неродные библиотеки? вы и память >тогда выделять будете через malloc() ? помесь C && C++ похожа >на помесь ежика с ужом и на порядок худе, чем взятые >оба вместе и по отдельности. > >// wbr Очевидно, что выбран не самый хороший пример для сравнения. Тут сравнивается конкретная подсистема ввода-вывода. Так же не справедливо я могу привести пример того, что std::sort в C++ лучше qsort в Си.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	70. "Си или Си ++?"
	Сообщение от Lamr on 18-Авг-04, 19:03  (MSK)
	>Очевидно, что выбран не самый хороший пример для сравнения.    Это просто пример.    Возвращаясь к идее написания ядра UNIX на С++ могу предположить, что требовательность к ресурсам вырастет максимум на 20-30%. Взамен получиться горазда более доступный для понимания и модернизации код, который можно будет целыми классами и шаблонами использовать в разных вариантах ОС.   Скорость разработки возрастёт многократно.   Надёжность (хотя куда уж надёжнее?)   Могу сослаться на новость, в которой несчастный Линус не смог даже назвать ядро как ему нравиться, пришлось подстраивать своё хочу под сделанное. :-))   Почитайте в новостях :-))))
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	71. "Си или Си ++?"
	Сообщение от klalafuda on 18-Авг-04, 19:27  (MSK)
	>Очевидно, что выбран не самый хороший пример для сравнения. Тут сравнивается конкретная >подсистема ввода-вывода. Так же не справедливо я могу привести пример того, >что std::sort в C++ лучше qsort в Си. пардон, вы не делаете разницы между языком, стандартными библиотеками и их конкретной реализацией ? почему std::sort() должен быть быстрее, чем qsort() ? или наоборот ? что, это явно диктуется языком или стандартом на библиотеки ? производительность зависит от конкретной реализации компилятора и окружения и абстрактно сравнивать производительность "языков С и С++", а тем более библиотек, мягко говоря глупо. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	77. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 19-Авг-04, 12:23  (MSK)
	>>Очевидно, что выбран не самый хороший пример для сравнения. Тут сравнивается конкретная >>подсистема ввода-вывода. Так же не справедливо я могу привести пример того, >>что std::sort в C++ лучше qsort в Си. > >пардон, вы не делаете разницы между языком, стандартными библиотеками и их конкретной >реализацией ? почему std::sort() должен быть быстрее, чем qsort() ? или >наоборот ? что, это явно диктуется языком или стандартом на библиотеки >? Почему он должен быть быстрее - я не знаю, но то, что он быстрее - это факт. >производительность зависит от конкретной реализации компилятора и окружения и абстрактно >сравнивать производительность "языков С и С++", а тем более библиотек, мягко >говоря глупо. Совершенно согласен. В одном из постов я приводил конкретные примеры, что в Си лучше Си++ и наоборот. > >// wbr А этим постом я лишь подчеркнул глупость сравнения производительности языков тем тестом, за который молодой человек потребовал сказать ему спасибо. \\
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	78. "Си или Си ++?"
	Сообщение от Андрей (??) on 19-Авг-04, 12:37  (MSK)
	>Почему он должен быть быстрее - я не знаю, но то, что >он быстрее - это факт. Извините, я не допонял предложение. Вы не знаете почему std::sort() быстрее, чем qsort()? Поясните мысль, пожалуйста.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	79. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 19-Авг-04, 12:43  (MSK)
	>>Почему он должен быть быстрее - я не знаю, но то, что >>он быстрее - это факт. > >Извините, я не допонял предложение. Вы не знаете почему std::sort() быстрее, чем >qsort()? >Поясните мысль, пожалуйста. Я не знаю, почему qsort() ДОЛЖЕН быть быстрее std::sort() и наоборот. А почему std::sort() быстрее - я, конечно, знаю. qsort() - не идеальная функция сортировки, отсутствует сохранность типов (type safety), в качестве функции сравнения передается указатель на ф-ю (Comparison function call overhead), нет возможности для встраивания операций сравнения и т.п. (No opportunity for compiler inlining etc.). + существует выбор функций сортировки, в зависимости от задачи, например partial_sort, partition.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	80. "Си или Си ++?"
	Сообщение от Андрей (??) on 19-Авг-04, 12:55  (MSK)
	Извините. :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	82. "Си или Си ++?"
	Сообщение от HISH (ok) on 21-Авг-04, 01:22  (MSK)
	>>Очевидно, что выбран не самый хороший пример для сравнения. Тут сравнивается конкретная >>подсистема ввода-вывода. Так же не справедливо я могу привести пример того, >>что std::sort в C++ лучше qsort в Си. > >пардон, вы не делаете разницы между языком, стандартными библиотеками и их конкретной >реализацией ? почему std::sort() должен быть быстрее, чем qsort() ? или >наоборот ? что, это явно диктуется языком или стандартом на библиотеки >? производительность зависит от конкретной реализации компилятора и окружения и абстрактно >сравнивать производительность "языков С и С++", а тем более библиотек, мягко >говоря глупо. > >// wbr Если у Вас спросят: "Что быстрее - Си или Java", Вы тоже скажете, что Java может быть быстрее, все зависит от реализации? Человек же спрашивал не для каких-то своих философских нужд, а, очевидно, для практических целей.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	83. "Си или Си ++?"
	Сообщение от klalafuda on 21-Авг-04, 11:24  (MSK)
	>Если у Вас спросят: "Что быстрее - Си или Java", Вы тоже >скажете, что Java может быть быстрее, все зависит от реализации? Человек >же спрашивал не для каких-то своих философских нужд, а, очевидно, для >практических целей. спрашивая для практических целей, обычно указывают производителя и версию OS, компилятора, libc/libstdc++ и пр. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	84. "Си или Си ++?"
	Сообщение от Андрей (??) on 21-Авг-04, 11:31  (MSK)
	>Если у Вас спросят: "Что быстрее - Си или Java", Вы тоже >скажете, что Java может быть быстрее, все зависит от реализации? Человек >же спрашивал не для каких-то своих философских нужд, а, очевидно, для >практических целей. Честно говоря, я не настолько асс в программировании (видимо, в отличие от многих здесь), и вопрос был задан, в надежде получить больше информации. И я её получил (спасибо всем).   Поясню вопрос. Как я понял, Си++ это надмножество Си. Из этого следует(как я понимаю), что Си++ включает в себя Си _полностью_ (поправте меня, если ошибаюсь), т.е., говоря по-русски на Си++ можно сделать _всё_, что можно сделать на Си и ещё можно делать проще то, что на Си сделать труднее (так?). Логично (на мой взгляд) использовать Си++ (исходя из этих рассуждений).   Так я думал. Но шло время, и я встречал доказательства того, что очень многие люди программируют на Си. Возникло подозрение, что либо я ошибся в рассуждениях, либо знаю не всё, либо оба варианта сразу. Я попытался найти ответ сам, но ввиду нехватки времени, а может и способностей, не нашёл, и решил обратиься с вопросом к сведующим людям, а где их найти? Логично (на мой взгляд) было искать здесь.   Пока я нашёл два аргумента в "пользу" Си: 1. Линковка стандартизована(в лтличии от Си++), что важно для переносимости (поправте, если ошибаюсь). 2. Логика конечных автоматов не требует ни одного из средств Си++(про это (логику) слышу всего раз третий-четвёртый, поэтому если не прав - простите и поправте). (Зачем использовать эксковатор для того, чтобы набрать ведро песка? Это явный перебор, причём гораздо лучше и быстрее лопатой). К сожалению, по поводу одного из важнейших факторов -- скорости выполнения приложения ничего конкретного узнать не удалось, только слова(и пример, за который спасибо, на самом деле, на мысли наводит). Посему две просьбы. 1. Если ошибся - поправте. 2. Если кто узнает что-нибудь стоящее по теме -- киньте ссылку на мыло aklaus@list.ru. Буду очень признателен. (Если кто надумает писать, пожалуйста пометьте тему "Си или Си++"). Спасибо. С уважением, Андрей.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

85. "Си или Си ++?"
Сообщение от Андрей (??) on 21-Авг-04, 11:34  (MSK)
>Если у Вас спросят: "Что быстрее - Си или Java", Вы тоже >скажете, что Java может быть быстрее, все зависит от реализации? Человек >же спрашивал не для каких-то своих философских нужд, а, очевидно, для >практических целей. Честно говоря, я не настолько асс в программировании (видимо, в отличие от многих здесь), и вопрос был задан, в надежде получить больше информации. И я её получил (спасибо всем).   Поясню вопрос. Как я понял, Си++ это надмножество Си. Из этого следует(как я понимаю), что Си++ включает в себя Си _полностью_ (поправте меня, если ошибаюсь), т.е., говоря по-русски на Си++ можно сделать _всё_, что можно сделать на Си и ещё можно делать проще то, что на Си сделать труднее (так?). Логично (на мой взгляд) использовать Си++ (исходя из этих рассуждений).   Так я думал. Но шло время, и я встречал доказательства того, что очень многие люди программируют на Си. Возникло подозрение, что либо я ошибся в рассуждениях, либо знаю не всё, либо оба варианта сразу. Я попытался найти ответ сам, но ввиду нехватки времени, а может и способностей, не нашёл, и решил обратиься с вопросом к сведующим людям, а где их найти? Логично (на мой взгляд) было искать здесь.   Пока я нашёл два аргумента в "пользу" Си: 1. Линковка стандартизована(в лтличии от Си++), что важно для переносимости (поправте, если ошибаюсь). 2. Логика конечных автоматов не требует ни одного из средств Си++(про это (логику) слышу всего раз третий-четвёртый, поэтому если не прав - простите и поправте). (Зачем использовать эксковатор для того, чтобы набрать ведро песка? Это явный перебор, причём гораздо лучше и быстрее лопатой). К сожалению, по поводу одного из важнейших факторов -- скорости выполнения приложения ничего конкретного узнать не удалось, только слова(и пример, за который спасибо, на самом деле, на мысли наводит). Посему две просьбы. 1. Если ошибся - поправте. 2. Если кто узнает что-нибудь стоящее по теме -- киньте ссылку на мыло aklaus@list.ru. Буду очень признателен. (Если кто надумает писать, пожалуйста пометьте тему "Си или Си++"). Спасибо. С уважением, Андрей.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	86. "Си или Си ++?"
	Сообщение от proff (??) on 21-Авг-04, 13:08  (MSK)
	>Как я понял, Си++ это надмножество Си. Из этого следует(как я понимаю), >что Си++ включает в себя Си _полностью_ (поправте меня, если ошибаюсь), >т.е., говоря по-русски на Си++ можно сделать _всё_, что можно сделать >на Си и ещё можно делать проще то, что на Си >сделать труднее (так?). Логично (на мой взгляд) использовать Си++ (исходя из >этих рассуждений). Формально, С++ действительно включает в себя синтаксис С. Но идеологически, это абсолютно другой язык. И то, что для абсолютно другого языка Страуструпом был выбран С'ишный синтаксис (IMHO) было ошибкой. От этого концептуально язык не выиграл, а проиграл. Исходя из такой концептуальной разницы (разные подходы в проектировании) говорить о том, что С++ надмножество С -- (IMHO) не совсем корректно. >  Так я думал. Но шло время, и я встречал доказательства >того, что очень многие люди программируют на Си. Возникло подозрение, что >либо я ошибся в рассуждениях, либо знаю не всё, либо оба >варианта сразу. Я попытался найти ответ сам, но ввиду нехватки времени, >а может и способностей, не нашёл, и решил обратиься с вопросом >к сведующим людям, а где их найти? Логично (на мой взгляд) >было искать здесь. >  Пока я нашёл два аргумента в "пользу" Си: >1. Линковка стандартизована(в лтличии от Си++), что важно для переносимости (поправте, если >ошибаюсь). >2. Логика конечных автоматов не требует ни одного из средств Си++(про это >(логику) слышу всего раз третий-четвёртый, поэтому если не прав - простите >и поправте). (Зачем использовать эксковатор для того, чтобы набрать ведро песка? >Это явный перебор, причём гораздо лучше и быстрее лопатой). > с точки зрения программиста -- это (IMHO) именно так. с точки зрения хакера (в старом понимании этого слова, т.е. мастера программистского дела) -- это не так, потому что инструмент для хакера -- вещь культовая. и если для "нормального" программера вышепреведенный пример с экскаватором всего-лишь пример, то для хакера -- очень существенный повод (не использовать экскаватор для насыпания песка в ведро). >К сожалению, по поводу одного из важнейших факторов -- скорости выполнения приложения >ничего конкретного узнать не удалось, только слова(и пример, за который спасибо, >на самом деле, на мысли наводит). > в такого рода вопросах можно делать только самостоятельные умозаключения. потому что сами метрики, с помощью которых мы можем что-то в программировании измерить -- весьма расплывчаты с формальной точки зрения -- слишком много степеней свободы. на одном и том же языке (например, на С++) можно спроектировать и закодировать одну и ту же задачу с разницей по скорости выполнения в порядки. только благодаря неправильной декомпозиции на классы (например, слишком "изощренной"). а если сюда добавить еще и разницу в средствах разработки (каждый компайлер генерит свой выполняемый код), разницу в подходах к декомпозиции и проч. и проч. то получится такой пласт вопросов, разрешить коротые без беспрестрастных исследований -- невозможно. а как они (исследования) могут быть беспрестрастны -- когда у программера есть любимые и нелюбимые инструменты? и кому интересно их проводить (они же дорогостоящи)? и кому интересно знать эти результаты (у каждого итак есть свой любимый инструмент)? и какой экономический эффект это даст (как мы отобьем потраченные деньги)? короче, это один из множества вопросов, на которые нет ответа, который бы устраивал все заинтересованные в ответе стороны. по этому каждая заинтересованная сторона ищет ответ самостоятельно. >Посему две просьбы. >1. Если ошибся - поправте. >2. Если кто узнает что-нибудь стоящее по теме -- киньте ссылку на >мыло aklaus@list.ru. Буду очень признателен. (Если кто надумает писать, пожалуйста пометьте >тему "Си или Си++"). > >Спасибо. >С уважением, Андрей.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	87. "Си или Си ++?"
	Сообщение от klalafuda on 21-Авг-04, 13:27  (MSK)
	>Посему две просьбы. >1. Если ошибся - поправте. >2. Если кто узнает что-нибудь стоящее по теме -- киньте ссылку на >мыло aklaus@list.ru. Буду очень признателен. (Если кто надумает писать, пожалуйста пометьте >тему "Си или Си++"). щаз вам тут расскажут, а вы уши и развесили.. что вам мешает попробовать оба инструмента самому и составить свое, собственное мнение ? ps: есть забавный manual по поводу того, как правильно задавать вопросы в сети http://ln.com.ua/~openxs/articles/smart-questions-ru.html если отталкиваться от данного труда, то ваш вопрос задан полностью некорректно. почитайте, IMHO не зря потратите свое время. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	90. "Си или Си ++?"
	Сообщение от SergeiZz on 25-Авг-04, 16:27  (MSK)
	>  Поясню вопрос. >Как я понял, Си++ это надмножество Си. Из этого следует(как я понимаю), >что Си++ включает в себя Си _полностью_ (поправте меня, если ошибаюсь), >т.е., говоря по-русски на Си++ можно сделать _всё_, что можно сделать >на Си и ещё можно делать проще то, что на Си >сделать труднее (так?). Логично (на мой взгляд) использовать Си++ (исходя из >этих рассуждений). На C можно сделать всё, что можно сделать на ассемблере... C включает ассемблер как множество (ассеблерные вставки имеются в виду)... Из этих рассуждений логично забыть про ассемблер? Исходные положения для рассуждений поставлены некорректно. >  Так я думал. Но шло время, и я встречал доказательства >того, что очень многие люди программируют на Си. ...Но не заметил, что подавляющее большинство из них делают это вовсе не потому, что C в чём-то лучше (даже применительно непосредственно к стоящим перед ними задачам)... >Я попытался найти ответ сам, но ввиду нехватки времени, >а может и способностей, не нашёл, и решил обратиься с вопросом >к сведующим людям, а где их найти? Логично (на мой взгляд) >было искать здесь. А как здесь отличить сведущего человека от несведущего? >  Пока я нашёл два аргумента в "пользу" Си: >1. Линковка стандартизована(в лтличии от Си++), что важно для переносимости (поправте, если >ошибаюсь). О-о! Если бы линковка была единственной (или хотя бы главной) проблемой переносимости! >2. Логика конечных автоматов не требует ни одного из средств Си++(про это >(логику) слышу всего раз третий-четвёртый, поэтому если не прав - простите >и поправте). Про логику конечных автоматов не буду ругаться до тех пор по крайней мере, пока proff не изложит, как он её понимает, а то некультурно получается. C и C++ к этим вещам вообще никакокого касательства не имеют. >(Зачем использовать эксковатор для того, чтобы набрать ведро песка? >Это явный перебор, причём гораздо лучше и быстрее лопатой). Правильно, конечно, но есть одно "но". Дело в том, что в современной жизни уже ну совсем не осталось места задачам, где нужна лопата, а не экскаватор. >К сожалению, по поводу одного из важнейших факторов -- скорости выполнения приложения >ничего конкретного узнать не удалось, только слова(и пример, за который спасибо, >на самом деле, на мысли наводит). Это пример на мысли наводить не должен -- это явно шутка. Если Вы ещё не отвыкли от привычки измерять время работы алгоритмов в секундах, то я бы посоветовал почитать про NFL теорему (Ноу-фри-ланч). Она доказана пока только для задач оптимизации, но рассчитывать, что она не верна для более широкого класса задач не приходится. Если надо, то подберу список ссылок на эту тему "для неспециалиста". >Посему две просьбы. >1. Если ошибся - поправте. Ошибся в главном: не понял, почему C всё ещё используется...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	91. "Си или Си ++?"
	Сообщение от Андрей (??) on 25-Авг-04, 16:43  (MSK)
	>>Посему две просьбы. >>1. Если ошибся - поправте. >Ошибся в главном: не понял, почему C всё ещё используется... Так поясни. И насчёт списка ссылок - буду признателен, коли не шутишь.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	92. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 25-Авг-04, 16:48  (MSK)
	>>>Посему две просьбы. >>>1. Если ошибся - поправте. >>Ошибся в главном: не понял, почему C всё ещё используется... > >Так поясни. 1) Андрей, мы уже обсуждали исторический фактор? Много всего на Си тянется ещё с тех времен, вот и тянем. Переходить с одного инструмента на другой - слишком дорого. 2) Не так много программистов умеют программировать, ещё больше не умеют программировать на Си, а на Си++ не умеют программировать великое множество людей. >И насчёт списка ссылок - буду признателен, коли не шутишь.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	93. "Си или Си ++?"
	Сообщение от SergeiZz on 25-Авг-04, 17:22  (MSK)
	>>>>Посему две просьбы. >>>>1. Если ошибся - поправте. >>>Ошибся в главном: не понял, почему C всё ещё используется... >> >>Так поясни. > >1) Андрей, мы уже обсуждали исторический фактор? Много всего на Си тянется >ещё с тех времен, вот и тянем. Переходить с одного инструмента >на другой - слишком дорого. > >2) Не так много программистов умеют программировать, ещё больше не умеют программировать >на Си, а на Си++ не умеют программировать великое множество людей. Браво! Короче и яснее, признаюсь, я не смог бы. >>И насчёт списка ссылок - буду признателен, коли не шутишь. Нород, чесное пионерское сделаю. Только надо ж как-то обдумать, не первое же попавшееся, не известно откуда взявшееся (намёк...). Если не втерпёшь, то ссылка на оригинальную работу есть в этом pdf: http://cs.gmu.edu/~eclab/papers/lecture-pres/nfl-handout.pdf
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	94. "Си или Си ++?"
	Сообщение от Андрей (??) on 25-Авг-04, 17:35  (MSK)
	>Нород, чесное пионерское сделаю. Только надо ж как-то обдумать, не первое >же попавшееся, не известно откуда взявшееся (намёк...). >Если не втерпёшь, то ссылка на оригинальную работу есть в этом pdf: > >http://cs.gmu.edu/~eclab/papers/lecture-pres/nfl-handout.pdf Втерпёжь (со временем - напряг), буду ждать. Ссылку гляну.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	100. "Си или Си ++?"
	Сообщение от SergeiZz on 27-Авг-04, 16:48  (MSK)
	>>Нород, чесное пионерское сделаю. Только надо ж как-то обдумать, не первое >>же попавшееся, не известно откуда взявшееся (намёк...). >>Если не втерпёшь, то ссылка на оригинальную работу есть в этом pdf: >> >>http://cs.gmu.edu/~eclab/papers/lecture-pres/nfl-handout.pdf > >Втерпёжь (со временем - напряг), >буду ждать. >Ссылку гляну. Да, я ж забыл совсем сформулировать утверждение теоремы. Исправляюсь: Если существует задача оптимизации (я утрирую терминологию для простоты), которую алгоритм А решает быстрее алгоритма B, то всегда найдётся другая задача оптимизации, которую алгоритм B рещает быстрее алгоритма A. Вот оригинальная работа: http://citeseer.ist.psu.edu/wolpert95no.html Тут я раньше думал привести списочек основных работ на эту тему, но сейчас думаю, что это мартышкин труд: эта суровая математика интересна только математикам, а они и сами найдут, что их интересует в связи с NFL, благо ключевые слова очевидны. А вот для "нематематиков", которые хотят поподробнее узнать, но так, что б "в одном абзаце" я советую прочитать раздел номер 1 вот этой работы Oliver Sharpe: http://citeseer.ist.psu.edu/296977.html Тем, кто захотят узнать поподробнее, можно почитать литобзор диссертации Оливера: http://citeseer.ist.psu.edu/sharpe00towards.html Там очень сжато изложено всё самое важное с сылками на литературу по этой тематике. Ну, и прямо здесь я попытаюсь угадать вопросы, которые наверняка уже возникли у "быстрых разумом Невтонов". Первый вопрос, а как же быть со статьями изобретателей алгоритмов за последние 50 лет, которые написаны в стиле "вот я придумал алгоритм, он на этих 10-ти задачах быстрее всех известных"? Ответ: начиная с середины 90-х вам очень трудно будет найти серьёзную работу одним результатом которой будет только иллюстрация высокой скорости работы алгоритма. И в этом именно NFL повинна. Второй вопрос, а как же быть с быстрой сортировкой qsort, которая быстрее всех? Во-первых NFL доказана только для задач оптимизации (пока?). Но дело даже не в этом. У алгоритма сортировки конечный набор входных данных (факториал n, где n -- длина последовательности), есть и предельное число шагов, а значит и число возможных алгоритмов сортировки конечно (но очень велико). В этих условиях можно надеяться, что есть "самый быстрый" алгоритм. Вот когда множество задач, которые должен решать алгоритм бесконечно, или даже бесконечномерно, то надежда эта быстро улетучивается. Но и это не всё. Думаете, что qsort быстрая? Ошибаетесь. О какой последовательности идёт речь? Если последовательность плохо перемешана (лишь немногие элементы стоят не на своих местах), то qsort будет едвали не самой медленной из всех классических алгоритмов сортировки. С этим эффектом можно бороться (что и делают разные реализации qsort), но победить его доконца нельзя в принципе. Так, что получается, что прежде, чем выбрать тот или иной алгоритм (например -- сортировки), нужно провести могучее чисто математическое исследование по объёму напоминающее докторскую диссертацию. Здесь ещё может возникнуть вопрос, как понимать разницу между программой и алгоритмом? Обычно можно отождествить программу и алгоритм, до тех пор, пока не сравниваются разные реализации одного и того же алгоритма, но и реализации -- это ведь тоже суть "последовательности шагов, решающие данный класс задач". Так, что на этом фоне высказывания вроде: "компилятор Borland хуже оптимизирован по сравнению с компилятором Microsoft" кажутся не более, чем сотрясанием воздуха. И наконец, а как мы вообще сравниваем время работы алгоритмов? Запустим 5-10 раз две программы с одинаковыми входными данными, да посмотрим, как они работают на нашей шустрой аппаратуре, авось на другой платформе ситуация будет той же? А где суровая математика, доказывающая, что пользователь целыми днями только и будет использовать входные данные из набора проверенных нами, или что на всех остальных возможных входных данных ситуация аналогична (вот этого-то и не стоит ждать, как учит нас NFL).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	95. "Си или Си ++?"
	Сообщение от proff (??) on 26-Авг-04, 11:55  (MSK)
	>А как здесь отличить сведущего человека от несведущего? здесь -- как и везде -- отличить можно лишь мозгами (под которыми понимаются знания и опыт). >Про логику конечных автоматов не буду ругаться до тех пор по крайней >мере, >пока proff не изложит, как он её понимает, а то некультурно получается. >C и C++ к этим вещам вообще никакокого касательства не имеют. к логике конечных автоматов имеют касательство законы логики. я в своих постах говорил о подходе проектирования, основанном на FSM-логике. о том, что на С++ НЕ закодировать FSM-програму -- я не сказал ни слова -- ибо это не так. (FSM -- Finite State Machine; я описался в посте, назвав ее FSA. но я надеюсь, что это не будет воспринято как идеологическая ошибка) читайте, господа, текст, а то получается, что вы разговариваете не со мной, а с кем-то другим, кого вы сами себе представили. >Правильно, конечно, но есть одно "но". >Дело в том, что в современной жизни уже ну совсем не осталось >места >задачам, где нужна лопата, а не экскаватор. осталось. вы просто, как я посмотрю, не в курсе. самое обширное поле деятельности -- обучение. нужно научить людей думать, а не клацать Copy+Paste. для того, чтобы учить людей методологии проектирования программ -- нужно научить их ориентироваться в различных системах координат. OOD (Object Oriented Design) здесь -- одна из трех основных. FSM -- вторая. SAD (Structured Analisys and Design) -- третья. Смесь этих подходов -- как это обычно и случается -- это результат работы по композиции (подходов) самими студентами, когда они решают конкретные задачи. второе по распространенности -- критичные ко времени исполнения и к ресурсоемкости вычисления. пример -- embedded or unmontainable solutions (MERA Softswitch, Cisco и т.п.) третье -- open source. наиболее ярко это просматривается IMHO в *BSD comminity. Этого мало вы считаете? >Ошибся в главном: не понял, почему C всё ещё используется... IMHO не стоит думать, что существует только одно правильное мнение. их может быть несколько...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	96. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 26-Авг-04, 12:08  (MSK)
	>>А как здесь отличить сведущего человека от несведущего? > >здесь -- как и везде -- отличить можно лишь мозгами (под которыми >понимаются знания и опыт). > >>Про логику конечных автоматов не буду ругаться до тех пор по крайней >>мере, >>пока proff не изложит, как он её понимает, а то некультурно получается. >>C и C++ к этим вещам вообще никакокого касательства не имеют. > >к логике конечных автоматов имеют касательство законы логики. > >я в своих постах говорил о подходе проектирования, основанном на FSM-логике. о >том, что на С++ НЕ закодировать FSM-програму -- я не сказал >ни слова -- ибо это не так. > Да, на С++ логика FSM ложится так же, как и на Си при этом с лучшей реализацией. К примеру type-safety, inline algorithms etc. >(FSM -- Finite State Machine; я описался в посте, назвав ее FSA. >но я надеюсь, что это не будет воспринято как идеологическая ошибка) > > >читайте, господа, текст, а то получается, что вы разговариваете не со мной, >а с кем-то другим, кого вы сами себе представили. > >>Правильно, конечно, но есть одно "но". >>Дело в том, что в современной жизни уже ну совсем не осталось >>места >>задачам, где нужна лопата, а не экскаватор. > >осталось. вы просто, как я посмотрю, не в курсе. > Остались задачи для лопатки? Вряд ли. Аргументируйте, аргументируйте, приводите примеры. >самое обширное поле деятельности -- обучение. >нужно научить людей думать, а не клацать Copy+Paste. Самое общирное поле деятельности - это не обучение. С чего ты взял? Для того, чтобы выбрать наиболее подходящее решение, нужно знать как можно больше вариантов. Конечно, в данном случае нужно знать и Си и Си++, и Java и .NET и assembler для всех архитектур, UML с XML, SQL 92/99 и т.д.. Этому стоит учиться, но при чем тут это к нашей дискуссии? > >для того, чтобы учить людей методологии проектирования программ -- нужно научить их >ориентироваться в различных системах координат. OOD (Object Oriented Design) здесь -- >одна из трех основных. FSM -- вторая. SAD (Structured Analisys and >Design) -- третья. >Смесь этих подходов -- как это обычно и случается -- это результат >работы по композиции (подходов) самими студентами, когда они решают конкретные задачи. > Ты случайно не бородатый дедушка-профессор в каком-то совковом вузе? Столько теории и ни капли практики. > >второе по распространенности -- критичные ко времени исполнения и к ресурсоемкости вычисления. >пример -- embedded or unmontainable solutions (MERA Softswitch, Cisco и т.п.) > Ну и ? Есть такие, опять же, при чем тут СИ и Си++. При правильном дизайне не будет разницы по производительности, будет лишь разница в цене. > >третье -- open source. наиболее ярко это просматривается IMHO в *BSD comminity. > А при чем тут open-source вообще?) > >Этого мало вы считаете? > >>Ошибся в главном: не понял, почему C всё ещё используется... > >IMHO не стоит думать, что существует только одно правильное мнение. их может >быть несколько... В этом ты прав, но из этих нескольких будет лучшее и худшее. ---- Я так и не понял твою роль в обсуждении что лучше все таки, Си или Си++? С твоими суждениями не стоит огород городить.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	97. "Си или Си ++?"
	Сообщение от proff (??) on 26-Авг-04, 16:37  (MSK)
	>Остались задачи для лопатки? Вряд ли. Аргументируйте, аргументируйте, приводите примеры. > вы спрашивате даже не дочитав до конца ответ. это как называется? с моей стороны это называется так: собеседник не понимает о чем идет речь. >>самое обширное поле деятельности -- обучение. >>нужно научить людей думать, а не клацать Copy+Paste. > >Самое общирное поле деятельности - это не обучение. С чего ты взял? > мы говорили о МЕСТАХ И ВОЗМОЖНОСТЯХ применения Си. я привел три примера. на мой взгляд - убедительных. >Для того, чтобы выбрать наиболее подходящее решение, нужно знать как можно больше >вариантов. Конечно, в данном случае нужно знать и Си и Си++, >и Java и .NET и assembler для всех архитектур, UML с >XML, SQL 92/99 и т.д.. Этому стоит учиться, но при чем >тут это к нашей дискуссии? > "знание основных законов освобождает от знания некоторых фактов". очень известная фраза. от себя добавлю: учиться в институте (и учить) нужно методологии, а не новомодным технологиям, которые через пару лет забудут как страшный сон. > >Ты случайно не бородатый дедушка-профессор в каком-то совковом вузе? Столько теории и >ни капли практики. > я хоть и бородат, но далек от совкового ВУЗа. а вот вы, видимо, далеки от осознания того, в какой банке находитесь. IMHO кроме ООП вы ничего толком не знаете. да видимо и ООП в полном виде не освоили, раз не знаете его узких мест. в противном случае так бы не голосили за ООП. предвосхищаю вопросы: почему я говорю, что некто "Vladislav Lazarenko" кроме ООП ничего не знает? потому, что он с пеной у рта доказывает о незаменимости С++, в то самое время, как С++ вне ООП не имеет никакого смысла. следовательно, Vladislav Lazarenko скорее всего не владеет ничем кроме ООП. иначе бы он видел альтернативы. (о которых я писал выше) > >Ну и ? Есть такие, опять же, при чем тут СИ и >Си++. При правильном дизайне не будет разницы по производительности, будет лишь >разница в цене. > примеры? приведите примеры разницы в цене? (для себя) >> >>третье -- open source. наиболее ярко это просматривается IMHO в *BSD comminity. >> > >А при чем тут open-source вообще?) > при том, что я говорил о *BSD comminity. в том контексте, что это сообщество предпочитает СИ. > >В этом ты прав, но из этих нескольких будет лучшее и худшее. > у каждого в башке одно правильное мнение -- собственное. это первое. а второе -- бывают и эквивалентные мнения. бывают и ортогональные. т.е. те, которые заведомо нельзя сравнивать. > >---- > >Я так и не понял твою роль в обсуждении что лучше все >таки, Си или Си++? >С твоими суждениями не стоит огород городить. невозможно сравнить два языка тупо, как две коробки спичек. ибо если тупо сравнивать, то заведомо объективной картины получить невозможно. по этому тупо сравнивать -- как предлагают некоторые -- умные дядьки не хотят. т.к. в этом сравнении, с их точки зрения, нет никакого резону. а то что вы переходите на личности -- говорит о неуверенности в себе как в участнике интеллектуальной дискуссии. ЗЫ: тред с моей точки зрения себя исчерпал. из него ушли те люди, с кем мне было бы интересно вести обмен мнениями.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	98. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 26-Авг-04, 16:48  (MSK)
	>>Остались задачи для лопатки? Вряд ли. Аргументируйте, аргументируйте, приводите примеры. >> > >вы спрашивате даже не дочитав до конца ответ. >это как называется? > >с моей стороны это называется так: >собеседник не понимает о чем идет речь. > > >>>самое обширное поле деятельности -- обучение. >>>нужно научить людей думать, а не клацать Copy+Paste. >> >>Самое общирное поле деятельности - это не обучение. С чего ты взял? >> > >мы говорили о МЕСТАХ И ВОЗМОЖНОСТЯХ применения Си. >я привел три примера. >на мой взгляд - убедительных. > >>Для того, чтобы выбрать наиболее подходящее решение, нужно знать как можно больше >>вариантов. Конечно, в данном случае нужно знать и Си и Си++, >>и Java и .NET и assembler для всех архитектур, UML с >>XML, SQL 92/99 и т.д.. Этому стоит учиться, но при чем >>тут это к нашей дискуссии? >> > >"знание основных законов освобождает от знания некоторых фактов". >очень известная фраза. > >от себя добавлю: >учиться в институте (и учить) нужно методологии, а не новомодным технологиям, которые >через пару лет забудут как страшный сон. > >> >>Ты случайно не бородатый дедушка-профессор в каком-то совковом вузе? Столько теории и >>ни капли практики. >> > >я хоть и бородат, но далек от совкового ВУЗа. >а вот вы, видимо, далеки от осознания того, в какой банке находитесь. > >IMHO кроме ООП вы ничего толком не знаете. да видимо и ООП >в полном виде не освоили, раз не знаете его узких мест. >в противном случае так бы не голосили за ООП. > >предвосхищаю вопросы: >почему я говорю, что некто "Vladislav Lazarenko" кроме ООП ничего не знает? >потому, что он с пеной у рта доказывает о незаменимости С++, >в то самое время, как С++ вне ООП не имеет никакого >смысла. следовательно, Vladislav Lazarenko скорее всего не владеет ничем кроме ООП. >иначе бы он видел альтернативы. (о которых я писал выше) > >> >>Ну и ? Есть такие, опять же, при чем тут СИ и >>Си++. При правильном дизайне не будет разницы по производительности, будет лишь >>разница в цене. >> > >примеры? приведите примеры разницы в цене? >(для себя) > >>> >>>третье -- open source. наиболее ярко это просматривается IMHO в *BSD comminity. >>> >> >>А при чем тут open-source вообще?) >> > >при том, что я говорил о *BSD comminity. в том контексте, что >это сообщество предпочитает СИ. > >> >>В этом ты прав, но из этих нескольких будет лучшее и худшее. >> > >у каждого в башке одно правильное мнение -- собственное. >это первое. >а второе -- бывают и эквивалентные мнения. бывают и ортогональные. т.е. те, >которые заведомо нельзя сравнивать. > >> >>---- >> >>Я так и не понял твою роль в обсуждении что лучше все >>таки, Си или Си++? >>С твоими суждениями не стоит огород городить. > >невозможно сравнить два языка тупо, как две коробки спичек. ибо если тупо >сравнивать, то заведомо объективной картины получить невозможно. > >по этому тупо сравнивать -- как предлагают некоторые -- умные дядьки не >хотят. т.к. в этом сравнении, с их точки зрения, нет никакого >резону. > >а то что вы переходите на личности -- говорит о неуверенности в >себе как в участнике интеллектуальной дискуссии. > >ЗЫ: тред с моей точки зрения себя исчерпал. из него ушли те >люди, с кем мне было бы интересно вести обмен мнениями. Cи++ очень интересен не только как объектно-ориентированый язык, что доказывает ваше незнание Си++. Аргументов в пользу того и другого языка я приводил достаточно много, вы же не приводили ничего существенного, кроме ссылок на чьи-то теории. Да, в форуме Вам не инетресно обмениваться-мнениями, так как в большинстве случаев Вы "мелете" чушь. На счет задачь для лопатки я так ничего и не услышал.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	99. "Си или Си ++?"
	Сообщение от SergeiZz on 27-Авг-04, 15:49  (MSK)
	>>А как здесь отличить сведущего человека от несведущего? > >здесь -- как и везде -- отличить можно лишь мозгами (под которыми >понимаются знания и опыт). Туманная формулировка, ну да бог с этим. Я просто говорю, что здесь не видно, с кем говоришь, а только слышно, что он говорит. Только по этим слышимым словам понять, с кем имеешь дело практически невозможно. >>Про логику конечных автоматов не буду ругаться до тех пор по крайней >>мере, >>пока proff не изложит, как он её понимает, а то некультурно получается. >>C и C++ к этим вещам вообще никакокого касательства не имеют. > >к логике конечных автоматов имеют касательство законы логики. Постарайтесь пожалуйста, если конечно хотите продолжать разговор в этой чуждой Вам (как и мне, кстати говоря) компании завсегдатаев этого форума, не делать подобных замечаний: это пустой звук, а вот он-то, как раз, сильно раздражает. >я в своих постах говорил о подходе проектирования, основанном на FSM-логике. о >том, что на С++ НЕ закодировать FSM-програму -- я не сказал >ни слова -- ибо это не так. Я понял Ваши слова именно как обратное утверждение, оттого и моё негодование. Теперь я успокоился, но всё ещё плохо представляю, о чём с Вашей стороны идёт речь. >(FSM -- Finite State Machine; я описался в посте, назвав ее FSA. >но я надеюсь, что это не будет воспринято как идеологическая ошибка) Эти термины часто смешиваются, я лично к этому давно привык... >читайте, господа, текст, а то получается, что вы разговариваете не со мной, >а с кем-то другим, кого вы сами себе представили. Это, кстати, совершенно неизбежно. Вы, наверное, не учитываете наличие этого эффекта, а зря. >>Правильно, конечно, но есть одно "но". >>Дело в том, что в современной жизни уже ну совсем не осталось >>места >>задачам, где нужна лопата, а не экскаватор. > >осталось. вы просто, как я посмотрю, не в курсе. Я спициально в подобных случаях пишу "ну совсем" или "ну правда-правда". Это утверждение, конечно, в стиле "давайте примем, что Земля круглая, и точка", конечно она не вполне круглая и вообще в быту достаточно считать, что она плоская, и так далее. Подчёркивается то, что круглая форма -- это главное для нас (в рамках данной задачи) свойство Земли. Здесь  Vladislav Lazarenko, (как и я) дочитал Вас до конца, просто примеры, которые Вы привели, показались ему слишком неубедительными. Мои же замечания ниже. >самое обширное поле деятельности -- обучение. Теперь я уже могу догадаться, что нужно понимать как "самое обширное поле деятельности для использования C -- обучение." Если я правильно понял Вас, то я очень с этим не согласен, но опять не хочу торопиться с упрёками до подтверждения правильности моего понимания. >нужно научить людей думать, а не клацать Copy+Paste. Это очень-очень-очень верно подмечено. Но здесь Вас не проймут, если не разжуёте им, почему именно "нужно научить людей думать", если, как они считают, вообще "думать -- вредно" (это шутка, разумеется...). >для того, чтобы учить людей методологии проектирования программ -- нужно научить их >ориентироваться в различных системах координат. OOD (Object Oriented Design) здесь -- >одна из трех основных. FSM -- вторая. SAD (Structured Analisys and >Design) -- третья. >Смесь этих подходов -- как это обычно и случается -- это результат >работы по композиции (подходов) самими студентами, когда они решают конкретные задачи. На мой взгляд, всё чётко и точно сказано. Лишь замечу, что Вы относите FSM слишком высокое место, но это может быть потому, что Вы или слишком обожествляете FSM (эта та проблема, о которой я упоминал раньше), либо просто используете малоупотребительную терминологию, поизнося слово FSM. Как видите, я пока плохо понимаю, что Вы разумеете под FSM методологией. >второе по распространенности -- критичные ко времени исполнения и к ресурсоемкости вычисления. >пример -- embedded or unmontainable solutions (MERA Softswitch, Cisco и т.п.) Это по сути неверно, но де-факто так и есть. Грубо говоря, эти вещи пишутся на ассемблере вовсе не для пущей эффективности, как ну очень-очень многие считают, а как раз в силу причины нумер два, указанной Vladislav Lazarenko. >третье -- open source. наиболее ярко это просматривается IMHO в *BSD comminity. И здесь дело вовсе не в C или C++... >Этого мало вы считаете? Этого мало. Если хотите привести пример, где надо использовать C, а не C++, очень точно, как мне кажется, выразился однажды здесь Арлекин. C++ не нужен для решения квадратного уравнения. Имеется в виду, конечно, задачи подобного рода. Но уже здесь видно, "где в современном мире сапа, а где мотыга", ибо стоит только расширить задачку до решения квадратного уравнения с комплексными коэффициентами и, покрайней мере, объектно-базовый язык уже становится весьма кстати. >>Ошибся в главном: не понял, почему C всё ещё используется... > >IMHO не стоит думать, что существует только одно правильное мнение. их может >быть несколько... Увы! Приходится, просто приходится вещать именно в таком категоричном тоне. А, кстати говоря, это ж и не надо, наверное, к каждому слову ставить "по моему мнению": это кому ж в голову придёт, что есть такой человек, который знает, как правильно. Так, что, IMHO, "IMHO" у каждого утверждения просто подразумевается автоматически.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	101. "Си или Си ++?"
	Сообщение от proff (??) on 27-Авг-04, 17:30  (MSK)
	>Теперь я уже могу догадаться, что нужно понимать как "самое обширное поле > >деятельности для использования C -- обучение." >Если я правильно понял Вас, то я очень с этим не согласен, >но опять не >хочу торопиться с упрёками до подтверждения правильности моего понимания. > учить людей нужно альтернативным подходам к решению задач. причем делать это нужно стараться таким образом, чтобы у них не появлялось устойчивого навыка использования какого-то одного подхода, в ущерб других. в нашем разговоре -- это ООП. это было первое. второе -- это то, что разговор по сути не имеет большого практического смысла (с моей точки зрения), когда в нем начинают сравнивать два языка как два мертвых предмета. и именно руководствуясь этой точкой зрения я что-то стучал в посты. мне не интересно сравнивать выразительные средства этих языков, ибо у С++ они заведомо более изощренные. что является как плюсом так одновременно и минусом. и у С есть свои плюсы и минусы. и ориентированны они на различную аудиторию пользователей (программистов) и проч. и проч. это все вторично и не интересно. интересно разобраться в идеологии. кто правит идеологией, тот правит миром. известная фраза. Уильям Гейтс это совершенно ясно понял и четко претворил. и то что сейчас есть -- есть. и мы с этим ничего не поделаем, пока не изменим идеологию. пока каждый из нас будет пожирателем интеллектуальных гамбургеров -- ничего с места не сдвинется. а снижение требований к человеческому фактору за счет "упрощения" инструмента и укоренение мнения что больше ничего не требуется -- это и есть формирование поколений вышеупомянутых пожирателей. я об этом писал и пишу, а не о тупом сравнении Си и Си++. я понимаю, что это не понятно большинству конкретно мыслящих и действующих. непонятно потому что они живут в своем мире атомов. и чтобы поднять свой взгляд над всей кристаллической решеткой -- на это у них конкретики не достаточно. а ее и не будет достаточно, т.к. это идеология. т.е. то, что находится выше -- мета уровень. еще раз говорю -- это непонятно. но тем не менее -- делать что-то нужно. >На мой взгляд, всё чётко и точно сказано. >Лишь замечу, что Вы относите FSM слишком высокое место, но это может >быть >потому, что Вы или слишком обожествляете FSM (эта та проблема, о которой >я >упоминал раньше), либо просто используете малоупотребительную >терминологию, поизнося слово FSM. >Как видите, я пока плохо понимаю, что Вы разумеете под FSM методологией. > FSM ничем не выделяется из OOD и SAD. одна из нескольких. а так много внимания я ей уделяю оттого, что она "случайно" забыта. и практически нигде о ней нет упоминания. что чрезвычайно "странно", т.к. это самый старый подход. чтобы понять, что я понимаю под FSM -- недостаточно прочитать вот эти работы питерских ученых. нужно их понять. если вы интересуетесь методологией проектирования -- поверьте, они вам пригодятся в любом случае, не зависимо от того, какой подход вам больше по душе. http://lib.aswl.ru/books/methodology/FSM/
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	102. "Си или Си ++?"
	Сообщение от DeadMustdie (??) on 28-Авг-04, 22:38  (MSK)
	Итак, обсуждение сугубо практического вопроса, поставленного в неточной и черезчур общей форме, преобразовалось в дискуссию, масштабами сходную с диспутами средневековых схоластов на тему числа ангелов, умещающихся на кончике булавки. Такое обычно происходит, когда в форум технико-практической направленности заглядывает некто "черезчур умный". Что не может в итоге не привести в раздражение всю местную тусовку, а в итоге заставляет проснуться даже флегматиков вроде меня. Весь этот абзац, разумеется, шутка - а вы что подумали? Сразу прошу прощения за безобразно длинный пост - увы, на данный момент пока не сумел научиться кратко излагать свои мысли. Грешен-с ;-) >учить людей нужно альтернативным подходам к решению задач. причем >делать это нужно стараться таким образом, чтобы у них не появлялось >устойчивого навыка использования какого-то одного подхода, в ущерб >других. в нашем разговоре -- это ООП. На практике обучение обычно делят на два параллельных, взаимосвязанных, но _раздельных_ процесса: 1. обучение понятиям, идеям и подходам; 2. применение знаний из пункта 1 к решению практических задач. Процесс 1 без процесса 2 заведомо неэффективен, что может снизить качество полученных знаний. Причина состоит в странной особенности мышления большинства людей: они почему-то легче усваивают теоретический базис, увидев, каким образом он может применяться на практике :). По очевидным соображениям экономического характера процесс обучения желательно оптимизировать (сиречь: для заданного уровня знаний сократить, насколько это возможно, затраты времени на обучение). Поэтому применение процесса 2 следует считать обязательным. То есть если обучаемые для закрепления знаний не заняты решением учебных задач, то либо они плохо усваивают материал (вероятность 99.9%), либо теряют время, усваивая этот материал не самым быстрым способом. Процесс 2 _автоматически_ формирует устойчивые навыки решения задач с применением определённых инструментов. Эти навыки не есть зло, если инструменты были правильно подобраны. Критерии подбора инструментов для обучения есть вопрос спорный. Однако я склонен признавать, что C++ мало пригоден как язык, используемый при обучении в равной степени как как и навыкам алгоритмического мышления, проектирования (в перспективе - моделирования), так и основам программирования. Для целей обучения, включая постановку и решение учебных задач, он слишком сложен. Не получив предварительно немалого практического опыта и не собрав солидного багажа знаний, решать учебные задачи качественно и корректно применять механизмы C++ сможет очень небольшая доля особо одарённых обучаемых. Сам я в их число точно не попал бы - и вообще это был бы почти садизм :). Однако и "чистый" C тоже не лучший язык для обучения _мышлению_. В этом языке для получения грамотного кода нужно соблюдать немало условностей, которые плохо формализуются и потому не поддерживаются в полном объёме никакими IDE и компиляторами. Как полагаете, может, Ada сгодится? Или Eiffel? > >второе -- это то, что разговор по сути не имеет большого практического >смысла (с моей точки зрения), когда в нем начинают сравнивать два >языка как два мертвых предмета. и именно руководствуясь этой точкой >зрения я что-то стучал в посты. мне не интересно сравнивать >выразительные средства этих языков, ибо у С++ они заведомо более >изощренные. что является как плюсом так одновременно и минусом. и у С >есть свои плюсы и минусы. и ориентированны они на различную аудиторию >пользователей (программистов) >и проч. и проч. это все вторично и не интересно. Мёртвые предметы вообще не очень интересны. Мёртвецов обычно закапывают, иногда сжигают. Что касается плюсов и минусов более мощного языка, то все минусы C++ проистекают из его же плюсов. Приведём несколько упрощённый пример азбучного характера: 1. Совместимость C++ с C позволила на ранних этапах обеспечить преемственность кода, обеспечила лёгкость взаимодействия нового кода на C++ со старым на C и вообще интеграцию этого самого нового кода в существующие системы. C++ фактически позаимствовал средства описания выполняемого алгоритма (не структур данных) из C, что позволило воспользоваться готовым весьма качественным решением и не изобретать в который раз велосипед. 2. Мощность конструкций C++ позволяет относительно легко описывать модели весьма сложных объектов реального мира и взаимоотношений между ними, выстраивая алгоритм как совокупность протоколов взаимодействия объектов. Эта же мощность позволила резко сократить писанину при выполнении рутинных операций; автоматически сокращается количество "дурацких" ошибок (если не ошибаюсь, это основная причина, по которой считается, что сопровождение хорошо написанной программы на C++ обходится дешевле сопровождения не менее хорошо написанной программы на C). 3. Необходимость подерживать приличный уровень совместимости с идеологически несхожим языком и наличие _очень_ сложных абстрактных конструкций, реализованных как "нашлёпка" над конструкциями C в сочетании образуют совершенно дьявольскую смесь. Именно поэтому так долго не было практически ни одного приличного компилятора C++. И именно по этому не менее 75% лиц, заявляющих о способности писать на C++, не только не способны грамотно программировать на этом языке, но и не могут ответить на элементарные вопросы по языку на собеседовании. > >интересно разобраться в идеологии. >кто правит идеологией, тот правит миром. известная фраза. >Уильям Гейтс это совершенно ясно понял и четко претворил. и то что >сейчас есть -- есть. и мы с этим ничего не поделаем, >пока не изменим идеологию. пока каждый из нас будет пожирателем >интеллектуальных гамбургеров -- ничего с места не сдвинется. >а снижение требований к человеческому фактору за счет "упрощения" >инструмента и укоренение >мнения что больше ничего не требуется -- это и есть формирование >поколений вышеупомянутых пожирателей. я об этом писал и пишу, а не >о тупом сравнении Си и Си++. > Не обижайтесь, пожалуйста - однако я позволю себе выразить сомнение в качестве Ваших знаний по предмету беседы - то бишь языку C++. Если сравнивать C и C++, то идеологически гамбургером будет именно C, как блюдо более простое и менее "извращённое". Повторю ещё раз: грамотно писать на C++ тяжело, это требует обширных знаний, хорошо развитого абстрактного мышления и довольно обширных познаний в области применяемых в объектном моделировании метафор. В противном случае программа при превышении некоего объёма кода перестанет быть сопровождаемой. Впрочем, вру - возможен ещё один вариант: когда во избежание хаоса все пишут на "почти чистом" C; код декорируется классами и собирается компилятором C++ - из почти пиаровских соображений. Такой подход я несколько раз наблюдал собственными глазами; со стороны он (подход) кажется несколько аляповатым, но позволяет начальству гордо раздувать щёки, не вкладываясь при этом в обучение кодеров и не неся соответствующих рисок. Чистая политика. Естественно, никакой пользы от применения более совершенного языка такая команда разработчиков не получает. Иногда они даже и не подозревают о возможности такой пользы. Было очень забавно однажды наблюдать, как такие "программисты на C++" разбирались в фрагменте кода на нормальном C++, полученном со стороны. Попутно был изучен пяток неведомых ранее конструкций. Изучаемый код был в итоге охарактеризован как "неправильный" и "запутанный". И был переписан в привычной манере :). Возвращаясь к исходным баранам: проблема изготовления и массового потребления "интеллектуальных хот-догов" никак не связана с языками, методологиями или подходами к решению задач практического толка. Эта беда пришла к нам из старой-престарой проблемы отчуждения средств труда от работников. В данном случае - знаний и опыта от проектировщиков и разработчиков. Поскольку средний интеллектуальный уровень оных проектировщиков и разработчиков (увы!) не слишком высок, нетрудно понять, какие методы проектирования и разработки оказываются наиболее популярны. Этого требует бизнес-модель, в которой крайне желательно застраховаться от взбрыков ключевых сотрудников. По моему скромному разумению, именно в этой проблеме лежат корни буйно расплодившихся "технологических евангелизмов" и прочего такого же. К слову: Вы заметили, что в последнее время технологии, основанные на C++, не являются "модным мейнстримом"? Прут всякие Жабы и ДотНеты, как на дрожжах, а в области, где классически силён C++, достаточно тихо, хотя в силу высоких качеств языка (при наличии опытной и обученной команды, разумеется) его по-прежнему используют как №1 в "промышленных" применениях? Но фирмам неудобно держать много высококвалифицированных сотрудников - да и раздельно аутсорсить разработку фрагментов сложной системы при использовании C++ есть форменное самоубийство. А гиганты типа MS тоже предпочитают сосредоточить максимально квалифицированный персонал в своих руках: пусть прочие бегут за лидером - всё равно не догонят. >я понимаю, что это не понятно большинству конкретно мыслящих и >действующих. непонятно потому что они живут в своем мире атомов. >и чтобы поднять свой взгляд над всей кристаллической решеткой -- >на это у них конкретики не достаточно. а ее и не будет достаточно, >т.к. это идеология. т.е. то, что находится выше -- мета уровень. > >еще раз говорю -- это непонятно. но тем не менее -- делать >что-то нужно. > Мета там или не мета... Философия при работе в ИТ нужна лишь настолько, насколько она тут полезна. Программирование на русском языке часто (чуть не написал обычно;-)) приводит к формированию функционального описания системы, которая вообще не реализуема в силу всякого рода ограничений. >FSM ничем не выделяется из OOD и SAD. одна из нескольких. >а так много внимания я ей уделяю оттого, что она "случайно" забыта. >и практически нигде о ней нет упоминания. что чрезвычайно "странно", т.к. >это самый старый подход. > >чтобы понять, что я понимаю под FSM -- недостаточно прочитать вот эти >работы питерских ученых. нужно их понять. >если вы интересуетесь методологией проектирования -- поверьте, они вам пригодятся в любом >случае, не зависимо от того, какой подход вам больше по душе. > > >http://lib.aswl.ru/books/methodology/FSM/ Спасибо за любопытный материал. Пока что не читал, так что, возможно, следующая реплика будет не вполне корректной. Однако же: Подход с непосредственным использованием FSM "естественно" применим лишь к достаточно узкой области прикладных задач. В прочих же множество состояний, определяющих поведение системы в каждый конкретный момент времени, оказывается совершенно необозримым, и приходится заниматься декомпозицией классов оных состояний. А в этом случае сам конечный автомат превращается в фикцию. Тем, кто сумел дочитать до конца: подарите себе 5 минут отдыха на свежем воздухе. Нельзя так долго сидеть у монитора :).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	103. "Си или Си ++?"
	Сообщение от proff (??) on 29-Авг-04, 01:51  (MSK)
	2DeadMustdie: спасибо за труд: Вы внятно высказали свое мнение. я получил массу удовольствия, читая Ваш пост. >Итак, обсуждение сугубо практического вопроса, поставленного >в неточной и черезчур общей форме, преобразовалось в дискуссию, >масштабами сходную с диспутами средневековых схоластов на >тему числа ангелов, умещающихся на кончике булавки. Такое обычно >происходит, когда в форум технико-практической направленности >заглядывает некто "черезчур умный". Что не может в итоге не >привести в раздражение всю местную тусовку, а в итоге заставляет >проснуться даже флегматиков вроде меня. Весь этот абзац, >разумеется, шутка - а вы что подумали? > а как Вы думаете -- иным способом мне бы удалось разбудить таких "флегматиков" как Вы? ;-) > >На практике обучение обычно делят на два параллельных, взаимосвязанных, >но _раздельных_ процесса: > 1. обучение понятиям, идеям и подходам; > 2. применение знаний из пункта 1 к решению практических задач. согласен с Вами. есть такой подход. но передо мной, в силу определенных обстоятельств, стоит несколько другая задача -- научить людей не просто думать, а думать правильно, т.е. принимать наилучшие решения из всех возможных. именно по этому я говорю об альтернативах, которые специалист должен знать. ведь ему нужно не просто решить задачу, а быть уверенным в том, что она решена наилучшим образом. >То есть если обучаемые для закрепления знаний не заняты решением >учебных задач, то либо они плохо усваивают материал >(вероятность 99.9%), либо теряют время, усваивая этот материал >не самым быстрым способом. IMHO бесспорно. (далее, с чем я согласен -- удалил, чтобы не занимать место) >Критерии подбора инструментов для обучения есть вопрос спорный. это не просто спорный вопрос -- это "ахиллесова пята всех курсов обучения". "ахиллесова" потому, что базируется на допущениях. обоснуйте, почему вы сделали такие допущения? можно тупить (или умнить) таким образом до бесконечности... > >Однако и "чистый" C тоже не лучший язык для обучения _мышлению_. именно так, Си для обучения в качестве первого языка -- далеко не лучший. он не создавался для обучения. а также для того, чтобы программмы на нем выглядели красиво. IMHO он создавался хакерами (K&R) для хакеров (K&R). я бы лично на их месте так и поступил. но в этом-то, на мой взгляд, и заключается его сила. >Как полагаете, может, >Ada сгодится? Или Eiffel? ничего не могу сказать. к моему стыду я ими не владею. >1. Совместимость C++ с C позволила на ранних этапах обеспечить >преемственность кода, обеспечила лёгкость взаимодействия нового кода >на C++ со старым на C и вообще интеграцию этого самого нового >кода >в существующие системы. C++ фактически позаимствовал средства описания >выполняемого алгоритма (не структур данных) из C, что позволило >воспользоваться готовым весьма качественным решением и не изобретать >в который раз велосипед. да, это так. это позволило многим чувствовать себя в новой среде комфортнее. но от этого компромисса что получилось? на С++ писали программы почти как на С? т.е. как и раньше глобальные переменные, функции и какие-то разрозненные вкрапления классов (или декорирование ими -- btw, очень меткое описание). это ли прорыв? > >2. Мощность конструкций C++ позволяет относительно легко описывать >модели весьма сложных объектов реального мира и взаимоотношений >между ними, выстраивая алгоритм как совокупность протоколов >взаимодействия объектов. Эта же мощность позволила резко сократить >писанину при выполнении рутинных операций; автоматически сокращается >количество "дурацких" ошибок (если не ошибаюсь, это основная причина, >по которой считается, что сопровождение хорошо написанной программы >на C++ обходится дешевле сопровождения не менее хорошо написанной >программы на C). есть такое мнение. старое. почти на уровне коры головного мозга. С++ реально позволяет забивать меньше символов, чтобы описать модель. но это справедливо тогда, когда мы говорим в общем виде. когда мы решаем задачу, то оптимизация модели может привести к тому, что нам не потребуются вся мощь конструкций С++. может так оказаться, что будет вполне достаточно лишь unum, typedef, struct и функций. > >3. Необходимость подерживать приличный уровень совместимости >с идеологически несхожим языком и наличие _очень_ сложных >абстрактных конструкций, реализованных как "нашлёпка" над >конструкциями C в сочетании образуют совершенно дьявольскую смесь. >Именно поэтому так долго не было практически ни одного приличного >компилятора C++. И именно по этому не менее 75% лиц, заявляющих >о способности писать на C++, не только не способны грамотно >программировать на этом языке, но и не могут ответить на >элементарные вопросы по языку на собеседовании. > да, именно так. то что Страуструп реализовал вначале на уровне препроцессора потом вылилось ему (и всем остальным) боком. не нужно было брать за основу Си. > >Не обижайтесь, пожалуйста - однако я позволю себе выразить сомнение >в качестве Ваших знаний по предмету беседы - то бишь языку C++. > а я и не обижаюсь: я не считаю себя мастером С++, ровно как и Си. я их всего-лишь использую как средства решения конкретных прикладных задач, а не как фетиш. не смотря на проекты, в которых я использовал С++ -- мне не были нужны все его могучие свойства. я концентрировался на оптимизации моделей. и в итоге, чтобы закодировать результирующую модель, вполне хватало классов. причем они использовались не в качестве декорации ;-) >Если сравнивать C и C++, то идеологически гамбургером будет именно >C, как блюдо более простое и менее "извращённое". Повторю ещё раз: >грамотно писать на C++ тяжело, это требует обширных знаний, >хорошо развитого абстрактного мышления и довольно обширных познаний >в области применяемых в объектном моделировании метафор. В противном >случае программа при превышении некоего объёма кода перестанет >быть сопровождаемой. вот в этом то и состоит концептуальная разница: мое представление идеального идеологического гамбургера -- "то, куда нечего добавить". в то время как "то, из чего нечего убрать" -- его антипод. из Си, на мой взгляд, гораздо меньше чего убрать, чем из С++, следовательно он (С++) в моем представлении ближе к интеллектуальному гамбургеру. именно то, что хорошо писать на С++ -- весьма не просто, а пишут на нем множество Copy+Paste программеров, потому что это якобы просто -- именно это и есть его (С++) самая большая проблема. пусть это называется компрометацией. пусть так. но кто понимает что это компрометация? > >Естественно, никакой пользы от применения более совершенного языка >такая команда разработчиков не получает. Иногда они даже и не >подозревают о возможности такой пользы. Было очень забавно однажды >наблюдать, как такие "программисты на C++" разбирались в фрагменте >кода на нормальном C++, полученном со стороны. Попутно был изучен >пяток неведомых ранее конструкций. Изучаемый код был в итоге >охарактеризован как "неправильный" и "запутанный". И был переписан >в привычной манере :). по всей видимости они (Ваши объекты наблюдения) к Си относятся аналогичным образом. тут дело не в "пуговицах" (С или С++), а в "консервной банке" (то место, куда едят). > >Возвращаясь к исходным баранам: проблема изготовления и массового >потребления "интеллектуальных хот-догов" никак не связана с языками, >методологиями или подходами к решению задач практического толка. >Эта беда пришла к нам из старой-престарой проблемы отчуждения >средств труда от работников. В данном случае - знаний и опыта от > >проектировщиков и разработчиков. Поскольку средний интеллектуальный >уровень оных проектировщиков и разработчиков (увы!) не слишком высок, >нетрудно понять, какие методы проектирования и разработки оказываются >наиболее популярны. Этого требует бизнес-модель, в которой крайне >желательно застраховаться от взбрыков ключевых сотрудников. По моему >скромному разумению, именно в этой проблеме лежат корни буйно >расплодившихся "технологических евангелизмов" и прочего такого же. >К слову: Вы заметили, что в последнее время технологии, основанные >на C++, не являются "модным мейнстримом"? Прут всякие Жабы и ДотНеты, >как на дрожжах, а в области, где классически силён C++, достаточно >тихо, хотя в силу высоких качеств языка (при наличии опытной и >обученной команды, разумеется) его по-прежнему используют как №1 >в "промышленных" применениях? Но фирмам неудобно держать много >высококвалифицированных сотрудников - да и раздельно аутсорсить >разработку фрагментов сложной системы при использовании C++ есть >форменное самоубийство. А гиганты типа MS тоже предпочитают >сосредоточить максимально квалифицированный персонал в своих >руках: пусть прочие бегут за лидером - всё равно не догонят. > заметил. эта проблема (производства и потребления интеллектуальных хот-догов) комплексна. Вы очень точно описали ее экономические составляющие. и следствия. отчуждение средств труда имеет свои корни от того времени, когда посредственным (в современном понимании этого слова) программистом быть было скорее всего невозможно: сложность задач программирования не могла позволить выжить личности с такой жизненной позицией. т.е. возможно, на начальном этапе с отчуждаемыми результатами труда ситуация была лучше. возможно. я могу лишь судить по результатам, что дошли до наших дней. а это может быть необъективно. таким образом причины, возможно, в другом. тихо, но используют С++ -- согласен. но малочисленность таких отделов и их закрытость сыграют с С++ такую же шутку, как они сыграли с другими ушедшими в историю языками. это всего-лишь переходный этап. > >Мета там или не мета... Философия при работе в ИТ нужна лишь >настолько, >насколько она тут полезна. Программирование на русском языке часто >(чуть не написал обычно;-)) приводит к формированию функционального >описания системы, которая вообще не реализуема в силу всякого рода >ограничений. нет. проектирование (в Вашей терминологии моделирование) происходит в сознании проектировщика. язык тут не причем, это всего лишь средство передать эти знания окружающим. в чем состоит критерий его (проектирования) "нереализуемости"? может быть с ним как-то связана "невозможность формирования функционального описания"? > >Подход с непосредственным использованием FSM "естественно" применим >лишь к достаточно узкой области прикладных задач. В прочих же множество >состояний, определяющих поведение системы в каждый конкретный момент >времени, оказывается совершенно необозримым, и приходится заниматься >декомпозицией классов оных состояний. А в этом случае сам конечный >автомат превращается в фикцию. не совсем. в рутинно-сложных системах, к которым можно отнести банковские, биллинговые, ERP, CRM и какие-то-другие-не-знаю-какие -- автоматная модель отлично ложится на объекты управления. когда требуется управляющий объект с предисторией -- это ли не конечный автомат?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	104. "Си или Си ++?"
	Сообщение от DeadMustdie (??) on 29-Авг-04, 16:28  (MSK)
	>но передо мной, в силу определенных обстоятельств, стоит несколько >другая задача -- научить людей не просто думать, а думать правильно, >т.е. принимать наилучшие решения из всех возможных. > >именно по этому я говорю об альтернативах, которые специалист >должен знать. ведь ему нужно не просто решить задачу, а быть >уверенным в том, что она решена наилучшим образом. > На данный момент лично мне представляется, что при наличии технологических альтернатив решения задачи эффективность того или иного выбора определяется не столько свойствами избранной технологии, сколько наличием у разработчиков опыта успешного применения этой самой технологии. Даже если с формальной точки зрения некое решение кажется более удачным, неуклюжая реализация разработчиком, впервые работающим с избранной технологией (и не знакомым с наиболее эффективными вариантами её использования) может похоронить всю затею. Универсалов же не бывает - сфера ИТ достаточно давно утратила обозримость. >>Критерии подбора инструментов для обучения есть вопрос спорный. > >это не просто спорный вопрос -- это "ахиллесова пята всех курсов >обучения". "ахиллесова" потому, что базируется на допущениях. >обоснуйте, почему вы сделали такие допущения? можно тупить >(или умнить) таким образом до бесконечности... > Ну как... Можно привести хотя бы базовый набор признаков, которые небесспорны разве что с точки зрения всяческих "евангелистов". Например: 1. Не следует смешивать "обучение понятиям, идеям и подходам" с обучением конкретным технологиям. 2. Для закрепления знаний (сиречь при выполнении учебных заданий) по возможности следует избегать применения средств, реализующих проприетарные технологии. В рамках общего курса программирования (или даже проектирования БД) не следует обучать ORACLE PL/SQL. 3. Технологии (в нашем случае - языки), реализуемые применяемыми инструментами, должны быть стандартизованы, иметь более одной реализации, иметь будущее на рынке и достаточно широко применяться. Кстати, по этому критерию из числа используемых языков напрочь вылетает Eiffel, а в российских условиях - и Ada. >да, это так. это позволило многим чувствовать себя в новой среде >комфортнее. но от этого компромисса что получилось? на С++ писали >программы почти как на С? т.е. как и раньше глобальные переменные, >функции и какие-то разрозненные вкрапления классов (или декорирование >ими -- btw, очень меткое описание). это ли прорыв? > Слово "компромисс" здесь всё объясняет. C++ не занял бы современной позиции, если бы не этот компромисс. Что же касается проблемных участков, то с ними ситуация постепенно выправляется. Вдобавок в помощь специалистам по аудиту кода появились неплохие инструменты. Скажем, `g++ -pedantic` ловит, по моим наблюдениям, более половины C-измов и и просто уродливых конструкций. А элементарные (но и наиболее часто встречающиеся) ошибки доступа к памяти прекрасно обнаруживает тот же valgrind. >есть такое мнение. старое. почти на уровне коры головного мозга. >С++ реально позволяет забивать меньше символов, чтобы описать модель. >но это справедливо тогда, когда мы говорим в общем виде. >когда мы решаем задачу, то оптимизация модели может привести к тому, что >нам не потребуются вся мощь конструкций С++. может так оказаться, что >будет вполне достаточно лишь unum, typedef, struct и функций. > Здесь всё упирается в планирование разработки. Предположим, есть абстрактно описанная прикладная задача, команда проектировщиков высокой квалификации и команда кодеров числом побольше, а квалификацией пониже. Ждать, пока проектировщики закончат формирование полного описания модели - которую как раз и можно оптимизировать - очень рискованное решение, связанное с большими потерями драгоценного времени. На практике проектировщики делают одну-две-три начальные итерации и выделяют максимально независимые фрагменты, которые нужно делать "в любом случае". Естественно, при более детальном изучении модели может оказаться, что эти фрагменты можно резко упростить, слить или, наоборот, разделить - но время кодеров уже можно использовать на создание этих участков, которые "с высокой вероятностью" будут нужны в конечном варианте системы. Для этих участков максимально чётко описывается интерфейс, и кодеры приступают к работе. Естественно, система получается не "оптимальной", и вероятность внесения изменений в спецификацию высока - но время, которого всегда мало, используется более эффективно. Правда, нервов на такую работу уходит сущая прорва. Так вот, "избыточные" возможности C++ оказываются порой совершенно необходимы, когда приходится срочно изменять поведение системы в аспектах, практически не предусмотртенных первоначальным дизайном кода и с минимальными изменениями уже написанных фрагментов (результат обычно нужен вчера - так что на писанину времени заведомо нет). Чего-то подобного можно добиться на C с помощью макросов, но результат получается несопровождаемый. > >да, именно так. то что Страуструп реализовал вначале на уровне >препроцессора потом вылилось ему (и всем остальным) боком. >не нужно было брать за основу Си. > Как было сказано в одном старом фильме - "у всех свои недостатки". :) > >вот в этом то и состоит концептуальная разница: >мое представление идеального идеологического гамбургера -- "то, куда >нечего добавить". в то время как "то, из чего нечего убрать" -- его >антипод. >из Си, на мой взгляд, гораздо меньше чего убрать, чем из С++, >следовательно он (С++) в моем представлении ближе к интеллектуальному >гамбургеру. > Когда-то я тоже считал, что ряд конструкций C++ можно выбросить из языка без ущерба для его полезных свойств, но с явным сокращением головной боли при программировании на нём. Однако со временем всё чаще мне стали попадаться примеры, в которых отсутствие той или иной "лишней" конструкции создало бы впечатление ущербности языка. Подобные вопросы очень подробно разбираются на comp.lang.c++.moderated - туда периодически заглядывают люди, входящие в состав комитет по стандарту C++. Причины, побуждающие их включать (или наоборот, не включать) определённые возможности в стандарт, обычно весьма весомы. В действительности абсолютно никто не заинтересован в том, чтобы "перегружать" язык избыточными возможностями. В действительности избыточные конструкции в C++, по сути дела, отсутствуют. Многих не устраивает несколько громоздкий синтаксис - но то плата за совместимость с C и ранними вариантами C++. >именно то, что хорошо писать на С++ -- весьма не просто, а >пишут на нем множество Copy+Paste программеров, потому что это >якобы просто -- именно это и есть его (С++) самая большая проблема. >пусть это называется компрометацией. пусть так. но кто понимает >что это компрометация? > Есть масса Copy+Paste программистов, которые пишут на Java, потому что это якобы просто - якобы намного проще, чем на C++. При этом эти самые программисты обычно попросту не в курсе, что для разработки больших и сильно связных систем Java - не очень удобный язык, как в силу ряда языковых особенностей, провоцирующих "каскады изменений" при внесении относительно мелких первоначальных коррекций, так и из-за недостаточного детерминизма поведения виртуальной машины, которое сильно зависит от капризов вендора и используемых настроек. Се беда человеческая, и идеология того или иного языка здесь вопрос, на мой взгляд, вторичный. > >по всей видимости они (Ваши объекты наблюдения) к Си относятся >аналогичным образом. тут дело не в "пуговицах" (С или С++), а в >"консервной банке" (то место, куда едят). > На "чистом" C у них, по крайней мере, получался "чистый" и почти не содержащий глупых ошибок код. Так что я никоим образом не считаю их квалификацию низкой. Просто по независящим от них причинам эти разработчики применяли "не тот" инструмент. >отчуждение средств труда имеет свои корни от того времени, когда >посредственным (в современном понимании этого слова) программистом >быть было скорее всего невозможно: сложность задач программирования >не могла позволить выжить личности с такой жизненной позицией. >т.е. возможно, на начальном этапе с отчуждаемыми результатами >труда ситуация была лучше. возможно. я могу лишь судить по >результатам, что дошли до наших дней. а это может быть необъективно. >таким образом причины, возможно, в другом. > Трудный вопрос. С одной стороны, тогдашнее несовершенство инструментов и отсутствие общепринятых практик качественной разработки программ привело к тому, что объём качественного (по современным меркам) кода в старых системах очень невелик. Вдобавок программированием поначалу занимались люди, которые задумывались не столько о качестве кода и возможностях его повторного использования (сопровождении), сколько о решении своей конкретной текущей проблемы. С другой стороны, разработанные тогда алгоритмы - не будем брать в расчёт не самую удачную их реализацию - удачны настолько, что применяются по 40 и более лет в десятках переработанных (и лишённых первоначальных огрехов) реализаций. > >тихо, но используют С++ -- согласен. но малочисленность таких >отделов и их закрытость сыграют с С++ такую же шутку, как они сыграли с >другими ушедшими в историю языками. это всего-лишь переходный этап. > Не всё так плохо. Объём существующего кода на C++ колоссален, никто не даст просто так похоронить сделанные в этот код вложения сил и средств. Вдобавок то самое спорное компромиссное решение, обеспечившее высокую степень совместимости с C, продолжает работать на живучесть языка. И, честно говоря, я не вижу серьёзной замены C++ даже с технологической точки зрения: нигде наличие столь изощрённых средств для описания абстракций не сочетается со столь богатыми возможностями тюнинга наиболее критичных по производительности участков - вплоть до использования ассемблерных вставок. > >>Программирование на русском языке часто (чуть не написал обычно;-)) >>приводит к формированию функционального описания системы, которая >>вообще не реализуема в силу всякого рода ограничений. > >нет. проектирование (в Вашей терминологии моделирование) происходит в >сознании проектировщика. язык тут не причем, это всего лишь средство >передать эти знания окружающим. > >в чем состоит критерий его (проектирования) "нереализуемости"? >может быть с ним как-то связана "невозможность формирования >функционального описания"? > Я писал не о невозможности формирования функционального описания, а о том, что периодически приходится сталкиваться с аккуратно сформированными функциональными описаниями систем, абсолютно не реализуемых имеющимися в наличии разработчиками, в указанный срок, либо - в совсем клинических случаях - в принципе, в силу наличия неявных противоречий в самом описании. Почему-то в России (не знаю, как с этим дело в Буржуиниях) довольно часто встречаются "специалисты по проектированию", которые не считают необходимым учитывать возможности и опыт остальной команды и решают каждую задачу так, как будто весь предыдущий опыт совместной работы отсутствует. Они обычно прикрываются красивым выражением "идти от задачи"; в результате же предложенные ими варианты решения практически каждый раз вовлекают всё новые и новые инструменты, реальная же потребность в них порой нулевая. Характерной особенностью таких пресонажей является устойчивая привычка формулировать свои мысли на "естественном языке" и практически полная неспособность излагать свои мысли на языке формальном. Что делает их идеальными кандидатами на работу в команде документирования, куда сами они (парадокс!) идти никак не хотят. Как раз о них и был мой предыдущий комментарий. > >не совсем. в рутинно-сложных системах, к которым можно отнести банковские, >биллинговые, ERP, CRM и какие-то-другие-не-знаю-какие -- автоматная >модель отлично ложится на объекты управления. когда требуется управляющий >объект с предисторией -- это ли не конечный автомат? Формально всё вроде бы правильно. Про биллинги и прочее ничего не скажу, а вот банковских систем я повидал немало. Вся задача там отчётливо делится на три участка: 1. Математически сложные фрагменты (клиринг и прочее в том же духе), в которых сложна именно математика, а собственно программа есть реализация формально описанного алгоритма. Здесь описание в форме конечного автомата не слишком полезно, так как по большому счёту у таких подсистем всего два состояния: задача подана - задача решена. 2. Формальные процедуры приёма документов, сверка, движение по счетам, генерация уведомлений. Здесь обычно всё заранее определено многочисленными и сверхподробными инструкциями, которые не дают сделать в сторону ни шагу. Поскольку инструкции у нас всё время помаленьку ползут, структуру кода желательно сделать аналогом структуры инструкций - так проще локализовать изменения. То есть описание такого "автомата" уже сделано в тех самых инструкциях. 3. Приложения анализа данных. Здесь сложность двойная. Непросто определить, как именно проводить анализ (цепочка цели-метод-результат весьма нетривиальна). И математически сложна реализация многих применяемых методов с приемлемой производительностью. Именно на основании такого рода наблюдений у меня на данный момент и сложилось мнение об узкой сфере применения подходов, основанных на работе с конечными автоматами.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	105. "Си или Си ++?"
	Сообщение от proff (??) on 29-Авг-04, 23:33  (MSK)
	> >На данный момент лично мне представляется, что при наличии >технологических альтернатив решения задачи эффективность того >или иного выбора определяется не столько свойствами избранной >технологии, сколько наличием у разработчиков опыта успешного >применения этой самой технологии. Даже если с формальной >точки зрения некое решение кажется более удачным, неуклюжая >реализация разработчиком, впервые работающим с избранной >технологией (и не знакомым с наиболее эффективными вариантами >её использования) может похоронить всю затею. Универсалов же >не бывает - сфера ИТ достаточно давно утратила обозримость. > Сложно спорить с этой, "сильно" устоявшейся точкой зрения. С одной стороны -- это разумеется так (иначе она бы не устоялась). Но с другой, когда мы говорим о программисте, который имеет приличный опыт проектирования и кодирования -- освоение, точнее доосвоение "новой" технологии займет, по всей видимости, не так много времени. Т.е. кривая обучения будет достаточно крутой. Заметьте -- я говорю "доосвоение". Т.е. редполагается, что программист знаком с основными принципами, заложенными в ней. С третьей стороны, имея правильно сформированную техническую культуру он будет внутренне сторониться неуклюжих реализаций. Таким образом может оказаться, что не столько глубокие знания инструмента определят успех, сколько подход к работе как к совокупности этапов проектирования, кодирования, тестирования и имплементации. Т.е. своеобразный системный подход, который как раз исключает специализацию в одном направлении за счет других. >>>Критерии подбора инструментов для обучения есть вопрос спорный. >> >>это не просто спорный вопрос -- это "ахиллесова пята всех курсов >>обучения". "ахиллесова" потому, что базируется на допущениях. >>обоснуйте, почему вы сделали такие допущения? можно тупить >>(или умнить) таким образом до бесконечности... >> > >Ну как... Можно привести хотя бы базовый набор признаков, которые >небесспорны разве что с точки зрения всяческих "евангелистов". >Например: > >1. Не следует смешивать "обучение понятиям, идеям и подходам" >с обучением конкретным технологиям. > >2. Для закрепления знаний (сиречь при выполнении учебных заданий) >по возможности следует избегать применения средств, реализующих >проприетарные технологии. В рамках общего курса программирования >(или даже проектирования БД) не следует обучать ORACLE PL/SQL. > >3. Технологии (в нашем случае - языки), реализуемые применяемыми >инструментами, должны быть стандартизованы, иметь более одной >реализации, иметь будущее на рынке и достаточно широко применяться. >Кстати, по этому критерию из числа используемых языков напрочь >вылетает Eiffel, а в российских условиях - и Ada. Вы привели отличные, с моей точки зрения, допущения. Только дело в том, что я вопрос этот задал не Вам лично, а как бы в качестве иллюстрации к тому, какие вопросы могут последовать (и обычно следуют) при "презентации курса обучения". Т.е. из-за того, что существуют такого рода допущения, есть формальная возможность задавать вопросы. > >>да, это так. это позволило многим чувствовать себя в новой среде >>комфортнее. но от этого компромисса что получилось? на С++ писали >>программы почти как на С? т.е. как и раньше глобальные переменные, >>функции и какие-то разрозненные вкрапления классов (или декорирование >>ими -- btw, очень меткое описание). это ли прорыв? >> > >Слово "компромисс" здесь всё объясняет. C++ не занял бы современной >позиции, если бы не этот компромисс. Что же касается проблемных >участков, то с ними ситуация постепенно выправляется. Вдобавок >в помощь специалистам по аудиту кода появились неплохие инструменты. >Скажем, `g++ -pedantic` ловит, по моим наблюдениям, более половины >C-измов и и просто уродливых конструкций. А элементарные (но и >наиболее часто встречающиеся) ошибки доступа к памяти прекрасно >обнаруживает тот же valgrind. Так о том и речь -- не зянял бы. А если бы он действительно не занял -- может быть в доминанты вышел бы другой, более изящный с концептуальной точки зрения язык? > >Здесь всё упирается в планирование разработки. Именно так. А если быть еще точнее, то "в стремление снизить влияние фактора <рука мастера>". Т.е. другими словами в стремление снизить влияние человеческого фактора. Многим бы очень сильно хотелось, чтобы программы проектировались не зависимо от того, кто их проектирует. >Предположим, есть >абстрактно описанная прикладная задача, команда проектировщиков >высокой квалификации и команда кодеров числом побольше, а >квалификацией пониже. Ждать, пока проектировщики закончат >формирование полного описания модели - которую как раз и можно >оптимизировать - очень рискованное решение, связанное с большими >потерями драгоценного времени. На практике проектировщики делают >одну-две-три начальные итерации и выделяют максимально >независимые фрагменты, которые нужно делать "в любом случае". >Естественно, при более детальном изучении модели может оказаться, >что эти фрагменты можно резко упростить, слить или, наоборот, >разделить - но время кодеров уже можно использовать на создание >этих участков, которые "с высокой вероятностью" будут нужны >в конечном варианте системы. Для этих участков максимально >чётко описывается интерфейс, и кодеры приступают к работе. >Естественно, система получается не "оптимальной", и вероятность >внесения изменений в спецификацию высока - но время, которого >всегда мало, используется более эффективно. Правда, нервов >на такую работу уходит сущая прорва. > Да-да. Именно так. Сейчас это очень модно -- Unified Software Development Process. Разработка методом эволюционирующих прототипов. Но я-то как раз говорю о том, что эта заведомая "избыточность" может быть заменена на "сухую необходимость", а высвобождаемые в результате этого временные ресурсы могут пойти на оптимизацию. Нужно искать мастеров, которые могут справиться с этой задачей. В одной голове. При этом исчезают весьма неслабые потери на "трение общения". Опять экономим время. Но здесь мы в полной зависимости от мастера. А какому капиталисту это понравится? Правильно. Мало какому. А именно тому, который научился работать с мастерами. Который понимает, что команда из трех человек может быть сильнее (в смысле производительнее), чем из тридцати или из трехсот. Как в фильме "формула любви": что нужно сделать мастеру, чтобы починить карету за день? За два? За неделю? И тут получается капкан: с одной стороны, рынок таких "смекалистых" капиталистов мал, т.е. нет никакого смысла ориентировать на него "брендовые" теории, с другой, отсутствие таких теорий приводит "общую массу" в фиксированное на одном подходе состояние. >Так вот, "избыточные" возможности C++ оказываются порой совершенно >необходимы, когда приходится срочно изменять поведение системы >в аспектах, практически не предусмотртенных первоначальным >дизайном кода и с минимальными изменениями уже написанных фрагментов >(результат обычно нужен вчера - так что на писанину времени заведомо >нет). Чего-то подобного можно добиться на C с помощью макросов, но >результат получается несопровождаемый. > Точно так. И это правда. Но в этом-то и состоит корень зла: "легкое" внесение изменений таит в себе привыкание к тому, что их потом можно вносить и вносить. И вроде как все работает. Но это совершенно не так: изменения, не предусмотренные в дизайне, становятся очередным гвоздем в крышке надежности, сопровождаемости и отчуждаемости. А пагубная привычка "зачем тратить время сейчас? внесем изменения по мере необходимости" поразила практически 100% современных программеров. Такая точка зрения стала настолько расхожим стереотипом, что иное встречает почти повсеместное раздражение. > >Когда-то я тоже считал, что ряд конструкций C++ можно выбросить из >языка без ущерба для его полезных свойств, но с явным сокращением >головной боли при программировании на нём. Однако со временем >всё чаще мне стали попадаться примеры, в которых отсутствие >той или иной "лишней" конструкции создало бы впечатление >ущербности языка. > Когда-то я тоже был "болен" ООП -- считал его панацеей. Слава Богу, со временем мне удалось сложить другое мнение. > >Есть масса Copy+Paste программистов, которые пишут на Java, потому что >это якобы просто - якобы намного проще, чем на C++. При этом >эти >самые программисты обычно попросту не в курсе, что для разработки >больших и сильно связных систем Java - не очень удобный язык, как >в >силу ряда языковых особенностей, провоцирующих "каскады изменений" >при внесении относительно мелких первоначальных коррекций, так и >из-за недостаточного детерминизма поведения виртуальной машины, >которое сильно зависит от капризов вендора и используемых настроек. > >Се беда человеческая, и идеология того или иного языка здесь >вопрос, на мой взгляд, вторичный. > Совершенно верно -- человеческая. Но у этой беды есть предпосылки. И, возможно, они находятся "выше" идеологий конкретно взятых языков. > >На "чистом" C у них, по крайней мере, получался "чистый" и почти >не содержащий глупых ошибок код. Так что я никоим образом не считаю >их квалификацию низкой. Просто по независящим от них причинам эти >разработчики применяли "не тот" инструмент. > В таком случае -- это лучшая иллюстрация моего посыла: не языком (программирования) силен человек, а тем местом, куда он ест. Не важно, на чем он пишет, важно -- как он думает. И получается, что задача научить людей думать правильно (принимать наилучшие проектные решения из всех доступных) -- может иметь решение. >> >>тихо, но используют С++ -- согласен. но малочисленность таких >>отделов и их закрытость сыграют с С++ такую же шутку, как они сыграли с >>другими ушедшими в историю языками. это всего-лишь переходный этап. >> > >Не всё так плохо. Объём существующего кода на C++ колоссален, >никто не даст просто так похоронить сделанные в этот код вложения >сил и средств. Вдобавок то самое спорное компромиссное решение, >обеспечившее высокую степень совместимости с C, продолжает >работать на живучесть языка. И, честно говоря, я не вижу серьёзной >замены C++ даже с технологической точки зрения: нигде наличие >столь изощрённых средств для описания абстракций не сочетается >со столь богатыми возможностями тюнинга наиболее критичных по >производительности участков - вплоть до использования >ассемблерных вставок. > Позвольте с Вами не согласиться: тюнить нужно алгоритмы, заниматься оптимизацией моделей, писать "красивые" (читаемые, поддерживаемые, отчуждаемые) программы. "Байты" тюнить (наличие ассемблерных вставок) -- вещь, на мой взгляд, экзотитеская. Связанная с какими-то зубодробительными (и страшно стабильными) алгоритмами, которые по сути можно вынести в отдельные либы. >>в чем состоит критерий его (проектирования) "нереализуемости"? >>может быть с ним как-то связана "невозможность формирования >>функционального описания"? >> > >Я писал не о невозможности формирования функционального описания, >а о том, что периодически приходится сталкиваться с аккуратно >сформированными функциональными описаниями систем, абсолютно >не реализуемых имеющимися в наличии разработчиками, в указанный >срок, либо - в совсем клинических случаях - в принципе, в силу >наличия неявных противоречий в самом описании. Позвольте, но Вы ведь говорите о содержании самих описаний, т.е. язык, с помощью которого они созданы, не имеет значения. Но мне показалось что Вы говорили об обратном, о том, что язык имеет значение. Я был удивлен этим и, честно говоря, если Вы так не считаете, то вопрос отпадает. > >Почему-то в России (не знаю, как с этим дело в Буржуиниях) >довольно часто встречаются "специалисты по проектированию", >которые не считают необходимым учитывать возможности и опыт >остальной команды и решают каждую задачу так, как будто >весь предыдущий опыт совместной работы отсутствует. Они обычно >прикрываются красивым выражением "идти от задачи"; в результате >же предложенные ими варианты решения практически каждый раз >вовлекают всё новые и новые инструменты, реальная же >потребность в них порой нулевая. > >Характерной особенностью таких пресонажей является устойчивая >привычка формулировать свои мысли на "естественном языке" и >практически полная неспособность излагать свои мысли на языке >формальном. Что делает их идеальными кандидатами на работу в >команде документирования, куда сами они (парадокс!) идти >никак не хотят. Как раз о них и был мой предыдущий комментарий. > Есть такие специалисты. Я с ними встречался и в западных компаниях. Таким образом получается, что это интернациональное достояние. Описываемый Вами факт -- что они вовлекают в процесс разработки все новые и новые инструменты -- может говорить о многом. В частности о том, что речь скорее всего не идет о какой либо оптимизации. Возможно, речь идет о раздувании собственной значимости, раскрутке собственного бренда, попытке освоить новые инструменты за чужой счет и, наверное, еще о чем-нибудь. > >> >>не совсем. в рутинно-сложных системах, к которым можно отнести банковские, >>биллинговые, ERP, CRM и какие-то-другие-не-знаю-какие -- автоматная >>модель отлично ложится на объекты управления. когда требуется управляющий >>объект с предисторией -- это ли не конечный автомат? > >Формально всё вроде бы правильно. Про биллинги и прочее ничего не >скажу, а вот банковских систем я повидал немало. Вся задача там >отчётливо делится на три участка: > >1. Математически сложные фрагменты (клиринг и прочее в том >же духе), в которых сложна именно математика, а собственно >программа есть реализация формально описанного алгоритма. >Здесь описание в форме конечного автомата не слишком полезно, >так как по большому счёту у таких подсистем всего два состояния: >задача подана - задача решена. > >2. Формальные процедуры приёма документов, сверка, движение >по счетам, генерация уведомлений. Здесь обычно всё заранее >определено многочисленными и сверхподробными инструкциями, >которые не дают сделать в сторону ни шагу. Поскольку инструкции >у нас всё время помаленьку ползут, структуру кода желательно >сделать аналогом структуры инструкций - так проще локализовать >изменения. То есть описание такого "автомата" уже сделано >в тех самых инструкциях. > >3. Приложения анализа данных. Здесь сложность двойная. >Непросто определить, как именно проводить анализ (цепочка >цели-метод-результат весьма нетривиальна). И математически >сложна реализация многих применяемых методов с приемлемой >производительностью. > Весьма любопытный анализ состава банковских систем: краткий и в то же время внятный. Но все-таки я осмелюсь кинуть небольшой камушек в Ваш огород: Вы ничего не сказали об объектах-координаторах. Ведь нужно как-то координировать логику? С тем же банкоматом -- какая тут может быть координация без предистории? И, скорее всего, есть какой-нибудь менеджер транзакций, который обслуживает нетривиальные бизнес-процессы, в которых тоже нужна предистория. Где возможен граф переходов -- возможен и автоматный подход. С формальными процедурами приема документов -- тоже возможны конечные автоматы. Генераторы конечных автоматов в лице lex+yacc -- чем не способ?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	107. "Си или Си ++?"
	Сообщение от DeadMustdie (??) on 30-Авг-04, 21:22  (MSK)
	>Таким образом может оказаться, что не столько глубокие знания >инструмента определят успех, сколько подход к работе как к >совокупности этапов проектирования, кодирования, тестирования >и имплементации. Т.е. своеобразный системный подход, который >как раз исключает специализацию в одном направлении за счет других. > В данном вопросе я закоренелый пессимист. Набрать команду подобного уровня на некрупный проект средней продолжительности за средние деньги нереально. Постоянное содержание такой команды предполагает наличие постоянного потока _очень_ дорогих проектов. Никогда не видел. Что, разумеется, не доказывает, что такого вообще не бывает :). В России сейчас очень ловко торгуют коробками... > >Вы привели отличные, с моей точки зрения, допущения. >Только дело в том, что я вопрос этот задал не Вам лично, >а как бы в качестве иллюстрации к тому, какие вопросы могут >последовать (и обычно следуют) при "презентации курса обучения". >Т.е. из-за того, что существуют такого рода допущения, есть >формальная возможность задавать вопросы. > Подходы (как и цели) могут быть разные, отсюда и возможность для возникновения вопросов. >Так о том и речь -- не зянял бы. А если бы >он действительно не занял -- может быть в доминанты вышел бы >другой, более изящный с концептуальной точки зрения язык? > Когда разработка поставлена на поток, начинают "играть" скорее своего рода инженерные свойства языка, нежели его концептуальная стройность. С этой точки зрения C++ весьма трудно побить. > >Именно так. А если быть еще точнее, то "в стремление снизить влияние >фактора <рука мастера>". Т.е. другими словами в стремление снизить >влияние человеческого фактора. Многим бы очень сильно хотелось, чтобы >программы проектировались не зависимо от того, кто их проектирует. > Разве что в предельном случае, который в этой ситуации - вырожденный :). В чистом виде переход от ремесленного искусства к промышленному производству. > >Да-да. Именно так. Сейчас это очень модно -- Unified Software >Development Process. >Разработка методом эволюционирующих прототипов. > Очень Сильно Не Люблю. Избыточно до безобразия. Лично мне гораздо больше импонируют eXtrem-исты. >Но я-то как раз говорю о том, что эта заведомая "избыточность" может >быть заменена на "сухую необходимость", а высвобождаемые в результате >этого временные ресурсы могут пойти на оптимизацию. Нужно искать >мастеров, которые могут справиться с этой задачей. В одной голове. >При этом исчезают весьма неслабые потери на "трение общения". >Опять экономим время. >Но здесь мы в полной зависимости от мастера. >А какому капиталисту это понравится? > >Правильно. Мало какому. А именно тому, который научился работать с >мастерами. Который понимает, что команда из трех человек может быть >сильнее (в смысле производительнее), чем из тридцати или из трехсот. >Как в фильме "формула любви": что нужно сделать мастеру, чтобы >починить карету за день? За два? За неделю? > Если у вас есть X проектов на общую сумму Y USD, то вы можете сформировать "бюджет развития" не более, чем на Y минус текущие расходы. "Притирка" даже квалифицированной команды занимает время, в течение которого всем нужно платить зарплату. Так что описанную Вами песню зачастую не даёт петь грубая проза жизни. >И тут получается капкан: с одной стороны, рынок таких "смекалистых" >капиталистов мал, т.е. нет никакого смысла ориентировать на него >"брендовые" теории, с другой, отсутствие таких теорий приводит "общую >массу" в фиксированное на одном подходе состояние. > Капкан здесь ещё более жёсткий. Для организации таких "мастерских" требуется большой стартовый капитал. Те, у кого он есть, не желают рисковать - местный рынок и без того напоминает рулетку. > >Точно так. И это правда. Но в этом-то и состоит корень зла: >"легкое" внесение изменений таит в себе привыкание к тому, что их >потом можно вносить и вносить. И вроде как все работает. Но >это совершенно не так: изменения, не предусмотренные в дизайне, >становятся очередным гвоздем в крышке надежности, сопровождаемости и >отчуждаемости. >А пагубная привычка "зачем тратить время сейчас? внесем изменения по >мере необходимости" >поразила практически 100% современных программеров. Такая точка >зрения стала настолько расхожим >стереотипом, что иное встречает почти повсеместное раздражение. > Всё это не от хорошей жизни. Лучше плохой, но работающий код сегодня, чем замечательный в светлом, но далёком завтра. > >Когда-то я тоже был "болен" ООП -- считал его панацеей. Слава Богу, >со временем мне удалось сложить другое мнение. > Как писал один умный америкос, "серебряной пули не бывает". >Совершенно верно -- человеческая. Но у этой беды есть предпосылки. >И, возможно, они находятся "выше" идеологий конкретно взятых языков. > Весьма вероятно. > >В таком случае -- это лучшая иллюстрация моего посыла: не языком >(программирования) силен человек, а тем местом, куда он ест. >Не важно, на чем он пишет, важно -- как он думает. > >И получается, что задача научить людей думать правильно >(принимать наилучшие проектные решения из всех доступных) >-- может иметь решение. > Я не жадный. Меня устроит работа с людьми, способными принимать в своей области хотя бы _приемлемые_ решения. > >Позвольте с Вами не согласиться: тюнить нужно алгоритмы, заниматься >оптимизацией моделей, писать "красивые" (читаемые, поддерживаемые, >отчуждаемые) программы. "Байты" тюнить (наличие ассемблерных вставок) >-- вещь, на мой взгляд, экзотитеская. Связанная с какими-то >зубодробительными (и страшно стабильными) алгоритмами, которые по сути >можно вынести в отдельные либы. > Так оно обычно и делается. Собственно, не вижу противоречий с тем, что я писал выше. > >Весьма любопытный анализ состава банковских систем: краткий и в то же >время внятный. >Но все-таки я осмелюсь кинуть небольшой камушек в Ваш огород: Вы ничего >не сказали об объектах-координаторах. >Ведь нужно как-то координировать логику? >С тем же банкоматом -- какая тут может быть координация без предистории? > Логика работы отдельно стоящего банкомата проста, и сам он (насколько мне известно) не контролирует предысторию. Контрольная функция обычно строится поверх централизованной системы, которая обрабатывает поступающие от банкоматов сообщения. И там действительно вполне могут быть средства, в реальном времени отслеживающие изменения в состоянии всей системы в целях обнаружения, скажем, жульничества. >И, скорее всего, есть какой-нибудь менеджер транзакций, >который обслуживает нетривиальные бизнес-процессы, в >которых тоже нужна предистория. Где возможен граф переходов -- >возможен и автоматный подход. > Такое делают _очень_ по разному. Здесь всё обычно упирается в масштабируемость, то есть обеспечиваемую степень параллелизма алгоритмов. Так что не столько автомат получается, сколько набор параллельно функционирующих таких автоматов с точками обмена информацией и соответствующими изменениями состояния. >С формальными процедурами приема документов -- >тоже возможны конечные автоматы. Там логика обычно совершенно линейная. Документ либо правильный, либо нет. Подпись или правильная, или подложная. Платёж либо проходит, либо отбрасывается. Доступно ученикам 5 класса средней школы и оформлено дубовой, не допускающей двойной трактовки, инструкцией. Конечный автомат получится не слишком интересный. >Генераторы конечных автоматов в лице lex+yacc -- чем не способ? Формат входных данных непригодный. Не текстовый. А если текстовый - то требующий слишком сложного разбора (обычно XML).
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	108. "Си или Си ++?"
	Сообщение от proff (??) on 30-Авг-04, 23:46  (MSK)
	> >В данном вопросе я закоренелый пессимист. Набрать команду подобного >уровня на некрупный проект средней продолжительности за средние >деньги нереально. Постоянное содержание такой команды предполагает >наличие постоянного потока _очень_ дорогих проектов. Никогда не видел. >Что, разумеется, не доказывает, что такого вообще не бывает :). >В России сейчас очень ловко торгуют коробками... > Когда есть небольшое предприятие, где у каждого мастера свой кусочек пирога -- есть тот самый повод собраться вместе. По всей видимости Вы работали в достаточно больших, стабильных организациях. Это как раз противоположный случай. > >Разве что в предельном случае, который в этой ситуации - вырожденный :). >В чистом виде переход от ремесленного искусства к промышленному >производству. > Такая постановка вопроса с переходом была в свое время констатацией факта, когда на горизонте еще не маячили индусы. Но сейчас они уже не только на горизонте, они в Сети. Конкурировать с ними на чистой моторике, которая предполагается тем самым "промышленным производством" -- сущая глупость, т.к. их себестоимость будет заведомо ниже, чем наша. Там, в Бангалоре, готовы работать буквально за еду. Здесь в Москве -- это абсолютно не возможно. Нам сейчас нужны конкурентные преимущества. Умение принимать лучшие решения из множества возможных в конкретной ситуации -- думаю, в этом что-то интересное есть. > >Очень Сильно Не Люблю. Избыточно до безобразия. Лично мне гораздо >больше импонируют eXtrem-исты. > А что они стоят эти eXtrem-исты? В чем новизна их подхода? > >Если у вас есть X проектов на общую сумму Y USD, то >вы можете >сформировать "бюджет развития" не более, чем на Y минус текущие >расходы. "Притирка" даже квалифицированной команды занимает время, >в течение которого всем нужно платить зарплату. Так что описанную >Вами песню зачастую не даёт петь грубая проза жизни. > Притирка занимает года. По этому кто-то сбивается в стаи, а кто-то ходит от одного работодателя к другому, в поисках куска "пожирнее". Тот кто сбивается -- имеет определенную финансово-интеллектуальную выгоду, работая в команде "своих". Тот кто не хочет сбиваться -- имеет вместо команды прозу жизни. (я не в коем мере не имел ввиду лично Вас) > >Капкан здесь ещё более жёсткий. Для организации таких "мастерских" >требуется большой стартовый капитал. Те, у кого он есть, не желают >рисковать - местный рынок и без того напоминает рулетку. > Все начинается с хобби. За хобби платит тот, кто его имеет. Люди сбиваются в стаи, потому что их тянет к единомышленникам. Это все пока бесплатно. Когда из хобби что-то получается, что можно потрогать/показать -- появляются деньги. > >Всё это не от хорошей жизни. Лучше плохой, но работающий код сегодня, >чем замечательный в светлом, но далёком завтра. > Когда планирование ужасно -- это успокаивающая точка зрения. Когда с ним все в порядке, -- уже спроектированы структуры данных и интерфейсы, которые осталось обвязать кодом. А это не так трудоемко. > >Я не жадный. Меня устроит работа с людьми, способными принимать в >своей области хотя бы _приемлемые_ решения. > Есть индусы, которые думают именно так, строят свою стратегию выживание именно на этом: мы не лучшие, мы достаточно хорошие. Но при этом стоим о-о-о-о-очень дешево. > >Так оно обычно и делается. Собственно, не вижу противоречий с тем, >что я писал выше. Либы можно писать на другом языке. >Логика работы отдельно стоящего банкомата проста, и сам он (насколько >мне известно) не контролирует предысторию. Контролирует. Только слишком короткую. В рамках одной сессии (сеанса работы с картой). > >Такое делают _очень_ по разному. Здесь всё обычно упирается в >масштабируемость, то есть обеспечиваемую степень параллелизма >алгоритмов. Так что не столько автомат получается, сколько >набор параллельно функционирующих таких автоматов с точками >обмена информацией и соответствующими изменениями состояния. Да, именно так -- параллельно функционирующих АВТОМАТОВ. > >Там логика обычно совершенно линейная. Документ либо правильный, >либо нет. Подпись или правильная, или подложная. Платёж либо >проходит, либо отбрасывается. Доступно ученикам 5 класса >средней школы и оформлено дубовой, не допускающей двойной трактовки, >инструкцией. Конечный автомат получится не слишком интересный. > Согласен -- что уж в нем интересного? Но автоматы-то мы используем не для интереса, а чтобы работу себе уменьшить. >>Генераторы конечных автоматов в лице lex+yacc -- чем не способ? > >Формат входных данных непригодный. Не текстовый. А если текстовый - >то требующий слишком сложного разбора (обычно XML). Хм... А вопрос синтаксического разбора программы -- он не сложный? Собственно lex+yacc изначально появились для этого. YACC -- Yet Another Compiler Compiler -- еще один компилятор компилаторов. Красивое название ;-)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	109. "Си или Си ++?"
	Сообщение от SergeiZz on 31-Авг-04, 15:13  (MSK)
	>Когда есть небольшое предприятие, где у каждого мастера свой кусочек пирога -- >есть тот самый повод собраться вместе. Обычно нужен ещё и инвестор... >Нам сейчас нужны конкурентные преимущества. >Умение принимать лучшие решения из множества возможных в конкретной ситуации -- думаю, >в этом что-то интересное есть. "Лучшие решения" можно понимать по-разному. Лучшие всегда относительно какой-то ситуации. Проще всего считать лучшим решением то, которое удовлетворит заказчика. Если так, то "умение принимать лучшие решения" -- это не только умение грамотно разработать. Дядя Билли мог бы, наверное, многое нам рассказать по поводу его понимания лучших решений... >>Очень Сильно Не Люблю. Избыточно до безобразия. Лично мне гораздо >>больше импонируют eXtrem-исты. >> > >А что они стоят эти eXtrem-исты? >В чем новизна их подхода? Ну, как они сами обычно утверждают, новизна в том и состоит, что они довели до экстремума самые прописные истины. На мой взгляд, XP -- это всё-таки больше рецепт организации проектирования/реализации/сопровождения, чем технология проектирования. >Притирка занимает года. Замечу, что у инвестора есть только месяцы... >>Капкан здесь ещё более жёсткий. Для организации таких "мастерских" >>требуется большой стартовый капитал. Те, у кого он есть, не желают >>рисковать - местный рынок и без того напоминает рулетку. >> > >Все начинается с хобби. За хобби платит тот, кто его имеет. Люди >сбиваются в стаи, потому что их тянет к единомышленникам. Это все >пока бесплатно. Когда из хобби что-то получается, что можно потрогать/показать -- >появляются деньги. Всё движение Open Source -- такое хобби. Но для подобной хоббисткой органицации процесса начальной "притирки" (как и для Open Source) очень характерна стихийность и неуправляемость. Это будет работать (и уже работает) достаточно успешно, если участников объединяет нечно большее, чем просто проффессиональный интерес (давнее крепкое знакомство, что угодно, но более крепкое и менее корыстное). Я знаю пару случаев, когда подобные коллективы странным образом распадались в момент, когда начинали появляться деньги. Я думаю, что именно из-за денег это и происходило. >>>Генераторы конечных автоматов в лице lex+yacc -- чем не способ? >> >>Формат входных данных непригодный. Не текстовый. А если текстовый - >>то требующий слишком сложного разбора (обычно XML). > >Хм... А вопрос синтаксического разбора программы -- он не сложный? >Собственно lex+yacc изначально появились для этого. >YACC -- Yet Another Compiler Compiler -- еще один компилятор компилаторов. >Красивое название ;-) Я плохо понимаю, к чему тут yacc и синтаксический анализ к этому месту вашей (множественное число) любопытной беседы. Можно поподробнее (желательно оба, а то я туповат от природы), если не трудно? Как я понимаю, приводится пример, где автоматщина может оказаться полезна. Или речь о другом?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	111. "Си или Си ++?"
	Сообщение от DeadMustdie (??) on 31-Авг-04, 19:43  (MSK)
	>"Лучшие решения" можно понимать по-разному. Лучшие всегда относительно >какой-то ситуации. Проще всего считать лучшим решением то, которое >удовлетворит заказчика. Если так, то "умение принимать лучшие решения" >-- это не только умение грамотно разработать. Дядя Билли мог бы, >наверное, многое нам рассказать по поводу его понимания >лучших решений... > За такой рассказ он попросит очень много денег. >Ну, как они сами обычно утверждают, новизна в том и состоит, что >они довели до экстремума самые прописные истины. >На мой взгляд, XP -- это всё-таки больше рецепт организации >проектирования/реализации/сопровождения, чем технология >проектирования. > Под этот рецепт в каждом частном случае необходимо подбирать технологии. Иначе работать не будет. >Всё движение Open Source -- такое хобби. Но для подобной хоббисткой >органицации процесса начальной "притирки" (как и для Open Source) очень >характерна стихийность и неуправляемость. Это будет работать (и уже >работает) достаточно успешно, если участников объединяет нечно большее, >чем просто проффессиональный интерес (давнее крепкое знакомство, что >угодно, но более крепкое и менее корыстное). >Я знаю пару случаев, когда подобные коллективы странным образом >распадались в момент, когда начинали появляться деньги. Я думаю, что >именно из-за денег это и происходило. > Есть другая сторона медали. Вендоры очень боятся оказаться в зависимости друг от друга, что мешает им напрямую войти в кооперацию. Крупный OpenSource проект, в рамках которого развивается нечто, нужное множеству таких вендоров, они очень даже готовы финансировать. Совместно. Что абсолютно немыслимо в других ситуациях. >Я плохо понимаю, к чему тут yacc и синтаксический анализ к этому >месту вашей (множественное число) любопытной беседы. Можно поподробнее >(желательно оба, а то я туповат от природы), если не трудно? >Как я понимаю, приводится пример, где автоматщина может оказаться >полезна. Или речь о другом? Компиляция предполагает разбор синтаксиса программы на некоем языке в соответствии с заданной грамматикой. Решение такой задачи есть хрестоматийный пример конечного автомата: есть текущее состояние компилятора, есть вход - текст программы - который это состояние изменяет, и есть выход - машинный код, например, который генерируется по достижении компилятором некоторых состояний.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	110. "Си или Си ++?"
	Сообщение от DeadMustdie (??) on 31-Авг-04, 19:33  (MSK)
	> >Когда есть небольшое предприятие, где у каждого мастера свой кусочек >пирога -- есть тот самый повод собраться вместе. >По всей видимости Вы работали в достаточно больших, стабильных >организациях. Это как раз противоположный случай. > Скорее в организациях, пытающихся поднять большой объём не очень хорошо оплачиваемых работ малыми силами. Попытка поделить пироги в таких условиях безнадёжна, так пирогов, требующих присмотра, намного больше, чем людей. Вдобавок почему-то очень немного возникает "стабильных видов" оных пирогов, которые возникали бы регулярно. Подозреваю, впрочем, что процесс шёл бы лучше, если бы был лучше организован. Сам я в данной области не столько профан (в теории мы все сильны :) ), сколько безручье. > >Такая постановка вопроса с переходом была в свое время констатацией >факта, когда на горизонте еще не маячили индусы. >Но сейчас они уже не только на горизонте, они в Сети. >Конкурировать с ними на чистой моторике, которая предполагается >тем самым "промышленным производством" -- сущая глупость, т.к. их >себестоимость будет заведомо ниже, чем наша. > >Там, в Бангалоре, готовы работать буквально за еду. Здесь в Москве -- >это абсолютно не возможно. > Очень сильно качество страдает. В качестве примера можно вспомнить тот же ORACLE свежайших версий. Много кто громко матерится. А уж что индусы с Апачем, в ORACLE AppServer встроенным, сделали... >Нам сейчас нужны конкурентные преимущества. >Умение принимать лучшие решения из множества возможных в конкретной >ситуации -- думаю, в этом что-то интересное есть. > Как лозунг, идея и лейбл - да, вероятно. Для привлечения того самого инвестора на стадии, когда в нём возникает реальная потребность. По-настоящему удачные проектные решения зачастую оказываются своего рода "идеальным компромиссом". Поиску таких компромиссов, по-моему, даже научить нереально - какое-то чутьё должно работать. Мало у кого оно есть. > >А что они стоят эти eXtrem-исты? >В чем новизна их подхода? > Объяснять долго и тяжело. Вот, вроде бы, неплохой ресурс: http://www.extremeprogramming.org/. На первый взгляд, идеальная методология для индусов. На практике же для того, чтобы поддержать должный порядок в предлагаемом этими "экстремалами" бардаке нужно обеспечить очень высокое качество кода от каждого из разработчиков. >Притирка занимает года. По этому кто-то сбивается в стаи, а кто-то ходит >от одного работодателя к другому, в поисках куска "пожирнее". >Тот кто сбивается -- имеет определенную финансово-интеллектуальную >выгоду, работая в команде "своих". > >Тот кто не хочет сбиваться -- имеет вместо команды прозу жизни. (я >не в коем мере не имел ввиду лично Вас) > У меня в этом плане пока получается специфический вариант - бродим всей ватагой (почти не шутка). > >Все начинается с хобби. За хобби платит тот, кто его имеет. Люди >сбиваются в стаи, потому что их тянет к единомышленникам. Это все >пока бесплатно. Когда из хобби что-то получается, что можно >потрогать/показать -- появляются деньги. > Это нужно сначала такую работу найти, чтобы денег на жизнь хватало и на хобби время + силы оставались. У меня пока не получилось :). > >Когда планирование ужасно -- это успокаивающая точка зрения. >Когда с ним все в порядке, -- уже спроектированы структуры данных и >интерфейсы, которые осталось обвязать кодом. А это не так трудоемко. > "Ужасное" планирование зачастую возникает под действием внешних факторов. Когда практически в любой момент (включая "за неделю до сдачи") может объявиться добрый дядя с нехилой пачкой дополнительных требований. Или когда заказчик сам не понимает, чего ему надо, и действует, с одной стороны, по принципу "принесите мне чего-нибудь на эту тему - я посмотрю", а с другой - требует к концу срока работ "живую" и приносящую пользу систему. > >Есть индусы, которые думают именно так, строят свою стратегию >выживание именно на этом: мы не лучшие, мы достаточно хорошие. >Но при этом стоим о-о-о-о-очень дешево. > По моим наблюдениям, они "достаточно хороши" примерно настолько же, насколько дёшевы. Уж больно падает качество продуктов у фирм, перешедших на модель с индийским аутсорсингом. Это при том, что контроль качества обычно используют свой, не индийский, и вдобавок многократно его усиливают перед совершением такого перехода. > >Либы можно писать на другом языке. > Дело вкуса. >Контролирует. Только слишком короткую. В рамках одной сессии >(сеанса работы с картой). > Соответственно, и логика настолько проста, что формально представлять её в виде автомата, мне кажется, излишне. > >Да, именно так -- параллельно функционирующих АВТОМАТОВ. > Ну и? Представлять подобную схему можно как угодно. Не самый плохой вариант - в виде набора "активных объектов" с определёнными интерфейсами и заданным графом переходов состояний. > >Согласен -- что уж в нем интересного? >Но автоматы-то мы используем не для интереса, а чтобы работу себе >уменьшить. > Ну если средства какие-то применить, которые будут код рутинного контроля переходов состояний по заданным условиям генерировать - тогда да, конечно. >>Формат входных данных непригодный. Не текстовый. А если текстовый - >>то требующий слишком сложного разбора (обычно XML). > >Хм... А вопрос синтаксического разбора программы -- он не сложный? >Собственно lex+yacc изначально появились для этого. >YACC -- Yet Another Compiler Compiler -- еще один компилятор >компилаторов. Красивое название ;-) Мне в руки как-то попал рекламный проспект отечественного компилятора C++, созданного как раз на основе yacc. Как сами же разработчики признавались на страницах оного опуса, с большим трудом смогли они уместить грамматику языка в возможности yacc. И меня до сих пор не оставляет подозрение, что всё же полного набора тестов на стандартность их компилятор не пройдёт. При всей внешней простоте, XML - язык достаточно сложный. И разбор лексем там - самая простая часть всей работы.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	112. "Си или Си ++?"
	Сообщение от klalafuda on 31-Авг-04, 21:31  (MSK)
	>Мне в руки как-то попал рекламный проспект отечественного компилятора >C++, созданного как раз на основе yacc. Как сами же разработчики >признавались на страницах оного опуса, с большим трудом смогли они >уместить грамматику языка в возможности yacc. И меня до сих пор не >оставляет подозрение, что всё же полного набора тестов на стандартность >их компилятор не пройдёт. эти пЫонЭры случаем не с gcc.gnu.org ? $ find /usr/src/gnu/dist/gcc/ -type f -name \*.y -exec du -k {} \; 128     /usr/src/gnu/dist/gcc//gcc/cp/parse.y 92      /usr/src/gnu/dist/gcc//gcc/c-parse.y 7       /usr/src/gnu/dist/gcc//gcc/gengtype-yacc.y 9       /usr/src/gnu/dist/gcc//gcc/intl/plural.y 120     /usr/src/gnu/dist/gcc//gcc/objc/objc-parse.y 26      /usr/src/gnu/dist/gcc//gcc/treelang/parse.y // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	113. "Си или Си ++?"
	Сообщение от DeadMustdie (??) on 31-Авг-04, 21:49  (MSK)
	> >эти пЫонЭры случаем не с gcc.gnu.org ? > >$ find /usr/src/gnu/dist/gcc/ -type f -name \*.y -exec du -k {} \; > >128     /usr/src/gnu/dist/gcc//gcc/cp/parse.y >92      /usr/src/gnu/dist/gcc//gcc/c-parse.y >7       /usr/src/gnu/dist/gcc//gcc/gengtype-yacc.y >9       /usr/src/gnu/dist/gcc//gcc/intl/plural.y >120     /usr/src/gnu/dist/gcc//gcc/objc/objc-parse.y >26      /usr/src/gnu/dist/gcc//gcc/treelang/parse.y > $ cd /opt/Build/gcc-3.4.0 $ find . -name '*.y' ./gcc/gengtype-yacc.y ./gcc/java/parse-scan.y ./gcc/java/parse.y ./gcc/objc/objc-parse.y ./gcc/treelang/parse.y ./gcc/c-parse.y ./intl/plural.y Нетрудно заметить, что gcc/cp/parse.y исчез с экранов радара. Современная версия g++ не использует yacc/lex.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	114. "Си или Си ++?"
	Сообщение от klalafuda on 31-Авг-04, 22:45  (MSK)
	>$ cd /opt/Build/gcc-3.4.0 >$ find . -name '*.y' >./gcc/gengtype-yacc.y >./gcc/java/parse-scan.y >./gcc/java/parse.y >./gcc/objc/objc-parse.y >./gcc/treelang/parse.y >./gcc/c-parse.y >./intl/plural.y > >Нетрудно заметить, что gcc/cp/parse.y исчез с экранов радара. >Современная версия g++ не использует yacc/lex. $ gcc --version gcc (GCC) 3.3.3 (NetBSD nb3 20040520) современная - это боевая :) 3.4 станет ею по мере внесения в дистрибутивы. но дело не современной/старой версии. 2.95.3 для кого-то вполне современная версия, зависит от платформы. а в целом, gcc team умудрился запихать синтаксис c/c++ на yacc и, судя по результату, вполне успешно. ps: в dragon book от Ахо в приложении приводится почти полный синтаксис c++ почти на yacc. наверное, не просто так. // wbr
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	115. "Си или Си ++?"
	Сообщение от DeadMustdie (??) on 01-Сен-04, 20:07  (MSK)
	Выдержка из списка изменений для серии 3.4.x: A hand-written recursive-descent C++ parser has replaced the YACC-derived C++ parser from previous GCC releases. The new parser contains much improved infrastructure needed for better parsing of C++ source codes, handling of extensions, and clean separation (where possible) between proper semantics analysis and parsing. The new parser fixes many bugs that were found in the old parser. Компиляторы линейки 2.95 далеко не во всём соответствуют стандарту. А серия 3.4 - очень большой шаг вперёд; на мой взгляд, объём внесённых усовершенствований при переходе с 3.3 на 3.4 примерно эквивалентен объёму их же при переходе с 2.95 на 3.3.
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	106. "Си или Си ++?"
	Сообщение от SergeiZz on 30-Авг-04, 19:59  (MSK)
	>2DeadMustdie: >спасибо за труд: Вы внятно высказали свое мнение. я получил массу удовольствия, >читая Ваш пост. Присоединяюсь. Вы в научнопопулярные издания пишите? Если нет, то стоит об этом подумать... >но передо мной, в силу определенных обстоятельств, стоит несколько другая задача -- >научить людей не просто думать, а думать правильно, т.е. принимать наилучшие >решения из всех возможных. Строго говоря, в такой постановке это уже несколько иная задача. Принято считать, что учащемуся нужно дать некоторый объём фундаментальных зний + научить думать. Научиться находить оптимальное решение (и что более важно -- выроботать привычку искать такое решение) он должен сам и по большей части на практике. >именно по этому я говорю об альтернативах, которые специалист должен знать. ведь >ему нужно не просто решить задачу, а быть уверенным в том, >что она решена наилучшим образом. Будучи логичной, такая точка зрения ("нужно обязательно найти оптимальное решение") довольно опасна. Лучшее, как известно, враг хорошего. Как всегда, всего хорошо в меру: не стоит ставить самоцелью поиск абсолютно оптимального решения. Да жизнь и не даст этим заниматься. К слову, по моему C++ в этом смысле как раз являет "хорошее" решение, не претендуя на "лучшее". >>Критерии подбора инструментов для обучения есть вопрос спорный. > >это не просто спорный вопрос -- это "ахиллесова пята всех курсов обучения". > >"ахиллесова" потому, что базируется на допущениях. >обоснуйте, почему вы сделали такие допущения? можно тупить (или умнить) таким образом >до бесконечности... Если начать даже очень приблизительно обдумывать принципы, по которым нужно было бы разрабатывать учебные курсы, мгновенно всплывут проблемы позаумнее даже этой. >>Как полагаете, может, >>Ada сгодится? Или Eiffel? > >ничего не могу сказать. к моему стыду я ими не владею. Я работаю с Ruby, синтаксис которого напоминает Eiffel. Моё мнение такое. Ни Ada, ни Eiffel не содержат, грубо говоря, чего-то такого, чего нет (с этой точки зрения) в C++. >>1. Совместимость C++ с C позволила на ранних этапах обеспечить >>преемственность кода, обеспечила лёгкость взаимодействия нового кода >>на C++ со старым на C и вообще интеграцию этого самого нового >>кода >>в существующие системы. C++ фактически позаимствовал средства описания >>выполняемого алгоритма (не структур данных) из C, что позволило >>воспользоваться готовым весьма качественным решением и не изобретать >>в который раз велосипед. > >да, это так. это позволило многим чувствовать себя в новой среде комфортнее. >но от этого компромисса что получилось? на С++ писали программы почти >как на С? т.е. как и раньше глобальные переменные, функции и >какие-то разрозненные вкрапления классов (или декорирование ими -- btw, очень меткое >описание). это ли прорыв? Всё-таки это не вина C++, а вина ИТ Индустрии, но эта тема слишком обширна. >>2. Мощность конструкций C++ позволяет относительно легко описывать >>модели весьма сложных объектов реального мира и взаимоотношений >>между ними, выстраивая алгоритм как совокупность протоколов >>взаимодействия объектов. Эта же мощность позволила резко сократить >>писанину при выполнении рутинных операций; автоматически сокращается >>количество "дурацких" ошибок (если не ошибаюсь, это основная причина, >>по которой считается, что сопровождение хорошо написанной программы >>на C++ обходится дешевле сопровождения не менее хорошо написанной >>программы на C). > >есть такое мнение. старое. почти на уровне коры головного мозга. >С++ реально позволяет забивать меньше символов, чтобы описать модель. >но это справедливо тогда, когда мы говорим в общем виде. >когда мы решаем задачу, то оптимизация модели может привести к тому, что >нам не потребуются вся мощь конструкций С++. может так оказаться, что >будет вполне достаточно лишь unum, typedef, struct и функций. Вот здесь я сильно не согласен с возможностью таким образом упростить модель. Здесь два возражения (раскрывать пока нет времени): 1) так упростить удастся только действительно тривиальную модель, которую и в голову не придёт моделировать с привличением объектного подхода; 2) даже если моделировать такую тривиальную задачу в рамках объектного подхода, модель получестя весьма неплохого качества. >>3. Необходимость подерживать приличный уровень совместимости >>с идеологически несхожим языком и наличие _очень_ сложных >>абстрактных конструкций, реализованных как "нашлёпка" над >>конструкциями C в сочетании образуют совершенно дьявольскую смесь. >>Именно поэтому так долго не было практически ни одного приличного >>компилятора C++. И именно по этому не менее 75% лиц, заявляющих >>о способности писать на C++, не только не способны грамотно >>программировать на этом языке, но и не могут ответить на >>элементарные вопросы по языку на собеседовании. >> > >да, именно так. то что Страуструп реализовал вначале на уровне препроцессора потом >вылилось ему (и всем остальным) боком. не нужно было брать за >основу Си. Нужно. >а я и не обижаюсь: я не считаю себя мастером С++, Я себя считаю. (в каждой шутке есть доля шутки...) >вот в этом то и состоит концептуальная разница: >мое представление идеального идеологического гамбургера -- "то, куда нечего добавить". в то >время как "то, из чего нечего убрать" -- его антипод. >из Си, на мой взгляд, гораздо меньше чего убрать, чем из С++, >следовательно он (С++) в моем представлении ближе к интеллектуальному гамбургеру. Из ассемблера, пожалуй, нельзя убрать ничего...
		Рекомендовать в FAQ | Cообщить модератору | Наверх

88. "Си или Си ++?"
Сообщение от AdVv (??) on 24-Авг-04, 12:21  (MSK)
>Вопрос к гуру. Скажите в чём разница с и с++? >Меня интересуют не особенности языка типа классы, и т.д., а отличие производительности >программ, что выбрать для написания приложения, почему пользуются си если есть Дадагой тебе сейчас тут подскажут... И жить научат ... Ты бы уточнил платформу и компилятор по крайней мере. Главное чтоб архитектура программы была быстрой.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	89. "Си или Си ++?"
	Сообщение от Vladislav Lazarenko on 25-Авг-04, 10:40  (MSK)
	>>Вопрос к гуру. Скажите в чём разница с и с++? >>Меня интересуют не особенности языка типа классы, и т.д., а отличие производительности >>программ, что выбрать для написания приложения, почему пользуются си если есть > >Дадагой тебе сейчас тут подскажут... И жить научат ... >Ты бы уточнил платформу и компилятор по крайней мере. >Главное чтоб архитектура программы была быстрой. быстрая архитектура программы... хм, это раз-два и готово ? :)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	116. "Си или Си ++?"
	Сообщение от Андрей (??) on 02-Сен-04, 11:36  (MSK)
	Помогите, пожалуйста, разобраться с реальной проблеммой. https://www.opennet.ru/openforum/vsluhforumID9/3326.html
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.