Доброго времени суток!
Как вы уже догадались, топик посвящается языкам С и С++. Однако, я не буду задавать вопрос "какой язык лучше?". Нет. Не буду кота за я"ца тянуть. Оба языка мне нравятся.
Процедурное программирование, т.е. чистый С хорош во многом. Особенно он мне понравился в разработке Windows приложений. Код получается весьма обширным, легко запутаться, но программа получается очень быстрой и маленькой по объёму. Нет ничего лишнего, только то, что мне надо. Реализовать такую простоту средствами ООП у меня не получилось. Может руки не с того места растут? Может быть... У меня мало опыта. Но зачем мне огромная куча объектов типа (к примеру) СButton? Каждая кнопка выполняет определённое действие, значит надо создавать множество классов наследников с виртуальными процедурами обработки. То же самое касается других элементов интерфейса. Согласитесь, это лишнее.
Однако, есть области программирования, где без ООП не обойтись. В таких случаях писать код на чистом С будет очень затратно и логических ошибок не избежать. 
Так как же? Совмещать оба языка? К примеру писать интерфейс программы на С, а суть программы писать, по необходимости, на С++. Приемлемо ли это? Или нужно выбрать конкретный язык?
Вопрос странный, понимаю, но тем не менее, помогите, пожалуйста, разобраться в этом очень нелёгком вопросе.

P.S. я большой противник всяких там MFC, VCL, Qt и тому подобное. Мне кажется, они лишают нас всего кайфа программирования.

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

Оно и понятно. Не в обиду.


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


Множеста классов не надо создавать. Объект = данные + код. Все кнопки - экземпляры одного класса СButton, а код обработчика какого-либо события у них может быть разным.


Писать интерфейс на С/С++ - почти всегда использование не по назначению.


Это сообщение отредактировал(а) kemiisto - 1.8.2010, 20:42

только в случае если интерфейс будет вызывать код на другом языке

А что же Вы предлагаете? Я конечно понимаю юношеский максимализм, но когда/если дорастете до проектов крупных и за которые платят деньги, поймете что основная цель - решить поставленную задачу в приемлимые сроки. За кайф от программирования заказчики не платят.
Но даже если смотреть на этот вопрос не с точки зрения затрат времени. Я не думаю что разработчику, которому нужно нарисовать интервейс будет в кайф реализовывать мегатонны велосипедов, архитектурный дизайн и прочие возможности, которые предоставляют фреймворки уровня Qt. Поверье есть задачи намного более сложные, чем натыкивание кнопочек на форму, которые решают и на уровне выше графической библиотеки, то есть различные извращения с интерфейсом, оптимизация под конкретные задачи и прочее. Сложный интерфейс сделать ведь тоже не легко. А так же задачи, решаемые на уровне ниже графического интерфейса, в ядре приложения. А переписывать каждый раз избитые велосипеды снова и снова это не кайф, а ненужная трата времени. Плюс тонны ошибок в этих велосипедах, которые так же нужно покрывать и отлаживать.
Думаю/надеюсь с опытом это пройдет.

Это сообщение отредактировал(а) cutwater - 1.8.2010, 22:09

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

cutwater, согласен, в программировании интерфейса мало чего интересного. Там мало интересных инженерных решений. Это просто рутинная работа, которую, если честно, я всегда не любил. Всегда было желание ускорить этот процесс и перейти к части, где нужно подумать и найти интересное решение проблемы. Пожалуй, я неправильно выразился и проблема с написанием интерфейса заключается в другом. Я провёл небольшой опыт. Написал две абсолютно идентичныео по функциональности программы: обе тупо создают пустое белое окно. Первая программа была написана с помощью MFC, другая на чистом С. Разница меня не порадовала. Окно написанное на MFC занимало в оперативной памяти на 1мб больше чем окно, написанное на С. И это всего лишь одно простое окошко. Что говорить о серьёзном приложении?
Но судя по вашим отзывам, вы за то, чтобы программировать только на С++. Я правильно понимаю?

• Серьёзное приложение с графическим интерфейсом на чистом С можно не дописать и до конца света.  
• Не надо сравнивать пустые окна. Нужно сравнивать готовые приложения. И не только размер в оперативной памяти, но и трудозатраты.

Боже, нет! Ну не надо С++! 2010 год на дворе, всё, хватит...

Предлагай людям альтернативные языки менее эмоционально. Все-таки, мы в разделе С++.   

Letchik, как ты думаешь, почему тот же Qt цветет и пахнет? А я тебе скажу, что 1 мегабайт роли не играет. Так как это константная плата за удобство. При большем расширении функционала объем занимаемой памяти будет не так сильно расти.

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



Особого смысла не вижу, если только клиент не требует. Везде работать надо.
Желание клиента - закон ! Он платит.

Интересен Ваш выбор ?
С#, Java или ???

Это сообщение отредактировал(а) Modul - 1.8.2010, 23:32

Не совсем так. Изначально ООП появилось как средство симуляции в Simula-I. В этом языке были activity (классы) и process (объекты). В Simula-67 уже повилось слово class. Ole-Johan Dahl и Kristen Nygaard опирались среди прочего и на работу C. A. R. Hoare    
, Record Handling.

Потом был Alan Kay со товарищи и Smalltalk. ООП - как средство построения графического интерфейса. Но в итоге опыт обобщили до любых сложных задач.

В итоге посыла было два:

Alan Kay, The Early History of Smalltalk


C# - можно, вместо Java лучше Scala. Ещё можно попробовать динамические ЯП. Тот же Python. Есть наблюдение, что любителям C нравится Python. Smalltalk тоже можно. Да много языков...  

ооо. прогресс. раньше помнится был только Оберон   

Знаешь в чем кайф программирования? Написал программу, сдал, получил деньги и кайфуешь  
А сидеть пару месяцев над простейшей программой, только потому, что тебе "не в кайф" учить Qt или .NET, а хочется поработать на WinAPI и сотворить пару сотен велосипедов - это уже патология. 

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

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

Абсолютно согласен! Я уже приводил минимум 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- прошлый век, это очень не умно. 

Вот. И теперь мы решаем сложные и еще более сложные задачи.

Мы же говорим про настоящий момент и немного на перспективу !  

Кроме того есть теоретики и практики.

Есть и определенные критерии (показатели) оценки эффективности.
Например скорость разработки, спрос, зарплата.

А смысл изучать что-то хорошее, но мало востребованное.
Нонсенс !

Да еще важна специализация работника - к чему он тяготеет.


Все хорошее уже изобретено.
...и человек займется наконец своей работой !   


Тоже верно.
Смысл писать 1 функцию и для нее класс, потом еще создать объект и его удалить.
Написал DLL, загрузил сишным методом и дело сделано.
Отсюда вывод:
Зачем из пушки по воробьям стрелять. Незачем !

Другое дело - большой класс, например парсер с 10 функциями.
Здесь без ООП просто не обойтись.

Можно здание строить из кирпичиков и из глины, долго месить и построить через 3 года.
А можно из блоков (классов-объектов) или из панелей (готовые классы).
Результат - полгода.
Зарплата та же.

p.s. Философия ООП

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

и потом еще можно свое творение (класс) снабдить описанием и толкнуть на рынке.

Чем не повторное использование, только на рынке.   

Еще на этой основе встречаются библиотеки - довел до ума - покупай !

Загнал в тупик... Как тогда тысячи программеров с FFMPEG разбираются?.. Как новые программеры сего проекта продолжают его дальнейшую разработку?.. У меня на освоение принципов работы с FFMPEG ушла неделя наряду с текущей загруженностью. Ещё через месяц у меня уже был готов простенький видео-редактор, абсолютно с нуля. Live555 меня поверг в уныние через 10 минут просмотра исходного кода... Так что, как говорил Альберт наш Эйнштейн, всё относительно. 

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


Ты очень остроумный. Но, тут разговор о десктопе. Так что уж слишком толсто получилось. Незачёт.


Я что-то ничего из этого примера не подчерпнул. Часть про asm совсем не к месту. Поток сознания. 

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

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


алсо да. и на С++ и на асме надо еще уметь программировать.

Что-то я в названии темы не увидел, что речь идёт ИСКЛЮЧИТЕЛЬНО о desctop, примеры были приведены десктопные, имхо, только потому что автор пока ими и занимался. Так что расписываться в моей зачётке не надо, без вас профессура уже давным-давно справилась. 



А у меня нет самоцели, чтобы лично вы что-то поняли. Между делом, в теме упоминались ещё и C#, и Java и ещё много других языков... Тоже не в тему, а в качестве примеров.

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


Знаете, в кривых руках и машинный код чистому C сливает. Я не говорю сейчас о горе-хаккерах, которые изучили систему команд x86 на уровне младших курсов МФТИ и мнят себя мегамозгами в asm. Их код может и cpp слить, что дальше?.. cpp всех круче?.. 

У вас в корне неправильный подход.

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

А какого размера получится скомпилированный модуль - 10 Кб или 3 Мб, сколько он памяти будет потреблять - 1 Мб или 50 Мб, и за сколько он у вас выполнит требуемое действие - за 10 микросекунд или за тысячу - НИКОГО не волнует. 




Все такими были когда-то 

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

Правда компилятор превращает ваше семейство в такой же набор функций.  Я сейчас не говорю об удобстве, по-моему уже стопятьсот раз упоминалось, что нужно миллион шаблонов и классов на все случаи жизни- .NET Framework уже есть, смысла изобретать велосипед не вижу...

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


Специально для вас был создан .NET Framework. Сколько клиентов за эти 10 микросекунд: 10 или 10000 сможет обслужить сервер тоже никого не волнует?.. Вы перегрелись на солнышке, уважаемый... 

и сколько можно эту гадость пиарить ? к тому же еще только виндоус ориентированную.. 
  


HellStranger, приведите обоснование тому факту, который Вы не раз озвучивали, о том, что С++ сливает Си..

Объясню для непонятливых.

Топикстартер хочет писать интерфейс на "чистом С". Написанное мной следует понимать в этом контексте.

"Интерфейс" не обслуживает 10000 клиентов за 10 микросекунд.
Поэтому за сколько именно микросекунд обновится, например, надпись на кнопке - никого не волнует.


То, что при циклических интенсивных операциях скорость важна - и коню понятно.

А кто её пиарит-то?.. По-моему, вы определённо перегрелись... )))))))))))) Я вовсе никого не склоняю к её использованию, а просто привожу пример хрени, в которой есть всё на все случаи жизни: для построение клиентских приложений да ещё и для тех, кого производительность ни в каком виде не трогает- просто находка! 



На эту тему можно нагуглить тонны статей как в пользу C, так и в обратную... Сторонников cpp не убедит ничего из доводов сишников, как и наоборот. А переливать из пустого в порожнее мне уже порядком надоело... Вам станет намного легче, если я выложу пару тройку ссылок на статьи, где говорится как и в чём cpp сливает?.. Уверен на стопятьсот процентов, что подтянутся местные воротилы cpp, и продолжится война C-cpp. Данахононадо. 

Я прекрасно знаю Си (очень на это надеюсь). Но при этом я не готов утверждать, что на Си напишу программу сложнее hello world за время, незначительно уступающее оному на  C++. Все-таки, есть вещи, которые удобней и, я уверен, быстрей работают на С++, чем на Си. Например, строки. когда тебе надо сравнить две строки, strcmp будет перебирать все символы, пока не встретятся различия, а std::string может (при желании его разработчиков, конечно) для начала просто сравнить размеры строк - это операция с константной сложностью, в отличие, от strlen. Сортировка с помощью std::sort работает быстрей, чем через qsort. Думаю, список можно продолжать. Конечно, это все достигается за счет увеличения размера программы. Но кому надо, тот добавит ключик -O1 компилятору...
И вообще, ты хоть сам С++ знаешь? Или критикуешь его по типу: "не читал, но осуждаю"?

Почему приводить то крайности ? тем более что требует она  специфических языков..  почему бы не привести пример хорошей библиотеки ? хотя бы той самой Qt..


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

Вообще-то при сравнении строк сравнивать первым делом их длину как-то не очень умно, "abcdefghij" < "cdefghij", причём длина?.. Да и немного настораживает уверенность по поводу реализации различных алгоритмов в стандартных бибилиотеках разных производителей... Попахивает ОБС (Одна Баба Сказала). Что касается сравнения строк, тоя  уже писал, что strcmp убивает string::compare в десятки раз... qsort- сильно зависит от того, что сортируем, все возмножные варианты не перебрать, но специалдьно для тебя проведу пару тестов и отпишусь. 

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


Ясно... Человек, который знает всё- глупец, не спорь с ним... 

Извиняюсь, что пронёс полную ахинею по поводу C... Ты во всём абсолютно прав! Я беру трубку и идут курить в корридоре...  

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


О чём здесь говорил, знаю и использовал неоднократно! "Прекрасно" C++ не знаю и никогда не узнаю. Во-первых, это невозможно, во-вторых, у меня другие интересы в программировании.

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


Хотя бы просто потому, что "хорошая библиотека Qt"- это очень спорный вопрос. Кому-то нравится, кому-то совсем наоборот. Можно привести и wx, но и здесь всё очень спорно. А по поводу .NET я ни слова не сказал, что это "хорошая" технология!

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 17:27

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

Хоть я и обещал не отвечать на ваши посты, но так уж и быть...

Только в свободное от проектов время, а это будет не раньше сентября. Так как за соревнования заказчик, к сожалению, не платит. А работа дороже...
Так как неоднократно поднимался вопрос о стандартной библиотеке C и stl. Предлагаю на этом и сконцентрировавть внимание. Всевозможные сравнения строк, поиски подстрок и т.д. и т.п. Сортировки наборов различных структур данных, ну и что ещё в голову взбредёт. 
Реализовывать рекурсивные алгоритмы, да, если ещё с отрисовкой- это больше смахивает на "у меня длиннее", а не на сравнение языков.
Продолжая тему, могу вам предложить реализовать простенький видеоредактор с базовым функционалом: я буду использовать сишный FFMPEG, а вы- что найдёте из cpp. 

Так что: базовые алгоритмы CRT и аналоги из STL. На паре-тройке компиляторов. Смогу начать уже сказал когда. До этого момента я даже сортировку пузырьком писать не буду...

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 18:38

слово "хорошая" было поставлено в противовес выделенному 
а Qt привел в пример не потому то, она такая хорошая, а потому, что в отличие от .Net свободная
в том плане, что 
1. хотя и требует тоже специфических особенностей, но позволяет пользовать обычный (не специфический) компилятор
2. доступна  значительно более, чем на одной платформе
3. необъективно: приятна и логична в освоении.. 

Это сообщение отредактировал(а) mes - 2.8.2010, 20:35

по поводу С vs. C++

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

если использовать С++ просто как "С с классами", то там нет практически ничего, что может затормозить процесс выполнения

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

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

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

В топку видеоредакторы, это весьма скучно и рутинно, к тому же решения будут базироваться на сторонних библиотеках - в итоге просто сравниваются библитотечные пиписьки. Предлагаю наколбасить по парсеру. Используем стандартные библиотеки (C99 - libc, C++03 - libc и libstdc++), всяким генераторам - нет. О входном языке можно договориться, о модулях (собсно парсер, оптимизатор, генератор кода/интерпретатор) - тоже; при подведении итогов сравниваются объем кода (меньше - лучше), его простота (проще - лучше), простота внесения новых языковых конструкций и прочих фич (к модулям, если будет что-то кроме парсера) (проще - заeбатее), производительность (скорость, память), что-нибудь еще? Заведомо субъективные оценки выносим на голосование.

Это сообщение отредактировал(а) djamshud - 2.8.2010, 22:11

djamshud, 
идея "соревнований" обречена на нереализацию ;)
проверено практикой

Естественно! Почему я приводил в пример PWLib, OPAL и старенький уже OpenH323. С++ используется просто как язык, поддерживающий ООП... ну и операторы переопределяются многие. Разработана вполне понятная, логичная архитектура классов, вся реализация которой- чистый C. 



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



Реализовывать круптые поделухи, я думаю, ни у кого особого желания нет, по крайней мере у меня и времени нет. А что-нибудь простенькое для сравнения CRT и stl- я только за. Пусть и другие заинтересованные лица подпрягаются. Обсудим, что будем сравнивать и как.

Добавлено @ 22:44


Прошу обратить внимание, что библиотечные пиписьки я указывал сишные и пипишные. Как нельзя лучше отвечает предмету нашего соревнования. ) Это во-первых. Во-вторых, когда сварганишь редактор и пережмёшь им пару сотен фильмов, поизголяешься над звуковыми пакетами в .mov и профилях H264 и AAC, тогда и скажешь, что скучно и рутинно. По-моему, очень интересная область программирования. В-третьих, неужели у программистов есть время на то, чтобы реально меряться письками?.. Наряду с рабочими проектами можно найти море сторонних проектов, чтобы на маслице и икорочку к хлебу заработать... когда здесь меряться?..

Это сообщение отредактировал(а) HellStranger - 2.8.2010, 22:57

учится, учится, еще раз учится (с) дядя ленин.


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

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

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

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

наследуемся от std::string, добавляем свойство - _хеш_сумму_, и вуаля! сравнение за один машинный такт! это же очевидно 

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


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

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

это чё?

т.е. вы хотите сказать, что выучить Си сложнее?  лжец!

Ага, в 12 ночи сел ваять. ;)



И это я флудер...  У меня по дискретке хорошо профессор говорил: "Нечем заняться, не делай этого здесь." От тебя уже реально один бред пошёл...

Если быть точным - в пять:Правда, я имел в виду сравнение на равенство, операторами == и !=. Только в их случае имеет смысл сравнивать длину.

Если ваша программа (данные+функции) написана на Си и вам понадобилось внедрить ваш код в многопоточное приложение, то у вас начнутся проблемы (не нерешаемые, но всё же ...)
Если ваша программа написана на Си++ и вам надо перевести её на Си (для использования в каком-нибудь контроллере, например), то у вас тоже будут проблемы.
Вывод: edem das zaine (пардон за мой немецкий)
И ещё: если нужно написать программу с одной кнопкой, выводящей по нажатии на неё Хело Ворлд, то без использования визардов на Си уйдёт пару часов, на MFC - минут 20-30, на VCL или Qt - 2-3 минуты. Выводы делай сам

множественное наследование и dynamic_cast на Си покажите

встроенных нет. но самому организовать тебе никто не запрещает   

bsa, я думаю вы понимаете, что это *много строк кода*
вернее *ОЧЕНЬ МНОГО СТРОК КОДА*

мой опыт работы с COM из асма показал что лучше использовать как минимум С++ и ATL 

Это сообщение отредактировал(а) Abyx - 3.8.2010, 10:27

HellStranger, тогда к чему вообще написание каких-то редакторов? Ищи по софтине с (примерно) аналогичным функционалом на разных языках и сравнивай. Можно найти кучу примеров как в пользу сишных поделок, так и плюсовых - в конечном счете все упирается в криворукость ваятелей каждого конкретного решения. Плюсы дают такой же простор для творчества и маневра, что и си, но предлагают больше слов для выражения своих идей, и, если ты путаешься в этих словах - ССЗБ, пиши на более простом си и трать на разработку больше времени, в противном случае получай как минимум тот же результат (хотя на деле результат скорее всего окажется более расширяемым и масштабируемым - но тут опять все зависит от криворукости) за умеренные сроки.

boostcoder, 

>наследуемся от std::string, добавляем свойство - _хеш_сумму_, и вуаля! сравнение за один машинный такт! это же очевидно

Че, серьезно? Показывайте пример сей чудной перделки или признавайтесь, что ляпнули глупость.

а что тут несерьезного? сложность в чем? точнее, в чем именно?

boostcoder, пример, пожалуйста. А там посмотрим, что за проблемы. Сколько уже можно теоретизировать?:)

В том, что методы сравнения у std::string как минимум не виртуальные. Т.е. наследованием ты тут не обойдешься - придется делать агрегацию и перенаписание всех методов заново. А потом, когда ты собрался считать хэш? на этапе присваивания/изменения значения? А ты не думал, что может оказаться такая ситуация, в которой есть куча смен значений и ни одного сравнивания? Кстати, хэш тебе не заменит compare.

Ну и ладно, теория тоже хорошо в конце концов.

1. Коллизии (потенциальные!). Что с ними делать?
2. Есть ли хеш-функции, гарантирующие, что хеш любой "меньшей" строки будет меньше хеша данной строки? Сомневаюсь.

потестить тут: http://liveworkspace.org/code/be1ad8c6bdca...15e8dd2119deb17


нет, я конечно подумал об этом. но раз HellStranger`а беспокоит производительность, значит ему нужно сравнивать не 5 строк. но если строк много, тысячи..сотни тысяч, то рассчитывать хешь нужно в момент "собирания" такого кол-ва строк. т.к. сложно представить источник, способный формировать, к примеру, мильён строк за 20мс.


смотря что ожидается от compare.

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

я так понял, разговор про operator==() и !=

Добавлено через 5 минут и 2 секунды
кстати, еще один тест: http://liveworkspace.org/code/6b5720fc2147...b8e099875da53d1
как видно из результата, сравнение стандартной строки, происходит в 6-7 раз дольше. профайлер говорит что все тормоза из-за функции(метода) __builtin_memcmp(). но я ее не нашел.

Добавлено через 5 минут и 48 секунд
зы
алгоритм подсчета хеш суммы, взят из википедии.

Если быть совсем точным, то зависит от компилятора и процессора, но суть Тела не меняет, правда ведь?.. 
Операторы сравнения: в C аналогов нету, смысл сравнивать?.. Или будем сравнивать указатели? 

Что касается qsort, то результат вас тоже не сильно обрадует... Хотя, сильно зависит от того, что сортировать...

Предлагаю! Всем заинтересованным в тесте людям, модераторам тоже! Реально заняться сравнением прелестей CRT и stl. Выработать ощий план: что сравниваем, как сравниваем, на чём сравниваем. Прок от этого, думаю, в любом случае будет: кто-то начнёт больше юзать CRT, а кто-то, возможно, обратит внимание на stl... 

Это сообщение отредактировал(а) HellStranger - 3.8.2010, 11:47

>я так понял, разговор про operator==() и !=

С ними весьма хорошо справляются и обычные сравнения длин + memcmp. Для сортировок нужно проверять на больше/меньше.

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

Добавлено через 4 минуты и 44 секунды
Я как бы намекаю, что сравнение строк по их хешу очень эффективно, когда идет речь о !=, а == - это сравнение хешей плюс сравнение самих строк.

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


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

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

вариант   

boostcoder, так вы признаете, что ваша реплика об однотактовом сравнении имеет смысл только для операции !=, а все остальные - ==, >, <, >=, <= - будут тупить и особого смысла применять к ним хеширование (внутри реализации класса "строка") нет? Или будете гуглить волшебные хеш-функции?:)

Да и между нами девочками, нехилые такие строки получаются... В C просто набор байт и ничего лишнего... А здесь уже нагородили хэш-таблицы, помимо своих охренительных прелестей std::string... А мне надо тупо сравнить "Вася Пупкин" с "Маша Залупкина"! Сейчас мы вооружимся ядерной боеголовкой производства boostcoder и Ёпнем по мухе!

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


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

да  

буду. любопытно  


ничего не городил. стандартная таблица.


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



  

boostcoder,

>буду. любопытно

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

а какая вероятность коллизий, кто-то может сказать? чувствую, что получится так, что она почти невероятна  

HellStranger, это была ирония. Почему никто этого не понял?.. :)

Добавлено через 3 минуты и 47 секунд
boostcoder, она маловероятна для десяти строк. Но вот же будет обидно, когда чудо-программа возьмет, да перепутает Васю с Маней. Какой бы малой эта вероятность ни была ее никак нельзя игнорировать.

Вообще-то, операции != и == имеют абсолютно одинаковую сложность. Так как != это инвертированный вариант ==. Т.е. если ты зафиксировал, что условие a != b не выполняется, то можно со 100% точностью сказать, что выполняется a == b. В нашем же случае, когда два хэша равны, это не значит что две строки равны. Это значит, что надо сравнить сами строки. И не важно для какого оператора - == или !=.

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

Это сообщение отредактировал(а) HellStranger - 3.8.2010, 12:40

bsa, да, у меня мысля за мыслю зашла.

Это сообщение отредактировал(а) djamshud - 3.8.2010, 13:10

зато если хэши не равны, то однозначно не равны.. хотя в любом случае не аргумент.. 

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

а вот например как выглядит на С реализация автоматизации по технологии CopyOnWrite ?
или RAII ? 

Посмотри OpenSSL  

Имхо, это нереально.

какие?

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

не надобно из-за отсутствия исключений ;)

MAKCim, в Си могут быть исключения.
в винде например есть SEH\VEH + RaiseException()

Abyx, 
это не связано с языком как таковым

MAKCim, когда функции используют глобальные статические переменные и их потребовалось использовать в нескольких потоках - это проблема. У меня были случаи, когда dll-ки, написанные подобным образом на Си нужно было переименовывать в рантайме и загружать её копию в каждом потоке.
Конечно и на Си++ можно так писать, но процедурное программирование к этому больше располагает, чем классы

вы уверены что это нормальный способ? если длл - ваши, то более тупого решения не придумать %) для таких вещей есть TLS