| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > C && C++ |
| Автор: Letchik 1.8.2010, 20:29 |
| Доброго времени суток! Как вы уже догадались, топик посвящается языкам С и С++. Однако, я не буду задавать вопрос "какой язык лучше?". Нет. Не буду кота за я"ца тянуть. Оба языка мне нравятся. Процедурное программирование, т.е. чистый С хорош во многом. Особенно он мне понравился в разработке Windows приложений. Код получается весьма обширным, легко запутаться, но программа получается очень быстрой и маленькой по объёму. Нет ничего лишнего, только то, что мне надо. Реализовать такую простоту средствами ООП у меня не получилось. Может руки не с того места растут? Может быть... У меня мало опыта. Но зачем мне огромная куча объектов типа (к примеру) СButton? Каждая кнопка выполняет определённое действие, значит надо создавать множество классов наследников с виртуальными процедурами обработки. То же самое касается других элементов интерфейса. Согласитесь, это лишнее. Однако, есть области программирования, где без ООП не обойтись. В таких случаях писать код на чистом С будет очень затратно и логических ошибок не избежать. Так как же? Совмещать оба языка? К примеру писать интерфейс программы на С, а суть программы писать, по необходимости, на С++. Приемлемо ли это? Или нужно выбрать конкретный язык? Вопрос странный, понимаю, но тем не менее, помогите, пожалуйста, разобраться в этом очень нелёгком вопросе. P.S. я большой противник всяких там MFC, VCL, Qt и тому подобное. Мне кажется, они лишают нас всего кайфа программирования. |
| Автор: kemiisto 1.8.2010, 20:41 | ||||||
Оно и понятно. Не в обиду.
Первое, о чём стоит заботиться - простой и ясный как день код. Программа не должна быть очень быстрой, она должна быть достаточно быстрой. Достаточно, чтоб не вызывать дискомфорта у конечного пользователя.
Множеста классов не надо создавать. Объект = данные + код. Все кнопки - экземпляры одного класса СButton, а код обработчика какого-либо события у них может быть разным.
Писать интерфейс на С/С++ - почти всегда использование не по назначению. |
| Автор: Abyx 1.8.2010, 20:59 | ||
только в случае если интерфейс будет вызывать код на другом языке |
| Автор: cutwater 1.8.2010, 22:09 | ||
А что же Вы предлагаете? Я конечно понимаю юношеский максимализм, но когда/если дорастете до проектов крупных и за которые платят деньги, поймете что основная цель - решить поставленную задачу в приемлимые сроки. За кайф от программирования заказчики не платят. Но даже если смотреть на этот вопрос не с точки зрения затрат времени. Я не думаю что разработчику, которому нужно нарисовать интервейс будет в кайф реализовывать мегатонны велосипедов, архитектурный дизайн и прочие возможности, которые предоставляют фреймворки уровня Qt. Поверье есть задачи намного более сложные, чем натыкивание кнопочек на форму, которые решают и на уровне выше графической библиотеки, то есть различные извращения с интерфейсом, оптимизация под конкретные задачи и прочее. Сложный интерфейс сделать ведь тоже не легко. А так же задачи, решаемые на уровне ниже графического интерфейса, в ядре приложения. А переписывать каждый раз избитые велосипеды снова и снова это не кайф, а ненужная трата времени. Плюс тонны ошибок в этих велосипедах, которые так же нужно покрывать и отлаживать. Думаю/надеюсь с опытом это пройдет. |
| Автор: bsa 1.8.2010, 22:28 |
| Ты заблуждаешься. Кайф программирования заключается в том, что ты делаешь что-то новое и полезное, познаешь что-то новое. Клепать "окошки" и расставлять кнопочки это вообще работа дизайнера. |
| Автор: Letchik 1.8.2010, 22:48 |
| cutwater, согласен, в программировании интерфейса мало чего интересного. Там мало интересных инженерных решений. Это просто рутинная работа, которую, если честно, я всегда не любил. Всегда было желание ускорить этот процесс и перейти к части, где нужно подумать и найти интересное решение проблемы. Пожалуй, я неправильно выразился и проблема с написанием интерфейса заключается в другом. Я провёл небольшой опыт. Написал две абсолютно идентичныео по функциональности программы: обе тупо создают пустое белое окно. Первая программа была написана с помощью MFC, другая на чистом С. Разница меня не порадовала. Окно написанное на MFC занимало в оперативной памяти на 1мб больше чем окно, написанное на С. И это всего лишь одно простое окошко. Что говорить о серьёзном приложении? Но судя по вашим отзывам, вы за то, чтобы программировать только на С++. Я правильно понимаю? |
| Автор: kemiisto 1.8.2010, 22:55 | ||||
Боже, нет! Ну не надо С++! 2010 год на дворе, всё, хватит... |
| Автор: bsa 1.8.2010, 23:21 |
| Предлагай людям альтернативные языки менее эмоционально. Все-таки, мы в разделе С++. Letchik, как ты думаешь, почему тот же Qt цветет и пахнет? А я тебе скажу, что 1 мегабайт роли не играет. Так как это константная плата за удобство. При большем расширении функционала объем занимаемой памяти будет не так сильно расти. |
| Автор: Modul 1.8.2010, 23:29 | ||
ООП-языки придуманы из-за увеличиваюшихся размеров и сложности программ, а потом и их расширения.
Особого смысла не вижу, если только клиент не требует. Везде работать надо. Желание клиента - закон ! Он платит. Интересен Ваш выбор ? С#, Java или ??? |
| Автор: kemiisto 2.8.2010, 08:37 | ||||
Не совсем так. Изначально ООП появилось как средство симуляции в Simula-I. В этом языке были activity (классы) и process (объекты). В Simula-67 уже повилось слово class. Ole-Johan Dahl и Kristen Nygaard опирались среди прочего и на работу C. A. R. Hoare , http://portal.acm.org/citation.cfm?id=1061041&dl=GUIDE&coll=GUIDE&CFID=80486137&CFTOKEN=39275062. Потом был Alan Kay со товарищи и Smalltalk. ООП - как средство построения графического интерфейса. Но в итоге опыт обобщили до любых сложных задач. В итоге посыла было два:
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html C# - можно, вместо Java лучше Scala. Ещё можно попробовать динамические ЯП. Тот же Python. Есть наблюдение, что любителям C нравится Python. Smalltalk тоже можно. Да много языков... |
| Автор: mrbrooks 2.8.2010, 08:40 | ||
ооо. прогресс. раньше помнится был только Оберон |
| Автор: azesmcar 2.8.2010, 08:43 | ||
Знаешь в чем кайф программирования? Написал программу, сдал, получил деньги и кайфуешь А сидеть пару месяцев над простейшей программой, только потому, что тебе "не в кайф" учить Qt или .NET, а хочется поработать на WinAPI и сотворить пару сотен велосипедов - это уже патология. |
| Автор: Earnest 2.8.2010, 11:04 |
Ну, не надо так категорично. Для новичка это нормально и даже полезно. И кайф есть - сделать самому всякие красивости, и заодно понять как оно работает. Но через некоторое время должно надоесть, или просто станет жаль время тратить (а на кнопочки его много уходит, если приходится нестандартный велосипед изобретать). Если, конечно, не работаешь в команде, которая на таких библиотеках специализируется. |
| Автор: GrayCardinal 2.8.2010, 11:29 |
| Ха. Если программу можно написать на чистом Си - лучше так и сделать. Если придет понимание того, что без классов не обойтись - дописываем нужные классы. То же с ассемблером. Ежели очень хочется - то можно. И почему некоторые пишут на чистом Си++ (всё есть классы) лично я не догоняю. |
| Автор: HellStranger 2.8.2010, 12:10 | ||
Абсолютно согласен! Я уже приводил минимум 5 проектов, написанных на чистейшем C (в некоторых применяется ООП, но реализация всех классов на том же старом добром C), широко и не очень применяемых под разными осями. То есть, люди хорошо знающие C, прекрасно обходятся без всех довольно спорных прелестей C++, а главное в практически такие же сроки, как, если бы задача решалась на cpp. Плюс, многие здесь говорят, что программа не должна быть очень быстрой, а должна быть довольно быстрой... Знаете, товарищи, воообще-то для серверного ПО скорость очень критична, как и затраты ресурсов. И здесь cpp до C как до Киева в одной позе... Приведу простой пример: компания контент-провайдер, в которой я работаю, разработала и использует 2 плоатформы: 3G_Video_IVR (работал в Германии) и платформа для sms. Первая- вся начинка сишная, вторая- cpp. Так вот 3G_Video_IVR держал 10 видео абонентов на Pentium 4 3.4 GHz с гигом оперативки под XP и грузил проц на 25-30% максимум, вторая по 5 раз на дню вылетает при более-менее нормальной нагрузке: 100-1000 sms. Я думаю, не нужно здесь доказывать, что обработка online-видео c перекодированием на лету и работа со строками длиной до 150 символов- разной сложности задачи. Возьмём ту же асму. Если человек хорошо знает архитектуру процессора, систему команд и операционку, под которую пишет, то серверное приложение будет разработано в те же сроки, что и приложение на cpp (всё-равно использовать API системы и там и там). Только вот кому будет нужен cppшный сервак, когда есть асмовский... А мораль сей басни такова: нужно быть профессионалом в том, чем ты занимаешься, и тогда границы между asm, C, C++, C# и т.д. и т.п. становятся очень размытыми... В идеале, современный программист должен знать всё, и выбирать язык и технологии в зависимости от задачи. А меряться: писька у cpp длиннее всех, а C и asm- прошлый век, это очень не умно. |
| Автор: Modul 2.8.2010, 12:25 | ||||||
Вот. И теперь мы решаем сложные и еще более сложные задачи. Мы же говорим про настоящий момент и немного на перспективу ! Кроме того есть теоретики и практики. Есть и определенные критерии (показатели) оценки эффективности. Например скорость разработки, спрос, зарплата. А смысл изучать что-то хорошее, но мало востребованное. Нонсенс ! Да еще важна специализация работника - к чему он тяготеет.
Все хорошее уже изобретено. ...и человек займется наконец своей работой !
Тоже верно. Смысл писать 1 функцию и для нее класс, потом еще создать объект и его удалить. Написал DLL, загрузил сишным методом и дело сделано. Отсюда вывод: Зачем из пушки по воробьям стрелять. Незачем ! Другое дело - большой класс, например парсер с 10 функциями. Здесь без ООП просто не обойтись. Можно здание строить из кирпичиков и из глины, долго месить и построить через 3 года. А можно из блоков (классов-объектов) или из панелей (готовые классы). Результат - полгода. Зарплата та же. p.s. Философия ООП |
| Автор: Abyx 2.8.2010, 12:26 | ||
потому что код должен быть повторно используемым, масштабируемым, удобным для рефакторинга, etc |
| Автор: Modul 2.8.2010, 12:35 | ||
и потом еще можно свое творение (класс) снабдить описанием и толкнуть на рынке. Чем не повторное использование, только на рынке. Еще на этой основе встречаются библиотеки - довел до ума - покупай ! |
| Автор: HellStranger 2.8.2010, 12:37 | ||
Загнал в тупик... Как тогда тысячи программеров с FFMPEG разбираются?.. Как новые программеры сего проекта продолжают его дальнейшую разработку?.. У меня на освоение принципов работы с FFMPEG ушла неделя наряду с текущей загруженностью. Ещё через месяц у меня уже был готов простенький видео-редактор, абсолютно с нуля. Live555 меня поверг в уныние через 10 минут просмотра исходного кода... Так что, как говорил Альберт наш Эйнштейн, всё относительно. |
| Автор: kemiisto 2.8.2010, 12:53 | ||||
Это доказывает лишь то, что С++ - плохой язык программирования. Плохой во всех смыслах.
Ты очень остроумный. Но, тут разговор о десктопе. Так что уж слишком толсто получилось. Незачёт. Я что-то ничего из этого примера не подчерпнул. Часть про asm совсем не к месту. Поток сознания. |
| Автор: Abyx 2.8.2010, 13:07 | ||
чушь это. если надо только вызывать апи, то код асма 1в1 совпадает с Си. это факт. если нужна арифметика, в т.ч. обычная арифметика указателей, то асм сливает. количество строк кода отличается на порядки. но было асм vs Си. теперь асм vs C++. на асме вы пишете набор функций. на С++ вы пишете шаблоны функций. т.е. не одну функцию, а сразу семейство функций. используя шаблоны можно настраивать программу, меняя код только в необходимых местах, а не весь сразу. алсо да. и на С++ и на асме надо еще уметь программировать. |
| Автор: HellStranger 2.8.2010, 14:48 | ||||||
Что-то я в названии темы не увидел, что речь идёт ИСКЛЮЧИТЕЛЬНО о desctop, примеры были приведены десктопные, имхо, только потому что автор пока ими и занимался. Так что расписываться в моей зачётке не надо, без вас профессура уже давным-давно справилась.
А у меня нет самоцели, чтобы лично вы что-то поняли. Между делом, в теме упоминались ещё и C#, и Java и ещё много других языков... Тоже не в тему, а в качестве примеров. Добавлено через 4 минуты и 16 секунд
Знаете, в кривых руках и машинный код чистому C сливает. Я не говорю сейчас о горе-хаккерах, которые изучили систему команд x86 на уровне младших курсов МФТИ и мнят себя мегамозгами в asm. Их код может и cpp слить, что дальше?.. cpp всех круче?.. |
| Автор: ncr 2.8.2010, 14:56 | ||||
У вас в корне неправильный подход. Код должен быть максимально понятным, прозрачным и компактным. Вам же с ним ещё работать, и все эти "легко запутаться" в итоге выльются в бессоные ночи, нервные срывы, красноглазие и прочие страшные слова. А какого размера получится скомпилированный модуль - 10 Кб или 3 Мб, сколько он памяти будет потреблять - 1 Мб или 50 Мб, и за сколько он у вас выполнит требуемое действие - за 10 микросекунд или за тысячу - НИКОГО не волнует.
Все такими были когда-то Со временем приходит понимание, что настоящий кайф программирования - это свободное от программирования время, которое можно посвятить куда более приятным вещам. А готовые общепринятые решения весьма ускоряют разработку и, что важно, позволяют сконцентрироваться непосредственно на сути программы, а не тратить время на стопицотое изобретение одних и тех же вспомогательных велосипедов. |
| Автор: HellStranger 2.8.2010, 14:57 | ||||
Правда компилятор превращает ваше семейство в такой же набор функций. Добавлено через 3 минуты и 30 секунд
Специально для вас был создан .NET Framework. Сколько клиентов за эти 10 микросекунд: 10 или 10000 сможет обслужить сервер тоже никого не волнует?.. Вы перегрелись на солнышке, уважаемый... |
| Автор: mes 2.8.2010, 15:16 | ||
и сколько можно эту гадость пиарить ? к тому же еще только виндоус ориентированную.. HellStranger, приведите обоснование тому факту, который Вы не раз озвучивали, о том, что С++ сливает Си.. |
| Автор: ncr 2.8.2010, 15:19 | ||
Объясню для непонятливых. Топикстартер хочет писать интерфейс на "чистом С". Написанное мной следует понимать в этом контексте. "Интерфейс" не обслуживает 10000 клиентов за 10 микросекунд. Поэтому за сколько именно микросекунд обновится, например, надпись на кнопке - никого не волнует. То, что при циклических интенсивных операциях скорость важна - и коню понятно. |
| Автор: HellStranger 2.8.2010, 15:39 | ||||
А кто её пиарит-то?.. По-моему, вы определённо перегрелись... )))))))))))) Я вовсе никого не склоняю к её использованию, а просто привожу пример хрени, в которой есть всё на все случаи жизни: для построение клиентских приложений да ещё и для тех, кого производительность ни в каком виде не трогает- просто находка!
На эту тему можно нагуглить тонны статей как в пользу C, так и в обратную... Сторонников cpp не убедит ничего из доводов сишников, как и наоборот. А переливать из пустого в порожнее мне уже порядком надоело... Вам станет намного легче, если я выложу пару тройку ссылок на статьи, где говорится как и в чём cpp сливает?.. Уверен на стопятьсот процентов, что подтянутся местные воротилы cpp, и продолжится война C-cpp. Данахононадо. |
| Автор: bsa 2.8.2010, 15:53 | ||
Я прекрасно знаю Си (очень на это надеюсь). Но при этом я не готов утверждать, что на Си напишу программу сложнее hello world за время, незначительно уступающее оному на C++. Все-таки, есть вещи, которые удобней и, я уверен, быстрей работают на С++, чем на Си. Например, строки. когда тебе надо сравнить две строки, strcmp будет перебирать все символы, пока не встретятся различия, а std::string может (при желании его разработчиков, конечно) для начала просто сравнить размеры строк - это операция с константной сложностью, в отличие, от strlen. Сортировка с помощью std::sort работает быстрей, чем через qsort. Думаю, список можно продолжать. Конечно, это все достигается за счет увеличения размера программы. Но кому надо, тот добавит ключик -O1 компилятору... И вообще, ты хоть сам С++ знаешь? Или критикуешь его по типу: "не читал, но осуждаю"? |
| Автор: mes 2.8.2010, 15:55 | ||||
Почему приводить то крайности ? тем более что требует она специфических языков.. почему бы не привести пример хорошей библиотеки ? хотя бы той самой Qt..
тогда и не надо постоянно употреблять, что С++ сливает С.. и объективный факт, в общем случае, машина оптимизирует средне-лучше чем человек.. Т.е. если даже на паре десятков строчек программист и выйграет, то при увеличении объема сливает.. |
| Автор: HellStranger 2.8.2010, 17:21 | ||||||
Вообще-то при сравнении строк сравнивать первым делом их длину как-то не очень умно, "abcdefghij" < "cdefghij", причём длина?.. Да и немного настораживает уверенность по поводу реализации различных алгоритмов в стандартных бибилиотеках разных производителей... Попахивает ОБС (Одна Баба Сказала). Что касается сравнения строк, тоя уже писал, что strcmp убивает string::compare в десятки раз... qsort- сильно зависит от того, что сортируем, все возмножные варианты не перебрать, но специалдьно для тебя проведу пару тестов и отпишусь. Добавлено @ 17:25 Ясно... Человек, который знает всё- глупец, не спорь с ним... Извиняюсь, что пронёс полную ахинею по поводу C... Ты во всём абсолютно прав! Я беру трубку и идут курить в корридоре... Добавлено @ 17:26
О чём здесь говорил, знаю и использовал неоднократно! "Прекрасно" C++ не знаю и никогда не узнаю. Во-первых, это невозможно, во-вторых, у меня другие интересы в программировании. Добавлено через 9 минут и 19 секунд
Хотя бы просто потому, что "хорошая библиотека Qt"- это очень спорный вопрос. Кому-то нравится, кому-то совсем наоборот. Можно привести и wx, но и здесь всё очень спорно. А по поводу .NET я ни слова не сказал, что это "хорошая" технология! |
| Автор: Abyx 2.8.2010, 18:12 |
| HellStranger, давайте соревнование замутим? реализуем какой-нить простенький алгоритмик типа вычисления множества мандельброта, вы на Сях или чем хотите, и я на С++ или чем захочу?) потом сравним производительность и LOC (объем кода) |
| Автор: HellStranger 2.8.2010, 18:26 | ||
Хоть я и обещал не отвечать на ваши посты, но так уж и быть... Только в свободное от проектов время, а это будет не раньше сентября. Так как за соревнования заказчик, к сожалению, не платит. А работа дороже... Так как неоднократно поднимался вопрос о стандартной библиотеке C и stl. Предлагаю на этом и сконцентрировавть внимание. Всевозможные сравнения строк, поиски подстрок и т.д. и т.п. Сортировки наборов различных структур данных, ну и что ещё в голову взбредёт. Реализовывать рекурсивные алгоритмы, да, если ещё с отрисовкой- это больше смахивает на "у меня длиннее", а не на сравнение языков. Продолжая тему, могу вам предложить реализовать простенький видеоредактор с базовым функционалом: я буду использовать сишный FFMPEG, а вы- что найдёте из cpp. Так что: базовые алгоритмы CRT и аналоги из STL. На паре-тройке компиляторов. Смогу начать уже сказал когда. До этого момента я даже сортировку пузырьком писать не буду... |
| Автор: mes 2.8.2010, 20:34 |
слово "хорошая" было поставлено в противовес выделенному а Qt привел в пример не потому то, она такая хорошая, а потому, что в отличие от .Net свободная в том плане, что 1. хотя и требует тоже специфических особенностей, но позволяет пользовать обычный (не специфический) компилятор 2. доступна значительно более, чем на одной платформе 3. необъективно: приятна и логична в освоении.. |
| Автор: MAKCim 2.8.2010, 21:14 |
| по поводу С vs. C++ на самом деле С вполнее может быть не быстрее С++, все зависит от того, какие средства С++ используются и как они реализованы для конкретной процессорной архитектуры если использовать С++ просто как "С с классами", то там нет практически ничего, что может затормозить процесс выполнения другой вопрос, что С++ объективно нагружен, сложен и костылеобразен, имеет абстрактный стандарт, который в реальной жизни не выполняет свою функцию...поэтому многие выбирают С: простой и понятный я уже много раз повторял, что парадигма программирования и конкретный язык - это разные вещи значительно упрощать себе жизнь на С помогает и ООП как _подход_ и _огромное_ множество (не сравнимое с С++) библиотек (кстати, из-за специфических возможностей С++ типа перегрузки) да и вообще, здравый смысл и логика позволяют любой инструмент использовать грамотно и с наименьшими трудозатратами HellStranger во многом прав, в частности в том, что голова и профессионализм в определенной области все-таки важнее конкретного инструмента |
| Автор: djamshud 2.8.2010, 22:10 |
| В топку видеоредакторы, это весьма скучно и рутинно, к тому же решения будут базироваться на сторонних библиотеках - в итоге просто сравниваются библитотечные пиписьки. Предлагаю наколбасить по парсеру. Используем стандартные библиотеки (C99 - libc, C++03 - libc и libstdc++), всяким генераторам - нет. О входном языке можно договориться, о модулях (собсно парсер, оптимизатор, генератор кода/интерпретатор) - тоже; при подведении итогов сравниваются объем кода (меньше - лучше), его простота (проще - лучше), простота внесения новых языковых конструкций и прочих фич (к модулям, если будет что-то кроме парсера) (проще - заeбатее), производительность (скорость, память), что-нибудь еще? Заведомо субъективные оценки выносим на голосование. |
| Автор: MAKCim 2.8.2010, 22:18 |
| djamshud, идея "соревнований" обречена на нереализацию ;) проверено практикой |
| Автор: HellStranger 2.8.2010, 22:40 | ||||||
Естественно! Почему я приводил в пример PWLib, OPAL и старенький уже OpenH323. С++ используется просто как язык, поддерживающий ООП... ну и операторы переопределяются многие. Разработана вполне понятная, логичная архитектура классов, вся реализация которой- чистый C.
Да вопрос даже скорее не в том, какой язык быстрее, в конце-концов это действительно зависит от многих факторов. Просто реально хочется проверть настолько ли хорошо stl, как его малюют. По крайней мере в работе со строками реально от отдыхает по сравнению с библиотекой C. Реализовывать круптые поделухи, я думаю, ни у кого особого желания нет, по крайней мере у меня и времени нет. А что-нибудь простенькое для сравнения CRT и stl- я только за. Пусть и другие заинтересованные лица подпрягаются. Обсудим, что будем сравнивать и как. Добавлено @ 22:44
Прошу обратить внимание, что библиотечные пиписьки я указывал сишные и пипишные. Как нельзя лучше отвечает предмету нашего соревнования. ) Это во-первых. Во-вторых, когда сварганишь редактор и пережмёшь им пару сотен фильмов, поизголяешься над звуковыми пакетами в .mov и профилях H264 и AAC, тогда и скажешь, что скучно и рутинно. По-моему, очень интересная область программирования. В-третьих, неужели у программистов есть время на то, чтобы реально меряться письками?.. Наряду с рабочими проектами можно найти море сторонних проектов, чтобы на маслице и икорочку к хлебу заработать... когда здесь меряться?.. |
| Автор: boostcoder 2.8.2010, 22:46 | ||||
учится, учится, еще раз учится (с) дядя ленин. через попу. т.к. написано огромное кол-во оберток на с++, потому как с интерфейсами на Си работать можно как написано выше.. Добавлено через 1 минуту и 36 секунд естественно. когда ядра начнут писать на с++, тогда Си стал бы оберткой. Добавлено через 4 минуты и 18 секунд
наследуемся от std::string, добавляем свойство - _хеш_сумму_, и вуаля! сравнение за один машинный такт! это же очевидно Добавлено через 6 минут и 25 секунд вы столько времени тратите на флуд, что можно было уже довольно крупный тест наваять. по крайней мере на С++, за, к примеру, час |
| Автор: HellStranger 2.8.2010, 22:57 | ||
Нет, через вполне понятные исходники и комменты к ним, а вот cpp-обёртки- это как раз и есть попа для тех, кому лень учиться, учиться и учиться языку C. |
| Автор: boostcoder 2.8.2010, 23:01 | ||
это чё?
т.е. вы хотите сказать, что выучить Си сложнее? |
| Автор: HellStranger 2.8.2010, 23:02 | ||
Ага, в 12 ночи сел ваять. ;) И это я флудер... |
| Автор: bsa 3.8.2010, 00:41 | ||||||
Если быть точным - в пять:
|
| Автор: borisbn 3.8.2010, 07:36 |
| Если ваша программа (данные+функции) написана на Си и вам понадобилось внедрить ваш код в многопоточное приложение, то у вас начнутся проблемы (не нерешаемые, но всё же ...) Если ваша программа написана на Си++ и вам надо перевести её на Си (для использования в каком-нибудь контроллере, например), то у вас тоже будут проблемы. Вывод: edem das zaine (пардон за мой немецкий) И ещё: если нужно написать программу с одной кнопкой, выводящей по нажатии на неё Хело Ворлд, то без использования визардов на Си уйдёт пару часов, на MFC - минут 20-30, на VCL или Qt - 2-3 минуты. Выводы делай сам |
| Автор: Abyx 3.8.2010, 08:12 | ||
множественное наследование и dynamic_cast на Си покажите |
| Автор: bsa 3.8.2010, 09:44 |
встроенных нет. но самому организовать тебе никто не запрещает |
| Автор: Abyx 3.8.2010, 10:26 |
| bsa, я думаю вы понимаете, что это *много строк кода* вернее *ОЧЕНЬ МНОГО СТРОК КОДА* мой опыт работы с COM из асма показал что лучше использовать как минимум С++ и ATL |
| Автор: djamshud 3.8.2010, 11:00 |
| HellStranger, тогда к чему вообще написание каких-то редакторов? Ищи по софтине с (примерно) аналогичным функционалом на разных языках и сравнивай. Можно найти кучу примеров как в пользу сишных поделок, так и плюсовых - в конечном счете все упирается в криворукость ваятелей каждого конкретного решения. Плюсы дают такой же простор для творчества и маневра, что и си, но предлагают больше слов для выражения своих идей, и, если ты путаешься в этих словах - ССЗБ, пиши на более простом си и трать на разработку больше времени, в противном случае получай как минимум тот же результат (хотя на деле результат скорее всего окажется более расширяемым и масштабируемым - но тут опять все зависит от криворукости) за умеренные сроки. boostcoder, >наследуемся от std::string, добавляем свойство - _хеш_сумму_, и вуаля! сравнение за один машинный такт! это же очевидно Че, серьезно? Показывайте пример сей чудной перделки или признавайтесь, что ляпнули глупость. |
| Автор: boostcoder 3.8.2010, 11:09 | ||
а что тут несерьезного? сложность в чем? точнее, в чем именно? |
| Автор: djamshud 3.8.2010, 11:13 |
| boostcoder, пример, пожалуйста. А там посмотрим, что за проблемы. Сколько уже можно теоретизировать?:) |
| Автор: bsa 3.8.2010, 11:14 |
В том, что методы сравнения у std::string как минимум не виртуальные. Т.е. наследованием ты тут не обойдешься - придется делать агрегацию и перенаписание всех методов заново. А потом, когда ты собрался считать хэш? на этапе присваивания/изменения значения? А ты не думал, что может оказаться такая ситуация, в которой есть куча смен значений и ни одного сравнивания? Кстати, хэш тебе не заменит compare. |
| Автор: djamshud 3.8.2010, 11:17 |
| Ну и ладно, теория тоже хорошо в конце концов. 1. Коллизии (потенциальные!). Что с ними делать? 2. Есть ли хеш-функции, гарантирующие, что хеш любой "меньшей" строки будет меньше хеша данной строки? Сомневаюсь. |
| Автор: boostcoder 3.8.2010, 11:28 | ||||||
потестить тут: http://liveworkspace.org/code/be1ad8c6bdca72b5c15e8dd2119deb17
нет, я конечно подумал об этом. но раз HellStranger`а беспокоит производительность, значит ему нужно сравнивать не 5 строк. но если строк много, тысячи..сотни тысяч, то рассчитывать хешь нужно в момент "собирания" такого кол-ва строк. т.к. сложно представить источник, способный формировать, к примеру, мильён строк за 20мс. смотря что ожидается от compare. Добавлено через 1 минуту и 23 секунды
я так понял, разговор про operator==() и != Добавлено через 5 минут и 2 секунды кстати, еще один тест: http://liveworkspace.org/code/6b5720fc21470c457b8e099875da53d1 как видно из результата, сравнение стандартной строки, происходит в 6-7 раз дольше. профайлер говорит что все тормоза из-за функции(метода) __builtin_memcmp(). но я ее не нашел. Добавлено через 5 минут и 48 секунд зы алгоритм подсчета хеш суммы, взят из википедии. |
| Автор: HellStranger 3.8.2010, 11:41 |
Если быть совсем точным, то зависит от компилятора и процессора, но суть Тела не меняет, правда ведь?.. Операторы сравнения: в C аналогов нету, смысл сравнивать?.. Или будем сравнивать указатели? Что касается qsort, то результат вас тоже не сильно обрадует... Хотя, сильно зависит от того, что сортировать... Предлагаю! Всем заинтересованным в тесте людям, модераторам тоже! Реально заняться сравнением прелестей CRT и stl. Выработать ощий план: что сравниваем, как сравниваем, на чём сравниваем. Прок от этого, думаю, в любом случае будет: кто-то начнёт больше юзать CRT, а кто-то, возможно, обратит внимание на stl... |
| Автор: djamshud 3.8.2010, 11:41 |
| >я так понял, разговор про operator==() и != С ними весьма хорошо справляются и обычные сравнения длин + memcmp. Для сортировок нужно проверять на больше/меньше. И таки что с коллизиями делять? (это когда у двух разных строк хеш-суммы совпадают (потенциально это может быть у любой пары строк)). Добавлено через 4 минуты и 44 секунды Я как бы намекаю, что сравнение строк по их хешу очень эффективно, когда идет речь о !=, а == - это сравнение хешей плюс сравнение самих строк. |
| Автор: boostcoder 3.8.2010, 11:47 | ||||||
мой вариант быстрее. но при условии, что сравнивать нужно большое кол-во строк, т.к. есть куча времени которое можно использовать для расчета хеш.
я не волшебник. я лишь привел пример одной из типичных ситуаций. хотя, по поводу коллизий, полагаю, есть решение. нужно гуглить. Добавлено через 1 минуту и 45 секунд
вариант |
| Автор: djamshud 3.8.2010, 11:52 |
| boostcoder, так вы признаете, что ваша реплика об однотактовом сравнении имеет смысл только для операции !=, а все остальные - ==, >, <, >=, <= - будут тупить и особого смысла применять к ним хеширование (внутри реализации класса "строка") нет? Или будете гуглить волшебные хеш-функции?:) |
| Автор: HellStranger 3.8.2010, 11:52 | ||
Да и между нами девочками, нехилые такие строки получаются... В C просто набор байт и ничего лишнего... А здесь уже нагородили хэш-таблицы, помимо своих охренительных прелестей std::string... А мне надо тупо сравнить "Вася Пупкин" с "Маша Залупкина"! Сейчас мы вооружимся ядерной боеголовкой производства boostcoder и Ёпнем по мухе! Добавлено через 3 минуты и 44 секунды А их нет и не может быть... Все алгоритмы подвержены коллизиям. Если мощность множества объектов, от которых будет вычисляться хэш больше мощности множества значений хэш-функции, а в нашем примере это так; то коллизии в любом случае есть и будут. Спорить собственно не о чем! |
| Автор: boostcoder 3.8.2010, 11:57 | ||
да буду. любопытно ничего не городил. стандартная таблица. т.е. для сравнения двух строк, вас мегабесспокоит затрачиваемое время? |
| Автор: djamshud 3.8.2010, 12:04 |
| boostcoder, >буду. любопытно Их нет. Можно нагородить тысячу костылей для адаптации хеш-суммы, если такая уже была однажды сгенерирована, но все эти проверки будут занимать уйму времени и памяти (ведь все нужно централизованно хранить, следить за созданием, изменением, удалением строк), а в конечном счете все равно рискуете упреться в потолок, когда весь спектр хеш-сумм будет задействован. |
| Автор: boostcoder 3.8.2010, 12:04 |
| а какая вероятность коллизий, кто-то может сказать? чувствую, что получится так, что она почти невероятна |
| Автор: djamshud 3.8.2010, 12:04 |
| HellStranger, это была ирония. Почему никто этого не понял?.. :) Добавлено через 3 минуты и 47 секунд boostcoder, она маловероятна для десяти строк. Но вот же будет обидно, когда чудо-программа возьмет, да перепутает Васю с Маней. Какой бы малой эта вероятность ни была ее никак нельзя игнорировать. |
| Автор: bsa 3.8.2010, 12:34 |
| Вообще-то, операции != и == имеют абсолютно одинаковую сложность. Так как != это инвертированный вариант ==. Т.е. если ты зафиксировал, что условие a != b не выполняется, то можно со 100% точностью сказать, что выполняется a == b. В нашем же случае, когда два хэша равны, это не значит что две строки равны. Это значит, что надо сравнить сами строки. И не важно для какого оператора - == или !=. |
| Автор: HellStranger 3.8.2010, 12:40 |
| Ребят, хорош хрень нести. Люди вроде все взрослые, что толку переливать из пустого в порожнее? Если нечего делать, лучше людям на форуме помочь... |
| Автор: djamshud 3.8.2010, 13:06 |
| bsa, да, у меня мысля за мыслю зашла. |
| Автор: mes 3.8.2010, 13:34 | ||
зато если хэши не равны, то однозначно не равны.. хотя в любом случае не аргумент.. К тому же хэш не является частью строки, а лишь может образовать с ней пару и если нужны вдруг какие то операции с хэшом, то они возможны не зависимо от языка программирования.. а вот например как выглядит на С реализация автоматизации по технологии CopyOnWrite ? или RAII ? |
| Автор: bsa 3.8.2010, 16:46 | ||
Посмотри OpenSSL Имхо, это нереально. |
| Автор: MAKCim 3.8.2010, 20:56 | ||
какие? Добавлено через 5 минут и 6 секунд не надобно из-за отсутствия исключений ;) |
| Автор: Abyx 3.8.2010, 21:19 |
| MAKCim, в Си могут быть исключения. в винде например есть SEH\VEH + RaiseException() |
| Автор: MAKCim 3.8.2010, 21:29 |
| Abyx, это не связано с языком как таковым |
| Автор: borisbn 4.8.2010, 06:49 |
| MAKCim, когда функции используют глобальные статические переменные и их потребовалось использовать в нескольких потоках - это проблема. У меня были случаи, когда dll-ки, написанные подобным образом на Си нужно было переименовывать в рантайме и загружать её копию в каждом потоке. Конечно и на Си++ можно так писать, но процедурное программирование к этому больше располагает, чем классы |
| Автор: Abyx 4.8.2010, 08:10 | ||
вы уверены что это нормальный способ? если длл - ваши, то более тупого решения не придумать %) для таких вещей есть TLS |
| Автор: borisbn 4.8.2010, 11:07 |
Естественно, Вы тут самый умный, а все вокруг - полные идиоты. Длл-ки были не мои. Предложи более правильный способ. |
| Автор: HellStranger 4.8.2010, 11:29 | ||||||||
Знаете, по-моему это проблема называется- недостаточно хорошее продумывание архитектуры приложения. И, если C по-вашему виноват в том, что не предоставляет инструментария по вырыванию рук криворуким программистам, то уж извините... Не для этого он разрабатывался...
А вот этов чистом виде ОБС (Одна Баба Сказала). Так можно писать и на C#, и на Java и т.д. и т.п. Классы не заменят мозгов!
Я, конечно, далёк от вашей проблемы, но решение выбрано и в самом деле брутальное... Сродни разработчикам вашей пресловутой dll... Добавлено через 4 минуты и 36 секунд
Только не все даже виндовые компиляторы поддерживают структурную обработку исключений. Так что соглашусь с MAKCim. Хотя, в принципе, если уж так сильно хочется исключений, то SEH- вполне нормальный выход... ) Добавлено через 5 минут и 48 секунд Поверьте, их может быть ОЧЕНЬ МНОГО! Только C как таковой здесь не причём... |
| Автор: Abyx 4.8.2010, 11:42 |
1. переписать эту длл, чтоб была многопоточной 2. перехватывать обращения к секции данных, выдавать каждому потоку свою секцию данных. делать по длл на поток - это весьма расточительное использование памяти. разве что дллки очень маленькие. впрочем переименовывать файл - это тоже сомнительное решение, из разряда "как умеем так и делаем". так что 3й вариант, с копированием: 3. свой загрузчик, который будет копировать только то что действительно надо копировать. |
| Автор: Леопольд 4.8.2010, 14:50 |
| По мне, так С++ силён шаблонами - работой на этапе компиляции |
| Автор: borisbn 4.8.2010, 15:18 | ||
| HellStranger, Abyx, повторю Abyx, мне нужно было простое и быстрое решение. Я его сделал за 10 минут. Сколько нужно на твои ( с учётом поиска информации о том, как это делается ) ? Transport Layer Security ?
предложи другое, но с учётом того, что я написал здесь. |
| Автор: boostcoder 4.8.2010, 15:22 |
Thread Local Storage |
| Автор: HellStranger 4.8.2010, 15:39 | ||||
Если по-русски, костыль... Опиши проблему в деталях- предложу. Пока что я понял, что есть кривая/ые dll и примерно такой же метод работы с ней/ними. Добавлено через 6 минут и 36 секунд
На самом деле никакого дополнительного использования памяти нет. Стопятьсот разных потоков грузят одну dll- результат один: в виртуальном адресном пространстве процесса одна dll, на которую стопятьсот ссылок и которая не выгрузится до тех пор пока либо не завершится приложение, либо не вызовется стопятьсот раз FreeLibrary. Как я понял, он переименовывает одну и ту же dll и грузит переименованные копии... Насчёт этого метода всё уже сказано... |
| Автор: borisbn 4.8.2010, 16:00 |
согласен. я http://forum.vingrad.ru/forum/act-ST/f-92/t-306983/unread-1.html, чтобы не захламлять чужую. |
| Автор: MAKCim 4.8.2010, 21:25 | ||
ну так акцент в высказывании делался именно на С ;) Добавлено через 2 минуты и 19 секунд
если либа не thread-safe, то что мешает вызовы функций либы обернуть локами? или тым критическая к локам функциональность? |
| Автор: W4FhLF 5.8.2010, 06:46 | ||
Вероятность коллизий обратнопропорциональная размеру выходного множества хеш-функции, для любого случайного входа для CRC32 вероятность коллизий 1 / 2^32. Для конечного множества из N элементов (в данном случае строк) вероятность коллизий (N - 1) / 2^32. А вообще тема скатилась в область системного программирования, где бессмысленно рассматривать эти два языка, особой разницы нет. Если же мы начинаем оперировать абстрактными типами данных, из реальной жизни или из каких-то научных направлений, то С сливает в жёсткой форме. Взять те же матрицы, они могут быть большими, маленькими, с комплексными числами, плотные и разреженные, симметричные, трёхдиагональные, хранить разные типы (простейший случае одинарная и двойная точность). И для всего этого на С++ я имею один унифицированный интерфейс и благодаря шаблонам оперирую над данными любых типов. Причём работает это всё очень очень быстро. В какое г**но это всё превратится на С даже трудно себе представить. |