Чем лутше объектный C++ , чем С, для простых прог?  
Так же проше ...

Проще чего??  

Проше чем необъектный))

NebelDT, я не понял - ты хочешь сказать что реализовал в своем коде парадигмы ООП? Или наоборот убил С++ своим подходом?

простых программ не бывает  

ничем
я даже больше скажу, и для сложных программ С++ не лучше   
(можете начинать набрасываться на меня)

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



На с++ есть гламурный qt. на си его нет   


Это сообщение отредактировал(а) Mayk - 30.9.2008, 13:24

GTK+?   

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

Это сообщение отредактировал(а) UnrealMan - 30.9.2008, 16:43

По теме топикстартеру можно предложить почитать книгу "Дизайн и эволюция C++" Б.Страуструпа.

UnrealMan Пасиб! но сейчас мне не до этого, надо делать лабы по С++...  

UnrealMan, 
ну, скажем так
любой специалист в своей области будет гуру
так что не надо сарказма

С++ объективно сложный, перегруженный, с кучей подводных камней и граблей, интерпретируемым кем угодно и как угодно стандартом
какие у него преимущества перед С?
ООП? так ООП != ЯП
программировать объектно можно и на С, причем это будет не менее эффективно
программистам на С++ это может показаться странным и нелогичным, но на то это и С++ программисты   
какие еще преимущества? STL?  есть куча либ, написанных на С на все случаи жизни
но в отличие от STL они эффективны на всех платформах, реализация же STL различна для каждого компилятора
исключения? имхо, они полезны для автоматического управления ресурсами
в С они абсолютно заменяемы через goto, т. к мы полностью сами управляем жизненным циклом объектов (нет деструкторов и пр.)
полиморфизм? реализуется через такие штуки

наследование? заменяется агрегированим (по сути любая реализация наследования - есть агрегирование)
удобство? как говорится, на вкус и цвет...
что еще?

type-safety
ну конечно если вы за всеми своими войдами можете уследить глазами и макросами (которые кстати в глобальном пространстве имен) то да, ничем не лучше... но тогда нахена вам вообще ЯВУ? пишите на ассемблее... а еще лучше - сразу в машинных кодах - и компилятор не нужен   

Это сообщение отредактировал(а) J0ker - 1.10.2008, 00:01

Ага, только есть один маленький нюанс  :  на С++ грязную работу делает компилятор, а на Си программист
поэтому  такой подход

   


  а сколько еще благ, помимо безопасности, хранит в себе типизация ! 

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

Урра! холивар! 


По сравненю с QT? Ты бы ещё XLib назвал.   


Обрати внимание на вторую букву в STL. В си нет шаблонов. И аналогов тоже нет.



Эффективны? Да вот только вызовы ф-ций в qsort не встраиваются. STL же inline'ится за милую душу.
Про разность реализации - glibc и freebsd libc тоже различны. И?


RAII. очень полезно 




можно. только зачем, если есть с++, java, c#?

Это сообщение отредактировал(а) Mayk - 1.10.2008, 05:51

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

да, отлично, надо бы перенести   



не вижу грязной работы
все то же самое, что и на С++, только по-другому реализовано, что выглядит для не С программистов неестественно   



а что, Xlib штуковина мощная   
правда все ручками делать нужно и нет ничего готового



они в С не нужны, тут есть void*   
чем это

хуже

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

я уже писал об этом


нет, нет, нет
джаву и шарп мы здесь не трогаем
у них действительно есть возможности, отсутствующие в С/С++
кроме того, оно заточены под определенные задачи сугубо прикладного плана с уклоном в веб
и решают их довольно хорошо

Добавлено @ 08:31
да, кстати, большинство кроссплатформенных либ (причем многие огромные) написаны на С
казалось бы, зачем заниматься геморроей и писАть на С, когда есть С++ 
или С++ непереносим    

Добавлено через 7 минут и 43 секунды

это верно на 100%  

Добавлено через 9 минут и 7 секунд

я считаю, что одинаково
главное, чтобы человек был профессионал в своем деле   

Это сообщение отредактировал(а) MAKCim - 1.10.2008, 08:33

  

Верно, и некоторым людям в силу собственной лени к изучению новых технологий в программировании психологически проще убедить себя, что старые технологии мол и так работают достаточно эффективно, чем взяться за рассмотрение пугающе большого объёма материала. По этой же причине некоторым, причисляющим себя к программистам C++, не хочется изучать STL или Boost - они до конца жизни готовы изобретать велосипеды, убеждая себя и других в том, что такой подход ничем не хуже, чем использование готовых и проверенных временем средств.


Собственно такие, из-за которых C++ появился на свет (было бы наивно предполагать, что его придумали исключительно из-за того, что кому-то некуда было растрачивать свою творческую энергию). Проблемы программирования на C перемалывались уже сотни раз, в том числе в D&E.


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


А для каждого компилятора разработчики не стремятся реализовать эффективно работающую STL? И STLport уже не является портируемой реализацией STL?


Надо же, как мало полезного в механизме, который используется далеко не в одном C++  


Да неужели? Один goto позволяет выйти из кучи функций (с освобождением захваченных ресурсов) и попасть в обработчик, о котором функция, выявившая исключительную ситуацию, ничего не знает? 


Угу, за соответствием типов дядя Вася будет следить.



В C++ тоже есть void*. Только почему-то вместо этого используют шаблоны. Странно, правда? Макросами с void* в лучшем случае кое-как можно заменить простые шаблоны (правда, придётся долбаться с их ручным "инстанцированием"). А что ты будешь делать, когда придётся изобразить шаблонный член шаблонного класса? В C++ я могу записать так:


Вместо std::list<int> можно взять хоть std::list<unsigned char>, хоть std::deque<short>, при этом инициализация vector будет выглядеть так же просто. Попробуй-ка изобрази такую обобщённость с помощью макросов и void* - пупок развяжется и пузико лопнет.


В строчке


ты забыл указать, с каким типом работаешь.


Обалденное преимущество. Искать утечки ресурсов - это ж такая романтика! 
Только не говори, что гуру C никогда ничего не забывают (в том числе вовремя освобождать ресурсы). Я в такие сказочки не верю. В теории управлять ресурсами ручками, конечно, можно. Но дык в теории можно и программу целиком написать без единой помарки - так, что она сразу без выдачи компилятором ошибок соберётся, вот только часто ли у вас такое бывает на практике?


Что-то не понял я, где это в C++ объект std::list<> хранит адреса соседних элементов  

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

хыхыхы 

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



"стремится" и "получится в итоге" - разные вещи   

 

что поделаешь...



исключения работают точно так же (по принципу лестницы)
через goto переходим на error_1:, error_2:, ..., error_N:
освобождаем ресурсы, возвращаем в вызыващую функцию код ошибки, она в свою очередь таким же образом использует goto и т. д

 

ну, тот, кто реализовал generic, в курсе типов, а остальному коду о них не нужно знать   



в С это не нужно   

потом на остальное отвечу

а программисту? программисту знать нужно?   

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

еще раз повторяю, нужно тому, кто ее реализовал   
все остальные используют таким образом



не, у меня глаз дергается просто   

ага, а array с нетипизированной требухой у нас пушкин заполняет, который волшебным образом нашепчет пользователю вашего чуда, что callback жестоко навернется когда мы ему случайно постороннюю структуру подсунем
или давайте все задефйним нафик как здесь:

а потом набьем морду злобному конкуренту, захотевшему заюзать кровно-наше vector_in
а заодно и пользователю - за измену   

у меня к вам конструктивное предложение - вы в конец дефайнов дописывайте GUID
ну не замечательно ли: vector_in_7F272518_73F9_4fb2_A374_EA310B8EBE7B   

Это сообщение отредактировал(а) J0ker - 1.10.2008, 21:42

а в С++ можно изменить private поле если очень захотеть
и что из этого?   

на каждое "а если", можно найти другое "а если"

Добавлено через 5 минут и 49 секунд
как-то дискуссия плавно перешла в то, какими извращениями можно реализовать шаблоны в С
  
зато в С есть массивы переменной длины на стеке
вектора STL курят     

мало того, они еще и пьют и прочему непотребствами занимаются    ухожу ухожу

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


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

вы о чем, сударь?   
и коню понятно, что в С нет шаблонов
вопрос состоит в том, а нужны ли они и можно ли обойтись без них
ответ положительный



я вот не понимаю
у нас есть структура t_generic
ее использование однозначно (t_generic->callback(t_generic->data))
с какого перепуга мы можем в t_generic->callback передать что-то отличное от t_generic->data?

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


ну не надо прибедняться
все вы отлично понимаете   


с перепуга void*, который принимает ЛЮБОЙ указатель. А вот что-бы он был не любой - надо либо следить пользователю, либо использовать маловразумительные дефайны (ро дефйны см. выше). Оно нам надо?

Это ты намекаешь на то, что все эти либы якобы легко заменяют собой все новшества C++ по отношению к C?


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


Я-то думал, речь идёт о виртуальных функциях, а тут generic 


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


Что это за потуги такие?  Этот обрывок кода, будучи самую малость дополнен, видимо, свершит чудо - заменит шаблоны, приведённые выше по теме? А как насчёт законченного примерчика? Каракули-то мы все рисовать умеем, но только вот мало что можно в них разглядеть. Откуда, к примеру, vector_in узнает точный тип элементов списка? А ежели не узнает, то чего тогда будет присваивать объектам типа double?

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

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

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

все "новшества" - это синтаксический сахар



гы
за нас компилятор конечно же создаст деструкторы, которые будут уничтожать наши ресурсы...     
точно так же придется ручками писАть
разница лишь в том, что в С функцию освобождения ресурсов надо вызывать вручную



виртуальные функции реализованы точно также, как и t_generic->callback
есть таблица ВФ, есть ее адрес в объекте, есть данные




никто и не вешает
только факты, мой друг, только факты   



  



вот именно, что никто себя не обманывает
зачем выдавать за факт то, чего нет
я уже давно сказал, что в С нет шаблонов
а так ли они необходимы?
ты уперся на своем, дескать шаблонов нет - и все, без них типа жить нельзя

Добавлено через 11 минут и 12 секунд
вся "прелесть" С++ в его т. н стандарте, которому до конца никто не следует
а все почему, да потому что сложный он
сидели бородатые дядьки, думали, думали и наконец придумали
конечно, их дело маленькое, обкуриться и выдать 
а вы уж реализовывайте   

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

Пока читал тему понаквотил целую кучу фраз. Когда доскроллил до формочки ответа понял, что на всё отвечать лень, поэтому просто выскажу своё мнение. 

Итак, С++ - объективно сложный и запутанный в современном состоянии. Это да.

Библиотеки? Если говорим про прикладнуху, то Qt достаточно чтобы считать С++ круче  IMHO, конечно.

По мне - так С хорош, но кое чего не хватает (неймспейсов, перегрузки функций, шаблонов или более навороченного препроцессора). Последнее впрочем решают внешнее утилиты.

А будущее (в прикладном ПО) вообще за всякими питонами, шарпами, явами и пр.

неа.

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

Да ну? Поддержка RTTI, исключения, шаблоны - всё это синтаксический сахар? Что же тогда по-твоему не синтаксический сахар? Может, у тебя и библиотечные функции - синтаксический сахар? 


Между прочим, компилятор C++ самостоятельно вызывает деструкторы для базовых подобъектов и нестатических членов-данных объекта. Для весомой части классов деструкторов, сгенерированных компилятором по умолчанию, вполне достаточно. А там, где недостаточно, мы всё равно избавляемся от необходимости явно уничтожать агрегированные объекты.


Только не надо забывать, что реализуем мы деструктор всего один раз, а вызываться он должен для всех создаваемых в программе объектов. Сложность слежения за тем, чтобы деструктор был вызван всюду, где это необходимо, часто превосходит сложность написания самого деструктора.


Мсье выдаёт желаемое за действительное.


Без тёплого и уютного жилья тоже можно жить. Бомжи вон как-то живут. Не хочешь составить им компанию? Для тебя ведь уровень жизни, видимо, не важен?

Шаблоны позволяют решать в общем виде задачи, которые без шаблонов полноценно в общем виде не решаются. Конечно, можно справиться с решением отдельных частных случаев задачи, но вот досада - это более затратно по времени. Решения в обход типобезопасности также затратны по времени - как прямо (за счёт необходимости отслеживания правильности преобразований), так и косвенно (за счёт практически неизбежно допускаемых ошибок, которые нуждаются во времени на их устранение).


А кто, собственно, требует читать исходники Boost?  Вменяемый человек ради понимания того, как пользоваться библиотекой, руководствуется документацией к ней, а не её исходным кодом.

но только это нихрена не работает, так как память освобождается в самом аллокаторе  

Это сообщение отредактировал(а) Lazin - 2.10.2008, 14:53

Насчёт аллокатора - если написать аллокатор, юзающий salloc - разве не то получится?

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

С++ в этом плане не настолько уж и крут (не-не - разница есть, но не надо преувеличивать).

сразу видно, на С ты не программировал   
нет ничего сложного
есть объект A, есть функция для его создания и уничтожения
есть функция, использующая A
в ней есть блок завершения, в котором идет вызов функции уничтожения
переход на блок завершения идет через goto
блоков завершения может быть несколько, в зависимости от числа типов создаваемых объектов
располагаются последовательно в обратном созданию порядке
любая функция строится по такому правилу
в итоге нет ни утечек, ни сложностей для восприятия
  


аналогия в корне не верна


а почему ты решил, что я на этом акцентирую внимание?   

я не преувеличиваю
C++ оставляет ВОЗМОЖНОСТЬ эту безопасность обойти, но если вам эта возожность понадобилась - ищите ошибки в проектировании, а язык тут совершенно не при чем.

Добавлено через 8 минут и 32 секунды

Действительно, поразительно удобно   

Народ, он ИМХО над нами издевается   

кстати, а чтож вы на неудобные вопросы-то не отвечаете, а?

о вкусах не спорят
сразу видно, что тут на С мало кто программировал   


давайте список, буду отвечать

Добавлено через 10 минут и 41 секунду

ничуть
я сам был раньше фанатом С++
пока не понял, что он того не стОит

Это сообщение отредактировал(а) MAKCim - 3.10.2008, 08:19

 А если надо что-то кросплатформенное?)
Тогда Qt.


 Это одна из возможных причин.
Вторая причина - в потенциальной кривости не программиста, а языка.
Сравни C++ с Java. Только языки(не платформы).
Т.е. считай, что в джаве есть указатели(естественно они deprecated) и она компилится в натив.
Тебе не кажется, что тогда практически все бы выбрали Java(как и случилось с ентерпрайзом)?

 О да. Собственно как и любой язык - синтаксический сахар над бинарным кодом.
Только вот этот "синтаксический сахар" очень удобен ;)

P.S. До недавнего времени юзал C, теперь C++. Ибо Qt и классическое ООП(без него стало сложно). Ненавижу C++ за сложность(неоправданную).

А ты что-нибудь посложнее Hello World на своём C программировал?


Ну, надо же, как всё просто 

Предположим, у нас есть два ресурса: первый захватывается объектом x, второй - объектом y:


В случае неудачной попытки захватить какой-либо ресурс, либо неудачного отрабатывания метода use_resource надо выйти из функции f (освободив все захваченные ресурсы) и передать ошибку наверх. Перепиши этот код на C.


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


А кто ж тебя знает, на чём ты там акцентировал внимание? Я всё-таки не телепат.


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


Я не знаю Java и сравнивать их не стану (ибо предпочитаю говорить только о том, в чём, как я считаю, достаточно хорошо разбираюсь).

Добавлено @ 12:17

если это действительно вопрос, а не стеб, то да   



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



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

Добавлено через 11 минут и 20 секунд
UnrealMan
давай все же на личности не переходить
или по-другому ты дискуссию вести не умеешь?

Это сообщение отредактировал(а) MAKCim - 3.10.2008, 12:19

Не ожидал что мне столько народу ответит, пасиб! 

Добавлено через 4 минуты и 11 секунд
Не ожидал что мне столько народу ответит, пасиб!  

А каким чудом функция, вызвавшая f, узнает, что за ошибка произшла? Будем считать, что существует по меньшей мере две причины, по которой захват ресурса не может быть выполнен успешно, и то же самое будет в отношении использования use_resource. Нужно, чтобы в функции, вызывающей f, можно было распознать тип ошибки (т.е. конкретную причину сбоя).

Кстати, нулевой handle обычно свидетельствует о неудачном захвате ресурса, так что в if-ах следовало бы добавить отрицание.


C больше походит на детский трёхколёсный велосипед, нежели на такси. Такси в определённом плане может быть ещё удобней, чем личное авто, ибо все тяготы, связанные с управлением машиной, уходом за ней, прохождением техосмотра и т.д. возьмут на себя специальные работники, осуществляющие и обслуживающие такого рода перевозки, а не пассажир, которому надо просто доехать из точки A в точку B. Это определённо не про C-программистов.


Зачастую этого уровня знаний хватает только на разжигание дурацких холиваров на форумах.


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


Если б ты добавил "лично для меня не лучше", к тебе б претензий не было. Ну, нравится тебе извращаться со всеми этими макросами, void* и goto, извращайся дальше сколько угодно. Но тебе зачем-то понадобилось провокационно такое уточнение опустить и снизвести тему в холивар:


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

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

 Признак фанатизма - необъективность. А необъективность мешает правильно оценить вещи. Как следствие - неверно принятое решение по заданным критериям оценки.

а, ну тут просто описка
функция должна int возвращать (или любым другим способом сигнализировать об ошибке)



опять описка

главное, что общая идея в коде прослеживается


аналогия раскрывается следующем образом
машина = шаблоны
нет машины = С
есть машина = С++
возьму такси = сделаю по-другому
в итоге и в первом случае, и во втором я доеду до пункта Б = решить задачу
  


это тонкий намек или мне кажется?


в холиварах тоже нужно вести себя корректно


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

Добавлено через 1 минуту и 37 секунд

это к чему?
определение фанатизма?

 Нет. Его отрицательные качества.

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

от этого он стал менее понятным?

Просто описка? А на то, что размер кода станет ещё больше, мы внимания не обращаем?  


Равноценной замены шаблонам в C нет. Более совершенной замены - тем более. Так что не надо тут преувеличивать насчёт такси: максимум, на что ты сможешь рассчитывать, это на трёхколёсный велосипед, позаимствованный у девочки Маши, либо на свои собственные ножки.


Потому что повышенная трудоёмкость (читай затратность по человеческим ресурсам) предлагаемых тобой изворотов очевидна. Если ты готов спорить с очевидным, то с тобой в принципе невозможно о чём-то договориться. К счастью, я и не собираюсь лично тебя в чём-то убеждать. Я тут ради собственного развлечения и ради тех, кто с очевидными вещами спорить не любит.

Стремление выбрать из двух способов достижения цели наиболее затратный - это мазохизм. Для серьёзных коммерческих проектов такой мазохизм убыточен.


И вопросы проектирования крупных программных систем конечно же никто никогда не рассматривал. В каменном веке живём.


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


Насчёт косвенности это ты зря упомянул. Немногим ранее ты написал следующее:


Между строк тут так и читается: "а если у вас получается не одинаково, то никакие вы не профессионалы в C".

Конечно, тут можно было бы упрекнуть меня в вольной интерпретации, однако же эта твоя пафосная фраза без приведённого мной подтекста, теряет всякий смысл. Тут уж что-то одно: либо человек, который не в силах вести разработку на C так же эффективно, как на C++, недостаточно профессионал в C, либо ты просто ляпнул что-то не то.
 

Цитата(MAKCim @  3.10.2008,  15:47 )

мы все-таки в религиозных войнах

Мне довелось участвовать в десятках религиозных спорах, причём религиозных в прямом смысле, т.к. предметом обсуждения в них было "христианство vs атеизм". Честно говоря, поражён, до чего уровень твоих аргументов похож на оный у христиан. Ты, случаем, не один из них?  


Его как минимум сложнее читать и модифицировать.

 От этого он стал больше.
Т.е. на его написание, поддержку, разбор другими программистами и модификацию уйдет больше ресурсов.

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

не волнуйтесь, мы и на ассемблере лабаем   

да я уже раза 3 его давал
1. типобезопасность
2. решение 1. путем создания макросов которые:
   2a. неотлаживаемы в принципе
   2b. непозволяют конкурентное использование разных библиотек в силу конфликта имен и несовместимости

-- А вы детей любите?
-- Нет...
-- Ааааа, вы просто готовить их правильно не умеете!!!
  

Так и скажите, что вам просто лень изучать сложный инструмент  

Добавлено через 3 минуты и 8 секунд

она оправдана близостью к железу

вкусовых стандартов не существует   

MAKCim, сразу видно соскчилсмя по РВ   

ты считаешь быть христианином это что-то плохое?

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

Добавлено через 3 минуты и 52 секунды

а я и не писал, чтосуществует, я писал "принимается"
это вопрос рациональности, а не искусства


скорее глупое
слепая вера - один из анти-паттернов   

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

Добавлено через 1 минуту и 59 секунд

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