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

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



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



а что, 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