C vs. C++ (ООП против процедурного П)

[elide]

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

ну не знаю... люди, которые начинали с чистого С, а теперь нормально пишут на С++ вызывают у меня чувство глубочайшего уважения. мне кажется, что переучиться в этом случае гораздо сложнее, чем освоить С++ с нуля. во всяком случае я прихожу к такому мнению глядя на С++ные проги, где, например, работа со строками ведется через указатели на asciiz, функциями типа strcmp и проч... процентов 70 из тех, кто пишет на С++ не знают что такое итератор и впадают в ступор от слова функтор.... я отношу подобные явления именно на счет практики изучения С первым....

[agreed]

Ну... Вообще-то такие понятия как итератор и функтор пришли в русские переводы книг из вычислительной математики и численных методов. А языки c и c++ отличаются как целевой аудиторией, так и своим прикладным назначением. В сишном подходе к работе с нуль-строками нет ничего плохого. От этого программа потеряет разве что читаемость, и то, для кого как. Ведь человек пишущий на си, имхо гораздо лучше понимает принципы работы с памятью и внутреннее устройство многих абстрактных понятий (структур, строк и т.п). А с++ я уже с 5 захода не могу освоить. Старею?.. Извини за критику. Это чисто субъективно.

[Sparky]

читайте RSDN и просвещайтесь :thumbsup:

[madskull]

agreed про строки правильно сказал. Зная, как работает strcpy и примерно, как работает и во что превращается присваивание "объектных строк" мне, человеку начинавшему изучать программирование с ассеблера для k580, просто ЖАЛКО памяти и тиков.
Конечно, это не касается кода, где сплошняком идет работа со строками.

[Sparky]

Ну... Вообще-то такие понятия как итератор и функтор пришли в русские переводы книг из вычислительной математики и численных методов. А языки c и c++ отличаются как целевой аудиторией, так и своим прикладным назначением. В сишном подходе к работе с нуль-строками нет ничего плохого. От этого программа потеряет разве что читаемость, и то, для кого как. Ведь человек пишущий на си, имхо гораздо лучше понимает принципы работы с памятью и внутреннее устройство многих абстрактных понятий (структур, строк и т.п). А с++ я уже с 5 захода не могу освоить. Старею?.. Извини за критику. Это чисто субъективно.

↑

никогда не думал, что структура и строка абстрактные понятия.... B)

agreed про строки правильно сказал. Зная, как работает strcpy и примерно, как работает и во что превращается присваивание "объектных строк" мне, человеку начинавшему изучать программирование с ассеблера для k580, просто ЖАЛКО памяти и тиков.
Конечно, это не касается кода, где сплошняком идет работа со строками.

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

Sparky добавил в 03.04.2005 00:49

Кстати хотельеще сказать, что сам спор ООП vs. ПП немного не корректен... ИМХО нужно знать оба подхода и эффективно использовать, там где это необходимо/удобно... т.д.

[elide]

кстати, только собирался предложить вставлять в отбитые темы какую-нить пометку, типа ==splitted==. а то не понятно получается. взялась непонятная тема, я автор... а я бы и в жизни никогда бы не подумал начинать флейм C vs C++. я еще не настолько болен...
кроме того, посты из контекста вырываются. изначально имелась ввиду конкретно процедура обучения. я просто хотел заметить, что С и С++ - разные языки для разных задач и для разных людей, а те, кто учит С++ после С в массе своей этого не понимают и тянут в С++ сишный подход не догадываясь, что С++ это не только другой синтаксис, но и другая идеология, другие приемы и другие акценты. что тики и байты, размер и скорость отходят там уже на второй план, а на первый выходят человеко-часы и качество продукта. что там надо учиться плевать на оверхед обертки строки, экономя часы на поиске какого-нить buffer overflow.

мне, человеку начинавшему изучать программирование с ассеблера для k580, просто ЖАЛКО памяти и тиков.

а использовать перл, где целые хранятся строками, не жалко? а может жалко писать скрипты на bash, помня, что выполнение команд сопровождается созданием и удалением целых отдельных процессов?
считать байты и тики - важно и полезно. но только там, где это необходимо. не надо пихать этот счет во все дыры - есть места, где он совсем "не к месту". машинное время все дешевле, а человеческие жизни все короче...

[t.t]

кстати, только собирался предложить вставлять в отбитые темы какую-нить пометку, типа ==splitted==. а то не понятно получается. взялась непонятная тема, я автор... а я бы и в жизни никогда бы не подумал начинать флейм C vs C++. я еще не настолько болен...

↑

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

[agreed]

Извините, конечно, что сейчас проснулся. Обнаружил, что кто-то уже успел рохулиганить от моего имени. По поводу парадигм программирования - здесь нет правых и неправых. Каждому свое. Вот я, например, сейчас читаю книгу Гради Буча "Объектно-ориентированный анализ и проектирование". Очень, просто очень советую. И уж точно стоит глянуть две забавных (по-моему) статьи: http://bugtraq.ru/library/programming/obje...enotfailed.html, и, соответственно http://bugtraq.ru/library/programming/objectshavefailed.html.
Существует же еще проблемно-ориентированная парадигма... Но это уже совсем другая история.
p.s.: извините, что поднял тему - уж очень интересно!