Так же проше ...
| Код |
|
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Религиозные войны > Чем лучше объектный C++ , чем С, для простых прог? |
| Автор: NebelDT 30.9.2008, 11:32 | ||
| Чем лутше объектный C++ , чем С, для простых прог? Так же проше ...
|
| Автор: Kozel 30.9.2008, 11:38 |
Проще чего??  |
| Автор: NebelDT 30.9.2008, 11:40 |
| Проше чем необъектный)) |
| Автор: mrbrooks 30.9.2008, 12:20 |
| NebelDT, я не понял - ты хочешь сказать что реализовал в своем коде парадигмы ООП? Или наоборот убил С++ своим подходом? |
| Автор: Lazin 30.9.2008, 12:34 | ||
простых программ не бывает  |
| Автор: MAKCim 30.9.2008, 13:08 | ||
ничем я даже больше скажу, и для сложных программ С++ не лучше  (можете начинать набрасываться на меня) |
| Автор: Mayk 30.9.2008, 13:23 | ||||
бывают, бывают. вот допустим задача - забить свежесформированную тестовую бд рандомными числами/строками. тут что классы что ни классы - все довольно просто.
На с++ есть гламурный qt. на си его нет |
| Автор: MAKCim 30.9.2008, 13:25 | ||
GTK+? |
| Автор: UnrealMan 30.9.2008, 16:08 | ||
С поправочкой - когда программу пишут C-программисты, которые ни хрена не знают C++ и толком не умеют пользоваться его средствами. Таким людям программирование на C++ противопоказано, особенно в коллективной разработке вместе с нормальными C++программистами. |
| Автор: UnrealMan 30.9.2008, 16:42 |
| По теме топикстартеру можно предложить почитать книгу "Дизайн и эволюция C++" Б.Страуструпа. |
| Автор: NebelDT 30.9.2008, 17:21 |
UnrealMan Пасиб! но сейчас мне не до этого, надо делать лабы по С++...  |
| Автор: MAKCim 30.9.2008, 21:36 | ||
| UnrealMan, ну, скажем так любой специалист в своей области будет гуру так что не надо сарказма С++ объективно сложный, перегруженный, с кучей подводных камней и граблей, интерпретируемым кем угодно и как угодно стандартом какие у него преимущества перед С? ООП? так ООП != ЯП программировать объектно можно и на С, причем это будет не менее эффективно программистам на С++ это может показаться странным и нелогичным, но на то это и С++ программисты какие еще преимущества? STL? есть куча либ, написанных на С на все случаи жизни но в отличие от STL они эффективны на всех платформах, реализация же STL различна для каждого компилятора исключения? имхо, они полезны для автоматического управления ресурсами в С они абсолютно заменяемы через goto, т. к мы полностью сами управляем жизненным циклом объектов (нет деструкторов и пр.) полиморфизм? реализуется через такие штуки
наследование? заменяется агрегированим (по сути любая реализация наследования - есть агрегирование) удобство? как говорится, на вкус и цвет... что еще? |
| Автор: J0ker 1.10.2008, 00:00 | ||
type-safety ну конечно если вы за всеми своими войдами можете уследить глазами и макросами (которые кстати в глобальном пространстве имен) то да, ничем не лучше... но тогда нахена вам вообще ЯВУ? пишите на ассемблее... а еще лучше - сразу в машинных кодах - и компилятор не нужен |
| Автор: mes 1.10.2008, 03:26 | ||||||
Ага, только есть один маленький нюанс : на С++ грязную работу делает компилятор, а на Си программист поэтому такой подход
 а сколько еще благ, помимо безопасности, хранит в себе типизация ! И главное что С++, обретя полиморфизм, типизацию, шаблоны и многое другое, позволяющее снять большую часть забот с программиста, не утратил возможностей и эффективности чистого Си. |
| Автор: Mayk 1.10.2008, 05:51 | ||||||||||||
Урра! холивар!
По сравненю с QT? Ты бы ещё XLib назвал. 
Обрати внимание на вторую букву в STL. В си нет шаблонов. И аналогов тоже нет.
Эффективны? Да вот только вызовы ф-ций в qsort не встраиваются. STL же inline'ится за милую душу. Про разность реализации - glibc и freebsd libc тоже различны. И?
RAII. очень полезно
можно. только зачем, если есть с++, java, c#? |
| Автор: bsa 1.10.2008, 08:23 | ||||
Ну как же! Если у тебя сложный проект, а-ля ядро операционной системы, то куда же без этого! Ведь принятно все системные вещи писать исключительно на Си. А без объектного программирования сложный проект практически нереально состряпать, чтобы он еще мог жить и развиваться. Имхо, каждому свое. Я, лично, считаю, что прикладной софт нужно писать на С++ - сильная экономия времени. А системный (особенно, системные библиотеки) на Си из-за большей стандартизованности. |
| Автор: MAKCim 1.10.2008, 08:27 | ||||||||||||||||||||
да, отлично, надо бы перенести
не вижу грязной работы все то же самое, что и на С++, только по-другому реализовано, что выглядит для не С программистов неестественно
а что, Xlib штуковина мощная правда все ручками делать нужно и нет ничего готового
они в С не нужны, тут есть void* чем это
хуже
единственное, это явная необходимость управления ресурсами хотя это даже преимущество, а не недостаток а все, что касается списков, деревьев, хэшей и т. д (все, что имеет списочную природу) то в С из-за отсутствия шаблонов применяется концептуально иной подход не объект списка хранит адреса соседних элементов, а сами элементы
я уже писал об этом
нет, нет, нет джаву и шарп мы здесь не трогаем у них действительно есть возможности, отсутствующие в С/С++ кроме того, оно заточены под определенные задачи сугубо прикладного плана с уклоном в веб и решают их довольно хорошо Добавлено @ 08:31 да, кстати, большинство кроссплатформенных либ (причем многие огромные) написаны на С казалось бы, зачем заниматься геморроей и писАть на С, когда есть С++ или С++ непереносим Добавлено через 7 минут и 43 секунды
это верно на 100% Добавлено через 9 минут и 7 секунд
я считаю, что одинаково главное, чтобы человек был профессионал в своем деле |
| Автор: bsa 1.10.2008, 08:54 | ||
 |
| Автор: UnrealMan 1.10.2008, 11:32 | ||||||||||||||||||||||||||||
Верно, и некоторым людям в силу собственной лени к изучению новых технологий в программировании психологически проще убедить себя, что старые технологии мол и так работают достаточно эффективно, чем взяться за рассмотрение пугающе большого объёма материала. По этой же причине некоторым, причисляющим себя к программистам 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<> хранит адреса соседних элементов |
| Автор: J0ker 1.10.2008, 16:30 | ||||
хыхыхы |
| Автор: MAKCim 1.10.2008, 18:42 | ||||||||||||
ты никак не можешь понять, что под С есть точно такая же куча всевозможных либ, решающих возникающие в процессе разработки сопутствующие вопросы
"стремится" и "получится в итоге" - разные вещи
что поделаешь...
исключения работают точно так же (по принципу лестницы) через goto переходим на error_1:, error_2:, ..., error_N: освобождаем ресурсы, возвращаем в вызыващую функцию код ошибки, она в свою очередь таким же образом использует goto и т. д
ну, тот, кто реализовал generic, в курсе типов, а остальному коду о них не нужно знать
в С это не нужно потом на остальное отвечу |
| Автор: J0ker 1.10.2008, 19:37 | ||||
а программисту? программисту знать нужно?
вы случайно подмигиваете не насчет макросов в глобальном нэймспэйс? тогда лучше такой смайлик -  |
| Автор: MAKCim 1.10.2008, 21:18 | ||||||||||
еще раз повторяю, нужно тому, кто ее реализовал все остальные используют таким образом
не, у меня глаз дергается просто
|
| Автор: J0ker 1.10.2008, 21:41 | ||||||
ага, а array с нетипизированной требухой у нас пушкин заполняет, который волшебным образом нашепчет пользователю вашего чуда, что callback жестоко навернется когда мы ему случайно постороннюю структуру подсунем или давайте все задефйним нафик как здесь:
а потом набьем морду злобному конкуренту, захотевшему заюзать кровно-наше vector_in а заодно и пользователю - за измену у меня к вам конструктивное предложение - вы в конец дефайнов дописывайте GUID ну не замечательно ли: vector_in_7F272518_73F9_4fb2_A374_EA310B8EBE7B |
| Автор: MAKCim 1.10.2008, 22:05 | ||
а в С++ можно изменить private поле если очень захотеть и что из этого? на каждое "а если", можно найти другое "а если" Добавлено через 5 минут и 49 секунд как-то дискуссия плавно перешла в то, какими извращениями можно реализовать шаблоны в С зато в С есть массивы переменной длины на стеке вектора STL курят |
| Автор: vinter 1.10.2008, 22:17 | ||
мало того, они еще и пьют и прочему непотребствами занимаются ухожу ухожу |
| Автор: J0ker 1.10.2008, 22:52 | ||||
а давайте остановимся на "без выкрутасов" без выкруасов всего того что вы там понаписали на C не реализовать - либо плюем на безопасность типов, либо (сильно условно) решаем эту проблему созданием другой проблемы - загрязнением глобального нэймспейса и несовместимостью библиотек, плюс полная неудобочитаемость таких перлов и невозможность их отладки.
слив защитан собственно ничем иным данный спор не мог закончится, т.к. одна из первых предпосылок создания C++ была проблема, в которую я вас так жестоко ткнул носом |
| Автор: MAKCim 1.10.2008, 23:08 | ||||
вы о чем, сударь? и коню понятно, что в С нет шаблонов вопрос состоит в том, а нужны ли они и можно ли обойтись без них ответ положительный
я вот не понимаю у нас есть структура t_generic ее использование однозначно (t_generic->callback(t_generic->data)) с какого перепуга мы можем в t_generic->callback передать что-то отличное от t_generic->data? |
| Автор: J0ker 1.10.2008, 23:28 | ||||||
если положительный - это дефайны - то ответ отрицательный в силу вышеназванных причин если ваше решение имеет хотя-бы какую-то академическую ценность (например как иллюстрация эволюции C в C++), то с точки зрения коммерческого применения эта ценность стремится к нулю, т.к. нигде кроме как монолитных приложениях оно не применимо
ну не надо прибедняться все вы отлично понимаете
с перепуга void*, который принимает ЛЮБОЙ указатель. А вот что-бы он был не любой - надо либо следить пользователю, либо использовать маловразумительные дефайны (ро дефйны см. выше). Оно нам надо? |
| Автор: UnrealMan 2.10.2008, 00:22 | ||||||||||
Это ты намекаешь на то, что все эти либы якобы легко заменяют собой все новшества C++ по отношению к C?
Слишком много возни. Даже без нужды в освобождении ресурсов это геморрой. С освобождением ресурсов это геморрой в квадрате. Соответственно, C тут банально сливает в эффективности разработки, т.к. заставляет программиста тратить лишнее время на реализацию того, что в C++ уже давно автоматизировано.
Я-то думал, речь идёт о виртуальных функциях, а тут generic
Ах вот оно что. Т.е. если мы на C чего-то не можем, то скажем, что не очень-то и хотелось. Ну, для избежания психологического дискомфорта такой самообман, конечно, сгодится, ибо тяжело осознавать, что твой повседневно используемый инструментарий - убогая рухлядь - так можно и интерес к программированию потерять. Но вешать эту лапшу на уши другим, пожалуйста, не надо, C++ программистам и без неё вполне хорошо живётся 
Что это за потуги такие? Этот обрывок кода, будучи самую малость дополнен, видимо, свершит чудо - заменит шаблоны, приведённые выше по теме? А как насчёт законченного примерчика? Каракули-то мы все рисовать умеем, но только вот мало что можно в них разглядеть. Откуда, к примеру, vector_in узнает точный тип элементов списка? А ежели не узнает, то чего тогда будет присваивать объектам типа double? |
| Автор: Lazin 2.10.2008, 05:42 | ||
и не засирают стек , все-же понимают, что на стеке много памяти выделять нельзя, а если очень хочется, то можно написать для вектора алокатор, который будет выделять память в стеке |
| Автор: MAKCim 2.10.2008, 08:11 | ||
в самом деле? ну-ка ну-ка по-подробнее с этого места может, ты перепутал сьаьтческий буфер в секции данных со стеком? |
| Автор: MAKCim 2.10.2008, 08:28 | ||||||||||||||
все "новшества" - это синтаксический сахар
гы за нас компилятор конечно же создаст деструкторы, которые будут уничтожать наши ресурсы...  точно так же придется ручками писАть разница лишь в том, что в С функцию освобождения ресурсов надо вызывать вручную
виртуальные функции реализованы точно также, как и t_generic->callback есть таблица ВФ, есть ее адрес в объекте, есть данные
никто и не вешает только факты, мой друг, только факты
вот именно, что никто себя не обманывает зачем выдавать за факт то, чего нет я уже давно сказал, что в С нет шаблонов а так ли они необходимы? ты уперся на своем, дескать шаблонов нет - и все, без них типа жить нельзя Добавлено через 11 минут и 12 секунд вся "прелесть" С++ в его т. н стандарте, которому до конца никто не следует а все почему, да потому что сложный он сидели бородатые дядьки, думали, думали и наконец придумали конечно, их дело маленькое, обкуриться и выдать а вы уж реализовывайте тот же boost - это мегатонны неудобночитаемого кода... попытка универсализировать шаблоны, показать всю их "мощь" дефайны по сравнению с этой кашей - это еще вполне удобноваримо |
| Автор: Любитель 2.10.2008, 13:18 |
Пока читал тему понаквотил целую кучу фраз. Когда доскроллил до формочки ответа понял, что на всё отвечать лень, поэтому просто выскажу своё мнение.  Итак, С++ - объективно сложный и запутанный в современном состоянии. Это да. Библиотеки? Если говорим про прикладнуху, то Qt достаточно чтобы считать С++ круче IMHO, конечно.По мне - так С хорош, но кое чего не хватает (неймспейсов, перегрузки функций, шаблонов или более навороченного препроцессора). Последнее впрочем решают внешнее утилиты. А будущее (в прикладном ПО) вообще за всякими питонами, шарпами, явами и пр. |
| Автор: Mayk 2.10.2008, 13:23 | ||||
неа.
если при написании подобных макросов допустить ошибку, то придется долго блеваться. Потому что из-за \ компиялтор не сможет сказать на какой именно строке ошибка. |
| Автор: UnrealMan 2.10.2008, 14:02 | ||||||||||||
Да ну? Поддержка RTTI, исключения, шаблоны - всё это синтаксический сахар? Что же тогда по-твоему не синтаксический сахар? Может, у тебя и библиотечные функции - синтаксический сахар?
Между прочим, компилятор C++ самостоятельно вызывает деструкторы для базовых подобъектов и нестатических членов-данных объекта. Для весомой части классов деструкторов, сгенерированных компилятором по умолчанию, вполне достаточно. А там, где недостаточно, мы всё равно избавляемся от необходимости явно уничтожать агрегированные объекты.
Только не надо забывать, что реализуем мы деструктор всего один раз, а вызываться он должен для всех создаваемых в программе объектов. Сложность слежения за тем, чтобы деструктор был вызван всюду, где это необходимо, часто превосходит сложность написания самого деструктора.
Мсье выдаёт желаемое за действительное.
Без тёплого и уютного жилья тоже можно жить. Бомжи вон как-то живут. Не хочешь составить им компанию? Для тебя ведь уровень жизни, видимо, не важен? Шаблоны позволяют решать в общем виде задачи, которые без шаблонов полноценно в общем виде не решаются. Конечно, можно справиться с решением отдельных частных случаев задачи, но вот досада - это более затратно по времени. Решения в обход типобезопасности также затратны по времени - как прямо (за счёт необходимости отслеживания правильности преобразований), так и косвенно (за счёт практически неизбежно допускаемых ошибок, которые нуждаются во времени на их устранение).
А кто, собственно, требует читать исходники Boost? Вменяемый человек ради понимания того, как пользоваться библиотекой, руководствуется документацией к ней, а не её исходным кодом. |
| Автор: Lazin 2.10.2008, 14:53 | ||||
но только это нихрена не работает, так как память освобождается в самом аллокаторе |
| Автор: Любитель 2.10.2008, 15:52 |
| Насчёт аллокатора - если написать аллокатор, юзающий salloc - разве не то получится? |
| Автор: J0ker 2.10.2008, 16:30 |
| вы немного растекаетесь мыслею по древу. Аргументов невозможности обеспечить безопасность типов и невозможности создания неконфликтующих библиотек на основе макросов - вполне достаточно, что-бы коммерческий программист отдал предпочтение C++. |
| Автор: Любитель 2.10.2008, 16:37 | ||
С++ в этом плане не настолько уж и крут (не-не - разница есть, но не надо преувеличивать). |
| Автор: MAKCim 2.10.2008, 22:41 | ||||||
сразу видно, на С ты не программировал нет ничего сложного есть объект A, есть функция для его создания и уничтожения есть функция, использующая A в ней есть блок завершения, в котором идет вызов функции уничтожения переход на блок завершения идет через goto блоков завершения может быть несколько, в зависимости от числа типов создаваемых объектов располагаются последовательно в обратном созданию порядке любая функция строится по такому правилу в итоге нет ни утечек, ни сложностей для восприятия
аналогия в корне не верна
а почему ты решил, что я на этом акцентирую внимание? |
| Автор: J0ker 2.10.2008, 23:13 | ||||||
я не преувеличиваю C++ оставляет ВОЗМОЖНОСТЬ эту безопасность обойти, но если вам эта возожность понадобилась - ищите ошибки в проектировании, а язык тут совершенно не при чем. Добавлено через 8 минут и 32 секунды
Действительно, поразительно удобно Народ, он ИМХО над нами издевается кстати, а чтож вы на неудобные вопросы-то не отвечаете, а? |
| Автор: MAKCim 3.10.2008, 08:18 | ||||||
о вкусах не спорят сразу видно, что тут на С мало кто программировал
давайте список, буду отвечать Добавлено через 10 минут и 41 секунду
ничуть я сам был раньше фанатом С++ пока не понял, что он того не стОит |
| Автор: nerezus 3.10.2008, 10:03 | ||||||
Тогда Qt.
Вторая причина - в потенциальной кривости не программиста, а языка. Сравни C++ с Java. Только языки(не платформы). Т.е. считай, что в джаве есть указатели(естественно они deprecated) и она компилится в натив. Тебе не кажется, что тогда практически все бы выбрали Java(как и случилось с ентерпрайзом)?
Только вот этот "синтаксический сахар" очень удобен ;) P.S. До недавнего времени юзал C, теперь C++. Ибо Qt и классическое ООП(без него стало сложно). Ненавижу C++ за сложность(неоправданную). |
| Автор: UnrealMan 3.10.2008, 11:50 | ||||||||||||||
А ты что-нибудь посложнее Hello World на своём C программировал?
Ну, надо же, как всё просто Предположим, у нас есть два ресурса: первый захватывается объектом x, второй - объектом y:
В случае неудачной попытки захватить какой-либо ресурс, либо неудачного отрабатывания метода use_resource надо выйти из функции f (освободив все захваченные ресурсы) и передать ошибку наверх. Перепиши этот код на C.
Я так понял, ты теперь отказываешься от этого своего супер-аргумента "раз без шаблонов можно выжить, значит они не нужны"?
А кто ж тебя знает, на чём ты там акцентировал внимание? Я всё-таки не телепат.
Когда речь заходит о фанатах, я в первую очередь вспоминаю о том, что фанатизм, как и всякое помешательство, свидетельствует скорее о психических отклонениях у человека, нежели о том, что он грамотный специалист в своём деле. Вот если б ты сказал, что был профессиональным программистом C++ (а не каким-то там фанатом), то мог бы создать хоть какую-то иллюзию того, что так оно и было
Я не знаю Java и сравнивать их не стану (ибо предпочитаю говорить только о том, в чём, как я считаю, достаточно хорошо разбираюсь). |
| Автор: MAKCim 3.10.2008, 12:09 | ||||||||||
Добавлено @ 12:17
если это действительно вопрос, а не стеб, то да
отнюдь просто аналогия не верна бомж и не бомж - слишком ортогональные понятия тут больше подходит аналогия есть машина и нет машины во втором случае я могу взять такси
фанаты бывают разные и зачастую уровень знаний фаната, так же как и любителя, превосходит оный т. н профессионала Добавлено через 11 минут и 20 секунд UnrealMan давай все же на личности не переходить или по-другому ты дискуссию вести не умеешь? |
| Автор: NebelDT 3.10.2008, 13:57 |
| Не ожидал что мне столько народу ответит, пасиб! Добавлено через 4 минуты и 11 секунд Не ожидал что мне столько народу ответит, пасиб! |
| Автор: UnrealMan 3.10.2008, 14:09 | ||||||||||||||||
А каким чудом функция, вызвавшая f, узнает, что за ошибка произшла? Будем считать, что существует по меньшей мере две причины, по которой захват ресурса не может быть выполнен успешно, и то же самое будет в отношении использования use_resource. Нужно, чтобы в функции, вызывающей f, можно было распознать тип ошибки (т.е. конкретную причину сбоя). Кстати, нулевой handle обычно свидетельствует о неудачном захвате ресурса, так что в if-ах следовало бы добавить отрицание.
C больше походит на детский трёхколёсный велосипед, нежели на такси. Такси в определённом плане может быть ещё удобней, чем личное авто, ибо все тяготы, связанные с управлением машиной, уходом за ней, прохождением техосмотра и т.д. возьмут на себя специальные работники, осуществляющие и обслуживающие такого рода перевозки, а не пассажир, которому надо просто доехать из точки A в точку B. Это определённо не про C-программистов.
Зачастую этого уровня знаний хватает только на разжигание дурацких холиваров на форумах.
Ты, видимо, привык путать личную тягу к извращениям с потребностями других людей. При таких обстоятельствах дискуссия не может не затрагивать обсуждение личностей. Давай-ка посмотрим, с чего начался разговор.
Если б ты добавил "лично для меня не лучше", к тебе б претензий не было. Ну, нравится тебе извращаться со всеми этими макросами, void* и goto, извращайся дальше сколько угодно. Но тебе зачем-то понадобилось провокационно такое уточнение опустить и снизвести тему в холивар:
И дальше везде по тексту ты приравниваешь "мне не нужно такое средство языка, я готов заменять его вот таким-то барахлом" к "никому не нужно такое средство языка, все были бы просто счастливы заменять его вот таким-то барахлом со всеми вытекающими издержками". Выдавать свои личные мазохистские предпочтения за всеобщие, а потом обижаться при переходе на личности - это, видимо, и есть правильный подход к ведению дискуссий, по-твоему? |
| Автор: nerezus 3.10.2008, 14:14 | ||
|
| Автор: MAKCim 3.10.2008, 14:47 | ||||||||||||||
а, ну тут просто описка функция должна int возвращать (или любым другим способом сигнализировать об ошибке)
опять описка главное, что общая идея в коде прослеживается
аналогия раскрывается следующем образом машина = шаблоны нет машины = С есть машина = С++ возьму такси = сделаю по-другому в итоге и в первом случае, и во втором я доеду до пункта Б = решить задачу
это тонкий намек или мне кажется?
в холиварах тоже нужно вести себя корректно
ну вот опять переход на личности во-первых, почему мои предпочтения - мазохистские? извини, но пока всемирный вопрос на тему сабжа никто не проводил и результатов у нас нет во-вторых, ты только что сам начал выдавать свои взгляды за всеобщие в-третьих, я твой уровень знаний/профессионализм/... ни прямо, ни косвенно не затрагивал да, возможно я резок, но резок по сабжу, а не по отношению к другим мы все-таки в религиозных войнах Добавлено через 1 минуту и 37 секунд
это к чему? определение фанатизма? |
| Автор: nerezus 3.10.2008, 16:08 | ||
Кстати недавно привели пример, у тебя кода при переписывании стало больше в несколько раз. |
| Автор: MAKCim 3.10.2008, 16:23 | ||
от этого он стал менее понятным? |
| Автор: UnrealMan 3.10.2008, 17:08 | ||||||||||||||||||||
Просто описка? А на то, что размер кода станет ещё больше, мы внимания не обращаем?
Равноценной замены шаблонам в C нет. Более совершенной замены - тем более. Так что не надо тут преувеличивать насчёт такси: максимум, на что ты сможешь рассчитывать, это на трёхколёсный велосипед, позаимствованный у девочки Маши, либо на свои собственные ножки.
Потому что повышенная трудоёмкость (читай затратность по человеческим ресурсам) предлагаемых тобой изворотов очевидна. Если ты готов спорить с очевидным, то с тобой в принципе невозможно о чём-то договориться. К счастью, я и не собираюсь лично тебя в чём-то убеждать. Я тут ради собственного развлечения и ради тех, кто с очевидными вещами спорить не любит. Стремление выбрать из двух способов достижения цели наиболее затратный - это мазохизм. Для серьёзных коммерческих проектов такой мазохизм убыточен.
И вопросы проектирования крупных программных систем конечно же никто никогда не рассматривал. В каменном веке живём.
Что ж, я рад, что до этого высказывал только всеобщие взгляды А теперь, пожалуйста, приведи пример, где в предыдущем посте я несправедливо начал выдавать свои взгляды за всеобщие
Насчёт косвенности это ты зря упомянул. Немногим ранее ты написал следующее:
Между строк тут так и читается: "а если у вас получается не одинаково, то никакие вы не профессионалы в C". Конечно, тут можно было бы упрекнуть меня в вольной интерпретации, однако же эта твоя пафосная фраза без приведённого мной подтекста, теряет всякий смысл. Тут уж что-то одно: либо человек, который не в силах вести разработку на C так же эффективно, как на C++, недостаточно профессионал в C, либо ты просто ляпнул что-то не то.
Мне довелось участвовать в десятках религиозных спорах, причём религиозных в прямом смысле, т.к. предметом обсуждения в них было "христианство vs атеизм". Честно говоря, поражён, до чего уровень твоих аргументов похож на оный у христиан. Ты, случаем, не один из них?
Его как минимум сложнее читать и модифицировать. |
| Автор: nerezus 3.10.2008, 17:21 | ||
Т.е. на его написание, поддержку, разбор другими программистами и модификацию уйдет больше ресурсов. |
| Автор: J0ker 3.10.2008, 17:22 | ||||||||||
ну за стандарт вкуса принимают обычно не вкус небольшой доли извращенцев (которая всегда присутствует в обществе), а вкусы большинства нормальных пиплов а большинство нормальных пиплов предпочитают день потерять (досконально изучить хороший но сложный инструмент), а потом за пять минут долететь (писать совместимые программы гораздо быстрее, проще и эффективнее)
не волнуйтесь, мы и на ассемблере лабаем
да я уже раза 3 его давал 1. типобезопасность 2. решение 1. путем создания макросов которые: 2a. неотлаживаемы в принципе 2b. непозволяют конкурентное использование разных библиотек в силу конфликта имен и несовместимости
-- А вы детей любите? -- Нет... -- Ааааа, вы просто готовить их правильно не умеете!!! Так и скажите, что вам просто лень изучать сложный инструмент Добавлено через 3 минуты и 8 секунд
она оправдана близостью к железу |
| Автор: vinter 3.10.2008, 17:33 | ||||
вкусовых стандартов не существует MAKCim, сразу видно соскчилсмя по РВ
ты считаешь быть христианином это что-то плохое? |
| Автор: J0ker 3.10.2008, 17:44 | ||||||
нет, батенька во втором случае вам на камазе привезут набор запчастей, свинченных с разных автомобилей и на карете скорой помощи доставят таксиста с инсультом ваша задача будет - собрать из несовместимых запчастей машину, нарисовать на ней шашечки, а затем откачать таксиста - вот тогда возможно вас куда-то и отвезут... и не важно, что самолет уже трое суток как улетел Добавлено через 3 минуты и 52 секунды
а я и не писал, чтосуществует, я писал "принимается" это вопрос рациональности, а не искусства
скорее глупое слепая вера - один из анти-паттернов |
| Автор: vinter 3.10.2008, 17:58 | ||||
на самом деле ты уже не прав, да и разговор это оффтопный. Надо понимать, что не все верующие фанатики, и уж тем более не все крещенные христьяне являются фанатиками. Если кто-то чего-то непонимает и не признает, это не значит, что этого нет. Добавлено через 1 минуту и 59 секунд
рациональности во вкусе быть не может. Я люблю пиццу. Но это не рационально, по твоей теории я ирроционален, а так большинство этого мира. Значит рациональность граничит с иррациональностью, что делат их неразличимыми в данном контексте. |
| Автор: Любитель 3.10.2008, 18:24 | ||||
Сложность С++ оправдана близостью к железу?! Сложность С++ ничем не оправданна - это просто исторический факт. А С что дальше от железа что ли
Ну уж до такого можно было бы и не опускаться ;) Давай не будем отходить от "технических" вопросов |
| Автор: nerezus 3.10.2008, 18:34 | ||
Если прийти к вере основываясь на изысканиях, логике и прочих рациональных факторах — то хорошо. |
| Автор: Любитель 3.10.2008, 18:47 | ||
Готов поспорить на самом деле (не только насчёт христианства - а насчёт утверждения, что логика хорошо, а вера плохо), но этож оффтоп уже пошёл. |
| Автор: J0ker 3.10.2008, 19:49 | ||||||||||||||
знаете, пытались меня всякими пресуппозициями наколоть, но чтоб так нагло - это впервые - зачет (добавил себе в подпись )
а про фанатиков я даже и не говорю
проблема в том, что от нас требуют признания без понимания - это постулат всех современных религий - есть это или этого нет - вопрос В ПРИНЦИПЕ не ставится (причины я могу вам рассказать отдельно ибо это обширная тема)
не передергивайте - я говорю НЕ о рациональности вкуса, а о принятии стандартом вкуса большинства - в коммерческом производстве это определенно рационально
оправдана совмещением близости к железу и концепции ЯВУ исторический факт - это лишь обратная совместимость с plain C - многие несуразности посто вынудены поддерживать. Все остальное обусловлено лишь попыткой совместить нативность с высоким уровнем абстракции. Если вам не нужна нативность - вперед на недоделанную джаву. В конце концов и хаскель есть... В plain C-же уровень абстракции на порядок ниже, а нативные проблемы те-же самые. Безусловно добавление уровня абстракции добавляет сложность этой абстракции, но оно так-же добавяет эффекивности и удобтва использования - за все в жизни надо платить.
а разве анти-паттерны это не технический вопрос?
ну давйте попорим - там где-то и раздел наверное подходящий есть только вот сложно о чем-то спорить с тем, кто не признает логических доводов |
| Автор: maxim1000 3.10.2008, 20:25 |
| Ох... ну и мне, что ли поучаствовать в религиозных войнах Все соображения основаны на личном опыте ну и немного на опыте окружающих и прочитанных статьях всяких. Языки в том виде, в котором они сейчас есть, появились не просто так. У каждого популярного языка программирования есть своё сообщество. И объединяет их набор того, что они ценят в процессе программирования, что и определяет критерии развития того или иного языка. И получается, что даже решая одну и ту же задачу, программисты на разных языках будут решать несколько разные задачи. Потому, что всегда есть критерии "по умолчанию" (скорость, поддерживаемость, масштабируемость), под которыми в каждом сообществе понимаются разные вещи, да и коэффициенты у этих "слагаемых" тоже разные. Взять, например, C++ и С (ниже - не полный список, а только примеры различий): Первым программистам нравится сбрасывать на компилятор (т.е. compile-time) кучу действий, чтобы быть уверенными, что ничего не забыто. Вторым программистам тупо не нравится, когда за безобидной скобкой "}" может скрываться огромная куча кода в деструкторах, которая закрывает подключения к БД, сбрасывает содержимое буферов в файл и вообще выключает комп и там, и там за чем-то нужно следить, у одних лучше получается следить за неявно вызываемым кодом, у других - за тем, когда нужно освободить память Изначально это было просто из-за специфики задач: одним хочется код, который больше отражает смысл производимого действия, а не всевозможные вариант обработки ошибок, другие не могут рисковать, чтобы в real-time задаче вызывался код, которого не видно, а значит, оценка времени начинает быть нетривиальным занятием. Но сейчас границы между областями размыты. На C пишут графические приложения, на С++ (да и на Java, если уж на то пошло) - программы для мобильных телефонов. Но люди подходят к задачам всё равно со своими критериями, и то, что они выбирают "свой" язык, вполне естественно. И потому сложно объяснить программисту на C, почему ему нужны шаблоны - они ему не нужны, т.к. критерии у него такие, что препроцессор вполне для них подходит. И программисту на C++ - что видеть весь код, который выполняется именно там, где он выполняется, может быть важным. Может, когда-то и сделают язык, который удовлетворяет и те, и те критерии (да и от Java можно немало взять, не говоря уже о функциональных языках). Так что вместо того, чтобы спорить о том, что лучше крылья или плавники, лучше обсуждать, кому где надо передвигаться... Вот где-то так... Изо всех сил старался быть объективным, хотя сам считаю, что тут и спорить не о чем - в C даже нельзя сделать такой банальной вещи, как посчитать факториал в compile-time |
| Автор: J0ker 3.10.2008, 20:37 | ||
именно поэтому типы в C++ разделяются на Основные (они-же базовые, фундаментальные, POD), Агрегаты (ониже PODS), и Классы. "Скрываться" это может только от ленивого. |
| Автор: UnrealMan 3.10.2008, 21:58 | ||||||||||||||
Ключевое слово здесь "тупо" С тем же успехом можно недовольствоваться сокрытием кода за вызовом функции, которая этот код содержит.
Маленькое уточнение: в большинстве случаев за вызовом деструкторов следить не нужно вообще.
Вот незадача: исходного кода любой функции (хоть явно она вызывается, хоть неявно) не видно в месте её вызова. Такие вот пассажи касаемо связи сокрытия кода с потерей производительности исходят либо от фундаментального непонимания того, откуда в большинстве случаев исходят устранимые потери производительности, или от откровенного лукавства, целью которого является хоть какое-то видимое оправдание своей мышиной возни с C.
Я очень сомневаюсь, что медитация над вызовами функций, очищающих ресурсы, способна привести к решению внесения неких изменений, благодаря которым будет достигнуто заметное повышение производительности.
Ну да, каких только критериев не встретишь у C-программимазохистов
Руководства правилами языка вполне достаточно.
Интересно было бы узнать, где имеет смысл применять такой подсчёт. |
| Автор: maxim1000 4.10.2008, 00:50 | ||||||||||||
эту фразу стоит рассматривать только в контексте с смайликом, который шёл после неё - Религиозные Войны всё-таки-------- честно говоря, возможно, мои примеры преимуществ C могут оказаться несколько надуманны, т.к. я ощущаю себя значительно комфортнее в C++, чем в C но нельзя сбрасывать со счетов, что мы (имеется в виду C++-программисты) уже освоились в той структуре языка, которая сложилась на данный момент, и его сложности нам кажутся проще (а иногда и совсем не сложными), чем другим
Большинство программ развиваются и видоизменяются. В процессе это развития типы могут переходить из одной группы в другую. Например писали функцию для double, а потом стали использовать complex. Писали для структуры, которая содержит координаты точки x,y,z в 3d на какой-то поверхности, перешли на параметризированный вид x,y,f(x,y), а потом и вообще на чтение из какого-то большого файла вместо вычисления f(x,y). [кривовато, конечно, но дальше продолжение ответа и в том числе ответ на реплики]
И для C++ абсолютно нормально, что знание о том, как объект будет удалён находится не возле "}", а в месте объявления объекта (ну а точнее ссылка на это знание). Это отличается от хронологического порядка, часто встречающегося в программировании - если что-то идёт после чего-то другого, то и выполнено оно будет позже. И я вполне мог допустить, что это не для всех комфортно.
Необходимые времена жизни объектов не всегда укладываются в идею стека, поэтому и приходится либо расширять их и использовать стековые объекты, либо переходить на ручное управление временем жизни. В таких случаях второй вариант вполне может обеспечить прирост эффективности не только по времени, но и по использованию памяти. И не всегда его можно заметить если алгоритм уже описан в терминах стековых объектов, особенно если вступает в дело взаимодействие соседних итераций одного цикла.
В том-то и состоит моя мысль, которую я отчасти хотел описать в первом посте: язык, как набор правил, бесполезно рассматривать в отрыве от идей, принятых в сообществе, которое его поддерживает. Более того, сами правила - всего лишь следствие тех или иных ценностей, принятых в этом сообществе (хотя нельзя не признать, что они же потом на эти ценности и влияют). Когда спрашивают "почему нельзя сделать <...>", ответ "потому, что это запрещено правилами языка (ну или стандартом)", ИМХО, в конре неправилен. Стандарт - не цель, это способ реализовать какую-то общую площадку, на которой можно писать, удовлетворяя принятым в сообществе критериям. |
| Автор: UnrealMan 4.10.2008, 02:02 | ||||||||
Допустим, "комфорт", связанный с видением всей последовательности операций в соответствующем порядке представляет собой какую-то ценность. Возникает резонный вопрос: какой ценой он достигается? Во-первых, тело функции становится длиннее, а в более длинных функциях менее удобно ориентироваться. Во-вторых, это неизбежно провоцирует ошибки: иногда функцию, заменяющую деструктор, либо вообще забывают вызвать, либо с перепугу вызывают дважды (если функция большая, то такую ситуацию можно и не заметить). Довольно дорогостоящий "комфорт", однако.
Когда требуемое время жизни объекта не укладывается во время жизни одного автоматического объекта, в большинстве случаев его следует уложить во время жизни нескольких вспомогательных автоматических объектов. И только если такой подход даёт неприемлемый оверхед, то тогда уже можно мудрить с чисто ручным управлением, которое в C++ доступно ровно в той же степени, как в и C.
Собственно, за счёт чего может быть достижим такой прирост? За счёт избавления от копирования объекта? Дык копирование достаточно несложно отслеживается, т.к. ситуации, когда оно осуществляется, вполне чётко очерчены рамками языка.
За этими ценностями должны стоять рациональные мотивы (касающиеся характеристик программного продукта и затрат на его создание), а иначе такие ценности (равно как и выведенные на их основе правила), кроме как сообществу фанатов, никому на фиг не нужны. |
| Автор: kemiisto 4.10.2008, 03:05 | ||||||||||||
Написано много, долго читал, разделяю точку зрения MAKCim'а. Подолью масла в огонь... Давайте-ка, обратимся к истории вопроса.  Итак, по-порядку...Начале 1970-х годов - Кеном Томпсоном и Денисом Ритчи создают C. Для разработки и последующего использования в операционной системе UNIX. 1983 - вышеупомянутые получают Премия Тьюринга (в сфере информационных технологий эта премия имеет статус, аналогичный Нобелевской премии в академических науках) (внимание!):
Конечно же, не будь C - не было бы и UNIX! С ценят за его эффективность и он является самым популярным языком для создания системного программного обеспечения. И всё же, почему так важно, что премию дали не за C? А потому, что годом позже... 1984 - Никлаус Вирт получает Премию Тьюринга (опять же внимание!)
Если бы мы обсуждали "холивар" C vs PASCAL, я бы поставил на этом точку. Но я продолжу... Начало 80-х годов - Бьярне Строуструп придумал ряд усовершенствований к языку С под собственные нужды (как утверждает Народная Энциклопедия). 1998 - ратифицирован первый международный стандарт языка С++. 2001 - знаковое событие - Ole-Johan Dahl и Kristen Nygaard (я позволю себе оставить имена в оригинале, ибо транскрипций много) награждаются Премией Тьюринга:
Лучше поздно, чем никогда! Внимательно вчитайтесь за что дали премию! Можно конечно возразить, мол дали за идеи, а в C++ они были воплощены! НО! Историю не перепишешь! И 2003 год ознаменовался не только выходом нынешней версия стандарта С++ но и вручением Премии Тьюринга Алану Кэю за:
Да будет вам известно, что первая версия Smalltalk'а была разработана в 1971. Страуструп в это время университет то не закончил, а люди в Xerox PARC уже вовсю мыслили объектами! Почитайте хоть немного вот http://www.smalltalk.ru/articles/smalltalk.html и вы, возможно, многое поймёте... 2005 - в очередной раз Премия Тьюринга вручается за разработку ЯП. На этот раз Питер Наур удостоился этой чести:
А как же Страуструп? Не удостоили. Забыли? Очередь не дошла? А может, попросту, не достоин?! Ещё можно почитать про Oberon. Например, http://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%B5%D1%80%D0%BE%D0%BD_(%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F). Обратите внимание вот на что. Вирт постепенно упрощал и до сих пор упрощает синтаксис (убирая элементы, которые, оказались ненужными, либо вызывали неоправданное усложнение реализации компилятор). А мощь языка только растёт! Oberon поддерживает ООП не множа сущности (смотри расширяемые записи), описание языка занимает страницу, производительность на уровне C! Так ещё и есть сборка мусора! А что делают наши старые знакомые-датчане? Первый (Страуструп) усложнает С настолько, что:
Я после третьего правила читать не мог! "Плакалъ"! Это, вообще, здравомыслящий человек написал? Второй (Хейлсберг) поступает аналогично с PASCAL. Правда, потом пытается (и относительно небезуспешно) иправить ошибки первого под крылом MS... Так что, можно реабилитировать! Вот, как то так... |
| Автор: J0ker 4.10.2008, 03:58 | ||||
тот, кто делает рефакторинг кода должен понимать разницу между типами типов (пардон за тафтологию). Если он этого НЕ понимает, то тут проблема не в сложности языка, а в некомпетентности программиста. Добавлено через 3 минуты и 52 секунды
ну на этом фоне изуверства MAKCim'а с goto уже совсем не комильфо |
| Автор: J0ker 4.10.2008, 04:20 |
| kemiisto, кипешь не понят итак понятно, что премии (в том числе и нобелевские) вручают намного позже факта потом, никто-же не утверждает, что C++ лучший и первый ОО язык - вопрос в приемуществе C++ конкрено над C и потом, пользуясь вашим-же сравнением, по аналогии - Эйнштейну нобелевку вручили вовсе не за Теорию Относительности - так что, порешим значение ТО в современной физике, выражаясь юридическим языком, ничтожным? |
| Автор: maxim1000 4.10.2008, 10:48 | ||||||
суть в том, что у них другой "курс обмена" одних сложностей на другие (при чём мы не считаем сложностями первое, а они - второе)
Ну, пример придумать можно: есть у нас объекты A, B, C (пусть они переданы в функцию) потом мы делаем преобразование f(A, B, C), которое даёт нам объект D а потом - преобразование g(B, C, D), которое даёт нужный результат объект A на момент второго преобразования уже не нужен, к тому же он занимает много памяти, которая очень нужна для выполнения g. Вот и становится полезно удалить его вручную до вызова g. Конечно, здесь можно придумать какие-то дополнительные стековые объекты, и для программиста на C++ это может оказаться даже полностью естественно и просто, но что может быть проще delete A перед вызовом g? (да, такая организация программы может потянуть кучу потенциальных проблем, которых мы привыкли избегать (в смысле решать заранее), но и ценность этой простоты сложно отрицать). Добавлено через 4 минуты и 17 секунд
ну, там они, насколько я заметил, ведут себя вполне хронологически - наверх не переходят впрочем, там другие проблемы - если в функции будет две ветки if'а, в каждой из которых выделяются свои ресурсы, которые нужно будет освободить, такое решение уже не очень подойдёт |
| Автор: MAKCim 4.10.2008, 11:03 | ||||||||||||||||||||||||||||||||||||||||||
дело не в количестве, а в качестве бывает, код длиной в 5 строчек, труден для восприятия
доехать до пункта Б = решить задачу и С без шаблонов, и С++ с шаблонами доедут до пункта Б шаблоны - это не панацея, есть туева хуча языков без шаблонов, тот же Python к примеру я согласен, что типобезопасность будет снижена, но при ведении грамотной документации и наличии прямых рук вероятность ошибок достаточно низка
объектный подход != ЯП ядро Linux - крупный програмный проект? VIM - крупный програмный проект? EMACS - крупный програмный проект? Python - крупный програмный проект? GTK - крупный програмный проект? ...
не забываем про производительность исключения, к примеру, могут очень дорого обойтись в конечном итоге
если ты умный человек, ты понял, о чем я
справедливость - не контекстно-независимый концепт здесь мы ни о чем не договоримся
именно, НО заметь, тут нет никакого намека на UnrealMan тут общий тезис, никого конкретно не затрагивающий у тебя же
тут прокомментирую по отношению к другому фанат может быть необъективным, но об объекте фанатизма он осведомлен в достаточной степени, чтобы быть "грамотным специалистом в своем деле"
опять таки, смотря кому С приграммисту легко, С++ программисту, возможно, тяжело, обратное тоже верно
видели мы ууровень лаб (без обид, никого из здесь присутствующих я не имею в виду, просто лабы и реальное программирование несколько отличаются)
да ниже (читай этот пост сначала, я уже писал об этом)
уточни, что подразумевается под отладкой
префиксы/суффиксы имен
я С++ знаю может это и не показатель (скорее всего), но комодераторами тематических разделов на винграде просто так не назначают я просто не знаю другого более менее объективного показателя, с которым могут согласится большинство форумчан
наболело J0ker, вопрос прямой ты профессионально занимался разработкой больших систем на С? (профессионльно = получал деньги, больших = хотя бы > 20000 строк и > 50 модулей (*.h, *.c файлы)) Добавлено через 7 минут и 52 секунды maxim1000, соглашусь по большей части это еще раз оправдывает мой тезис "главное, чтобы человек был профессионал в своем деле" Добавлено через 11 минут и 59 секунд
ой как мне не хочится начинать по поводу goto  что в моем примере изуверство? это стандартный способ управлением жизненным циклом объектов без дублирования кода и потери эффективности засчет вызова функций |
| Автор: MAKCim 4.10.2008, 11:23 | ||||
два вложенных if-а - это уже недостаточно хорошо и по возможности от этого надо избавляться (разделяю точку зрения Торвальдса) избавляемся инвертированием условий иначе - вызов функции что-то типа такого
применя правило рекурсивно, можно разрулить любую степень вложенности в ядре Linux эта тема раскрыта в полной мере есть * функции и __* функции вторые - это первые с конкретным инвариантом Добавлено @ 11:28 вообще говоря, крайне глупо сравнивать С и С++ as is принципы эффективного программирование на оных различаются то, что на С++ решается одним методом, на С будет решаться другим, но это не значит, что от отсутствия первого в другом теряется эффективность другого Добавлено через 13 минут и 18 секунд ну и вообще, спасибо тем, кто хоть как-то разделяет мою точку зрения это достаточно рисковано, замахнуться на "святое" |
| Автор: Lazin 4.10.2008, 11:49 | ||||
Все высокоуровневые средства С++, призваны бороться со сложностью, иногда это обескураживает, например вот строчка кода из одного реального проекта:
это просто вывод в лог, выглядит просто, но на самом деле хрен там: oik_error - макрос, который создает временный объект:
когда объект класса oik::log::logstream создается, он получает ссылку на глобальный объект класса logstream_backend, перегруженый оператор % вызывает шаблонную функцию logstream_backend.write с соответствующим параметром, а в свою очередь обращается к буферу (локальному для каждого потока) и форматирует в него переданое значение, следующий вызов оператора % делает то-же самое, только дописывает свои данные в конец буфера и тд, в результате буфер содержит строку сообщения, которую нужно записать в лог, затем, в деструкторе, при разрушении объекта класса oik::log::logstream вызывается библиотечная функция, которая копирует данные из буфера в "большой и длинный буфер вода вывода"(тм) который имеет размер кратный размеру сектора на диске, а так-же это буфер выровнен по границе страницы, в этот буфер могут писать несколько потоков одновременно не нарушая его структуру, далее, в случае если места в буфере не хватает, он будет сброшен на диск(напрямую, без кэширования), точнее будет сброшена только его часть, кратная размеру сектора, а то, что осталось, будет перемещено в его начало, во время этого процесса, будут заблокированы другие потоки(если они попытаются записать что-то в буфер), после того, как "большой и длинный буфер вода вывода"(тм) будет очищен, сначала будет запущен поток, который запусти этот процесс, а потом остальные, в том порядке, в котором они пытались записать данные. После этого буфер в который форматировались данные то-же будет очищен, далее, в случае если есть сетевое соединение, данные будут посланы клиенту, асинхронно ( есть клиентская программа, с помощью которой можно мониторить активность программ) наверное иногда не очень хорошо, когда одна строчка делает столько разной херни |
| Автор: UnrealMan 4.10.2008, 12:32 | ||||||||||||||||||||||
Если сложить всё вместе, то предлагаемый тобой код заметно труднее для восприятия. И не надо тут прятаться за субъективность - мол, для некоторых людей оно одинаково. С тем же успехом можно было бы утверждать, что психология - наука ни о чём, все люди разные и всё тут.
Выжить = решить задачу. Человек с домом и человек без дома выживают. Итак, ещё раз: не хочешь ли ты стать бездомным?
Это одно из преимуществ C++ перед C.
Использовать объектный подход на необъектно-ориентированном C затратнее, чем на объекто-ориентированном C++.
И что это доказывает? Что при создании этих проектов разработчикам не пришлось пострадать геморроем?
Могут, если их использовать не по назначению. Ну и что?
Я уже давно (ещё до появления этой темы) понял, что литературы, освещающей вопросы архитектуры программ, ты либо вообще не читал, либо читал очень мало. Зато рассуждать горазд.
Ага, т.е. если опустить одного человека - это плохо, а если опустить целую группу людей оптом, то в этом уже не будет ничего зазорного. Забавная у тебя логика
Ты тупо отрицаешь очевидное. Как я уже говорил, убеждать тебя лично я не собираюсь. Те, кто очевидное не отрицает, пусть делают выводы сами.
Мда уж, видел я твой уровень знаний. |
| Автор: kemiisto 4.10.2008, 12:54 | ||||||||
J0ker, я вот что хотел сказать. Рассмотрим императивное программирование. Существует программирование в машинных кодах - назовём его нулевым уронем абстракции. Далее, первый уровень - ассемблер (здесь уже есть мнемонические команды). Третий уровень - процедурные языки, или языки структурного программирования (это как хотите). Четвёртый - ООП. Так вот, несмотря на все недостатки С и несмотря на то, что, по большому счёту, своему успеху он обязан UNIX этот язык закремился на третьем уровне. Системные программисты любять С. А что C++? Вот Вы же сами правильно писали:
Вот, вот. Лень было в своё время программистам изучать SIMULA и Smalltalk. Они пошли по пути наименьшего сопроотивления - С++ - там хоть синтаксис был знакомый и совместимость c C есть.
То, что Вы плохо знакомы с физикой - очевидно из приведённой цитаты. Крайне неудачный пример. Во-первых, Альберт Эйнштейн получил премию «За заслуги перед теоретической физикой и особенно за открытие закона фотоэлектрического эффекта». Формулировку видите? Особеннно, но не только за теорию фотоэффекта. Во-вторых,
И СТО и ОТО тогда считались спорными! За спорные теории Нобеловской премии не дают! Видимо, и формулировку Премии Тьюринга создателям С можно трактовать в том же русле - за разработку теории ОС (и за создание UNIX в частности). Про С нет ни слова! |
| Автор: MAKCim 4.10.2008, 15:06 | ||||||||||||||||||
и тебе задаю этот вопрос ты профессионально (или вообще) программировал на С?
понимаешь ли в чем дело возьмем любые две сущности, одна обладает неким атрибутом, вторая нет тогда на них можно экстраполировать твой тезис? но это ж бредв качестве примера в С99 есть такая штука
в С++ ее нет но в С++ эту задачу можно решить обычным присваиванием (резкое увеличение кода, однако )как итог: ты хочешь стать бездомным?
ты профессионально (или вообще) программировал на С?
если ты знаешь, что они страдали, скажи мне, почему они не выбрали С++?
хотелось бы услышать способы использования исключений, а то я только 2 знаю
голословно, подкрепи фактами или хотя бы приведи логику своих рассуждений
ты профессионально (или вообще) программировал на С?
факты, факты и еще раз факты я вот знаю про тебя только то, что ты якобы хорошо знаешь "стандарт" C++ (хотя, может, это только понты) |
| Автор: MAKCim 4.10.2008, 15:32 | ||
веришь или нет, никого опускать не хотел даже не думал, что этой фразой могу кого-то оскорбить Добавлено @ 15:38 UnrealMan да, кстати не хочешь вместо меня модератором в С++ (общие вопросы и для новичков)? у меня времени мало да и энтузиазма особого нет из-за моей позиции ты, я вижу, гуру (по крайней мере мне с моим уровнем знаний до тебя далеко), форум только приобретет от такого назначения |
| Автор: MAKCim 4.10.2008, 15:55 | ||||
ну а я напишу (из реального проекта)
я думаю, этот код без труда поймут как С, так и С++ программисты сложность С++ - это понты для тех, кому кроме медитирования над книжкой Страуструпа/стандартом больше нечем заняться |
| Автор: UnrealMan 4.10.2008, 17:08 | ||||||||||||||||
Конкрентно такая штука редко нужна. Вот явное указание полей структуры при инициализации - это действительно полезная вещь. Но по сравнению с шаблонами это довольно скромное преимущество.
Вообще программировал, но мало. С кодом на C++, написанном в стиле C другими программистами, имел дело достаточно. Насколько бы скромен не был мой опыт работы с C, я предпочитаю доверять общепризнанным авторитетам и собственной интуиции, нежели тебе с твоими неизвестно на чём основанными идеалистическими тезисами. В любом случае было бы наивно полагаться исключительно на собственный опыт (тем более, что и у меня и у тебя, в сравнении с опытом некоторых людей, он в общем-то ничтожен). А это значит, что опыт, накопленный другими людьми и изложенный в литературе, вероятно, следует рассматривать, в первую очередь.
Здесь высказано в точности то, о чём я говорил.
А это ты у них спроси
А я знаю только один: выбросить и поймать
Высказываемые тобой тезисы поразительно часто расходятся с высказываниями и рекомендациями авторитетных авторов литературы по программированию. Рыться в твоих постах ради приведения конкретных примеров мне, откровенно говоря, лениво (да и время зря тратить не хочется). Касаемо этого вопроса можешь упрекать меня в голословности - дело твоё.
Там тогда некому будет отвечать на вопросы Лучше оставить всё, как есть. |
| Автор: J0ker 4.10.2008, 19:26 | ||||||||||||||||||||
нет, они там В ОБРАТНОМ порядке - чел пытался сымитировать разрушение при выходе в случае возникновения исключения так шо не комильфо
подойдет подойдет - там надо будет перед } продублировать тот-же код
сразу замето что мы из разных поколений - "лабать" по фене - играть (на музыкальном инструменте обычно)
не скромничайте - она будет отсутствоват без макросов
ээээээ.... пардон.... у нас тут прграммисты собрались или где?
т.е. вы хотите использовать префиксы/суффиксы для ВСЕХ экспортируемых имен библиотеки (заметьте, не только для макросов)? 
разработкой конечно нет - я-ж не мазохист Поддержкой - да, так-что знаком с макрос-бэйзд контейнерами
goto не при чем читайте контекст Добавлено через 5 минут и 12 секунд
теряется не эффективность кода, а эффективность разработки - т.е. вас уволят ДО выяснения эффективен код или нет
не стройте из себя мученника |
| Автор: vinter 4.10.2008, 19:37 | ||||
очень неправильный подход, выдающимися люди становяться не из-за того, что воспроизводят чужой опыт, а из-за того, что реализуют нечто новое и необыкновенное. Не задумавался никогда почему нет ни одного известного вундеркинда?
UnrealMan, а ты зачем нас убогих тогда вообще посещаешь? |
| Автор: J0ker 4.10.2008, 20:00 | ||||||||
должен я сделать из этого вывод, что системные программисты любят SIMULA и Smalltalk? или вы чего-то недоговариваете? может быть системные программисты просто не любять ООП а не конкретно C++?
ну не занимайтесь буквоедством У них так принято - почитайте остальные формулировки Так-шо можете считать дефакто - только
извините за цитирование, но "То, что Вы плохо знакомы с физикой - очевидно из приведённой цитаты." Не спорных теорий не бывает в природе. Основной принцип научности теории - это ее фальсифицируемость - т.е. теория на протяжении всего своего существования обязана оставаться спорной - здесь можно говорить лишь о ее достоверности. Именно поэтому, кстати, теория Бога не является научной и именно по этому РАН отказывается добавлять теологию в число научных дисциплин. Да, и почитайте формулировку ВРУЧЕННЫХ премий - там не одна за теорию выдана. Ну дальнейшая посылка вобщем-то ничтожна в свете вышесказанного |
| Автор: UnrealMan 4.10.2008, 20:29 | ||||||
Типичная отмаза тех, кто не хочет изучать опыт других людей и созданные ими технологии. Типа раз некто изо дня в день Америку открывает и велосипеды изобретает, то, глядишь, он вот-вот выдающимся человеком станет. Ну-ну.
Как насчёт Карла Гаусса?
Прежде всего ради собственного развлечения. |
| Автор: nickless 4.10.2008, 21:49 |
Ого, тут прямо войны  Много писать некогда (да и лень), я просто вот что сказать хотел, сравнивать похожие языки по фичам и удобности довольно просто, да и подобрать конкретные критерии по которым можно считать язык "лучше" тоже сравнительно легко. Сравнивать же диаметрально противоположные языки, использующие разные парадигмы и предназначеные для разных целей - гиблое дело. С таким же успехом можно сравнивать трактор и гоночный мотоцикл - на обоих можно ездить, но в остальном... Ну можно сравнить размер колёс, или там шум двигателя, но большинство сравнений переходит в что-то подобное этому: - а на трактор можно сеялку привесить! - да на кой? нам на мотациклах сеялки вообще не нужны - да как же, ведь без сеялки никак, вот как бы ты на мотацикле зерно сеял? - ну можно что-нибудь придумать, по полю ездить и разбрасывать, но это всё фигня, зато на мотацикле можно до 100 за 3 секунды разогнаться! - дааа... посмотрел бы я как ты по полю 100 едешь - сразу видно ни разу на мотациклах не ездил... у тебя хоть права-то на него есть? или может ты вообще без прав? ... Я к чему клоню Чтобы программировать эффективно и с удобствами нужно использовать подход который в первую очередь удобен программисту, т.е. он должен его не только понимать, он должен думать на нём. А уж потом на основе этого он выберет себе и подходящие задачи, и язык, поддерживающий этот подход.Некоторые потом программируют точно так же на других языках/парадигмах. Встречают массу неудобств, ведь задача и/или язык не преднозначены для другого подхода - приходится изворачиваться. Но даже если удаётся писать как удобно, то код такой выглядит для других программистов просто дико, делает много не нужный вещей, плохо совместим с другим кодом, не использует всякие удобства языка или использует их изумительно извращённым способом...  Конечно профессионал тем и отличается, что не только знает несколько языков/либ/фреймворков/итд но и может вполне сносно написать всё что угодно на любом из них. Но, даже сделав всё по правилам, по "другим" правилам, он не будет чувствовать себя комфортно - НЕ ТО. Не удобно, можно было бы сделать по-другому (как было бы правильно на другом языке, как привык итд), замечается масса недочетов другого подхода, в конце концов хочется похоливарить В то же время используя "свой" привычный способ, всё идёт как по маслу, недочеты и неудобства этого подхода не замечаются, просто сама проблема решается совсем по другому, теми средствами что есть, и ничего другого и не нужно. А тех мест, где удобно было бы использовать другой подход, т.е. те же шаблоны или исключения, просто не возникает. Со временем что-то может конечно изменится, другой подход может понравится больше, и тогда всё повторяется, но уже в других холиварах... Так что давайте жить дружно, каждый язык имеет право (хотя, нет, не каждый ) на существование, свой подход и свои задачи.А ведь не хотел писать много  |
| Автор: kemiisto 4.10.2008, 21:54 | ||||
Можеть быть просто напросто не стоит "выдирать" цитаты из разных постов? Обсуждение идет в контексте прикладного ПО, т.к. иначе спор бессмыслен. И собственно так тема и называется ("для простых прог"). Так вот, когда то и прикладное ПО писали на процедурных языках (C, PASCAL). Потом пришло ООП (SIMULA, Smalltalk), но лень победила. Зато когда Страуструп, (как многие считаю, "придумал ряд усовершенствований к языку Си под собственные нужды." (цитата из Википедии), а на самом деле просто попытался "прилепить" красивый ярлычок "ООП" к С) создал C++ - массы откликнулись! Синтаксис тотже, совместимость есть + ООП.
Полный бред! Простите, конечно, за грубость... Читаем для начала хотя бы http://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BB%D1%8C%D1%81%D0%B8%D1%84%D0%B8%D1%86%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D1%81%D1%82%D1%8C. Во-первых, почему это "основной"? Во-вторых фалсифицируемость теории означает, что должна существовать возможность (пусть даже нипотетическая) её опровержения путём постановки эксперимента. Разницу с написанным Вами чувствуете? Ну, а в третьих, Вы же сами пишите, что это критерий НАУЧНОСТИ! То, что теория относительности фальсифицируема говорит в пользу ее научности! |
| Автор: J0ker 4.10.2008, 22:21 | ||||||||||
чтд собстна куча кода уже написанного требует совместимости
да сами почитайте http://en.wikipedia.org/wiki/Theory я это и так знаю видите-ли, многие рускоязычные статьи в Википедии не блещут полнотой так-что не горячитесь...
один из основных вас устроит?
нет не чувствую требование возможности постановки оровергающего эксперимента исключает теорию из множества бесспорных сущностей (надеюсь c http://en.wikipedia.org/wiki/Mathematical_logic вы знакомы?).
я вас поздравляю. судя по восклицательным знакам вы открыли что-то для себя новое |
| Автор: UnrealMan 4.10.2008, 22:23 | ||
В сад. C++ позволяет делать почти всё то же, что и C, одинаково легко. Это явно не оставляет поводов считать эти языки диаметрально противоположными. |
| Автор: J0ker 4.10.2008, 22:42 | ||||
UnrealMan по правилам ООН писмэйкеров бить не положено - они должны стоять в сторонке и призывать: "Ребята, давайте жить дружно" |
| Автор: vinter 4.10.2008, 22:44 | ||||
UnrealMan, ты видимо не понял, перед тобой никто не отмазывыается, не то место для отмазок, тут в них нет смысла. Ты считаешь , что надо следовать опыту других людей и стандартам, кто-то считает иначе.
Вики почитал? Я тоже почитал, нет там ни одного факта по которому его можно назвать вундеркиндом, он был именно гением, но он не был вундеркиндом. P.S народ, я бы вам советовал не спорить с UnrealMan и J0ker, это совершенно бесполезно. |
| Автор: J0ker 4.10.2008, 22:50 | ||
читай подись |
| Автор: nickless 4.10.2008, 23:03 | ||
Да, а еще это можно делать на куче других языков, но тем не менее подход абсолютно разный. Не, можно конечно программировать на C и компилировать это C++ компилятором, но программа эта так и останется C-шной. А вообще я во всём посте ни разу не сравнил C и C++ |
| Автор: Dims 5.10.2008, 00:02 |
| Все эти штучки (объектность) нужны для разгрузки мозга. Соответственно, на тех задачах, где мозг сильно не нагружен, они и не нужны. |
| Автор: UnrealMan 5.10.2008, 00:46 | ||||||||||||
В этом плане мои взгляды традиционны.
Ты не поверишь: почти в любой сфере жизни найдутся индивидуумы, которые "считают иначе". Например, уголовники, которые считают, что соблюдать закон не нужно. Ну и что ты теперь предложишь? Взять за правило, что образ жизни уголовника ничем не хуже, чем у остальных? С их точки зрения он может быть не хуже. Сравнение C и C++ я рассматриваю только с позиции традиционного подхода к вещам. Маргинальные подходы в рамках данной темы меня не интересуют (и, по-моему, я достаточно ясно дал это понять в своих предыдущих сообщениях).
Вундеркинд - это интеллектуально одарённый ребёнок, и именно таким был Гаусс.
Я был бы более категоричен: это мазохизм
Не надо путать язык и подход. В C++ структурное программирование поддерживается практически не хуже, чем в C, и практически теми же самыми средствами. Притом использование таких полезных фич, как пространства имён, шаблоны, перегрузка функций, аргументы по умолчанию и ссылки, вполне неплохо вписывается в рамки структурного программирования.
А здесь в топике вообще-то C и C++ сравниваются, если ты не заметил |
| Автор: MAKCim 5.10.2008, 09:54 | ||||
| nickless, +1 и опять таки "главное, чтобы человек был профессионал в своем деле" UnrealMan, ты точно фанат Добавлено @ 10:00
ты не поверишь, но сравнение некорректно
после этого спор надо прекращать, ибо он бесполезен заставить тебя немного по-другому взглянуть на свои фанатические предубеждения у меня не получится также я бы не был столь категоричным по поводу маргинальности по большей части весь мир opensource придерживается такой позиции в частности Л. Торвальдс, который для меня является авторитетом дабы проверить, насколько маргинален такой подход в рамках форума, создам голосование |
| Автор: nerezus 5.10.2008, 11:10 |
| Проголосовал за посследний вариант, причина: оба фанаты. C в ООП неудобен из-за резкого увеличения количества кода. Т.е. затраты считай в 2 раза увеличиваются. Согласен с nickless: в языках нет ничего общего кроме основ синтаксиса. |
| Автор: UnrealMan 5.10.2008, 12:36 | ||||||||||
Ничего более оригинального, чем выпада в духе "сам дурак", я от тебя не ждал
Внятно объяснить, в чём заключается некорректность, ты не смог, так что я действительно тебе не поверю
Ты уж определился бы: по большей части или весь
Для меня он определённо не является авторитетом. Я бы даже сказал, что для меня он никто. Каких-либо известных исследовательских работ в области проектирования и программирования у него нет (по крайней мере, я таковых не видел). За то, что героическими усилиями он создал сложную работоспособную систему на C, ему, конечно, можно повесить медаль или поставить памятник, но вот считать его высказывания авторитетными я бы не стал. Собственно, в проекте такого масштабного применения, как ОС, компенсировать недостатки программного кода, возникшие как следствие убогости использованного языка программирования, привлечением дополнительных человеческих ресурсов (посредством тупого - в плане, что на это не требуется особых телодвижений - открытия исходного кода) может быть достаточно легко. Однако же далеко не каждый проект может рассчитывать на такую роскошь, как халявные человеческие ресурсы.
Мдя, щас сбежится целый консилиум экспертов (на этом форуме их прямо-таки один через два участника) и выразит своё веское мнение  |
| Автор: nerezus 5.10.2008, 16:11 | ||
|
| Автор: UnrealMan 5.10.2008, 16:51 | ||||||
Покажи хоть одну широко известную работу своих преподавателей. В трудах того же Буча обобщён опыт огромного сообщества программистов и архитекторов программного обеспечения. А что может высказать человек, который варится в собственном соку со своим любимым C? "Как-то раз n-цать лет назад я попробовал попользовать C++ разлива начала 90-х годов, мне не понравилось, так что C++ - это кака"? И все с благоговением должны принимать это к сведению?
Не надо преувеличивать: непосредственными пользователями этого проекта являются далеко не все. В частности, мне он не нужен. И создал он его не в одиночку (про халявные человеческие ресурсы я уже говорил).
Для меня он никто. Рискну предположить, что для многих нелинуксоидов он также никто. |
| Автор: nerezus 5.10.2008, 17:05 | ||||
| UnrealMan, Тот же Таненбаум для тебя авторитет? При этом он ставит ОС Minix как реальную, поливает грязью Linux. Но где Линукс, а где Миникс сейчас?
|
| Автор: UnrealMan 5.10.2008, 17:27 | ||||||||
Честно говоря, с его трудами я не знаком.
На популярность продукта много чего может влиять.
Я говорил о непосредственном использовании.
Может быть, может быть. |
| Автор: nerezus 5.10.2008, 19:06 | ||
|
| Автор: MAKCim 5.10.2008, 19:23 | ||||||||
это не выпада просто меня вдруг осенило
по-моему, это очевидно очевидные вещи я объяснять не буду и мне, кстати, глубоко наплевать, веришь ты мне или нет это было утверждение
я же ясно написал: по большей части что здесь непонятного?
можно перечислить недостатки програмного кода, эксперт ты наш? да, вот еще, вполне себе закрытая ОС Windows тоже на С написана |
| Автор: UnrealMan 5.10.2008, 19:56 | ||
Ну вот, ты не только отвергаешь очевидное, но теперь ещё и выдаёшь за очевидное то, что в действительности не очевидно. Такое неадекватное восприятие тобой реальности опасно смахивает на психическую неполноценность. Поскольку прикалываться над психически неполноценным человеком было бы очень цинично, а другие нескучные занятия в этой теме мне вряд ли сыскать, то, пожалуй, на этом нашу беседу со своей стороны я прекращаю. |
| Автор: J0ker 5.10.2008, 22:25 |
| ну вот апкакали друг друга и разбежались MAKCim, вы идеалист и это не комплимент |
| Автор: kemiisto 5.10.2008, 23:06 | ||||||||
Так, вроде остыл... Ого, сколько тут всего появилось!
Да.
Да, тут Вот я "дал дури". Все верно, просто погорячился. Бывает. В пылу сражения. Смысл прячем за слова, в итоге - спорим не по существу. Мои извинения. С мат. логикой знаком.
Ну, специфика раздела такая. Ничего не поделаешь... |
| Автор: Dims 5.10.2008, 23:22 |
| Господа, не позорьтесь. А то у вас уже дошло, что и Танненбаума вы не знаете, и Торвальдс дурак и Буч со Страуструпом. А кто же умный тогда? Гораздо интересней спор когда какие-то аргументы по сути приводятся, пусть даже спорные или, наоборот, очевидные. |
| Автор: Samotnik 5.10.2008, 23:22 |
| По САБЖу ДА НИЧЕМ JAVA RULLEZZZ |
| Автор: krwlr 5.10.2008, 23:31 | ||
подробнее... |
| Автор: Dims 5.10.2008, 23:32 |
| Я вот, тоже иногда подумываю, как бы придумать что-то такое, чтобы отделаться от ООП. Ведь в ней же есть недостатки. Например, допустим у класса есть метод, который, в качестве параметра, принимает другой метод. По смыслу, этот метод -- это просто функция, которая работает с обоими классами. На каком же тогда основании эта функция считается "членом" первого класса, а не второго? Особенно это видно на примере таких методов как opreator== в Си++ или equals в Джаве. То есть, по логике, должно быть можно создать метод, который является членом сразу нескольких классов. Но это получается ни что иное, как обычная глобальная функция. |
| Автор: Samotnik 5.10.2008, 23:35 |
| - Быстрая - Кроссплотформенная - Легче для понимания - Легкость применения фреймворков - Простая инеграция javascript, css, html (и д.р. ВЕБ компонентов) - Философия "Писать однажды, исполнять везде" - Читать мою подпись |
| Автор: krwlr 5.10.2008, 23:53 | ||||||||
можно я скромно так... БУГАГАГА!!! БУГАГАГА! БУГАГАГА! БУГАГАГА! не могу остановиться... ик... БУГАГАГА! не ну честное слово, это прикол был? оценил!!
... реализация. нормально, сейчас у всех нгормальных интерпретируемо-компилируемых так...
субьективно... есть и полегче... (тоже субьективно)
читать мою подпись) |
| Автор: Samotnik 5.10.2008, 23:55 | ||
ты позже ее написал, чем я |
| Автор: J0ker 6.10.2008, 00:23 | ||||||||
я я умный только я это хорошо скрываю Добавлено @ 00:29
по смыслу - любой метод - это функция
совсем не правда этот метод знает только свой класс через this, а вот метод, который он принимает в качестве параметра он не может вызвать без экземпляра класса которому оный метод принадлежит
а что там видно? ИМХО все просто и логично... |
| Автор: kemiisto 6.10.2008, 00:50 | ||||
А это Вы где такое увидели? Просмотрел весь топик - не нашел.
Сколько раз не перечитивал - так и не понял, что хотел сказать автор... |
| Автор: Dims 6.10.2008, 00:52 | ||
Что за метод в качестве параметра? Речь идёт о методе, который принадлежит к классу А, а его единственный параметр -- к классу Б, вот void A::method(B arg) в ООП метод обязан быть "более родным" классу A, нежели классу B. Иногда это оправдано, а иногда нет. |
| Автор: UnrealMan 6.10.2008, 00:53 | ||||||
К сожалению, пока не нашлось времени прочитать абсолютно всё
Аргументов по сути тут уже приводилось достаточно. Если надо больше, читайте "Дизайн и эволюцию C++" Страуструпа. В данном топике по сути всё свелось к тому, что новшества C++ - это понты для ламерофф, которые настоящим профессионалам не нужны (что подразумевает либо невозможность извлечения такими профессионалами из этих средств какой-либо выгоды, либо отсутствие у них желания эту выгоду извлекать).
Наверное, такие затруднения возникают от недостатка в языке поддержки мультиметодов. В общем-то, самые большие проблемы начинаются тогда, когда требуется произвести виртуальный вызов с учётом динамических типов двух объектов. Моделировать такую ситуацию без языковой поддержки мультиметодов довольно хлопотно. |
| Автор: J0ker 6.10.2008, 01:24 | ||||||
это вы у меня спрашиваете?
а разве методу method более родней класс B??? почему вас тогда не смущает void A::method(int arg)? |
| Автор: Lazin 6.10.2008, 05:36 |
| в ООП, метод method, просто способ послать сообщение объекту А, а объект B - всего-лишь параметр этого сообщения причем там вообще функции? =)) |
| Автор: Lazin 6.10.2008, 08:01 | ||||||||||||||||
смотря с чем сравнивать, к примеру до сабжа не дотягивает
сабж то-же, только некоторые API - библиотеки непереносимы
на самом деле Java мало чем отличается в этом плане, вот руби или пайтон легче для понимания, а Java это та-же статическая типизация что и в С++
лолшто?
бывает и проще
это как-то связано с языком программирования?
читаю
|
| Автор: nerezus 6.10.2008, 08:11 | ||
Первый не обладает этим, второй обладает. |
| Автор: MAKCim 6.10.2008, 08:35 | ||
чего чего? скажем так, оба обладают на уровне исходного кода, но второй в меньшей степени 1. С++ компилятор есть на меньшем числе платформ 2. Интерпретация "стандарта" C++ не одинакова для всех компиляторов 3. Нативный С++ код непереносим даже в рамках одной платформы ps. а Java и вправду рулит простая как дважды-два, но в то же время крайне мощная из-за различных фреймворков |
| Автор: Samotnik 6.10.2008, 12:04 |
| А прогу которая написанная на С/С++ можно установить на пульт от телевизора ? или в меню стиральной машины? или в микроволновку ? А может игру для мобил можно на Сях написать ? |
| Автор: vinter 6.10.2008, 12:15 |
| Samotnik, а почему бы нет? |
| Автор: MAKCim 6.10.2008, 12:22 | ||
конечно главное, чтобы были компиляторы под процессоры этих девайсов |
| Автор: Samotnik 6.10.2008, 12:25 |
| но почему-то это все делается на Java |
| Автор: krwlr 6.10.2008, 12:36 | ||
я почему-то думал что микроконтроллеры на Сях, С++ и Форте программируются... Добавлено через 24 секунды наивная моя душа |
| Автор: Dims 6.10.2008, 12:51 | ||||
Я оговорился. Я просто имел в виду объект другого класса. Добавлено через 2 минуты и 9 секунд
А что смешного? По каким причинам Джава должна быть медленной, если используется JIT? |
| Автор: Samotnik 6.10.2008, 12:58 |
| krwlr, все правильно, микроконтроллеры написанны на Си. Я ж не спорю. Я хочу сказать, что Java самый кроссплотформенный язык в мире, потому как его легче всего встроить в мобилы (Java - игры) и маленькие аппаратики (Печи СВЧ, стиралки). Вот поэтому на нем все и написанно. А попробуй вижуал студио на мобилу поставить |
| Автор: krwlr 6.10.2008, 12:59 | ||
вы тоже приколист? Как там у явы с апстартом? Какие минимальные системные требования?(Прям день приколистов на Винграде  ) |
| Автор: vinter 6.10.2008, 13:01 |
| Samotnik, иди во флейм и не позорься |
| Автор: Lazin 6.10.2008, 13:03 | ||
мдя, 2 года программировал контроллеры, но теперь я в сомнениях, не программировал ли я все это время на java? |
| Автор: krwlr 6.10.2008, 13:04 | ||||||
хых, ну ладно... На твой взгляд Ява - самый ...
|
| Автор: Samotnik 6.10.2008, 13:05 | ||||||
что я не так сказал Обоснуй.
Добавлено через 6 минут и 17 секунд vinter, ты никогда не слышал о Java играх для мобил ? Ну тогда ты не позорься ! |
| Автор: vinter 6.10.2008, 13:29 | ||||||||||
|
| Автор: Lazin 6.10.2008, 13:53 |
Задолбали вы со своей жабой, в этом треде не языки программирования обсуждают а троллят MAKCim-a  |
| Автор: MAKCim 6.10.2008, 14:02 | ||
да-да-да |
| Автор: krwlr 6.10.2008, 14:06 |
| мы типа хотели внести новую струю в этот холодный поток... Лучик света в темное царство.. |
| Автор: vinter 6.10.2008, 14:26 |
| из выше приведенного описания у меня вырисовывается только одна струя, и не надо ее сюда вносить |
| Автор: nerezus 6.10.2008, 14:49 | ||||||||
А как платформа - то нет, C++ в этом плане кроссплатформенней(Qt). Твоя ошибка в том, что ты считаешь J2SE и J2ME одной технологией, что неверно. Однако считаю Java самым легким и лучшим языком с dynamic strong типизацией. |
| Автор: MAKCim 6.10.2008, 15:09 | ||
т. е Qt реализована так, что ее код не зависит от того, каким образом компилятор интерпретирует стандарт? |
| Автор: smartov 6.10.2008, 15:32 |
| Жосский оффтопик... Samotnik, жёлтая карточка устно. Название темы нечитабельным шрифтом написано? Или тебе там Java чудится? (Вопросы риторические, отвечать не надо) Модератор: Давайте вернёмся к теме обсуждения. |
| Автор: J0ker 7.10.2008, 02:42 | ||||||
я тебе по секрету скажу, что есть даже платформы, на которых C нету... вернее были всплакнем о динозаврах?
ну никтож не спорит что C++ моложе C - стандарт уточняется и последние реализации полностью совместимы - boost вполне портируем
ээээ... чаво???? так все-таки - нативный или C++? вы уж определитесь |
| Автор: J0ker 7.10.2008, 03:15 | ||
ifdef'ы никто не отменял |
| Автор: MAKCim 7.10.2008, 08:42 | ||||||||
с 98-го года все уточняется я уж молчу про новый стандарт, он вообще лет 20 будет уточняться, если вообще когда-нибудь уточнится
нативный код, полученный путем применения С++ компилятора к модулю, написанному на С++
т. е есть ifdef-ы для gcc4.* gcc3.*, gcc2.*, icc, sc, ...?
мы говорим про сегодня и коню понятно, что когда-то небыло всего того, что есть сейчас |
| Автор: nerezus 7.10.2008, 09:05 | ||
|
| Автор: nerezus 7.10.2008, 09:58 |
| Кроссплатформенность: Windows/linux/*bsd/WM - т.е. практически все платформы(кроме Symbian, но как раз Nokia купила же Qt, ведется работа). Без переписывания кода. Включает в себя гуй, сеть, бд, хмл... Что может предоставить C? |
| Автор: MAKCim 7.10.2008, 10:29 | ||
аналогичные кроссплатформенные либы разница в том, что они не собраны в единый фреймворк |
| Автор: nerezus 7.10.2008, 10:41 |
| MAKCim, Дай ссылочки на качественные либы для потоков и и сети? Не для спора, а чтобы принять их ввиду и юзать в случае чего. Для сети только SDL Network нашел, но... под WM сомнительно, что заработает. |
| Автор: MAKCim 7.10.2008, 15:21 | ||
ну как бы POSIX threads сеть: cURL, openSSL |
| Автор: nerezus 7.10.2008, 16:32 | ||
А либа для сокетов? |
| Автор: J0ker 7.10.2008, 19:05 | ||||||||
с 2003
детские болезни рано или поздно наиболее эффективные реализации будут стандартизированы С++ все-таки на 11 лет младше C и на порядок сложней в реализации - отсюда и данные на откуп создателей компиляторов некоторые тонкости реализации. Естественный отбор покажет кто прав
я правильно понимаю - вы предлагаете прекратить разработку новых языков только потому, что СЕГОДНЯ они не поддерживаются большинством платформ??????? и должен ли я рассматривать это заявление как "C forever!!!"? Добавлено через 4 минуты и 46 секунд
что-то вы с gcc разошлись разных интерпретаций гораздо меньше (на порядки я думаю ) чем вам бы хотелось |
| Автор: MAKCim 7.10.2008, 19:59 | ||||||
насколько я знаю, есть реализация POSIX threads под Windows
openSSL имеет мощный кроссплатформенный интерфейс BIO, инкапсулирующий работу с сокетами
нет я против разработки языков, для поддержки стандарта которых требуется нетривиальный компилятор |
| Автор: nerezus 7.10.2008, 20:08 | ||
POSIX Threads (pthreads) for Win32:
Хорошо проект поддерживается) |
| Автор: J0ker 8.10.2008, 20:20 | ||
компилятор всегда нетривиальный хотя-бы в силу необходимости оптимизации все несуразности C++ проистекают по большей части от необходимости поддерживать совместимость с C. Та небольшая доля, что приходится на некоторые конструктивные недороботки в конечном итоге будут отработаны - не ошибается лишь тот, кто ничего не делает я опять-таки акцентирую ваше внимание на том, что C++ сочетает в себе такие достоинства как нативность, и присущая ООП масштабируемость и высокий уровень абстракции (фактически любой уровень - от самого низкого - как и plain C, до одного из самых высоких - generic) - такого сочетания не может предложить на сегодняшний день ни один другой язык. |
| Автор: MAKCim 9.10.2008, 08:25 | ||
это и не надо лучше много хороших узкоспециализированных, чем гигант-середнячок в каждой специализации да, с абстракцией у С все в порядке я вот давеча смотрел реализацию интерфейса устройств в ядре Linux и был поражен, насколько С может быть объектен могу ссылки привести |
| Автор: nerezus 9.10.2008, 08:43 | ||
Например разработка прикладнухи и игр. |
| Автор: MAKCim 9.10.2008, 11:35 | ||
я с этим не спорю я лишь отстаиваю свою позицию по сабжу |
| Автор: nerezus 9.10.2008, 11:48 |
| MAKCim, ну в том то и дело, что отстаивая свою позицию, ты задел другую) А сам я его юзал из-за заказов(я во всех областях как бы неглубоко сижу, что позволяет мне работать на любых легких/средних заказах во всех областях). При этом выбирал инструмент, наиболее подходящий. И C++ часто был им. Очень часто(гораздо чаще, чем мне хотелось, ибо ненавижу его). |
| Автор: MAKCim 9.10.2008, 12:02 | ||
каждый выбирает, то, что позволяет ему наиболее эффективно решить задачу мой тезис: в областях, где лидирует C++, можно применять С, причем не менее эффективно все, я никого здесь не задеваю |
| Автор: nerezus 9.10.2008, 12:22 | ||
Т.е. при аналогичном времени эффективность в 2 раза ниже будет. |
| Автор: J0ker 10.10.2008, 17:54 | ||||||
не надо штампами отбиваться вы же не можете программировать на "многих хороших узкоспециализированных" языках - покамест это в принципе невозможно - в лучшем случае интерфейсы между языками отъедают кучу производительности, а в худшем - их (интерфейсов) просто не существует
в порядке конечно но вот уровень до C++ не дотягивает (что и понятно впринципе) Добавлено @ 17:56
этот тезис мы уже обсудили - можно применять даже машинные коды - в конечном итоге все сводится к ним - тогда вообще можно без компилятора обойтись |
