Re: С vs C++
От: frogkiller Россия  
Дата: 29.01.10 06:42
Оценка: 2 (2) +3 -5
Здравствуйте, abdul.zycor, Вы писали:

AZ>Всем привет! Не так давно стал изучать программирование для unix систем.

AZ>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.
AZ>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.
AZ>Какие могут быть обьяснения тому?

AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.


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

Но всё вышесказанное относится к большим промышленным серверам — когда речь идёт о миллионах запросов в сутки и куче разнообразного контента. А так, для простых нужд сервера пишут на чём душе угодно, включая перл с питоном и хаскель с лиспом
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[2]: С vs C++
От: Pavel Dvorkin Россия  
Дата: 29.01.10 07:17
Оценка: 2 (2) +2 -5
Здравствуйте, frogkiller, Вы писали:

F>Полагаю, что на плюсах сложнее оптимизировать производительность больших серверов. Казалось бы: тут лишнее копирование, здесь виртуальный вызов, а вон там чуть больше памяти аллокатор выделил — вроде бы по отдельности это мелочи, но вместе может набежать нехилое замедление. Это обратная сторона более простого и красивого кода, я имею ввиду именно плюсовый стиль, а не си-стайл или около него, просто скомпилированный плюсовым компилятором. (И да, я считаю грамотно написанный плюсовый код с шаблонами и наследованием более простым)


Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.
With best regards
Pavel Dvorkin
Re[3]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.01.10 11:00
Оценка: +2 -5 :))
Здравствуйте, Pavel Dvorkin, Вы писали:

F>>Полагаю, что на плюсах сложнее оптимизировать производительность больших серверов. Казалось бы: тут лишнее копирование, здесь виртуальный вызов, а вон там чуть больше памяти аллокатор выделил — вроде бы по отдельности это мелочи, но вместе может набежать нехилое замедление. Это обратная сторона более простого и красивого кода, я имею ввиду именно плюсовый стиль, а не си-стайл или около него, просто скомпилированный плюсовым компилятором. (И да, я считаю грамотно написанный плюсовый код с шаблонами и наследованием более простым)


PD>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.


Это как бы ЯВУ, на самом дело недо-ЯВУ.
Re: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.01.10 10:58
Оценка: +1 -6 :)
Здравствуйте, abdul.zycor, Вы писали:

AZ>Всем привет! Не так давно стал изучать программирование для unix систем.

AZ>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.

Так и есть.

AZ>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.


Есть в с++ нечто, что рождает монстров вроде буста и стл, и благодаря им так и сложилось с серверами.

AZ>Какие могут быть обьяснения тому?

AZ>У меня такие:
AZ>Почему пишут на с:
AZ>1. в отладчике gdb приятнее видеть короткий простой код на с
AZ>2. не знают с++, поэтому пишут на с
AZ>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++
AZ>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++
AZ>5. мног окода написано уже на с, хоят и новые почему-то пишут на с

AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.


с++ мало кто знает на том уровне, на котором его нужно знать для разработки.

многие вещи в С++ можно использовать не иначе с оглядкой.

с++ гораздо дОльше учить, а преимущества весьма сомнительны.

нет хорошо доступных серьезных инструметов например
1 для рефакторинга,
2 отладки
3 анализа кода

компиляторы между собой слабовато совместимы, собственно это и показывает ущербность языка
Re[6]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.02.10 14:55
Оценка: -3 :))) :))
Здравствуйте, CreatorCray, Вы писали:

I>>>>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.

DC>>>Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься.
I>>между компилерами с++ совместимость крайне слабая, все они совместимы на уровне Си
CC>Это в общем случае.
CC>ICC например совместим с MSVC и GCC (линуховая версия ICC).

ICC это экзотика.
Re[7]: С vs C++
От: CreatorCray  
Дата: 02.02.10 09:20
Оценка: +3 :)))
Здравствуйте, bazis1, Вы писали:

PD>>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.

I>>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>>Совместимость с C делает его недо-ЯВУ.
B>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет? Код более читабелен, по сравнению с альтернативами? Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?
Это КСВ, тут принято кидать какашками в друг дружку. Причем всем ведь (кроме закостенелых троллей) на самом деле глубоко накакать на результат флейма. На практике все вменяемые люди будут применять тот либо иной язык исходя из практических соображений, а не от написанного/прочитанного тут.

I>>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.

B>Там синтаксис невменяемый.
Ну вот, так хорошо начал, а сам?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[39]: С vs C++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.02.10 21:49
Оценка: +4 :))
Здравствуйте, Ikemefula, Вы писали:

MC>>Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. [...]


I>Пусть развивается. Он за пределами стат-погршности, всего то.


I>Нужен интрумент для решения текущих задач бизнеса, а Лисп — нет, не нужен.


Так сказал Ikemefula!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.01.10 19:34
Оценка: 1 (1) +3 -1
Здравствуйте, dr.Chaos, Вы писали:

AZ>>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.


DC>Переносимость выше.


Дело в том, что С по всем признакам есть платформа, хотя это всего лишь язык.

Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.

Я такую вещь заметил, что чем больше пишу на С#, тем
1 труднее переключаться на С++
2 легче писать на Си.
Re[2]: С vs C++
От: TarasCo  
Дата: 29.01.10 06:29
Оценка: :))) :))
N>я вообще дотнетчик и скорее должен рассказывать анекдоты в КУ, чем писать сюда, но рискну предположить что прострелить ногу в условиях сервера очень больно и чтобы сделать все проще люди пишут самое критическое на си

Э, да ты сразу на святое замахнулся! Все спипишники считают, что два креста благословят их код и спасут их ноги.
Да пребудет с тобою сила
Re[13]: С vs C++
От: Vamp Россия  
Дата: 03.02.10 14:53
Оценка: +5
I>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?
Да здравствует мыло душистое и веревка пушистая.
Re[11]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 12:43
Оценка: 4 (3) +1
Здравствуйте, Ikemefula, Вы писали:

C>>Есть стандартизованный D-BUS. Прямой аналог COM, в общем.+++

I>Ога, а ты COM то видел ? Сравни и не пори чушь
Мальчик, я COM не только видел, но и ещё с нуля писал OLE-контейнер.

COM:
hr = CoCreateInstance (pClsid,NULL,CLSCTX_LOCAL_SERVER,
         IID_IDispatch,
         (void FAR* FAR*)lpDispatch );

if (hr != S_OK)
 return (-1);

hr=lpDispatch->GetIDsOfNames(IID_NULL,&szStart, 1,LOCALE_SYSTEM_DEFAULT,&dispid);

if (hr != S_OK)
 return (-1);

    dispparams.rgvarg = &myargs[0];
    dispparams.rgvarg[0].vt = VT_I4;
    dispparams.rgvarg[0].iVal = 12345;
    dispparams.rgvarg[1].vt = VT_I4;
    dispparams.rgvarg[1].iVal = 67890;
    dispparams.cArgs = 2;
    dispparams.cNamedArgs = 0;

hr = lpDispatch->Invoke (dispid,IID_NULL,LOCALE_USER_DEFAULT,
DISPATCH_METHOD,&dispparams,NULL,NULL,NULL);


D-BUS
org::foo::bar::network *interface = 
    new org::foo::bar::network("org.foo.bar", "/network",
                            QDBusConnection::sessionBus(),
                            this);
interface->ping("kde.org");

или с более сложным примером: http://wiki.apertium.org/wiki/Compiling_a_C%2B%2B_D-Bus_program
//Имена, а не GUID'ы!
    static const char* TRANSLATE_SERVICE_NAME = "org.apertium.mode";
    static const char* TRANSLATE_OBJECT_PATH = "/";

    std::string mode;
    std::map< ::DBus::String, ::DBus::String> translate_options;
///....

    //Никаких CoCreateInstance - простые конструкторы!
    Translate translator(bus, TRANSLATE_OBJECT_PATH, TRANSLATE_SERVICE_NAME);
    //Да-да, мы передаём не жуткие SAFEARRAY и VARIANT, а самый обычный std::map
    std::cout << translator.translate(mode, translate_options, input.str())
              << std::endl;


I>D-Bus это докомовский период

Посткомовский. Там исправлены кретинизмы COMа.
Sapienti sat!
Re[4]: С vs C++
От: zaufi Земля  
Дата: 29.01.10 21:29
Оценка: 2 (2) +1 -1
Здравствуйте, abdul.zycor, Вы писали:

AZ>Здравствуйте, Menestrel, Вы писали:


M>>Здравствуйте, Ikemefula, Вы писали:


I>>>нет хорошо доступных серьезных инструметов например

I>>>1 для рефакторинга,
I>>>2 отладки
I>>>3 анализа кода

M>>Это ты зря сказал

M>>Сейчас тебя загрызать будут

AZ>Между прочим это действительно так, различается очень разработка в студии.

AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично ну если это возможно. А написав код в виме, например трейсить его лишний раз в gdb желание отпадает, ну конечно остается только смотреть логи.

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

второе это просмотр коры... собственно в 90% случаев именно для этого я использую GDB -- какиета мега IDE и прочий гуйный хлам нафиг тут не сдался...
`gdb mybinary core`
bt


вот и все!
зачем вокруг нескольких команд (fr, thr, bt, p, x) делать front endы для меня загадка...

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

раз уж начал писать в этот thread, не могу не высказаться по другим пунктам...

со средствами рефакторинга как известно есть проблемы -- не раз обсуждалось почему и от чего это так (и в данном контексте оффтопик)...
опять таки скажу с позиции лично моего опыта: ну да несколько не удобно работать, но не архисложно... т.е. даже "не сложно"... ибо большая часть рефакторингов делается руками в редакторе... ну да вместо "одной кнопочки" (точнее меню, диалога, и нажатия Ок) приходится копипакостничать, пользоваться find/replace + regex. А также выручает умение моего редактора пропайпить выделенный текст через любой фильтр (сымсле конвейер, если кто не понял) -- и вот тут всякие IDE с решарперами могут покурить в сторонке... в более сложных случаях на помощь приходят find, grep, sed, xargs, & etc выполняемые из консоли... но это все мелочи по сравнени с тем что сначало приходтся фтыкать в говнокод, потом думать как это улучшить малой кровью и только после этого начать чегото колбасить... вот это я назвал бы полным циклом рефакторинга, а не только последнюю часть связанную с редактированием текста ... дык вот во всем этом цикле сэкономленное время мне кажется не мегасущественным... -- на обед времени тратицо гараздо больше

про отладку уже сказал выше

анализ кода? это о чем? смысле поиск багов без компиляции? навигация по коду? -- не зная что аффтар имел ввиду просто перечислю чем я еще пользуюсь в работе:
ctags -- ну какая-никакая навигация (прикручен в редактор)
lint -- статический анализатор кода... крайне редко пользовался (фактически пару раз когда захотелось проаналайзить откровенно аццкий быдлокод стереть который немедленно было нельзя)... в природе есть еще там какиета подобные тулзы -- но это все для реальных проектов не канает... ошибки обычно более сложные чем они могут находить (если конечно код писали не студенты практиканты)
valgrind -- отдельного представления не требуется я думаю...
strace,truss & etc -- ну тоже все понятно...

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

AZ>Не плохо и не хорошо это, просто по другому.

+100500
Re[11]: С vs C++
От: CreatorCray  
Дата: 03.02.10 11:57
Оценка: 1 (1) +2 :)
Здравствуйте, Ikemefula, Вы писали:

DC>>>>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.

I>>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
M_>>неплохая причина ругать язык

I>Нормальная, если язык позволяет кидать-ловить исключения как попало, значит их и будут кидать как попало.

I>Это только один из примеров.

Человек тоже может справить нужду в любом месте. Но есть те, кто пользуется уборной, а есть "говнокодеры"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[21]: С vs C++
От: Vamp Россия  
Дата: 04.02.10 14:32
Оценка: +3 -1
A>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме. Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
В нормально спроектированной графической системе это будет выглядеть так:

button1.x = 30;
frame.redraw();

Автоматическая перерисовка — зло.
Да здравствует мыло душистое и веревка пушистая.
Re[9]: С vs C++
От: CreatorCray  
Дата: 01.02.10 15:20
Оценка: 3 (1) +1 :)
Здравствуйте, Ikemefula, Вы писали:

I>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

DC>>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.
I>А я не про ваш код говорю, а про тот, который мне довелось видеть.
Ну дык не смотри больше на хреновый код.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
С vs C++
От: abdul.zycor  
Дата: 28.01.10 23:16
Оценка: :)))
Всем привет! Не так давно стал изучать программирование для unix систем.
Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.
Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.
Какие могут быть обьяснения тому?
У меня такие:
Почему пишут на с:
1. в отладчике gdb приятнее видеть короткий простой код на с
2. не знают с++, поэтому пишут на с
3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++
4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++
5. мног окода написано уже на с, хоят и новые почему-то пишут на с

В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.
Re: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 29.01.10 08:18
Оценка: +1 -2
Здравствуйте, abdul.zycor, Вы писали:

AZ>Всем привет! Не так давно стал изучать программирование для unix систем.

AZ>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.

Переносимость выше.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[4]: С vs C++
От: skeptik_  
Дата: 30.01.10 11:24
Оценка: +2 :)
Здравствуйте, Vamp, Вы писали:

_>>Для этого extern C есть.

V>Особенно он полезен, когда в библиотеку помещаются классы.
Этот аргумент невероятно полезен при сравнении С++ и С. Или при использовании С ты сможешь экспортировать классы?
Re[6]: С vs C++
От: denisko http://sdeniskos.blogspot.com/
Дата: 01.02.10 03:24
Оценка: -3
Здравствуйте, Ikemefula, Вы писали:

I>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.


Вы еще дрочите на мак? Тогда мы идем к Вам. Ты на нем хоть что нибудь писал, интересно?
<Подпись удалена модератором>
Re[4]: С vs C++
От: Pavel Dvorkin Россия  
Дата: 01.02.10 07:06
Оценка: +1 :))
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...


На которых пишут не программисты (как на С++), а всякие супер- и пупер-программисты
With best regards
Pavel Dvorkin
Re[3]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 01.02.10 12:58
Оценка: +2 :)
Здравствуйте, Ikemefula, Вы писали:

I>Дело в том, что С по всем признакам есть платформа, хотя это всего лишь язык.


Само собой, на нём ведь API всех популярных ОС написано. Думаю на BeOS ощущения несколько иные .

I>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.


Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься. Ну так и классами и stl-ем никто пользоваться не заставляет, а вот перегрузка функций и шаблоны могут очень сократить количество кода, не отразившись негативно на производительности. Т.е. С++ чувствует себя на платформе С, не хуже, а даже и лучше, чем F# на платформе .Net.

I>Я такую вещь заметил, что чем больше пишу на С#, тем

I>1 труднее переключаться на С++
I>2 легче писать на Си.
Что как бе намекает нам о снижении уровня... абстракции?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[7]: С vs C++
От: CreatorCray  
Дата: 01.02.10 14:59
Оценка: +2 :)
Здравствуйте, Ikemefula, Вы писали:

CC>>ICC например совместим с MSVC и GCC (линуховая версия ICC).

I>ICC это экзотика.
Вау! А пацаны то и не знают.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[17]: С vs C++
От: Mr.Cat  
Дата: 03.02.10 16:26
Оценка: +3
Здравствуйте, Ikemefula, Вы писали:
I>>>Нужны высокоуровневые средтва, рефакторинг тот же.
MC>>Как будто тот же решарпер умеет что-то принципиально более сложное.
I>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение
Ну у решарпера на твоем скриншоте количество пунктов меню набивается за счет "convert шило to мыло" (например, абстрактный класс в интерфейс, ну и туда же преобразования пропертей — которые к C++ неприменимы). А так, что CreatorCray перечислил — это и есть основные возможности — и они заявлены. Не знаю, насколько это в ассисте хорошо работает, просто в этой теме шарповый рефакторинг почему-то преподносится как что-то неземное.
Re[2]: С vs C++
От: Aleх  
Дата: 04.02.10 02:13
Оценка: -2 :)
Здравствуйте, bazis1, Вы писали:

B>C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.

B>Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.

На самом деле, с точки зрения выразительности запись std::map<std::string, std::string> гораздо лучше. И нужно писать именно так (но не в случае с STL ). Проблема в том, что STL довольно хреновая библиотека. И я вообще не знаю случаев, когда её использование было бы оптимальным решением. Но вообще говоря, можно реализовать библиотеку контейнеров (назовем её my_lib) так, чтобы использования объекта с типом my_lib::map<my_lib::string, my_lib:string> транслировалось в эффективный код.
Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка. Размер массива можно задавать через параметр шаблона, для этого определение класса строка должно иметь вид template<unsigned N = sizeof(char*)> class string;
Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.
И можно придумать множество параметров, в соответствии с которыми будут настраиваться контейнеры.
В итоге процесс программирования в таком случае можно будет поделить на две части. 1 — Написание логики работы программы. 2 — оптимизация программы путем подбора параметров контейнеров.
Только почему то господину Степанову это совершенно не пришло в голову...

B>На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.
Re[42]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 10.02.10 11:40
Оценка: +2 -1
Здравствуйте, Mr.Cat, Вы писали:

I>>Ну да, есть проектов, меньше статпогрешности

MC>Извини, я не смог уловить смысла этого высказывания.

Это значит что Лиспа в индустрии по большому счету не существует, т.к. проектов на нем, хучь по чем меряй, меньше статпогрешности.
Re[14]: С vs C++
От: Eugeny__ Украина  
Дата: 25.05.10 11:00
Оценка: +2 :)
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++. Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу. Во всяком случае, такой вывод можно сделать из разнообразных деклараций.


Дело в том, что управляемые языки не содержат такого жииирного источника багов(особенно, особенно для начинающих), как проблемы с памятью. Потому, действительно, клепать формы может даже не особо обремененный знаниями "специалист". И программа не будет постоянно падать, или отжирать память, как если бы было на плюсах у программиста такого же уровня. Станет ли такой человек профи, или нет — вопрос второй. Но порог вхождения для написания несложного коммерческого говнософта(этот факт никого, кстати, не волнует: главное, чтобы деньги приносил) у С/C++ и у управляемых языков весьма различен.

То есть, дело в задачах. При написании сложных систем, требоватальных к памяти/производительности/устойчивости граница не так заметна. На чем не пиши, нужны профессионалы(и тут уже нужны знания и про нюансы работы GC, и понимание, почему ресурсы надо обязательно освобождать, и прочая тысяча нюансов). А если нужно написать софтину о десятке формочек... За памятью сборщик проследит, а других таких масштабных источников багов для такого приложения вроде как уже и нет.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[17]: С vs C++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 25.05.10 15:48
Оценка: 2 (1) +1
Здравствуйте, Ikemefula, Вы писали:

ГВ>>Упс. Не, ну это полный ништяк. Программист, который не понимает, что такое сопоставление символического имени блоку бинарного кода — это анекдот (я в курсе, что их много есть, менее анекдотичными они от этого не становятся). Собственно, этих, альтернативно одарённых, я в расчёт не беру. А в противном случае, линковку как-то особенно "понимать" никакой нужды нет.

I>При чем здесь понимание линковки ?

При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?

I>Речь о практическх навыках работы с линкером. И линкер это не единственная проблема.


Хм. Ты навёл меня на клёвую мысль, надо написать в резюме: "практические навыки работы с редактором связей — 17 лет". А потом отлавливать особо грамотных по вопросам, что это за связи такие.

I>>>Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.

ГВ>>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...
I>Средства рефакторинга помогают преобразовать код к понятному виду. Не долбить целый день одно и то же, а за полчаса привести к нужному виду и двигаться дальше.

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

I>В С++ во первых, средства рефакторинга слабее, во вторых, компиляция слишком долгая.


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

I>Кроме того, в С++ затруднено юниттестирование, написание моков.


При чём тут обучение языку? Чтобы вписывать нужные буквы в мок, необходимо уже понимать — что, куда, почему. А проще всего проверять себя маленькими программками, где нет ничего лишнего. Зачем тут какие-то специальные средства мокогенерирования? Мы всё ещё про обучение?

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

ГВ>>Я говорю "шугаться", поскольку был свидетелем такого "шугания" — даже приходилось по требованию заказчика (внимание — хи-хи) кромсать буст, чтобы не "пугать программистов". Идиотизма ситуации это не отменяет, но зато какая основа для положительных эмоций!
I>Я сильно понимаю этого заказчика — буст увеличивает зависимость от человеческого фактора.

(Отметка на память: посмотреть список авторов буста, буду знать, от кого зависят проекты. В прочем, я отвлёкся.)

I>Если не дай бог он не сможет найти вторую такую же команду, то придется выкидывать или гору денег или похоронить проект.


Одному мне это кажется паранойей (буст — общеупотребительный инструмент)? Знаешь, если так рассуждать, то в программирование вообще лучше не соваться, а то, так и будешь всё время переписывать продукт, пугаясь того, что чайников на разработку не найдётся. Что самое забавное, как раз C++ на сегодняшний день — самый, что ни на есть, стабильный во всех отношениях язык, в отличие от. А буст вообще частью уже перекочевал в стандарт.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[2]: С vs C++
От: bazis1 Канада  
Дата: 01.02.10 10:25
Оценка: 1 (1) +1
Здравствуйте, BigBoss, Вы писали:

BB>Здравствуйте, abdul.zycor, Вы писали:


AZ>>Какие могут быть обьяснения тому?


BB>http://www.kernel.org/pub/linux/docs/lkml/#s15-3

[quote]There is no point in just compiling the kernel with g++ and writing the odd function in C++, this would just result in a confusing mix of C and C++ code. Either the kernel is left in C, or it's all moved to C++.[/quote]
Ну это просто зашибись аргумент. Типа, или всё бросить и начать сначала, или ничего не трогать и закрыть глаза на удобные фичи C++. Ну типа нах нам автоматическая коробка, ведь это надо все машины с ручной в утиль сдать, а потом выпускать на улицы автомат. А то чтобы по одной улице одни ездили на "ручке", а другие на "автомате" — это же некошерно. Да и Торвальдс не разрешит.
О том, как бы поюзать часть удобных фич C++, дабы быстрее и качественнее решить проблемы, стоящие перед разработчиками сейчас, никто и не задумывается. Элементарно можно создать inline wrapper-ы на С++ вокруг существующего API на C — вызывать будет удобнее (те же mutex guard-ы можно красиво реализовать), размер бинаря не увеличит, ибо все разрезолвится во время компиляции. Ту же VFS сделать на базе виртуальных функций, чтобы унаследовал класс, переопределил 3 метода, вернул new MyClass(); из entry point — и VFS юзабельна. Но ведь нет — куда кошернее руками заполнять таблицы указателей и кастить inode->extension к struct my_vfs_driver_extension в каждом вызове...
Re[2]: С vs C++
От: Sheridan Россия  
Дата: 05.02.10 16:12
Оценка: 1 (1) +1
Вот и выросло поколение...
avalon 1.0rc2 rev 300, zlib 1.2.3
build date: 19.08.2009 14:13:36 MSD +04:00
Qt 4.5.2
Matrix has you...
Re: С vs C++
От: Niemand Австралия  
Дата: 29.01.10 00:13
Оценка: :))
Здравствуйте, abdul.zycor, Вы писали:

AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.


я вообще дотнетчик и скорее должен рассказывать анекдоты в КУ, чем писать сюда, но рискну предположить что прострелить ногу в условиях сервера очень больно и чтобы сделать все проще люди пишут самое критическое на си
If the message above is in English — means I'm wasting my work time and work computer to post here. No hard feelings
Re: С vs C++
От: skeptik_  
Дата: 29.01.10 09:41
Оценка: +2
Здравствуйте, abdul.zycor, Вы писали:

AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.


На дату написания смотри.
Re[3]: С vs C++
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 29.01.10 19:26
Оценка: :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.


С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[5]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 31.01.10 16:17
Оценка: :))
Здравствуйте, труженик села, Вы писали:

PD>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.


I>>Это как бы ЯВУ, на самом дело недо-ЯВУ.


ТС>Совместимость с C делает его недо-ЯВУ.


Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.

ТС>Если из него убрать все эти недо-ЯВУ, то будет Java или C#.


Совсем не обязательно.
Re[5]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 01.02.10 13:44
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

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


Не правда, я каждый день собираю код xlc 10 и ms vc 2005, совместимость отличная, есть конечно тонкости но они в основном связаны с линковкой, а у AIX-а и Винды они очень разные.

I>>>Я такую вещь заметил, что чем больше пишу на С#, тем

I>>>1 труднее переключаться на С++
I>>>2 легче писать на Си.
DC>>Что как бе намекает нам о снижении уровня... абстракции?

I>нет, дело не в уровне абстракции. в си все что надо вызывается явно. В С++ злоупотребили неявным вызовом функционала, при том что эти неявные вызовы все равно приходится контролировать.

I>Т.е. в С++ снижения уровня абстракции по факту нет.
I>В C# нет таких проблем как в с++.

В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[3]: С vs C++
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.02.10 01:45
Оценка: :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ...


недоЯВУ. Со всеми вытекающими.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: С vs C++
От: bazis1 Канада  
Дата: 02.02.10 08:14
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, труженик села, Вы писали:


PD>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.

I>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>Совместимость с C делает его недо-ЯВУ.
Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет? Код более читабелен, по сравнению с альтернативами? Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?

I>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.

Там синтаксис невменяемый.
Re[4]: С vs C++
От: Erop Россия  
Дата: 02.02.10 19:15
Оценка: +1 -1
Здравствуйте, Vamp, Вы писали:

V>Чем тебе STL-то не угодил? Где в нем опасность?

Очень легко написать очень неэффективный код. Предполагает очень умного и знающего пограммиста.
Собственно я отвечал на сообщение, где наличие STL упоминадось как недостаток С++.
Можно разработать менее кудрявый фреймворк, который будет не таким легко расширяемым и универсальным, но, зато, и не будет провоцировать написание неэффективного кода по незнанию...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: С vs C++
От: _d_m_  
Дата: 03.02.10 08:12
Оценка: -2
Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, Ikemefula, Вы писали:


I>>Здравствуйте, труженик села, Вы писали:


PD>>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.

I>>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>>Совместимость с C делает его недо-ЯВУ.
B>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

Позволяет. Но некоторые языки позволяют делать это лучше.

B>Код более читабелен, по сравнению с альтернативами?


Код читабелен? Бу-га-га
На С++ код конечно читабелен. По сравнению с Брейнфаком. Но не более.

B>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?


Ехать. Но с комфортом.
Re[5]: С vs C++
От: March_rabbit  
Дата: 03.02.10 11:32
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.


KV>>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...


I>Какой же он ЯВУ если в нем нет абстрагирования от вопросов связаных например с памятью а многие инструменты просто не работают ?

как-бы некоторый уровень абстрагирования есть. Если не изобретать ядерного реактора, то с распределением памяти не сталкиваешься.
А про инструменты: таки, может, дело в инструментописателях?
Re[12]: Слава COM!!!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 13:48
Оценка: -1 :)
Здравствуйте, Cyberax, Вы писали:

I>>Ога, а ты COM то видел ? Сравни и не пори чушь

C>Мальчик, я COM не только видел, но и ещё с нуля писал OLE-контейнер.

А по коду тобою показаному это не заметно. Это даже не смешно — самописный OLE-контейнер.
Чего ты хочешь показать на примере изобретения велосипеда ?

Ты сравнил бегемота с табуреткой. В своем примере на D-bus ты показал, что есть биндинги.
А слабо было показать биндинги для COM или твой огромный опыт написания велосипеда не включает это ?

Показать D-bus-аналог того кода, что ты привел для COM, вероятно помешала скромность
Ну да ладно, я давно в курсе что ты очень скромный.

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

IServerPtr ptr;

ptr.CreateInstance(clsid);

_bstr_t bstr = ptr->GetStuff(s);


— при том появилоь это более 12 лет назад

>>D-Bus это докомовский период

C>Посткомовский. Там исправлены кретинизмы COMа.

Посткомовский он только по дате рождения

ну и для начала надо научиться сравнивать сравниваемое, а не бегемота с табурткой.
т.е. биндинги с биндингами, отсутствие оных с отсутствием
Re[16]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 14:12
Оценка: -1 :)
C>Ну так и COM — это просто формат на таблицу методов
Ну все таки, технологии существенно разные. КОМ — это реализация объектно-ориентированной модели средствами С (что бы там не говорил Егор выше, которому с какого-то перепоя показалось, что КОМ — это С++).
Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.

Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.
Я прав?
Да здравствует мыло душистое и веревка пушистая.
Re[17]: Держи, пожалуйста, себя в рамках!
От: Vamp Россия  
Дата: 03.02.10 18:33
Оценка: -2
E>А ты перечитай моё первое сообщение, где я приводил примеры и COM в том числе
То есть, ты хотел сказать, что есть и другие реализации ООП, кроме С++? Тогда твое высказывание тривиально.
Да здравствует мыло душистое и веревка пушистая.
Re[19]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 20:01
Оценка: -1 :)
Здравствуйте, Erop, Вы писали:

E>>>Чего? Как оно нужный ::operator delete найдёт?

C>>Они forward compatible в libstdc++.
E>Ха! А если я перекрою, например?
Будешь сам себе злобный Буратино.
Sapienti sat!
Re[5]: С vs C++
От: CreatorCray  
Дата: 04.02.10 14:42
Оценка: +2
Здравствуйте, Aleх, Вы писали:

A>>>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.


CC>>В качестве лирического отступления.

CC>>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.

Настраиваемый через шаблонный параметр размер буфера это цирк.
А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?

A>Тогда причем здесь это, я же описал совершенно другой случай.

Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.

A>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.


CC>>Я уже представляю себе этот нереальный пипец в коде.

A>В чем заключается этот пипец?
В огромном шаблоне, в котором будет куча кода для реализации всех этих внутренних представлений.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[26]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.02.10 11:00
Оценка: :))
Здравствуйте, CreatorCray, Вы писали:

I>>>>Из того, с чем не работаю, примеры не привожу.

CC>>>А с С++ ты работаешь?

I>>Приходится посматривать туда.

CC>А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.

Сколько месяцев этому проекту ?
сколько релизов было ?
Сколько тестеров, колько девелоперов ?
Сколько кастомизаций/варантов деплоймента ?
Сколько раз кастомер менял требования ?
Сколько есть конкурентов у продукта ?
Re: С vs C++
От: shasa  
Дата: 05.02.10 13:47
Оценка: :))
Здравствуйте, abdul.zycor, Вы писали:
AZ> ... В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.

Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.
Re[10]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.05.10 08:26
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

HA>>Узнают о boost, когда уже нет времени учиться.

ГВ>Это как это? До пенсии всего ничего, что ли?


Бусту надо учиться, а в дотнет и джаву можно идти буквально сразу.

HA>>Время обучения потрачено непонятно на что.


ГВ>Время обучения чему?


Время обучения в университете. Бусту там не учат.
Re[22]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.05.10 18:17
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Понял. Только при чём тут сам линкер-то? Запутать можно всё, что хочешь.


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

I>>Ну так обучение, изучение оно не только в университете.


...

я тут скипнул, ни вижу смысла объяснять

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


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


I>>Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.

I>>Это значит, что если есть сложность подбора спецов, то инструмент(язык) не пригоден для использования в бизнесе.

ГВ>Это значит, что в данном случае переписали продукт с лиспа на плюсы, больше это ничего не значит.


Это уже следствие. Фишка в том, что это вынужденный шаг.

I>>1 ты тот семый чел из Яхи, которому надо сдават проект,

I>>2 лисперов у тебя нет.

ГВ>Куда они делись?


Ушли вместе с Грехемом.

I>>3 бюджет жмет


ГВ>Противоречивая ситуация: разработчиков нет, а бюджет есть. Откуда он взялся, если не ясна потребность?

>Руководство — идиоты?

А как ты хотел, сначала бюджет, а потом разработчики ? Потребность вполне ясна, цели проекта — все предельно ясно.

I>>4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала


ГВ>Почему свалили лисперы? Они сами ушли, или их выпинали?


А это неважно абсолютно. В данном случае Грехем сам продал свой бизнес.

I>>Твои действия ?


ГВ>Свалить вместе с предыдущими лисперами — идиоты не мой профиль.


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

ГВ>Хочешь более реалистичный сценарий?


ГВ>1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.


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

ГВ>2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".


ГВ>Если учесть, что именно лисперам (Грэхему с компанией) Viaweb вместе с лиспом принесли весьма неплохой доход — то откуда берутся рассуждения о том, что лисп не нужен, а паче чаяния — опасен для бизнеса? ИМХО, всё строго наоборот.


О том, что нужно мощное средство разработки, никто не спорит. Но глупо отрицать такие риски, как отсутствие специалистов.

Лисп тем и опасен своей чрезмерной зависимостью от топовых специалистов.

>Потом знаешь, "не нашли лисперов" в стране, где лисп входит в программу в/о — это что-то запредельное.


Даже в этой стране лисперов около нуля.

Вот, смотри, что сказал Грехем:

Why? Because they didn't think they'd be able to find Lisp hackers.

Re[31]: Ещё детали
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.05.10 15:59
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>...что, в общем, заставляет усомниться в том, что действительная распространённость лиспа близка к статпогрешности. Следовательно, я поторопился, говоря здесь
Автор: Геннадий Васильев
Дата: 29.05.10
:

А никто не пытался опровергать, что распространённость лиспа находится на уровне этой самой статпогрешности.


Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел

Лисп уже давно сдох, и это подтвержается тем фактом, что о нем спорят только те, для кого это максимум основной язык.
Re[26]: С vs C++
От: hattab  
Дата: 04.02.10 19:36
Оценка: 2 (1)
Здравствуйте, CreatorCray, Вы писали:

CC> Согласен с оратором, что оппоненту следует разъяснить, зачем проперти все таки так нужен в С++.


Ну, вообще, свойства это один из способов улучшения инкапсуляции, безотносительно языка. Просто еще один способ отделить интерфейс от реализации. Можно-ли обойтись без них? Разумеется. Вопрос удобства.
avalon 1.0rc2 rev 272
Re[18]: Слава COM!!!
От: EreTIk EreTIk's Box
Дата: 05.02.10 18:23
Оценка: 2 (1)
V>>Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.
C>А каким образом происходит вызов out-of-proc методов?
C>Hint: там ещё посылается оконное сообщение.

Вызов out-proc это вызов RPC. C 96-го года (Windows NT), в качестве транспорта, оконные сообщения не используются. В Windows 2k, XP и 2k3 передача основной массы данных осуществляется взаимодействием через LPC-порты. К сожалению, они синхронные, поэтому, что бы поддержать общий интерфейс асинхронных вызовов используются отсылка сообщений. Т.е. сообщения используются в качестве уведомлений.

Теперь посмотрим на Windows Vista и старше. Тут дела еще лучше — ALPC порты. В нашем контексте их основное новшество — возможность привязки IOCP (I/O Completion Ports), полностью асинхронный интерфейс и передача контекстов, в рамках одного transceiv'а. Это позволило полностью отказаться от оконных сообщений (я их там не видел, поправьте, если кто-то раскопал).
Re[10]: Слава COM!!!
От: bazis1 Канада  
Дата: 03.02.10 15:58
Оценка: 1 (1)
Здравствуйте, Vamp, Вы писали:

F>>А я как раз, было дело, руками лепил COM-интерфейс на C++.

F>>И представлял он из себя ничто иное как C++ класс, у которого все методы — виртуальные.

V>Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.

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

class CSomething : ISomething
{
public:
  HRESULT __stdcall Method1();
  HRESULT __stdcall Method2();
};

ISomething *CreateSomething()
{
  return new CSomething;
}


Дюбители "потрахаться с компилятором", безусловно, могут написать на С:
struct CSomething
{
  struct ISomething intf;
};

HRESULT __stdcall CSomething_Method1(struct CSomething *pSomething);
HRESULT __stdcall CSomething_Method2(struct CSomething *pSomething);

struct ISomething *CreateSomething()
{
  struct CSomething *p = (struct CSomething *)malloc(sizeof(struct CSomething));
  p->intf.Method1 = &CSomething_Method1;
  p->intf.Method2 = &CSomething_Method2;
  return (struct ISomething *)p;
}

Результат тот же, а писанины в 2 раза больше. Зато можно почувствовать себя "крутым перцем, пишущим на низком уровне". Детский сад, короче.
Re[4]: загадка
От: Mamut Швеция http://dmitriid.com
Дата: 08.02.10 13:58
Оценка: 1 (1)
Здравствуйте, TarasCo, Вы писали:


B>>Это может быть любой язык, поддерживающий препроцессор


TC>Ну, в общем да )). Но все же хотелось услышать конкретные предположения о языке( платформе, фреймворке ). Короче что за чудо и откуда?


гугл

http://vcc.codeplex.com/wikipage?title=Memory%20Reinterpretation

VCC is a tool that proves correctness of annotated concurrent C programs or finds problems in them. VCC extends C with design by contract features, like pre- and postcondition as well as type invariants.



dmitriid.comGitHubLinkedIn
Re[32]: Ещё детали
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.05.10 16:03
Оценка: 1 (1)
Здравствуйте, Ikemefula, Вы писали:

ГВ>>...что, в общем, заставляет усомниться в том, что действительная распространённость лиспа близка к статпогрешности. Следовательно, я поторопился, говоря здесь
Автор: Геннадий Васильев
Дата: 29.05.10
:

А никто не пытался опровергать, что распространённость лиспа находится на уровне этой самой статпогрешности.


I>Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел


I>Лисп уже давно сдох, и это подтвержается тем фактом, что о нем спорят только те, для кого это максимум неосновной язык.


Исправленому верить, накосячил с клиподм
Re: С vs C++
От: Turyst  
Дата: 29.01.10 10:35
Оценка: +1
Здравствуйте, abdul.zycor, Вы писали:

AZ>Всем привет! Не так давно стал изучать программирование для unix систем.

AZ>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.
AZ>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.
AZ>Какие могут быть обьяснения тому?
AZ>У меня такие:
AZ>Почему пишут на с:
AZ>1. в отладчике gdb приятнее видеть короткий простой код на с
AZ>2. не знают с++, поэтому пишут на с
AZ>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++
AZ>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++
AZ>5. мног окода написано уже на с, хоят и новые почему-то пишут на с

AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.


Был уже подобный спор здесь не так давно.
Re[2]: С vs C++
От: skeptik_  
Дата: 29.01.10 19:20
Оценка: +1
Здравствуйте, Vamp, Вы писали:

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


V>В С таких проблем нет.


Для этого extern C есть.
Re[4]: С vs C++
От: IID Россия  
Дата: 29.01.10 20:39
Оценка: +1
Здравствуйте, Vamp, Вы писали:

_>>Для этого extern C есть.

V>Особенно он полезен, когда в библиотеку помещаются классы.

Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано.
kalsarikännit
Re[5]: С vs C++
От: Vamp Россия  
Дата: 29.01.10 20:48
Оценка: +1
IID>Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано.
Ну это кривизна необыкновенная. Когда два С++ класса общаются между собой на C, и лишены возможностей взимодействовать с использованием возможностей С++. И то, как это сделано в ВинАПИ, кстати, есть тоже кривулина.
Да здравствует мыло душистое и веревка пушистая.
Re[2]: С vs C++
От: frogkiller Россия  
Дата: 29.01.10 21:43
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

AZ>>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.

I>Есть в с++ нечто, что рождает монстров вроде буста и стл, и благодаря им так и сложилось с серверами.

На самом деле ни буст ни стл не являются необходимым условием написания программ, даже таких хитрых, как промышленный веб-сервер. Ни что не мешает с нуля сделать свои библиотеки с преферансом и гетерами — так как это обычно делают на голом С, типичный пример apache и его apr + apr-util.

AZ>>Какие могут быть обьяснения тому?

AZ>>У меня такие:
AZ>>Почему пишут на с:
AZ>>1. в отладчике gdb приятнее видеть короткий простой код на с

на самом деле gdb довольно хорошо умеет работать и с с++.

AZ>>2. не знают с++, поэтому пишут на с


Возможно. Но тогда скорее всего пишут на "си с классами".

AZ>>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++


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

AZ>>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++


Имхо никакой разницы нет — поддержка этих языков практически одинакова.

I>нет хорошо доступных серьезных инструметов например

I>1 для рефакторинга,
I>2 отладки
I>3 анализа кода

Опять-таки ситуация с С и С++ в этом плане практически одинакова. И она не является препятствием для написания серверов

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


И опять-таки это не важно для выбора C vs C++
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[11]: С vs C++
От: zaufi Земля  
Дата: 02.02.10 07:33
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, CreatorCray, Вы писали:


I>>>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

DC>>>>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.
I>>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
CC>>Ну дык не смотри больше на хреновый код.

I>Какой пишут на такой и смотрю. При чем пишут люди, которые во всю ругают индусокод. Так шта...

это что у нас теперьь новое мерило для "проффесианализма"??? начал ругать индусокод, значит мега профессионал?
вместо того чтоб ругать взяли бы да исправили раз такие умные...
---
а кроссплатформенные проекты с минимумом макросов оч даже возможны... видел и делал такие... причем не однократно.
Re[11]: С vs C++
От: CreatorCray  
Дата: 02.02.10 08:11
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>При чем пишут люди, которые во всю ругают индусокод.

Честно говоря мне не известны люди, которые бы хвалили индусокод.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[12]: С vs C++
От: Mr.Cat  
Дата: 02.02.10 15:45
Оценка: +1
Здравствуйте, dr.Chaos, Вы писали:
DC>Goroutines мапятся на реальные нити, но как — хз, только рантайм знает . Не думаю что сборка мусора будет большой проблемой.
Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?
Re[13]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.02.10 17:17
Оценка: :)
Здравствуйте, Mr.Cat, Вы писали:

MC>Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?


Рантайм пусть делат, главное что бы не было необходимости это контролировать.

А то в с++ приходится явно контролировать неявное
Re[8]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 00:05
Оценка: +1
Здравствуйте, Vamp, Вы писали:

V>При том, что тот тоже мечтал о несбыточном.

Если ты не понял, то при чём тут несбыточное?

V>Декорирование имен не входит в стандарт. Хорошо это или плохо — я не знаю. Наверное, плохо, но по-другому не выходит, потому что стандарт такими вещами не занимается.

Да и пусть себе не входит. Вот если в Линуксе появится С++ API, в котором будет заданы правила декорирования, то все компиляторы под линукс легко смогут приделать опцию "придерживаться этих правил"...

V>Во-во. Как бы ты взаимодействовал с этим кодом из С? Который декорировать не умеет никак?

Через переходники.
Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься. И ничего, живут себе люди...
К .net тоже без управляемых заморок не подлезешь, а ничего, зовут, если надо и из неуправляемого кода...
GDI+, опять же...

E>>Ну COM под виндой, например, знаешь?

V>КОМ к С++ никакого отношения не имеет. Так же как и к виртуальным функциям.
Ну вот COM под виндой -- это пример того, как взяли в системе, да и стандаритизировали, фактически, то, как таблица виртуальных функций должна выглядеть. И ничего, всё у них получилось. Все компиллеры С++ под винду это дело поддержали...

А ведь декорирование имён -- это намного менее чувствительное место в компиляторе, чем реализация виртуальности...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 00:21
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Да и пусть себе не входит. Вот если в Линуксе появится С++ API, в котором будет заданы правила декорирования, то все компиляторы под линукс легко смогут приделать опцию "придерживаться этих правил"...

Стандарт де-факто — это gcc. Он достаточно backward compatible и его эмулирует icc.

Более того, он даже кодифицирован: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling

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

Есть стандартизованный D-BUS. Прямой аналог COM, в общем.
Sapienti sat!
Re[8]: Слава COM!!!
От: filkov СССР  
Дата: 03.02.10 00:40
Оценка: +1
Здравствуйте, Vamp, Вы писали:

V>КОМ к С++ никакого отношения не имеет. Так же как и к виртуальным функциям.


Странно.
А я как раз, было дело, руками лепил COM-интерфейс на C++.
И представлял он из себя ничто иное как C++ класс, у которого все методы — виртуальные.

Ну, как здесь, примерно, излагается:

It is no coincidence that the Win32 COM object layout matches closely the C++ object layout
The Win32 COM calling convention specifies the layout of the virtual method table (vtable) of an object

Санкционный Смотритель.
Re[10]: Слава COM!!!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 07:32
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

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

C>Есть стандартизованный D-BUS. Прямой аналог COM, в общем.

Ога, а ты COM то видел ? Сравни и не пори чушь

COM

BOOL b;
BSTR bstr;

HRESULT hr = pSomePtr->GetStuff(&b,&bstr);

if(SUCCEEDED(hr))
{
 ...
}



D-BUS

gboolean boolret;
  char *strret;
  
  error = NULL;
  if (!dbus_g_proxy_call (proxy, "GetStuff", &error,
              G_TYPE_INVALID,
                          G_TYPE_BOOLEAN, &boolret,
                          G_TYPE_STRING, &strret,
              G_TYPE_INVALID))
    {
      /* Handle error */
    }
  printf ("%s %s", boolret ? "TRUE" : "FALSE", strret);
  g_free (strret);


D-Bus это докомовский период
Re[10]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 11:46
Оценка: :)
Здравствуйте, March_rabbit, Вы писали:

DC>>>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.


I>>А я не про ваш код говорю, а про тот, который мне довелось видеть.

M_>неплохая причина ругать язык

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

Это только один из примеров.
Re[10]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 13:58
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

I>>>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.

CC>>>Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?

I>>Я не сильно слежу за ассистом. он умеет ли он (2005я)

CC>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

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

А что ассист то поддерживает из приведеного списка ?

I>>Помнится, один наш общий знакомый вещал что "не пользуемся рефакторингом потому что архитектура идеальная "

CC>Я пользуюсь refactor rename, create implementation, create declaration, extract method
CC>Вроде как всё.

этого мягко говоря мало.
Re[13]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 14:01
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>>>Ога, а ты COM то видел ? Сравни и не пори чушь

C>>Мальчик, я COM не только видел, но и ещё с нуля писал OLE-контейнер.
I>А по коду тобою показаному это не заметно. Это даже не смешно — самописный OLE-контейнер.
I>Чего ты хочешь показать на примере изобретения велосипеда ?
Нет, так как существующие контейнеры были недостаточны.

I>Ты сравнил бегемота с табуреткой. В своем примере на D-bus ты показал, что есть биндинги.

I>А слабо было показать биндинги для COM или твой огромный опыт написания велосипеда не включает это ?
Я лично всегда использую Comet:
    comet::bstr_t appID("SD");
    comet::bstr_t appName("StaffDirector Application");
    comet::bstr_t ticket;

    comet::QBXMLRPLib::IRequestProcessor2Ptr rqPtr(comet::QBXMLRPLib::RequestProcessor::create());
    rqPtr ->OpenConnection(appID, appName);
    // begin session
    ticket = rqPtr ->BeginSession(argv[1], comet::QBXMLRPLib::qbFileOpenDoNotCare);


I>Показать D-bus-аналог того кода, что ты привел для COM, вероятно помешала скромность

I>Ну да ладно, я давно в курсе что ты очень скромный.
То есть? Что именно нужно показать?

I>

I>IServerPtr ptr;
I>ptr.CreateInstance(clsid);
I>_bstr_t bstr = ptr->GetStuff(s);

I>- при том появилоь это более 12 лет назад
А теперь попробуй передать в метод карту. Как будешь её представлять? В виде двумерного SAFEARRAY (для которого в ATL нет нормальных байндингов)? А что будем делать с асинхронными вызовами (AKA посылка сообщений)? Напомнить какой это геморрой в COM?

А как насчёт out-of-proc серверов, напомнить кретинизм с их активацией, маршаллингом, ROT и прочими радостями?

>>>D-Bus это докомовский период

C>>Посткомовский. Там исправлены кретинизмы COMа.
I>Посткомовский он только по дате рождения
Нет, ещё и по удобсвту использования. Но тебе не понять, у тебя мозг вынул и выбросил сертефицированный представитель Microsoft.

В общем, твой тезис о том, что в Линуксе нет COM — банально неверен.
Sapienti sat!
Re[14]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 14:03
Оценка: :)
Вопрос имею.
А разве D-BUS — это не просто шина сообщений?
Да здравствует мыло душистое и веревка пушистая.
Re[7]: С vs C++
От: _wqwa США  
Дата: 03.02.10 14:07
Оценка: +1
Здравствуйте, denisko, Вы писали:


I>>Objective-C тоже совместим с С, но при этом он настоящий ЯВУ.


D>Вы еще дрочите на мак? Тогда мы идем к Вам. Ты на нем хоть что нибудь писал, интересно?

Ну я писал, и тоже так считаю. Какие Ваши аргументы?
Кто здесь?!
Re[14]: Слава COM!!!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 14:40
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

I>>Показать D-bus-аналог того кода, что ты привел для COM, вероятно помешала скромность

I>>Ну да ладно, я давно в курсе что ты очень скромный.
C>То есть? Что именно нужно показать?

А что мешало это разу сделать ? Вместо этого ты нагородил какой то бред с IDispatch

I>>

I>>IServerPtr ptr;
I>>ptr.CreateInstance(clsid);
I>>_bstr_t bstr = ptr->GetStuff(s);

I>>- при том появилоь это более 12 лет назад
C>А теперь попробуй передать в метод карту. Как будешь её представлять? В виде двумерного SAFEARRAY (для которого в ATL нет нормальных байндингов)? А что будем делать с асинхронными вызовами (AKA посылка сообщений)? Напомнить какой это геморрой в COM?

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

C>А как насчёт out-of-proc серверов, напомнить кретинизм с их активацией, маршаллингом, ROT и прочими радостями?


все это _было_

C>Нет, ещё и по удобсвту использования. Но тебе не понять, у тебя мозг вынул и выбросил сертефицированный представитель Microsoft.

C>В общем, твой тезис о том, что в Линуксе нет COM — банально неверен.

На виндовсе COM имеет отличную поддержку и на .Net и в Delphi том же, а в линуксе это yet another ipc.

Вот когда D-bus дорастет до стандарта, как это было с COM, тогда и поговорим.
Re[12]: Слава COM!!!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 14:42
Оценка: :)
Здравствуйте, elmal, Вы писали:

I>>D-Bus это докомовский период

E>А тебе не кажется, что независимо от простейшего Hello DBUS и Hello COM, все эти вызовы прекрасно оборачиваются в одном методе, интерфейс которого можно подобрать так, что с ним будет достаточно удобно работать. И что вызо функции через COM, что через DBUS — в реальном коде все будет занимать одну простую строчку. Вернее скорее всего 2, одна — получение интерфейса, и вторая — вызов метода этого интерфейса. Или же планируется, что всем эти будут пользоваться индусы, которым платят за количество строчек кода?

COM в первую очередь это стандарт а не "yet another ipc"

Соответсвенно, как стандарт, имеет отличную поддержку в .Net
Re[15]: С vs C++
От: Vamp Россия  
Дата: 03.02.10 15:11
Оценка: +1
V>>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

I>За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов

Геттеры и сеттеры не нужны. Вообще. Приведи пример простого класса, для которого ты считаешь нужными property, и я покажу тебе, почему без них лучше.
Да здравствует мыло душистое и веревка пушистая.
Re[11]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 16:03
Оценка: -1
B>COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:

Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.
Да здравствует мыло душистое и веревка пушистая.
Re[13]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 16:30
Оценка: :)
B>Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.
Сдается мне, ты вообще не понимаешь, о чем идет речь в это дискуссии.
Да здравствует мыло душистое и веревка пушистая.
Re[11]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 17:19
Оценка: :)
E>И, тем не менее, из С++ COM-интерфейс виден, как объект с кучей виртуальных методов...
Нет. Только при использовании биндингов. Сам по себе он сишный.

E>Из любой реализации под С++ под винду, обрати внимание

Потому, что он сишный.
Да здравствует мыло душистое и веревка пушистая.
Re[11]: Слава COM!!!
От: LuciferSaratov Россия  
Дата: 03.02.10 18:18
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, LuciferSaratov, Вы писали:


E>>>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.

LS>>Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.

E>А ты ей пользовался? Я вот пользовался. Всё равно удобно иметь кусок на Objective-C, на самом деле.


Удобно, кто бы спорил.

E>Для связи с C++ объектами тоже можно аналогичную библиотеку написать...


Для С++ можно написать, а там уже есть.
Re[15]: С vs C++
От: Vamp Россия  
Дата: 03.02.10 19:10
Оценка: -1
MK>А что в них уродливого?
Все.
Да здравствует мыло душистое и веревка пушистая.
Re[19]: Держи, пожалуйста, себя в рамках!
От: Vamp Россия  
Дата: 03.02.10 19:15
Оценка: :)
E>То что я хотел сказать, я сказал уже много раз.

Проблемы с декорайией С++ имён не так страшны, чтобы помешать использовать С++ в качестве языка части API OS


Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.
Да здравствует мыло душистое и веревка пушистая.
Re[23]: Держи, пожалуйста, себя в рамках!
От: Vamp Россия  
Дата: 03.02.10 20:06
Оценка: :)
E>Я не утверждаю, что COM на С++ написан или на него ориентирован. Я всего лишь утверждаю, что он задал формат таблиц виртуальных функций под винду...
Твое утверждение необоснованно.
Да здравствует мыло душистое и веревка пушистая.
Re[18]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 10:47
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Ikemefula, Вы писали:


I>>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение

CC>Дык существенная часть того что там он умеет для С++ попросту нафиг не нужно.

Отчасти это верно, потому что С++ уже вытеснен в дотаточно узкую нишу.

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

Хочешь выделить небольшую фичу в отдельную подсистему — добро пожаловать в ад на с++.
Хочешь интегрировать одну подсистему в другую — обратно тоже самое.
ну или придетя доказывать чего то кастомеру, что у него плохие идеи
Re[19]: С vs C++
От: CreatorCray  
Дата: 04.02.10 11:30
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>>>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение

CC>>Дык существенная часть того что там он умеет для С++ попросту нафиг не нужно.

I>Отчасти это верно, потому что С++ уже вытеснен в дотаточно узкую нишу.

Твои фантазии касательно ниши С++ (и сопутствующий им флейм) оставим в стороне.

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

Это какое отношение имеет к обсуждению фич средств рефакторинга для С++?

I>Хочешь выделить небольшую фичу в отдельную подсистему — добро пожаловать в ад на с++.

Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[17]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 04.02.10 11:53
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Вот есть задача или изменение имеющейся архитектуры под новые требования.


I>Есть куча кода, который исправно работал где то с 2003го года, а сейчас появились новые требования для него.


I>Или такая задача — упрощения имеющегося кода.


И для этого мы, видимо, выделяем метод аж в целый класс .

I>Можно, конечно, подойти по понЭрски — все переписать заново, с нуля или около того.




I>Но гораздо проще, быстре и надежнее будет сделать рефакторинг.


I>Практически везде нужно


I>1. выделение базового класса/интерфейса

I>2. перемещение методов по иерархии
I>3. использование базового класса

Ну да, у нас же нет свободных функций, нам везде классы лепить надо.

I>еще очень сильно не хватает "преобразование метода в класс"

I>и вообще очень много чего не хватает

I>при этом Решарпер предоставляет много средств которые не показыны в меню что я привел, например создание наследника, генерацию конструкторов и многое другое


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

I>заметь — выделение метода я упомянул только здесь.


CC>>Ты не меряй то, что надо для шарпа на плюсы.


I>Рефакторинг нужен независимо от языка.


I>В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер потому ты их там и не видишь.

Самое мощьное средство рефакторинга программист и если ему для написания кода нужна графическая штамповалка boilerplate кода, то либо что=то не так с языком, либо программист что-то не так делает.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[18]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 12:17
Оценка: :)
Здравствуйте, dr.Chaos, Вы писали:

I>>Есть куча кода, который исправно работал где то с 2003го года, а сейчас появились новые требования для него.

I>>Или такая задача — упрощения имеющегося кода.

DC>И для этого мы, видимо, выделяем метод аж в целый класс .


Упрощением может быть преобразование метода в класс, а может и наоборот, класса в метод.

I>>Можно, конечно, подойти по понЭрски — все переписать заново, с нуля или около того.


DC>


I>>Но гораздо проще, быстре и надежнее будет сделать рефакторинг.


I>>Практически везде нужно


I>>1. выделение базового класса/интерфейса

I>>2. перемещение методов по иерархии
I>>3. использование базового класса

DC> Ну да, у нас же нет свободных функций, нам везде классы лепить надо.


свободные функции это каменный век.

DC>Я вообще придерживаюсь мнения, что biolerplate код должен убираться, а не плодиться с использованием мегакрутого решарпера.


он и убирается. при чем оставшийся код приводится к легко понятной форме

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


функции это круто. а как на счет подсистем над которыми работали десятки девелоперов в течении многих лет ?

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

I>>В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер потому ты их там и не видишь.

DC>Самое мощьное средство рефакторинга программист и если ему для написания кода нужна графическая штамповалка boilerplate кода, то либо что=то не так с языком, либо программист что-то не так делает.

Хорошему программисту лишний инструмент не помеха.
Re[23]: С vs C++
От: CreatorCray  
Дата: 04.02.10 14:42
Оценка: +1
Здравствуйте, MxKazan, Вы писали:

MK>Так чего тогда плюсовал слившему товарищу?

Ты о чём конкретно?

MK> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.

Если ты ничего не понял то лучше бы спросил.

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

Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.
На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.

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

Мьсе потрудится привести пруфлинк?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[26]: С vs C++
От: Vamp Россия  
Дата: 04.02.10 15:43
Оценка: +1
CC>Согласен с оратором, что оппоненту следует разъяснить, зачем проперти все таки так нужен в С++.
Причем без отсылки к шарповским библиотекам.
Да здравствует мыло душистое и веревка пушистая.
Re[8]: С vs C++
От: Aleх  
Дата: 04.02.10 16:16
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Aleх, Вы писали:


A>>>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.

CC>>>Настраиваемый через шаблонный параметр размер буфера это цирк.
CC>>>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?

A>>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.

A>>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.

CC>А не проще ли будет ускорить реально тормозящее место во всех реализациях строки — прикрутить к строке быстрый кастомный аллокатор?

Можно и так, если это позволит достичь желаемых результатов. Но все равно подход останется тем же — аллокатор будет передаваться в качестве параметра шаблона.
CC>Считай это подсказкой направления.

A>>>>Тогда причем здесь это, я же описал совершенно другой случай.

CC>>>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
CC>>>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.

A>>Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.

CC>Hint: дело не в командах проца а в работе кэша.
И что? кеш это часть процессора. и про команды я ничего не писал.

A>>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.

CC>Для людей, пишущих в стиле Александреску, на одном из моих предыдущих мест работы появился термин "укушенный Александреску".
CC>Ибо человек, постигший Александреску-дзэн поначалу начинает писать на шаблонах всё. В прямом смысле, вообще всё.
CC>А потом приходит пушистый северный зверёк в виде черепашьей скорости компиляции и (да, бывает и такое!) compiler limits.
Конечно, нужно знать меру, но вообще избегать шаблонов и особенно считать, что они не нужны совсем (как считают, например, оберонщики ) тоже не стоит.
Re[7]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 05.02.10 08:44
Оценка: +1
Здравствуйте, Aleх, Вы писали:

A>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.

A>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
A>>>Тогда причем здесь это, я же описал совершенно другой случай.
Ничем он особо не лучше: от параметров шаблонов пухнет страшно код, да и засунуть 2 такие строки в один массив целая проблема. Т.е. Здесть возможно даже аллокатор стоит делать не параметром шаблона, а параметром конструктора.

A>>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.


A>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.


Скажем по другому: чем это лучше 5ти классов map, map_double_hashing и т.д. с одним интерфейсом? Допустим параметразовать можно было бы хеш функцией, но все эти 5 реализаций карты очень различаются и найти что-то общее в рамках одной реализации тут ИМХО будет сложнее, да и смысл?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[27]: С vs C++
От: CreatorCray  
Дата: 05.02.10 11:04
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>>>Приходится посматривать туда.

CC>>А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.

I>Сколько месяцев этому проекту ?

I>сколько релизов было ?
I>Сколько тестеров, колько девелоперов ?
I>Сколько кастомизаций/варантов деплоймента ?
I>Сколько раз кастомер менял требования ?
I>Сколько есть конкурентов у продукта ?

Может тебе еще и номера счетов и пароли к SVN написать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[37]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 05.02.10 16:02
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?


I>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?


А какое это имеет отношение к рефакторингам Кириевски? Кириевски написал — все должны делать. ёпт!
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[38]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.02.10 16:29
Оценка: :)
Здравствуйте, Mr.Cat, Вы писали:

I>>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

MC>Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. А вот судьба нынешнего мейнстрима предрешена: c#,java ждет судьба кобола, питон — в самом лучшем случае судьба tcl.

Пусть развивается. Он за пределами стат-погршности, всего то.

Нужен интрумент для решения текущих задач бизнеса, а Лисп — нет, не нужен.

I>>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

MC>Набрали команду инди-кодеров, продолбали все полиме^W акции и превратились в моральных пигмеев?

Нет, они нашли инструмент, который решил их задачи.
Re[42]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 09.02.10 18:54
Оценка: +1
Здравствуйте, Mr.Cat, Вы писали:

MC>Извини, я не смог уловить смысла этого высказывания.

Он довольно часто выражается в стиле Черномырдина .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[4]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.02.10 06:57
Оценка: :)
Здравствуйте, Head Ache, Вы писали:

HA>Я бы разделил программистов на 2 группы:

HA>первая — уже поняли, что STL (и boost, и ему подобные расширения) не имеют альтернативы в других языках
HA>вторая — мне их жалко...

Чуток наоборот, первая — это челы понимают, что без stl или boost за другими языками не угнаться даже при правильном ветре.
Re[2]: Тоже мне удивил ;)
От: Erop Россия  
Дата: 25.02.10 10:39
Оценка: +1
Здравствуйте, trop, Вы писали:

T>ядро vxworks имеет статистику более 30 лет

T>и поэтому считается наиболее отказоустойчивой осрв

Не, ну если у вас есть унаследованный код 30-летней давности, то точно лучше ничего не менять, пока работает
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: С vs C++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 23.05.10 22:08
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

I>Мощь есть, это так. Только что бы эта мощь не задавила программиста, надо вагон времени убить, года три, не меньше.


То есть?

I>Сейчас например найти чела, который умеет шаблоны С++ на уровне достаточном для буст или хотя бы стл крайне сложно.


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

I>Еще лет 5 назад было гораздо проще.


Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.05.10 10:41
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не понял. На что нужно потратить три года? На буст? Чепуха. На C++? Тоже преувеличение — года вполне достаточно, а базовый язык вообще осваивается за несколько месяцев. Чему нужно три года учиться?


На с++, шаблоны и буст нужно примерно 3 года, в промышленной разработке разумеется.

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

ГВ>>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

I>>За 5 лет С++ подрястерял позиции, а студенты в основном джавой и дотнетом интересуются.

ГВ>Дык, дело-то, наверное, как раз в этом, а не в какой-то гиперсложности использования буста.


Гиперсложности не нужно. Достаточно, что бы на рынке был продукт попроще, доступнее, прозрачнее при сравнимых возможностях.

Раньше например джава была но люди интересовались с++. У нас например чуть не весь поток такой был.

С++ сам по себе геморрой, а буст достаточно сложен для начинающего.

Я знаю случаи, когда люди в нормальных проектах выкашивали оный буст из за того, что не хватало знаний побороть трудноуловимые баги.
Re[16]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.05.10 13:31
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Упс. Не, ну это полный ништяк. Программист, который не понимает, что такое сопоставление символического имени блоку бинарного кода — это анекдот (я в курсе, что их много есть, менее анекдотичными они от этого не становятся). Собственно, этих, альтернативно одарённых, я в расчёт не беру. А в противном случае, линковку как-то особенно "понимать" никакой нужды нет.


При чем здесь понимание линковки ? Речь о практическх навыках работы с линкером. И линкер это не единственная проблема.

I>>Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.


ГВ>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...


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

В С++ во первых, средства рефакторинга слабее, во вторых, компиляция слишком долгая.

Кроме того, в С++ затруднено юниттестирование, написание моков.

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


ГВ>Я говорю "шугаться", поскольку был свидетелем такого "шугания" — даже приходилось по требованию заказчика (внимание — хи-хи) кромсать буст, чтобы не "пугать программистов". Идиотизма ситуации это не отменяет, но зато какая основа для положительных эмоций!


Я сильно понимаю этого заказчика — буст увеличивает зависимость от человеческого фактора.

Если не дай бог он не сможет найти вторую такую же команду, то придется выкидывать или гору денег или похоронить проект.
Re[20]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.05.10 06:54
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?

I>>Например в структуре проектов, в настройках оных проектов и тд. В итоге задача подключить либу чатенько растягивается на неделю.

ГВ>А ты уверен, что причина именно в сложности понимания работы линкера? Может, дело в чём-то сильно-сильно другом?


Цитирую себя про сложность "При чем здесь понимание линковки ? Речь о практическх навыках работы с линкером."

и еще

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

I>>Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.


ГВ>Знамо дело, не смешно. Не знать, что такое редактирование связей, да ещё нарваться на lnk2005 — можно только посочувствовать.


Что интересно, сиплюсники с большим опытом ничем не смогли мне помочь когда был затык почти на неделю из за линкера. Все стандартные рецепты не помогли.

I>>Это зависит от проекта, а не от ученика.


ГВ>Это я понимаю, знаешь ли. Я никак не соображу, как связать "большой проект" с "учебными программами". Наверное, я старомоден.


Ну так обучение, изучение оно не только в университете.

I>>Да, это все оно же. Моки, тесты снижают порог вхождения в проект/фреймворк.



ГВ>1) написать саму такую программу,

ГВ>2) понять, что происходит, "поиграться" с кодом, объяснить результаты.
ГВ>1.1) написать формальный код вызовов,
ГВ>1.2) наполнить формальный код функциональностью. Мокогенератор может помочь на стадии 1.1, плюс, (возможно), на 1.2.
ГВ>Вопос: как относятся (1.1 + часть 1.2) к (1+2)?

Если только написать и поиграться, то тесты не нужны вовсе

ГВ>Резюмирую: я не против мокогенерации самой по себе, как части обучения, но я не согласен с тем, что она значительно влияет на скорость обучения.


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

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


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

ГВ>>>[...] А буст вообще частью уже перекочевал в стандарт.

I>>Что с того что он в стандарте ? Его изучать чтоли не нужно ?

ГВ>Глупо от него отказываться, тем более, объясняя это трудностями поиска программистов.


Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.

Это значит, что если есть сложность подбора спецов, то инструмент(язык) не пригоден для использования в бизнесе.

Вот представь себе,

1 ты тот семый чел из Яхи, которому надо сдават проект,
2 лисперов у тебя нет.
3 бюджет жмет
4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала

Твои действия ?
Re[21]: С vs C++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.10 14:59
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

ГВ>>А ты уверен, что причина именно в сложности понимания работы линкера? Может, дело в чём-то сильно-сильно другом?

I>Цитирую себя про сложность "При чем здесь понимание линковки ? Речь о практическх навыках работы с линкером."
I>и еще
I>"Например в структуре проектов, в настройках оных проектов и тд. В итоге задача подключить либу чатенько растягивается на неделю."

Понял. Только при чём тут сам линкер-то? Запутать можно всё, что хочешь.

I>>>Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.

ГВ>>Знамо дело, не смешно. Не знать, что такое редактирование связей, да ещё нарваться на lnk2005 — можно только посочувствовать.
I>Что интересно, сиплюсники с большим опытом ничем не смогли мне помочь когда был затык почти на неделю из за линкера. Все стандартные рецепты не помогли.

Ну, плохо. Сочувствую. Хотя я часто язвлю в таких случаях: "Не смогли, или не захотели?"

I>>>Это зависит от проекта, а не от ученика.

ГВ>>Это я понимаю, знаешь ли. Я никак не соображу, как связать "большой проект" с "учебными программами". Наверное, я старомоден.
I>Ну так обучение, изучение оно не только в университете.

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

Короче, у тебя тут куча разрозненных фактов, смешанных чёрт-те как. Пудри мозги кому-нибудь другому, а?

I>>>Да, это все оно же. Моки, тесты снижают порог вхождения в проект/фреймворк.


ГВ>>1) написать саму такую программу,

ГВ>>2) понять, что происходит, "поиграться" с кодом, объяснить результаты.
ГВ>>1.1) написать формальный код вызовов,
ГВ>>1.2) наполнить формальный код функциональностью. Мокогенератор может помочь на стадии 1.1, плюс, (возможно), на 1.2.
ГВ>>Вопос: как относятся (1.1 + часть 1.2) к (1+2)?

I>Если только написать и поиграться, то тесты не нужны вовсе


Назови хоть груздём.

ГВ>>Резюмирую: я не против мокогенерации самой по себе, как части обучения, но я не согласен с тем, что она значительно влияет на скорость обучения.

I>Если есть тесты, новичек может поиграться с кодом, который писался группой серьезных девелоперов.

Так всё же, тесты "не нужны", или "нужны"? Полезны или нет? Давай, ты сделашь дефрагментацию своих тезисов? Потом, если тесты написаны опытными девелоперами, то откуда берётся влияние мокогенератора? Тесты-то уже есть!

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

I>Это же неудобно — рыться где то, искать и тд. Так все в одном солюшне, получаешь целый полигон для испытаний в одном флаконе.

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

ГВ>>>>[...] А буст вообще частью уже перекочевал в стандарт.

I>>>Что с того что он в стандарте ? Его изучать чтоли не нужно ?

ГВ>>Глупо от него отказываться, тем более, объясняя это трудностями поиска программистов.


I>Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.

I>Это значит, что если есть сложность подбора спецов, то инструмент(язык) не пригоден для использования в бизнесе.

Это значит, что в данном случае переписали продукт с лиспа на плюсы, больше это ничего не значит.

I>Вот представь себе,


Ха-ха, пофантазируем.

I>1 ты тот семый чел из Яхи, которому надо сдават проект,

I>2 лисперов у тебя нет.

Куда они делись?

I>3 бюджет жмет


Противоречивая ситуация: разработчиков нет, а бюджет есть. Откуда он взялся, если не ясна потребность? Руководство — идиоты?

I>4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала


Почему свалили лисперы? Они сами ушли, или их выпинали?

I>Твои действия ?


Свалить вместе с предыдущими лисперами — идиоты не мой профиль.

Хочешь более реалистичный сценарий?

1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.
2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".

Если учесть, что именно лисперам (Грэхему с компанией) Viaweb вместе с лиспом принесли весьма неплохой доход — то откуда берутся рассуждения о том, что лисп не нужен, а паче чаяния — опасен для бизнеса? ИМХО, всё строго наоборот. Потом знаешь, "не нашли лисперов" в стране, где лисп входит в программу в/о — это что-то запредельное.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: С vs C++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.10 20:33
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

ГВ>>Понял. Только при чём тут сам линкер-то? Запутать можно всё, что хочешь.

I>Наличие линкера это лишняя сложность, это так или иначе придется освоить, при чем это чисто балласт.

Вот с этого и надо начинать. Что это просто "дополнительное что-то". Правда, вполне очевидно используемое, но не мышкой, а это "сложно".

I>>>Ну так обучение, изучение оно не только в университете.

I>...
I>я тут скипнул, ни вижу смысла объяснять

Хорошо, слив засчитан. Молодняк мне твой жалко, конечно, но что поделаешь...

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

I>Скачай и открой например Moq. Сам все увидишь. Не увидишь, значит смысла говорить не о чем, ибо мнения слишком полярны.

Ну, я уже понял, что согласованость посылок — ничто. Главное — что C++-отстой, лисп — опасность.

I>>>Есть хороший пример про Лисп и Яху. Челы не смогли найти второго Грехема, не смогли укомплектовать комманду и в итоге вынуждены были выбросить Лисп и переписали проект на плюсах.

I>>>Это значит, что если есть сложность подбора спецов, то инструмент(язык) не пригоден для использования в бизнесе.
ГВ>>Это значит, что в данном случае переписали продукт с лиспа на плюсы, больше это ничего не значит.

I>Это уже следствие. Фишка в том, что это вынужденный шаг.


Я одного не понимаю, как можно называть "непригодным для использования в бизнесе" инструмент, благодаря которому появился столь успешный продукт? 1 == 0? Эти люди допущены к обучению молодых, с такой-то кашей в голове. O tempora, o mores!

I>>>1 ты тот семый чел из Яхи, которому надо сдават проект,

I>>>2 лисперов у тебя нет.
ГВ>>Куда они делись?
I>Ушли вместе с Грехемом.

Угу, ну ладно. Испарились. Ну, бывает.

I>>>3 бюджет жмет

ГВ>>Противоречивая ситуация: разработчиков нет, а бюджет есть. Откуда он взялся, если не ясна потребность?
>>Руководство — идиоты?
I>А как ты хотел, сначала бюджет, а потом разработчики ? Потребность вполне ясна, цели проекта — все предельно ясно.

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

I>>>4 сроки жмут — бизнес яхи несет убытки из за отсутствия функционала

ГВ>>Почему свалили лисперы? Они сами ушли, или их выпинали?
I>А это неважно абсолютно. В данном случае Грехем сам продал свой бизнес.

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

I>>>Твои действия ?

ГВ>>Свалить вместе с предыдущими лисперами — идиоты не мой профиль.
I>У человека, который решит продвигать этот проект, выбора вобщем то нет — нужно работать с теми кто есть, т.е. с тем, кого можно нанять в разумный срок.

Если это топ-менеджмент Yahoo, принявший решение о покупке сервиса — тогда логика вполне ясна. Компания купила проект, ключевые специалисты свалили. Что делать? Отдали проект своим специалистам, а кому ещё? Те оказались перед дилеммой: изучать лисп, либо переписать всё на привычном языке. Изучить лисп, наверное, было бы прикольно, только, подозреваю, никаких пряников за это им бы не обломилось — всего лишь, ещё один "спасённый" проект. Следовательно — переписываем! Специалисты радостно потирают руки, руководство получает сценарий к действию, неопределённость преодолена, все довольны. Я уверен почти на 100%, что цена переписывания при любых раскладах была не сопоставима с ценой покупки продукта, а цена покупки вряд ли создала критическую нагрузку на бюджет самой Yahoo. Следовательно — без лишнего шума переписали на том, на чём захотели. Были бы джависты — переписали бы на Java. Бюджет на переписывание всё равно отстегнули бы ровно тот, который нужен, а иначе вся покупка — коту под хвост. Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет. А тут можно начинать действовать прямо сейчас.

То есть вся эта ситуация никоим образом не бросает тень на сам лисп. Напротив: не будь лиспа, Грэм не заработал бы свои сколько-то там в шестой степени. У Грэма получился очень успешный бизнес. Yahoo тоже от этого не проиграла.

Ну а ситуация, к которой ты клонишь: "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов" — это полный абсурд.

ГВ>>Хочешь более реалистичный сценарий?

ГВ>>1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.
I>Разумется они предполагали это. Только С++ не от балды взяли, а посчитали риски, затраты и тд.

Ты вторую часть моего предложения прочёл?

ГВ>>2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".

ГВ>>Если учесть, что именно лисперам (Грэхему с компанией) Viaweb вместе с лиспом принесли весьма неплохой доход — то откуда берутся рассуждения о том, что лисп не нужен, а паче чаяния — опасен для бизнеса? ИМХО, всё строго наоборот.
I>О том, что нужно мощное средство разработки, никто не спорит. Но глупо отрицать такие риски, как отсутствие специалистов.
I>Лисп тем и опасен своей чрезмерной зависимостью от топовых специалистов.

Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир. У Yahoo — тоже никаких особых рисков, переписала и не развалилась. А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.

Потом знаешь, был бы топовый специалист — а зависимость от него всегда сложится, не зависимо от языка программирования. Почитай недавние истории от того же мыщъха — он тоже один из топовых специалистов в своей области. Что теперь? C — тоже плохой?

>>Потом знаешь, "не нашли лисперов" в стране, где лисп входит в программу в/о — это что-то запредельное.

I>Даже в этой стране лисперов около нуля.
I>Вот, смотри, что сказал Грехем:

I>

I>Why? Because they didn't think they'd be able to find Lisp hackers.


Внимательно всматриваемся в выделенное. Чем отличается hacker от "просто программиста"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.05.10 20:00
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

I>>>>я тут скипнул, ни вижу смысла объяснять

ГВ>>>Хорошо, слив засчитан.
I>>Ай, умно выпендрился, и, главное, оригинально

ГВ>Заметь, я был вторым.


Ну да, это ведь я про слив написал твоей рукой, ага

I>>Предствь себе, это решаю люди которые изучали лисп в университете. Именно они отказываются от лиспа в пользу с++.


ГВ>Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?


Да вобщем то Лисп изучают не только в Мит, а в подавляющем большинстве серьезных технических вузов.

I>>Грехем продал проект, а не программистов. Вроде все ясно


ГВ>Допустим. Что это меняет? Из моих рассуждений выпадает ровно одно звено — про пребывание Грэма в Yahoo.


Да ладн

I>>Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.


ГВ>Почему странная? Привычный язык на то и привычный. Потом, ты же знаешь корпоративную этику: а себя работой обеспечить? Так что, дилемма, подозреваю, не настолько сильная.




>>>Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.

I>>Именно это и вносит огромные риски.

ГВ>Обрати внимание — речь идёт о талантах, а не о "рядовых лисповиках". Пнимаешь, проблема в том, что рядовые — они везде рядовые, что на лиспе, что на бейсике. Это, если грубо, способ мышления.


Рядовых лисперов тоже мало. Потому в любом случае,уже просто потому, что Лисп это будет " игра без определённого итога — то ли найдём, то ли нет."

Т.е. по твоим же словам риск, неопределенность.

По этой причине лисп все свои 50 лет все время был Неуловимым Джо.

>>>А тут можно начинать действовать прямо сейчас.

I>>О чем я тебе и говорю.

ГВ>Правильно! Только ты упускаешь главное: "действовать" — означает именно, что "двигаться с места на место". Прыгать, короче говоря. Шевелиться. Пыль поднимать.


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

I>>На лисп как абстракцию, конечно тень не бросает.

I>>А на лисп как язык, сообщество и тд этот пример полностью дискредитирует.

ГВ>В чьих глазах? В моих, точно, не дискредитирует.


В твоих возможно и нет. А чем объяснить его распространенность ?

ГВ>Дык. А отказалась-то она почему? Не из-за того ли, что иначе вставала перед угрозой разорения?


Не было угрозы разорения. Был шанс упустить рынок и доход с этого рынка.

>Пойми, проблема твоих рассуждений в том, что они апеллируют к фантастической ситуации: здесь никто на самом деле не мог встать перед такой угрозой из-за лиспа. Ни Грэм, ни Yahoo. Соображения я изложил в соседнем постинге. Если вкратце, то Грэму по поределению не испытывает проблем "из-за лиспа", а Yahoo по-любому готова переписать продукт, а иначе она его попросту не купила бы.


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

Их понять можно — никто не хочет играть в игру "найдем/ненайдем", потому как можно использовать готовых сиплюсников.

В бизнесе принято работать с тем, что есть, а не с тем, чем удобно.

Лисп из этой формулы выпадает.

ГВ>А я это запросто списываю на: а) феномен привычного языка; б) спокойствие, присущее работе в "большой компании"; в) желание поднять собственную значимость; г) сложившуюся культуру производства ПО (схоже с пунктом "а)" ).


Ага, и 50 лет Лиспу мешала эта формула.

Почему же эта формула не мешала другим языкам ?

I>>Да, у Грема не было. Это мега показатель А у меня, представь, зависимости от меня самого тоже нет


ГВ>Это единственный показатель, на самом деле.


Это тавтология а не показатель.

>При условии, что "майнстрим" не промыл дыру в башке своим мутным потоком.


Майнстрим подчиняется бизнесу,а бизнес требует определенность.

Люди готовы заплатить деньги, но хотят иметь определенность.

Только зависимостью от топ-специалистов Лисп устраняет начисто эту определенность.


>У компании есть ровно одна критичная опасность — разориться. Остальное — преодолимо, если оно не ведёт к гарантированному разорению.


Нужна определенность, которой нет у Лиспа.

>Я подозреваю, что Yahoo, покупая Viaweb, вообще могла не брать исходники. Кому они нужны при наличии своего штата специалистов?! Нужен рыночный сегмент, плюс — спецификация продукта, а сам Viaweb мог быть написан хоть на Brainfuck.


Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.

I>>Определись что ли ?


ГВ>Встречная просьба того же свойства: доведи свои посылки до конца, реши силлогизм(ы), наконец, которых ты сам понасоздавал.


Посылки вполне простые.

ГВ>Зато сишников, с таким складом мышления, как у мыщъха — днём с огнём.


Много больше, чем лисперов.

ГВ>Ничего это не значит, пока сюда не доставлены количественные интерпретации рисков в виде затрат.


Ну ты и дал. Кто ж тебе неопределенность числом определит ? Это ж секрет философского камня

ГВ>Это означает, что "просто специалисты" не смогли бы поддерживать продукт, написанный лучшими специалистами. Ситуация классическая. Но намного вероятнее, что это означает только лишь то, что Yahoo на самом деле не слишком мучилась "выбором технологии". Повторюсь: оказалось бы под рукой много джавистов — переписали бы на Java.


Естественно. Бизнес работает с тем что есть, а не с тем, что удобно.

Лисп в бизнес за 50 лет и не попал.
Re[27]: С vs C++
От: FR  
Дата: 29.05.10 02:49
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:


I>Только зависимостью от топ-специалистов Лисп устраняет начисто эту определенность.


Тут не важен лисп, зависимость от С++ или C# топ специалистов делает тоже самое. Но именно такие
специалисты и создают (или участвуют) стартапы и продукты которые потом покупают те же монстры.
Риск неопределенности компенсируется возможной большой прибылью.
Re[34]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.05.10 18:46
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Если я правильно помню, то помимо всего прочего, во времена кобола лисп однозначно ассоциировался с задачами ИИ, но никак не с повседневными экономическими расчётами. Но, конечно, факторов тут много, спекулировать на каком-то одном — неблагодарное занятие даже для КСВ.


Лисп и сейчас недалеко ушел от ИИ, экспертных систем.

ГВ>>>Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.

I>>Это не имеет значения, глядя на 40 лет кобола.

ГВ>Не понял.


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

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

ГВ>>>>>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.
I>>Я ж сказал — за гранью статпогрешности.

ГВ>Снова не врубился. Ты можешь не так туманно выражаться?


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

I>>С++, Джава, С№ не надо никуда впихивать. Бизнес сам приходит и просит именно это.


ГВ>Повторяю, бизнес бывает разный.


Бывает, да.

ГВ>>>Ой, ну извините... Ладно, продолжай демонстрировать всяческое презрение к лиспу дальше, у тебя это хорошо получается.

I>>Презрение это твоя проекция.

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


Не нужен и статпогрешность никакого отношения к презрению не имеют и иметь не могут.
Re[2]: С vs C++
От: Menestrel Россия  
Дата: 29.01.10 11:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>нет хорошо доступных серьезных инструметов например

I>1 для рефакторинга,
I>2 отладки
I>3 анализа кода

Это ты зря сказал
Сейчас тебя загрызать будут
Сложность программы растет до тех пор, пока не превысит способности программиста
Re[3]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.01.10 11:55
Оценка:
Здравствуйте, Menestrel, Вы писали:

I>>нет хорошо доступных серьезных инструметов например

I>>1 для рефакторинга,
I>>2 отладки
I>>3 анализа кода

M>Это ты зря сказал

M>Сейчас тебя загрызать будут

Канальи !
Re[3]: С vs C++
От: Eugeny__ Украина  
Дата: 29.01.10 12:19
Оценка:
Здравствуйте, Menestrel, Вы писали:

M>Здравствуйте, Ikemefula, Вы писали:


I>>нет хорошо доступных серьезных инструметов например

I>>1 для рефакторинга,
I>>2 отладки
I>>3 анализа кода

M>Это ты зря сказал

M>Сейчас тебя загрызать будут

А что, уже появились нормальные инструменты для рефакторинга и анализа кода? Тогда пусть кидают ссылку в студию!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[3]: С vs C++
От: abdul.zycor  
Дата: 29.01.10 13:09
Оценка:
Здравствуйте, Menestrel, Вы писали:

M>Здравствуйте, Ikemefula, Вы писали:


I>>нет хорошо доступных серьезных инструметов например

I>>1 для рефакторинга,
I>>2 отладки
I>>3 анализа кода

M>Это ты зря сказал

M>Сейчас тебя загрызать будут

Между прочим это действительно так, различается очень разработка в студии.
Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично ну если это возможно. А написав код в виме, например трейсить его лишний раз в gdb желание отпадает, ну конечно остается только смотреть логи.
Не плохо и не хорошо это, просто по другому.
Re: С vs C++
От: Vamp Россия  
Дата: 29.01.10 19:09
Оценка:
Одна из причин заключается в том, что из-за манглинга динамические библиотеки сделанные одним компилятором проблематично использовать в исполняемых файлах, сделанных в другом.

В С таких проблем нет.
Да здравствует мыло душистое и веревка пушистая.
Re[3]: С vs C++
От: Vamp Россия  
Дата: 29.01.10 19:28
Оценка:
_>Для этого extern C есть.
Особенно он полезен, когда в библиотеку помещаются классы.
Да здравствует мыло душистое и веревка пушистая.
Re[4]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.01.10 19:31
Оценка:
Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Pavel Dvorkin, Вы писали:


PD>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.


KV>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...


Какой же он ЯВУ если в нем нет абстрагирования от вопросов связаных например с памятью а многие инструменты просто не работают ?
Re[5]: С vs C++
От: kochetkov.vladimir Россия https://kochetkov.github.io
Дата: 29.01.10 20:08
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Какой же он ЯВУ


ЯВУ, он такой ЯВУ

[Интервью] .NET Security — это просто
Автор: kochetkov.vladimir
Дата: 07.11.17
Re[4]: С vs C++
От: Mr.Cat  
Дата: 30.01.10 05:27
Оценка:
Здравствуйте, abdul.zycor, Вы писали:
AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично
Да ну, бросай ты это дело. Если время есть — лучше и правда тест написать — на будущее останется.
Re[6]: С vs C++
От: IID Россия  
Дата: 30.01.10 07:49
Оценка:
Здравствуйте, Vamp, Вы писали:

IID>>Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано.

V>Ну это кривизна необыкновенная. Когда два С++ класса общаются между собой на C, и лишены возможностей взимодействовать с использованием возможностей С++. И то, как это сделано в ВинАПИ, кстати, есть тоже кривулина.

Всё дело в волшебных пузы^W^W правильной декомпозиции. Зато "внутренности" православно написаны на плюсах. К тому же задействование возможностей С++ во внешних интерфейсах автоматически кладёт болт на другие языки. Т.к. биндинги к pure-С есть у всех, а с С++ это не так.
kalsarikännit
Re: С vs C++
От: bazis1 Канада  
Дата: 31.01.10 09:40
Оценка:
Здравствуйте, abdul.zycor, Вы писали:

AZ>Всем привет! Не так давно стал изучать программирование для unix систем.

AZ>Возникло впечетление, что большая часть кода всяких серверов написана на с, а не на с++.
AZ>Вот возникает вопрос почему так, когда с++ современее, удобнее. Есть библиотеки типа boost, stl.
AZ>Какие могут быть обьяснения тому?
AZ>У меня такие:
AZ>Почему пишут на с:
AZ>1. в отладчике gdb приятнее видеть короткий простой код на с
AZ>2. не знают с++, поэтому пишут на с
AZ>3. переносимость под другие платформы, все же мне кажется код на с переносимее чем на с++
AZ>4. нет инструментов типа, таких как под винду, для рефакторинга и прочее, с инструментами типа gdb, emacs, vim п омоеум сложнее писать на с++
AZ>5. мног окода написано уже на с, хоят и новые почему-то пишут на с

AZ>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.

C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.
Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.
На практике получается, что объяснить программистам, как писать компактный и производительный код на С++ сложнее, чем запретить им пользоваться чем-либо кроме C. Увы.

Примерно как с автопилотом. Если в течение всего полета следить за курсом, картой, маяками и поддерживать направление вручную, полет пройдет по плану. Если задать в автопилоте план полета с координатами, полет также пройдет нормально. Но если пустить к управлению немотивированного "быдлокодера", он выставит на автопилоте примерный курс и уйдет спать, в результате чего ошибка в 1 градус при указании курса выльется в стокилометровый уход от цели.
Re[2]: С vs C++
От: alexdev Россия http://alexdev-ru.livejournal.com
Дата: 31.01.10 11:53
Оценка:
Здравствуйте, bazis1, Вы писали:

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


Думаю в тут можно заменить "быдлокодера" на "быдлолетчика" ))
... << RSDN@Home 1.2.0 alpha 4 rev. 1410>>
Re[3]: С vs C++
От: alexdev Россия http://alexdev-ru.livejournal.com
Дата: 31.01.10 11:54
Оценка:
Здравствуйте, alexdev, Вы писали:

A>Думаю в тут можно заменить "быдлокодера" на "быдлолетчика" ))


"Быдлокодер" за штурвалом с большей вероятностью все и всех похерит )))
... << RSDN@Home 1.2.0 alpha 4 rev. 1410>>
Re[4]: С vs C++
От: труженик села  
Дата: 31.01.10 15:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

PD>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.


I>Это как бы ЯВУ, на самом дело недо-ЯВУ.


Совместимость с C делает его недо-ЯВУ.
Если из него убрать все эти недо-ЯВУ, то будет Java или C#.
Одна из таких попыток — это Managed C++ Микрософта.
Re[4]: С vs C++
От: landerhigh Пират  
Дата: 31.01.10 20:45
Оценка:
Здравствуйте, abdul.zycor, Вы писали:

AZ>Написав код в студии я сразу же пытаюсь его отлаживать, протрейсить его весь или частично ну если это возможно.

Я всегда говорил, говорю и буду говорить, что программист, которому нужен отлЯдчик для только что написанного им кода — плохой, негодный программист.
www.blinnov.com
Re: С vs C++
От: BigBoss  
Дата: 01.02.10 01:10
Оценка:
Здравствуйте, abdul.zycor, Вы писали:

AZ>Какие могут быть обьяснения тому?


http://www.kernel.org/pub/linux/docs/lkml/#s15-3
Re[5]: С vs C++
От: CreatorCray  
Дата: 01.02.10 12:32
Оценка:
Здравствуйте, труженик села, Вы писали:

ТС>Одна из таких попыток — это Managed C++ Микрософта.

Надо сказать, получилось говно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: С vs C++
От: CreatorCray  
Дата: 01.02.10 12:32
Оценка:
Здравствуйте, Menestrel, Вы писали:

M>Это ты зря сказал

M>Сейчас тебя загрызать будут
Учитывая его репутацию скорее проигнорируют.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.02.10 13:16
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

I>>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.


DC>Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься.


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


I>>Я такую вещь заметил, что чем больше пишу на С#, тем

I>>1 труднее переключаться на С++
I>>2 легче писать на Си.
DC>Что как бе намекает нам о снижении уровня... абстракции?

нет, дело не в уровне абстракции. в си все что надо вызывается явно. В С++ злоупотребили неявным вызовом функционала, при том что эти неявные вызовы все равно приходится контролировать.
Т.е. в С++ снижения уровня абстракции по факту нет.
В C# нет таких проблем как в с++.
Re[6]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.02.10 14:12
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Не правда, я каждый день собираю код xlc 10 и ms vc 2005, совместимость отличная, есть конечно тонкости но они в основном связаны с линковкой, а у AIX-а и Винды они очень разные.


А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

I>>нет, дело не в уровне абстракции. в си все что надо вызывается явно. В С++ злоупотребили неявным вызовом функционала, при том что эти неявные вызовы все равно приходится контролировать.

I>>Т.е. в С++ снижения уровня абстракции по факту нет.
I>>В C# нет таких проблем как в с++.

DC>В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.


Я и не использую, потому языком С++ это крайне сложно назвать.
Re[7]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 01.02.10 14:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.


У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.

I>Я и не использую, потому языком С++ это крайне сложно назвать.


Ты в эту ветку о C# пришёл пописать?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[5]: С vs C++
От: CreatorCray  
Дата: 01.02.10 14:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Язык С++ хотя и мощнее С, но всего лишь язык и на платфому ну никак не тянет.

DC>>Почему? С — это подмножество. Вообще все забывают о том, что одна из основополагающих фишек С++ — ты не платишь за то, чем не пользуешься.
I>между компилерами с++ совместимость крайне слабая, все они совместимы на уровне Си
Это в общем случае.
ICC например совместим с MSVC и GCC (линуховая версия ICC).
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: С vs C++
От: Mr.Cat  
Дата: 01.02.10 14:40
Оценка:
Здравствуйте, dr.Chaos, Вы писали:
DC>В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.
В соседней ветке
Автор: yumi
Дата: 25.01.10
, кстати, обсуждается возможность улучшить C не путем превращения его в C++, а путем улучшения макросов.
Re[8]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.02.10 15:00
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

I>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.


DC>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.


А я не про ваш код говорю, а про тот, который мне довелось видеть.

I>>Я и не использую, потому языком С++ это крайне сложно назвать.


DC>Ты в эту ветку о C# пришёл пописать?


Я вообще то про С говорю. Про C# было в контексте Си
Re[10]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.02.10 20:01
Оценка:
Здравствуйте, CreatorCray, Вы писали:

I>>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

DC>>>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.
I>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
CC>Ну дык не смотри больше на хреновый код.

Какой пишут на такой и смотрю. При чем пишут люди, которые во всю ругают индусокод. Так шта...
Re[12]: С vs C++
От: alexdev Россия http://alexdev-ru.livejournal.com
Дата: 02.02.10 08:29
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Ikemefula, Вы писали:


I>>При чем пишут люди, которые во всю ругают индусокод.

CC>Честно говоря мне не известны люди, которые бы хвалили индусокод.

А как же сами индусы?
... << RSDN@Home 1.2.0 alpha 4 rev. 1421>>
Re[12]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.02.10 08:49
Оценка:
Здравствуйте, zaufi, Вы писали:

I>>Какой пишут на такой и смотрю. При чем пишут люди, которые во всю ругают индусокод. Так шта...

Z>это что у нас теперьь новое мерило для "проффесианализма"??? начал ругать индусокод, значит мега профессионал?
Z>вместо того чтоб ругать взяли бы да исправили раз такие умные...

Дай объявление в местную газету, что бы не ругали, а исправляли и сами такой не писали.
Re[13]: С vs C++
От: CreatorCray  
Дата: 02.02.10 09:20
Оценка:
Здравствуйте, alexdev, Вы писали:

I>>>При чем пишут люди, которые во всю ругают индусокод.

CC>>Честно говоря мне не известны люди, которые бы хвалили индусокод.

A>А как же сами индусы?

Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[14]: С vs C++
От: alexdev Россия http://alexdev-ru.livejournal.com
Дата: 02.02.10 09:34
Оценка:
Здравствуйте, CreatorCray, Вы писали:

A>>А как же сами индусы?

CC>Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.

Индусокодеры
... << RSDN@Home 1.2.0 alpha 4 rev. 1421>>
Re[15]: С vs C++
От: CreatorCray  
Дата: 02.02.10 09:55
Оценка:
Здравствуйте, alexdev, Вы писали:

A>Здравствуйте, CreatorCray, Вы писали:


A>>>А как же сами индусы?

CC>>Индусы или индусокодеры? Ты уточни кого ты имеешь в виду.

A>Индусокодеры

Увы поблизости нету таких чтоб спросить.
Но исходя из человеческой природы можно предположить, что свой код они индусским не считают, а соседский могут и поругать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 02.02.10 09:57
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>ICC например совместим с MSVC и GCC (линуховая версия ICC).


Кстати, xlc с 9й версии (а может и раньше) совместим с gcc на уровне ключей.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[7]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 02.02.10 10:15
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>В соседней ветке
Автор: yumi
Дата: 25.01.10
, кстати, обсуждается возможность улучшить C не путем превращения его в C++, а путем улучшения макросов.


С с такими макросами — уже не С будет . Т.е. если туда добавить гигиенические макры и в совокупности с llvm мы лисп порвём на тряпки , по гибкости и скорости. Но есть у меня сомнения что гигиенические макры дадуться бесплатно.

Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[8]: С vs C++
От: Mr.Cat  
Дата: 02.02.10 12:06
Оценка:
Здравствуйте, dr.Chaos, Вы писали:
DC>мы лисп порвём на тряпки , по гибкости и скорости.
Или превратимся в лисп.

DC>Но есть у меня сомнения что гигиенические макры дадуться бесплатно.

Я слышал, что строгая типизация вносит сложности в макросы. Т.е., видимо, придется дополнительно черпать идеи из nemerle/haskell/...
Еще для гигиены желательно наличие какого-то механизма пространств имен, чтобы развернутый в разных местах программы макрос ссылался на одни и те же функции/макросы (которые были видны в месте его определения).

DC>Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?

Кстати, а откуда исходит уверенность в том, что go будет супершустрый, как C? Там же, я так понял, планируется применять такие высокоуровневые вещи, как процессы/каналы, интерфейсы с аналогом утиной типизации и т.п. Т.е. мне показалось, это будет что-то типа эрланга, что-ли.
Re[9]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 02.02.10 13:28
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Или превратимся в лисп.


Только быстрый и типизированный.

DC>>Мне в этом плане намного симпатичней Go, но получится ли его сделать столь же производительным?

MC>Кстати, а откуда исходит уверенность в том, что go будет супершустрый, как C? Там же, я так понял, планируется применять такие высокоуровневые вещи, как процессы/каналы, интерфейсы с аналогом утиной типизации и т.п. Т.е. мне показалось, это будет что-то типа эрланга, что-ли.

В супершустрости Go я не уверен, но мне нравится как в нём решены многие проблемы, пока нравится. А процессы/каналы я и в С использовать могу, это не делает его дальше от железа.

Я, вообше, к тому говорил, что С не заменит язык с макросами, а заменит лишь язык с простым и мощным набором фич. Хотя может его ничего и не заменит в обозримом будущем.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[10]: С vs C++
От: Mr.Cat  
Дата: 02.02.10 14:18
Оценка:
Здравствуйте, dr.Chaos, Вы писали:
DC> но мне нравится как в нём решены многие проблемы
Имеются в виду проблемы C? А можно в двух словах? Я просто с этой стороны на Go не смотрел. Вроде как с хедерами разобрались раз и навсегда. Наверняка с контролем за размерами буферов и т.п. получше. А вот как там с обработкой ошибок/освобождением ресурсов? Эксепшены?

DC>А процессы/каналы я и в С использовать могу, это не делает его дальше от железа.

Я так понял во Go процессы "юзерспейсные", а не потоки ОС. Т.е. вроде как в порядке вещей наплодить их много-много (ну я судил по примеру с prime sieve). Плюс вроде там сборка мусора есть. Хотя вон, предшественник (как я понял) go — limbo — использовался как раз для системного программирования в inferno.
Re[11]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 02.02.10 14:54
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Имеются в виду проблемы C? А можно в двух словах? Я просто с этой стороны на Go не смотрел. Вроде как с хедерами разобрались раз и навсегда. Наверняка с контролем за размерами буферов и т.п. получше.


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

MC>А вот как там с обработкой ошибок/освобождением ресурсов? Эксепшены?


Там с обработкой ошибок ещё не решили до конца, пока коды возврата. Думаю при желании можно накрутить сверху монаду Maibe .

MC>Я так понял во Go процессы "юзерспейсные", а не потоки ОС. Т.е. вроде как в порядке вещей наплодить их много-много (ну я судил по примеру с prime sieve). Плюс вроде там сборка мусора есть. Хотя вон, предшественник (как я понял) go — limbo — использовался как раз для системного программирования в inferno.


Goroutines мапятся на реальные нити, но как — хз, только рантайм знает . Не думаю что сборка мусора будет большой проблемой.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[13]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 02.02.10 15:50
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Мне почему-то казалось, что С используют те, кто "не любит", когда рантайм делает за кадром слишком многое: создает потоки, управляет памятью и т.п. (потому и немного странно было, когда в Go сравнивался с С). Это не так?


Время покажет. Мне нравится простота языка, но между "мне нравится" и "замена С" сам понимаешь пропасть, я, собственно, и не берусь утверждать что Go заменит C (да и не верю в это), просто ИМХО у подхода с небольшим набором фич больше шансов.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[4]: Слава COM!!!
От: Erop Россия  
Дата: 02.02.10 18:43
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Особенно он полезен, когда в библиотеку помещаются классы.

Можно было бы на платформе застандартизировать принцип декорирования имён.
Можно через виртуальные функции и интерфейсы всё делать на худой конец...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[2]: С vs C++
От: Erop Россия  
Дата: 02.02.10 18:53
Оценка:
Здравствуйте, bazis1, Вы писали:

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


Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: С vs C++
От: Erop Россия  
Дата: 02.02.10 18:59
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>В С нужно писать тонны boilplate кода, это его основная проблема, а вот С++ позволяет сократить количество кода, но никто тебя не заставляет использовать конструкции несущие неявную семантику.


Мало того, можно довольно легко родить анализатор, который укажет на "некашерные" места...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: С vs C++
От: Erop Россия  
Дата: 02.02.10 19:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.

Дык ты С-шные исходники под много компиляторов видел?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: С vs C++
От: Vamp Россия  
Дата: 02.02.10 19:08
Оценка:
E>Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...
Чем тебе STL-то не угодил? Где в нем опасность?
Да здравствует мыло душистое и веревка пушистая.
Re[5]: Слава COM!!!
От: Vamp Россия  
Дата: 02.02.10 19:09
Оценка:
E>Можно было бы на платформе застандартизировать принцип декорирования имён.
Можно было бы. Манилова помнишь?

E>Можно через виртуальные функции и интерфейсы всё делать на худой конец...

А эти тут причем?
Да здравствует мыло душистое и веревка пушистая.
Re[6]: Слава COM!!!
От: Erop Россия  
Дата: 02.02.10 19:18
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Можно было бы. Манилова помнишь?

При чём тут Манилов? В чём проблема вообще сделать декорирование настраиваемым в любом компиляторе?
Вот была бы часть API линукса на С++ и все бы как миленькие декарировали бы имена так же, как и gcc...

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

E>>Можно через виртуальные функции и интерфейсы всё делать на худой конец...

V>А эти тут причем?

Ну COM под виндой, например, знаешь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: Слава COM!!!
От: Vamp Россия  
Дата: 02.02.10 19:21
Оценка:
E>При чём тут Манилов?
При том, что тот тоже мечтал о несбыточном.

E>В чём проблема вообще сделать декорирование настраиваемым в любом компиляторе?

Декорирование имен не входит в стандарт. Хорошо это или плохо — я не знаю. Наверное, плохо, но по-другому не выходит, потому что стандарт такими вещами не занимается.

E>Вот была бы часть API линукса на С++ и все бы как миленькие декарировали бы имена так же, как и gcc...

E>Другое дело, что взаимодействие с другими языками было бы *сильно затруднено*, ну да и фиг бы с ним, с другой стороны...
Во-во. Как бы ты взаимодействовал с этим кодом из С? Который декорировать не умеет никак?

E>Ну COM под виндой, например, знаешь?

КОМ к С++ никакого отношения не имеет. Так же как и к виртуальным функциям.
Да здравствует мыло душистое и веревка пушистая.
Re[10]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 07:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Стандарт де-факто — это gcc. Он достаточно backward compatible и его эмулирует icc.

C>Более того, он даже кодифицирован: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling

Так я про то же! Проблема с манглином -- надуманная!
C>Есть стандартизованный D-BUS. Прямой аналог COM, в общем.
Угу
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: С vs C++
От: _d_m_  
Дата: 03.02.10 08:18
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, kochetkov.vladimir, Вы писали:


KV>>С++ — это ЯВУ, согласен. Жаль только, что уже давно появились мега-ЯВУ, гипер-ЯВУ, супер-ЯВУ и, конечно же, пупер-ЯВУ. Со всеми вытекающими...


PD>На которых пишут не программисты (как на С++), а всякие супер- и пупер-программисты


Ага, я был программистом, а потом левел ап и я стал супер-программистом
Re[11]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 10:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ога, а ты COM то видел ? Сравни и не пори чушь

1) Ты бы уж тогда всё на С писал...

I>COM


I>
I>BOOL b;
I>BSTR bstr;

I>HRESULT hr = pSomePtr->GetStuff(&b,&bstr);

I>if(SUCCEEDED(hr))
I>{
I> ...
I>}
I>



Но вернёмся к нашему С++
Вот этот вот самый COM'овский вызов pSomePtr->GetStuff и эксплуатирует совместимость формата виртуальных таблиц между разными средами разработки
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Слава COM!!!
От: LuciferSaratov Россия  
Дата: 03.02.10 10:24
Оценка:
Здравствуйте, Erop, Вы писали:

E>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.


Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.
Re[8]: С vs C++
От: NikeByNike Россия  
Дата: 03.02.10 10:50
Оценка:
Здравствуйте, _d_m_, Вы писали:

B>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?


___>Позволяет. Но некоторые языки позволяют делать это лучше.


Например? Практики буквально на днях выясняли, что С++ таки самый лучший
Нужно разобрать угил.
Re[9]: С vs C++
От: _d_m_  
Дата: 03.02.10 11:31
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>Здравствуйте, _d_m_, Вы писали:


B>>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?


___>>Позволяет. Но некоторые языки позволяют делать это лучше.


NBN>Например? Практики буквально на днях выясняли, что С++ таки самый лучший


Пруфлинк. Или нотариально заверенные скриншоты.

Примеров масса: С#, Nemerle, Lisp и многое. Если заведут старую пластинку про какой-нибудь драйвер, то уж лучше С.
Re[9]: С vs C++
От: March_rabbit  
Дата: 03.02.10 11:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, dr.Chaos, Вы писали:


I>>>А я как ни загляну в многофплатформенный код , мне сразу дурно становится от препроцессорных директив.


DC>>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.


I>А я не про ваш код говорю, а про тот, который мне довелось видеть.

неплохая причина ругать язык
ты давно иномарки ругал за то, что ими управляют водятлы?
Re[6]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 11:52
Оценка:
Здравствуйте, March_rabbit, Вы писали:

I>>Какой же он ЯВУ если в нем нет абстрагирования от вопросов связаных например с памятью а многие инструменты просто не работают ?

M_>как-бы некоторый уровень абстрагирования есть. Если не изобретать ядерного реактора, то с распределением памяти не сталкиваешься.

Для начала надо на раз выучить и использовать RAII. Сам язык дает слишком большой простор.

отсюда неудивительно наблюдать винигрет недо-библотек и мега-монстров

M_>А про инструменты: таки, может, дело в инструментописателях?


Один ты умный, да.

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

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

В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.
Re[12]: Слава COM!!!
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 11:55
Оценка:
Здравствуйте, Erop, Вы писали:

I>>Ога, а ты COM то видел ? Сравни и не пори чушь

E>1) Ты бы уж тогда всё на С писал...

Вот тебе COM на C

HRESULT hr = pSomePtr->GetStuff(pSomePtr->lpVtbl,&b,&bstr);


всего то this явно передаешь. Можешь хоть COM сервер на C писать, никаких проблем.

E>Но вернёмся к нашему С++

E>Вот этот вот самый COM'овский вызов pSomePtr->GetStuff и эксплуатирует совместимость формата виртуальных таблиц между разными средами разработки

не между средами, а между компиляторами.
Re[7]: С vs C++
От: CreatorCray  
Дата: 03.02.10 11:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Какой же он ЯВУ если в нем нет абстрагирования от вопросов связаных например с памятью а многие инструменты просто не работают ?

M_>>как-бы некоторый уровень абстрагирования есть. Если не изобретать ядерного реактора, то с распределением памяти не сталкиваешься.

I>Для начала надо на раз выучить и использовать RAII. Сам язык дает слишком большой простор.

Ну дык и мощное оружие в руки дают только подготовленным людям.

I>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.

Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: С vs C++
От: March_rabbit  
Дата: 03.02.10 12:00
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Vamp, Вы писали:


V>>Чем тебе STL-то не угодил? Где в нем опасность?

E>Очень легко написать очень неэффективный код. Предполагает очень умного и знающего пограммиста.
E>Собственно я отвечал на сообщение, где наличие STL упоминадось как недостаток С++.
E>Можно разработать менее кудрявый фреймворк, который будет не таким легко расширяемым и универсальным, но, зато, и не будет провоцировать написание неэффективного кода по незнанию...
кухонным ножом можно влегкую порезать палец
паяльником можно.... хм... шрам на руке, оказывается, зажил. Надо же. как сейчас помню ощущения.
недавно на кухне с грохотом упала люстра, сломался пластиковый замок. Повезло, что под ней никого не оказалось....
....

ну ты понял, да?
Re[12]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 12:34
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Ikemefula, Вы писали:


DC>>>>>У нас их крайне мало. Несмотря на то, что сначала это были xlc 5 и VC98.

I>>>>А я не про ваш код говорю, а про тот, который мне довелось видеть.
M_>>>неплохая причина ругать язык

I>>Нормальная, если язык позволяет кидать-ловить исключения как попало, значит их и будут кидать как попало.

I>>Это только один из примеров.

CC>Человек тоже может справить нужду в любом месте. Но есть те, кто пользуется уборной, а есть "говнокодеры"


Если хочешь что бы аналогия была полной, надо взять и создать в С++ сообществе инструмент с функциями МВД

А можно сделать по уму — переложить решение проблемы на компилятор. что и сделано в нормальных языках.
Re[8]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 12:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

I>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.

CC>Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?

Я не сильно слежу за ассистом. он умеет ли он (2005я)



Без малого, я пользуюсь всем этим постоянно

Помнится, один наш общий знакомый вещал что "не пользуемся рефакторингом потому что архитектура идеальная "
Re[11]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 12:46
Оценка:
Здравствуйте, Erop, Вы писали:

C>>Стандарт де-факто — это gcc. Он достаточно backward compatible и его эмулирует icc.

C>>Более того, он даже кодифицирован: http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
E>Так я про то же! Проблема с манглином -- надуманная!
Тем не менее, он менялся несколько раз. Скажем, gcc 2.95 и gcc 3.3 — несовместимы. А ещё на него влияют разные настройки (скажем, использование исключений).

Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?

Поэтому на С++ особо и нет бинарных интерфейсов.
Sapienti sat!
Re[10]: С vs C++
От: NikeByNike Россия  
Дата: 03.02.10 12:53
Оценка:
Здравствуйте, _d_m_, Вы писали:

NBN>>Например? Практики буквально на днях выясняли, что С++ таки самый лучший


___>Пруфлинк. Или нотариально заверенные скриншоты.


___>Примеров масса: С#, Nemerle, Lisp и многое. Если заведут старую пластинку про какой-нибудь драйвер, то уж лучше С.


Нравятся мне религиознутые теоретики Ну попробуй с помощью шарпа напиши что-нибудь кроссплатформенное и не сферическое
Во, например, из последнего:
http://www.rsdn.ru/forum/pda/3671612.flat.aspx
Автор: sh1ng
Дата: 18.01.10
Нужно разобрать угил.
Re[7]: С vs C++
От: Eugeny__ Украина  
Дата: 03.02.10 13:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:


I>современный язык должен как можно сильнее облегчать задачу рефакторнга, анализа кода, генерации и тд.


I>В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.


Нуу, они пошли проторенной дорожкой за жабой в этом смысле, если быть точным .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[9]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 13:11
Оценка:
E>Если ты не понял, то при чём тут несбыточное?
Объяснись тогда.

E>Да и пусть себе не входит. Вот если в Линуксе появится С++ API, в котором будет заданы правила декорирования, то все компиляторы под линукс легко смогут приделать опцию "придерживаться этих правил"...

В Линуксе "вдруг" ничего появиться не может. Линукс — это только ядро, а ядро правила декорирования не устанавливает.

V>>Во-во. Как бы ты взаимодействовал с этим кодом из С? Который декорировать не умеет никак?

E>Через переходники.
И прощай легаси драйверы и программы. Нафиг такое счастье.

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

КОМ в винде реализован на С. И его интерфейс — сишный. С++ тут вообще не при чем, точно такой же КОМ можно реализовать и в Линуксе.
Да здравствует мыло душистое и веревка пушистая.
Re[9]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 13:13
Оценка:
F>А я как раз, было дело, руками лепил COM-интерфейс на C++.
F>И представлял он из себя ничто иное как C++ класс, у которого все методы — виртуальные.

Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.
Да здравствует мыло душистое и веревка пушистая.
Re[9]: С vs C++
От: CreatorCray  
Дата: 03.02.10 13:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере.

CC>>Assist вполне покрывает 100% моих задач. Что еще такого нужно для С++?

I>Я не сильно слежу за ассистом. он умеет ли он (2005я)

Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>Помнится, один наш общий знакомый вещал что "не пользуемся рефакторингом потому что архитектура идеальная "

Я пользуюсь refactor rename, create implementation, create declaration, extract method
Вроде как всё.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: С vs C++
От: CreatorCray  
Дата: 03.02.10 13:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Если хочешь что бы аналогия была полной, надо взять и создать в С++ сообществе инструмент с функциями МВД

Дык есть! Нагадил мимо буфера — бдыщ! Всё в продукте вторичном.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 13:54
Оценка:
Здравствуйте, Eugeny__, Вы писали:

I>>современный язык должен как можно сильнее облегчать задачу рефакторнга, анализа кода, генерации и тд.


I>>В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.


E__>Нуу, они пошли проторенной дорожкой за жабой в этом смысле, если быть точным .


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

кроме того, в .net много средтв которые теснят именно нативный C++ а не джаву.
Re[14]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 13:59
Оценка:
Здравствуйте, CreatorCray, Вы писали:

I>>Если хочешь что бы аналогия была полной, надо взять и создать в С++ сообществе инструмент с функциями МВД

CC>Дык есть! Нагадил мимо буфера — бдыщ! Всё в продукте вторичном.

Нету. Для полной аналогии говнокодер уличенный кем либо в сообществе С++ников должен понести административную или уголовную ответственность.
Re[15]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 14:06
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Вопрос имею.

V>А разве D-BUS — это не просто шина сообщений?
Ну так и COM — это просто формат на таблицу методов
Sapienti sat!
Re[11]: С vs C++
От: CreatorCray  
Дата: 03.02.10 14:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Я не сильно слежу за ассистом. он умеет ли он (2005я)

CC>>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.

I>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.

I>этого мягко говоря мало.

Для шарпа мало. Для С++ — достаточно.
Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[11]: Слава COM!!!
От: elmal  
Дата: 03.02.10 14:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>D-Bus это докомовский период

А тебе не кажется, что независимо от простейшего Hello DBUS и Hello COM, все эти вызовы прекрасно оборачиваются в одном методе, интерфейс которого можно подобрать так, что с ним будет достаточно удобно работать. И что вызо функции через COM, что через DBUS — в реальном коде все будет занимать одну простую строчку. Вернее скорее всего 2, одна — получение интерфейса, и вторая — вызов метода этого интерфейса. Или же планируется, что всем эти будут пользоваться индусы, которым платят за количество строчек кода?
Re[9]: С vs C++
От: Eugeny__ Украина  
Дата: 03.02.10 14:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Eugeny__, Вы писали:


I>>>современный язык должен как можно сильнее облегчать задачу рефакторнга, анализа кода, генерации и тд.


I>>>В C# например пошли именно этим путем — облегчили работу людям которые пишут средства разработки.


E__>>Нуу, они пошли проторенной дорожкой за жабой в этом смысле, если быть точным .


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


О да, пропертя, индексеры и евенты — это, конечно, супер-пупер возможности! Кстати, я не буду спорить, что они удобны, в жабе приходится воротить более синтаксически сложные конструкции, особенно в случае эвентов, но я не про то говорил.
Я имел ввиду, что в жабе гораздо раньше появились мощные средства рефакторинга, и именно благодаря простоте и отсутствию мозголомных конструкций, как в плюсах. МС при создании шарпа этот опыт учла, и не зря. Под плюсы рефакторинг убогий до сих пор.
То, что в синтаксическом плане шарп сейчас сильнее жабы(и это немного удручает: уж очень со скрипом в последнюю изменения вносятся), я не оспариваю, но мы сейчас не об этом говорим.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[17]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 14:36
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Вызов по COM — это реальный вызов метода, in-proc или out-proc. В результате имеет счетчик ссылок и прочее.

А каким образом происходит вызов out-of-proc методов?

Hint: там ещё посылается оконное сообщение.

V>Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.

V>Я прав?
Не совсем. D-BUS заточена под локальное использование, но в теории оно возможно.

Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.
Sapienti sat!
Re[18]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 14:40
Оценка:
C>А каким образом происходит вызов out-of-proc методов?
А in-proc?

C>Hint: там ещё посылается оконное сообщение.

Ну да.

V>>Вызов по D-BUS — это передача сообщения по миддлеваре. В теории, ничего не измениться, если вместо D-BUS мы поставим тибку, например.

V>>Я прав?
C>Не совсем. D-BUS заточена под локальное использование, но в теории оно возможно.
Тибка тоже отлично работает локально.

C>Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.

И тибка делает то же самое.
Да здравствует мыло душистое и веревка пушистая.
Re[12]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 14:44
Оценка:
Здравствуйте, CreatorCray, Вы писали:

I>>>>Я не сильно слежу за ассистом. он умеет ли он (2005я)

CC>>>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

I>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.

I>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
CC>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.

Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.

CC>Для шарпа мало. Для С++ — достаточно.

CC>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?
Re[10]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 14:47
Оценка:
Здравствуйте, Eugeny__, Вы писали:

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


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


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

E__>То, что в синтаксическом плане шарп сейчас сильнее жабы(и это немного удручает: уж очень со скрипом в последнюю изменения вносятся), я не оспариваю, но мы сейчас не об этом говорим.


Ну вот щас Оракл покажет, как надо
Re[13]: С vs C++
От: CreatorCray  
Дата: 03.02.10 15:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

CC>>Для шарпа мало. Для С++ — достаточно.

CC>>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

I>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?

на работе не самый свежий ассист стоит.
глянь на оффсайте, например тут:
http://wholetomato.com/products/default.asp
http://wholetomato.com/products/featureRefactoring.asp
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[14]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 15:03
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.

V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов

Например есть

someObj.Prop = something;

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

Что делает инструмент ? Правильно, предлагает создать сеттер, более того, он его и напишет за меня.

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

и вообще, всех действий нужно вдвое меньше, чем в джаве без пропертей
Re[19]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 15:16
Оценка:
Здравствуйте, Vamp, Вы писали:

C>>А каким образом происходит вызов out-of-proc методов?

V>А in-proc?
in-proc его обычно не используют (а смысл?). Хотя можно, он просто будет так же как и COM примерно работать.

C>>Но кроме диспетчеризации сообщений, D-BUS ещё и стандартизует формат сообщений. Т.е. способ маршаллинга аргументов сообщений. Так что без проблем делается кросс-языковая интероперабельность.

V>И тибка делает то же самое.
Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS
Sapienti sat!
Re[20]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 15:20
Оценка:
C>Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS
Это вряд ли. Тибка дорогая.
Я просто пытался показать, что технологии КОМ и ДБАС — разные, хотя и обеспечивают похожую функцуиональность.
Да здравствует мыло душистое и веревка пушистая.
Re[21]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 15:27
Оценка:
Здравствуйте, Vamp, Вы писали:

C>>Ну вот как стандарт Тибки станет использоваться в почти всех линуксовых программах — так она и заменит D-BUS

V>Это вряд ли. Тибка дорогая.
V>Я просто пытался показать, что технологии КОМ и ДБАС — разные, хотя и обеспечивают похожую функцуиональность.
Они разные, но в то же время похожие. Просто в COM упор идёт на in-proc, а маршаллинг out-of-proc вызовов и IDispatch добавлены как afterthought. В D-BUS ровно наоборот — он затачивался под out-of-proc работу и удобные динамические вызовы, а COM-подобные интерфейсы были добавлены уже как дополнительное средство для ускорения работы.
Sapienti sat!
Re[16]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 15:33
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>За тем, что геттер и сеттер собраны вместе и это очень удобно для читаемости/писаемости кода и для инструментов

V>Геттеры и сеттеры не нужны. Вообще.

Например, генерим какой класс по базе, это около 2-3 кликов мышом

получаетяс нечто вроде

class MegaItem
{
...

public string SomeField {get;set;}
public string SomeField2 {get;set;}
public string SomeField3 {get;set;}


...
}

далее, получаем инстанц и делаем следующее

MegaItem item = dbMgr.GetMegaItem(query);

и делаем следующее

_propertyGrid.DataSource = item;

где _propertyGrid это экземпляр пропертигрида

в итоге получаем вот ткое представление

название — Хуман ридабл строка для конкретной проперти (строка берется из Display Proxy) : значение (берётся из проперти)

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

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


Например System.Drawing.Graphics

интересуют вот эти

Graphics.CompositingQuality
Graphics.SmoothingMode
Graphics.InterpolationMode
Graphics.TextRenderingHint

или System.Rectangle — там сразу ясно какие
Re[17]: С vs C++
От: Vamp Россия  
Дата: 03.02.10 15:40
Оценка:
I>Например, генерим какой класс по базе, это около 2-3 кликов мышом
Прости, ничего не понялю. Давай пример попроще, без базы данных. Ну знаешь, как любят в школе объяснять — объект фигура, его потомок — объект квадрат. Или как нибудь в похожем роде.

I>А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF

Что это такое?

I>или System.Rectangle — там сразу ясно какие

Я понятия не имею, что такое System.Rectangle. См. выше.
Да здравствует мыло душистое и веревка пушистая.
Re[14]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 15:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

I>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?

CC>на работе не самый свежий ассист стоит.
CC>глянь на оффсайте, например тут:
CC>http://wholetomato.com/products/featureRefactoring.asp

Короче говоря — ничего нет

Нужны высокоуровневые средтва, рефакторинг тот же.
Re[3]: С vs C++
От: bazis1 Канада  
Дата: 03.02.10 15:48
Оценка:
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, bazis1, Вы писали:


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


E>Казалось бы, запретить вообще stl нафиг и разарботать своё, безопасное...

Зачем запрещать? Напишите свою библиотеку, лучше STL. Выложите на SourceForge, напишите по ней с десяток статей и радуйтесь. А на практике получается, что народ, не способный написать нормальный код с использованием STL, пишет свои библиотеки, по кривости и глючности превосходящие STL в разы...
Re[18]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 15:58
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>Например, генерим какой класс по базе, это около 2-3 кликов мышом

V>Прости, ничего не понялю. Давай пример попроще, без базы данных. Ну знаешь, как любят в школе объяснять — объект фигура, его потомок — объект квадрат. Или как нибудь в похожем роде.

Т.е. показать тебе именно пример где проперти не надо ?

I>>А вообще лучше расскажи, чем ты собираешься заменить проперти в WPF

V>Что это такое?

Windows Presentation Framework

I>>или System.Rectangle — там сразу ясно какие

V>Я понятия не имею, что такое System.Rectangle. См. выше.

Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.
Re[15]: С vs C++
От: Mr.Cat  
Дата: 03.02.10 16:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:
CC>>http://wholetomato.com/products/featureRefactoring.asp
I>Короче говоря — ничего нет
I>Нужны высокоуровневые средтва, рефакторинг тот же.
Как будто тот же решарпер умеет что-то принципиально более сложное.
Re[19]: С vs C++
От: Vamp Россия  
Дата: 03.02.10 16:04
Оценка:
I>Т.е. показать тебе именно пример где проперти не надо ?
То есть, property нужен только при работе с базами данных?

I>Windows Presentation Framework

Ничего про нее не знаю.

I>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.

Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.
Да здравствует мыло душистое и веревка пушистая.
Re[16]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.02.10 16:05
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

I>>Короче говоря — ничего нет

I>>Нужны высокоуровневые средтва, рефакторинг тот же.
MC>Как будто тот же решарпер умеет что-то принципиально более сложное.

Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение

"Как будто" — так и я умею. Смотри, как ловко:

Как будто нет ?
Re[8]: С vs C++
От: bazis1 Канада  
Дата: 03.02.10 16:07
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, bazis1, Вы писали:


B>>Здравствуйте, Ikemefula, Вы писали:


I>>>Здравствуйте, труженик села, Вы писали:


PD>>>>>>Если коротко — С — это высокоуровневый ассемблер. А С++ — это ЯВУ. Со всеми вытекающими.

I>>>>>Это как бы ЯВУ, на самом дело недо-ЯВУ.
ТС>>>>Совместимость с C делает его недо-ЯВУ.
B>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?

___>Позволяет. Но некоторые языки позволяют делать это лучше.


B>>Код более читабелен, по сравнению с альтернативами?


___>Код читабелен? Бу-га-га

___>На С++ код конечно читабелен. По сравнению с Брейнфаком. Но не более.
Вы про "среднюю температуру по больнице"? Или читабельность кода с 20 вложенными шаблонами равна читабельности кода, состоящего из пары классов, реализующих простой интерфейс?
Можно подумать, на C индусы не пишут
http://opensource.apple.com/source/procmail/procmail-1.2/procmail/src/procmail.c

B>>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?

___>Ехать. Но с комфортом.
Приведите пример задачи, которую нельзя "некриво" реализовать на С++ и я удивлю вас контрпримером
Re[12]: Слава COM!!!
От: bazis1 Канада  
Дата: 03.02.10 16:11
Оценка:
Здравствуйте, Vamp, Вы писали:

B>>COM — это тезнология, не имеющая формально отношения к используемому языку. Но, для облегчения жизни разработчикам на С++ формат интерфейсов соответствует С++ному. В итоге, это позволяет писать на С++ код вида:


V>Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.

Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.
Re[10]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 16:40
Оценка:
Здравствуйте, LuciferSaratov, Вы писали:

E>>Вот, например, к акве-какаве в МэкОС Х тоже никак, кроме как через ОбжективС не достучишься.

LS>Если я правильно помню, все же можно — вроде, там есть некая библиотека, позволяющая C-коду взаимодействовать с Objective-C объектами.

А ты ей пользовался? Я вот пользовался. Всё равно удобно иметь кусок на Objective-C, на самом деле.
Для связи с C++ объектами тоже можно аналогичную библиотеку написать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 16:43
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>не между средами, а между компиляторами.

Не только компиляторами. COM-объект можно и из Word'а из VBA дёрнуть, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: С vs C++
От: Erop Россия  
Дата: 03.02.10 16:45
Оценка:
Здравствуйте, March_rabbit, Вы писали:

M_>ну ты понял, да?

Не я тут высказывал идею, что С лучше С++ из-за наличия в последнем STL...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 16:49
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?


C>Поэтому на С++ особо и нет бинарных интерфейсов.


Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
Было бы API на С++ -- там бы подумали каким образом декорировать имена, ну и во всех бы компиляторах появился бы ещё один __declspec...

Другое дело, что декорирование имён совсем и не главная проблема. Главная проблема -- это аллокация памяти, исключения и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 17:13
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Ты не понял, что ты сделал. КОМ — это сишный интерфейс, и реализован он на С.


И, тем не менее, из С++ COM-интерфейс виден, как объект с кучей виртуальных методов...
Из любой реализации под С++ под винду, обрати внимание
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: С vs C++
От: Erop Россия  
Дата: 03.02.10 17:25
Оценка:
Здравствуйте, bazis1, Вы писали:

B>Зачем запрещать? Напишите свою библиотеку, лучше STL. Выложите на SourceForge, напишите по ней с десяток статей и радуйтесь. А на практике получается, что народ, не способный написать нормальный код с использованием STL, пишет свои библиотеки, по кривости и глючности превосходящие STL в разы...


Имелось в виду, запретить в проекте, для которого выбирают язык...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 17:30
Оценка:
Здравствуйте, Vamp, Вы писали:

E>>Из любой реализации под С++ под винду, обрати внимание

V>Потому, что он сишный.

Это, в данном случае, не важно. Важно ут совсем дургое -- API системы зафиксировало формат таблицы виртуальных функций, в случае COM-объекта. И привет, все компиляторы под винду его поддерживают
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 17:37
Оценка:
E>Это, в данном случае, не важно. Важно ут совсем дургое -- API системы зафиксировало формат таблицы виртуальных функций, в случае COM-объекта. И привет, все компиляторы под винду его поддерживают
Ты правда не понимаешь? КОМ — это приложение, реализованное на С. Не имеет никакого отношения к С++, и зачем ты его здесь приплетаешь, неясно.
Да здравствует мыло душистое и веревка пушистая.
Re[13]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 17:41
Оценка:
Здравствуйте, Erop, Вы писали:

C>>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?

C>>Поэтому на С++ особо и нет бинарных интерфейсов.
E>Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.

E>Было бы API на С++ -- там бы подумали каким образом декорировать имена, ну и во всех бы компиляторах появился бы ещё один __declspec...

E>Другое дело, что декорирование имён совсем и не главная проблема. Главная проблема -- это аллокация памяти, исключения и т. д...
Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.
Sapienti sat!
Re[14]: Держи, пожалуйста, себя в рамках!
От: Erop Россия  
Дата: 03.02.10 18:25
Оценка:
Здравствуйте, Vamp, Вы писали:

E>>Это, в данном случае, не важно. Важно ут совсем дургое -- API системы зафиксировало формат таблицы виртуальных функций, в случае COM-объекта. И привет, все компиляторы под винду его поддерживают

V>Ты правда не понимаешь? КОМ — это приложение, реализованное на С. Не имеет никакого отношения к С++, и зачем ты его здесь приплетаешь, неясно.

Я правда не понимаю, откуда следует выделенное.

А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 18:27
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Erop, Вы писали:


C>>>Причём далеко не только на gcc. Про то как разные настройки выравнивания или "Treat wchar_t as built-in type" на MSVC ломают бинарную совместимость напомнить?

C>>>Поэтому на С++ особо и нет бинарных интерфейсов.
E>>Ну так на С могли бы быть ровно те же проблемы. Просто у системы есть API на С, и нет API на С++
C>Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.
Зато им не однофигственно сколько байт из стека доставать

C>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.

Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 18:27
Оценка:
Здравствуйте, LuciferSaratov, Вы писали:

E>>Для связи с C++ объектами тоже можно аналогичную библиотеку написать...

LS>Для С++ можно написать, а там уже есть.

Ну так и системных API на плюсах мало... GDI+ разве отчасти...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: Держи, пожалуйста, себя в рамках!
От: Vamp Россия  
Дата: 03.02.10 18:29
Оценка:
E>Я правда не понимаю, откуда следует выделенное.
Скажем так, на чем реализован КОМ, я точно не знаю. Но полагаю, что на С, как и вся Windows. Но его интерфейсы — сишные. И это следует из спецификации.

E>А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...

Ну ты и джаву мог привести с тем же успехом. И питон. И .Нет, прости господи.
Да здравствует мыло душистое и веревка пушистая.
Re[16]: Держи, пожалуйста, себя в рамках!
От: Erop Россия  
Дата: 03.02.10 18:31
Оценка:
Здравствуйте, Vamp, Вы писали:

E>>А привёл я его тут, как пример успешной фиксации платформой одной из особенностей реализации С++...

V>Ну ты и джаву мог привести с тем же успехом. И питон. И .Нет, прости господи.

А ты перечитай моё первое сообщение, где я приводил примеры и COM в том числе
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 18:32
Оценка:
Здравствуйте, Erop, Вы писали:

C>>Откуда они на С возьмутся? Экспортируемые функции С не содержат полных сигнатур, так что им однофигственно что у тебя wchar_t — это отдельный тип, а не typedef для short'а.

E>Зато им не однофигственно сколько байт из стека доставать
Ну так то было решено ещё в эпоху PASCAL'я.

C>>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.

E>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?
Да, и можно.
Sapienti sat!
Re[14]: С vs C++
От: MxKazan Португалия  
Дата: 03.02.10 19:04
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.

V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?
А что в них уродливого?
Re[16]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 19:10
Оценка:
Здравствуйте, Cyberax, Вы писали:

E>>Зато им не однофигственно сколько байт из стека доставать

C>Ну так то было решено ещё в эпоху PASCAL'я.

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

C>>>Как раз твоя "главная проблема" на том же Линуксе вообще не стоит.

E>>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?
C>Да, и можно.

Чего? Как оно нужный ::operator delete найдёт?
Про исключения тоже забавно. Из какого именно std::excegtion оин будут унаследованы? От STL которой версии?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: Держи, пожалуйста, себя в рамках!
От: Erop Россия  
Дата: 03.02.10 19:12
Оценка:
Здравствуйте, Vamp, Вы писали:

V>То есть, ты хотел сказать, что есть и другие реализации ООП, кроме С++? Тогда твое высказывание тривиально.

То что я хотел сказать, я сказал уже много раз.

Проблемы с декорайией С++ имён не так страшны, чтобы помешать использовать С++ в качестве языка части API OS

Но теперь я, кажется, уже хочу сказать, что ты не совсем хорошо умеешь читать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: С vs C++
От: MxKazan Португалия  
Дата: 03.02.10 19:17
Оценка:
Здравствуйте, Vamp, Вы писали:

MK>>А что в них уродливого?

V>Все.
Слил?
Re[17]: С vs C++
От: Vamp Россия  
Дата: 03.02.10 19:19
Оценка:
MK>Слил?
Это смотря кто.
Да здравствует мыло душистое и веревка пушистая.
Re[20]: Держи, пожалуйста, себя в рамках!
От: Erop Россия  
Дата: 03.02.10 19:19
Оценка:
Здравствуйте, Vamp, Вы писали:

V>Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.


Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[21]: Держи, пожалуйста, себя в рамках!
От: Vamp Россия  
Дата: 03.02.10 19:21
Оценка:
E>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...
Да нет же! КОМ вообще не имеет дела с виртуальными таблицами, потому что НЕ экспортирует С++-классы. Программы на КОМ можно писать, например, на VB, в котором никаких виртуальных таблиц нет вообще.
Да здравствует мыло душистое и веревка пушистая.
Re[21]: Держи, пожалуйста, себя в рамках!
От: Cyberax Марс  
Дата: 03.02.10 19:23
Оценка:
Здравствуйте, Erop, Вы писали:

V>>Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.

E>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...
Странно, но у gcc абсолютно такие же виртуальные таблицы. Странно, да?
Sapienti sat!
Re[17]: Слава COM!!!
От: Cyberax Марс  
Дата: 03.02.10 19:32
Оценка:
Здравствуйте, Erop, Вы писали:

E>>>Зато им не однофигственно сколько байт из стека доставать

C>>Ну так то было решено ещё в эпоху PASCAL'я.
E>Блин! Так я про то же и говорю, что в С свои проблемы бинарной совместимости были, и что они были успешно решены. Было бы надо -- и с С++ справились бы...
Эти проблемы на пару порядков сложности различаются. Описание calling convention для С занимает страничку, описание ABI для C++ — около 500 (с учётом исключений, множественного наследования и всяких dynamic_cast).

E>>>Как так "не стоит"? Исключения могут летать между разными версиями gcc? Или, аллокации можно передавать?

C>>Да, и можно.
E>Чего? Как оно нужный ::operator delete найдёт?
Они forward compatible в libstdc++.
Sapienti sat!
Re[18]: Слава COM!!!
От: Erop Россия  
Дата: 03.02.10 19:55
Оценка:
Здравствуйте, Cyberax, Вы писали:

E>>Чего? Как оно нужный ::operator delete найдёт?

C>Они forward compatible в libstdc++.

Ха! А если я перекрою, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Держи, пожалуйста, себя в рамках!
От: Erop Россия  
Дата: 03.02.10 19:56
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Странно, но у gcc абсолютно такие же виртуальные таблицы. Странно, да?

Не абсолютно, но похожие.
А вот с точки зрения COM'а -- точно такие же, кстати...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Держи, пожалуйста, себя в рамках!
От: Erop Россия  
Дата: 03.02.10 19:57
Оценка:
Здравствуйте, Vamp, Вы писали:

E>>Потому, что COM, тем не менее, смог зафиксировать формат таблицы виртуальных функций, которому следуют ВСЕ компиляторы С++ под винду...

V>Да нет же! КОМ вообще не имеет дела с виртуальными таблицами, потому что НЕ экспортирует С++-классы. Программы на КОМ можно писать, например, на VB, в котором никаких виртуальных таблиц нет вообще.

И что? Как то вообще связано с моим утверждением?
Я не утверждаю, что COM на С++ написан или на него ориентирован. Я всего лишь утверждаю, что он задал формат таблиц виртуальных функций под винду...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: С vs C++
От: CreatorCray  
Дата: 03.02.10 20:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?

CC>>на работе не самый свежий ассист стоит.
CC>>глянь на оффсайте, например тут:
CC>>http://wholetomato.com/products/featureRefactoring.asp
I>Короче говоря — ничего нет

I>Нужны высокоуровневые средтва, рефакторинг тот же.

Зачем?
Объясни?
Какие средства надо? Что у тя входит в рефакторинг?
Ты не меряй то, что надо для шарпа на плюсы.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: Слава COM!!!
От: SleepyDrago Украина  
Дата: 03.02.10 21:05
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Erop, Вы писали:


E>>>>Чего? Как оно нужный ::operator delete найдёт?

C>>>Они forward compatible в libstdc++.
E>>Ха! А если я перекрою, например?
C>Будешь сам себе злобный Буратино.
ага вы можете выбрать себе любой цвет при условии что он черный И соответственно определить любой operator delete при условии что он тождественно равный free()
Re[14]: Слава COM!!!
От: bazis1 Канада  
Дата: 03.02.10 21:30
Оценка:
Здравствуйте, Vamp, Вы писали:

B>>Причем здесь манглинг, если взаимодействие с компонентами реализуется посредством интерфейсов, а не эскпортированием методов по имени? А то, что системные функции COM незаманглены, всего лишь означает extern "C" при объявлении оных и совсем не говорит, что они написаны на C.

V>Сдается мне, ты вообще не понимаешь, о чем идет речь в это дискуссии.
Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.
Re[15]: Слава COM!!!
От: Vamp Россия  
Дата: 03.02.10 21:33
Оценка:
B>Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.
Господь с тобой, какие мои аргументы ты опроверг? Давай сначала, а то уже запуталось все.
Итак, с какими конкретно моими тезисами ты не согласен и почему?
Да здравствует мыло душистое и веревка пушистая.
Re[10]: С vs C++
От: Aleх  
Дата: 04.02.10 01:04
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Здравствуйте, NikeByNike, Вы писали:


NBN>>Здравствуйте, _d_m_, Вы писали:


B>>>>Затрахали уже своими "моё ЯВУ кавайнее твоего". Свой круг прикладных задач решать позволяет?


___>>>Позволяет. Но некоторые языки позволяют делать это лучше.


NBN>>Например? Практики буквально на днях выясняли, что С++ таки самый лучший


___>Пруфлинк. Или нотариально заверенные скриншоты.


___>Примеров масса: С#, Nemerle, Lisp и многое. Если заведут старую пластинку про какой-нибудь драйвер, то уж лучше С.

Я понимаю, Nemerle может служить примером. Но зачем писать Lisp? Почему его вообще всегда упоминают, а забывают про какую нибудь Аду или PL/1? Это же всё устаревшие языки программирования.
Re[20]: С vs C++
От: Aleх  
Дата: 04.02.10 01:30
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>Т.е. показать тебе именно пример где проперти не надо ?

V>То есть, property нужен только при работе с базами данных?

I>>Windows Presentation Framework

V>Ничего про нее не знаю.

I>>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.

V>Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме. Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>). Кому то нравится первый вариант. Если отрицать это, и рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.
Re[14]: С vs C++
От: Aleх  
Дата: 04.02.10 01:33
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Ikemefula, Вы писали:


CC>>>Для шарпа мало. Для С++ — достаточно.

CC>>>Там в ассисте еще много всякой бороды есть, типа encapsulate field, change visibility, change signature (во, еще этой иногда пользуюсь), create from usage и т.п.

I>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?

CC>на работе не самый свежий ассист стоит.
CC>глянь на оффсайте, например тут:
CC>http://wholetomato.com/products/default.asp
CC>http://wholetomato.com/products/featureRefactoring.asp
Ассист бяка. Он на сложном коде, насыщенном шаблонами глючит.
Re: загадка
От: TarasCo  
Дата: 04.02.10 07:29
Оценка:
WTF, что это за язык?!

void split(int *arr)
  requires(is_object_root(as_array(arr, 100)))
  writes(extent(as_array(arr, 100)))
{
  split_array(as_array(arr, 100), 50);
  split_array(as_array(arr+50, 50), 25);
  split_array(as_array(arr, 50), 25);
  split_array(as_array(arr+25, 25), 10);
}

void splitAndJoin(int *arr)
  requires(is_object_root(as_array(arr, 100)))
  writes(extent(as_array(arr, 100)))
{
  split_array(as_array(arr, 100), 50);
  join_arrays(as_array(arr, 50), as_array(arr+50, 50));
}

void join(int *arr1, int *arr2)
  requires(arr1 + 100 == arr2)
  requires(is_object_root(as_array(arr1, 100)))
  requires(is_object_root(as_array(arr2, 32)))
  writes(extent(as_array(arr1, 100)), extent(as_array(arr2, 32)))
{
  join_arrays(as_array(arr1, 100), as_array(arr2, 32));
}
Да пребудет с тобою сила
Re[21]: С vs C++
От: CreatorCray  
Дата: 04.02.10 08:35
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.

A>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.

проперти перед вызовом функции по мне так выигрывают совсем ничтожный мизер "синтаксического оверхеда" (С) (R) (ТМ), при этом иногда затрудняя читабельность кода, т.к. скрывают реальную работу, происходящую в этом месте. Как на глаз отличить присвоение проперти и присвоение переменной? Каждый раз лазить и смотреть есть ли сеттер?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[17]: С vs C++
От: CreatorCray  
Дата: 04.02.10 10:02
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Открой ссылку для асиста, открой картинку что я показал, сравни и напиши сюда свое мнение

Дык существенная часть того что там он умеет для С++ попросту нафиг не нужно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[18]: С vs C++
От: CreatorCray  
Дата: 04.02.10 10:02
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Не знаю, насколько это в ассисте хорошо работает,

Нормально работает. Кода с дикой мешаниной шаблонов, на котором кто-то отмечал глюки ассиста у меня под рукой нет.
Были билды где авторы чегой то там ломали, но на относительно последних — все ок.

MC>просто в этой теме шарповый рефакторинг почему-то преподносится как что-то неземное.

Ну, надо ж им чем то гордиться.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 10:07
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>Т.е. показать тебе именно пример где проперти не надо ?

V>То есть, property нужен только при работе с базами данных?

Необязательно.

I>>Windows Presentation Framework

V>Ничего про нее не знаю.

Загляни в какой толковый туториал по MVVM.

I>>Я уже понял, что ты хотел сказать — в твоем коде/области проперти не нужны. Вполне возможно оно и так.

V>Нет, ты покажи мне код, где они нужны. Пока что ты показал только какое-то непонятное месиво, посвященное базам данных.

Контролы в WPF и тот же System.Rectangle никакого отношения к БД не имеют.

Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?
Re[16]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 10:35
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Ikemefula, Вы писали:


I>>>>Сделай скрин да покажи, разве трудно раз нажать на PrtSc ?

CC>>>на работе не самый свежий ассист стоит.
CC>>>глянь на оффсайте, например тут:
CC>>>http://wholetomato.com/products/featureRefactoring.asp
I>>Короче говоря — ничего нет

I>>Нужны высокоуровневые средтва, рефакторинг тот же.

CC>Зачем?
CC>Объясни?
CC>Какие средства надо? Что у тя входит в рефакторинг?

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

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

Или такая задача — упрощения имеющегося кода.

Можно, конечно, подойти по понЭрски — все переписать заново, с нуля или около того.

Но гораздо проще, быстре и надежнее будет сделать рефакторинг.

Практически везде нужно

1. выделение базового класса/интерфейса
2. перемещение методов по иерархии
3. использование базового класса

еще очень сильно не хватает "преобразование метода в класс"
и вообще очень много чего не хватает

при этом Решарпер предоставляет много средств которые не показыны в меню что я привел, например создание наследника, генерацию конструкторов и многое другое

заметь — выделение метода я упомянул только здесь.

CC>Ты не меряй то, что надо для шарпа на плюсы.


Рефакторинг нужен независимо от языка.

В с++ мощные средства рефакторинга будут работать с такой же скоростью как и компилер потому ты их там и не видишь.
Re[16]: Слава COM!!!
От: bazis1 Канада  
Дата: 04.02.10 10:56
Оценка:
Здравствуйте, Vamp, Вы писали:

B>>Сдается мне, что я опроверг все твои аргументы и ты перешел на "ты ваще с какого района" за неимением ничего лучшего.

V>Господь с тобой, какие мои аргументы ты опроверг? Давай сначала, а то уже запуталось все.
V>Итак, с какими конкретно моими тезисами ты не согласен и почему?

B>>В итоге, это позволяет писать на С++ код вида:

V>Напрямую — не позволяет. COM написан на С, там манглинга (вспомни, с чего начался топик) нет. Только через С++ биндинги.
1) Не согласен с тем, что COM не позволяет напрямую использовать C++ для реализации интерфейсов. Контрпример — приведенный код, который будет успешно создавать экземпляр COM-интерфейса (AddRef()/Release() были опущены для краткости, с ними будет new CComObject<CSomething> вместо CSomething). И CComObject<> — это не "специфический биндинг для C++", а всего лишь shortcut для стандартных реализаций AddRef()/Release(), дополнительно упрощающий жизнь. Основной функционал — генерация vtable, выполняемая компилятором С++ без каких-либо дополнительных библиотек.
2) С тем, что "COM написан на C, так как там нет манглинга". Отсутствие манглинга и C-совместимые API для приложений означают extern "C" и желание разработчиков оставить совместимость для фанатов чистого C.
Re[20]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 04.02.10 11:44
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.


Да ты што!! Нам решарпер любую архитектуру исправит. Это ведь такая продвинутая штука!
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[3]: С vs C++
От: CreatorCray  
Дата: 04.02.10 11:49
Оценка:
Здравствуйте, Aleх, Вы писали:

A>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.


В качестве лирического отступления.
При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.


Я уже представляю себе этот нереальный пипец в коде.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[21]: С vs C++
От: CreatorCray  
Дата: 04.02.10 11:53
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

CC>>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.

DC>Да ты што!! Нам решарпер любую архитектуру исправит. Это ведь такая продвинутая штука!
На пришедшем от американских индусов C# проекте решарпер сжирал всю доступную память и вижуалка дохла в корчах.
Снёс нахрен и поставил ассист.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 12:23
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

CC>Это какое отношение имеет к обсуждению фич средств рефакторинга для С++?

Непосредственное.

I>>Хочешь выделить небольшую фичу в отдельную подсистему — добро пожаловать в ад на с++.

CC>Неоднократно делал. Ада не замечено. Видимо архитектурно изначально было всё в порядке.

"написание биндингов"
Re[22]: С vs C++
От: MxKazan Португалия  
Дата: 04.02.10 12:49
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Aleх, Вы писали:


A>>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.

A>>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
CC>По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
CC>Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
CC>И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.

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

Так чего тогда плюсовал слившему товарищу? Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти. Блин, я ждал откровений, а все оказалось так банально. Подобная аргументация от чуваков, вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного, способна только вызвать улыбку.
Re[21]: С vs C++
От: MxKazan Португалия  
Дата: 04.02.10 12:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Windows Presentation Framework

V>>Ничего про нее не знаю.
I>Загляни в какой толковый туториал по MVVM.
Я тока поправлю. Все-таки не Framework, а Foundation. Windows Presentation Foundation
Re[22]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 13:02
Оценка:
Здравствуйте, MxKazan, Вы писали:

I>>>>Windows Presentation Framework

V>>>Ничего про нее не знаю.
I>>Загляни в какой толковый туториал по MVVM.
MK>Я тока поправлю. Все-таки не Framework, а Foundation. Windows Presentation Foundation

Да, я поторопился.
Re[22]: С vs C++
От: Aleх  
Дата: 04.02.10 13:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Aleх, Вы писали:


A>>Например, такая простая ситуация. Есть GUI элемент Button. В процессе выполнения программы нам нужно передвинуть кнопку на форме.

A>>Положим, по координате X. С использованием Property это будет выглядеть так: button1.x = <новое значение>. Без button1.setX(<новое значение>).
CC>По мне так это абсолютно одно и то же. Синтаксический сахар и не более того.
CC>Я так понимаю проперти тебе там понадобилось для того, чтоб выполнить кроме самого изменения координаты еще и перерисовку (immediate или deferred, неважно).
CC>И тут и там вызов функции, только в случае с проперти он неявный. Что меня регулярно сильно раздражало при разборе индусокода на шарпе: эти уникумы любят пихать в сеттеры/геттеры дохренища кода, который делает много чего левого, не относящегося собственно к этой проперти.

A>>рассуждать в том же духе, что синтаксический сахар не нужен, можно оставаться программировать на ассемблере.

CC>проперти перед вызовом функции по мне так выигрывают совсем ничтожный мизер "синтаксического оверхеда" (С) (R) (ТМ), при этом иногда затрудняя читабельность кода, т.к. скрывают реальную работу, происходящую в этом месте. Как на глаз отличить присвоение проперти и присвоение переменной? Каждый раз лазить и смотреть есть ли сеттер?
Теоретически, среда разработки может подсказывать, что там происходит на самом деле. А вообще, в С++ много конструкций с неочевидной семантикой (использование перегруженных операторов). Многие поклонники Си говрят, что они по этой причине не переходят на С++. Если же грамотно использовать все эти фитчи, предоставляющие альтернативную семантику для привычных конструкций, проблемы не будет. Проблема в программистах недостаточно знающий язык или недостаточно хорошо умеющий проектировать интерфейсы классов.
Re[4]: С vs C++
От: Aleх  
Дата: 04.02.10 13:51
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Aleх, Вы писали:


A>>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.


CC>В качестве лирического отступления.

CC>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.
Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет. Тогда причем здесь это, я же описал совершенно другой случай.

A>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.


CC>Я уже представляю себе этот нереальный пипец в коде.

В чем заключается этот пипец?
Re[21]: С vs C++
От: Vamp Россия  
Дата: 04.02.10 14:42
Оценка:
I>Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?
Ты приводишь примеры какой-то незнакомой мне среды. Ты можешь показать УНИВЕРСАЛЬНЫЙ пример?
А ведь я тоже могу покахать тебе кусок на Мотиве и спросить, куда здесь засунуть проперти и зачем.
Да здравствует мыло душистое и веревка пушистая.
Re[22]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 14:53
Оценка:
Здравствуйте, Vamp, Вы писали:

I>>Есть такой класс как System.Windows.Forms.Control и его наследники. Куда деть тамошние проперти ?

V>Ты приводишь примеры какой-то незнакомой мне среды. Ты можешь показать УНИВЕРСАЛЬНЫЙ пример?

Я привожу примеры из того, с чем работаю.
Из того, с чем не работаю, примеры не привожу.
Re[24]: С vs C++
От: MxKazan Португалия  
Дата: 04.02.10 14:56
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, MxKazan, Вы писали:


MK>>Так чего тогда плюсовал слившему товарищу?

CC>Ты о чём конкретно?
О плюсе к этому посту
Автор: Vamp
Дата: 03.02.10
.

MK>> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.

CC>Если ты ничего не понял то лучше бы спросил.
Да вроде понятно.

CC>Уродство: это переться со своим уставом (методиками программирования на одном языке) в чужой монастырь (пытаться в тех же методиках писать на другом языке). И потом орать что это дескать не сам дурак, а язык плохой.

CC>Ей богу, шо дети.

CC>Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.

CC>На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.
Вот не надо. В твоем же примере убогости свойств, разговор идет про C#.

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

CC>Мьсе потрудится привести пруфлинк?
Нет, лопатить кучу страниц КСВ мне в лом. Но ты же не будешь отнекиваться, что всегда выступаешь на стороне С++.
Re[23]: С vs C++
От: CreatorCray  
Дата: 04.02.10 14:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Из того, с чем не работаю, примеры не привожу.

А с С++ ты работаешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[24]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.02.10 15:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

I>>Из того, с чем не работаю, примеры не привожу.

CC>А с С++ ты работаешь?

Приходится посматривать туда.
Re[18]: С vs C++
От: Mr.Cat  
Дата: 04.02.10 15:13
Оценка:
Здравствуйте, dr.Chaos, Вы писали:
DC>графическая штамповалка boilerplate
Это все оттого, я считаю, что в C# мало средств метапрограммирования. Без макросов типичную конструкцию (свойство, например) разработчик языка не выпустит в виде библиотеки — надо в язык включать. А разработчик приложений не сможет генерацию и поддержку boilerplate поручить макросу — ему нужны будут тулзы.
Re[25]: С vs C++
От: CreatorCray  
Дата: 04.02.10 15:37
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>>>Так чего тогда плюсовал слившему товарищу?

CC>>Ты о чём конкретно?
MK>О плюсе к этому посту
Автор: Vamp
Дата: 03.02.10
.


I>>>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.
I>>>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
CC>>>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.
I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.
V>Вот ты мне можешь объяснить, зачем нужен такой уродец, как property?

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

MK>>> Написал бы лучше рядом, что уродство — это не проперти, а "индусские" проперти.

CC>>Если ты ничего не понял то лучше бы спросил.
MK>Да вроде понятно.
Что то в глаза не бросается

CC>>Ikemefula же ведёт разговор в русле: раз в тулах для С++ нет "средства инкапуляции филда в пропертю" то С++ есть говно недостойное.

CC>>На что следует резонный вопрос: а нахрена они нам сдались то, проперти в С++? Как то без них живём, проекты выпускаем, бабло получаем.
MK>Вот не надо. В твоем же примере убогости свойств, разговор идет про C#.
Мсье не потрудился прочитать внимательно ветку сообщений?
См. выше процитированный кусок. Там чётко видно, что речь идёт о пропертях касательно С++.

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

CC>>Мьсе потрудится привести пруфлинк?
MK>Нет, лопатить кучу страниц КСВ мне в лом. Но ты же не будешь отнекиваться, что всегда выступаешь на стороне С++.
Т.е. мьсе трепло?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: С vs C++
От: CreatorCray  
Дата: 04.02.10 15:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Из того, с чем не работаю, примеры не привожу.

CC>>А с С++ ты работаешь?

I>Приходится посматривать туда.

А мы там давно работаем. В текущем проекте под 2008R2 используется С#, С и С++. C# исключительно для гуя.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[6]: С vs C++
От: Aleх  
Дата: 04.02.10 15:43
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Aleх, Вы писали:


A>>>>Во первых, нужно эффективно реализовать строку. Что я имею ввиду? Обычно строки используемые в таких случаях имеют маленькую длину. В таком случае можно применить слудующую оптимизацию: строка до определенного размера будет хранится не в динамической памяти, а в массиве фиксированной длины, являющимся членом класса строка.


CC>>>В качестве лирического отступления.

CC>>>При переходе с одной версии STL на другую, при неизменном компиляторе мы как то поимели неслабый провал производительности в парсере, который работал с std::string.
CC>>>После разбора полётов оказалось, что виновата реализация std::string с буфером для маленьких строк. После "хака", убирающего буфер всё опять стало хорошо.

A>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.

CC>Настраиваемый через шаблонный параметр размер буфера это цирк.
CC>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?
Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.
Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
A>>Тогда причем здесь это, я же описал совершенно другой случай.
CC>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
CC>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.
Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.

A>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.


CC>>>Я уже представляю себе этот нереальный пипец в коде.

A>>В чем заключается этот пипец?
CC>В огромном шаблоне, в котором будет куча кода для реализации всех этих внутренних представлений.
Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.
Re[7]: С vs C++
От: CreatorCray  
Дата: 04.02.10 15:59
Оценка:
Здравствуйте, Aleх, Вы писали:

A>>>Ок. Там настраивался размер этого буфера? его можно было отключить через параметр шаблона класса string? Наверное нет.

CC>>Настраиваемый через шаблонный параметр размер буфера это цирк.
CC>>А если в одном месте программы идеальный буфер == 20 символов а потом строки передаются в код, где идеальный размер уже 50 что будет?

A>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.

A>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.

А не проще ли будет ускорить реально тормозящее место во всех реализациях строки — прикрутить к строке быстрый кастомный аллокатор?
Считай это подсказкой направления.

A>>>Тогда причем здесь это, я же описал совершенно другой случай.

CC>>Это всё к тому, что далеко не все "оптимизации" на практике ускоряют работу.
CC>>Причем работающая на конкретном проце оптимизация может ацки тормозить на другом.

A>Это если какие процы рассматривать? Как мне кажется, те оптимизации, которые на разных процах ведут себя по разному выполняет компилятор, но никак не программист.

Hint: дело не в командах проца а в работе кэша.

CC>>>>Я уже представляю себе этот нереальный пипец в коде.

A>>>В чем заключается этот пипец?
CC>>В огромном шаблоне, в котором будет куча кода для реализации всех этих внутренних представлений.
A>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.

Для людей, пишущих в стиле Александреску, на одном из моих предыдущих мест работы появился термин "укушенный Александреску".
Ибо человек, постигший Александреску-дзэн поначалу начинает писать на шаблонах всё. В прямом смысле, вообще всё.
А потом приходит пушистый северный зверёк в виде черепашьей скорости компиляции и (да, бывает и такое!) compiler limits.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[26]: С vs C++
От: MxKazan Португалия  
Дата: 04.02.10 17:18
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Т.е. мьсе трепло?

В таком тоне я общаться не собираюсь.

P.S. Пример
Автор: CreatorCray
Дата: 30.01.08
Re[19]: С vs C++
От: dr.Chaos Россия Украшения HandMade
Дата: 04.02.10 18:35
Оценка:
Здравствуйте, Mr.Cat, Вы писали:

MC>Это все оттого, я считаю, что в C# мало средств метапрограммирования. Без макросов типичную конструкцию (свойство, например) разработчик языка не выпустит в виде библиотеки — надо в язык включать. А разработчик приложений не сможет генерацию и поддержку boilerplate поручить макросу — ему нужны будут тулзы.


Нет, это из-за распространённости языка . На C# тоже можно писать лаконично, красиво и понятно, только миллионам леммингов надо быстро напедалить, вот и есть хорошие штамповалки, там где они нужны и востребованы. На С++ тоже востребованы, но сложны в изготовлении. Макросы безусловно вещь мощная, но их никто не даст использовать кому попало .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[27]: С vs C++
От: CreatorCray  
Дата: 04.02.10 22:48
Оценка:
Здравствуйте, MxKazan, Вы писали:

CC>>Т.е. мьсе трепло?

MK>В таком тоне я общаться не собираюсь.
Аналогично. Потому и прошу подтверждать ссылками.

MK>P.S. Пример
Автор: CreatorCray
Дата: 30.01.08

Я право не вижу там ничего подобного "вовсю доказывающих, что в указателях прелестного С++ нет ничего сложного"
Единственная фраза, содержащая слово "указатель" вот:

Блин, такое ощущение что программирование на С++ ассоциируется с суровой рукопашной с указателями, копипастом кода и т.п.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: С vs C++
От: _d_m_  
Дата: 05.02.10 08:51
Оценка:
Здравствуйте, bazis1, Вы писали:


B>>>Производительность не меньше? Какие тогда проблемы юзать язык в тех задачах, где от него есть польза, забив, труъ ли это ЯВУ? Или надо шашечки, а не ехать?

___>>Ехать. Но с комфортом.
B>Приведите пример задачи, которую нельзя "некриво" реализовать на С++ и я удивлю вас контрпримером

Да этими примерами забит весь КСВ. Оскомину уже набило.
Re[2]: загадка
От: bazis1 Канада  
Дата: 05.02.10 12:09
Оценка:
Здравствуйте, TarasCo, Вы писали:

TC>WTF, что это за язык?!

Это может быть любой язык, поддерживающий препроцессор
Re[28]: С vs C++
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.02.10 12:24
Оценка:
Здравствуйте, CreatorCray, Вы писали:

I>>Сколько месяцев этому проекту ?

I>>сколько релизов было ?
I>>Сколько тестеров, колько девелоперов ?
I>>Сколько кастомизаций/варантов деплоймента ?
I>>Сколько раз кастомер менял требования ?
I>>Сколько есть конкурентов у продукта ?

CC>Может тебе еще и номера счетов и пароли к SVN написать?


тяжелый случай. значит, зайдем с другой стороны,

объясни, почему рфакторинги, перечисленые в книге http://www.rsdn.ru/res/book/prog/rtp.xml
Автор(ы): Джошуа Кериевски
Книга "Рефакторинг с использованием шаблонов" представляет результаты многолетнего опыта профессионального программиста по применению шаблонов проектирования (паттернов). Авторский подход к проектированию состоит в том, что следует избегать как недостаточного, так и избыточного проектирования, постоянно анализируя готовый работоспособный код и реорганизуя его только в том случае, когда это приведет к повышению его эффективности, упрощению его понимания и сопровождения. Шаблоны проектирования — не панацея, так что бывают как ситуации, когда такая реорганизация должна выполняться с использованием шаблонов проектирования, так и ситуации, когда наилучшее решение состоит в отказе от них. Автор на основании как собственного, так и чужого опыта детально рассматривает различные признаки кода, требующего рефакторинга, описывает, какой именно рефакторинг наилучшим образом подходит для той или иной ситуации, и описывает его механику, подробно разбирая ее на конкретных примерах из реальных задач. Книга "Рефакторинг с использованием шаблонов" может рассматриваться и как учебник по рефакторингу для программиста среднего уровня, и как справочное пособие для профессионала, которое может подсказать, какое именно решение стоит принять в той или иной сложной ситуации.

в главах 6-9 неактуальны для с++ воообще, а не только вашей песочницы

хочу услышать внятный ответ, как наприер:

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

Пока что все что сказал ты и dr.Chaos сводится к абурду следующего вида —
дай дураку перфоратор/шуроповерт, он всю стену враз опаскудит, посему для настоящих мастеров перфоратор/шуроповерт не нужен в прынцыпе.
Re[29]: С vs C++
От: CreatorCray  
Дата: 05.02.10 12:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>объясни, почему рфакторинги, перечисленые в книге http://www.rsdn.ru/res/book/prog/rtp.xml
Автор(ы): Джошуа Кериевски
Книга "Рефакторинг с использованием шаблонов" представляет результаты многолетнего опыта профессионального программиста по применению шаблонов проектирования (паттернов). Авторский подход к проектированию состоит в том, что следует избегать как недостаточного, так и избыточного проектирования, постоянно анализируя готовый работоспособный код и реорганизуя его только в том случае, когда это приведет к повышению его эффективности, упрощению его понимания и сопровождения. Шаблоны проектирования — не панацея, так что бывают как ситуации, когда такая реорганизация должна выполняться с использованием шаблонов проектирования, так и ситуации, когда наилучшее решение состоит в отказе от них. Автор на основании как собственного, так и чужого опыта детально рассматривает различные признаки кода, требующего рефакторинга, описывает, какой именно рефакторинг наилучшим образом подходит для той или иной ситуации, и описывает его механику, подробно разбирая ее на конкретных примерах из реальных задач. Книга "Рефакторинг с использованием шаблонов" может рассматриваться и как учебник по рефакторингу для программиста среднего уровня, и как справочное пособие для профессионала, которое может подсказать, какое именно решение стоит принять в той или иной сложной ситуации.

I>в главах 6-9 неактуальны для с++ воообще, а не только вашей песочницы
Ты б хоть ссылку давал не на содержание а на сам текст
Неужто ты хочешь сказать что в

I>хочу услышать внятный ответ

Только после того, как ответишь что из этого умеет решарпер:

  • Replace Constructors with Creation Methods[/*]
  • Move Creation Knowledge to Factory[/*]
  • Encapsulate Classes with Factory[/*]
  • Introduce Polymorphic Creation with Factory Method[/*]
  • Encapsulate Composite with Builder[/*]
  • Inline Singleton[/*]
  • ComposeMethod[/*]
  • Replace Conditional Logic with Strategy[/*]
  • Move Embellishment to Decorator[/*]
  • Replace State-Altering Conditionals with State[/*]
  • Replace Implicit Tree with Composite[/*]
  • Replace Conditional Dispatcher with Command[/*]
  • Form Template Method[/*]
  • ExtractComposite[/*]
  • Replace One/Many Distinctions with Composite[/*]
  • Replace Hard-Coded Notifications with Observer[/*]
  • Unify Interfaces withAdapter[/*]
  • Extract Adapter[/*]
  • Replace Implicit Language with Interpreter [/*]
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
  • Забанили по IP, значит пора закрыть эту страницу.
    Всем пока
    Re[3]: загадка
    От: TarasCo  
    Дата: 05.02.10 13:00
    Оценка:
    B>Это может быть любой язык, поддерживающий препроцессор

    Ну, в общем да )). Но все же хотелось услышать конкретные предположения о языке( платформе, фреймворке ). Короче что за чудо и откуда?
    Да пребудет с тобою сила
    Re[30]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 05.02.10 13:13
    Оценка:
    Здравствуйте, CreatorCray, Вы писали:

    I>>хочу услышать внятный ответ

    CC>Только после того, как ответишь что из этого умеет решарпер:

    Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.

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

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

    Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.
    Т.е. да или нет, без виляний в твоем духе.
    Re[31]: С vs C++
    От: CreatorCray  
    Дата: 05.02.10 13:25
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>хочу услышать внятный ответ

    CC>>Только после того, как ответишь что из этого умеет решарпер:

    I>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.

    Зависят. Ты тут речь завёл с того, что С++ дескать такое говно что под него нет тулов для рефакторинга.

    I>>>Парсить С++ код та еще задача. до сих пор нет нормального средства рефакторинга, которое было бы таким же доступным как и то что есть в решарпере

    На что тебе был приведён тул — ассист.
    Ты начал ныть что мол, он слишком мало умеет.
    На что тебе было сказано что для рефакторинга в С++ он умеет достаточно.

    I>в готовом виде он конечно все это он не умеет

    Тогда какое отношение эта книга имеет к разговору о тулах для рефакторинга?

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

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

    I>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.

    Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.

    I>Т.е. да или нет, без виляний в твоем духе.

    Прекращай нести чушь.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Забанили по IP, значит пора закрыть эту страницу.
    Всем пока
    Re[32]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 05.02.10 14:14
    Оценка:
    ++равствуйте, CreatorCray, Вы писали:

    I>>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.

    CC>Зависят.

    Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."

    CC>На что тебе был приведён тул — ассист.


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

    CC>Ты начал ныть что мол, он слишком мало умеет.


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

    CC>На что тебе было сказано что для рефакторинга в С++ он умеет достаточно.


    Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++

    Ты так и не не отвтил на этот вопрос, а начал валять дурака

    >хочу услышать внятный ответ
    Только после того, как ответишь что из этого умеет решарпер:


    — ответа, заметь, не было

    I>>в готовом виде он конечно все это он не умеет

    CC>Тогда какое отношение эта книга имеет к разговору о тулах для рефакторинга?

    чуть ниже было пояснение или для тебя абзац текта слишком сложно осилить ?

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

    CC>Простые рефакторинги для методик разработки, принятых и используемых в С++ в ассисте есть.

    Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

    В чем особенность этого С++, что в нём не надо упрощать логику ? Что за мега-методики ?

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

    I>>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.

    CC>Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.

    Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

    I>>Т.е. да или нет, без виляний в твоем духе.

    CC>Прекращай нести чушь.

    Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

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

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

    Какие средсва в языке С++, что отменяют необходимость инструмента для воплощения этого и других принципов ?

    P.S. слушай, тебе AV не помогает постить ? А то ощущение у вас одна и та же болезнь. Ты хоть пересядь куда.
    Re[2]: С vs C++
    От: Antikrot  
    Дата: 05.02.10 14:42
    Оценка:
    Здравствуйте, shasa, Вы писали:

    S>Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.

    компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.
    Re[2]: С vs C++
    От: Eugeny__ Украина  
    Дата: 05.02.10 14:44
    Оценка:
    Здравствуйте, shasa, Вы писали:


    S>Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости.


    Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?
    Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
    There is no such thing as a winnable war.
    Re[33]: С vs C++
    От: CreatorCray  
    Дата: 05.02.10 15:00
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.

    CC>>Зависят.
    I>Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."
    Не дури голову. Прочитай ветку с начала обсуждения ассиста как средства рефакторинга для С++.

    CC>>На что тебе было сказано что для рефакторинга в С++ он умеет достаточно.

    I>Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++
    Потому что вопрос тролльский и к теме отношения не имеет.

    I>- ответа, заметь, не было

    Твоего в общем то тоже. Или ответом было "ничего не умеет"?

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

    CC>>Простые рефакторинги для методик разработки, принятых и используемых в С++ в ассисте есть.

    I>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

    Так. Ясно. Чукча у нас даже не читатель.
    Пруфлинк на мои слова где я утверждаю что "рефакторинги, приведеные в книге, не нужны в С++".
    Озаботься напоминанием себе о чём все таки идёт речь в этой ветке.

    I>>>Соответсвенно, хочу услышать внятный вопрос — нужны ли рефакторинги _тобою_ перечисленные в С++.

    CC>>Это не мною перечисленные. Это "рфакторинги, перечисленые в книге в главах 6-9" из твоего поста.
    I>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?
    А с чего ты взял вдруг что они не нужны? Я ничего подобного не утверждал.
    Не нужно свои фантазии приписывать другим.
    Или это такой новый метод троллинга?
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Забанили по IP, значит пора закрыть эту страницу.
    Всем пока
    Re[33]: С vs C++
    От: dr.Chaos Россия Украшения HandMade
    Дата: 05.02.10 15:21
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>мало, потому что задача, например, упрощения кода актуальна для любого языка, в т.ч. С++

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

    В С# и Java кроме классов ничего долгое время и не было
    Побеждающий других — силен,
    Побеждающий себя — Могущественен.
    Лао Цзы
    Re[34]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 05.02.10 15:29
    Оценка:
    Здравствуйте, CreatorCray, Вы писали:

    I>>Перечитай выделеное чуть выше. Не понял идею, каким образом необходимость конкретного рефакторинга для С++ зависит от решарпера ? Начни так "в нативном с++ рефакторинг ... не нужен, потому что решарпер в .Net ..."

    CC>Не дури голову. Прочитай ветку с начала обсуждения ассиста как средства рефакторинга для С++.

    I>Не валяй дурака, нужен ли эти рефакторинги для с++ или нет, не зависят от того, умеет ли это решарпер и любому, знакомому с логикой это понятно.
    Зависят.


    Твоей ответ чисто в КУ

    I>>Был даден список рефакторингов, ты так и не ответил на вопрос, почему эти рефакторинги нахрен не нужны в с++

    CC>Потому что вопрос тролльский и к теме отношения не имеет.

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

    I>Нужны высокоуровневые средтва, рефакторинг тот же.
    Зачем?
    Объясни?
    Какие средства надо? Что у тя входит в рефакторинг?
    Ты не меряй то, что надо для шарпа на плюсы.


    Это не троллинг — это принуждение к ответу.

    Или вот

    I>хочу услышать внятный ответ
    Только после того, как ответишь что из этого умеет решарпер:


    И снова ответа нет

    I>>- ответа, заметь, не было

    CC>Твоего в общем то тоже. Или ответом было "ничего не умеет"?

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

    и вот эти рефакторинги решарпер уже умеет, а ассист — нет.

    выделеное и три строчки понятны или нет ?

    Стало быть вопрос — нужны ли рефакторинги из книги при разработке на С++ или нет.

    В который раз задаю вопрос !

    I>>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

    CC>Так. Ясно. Чукча у нас даже не читатель.
    CC>Пруфлинк на мои слова где я утверждаю что "рефакторинги, приведеные в книге, не нужны в С++".

    I>Нужны высокоуровневые средтва, рефакторинг тот же.
    Зачем?
    Объясни?
    Какие средства надо? Что у тя входит в рефакторинг?
    Ты не меряй то, что надо для шарпа на плюсы.


    как трактовать твой недо-ответ я и не знаю.

    I>>Еще раз — почему рефакторинги, приведеные в книге, не нужны в С++ ?

    CC>А с чего ты взял вдруг что они не нужны? Я ничего подобного не утверждал.

    ты вообще ничего не утверждал и утверждал одновременно Я у тебя спросил — какие средства нужны, ответа не было.
    Только общая фраза "Простые рефакторинги для методик разработки, принятых и используемых в С++ в ассисте есть." и "Какие средства надо? Что у тя входит в рефакторинг?
    Ты не меряй то, что надо для шарпа на плюсы.
    "

    Нужны или не нужны рефакторинги из книги ты не сказал.

    Вот что было

    I>Нужны высокоуровневые средтва, рефакторинг тот же.
    Зачем?
    Объясни?
    Какие средства надо? Что у тя входит в рефакторинг?
    Ты не меряй то, что надо для шарпа на плюсы.


    Хочу услышать ответ примерно такой по форме:

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

    или

    средства рефакторинга указаные в книге Джошуа Кериевски не нужны при разработке на С++, потому что в С++ есть встроеные средтва которые вынуждают разработчика соблюдать принципы проектирования, как например принцип замещения Лисков и тд и тд.
    Re[34]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 05.02.10 15:32
    Оценка:
    Здравствуйте, dr.Chaos, Вы писали:

    I>>мало, потому что задача, например, упрощения кода актуальна для любого языка, в т.ч. С++

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

    DC>В С# и Java кроме классов ничего долгое время и не было


    Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.

    А получается наоборот — классы есть и в С++ а инструмента для их рефакторинга нет, даже самого простого.
    Re[35]: С vs C++
    От: dr.Chaos Россия Украшения HandMade
    Дата: 05.02.10 15:53
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.


    I>А получается наоборот — классы есть и в С++ а инструмента для их рефакторинга нет, даже самого простого.


    В lisp-е тоже есть классы, а средств для рефакторинга нету . Просто вселенский заговор какой-то.
    Побеждающий других — силен,
    Побеждающий себя — Могущественен.
    Лао Цзы
    Re[36]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 05.02.10 15:56
    Оценка:
    Здравствуйте, dr.Chaos, Вы писали:

    I>>Это значит, что для них и инструментов надо меньше. Например для С# и Джавы не нужны инструменты рефакторинга множественного наследования или рефакторнга макросов.


    I>>А получается наоборот — классы есть и в С++ а инструмента для их рефакторинга нет, даже самого простого.


    DC>В lisp-е тоже есть классы, а средств для рефакторинга нету . Просто вселенский заговор какой-то.


    И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?

    Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?
    Re[38]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 05.02.10 16:13
    Оценка:
    Здравствуйте, dr.Chaos, Вы писали:

    I>>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?


    I>>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?


    DC>А какое это имеет отношение к рефакторингам Кириевски? Кириевски написал — все должны делать. ёпт!


    На вопросы для начала ответь.

    Есть задача упрощения кода — она на любом языке решается быстрее с инструментом, нежели без оного.

    нет никаких рефакторингов Кериевски, в его книги приведены самые общие рефакторинги, которые нужны везде где есть классы например.

    В лиспе тоже есть классы, представь себе.
    Re[37]: С vs C++
    От: Mr.Cat  
    Дата: 05.02.10 16:24
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:
    I>И насколько сильно Лисп распространен ? Вышел уже за пределы стат погрешности или 50 лет надо ждать ?
    Лисп прекрасно живет и развивается в своем комьюнити. И будет так же жить и развиваться в ближайшие 50 лет. А вот судьба нынешнего мейнстрима предрешена: c#,java ждет судьба кобола, питон — в самом лучшем случае судьба tcl.

    I>Ты в курсе, что сделали в Яхе, когда оттуда ушел Грехем со своей бандой лисперов ?

    Набрали команду инди-кодеров, продолбали все полиме^W акции и превратились в моральных пигмеев?
    Re[8]: С vs C++
    От: Aleх  
    Дата: 05.02.10 19:40
    Оценка:
    Здравствуйте, dr.Chaos, Вы писали:

    DC>Здравствуйте, Aleх, Вы писали:


    A>>Например преобразование типа строки с буфером 20 символов к строке с буфером 50 символов.

    A>>Естественно данный подход не будет давать оптимальных оптимизаций, но всё же это лучше чем вообще ничего. К тому же С++ не дает ничего лучше.
    A>>>>Тогда причем здесь это, я же описал совершенно другой случай.
    DC>Ничем он особо не лучше: от параметров шаблонов пухнет страшно код, да и засунуть 2 такие строки в один массив целая проблема. Т.е. Здесть возможно даже аллокатор стоит делать не параметром шаблона, а параметром конструктора.
    Можно и так, только если без параметра шаблона, в теории будет медленнее.

    A>>>>>>Во вторых, контейнер map тоже должен быть настраиваемым. Например, в качестве дополнительного параметра шаблона должно быть возможно выбирать способ внутреннего представления отображения (double_hashing, chain_hashing, red_black_tree, avl_tree, ordered_vector), которое никак не влияет на интерфейс map.


    A>>Ну и что здесь плохого? Александреску, например, пропагандирует такой подход.


    DC>Скажем по другому: чем это лучше 5ти классов map, map_double_hashing и т.д. с одним интерфейсом? Допустим параметразовать можно было бы хеш функцией, но все эти 5 реализаций карты очень различаются и найти что-то общее в рамках одной реализации тут ИМХО будет сложнее, да и смысл?

    Различаться будут только реализацией. Ну а смысл в том, чтобы сократить объем кода библиотеки: предполагается, что эти же внутренние представления можно задействовать для других контейнеров — например, set.
    Re[3]: С vs C++
    От: shasa  
    Дата: 05.02.10 20:11
    Оценка:
    Здравствуйте, Eugeny__, Вы писали:
    E__>Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?
    Эээ... как бы да, если быть точнее после того как хотя бы одна переменная была использована, объявлять переменные нельзя (это касается Си).
    Re[3]: С vs C++
    От: shasa  
    Дата: 05.02.10 20:13
    Оценка:
    Здравствуйте, Antikrot, Вы писали:

    A>Здравствуйте, shasa, Вы писали:


    S>>Да я бы не стал никогда писать на чистом си ...

    A>компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.

    Компилятор со мной уже согласен, coding guidelines — это не ко мне
    Re[4]: С vs C++
    От: Antikrot  
    Дата: 05.02.10 20:55
    Оценка:
    Здравствуйте, shasa, Вы писали:

    S>>>Да я бы не стал никогда писать на чистом си ...

    A>>компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.
    S>Компилятор со мной уже согласен,
    компилятор С++. компилятор С не согласится с, хотя бы, class. По крайней мере, я таких не знаю (#define class struct не считается). то есть пишешь ты на С++, и упоминать С всуе совсем незачем было. просто бы сказал, что в споре C vs С++ ты за C++.

    S>coding guidelines — это не ко мне

    вот и индусы так говорят, и, что хуже, делают
    Re[2]: С vs C++
    От: Antikrot  
    Дата: 05.02.10 20:57
    Оценка:
    Здравствуйте, shasa, Вы писали:

    S>Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости.


    #pragma flame on
    переменные вообще не нужны
    Re[4]: С vs C++
    От: CreatorCray  
    Дата: 05.02.10 21:01
    Оценка:
    Здравствуйте, shasa, Вы писали:

    E__>>Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?

    S>Эээ... как бы да, если быть точнее после того как хотя бы одна переменная была использована, объявлять переменные нельзя (это касается Си).
    в C99 стало можно объявлять не только в начале блока.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Забанили по IP, значит пора закрыть эту страницу.
    Всем пока
    Re[5]: С vs C++
    От: Antikrot  
    Дата: 05.02.10 21:11
    Оценка:
    Здравствуйте, CreatorCray, Вы писали:

    E__>>>Ты точно ничего не путаешь? Кто сказал, что в си нужно объявлять переменные только в начале блока?

    S>>Эээ... как бы да, если быть точнее после того как хотя бы одна переменная была использована, объявлять переменные нельзя (это касается Си).
    CC>в C99 стало можно объявлять не только в начале блока.
    мне что-то кажется, что у него компилятор С99 не очень поддерживает
    Re[39]: С vs C++
    От: Mr.Cat  
    Дата: 08.02.10 14:28
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:
    I>Нужен интрумент для решения текущих задач бизнеса
    У всех разные задачи и, соответственно, применяются разные инструменты их решения. Где-то нужна профессиональная команда и высокотехнологичные средства разработки, навроде лиспа. А чтобы торговать контентом почтовых ящиков клиентов — и программировать-то ничего не надо. Jedem das Seine.
    Re[5]: загадка
    От: TarasCo  
    Дата: 08.02.10 14:39
    Оценка:
    +1.

    C — живее всех живых.
    Да пребудет с тобою сила
    Re[3]: С vs C++
    От: Privalov  
    Дата: 08.02.10 14:40
    Оценка:
    Здравствуйте, Antikrot, Вы писали:

    A>компилятор или coding guidelines вполне может иметь своё мнение по этому вопросу. позови посмотреть когда будешь доказывать им свою точку зрения.


    Сдается мне, товарищ еще ни разу не нарывался на функции в пару-тройку тысяч строк и без локальных переменных
    Re[40]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 09.02.10 10:45
    Оценка:
    Здравствуйте, Mr.Cat, Вы писали:

    I>>Нужен интрумент для решения текущих задач бизнеса

    MC>У всех разные задачи и, соответственно, применяются разные инструменты их решения. Где-то нужна профессиональная команда и высокотехнологичные средства разработки, навроде лиспа.

    Ну да, есть проектов, меньше статпогрешности
    Re[41]: С vs C++
    От: Mr.Cat  
    Дата: 09.02.10 18:06
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:
    I>Ну да, есть проектов, меньше статпогрешности
    Извини, я не смог уловить смысла этого высказывания.
    Re[22]: С vs C++
    От: Игoрь Украина  
    Дата: 09.02.10 23:09
    Оценка:
    Здравствуйте, Vamp, Вы писали:

    V>
    V>button1.x = 30;
    V>frame.redraw();
    V>

    V>Автоматическая перерисовка — зло.
    Это еще почему? Зло оно только в случае классической виндовой архитектуры и библиотек, так как может хреново выглядеть из-за частых перерисовок. В WPF все иначе, и это реально удобнее.
    Re[6]: С vs C++
    От: Игoрь Украина  
    Дата: 09.02.10 23:37
    Оценка:
    Здравствуйте, Vamp, Вы писали:

    IID>>Тем не менее это не мешает "мясо" библиотеки писать на С++, а наружу выставлять pure-С API. Вон, в винде дофига юзерленда именно так сделано.

    V>Ну это кривизна необыкновенная. Когда два С++ класса общаются между собой на C, и лишены возможностей взимодействовать с использованием возможностей С++. И то, как это сделано в ВинАПИ, кстати, есть тоже кривулина.
    +1. Причем не понятно, почему сторонники С# так "любят" спорить о пропертях, как по мне, херня на постном масле, полезная в C#, но не особо ненужная в С++, а вот отсутствие стандартизированной модульности в С++ на уровне бинарных модулей, вот это реальный минус С++.
    Re[23]: С vs C++
    От: koandrew Канада http://thingselectronic.blogspot.ca/
    Дата: 17.02.10 16:56
    Оценка:
    Здравствуйте, Aleх, Вы писали:

    A>Теоретически, среда разработки может подсказывать, что там происходит на самом деле. А вообще, в С++ много конструкций с неочевидной семантикой (использование перегруженных операторов). Многие поклонники Си говрят, что они по этой причине не переходят на С++. Если же грамотно использовать все эти фитчи, предоставляющие альтернативную семантику для привычных конструкций, проблемы не будет. Проблема в программистах недостаточно знающий язык или недостаточно хорошо умеющий проектировать интерфейсы классов.


    По-моему, проблема не столько в наличии выделенного, сколько в том, что их много...
    [КУ] оккупировала армия.
    Re[13]: С vs C++
    От: ollv СССР https://youtu.be/DQDoYs6wHoo
    Дата: 18.02.10 00:06
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Здравствуйте, CreatorCray, Вы писали:


    I>>>>>Я не сильно слежу за ассистом. он умеет ли он (2005я)

    CC>>>>Не могу представить когда в C++ может понадобиться аналог пункта "Convert"

    I>>>Ну так в с++ нет такого понятия как интерфейсы, проперти, индексеры, эвенты и тд.

    I>>>Есть сущности аналогчные перечисленым, но на уровне инструментов они не поддерживаются, этот код ты лопатишь руками.
    CC>>Лопатишь это как то громко сказано. В языке всей этой ботвы нет. Этот функционал обеспечивается библиотеками.

    I>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.

    Это в С++ сделать возможно, а вот ты приведи код который позволяет в компайлтайме узнатьсуществование филды/метода у класса ивыбрать дальнейший алгоритм компиляции.
    Compiler can be as trained AI but can't compose music.
    Antheil piano jazz sonata. Я болен ПГМ.
    Re[2]: С vs C++
    От: Vain Россия google.ru
    Дата: 18.02.10 00:18
    Оценка:
    Здравствуйте, shasa, Вы писали:

    S>Здравствуйте, abdul.zycor, Вы писали:

    AZ>> ... В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.
    S>Да я бы не стал никогда писать на чистом си или сипипи. Если мне не надо конструктора в объекте я объявлю струтуру, нужен конструктор объявлю класс. Нет смысла все функции прятать в методы. Нет смысла обявлять все переменные в начале блока, как в си, а есть смысл объявлять по мере необходимости. В общем чистота программы в плане написания на си или на сипипи ненужна.

    Святая простота..
    [In theory there is no difference between theory and practice. In
    practice there is.]
    [Даю очевидные ответы на риторические вопросы]
    Re[14]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 18.02.10 09:05
    Оценка:
    Здравствуйте, ollv, Вы писали:

    I>>Вот приведи сюда код который пропертю реализует и покажи средства инкапуляции филда в пропертю.

    O> Это в С++ сделать возможно,

    Ты код покажи, желательно, что бы строчек было поменьше.

    O>а вот ты приведи код который позволяет в компайлтайме узнать существование филды/метода у класса ивыбрать дальнейший алгоритм компиляции.


    Если тебе надо только для компиляции, то это к доктору. Если тебе нужно решить кое какую задачу, это совсем другое.
    Re[3]: С vs C++
    От: Head Ache  
    Дата: 19.02.10 02:01
    Оценка:
    Здравствуйте, frogkiller, Вы писали:

    I>>Есть в с++ нечто, что рождает монстров вроде буста и стл, и благодаря им так и сложилось с серверами.


    F>На самом деле ни буст ни стл не являются необходимым условием написания программ, даже таких хитрых, как промышленный веб-сервер. Ни что не мешает с нуля сделать свои библиотеки с преферансом и гетерами — так как это обычно делают на голом С, типичный пример apache и его apr + apr-util.


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


    F>Имхо никакой разницы нет — поддержка этих языков практически одинакова.


    F>Опять-таки ситуация с С и С++ в этом плане практически одинакова. И она не является препятствием для написания серверов


    Просто подумай, почему STL начала широко применяться практически сразу после выхода первых версий. Без наличия пространной документации.
    Что такое изучение ворнингов компилятора на vc 4.2 например? — ну п... полный!
    Что этих мышей заставляло и заставляет плакать и колоться???

    Я бы разделил программистов на 2 группы:
    первая — уже поняли, что STL (и boost, и ему подобные расширения) не имеют альтернативы в других языках
    вторая — мне их жалко...

    Конкретный пример из личной практики.
    Крайне глючная DLL (примерно 50000 строк гавнокода, писалась 1.5 года, все ошибки "плавающие", в debug не воспроизводятся) "на чистом C" переписана на 70% функционала примерно за 2 недели. Причем практически "на автомате", без мучительных усилий. Прошел год — еще не видел ни одной ошибки (при отлаженной системе транспортировки багов). Ах, да. Был ли "рефакторинг". Из старых исходников актуальны были примерно 1-2% кода, остальное сделано просто по описанию функционала.
    Этот аккаунт покинут.
    Re[2]: С vs C++
    От: Head Ache  
    Дата: 19.02.10 04:13
    Оценка:
    Здравствуйте, bazis1, Вы писали:

    B>Здравствуйте, abdul.zycor, Вы писали:


    AZ>>В общем приводите свое мнение, высказывайтесь, только без лишнего фанатизма пожалуйста.

    B>C++ позволяет сильно автоматизировать и упрощать многие вещи (та же работа со строками или STL). Это не означает, что на C++ нельзя написать код, идентичный по производительности коду на C и при этом занимающий в 2 раза меньше строк. Но означает, что для того, чтобы написать громоздкое приложение на C надо писать много кода, на C++ для этого достаточно пару раз не задуматься о последствиях и поюзать стандартные конструкции кривым способом.

    Не понял, что "означает". Почему обязательно надо юзать "кривым способом" (а какой прямой).

    B>Например, хэш-таблицу для повторяющихся строк на C можно реализовать, вручную распихав строки в едином блоке без дублирования совпадающих подстрок и сделав вычисление хэшей. Займет это N строк. На C++ все можно реализовать аналогично низкоуровнево, займет это меньше N строк и будет иметь красивую модульную структуру. НО всегда найдется программист, который поюзает std::map<std::string, std::string>, не вьезжая в принцип его работы, чем увеличит требуемый размер памяти в разы.


    Претензии к map или string? К памяти? Вообще там не въезжая можно породить с десяток решений под разные требования (и все не "кривые").
    Насколько я в курсе, std::map<std::string, std::string> хотя бы работает. Если тот же автор то же самое ручками писать начнет. Ой-ой.
    Просто не раз видел, какой бред можно написать, например вместо sort -> unique.
    Вплоть до создания временных таблиц на SQL и выполнения каких-то мутных select. С полным утоплением в г... всех зависимостей, т.е. при изменении требований вообще неясно где копать.

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


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


    Не-а. Он будет руками махать вместо самолета.
    Этот аккаунт покинут.
    Re: Re:
    От: trop Россия  
    Дата: 19.02.10 09:22
    Оценка:
    AZ>Всем привет! Не так давно стал изучать программирование для unix систем.

    c++ не очень надёжный язык, не собрано достаточно статистики,
    имеет некоторые неявные нюансы на этапе разработки.

    системы реального времени и бортовые системы пишут в основном на c.
    марсоходы, которые >3 лет ездили по марсу
    собраны на powerpc 120 и осрв vxworks (язык c),
    ядро vxworks имеет статистику более 30 лет
    и поэтому считается наиболее отказоустойчивой осрв
    -
    Re[3]: С vs C++
    От: Head Ache  
    Дата: 25.02.10 06:33
    Оценка:
    Здравствуйте, bazis1, Вы писали:

    B>Здравствуйте, BigBoss, Вы писали:


    BB>>Здравствуйте, abdul.zycor, Вы писали:


    AZ>>>Какие могут быть обьяснения тому?


    BB>>http://www.kernel.org/pub/linux/docs/lkml/#s15-3

    B>[quote]There is no point in just compiling the kernel with g++ and writing the odd function in C++, this would just result in a confusing mix of C and C++ code. Either the kernel is left in C, or it's all moved to C++.[/quote]
    B>Ну это просто зашибись аргумент. Типа, или всё бросить и начать сначала, или ничего не трогать и закрыть глаза на удобные фичи C++. Ну типа нах нам автоматическая коробка, ведь это надо все машины с ручной в утиль сдать, а потом выпускать на улицы автомат. А то чтобы по одной улице одни ездили на "ручке", а другие на "автомате" — это же некошерно. Да и Торвальдс не разрешит.
    B>О том, как бы поюзать часть удобных фич C++, дабы быстрее и качественнее решить проблемы, стоящие перед разработчиками сейчас, никто и не задумывается. Элементарно можно создать inline wrapper-ы на С++ вокруг существующего API на C — вызывать будет удобнее (те же mutex guard-ы можно красиво реализовать), размер бинаря не увеличит, ибо все разрезолвится во время компиляции. Ту же VFS сделать на базе виртуальных функций, чтобы унаследовал класс, переопределил 3 метода, вернул new MyClass(); из entry point — и VFS юзабельна. Но ведь нет — куда кошернее руками заполнять таблицы указателей и кастить inode->extension к struct my_vfs_driver_extension в каждом вызове...

    Это все фигня. Реальный аргумент один. В том же тексте ниже, курсивом:

    the whole C++ exception handling thing is fundamentally broken . It's _especially_ broken for kernels.

    Ядро НЕ ПИШУТ на С++. Потому что в принципе исключения не могут правильно работать в режиме ядра.
    Точнее, на уровне ядра их поддержка и реализована, как относительно "высокоуровневый" сервис, на С + ассемблер.
    Этот аккаунт покинут.
    Re[2]: Re:
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.02.10 06:54
    Оценка:
    Здравствуйте, trop, Вы писали:

    AZ>>Всем привет! Не так давно стал изучать программирование для unix систем.


    T>c++ не очень надёжный язык, не собрано достаточно статистики,

    T>имеет некоторые неявные нюансы на этапе разработки.

    Там куда ни ткни, надо десяток-другой нюансов учесть. Исключение бросить, целая задача — надо пройтись по тем местам где ловят, словить — надо пройтись по тем местам, где бросают.
    Re[5]: С vs C++
    От: CreatorCray  
    Дата: 25.02.10 07:50
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    HA>>Я бы разделил программистов на 2 группы:

    HA>>первая — уже поняли, что STL (и boost, и ему подобные расширения) не имеют альтернативы в других языках
    HA>>вторая — мне их жалко...

    I>Чуток наоборот, первая — это челы понимают, что без stl или boost за другими языками не угнаться даже при правильном ветре.

    А вторая ни за кем не гонится и спокойно делает и сдаёт проекты.
    Первым нужны "шашечки", вторым — "ехать".
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Забанили по IP, значит пора закрыть эту страницу.
    Всем пока
    Re[5]: С vs C++
    От: Cadet  
    Дата: 14.05.10 13:10
    Оценка:
    Здравствуйте, landerhigh, Вы писали:

    L>Я всегда говорил, говорю и буду говорить, что программист, которому нужен отлЯдчик для только что написанного им кода — плохой, негодный программист.


    А если в этом коде вынужденно используется либа, в сырцах которой хрен разберешься или они недоступны, программист ее писавший уволился, а результат как всегда нужен вчера и времени вдумчиво подобрать альтернативу нет, или нельзя подбирать альтернативу?
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1468>>
    Re[5]: С vs C++
    От: Head Ache  
    Дата: 23.05.10 15:40
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Чуток наоборот, первая — это челы понимают, что без stl или boost за другими языками не угнаться даже при правильном ветре.


    Это серьезно? boost за другими языками гоняется? Вы хоть понимаете, о чем пишете?
    Я вижу обратное. Кривые попытки хотя бы как-то воспроизвести хотя бы внешне похожую функциональность.
    Потому что реальной мощью, основанной на возможностях С++ даже близко не пахнет.
    Этот аккаунт покинут.
    Re[6]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 23.05.10 17:22
    Оценка:
    Здравствуйте, Head Ache, Вы писали:

    HA>Я вижу обратное. Кривые попытки хотя бы как-то воспроизвести хотя бы внешне похожую функциональность.

    HA>Потому что реальной мощью, основанной на возможностях С++ даже близко не пахнет.

    Мощь есть, это так. Только что бы эта мощь не задавила программиста, надо вагон времени убить, года три, не меньше.

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

    Еще лет 5 назад было гораздо проще.
    Re[8]: С vs C++
    От: Head Ache  
    Дата: 24.05.10 00:42
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?


    Узнают о boost, когда уже нет времени учиться.
    Время обучения потрачено непонятно на что.
    Нет знания ни ОС, ни основ теории, ни хотя бы одного языка на профессиональном уровне.
    С таким багажом про boost лучше ничего не знать.
    Этот аккаунт покинут.
    Re[9]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 24.05.10 01:04
    Оценка:
    Здравствуйте, Head Ache, Вы писали:

    ГВ>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

    HA>Узнают о boost, когда уже нет времени учиться.

    Это как это? До пенсии всего ничего, что ли?

    HA>Время обучения потрачено непонятно на что.


    Время обучения чему?

    HA>Нет знания ни ОС, ни основ теории, ни хотя бы одного языка на профессиональном уровне.

    HA>С таким багажом про boost лучше ничего не знать.

    Что-то я тебя не понимаю.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[8]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 24.05.10 08:03
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    I>>Мощь есть, это так. Только что бы эта мощь не задавила программиста, надо вагон времени убить, года три, не меньше.


    ГВ>То есть?


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

    I>>Сейчас например найти чела, который умеет шаблоны С++ на уровне достаточном для буст или хотя бы стл крайне сложно.


    ГВ>Не понял. На уровне, достаточном для того, чтобы написать буст, или чтобы использовать буст?


    Использовать.

    I>>Еще лет 5 назад было гораздо проще.


    ГВ>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?


    За 5 лет С++ подрястерял позиции, а студенты в основном джавой и дотнетом интересуются.
    Re[11]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 24.05.10 09:13
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    ГВ>>>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?

    HA>>>Узнают о boost, когда уже нет времени учиться.
    ГВ>>Это как это? До пенсии всего ничего, что ли?
    I>Бусту надо учиться, а в дотнет и джаву можно идти буквально сразу.

    Хм. Это для меня новость, вообще-то. Бусту надо учиться никак не более, чем надо учиться практическому программированию на C++. Он, собственно, для того и предназначен — для решения вполне определённых задач.

    С другой стороны — да, приличный C++-ник получается, где-то, не меньше, чем за год. В прочем, с другими языками примерно то же самое.

    HA>>>Время обучения потрачено непонятно на что.

    ГВ>>Время обучения чему?
    I>Время обучения в университете. Бусту там не учат.

    А... Понятно. Опять университет виноват?
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[9]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 24.05.10 09:20
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>Мощь есть, это так. Только что бы эта мощь не задавила программиста, надо вагон времени убить, года три, не меньше.

    ГВ>>То есть?
    I>То есть входная планка для буста гораздо выше, чем для дотнета или джавы.

    Не понял. На что нужно потратить три года? На буст? Чепуха. На C++? Тоже преувеличение — года вполне достаточно, а базовый язык вообще осваивается за несколько месяцев. Чему нужно три года учиться?

    I>>>Сейчас например найти чела, который умеет шаблоны С++ на уровне достаточном для буст или хотя бы стл крайне сложно.

    ГВ>>Не понял. На уровне, достаточном для того, чтобы написать буст, или чтобы использовать буст?
    I>Использовать.



    I>>>Еще лет 5 назад было гораздо проще.

    ГВ>>Куда ж они делись-то? В нирвану поуходили, овладев означенной мощью?
    I>За 5 лет С++ подрястерял позиции, а студенты в основном джавой и дотнетом интересуются.

    Дык, дело-то, наверное, как раз в этом, а не в какой-то гиперсложности использования буста.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[12]: С vs C++
    От: Head Ache  
    Дата: 24.05.10 14:49
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    HA>>>>Узнают о boost, когда уже нет времени учиться.

    ГВ>>>Это как это? До пенсии всего ничего, что ли?
    вообще надо жить как-то, чтобы деньги платили.

    I>>Бусту надо учиться, а в дотнет и джаву можно идти буквально сразу.

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

    ГВ>Хм. Это для меня новость, вообще-то. Бусту надо учиться никак не более, чем надо учиться практическому программированию на C++. Он, собственно, для того и предназначен — для решения вполне определённых задач.

    и вообще это просто набор библиотек в стиле "бери и пользуйся". тем не менее, вещи вроде mpl или concept check доходят далеко не сразу. Или просто не доходят никогда.
    Этот аккаунт покинут.
    Re[13]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.05.10 01:11
    Оценка:
    Здравствуйте, Head Ache, Вы писали:

    HA>>>>>Узнают о boost, когда уже нет времени учиться.

    ГВ>>>>Это как это? До пенсии всего ничего, что ли?
    HA>вообще надо жить как-то, чтобы деньги платили.

    Ну, с этим, конечно, не поспоришь.

    I>>>Бусту надо учиться, а в дотнет и джаву можно идти буквально сразу.

    HA>вот таких пинком под зад выставлять надо из нормальных проектов
    HA>самый волшебный язык не спасет от невежества

    Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++. Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу. Во всяком случае, такой вывод можно сделать из разнообразных деклараций.

    ГВ>>Хм. Это для меня новость, вообще-то. Бусту надо учиться никак не более, чем надо учиться практическому программированию на C++. Он, собственно, для того и предназначен — для решения вполне определённых задач.

    HA>и вообще это просто набор библиотек в стиле "бери и пользуйся". тем не менее, вещи вроде mpl или concept check доходят далеко не сразу. Или просто не доходят никогда.

    mpl и concept_check, как раз далеко не всегда нужны (не считая внутренностей буста). Но я в упор не понимаю, почему нужно так резко шугаться буста в части остальных библиотек.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[14]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.05.10 09:36
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++.


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

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

    >Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу. Во всяком случае, такой вывод можно сделать из разнообразных деклараций.


    На простом языке можно сосредоточиться на задаче, а не заниматься всем подряд.

    Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.

    ГВ>mpl и concept_check, как раз далеко не всегда нужны (не считая внутренностей буста). Но я в упор не понимаю, почему нужно так резко шугаться буста в части остальных библиотек.


    Шугаться не нужно, но практика показывает, что буст даже у сиплюсника можно не спрашивать, если опыт работы менее 3х лет.
    Re[15]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.05.10 11:37
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    ГВ>>Вот это как раз для меня один из самых больших парадоксов IT-отрасли. Казалось бы, навыки именно программирования нужны примерно одни и те же, что для Java, что для .Net, что для C++.


    I>Вобщем то это в корне не верно. В случае с С++ нужно знать и уметь множество всякой всячины, которая непосредственно к программухе не относится, например линковка та же.


    Упс. Не, ну это полный ништяк. Программист, который не понимает, что такое сопоставление символического имени блоку бинарного кода — это анекдот (я в курсе, что их много есть, менее анекдотичными они от этого не становятся). Собственно, этих, альтернативно одарённых, я в расчёт не беру. А в противном случае, линковку как-то особенно "понимать" никакой нужды нет.

    I>Кроме того, в самом С++ столько подводных камней, что даже для опытного разработчика довольно сложно пересесть на плюсы.


    Никто не говорит "сразу", но и не три года, ёлки зелёные!

    ГВ>>Они сразу не появляются, каким бы простым язык ни был. Но нет — почему то считается, что на "простом" языке можно писать любому неучу. Во всяком случае, такой вывод можно сделать из разнообразных деклараций.


    I>На простом языке можно сосредоточиться на задаче, а не заниматься всем подряд.

    I>Кроме того, с .Net cкорост обученяи много выше С++ потому что есть такие инструменты как Reflector или, например, качественные средства рефакторинга.

    Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...

    ГВ>>mpl и concept_check, как раз далеко не всегда нужны (не считая внутренностей буста). Но я в упор не понимаю, почему нужно так резко шугаться буста в части остальных библиотек.

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

    Я говорю "шугаться", поскольку был свидетелем такого "шугания" — даже приходилось по требованию заказчика (внимание — хи-хи) кромсать буст, чтобы не "пугать программистов". Идиотизма ситуации это не отменяет, но зато какая основа для положительных эмоций!
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[15]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.05.10 11:44
    Оценка:
    Здравствуйте, Eugeny__, Вы писали:

    E__>Дело в том, что управляемые языки не содержат такого жииирного источника багов(особенно, особенно для начинающих), как проблемы с памятью. Потому, действительно, клепать формы может даже не особо обремененный знаниями "специалист". И программа не будет постоянно падать, или отжирать память, как если бы было на плюсах у программиста такого же уровня. Станет ли такой человек профи, или нет — вопрос второй.


    Именно.

    E__>Но порог вхождения для написания несложного коммерческого говнософта(этот факт никого, кстати, не волнует: главное, чтобы деньги приносил) у С/C++ и у управляемых языков весьма различен.


    Вот! Понимаешь, я сказал то же самое, но в более обтекаемой форме. Именно, что для, э-э-э... Для софта, склёпанного на коленке как раз критична "скорость вхождения". Вчера таксист, сегодня — комбобоксорасполагатель. "Расставляю комбобоксы за еду! А за бутерброд дополнительно накидаю кнопочек!"

    E__>То есть, дело в задачах. При написании сложных систем, требоватальных к памяти/производительности/устойчивости граница не так заметна. На чем не пиши, нужны профессионалы(и тут уже нужны знания и про нюансы работы GC, и понимание, почему ресурсы надо обязательно освобождать, и прочая тысяча нюансов). А если нужно написать софтину о десятке формочек... За памятью сборщик проследит, а других таких масштабных источников багов для такого приложения вроде как уже и нет.


    Угу, угу. Только, ИМХО, дело не столько в задачах, сколько в отношении к потребителю этих самых задач, то есть — решений.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[43]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.05.10 11:52
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>Ну да, есть проектов, меньше статпогрешности

    MC>>Извини, я не смог уловить смысла этого высказывания.
    I>Это значит что Лиспа в индустрии по большому счету не существует, т.к. проектов на нем, хучь по чем меряй, меньше статпогрешности.

    Я бы сказал так: тем, кто использует лисп, глубоко плевать на способы измерения индустрии.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[15]: С vs C++
    От: Head Ache  
    Дата: 25.05.10 12:26
    Оценка:
    Здравствуйте, Eugeny__, Вы писали:

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


    Почему только "управляемые" языки? (нет, эта ненавязчивая реклама везде достанет...)
    Куда делись еще сотня названий.
    Да и в управляемых средах легко похожие проблемы заиметь, достаточно подергать winapi или неуправляемые dll.
    И когда это у "специалистов" были проблемы со средствами воспроизводства г..кода.
    Еще со времен виндоус 3.1 было на чем оттянуться.
    Среднее время клепания формочки/отчета, я заметил, некая константа, которая последние лет 10 стабильна.
    Этот аккаунт покинут.
    Re[44]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.05.10 13:13
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    I>>>>Ну да, есть проектов, меньше статпогрешности

    MC>>>Извини, я не смог уловить смысла этого высказывания.
    I>>Это значит что Лиспа в индустрии по большому счету не существует, т.к. проектов на нем, хучь по чем меряй, меньше статпогрешности.

    ГВ>Я бы сказал так: тем, кто использует лисп, глубоко плевать на способы измерения индустрии.


    Что с того ?
    Re[45]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.05.10 15:49
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>>>Ну да, есть проектов, меньше статпогрешности

    MC>>>>Извини, я не смог уловить смысла этого высказывания.
    I>>>Это значит что Лиспа в индустрии по большому счету не существует, т.к. проектов на нем, хучь по чем меряй, меньше статпогрешности.
    ГВ>>Я бы сказал так: тем, кто использует лисп, глубоко плевать на способы измерения индустрии.

    I>Что с того ?


    Ничего. Это моё алаверды в порядке пикировки. К этому:
    Автор: Ikemefula
    Дата: 05.02.10


    Нужен интрумент для решения текущих задач бизнеса, а Лисп — нет, не нужен.


    Оценки объёма сектора лиспа (тем более — умозрительные) никак не влияют на процесс его использования теми, кто хочет лисп использовать. Вот такая загадка природы.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[18]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 25.05.10 17:23
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?


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

    ГВ>Хм. Ты навёл меня на клёвую мысль, надо написать в резюме: "практические навыки работы с редактором связей — 17 лет". А потом отлавливать особо грамотных по вопросам, что это за связи такие.


    Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.

    ГВ>>>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...

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

    ГВ>Есть мнение, что количество нужных видов растёт прямо пропорционально лёгкости их получения. Есть также ещё одно мнение: что время получения финального вида слабо зависит от количества промежуточных прикидок. Почему-то я согласен с ними обоими.


    А какое

    ГВ>Хм. Либо ученик юзает шаблоны, тогда будет большое время компиляции, но квалификация уже очевидна; либо ученик шарахается шаблонов, но тогда откуда взяться большому времени компиляции? Неужели он, пугающийся шаблонов, собирает настолько большой проект?


    Это зависит от проекта, а не от ученика.

    I>>Кроме того, в С++ затруднено юниттестирование, написание моков.


    ГВ>При чём тут обучение языку? Чтобы вписывать нужные буквы в мок, необходимо уже понимать — что, куда, почему. А проще всего проверять себя маленькими программками, где нет ничего лишнего. Зачем тут какие-то специальные средства мокогенерирования?


    Это ж каменный век.

    ГВ>Мы всё ещё про обучение?


    Да, это все оно же. Моки, тесты снижают порог вхождения в проект/фреймворк.

    ГВ>Одному мне это кажется паранойей (буст — общеупотребительный инструмент)? Знаешь, если так рассуждать, то в программирование вообще лучше не соваться, а то, так и будешь всё время переписывать продукт, пугаясь того, что чайников на разработку не найдётся. Что самое забавное, как раз C++ на сегодняшний день — самый, что ни на есть, стабильный во всех отношениях язык, в отличие от. А буст вообще частью уже перекочевал в стандарт.


    Что с того что он в стандарте ? Его изучать чтоли не нужно ?
    Re[19]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 25.05.10 22:44
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    ГВ>>При том, что это самое сопоставление — есть краеугольный камень линковки. ИМХО, "не понятной" она может быть, только если не понимать вышеуказанного. Где там ещё китайская грамота? В декорировании имён?

    I>Например в структуре проектов, в настройках оных проектов и тд. В итоге задача подключить либу чатенько растягивается на неделю.

    А ты уверен, что причина именно в сложности понимания работы линкера? Может, дело в чём-то сильно-сильно другом?

    ГВ>>Хм. Ты навёл меня на клёвую мысль, надо написать в резюме: "практические навыки работы с редактором связей — 17 лет". А потом отлавливать особо грамотных по вопросам, что это за связи такие.

    I>Это не смешно, особенно когда приходтся исправлять какую нибудь lnk2005. Причин — вагоны.

    Знамо дело, не смешно. Не знать, что такое редактирование связей, да ещё нарваться на lnk2005 — можно только посочувствовать.

    ГВ>>>>Чего? Ну ладно, рефлектор — он, по крайней мере, может дать доступ к образцам кода. Но средства рефакторинга...

    I>>>Средства рефакторинга помогают преобразовать код к понятному виду. Не долбить целый день одно и то же, а за полчаса привести к нужному виду и двигаться дальше.
    ГВ>>Есть мнение, что количество нужных видов растёт прямо пропорционально лёгкости их получения. Есть также ещё одно мнение: что время получения финального вида слабо зависит от количества промежуточных прикидок. Почему-то я согласен с ними обоими.

    I>А какое

    Похоже, фраза оборвана на полуслове.

    ГВ>>Хм. Либо ученик юзает шаблоны, тогда будет большое время компиляции, но квалификация уже очевидна; либо ученик шарахается шаблонов, но тогда откуда взяться большому времени компиляции? Неужели он, пугающийся шаблонов, собирает настолько большой проект?

    I>Это зависит от проекта, а не от ученика.

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

    I>>>Кроме того, в С++ затруднено юниттестирование, написание моков.

    ГВ>>При чём тут обучение языку? Чтобы вписывать нужные буквы в мок, необходимо уже понимать — что, куда, почему. А проще всего проверять себя маленькими программками, где нет ничего лишнего. Зачем тут какие-то специальные средства мокогенерирования?
    I>Это ж каменный век.
    ГВ>>Мы всё ещё про обучение?
    I>Да, это все оно же. Моки, тесты снижают порог вхождения в проект/фреймворк.

    Хорошо, я согласен, что сейчас пытаюсь опровергнуть формально корректные высказывания. Меня смущает другое. Давай, разобьём задачи, с которыми сталкивается ученик, когда он пишет исследовательскую программу, на две составляющие: 1) написать саму такую программу, 2) понять, что происходит, "поиграться" с кодом, объяснить результаты. Написание программы снова разобьём на: 1.1) написать формальный код вызовов, 1.2) наполнить формальный код функциональностью. Мокогенератор может помочь на стадии 1.1, плюс, (возможно), на 1.2. Вопрос: как относятся (1.1 + часть 1.2) к (1+2)? AFAIK, это примерно 0.15-0.30, остальное уходит на то, чтобы понять, какой функциональностью нужно наполнить формальный код, а после — что же там на самом деле происходит. У меня бывали случаи, когда эта величина колебалась в районе 0.05 — но это уже касается сложных ситуаций, например, выяснения тонкостей работы какого-нибудь API. В пределе этот показатель стремится к нулю (написал один раз тестовую программу, потом месяц с ней периодически играешься).

    Резюмирую: я не против мокогенерации самой по себе, как части обучения, но я не согласен с тем, что она значительно влияет на скорость обучения. По крайней мере, если у нас малоопытный ученик. Плюс к тому, например, для той же стандартной библиотеки в сети полно разнообразного boilerplate кода, который вполне можно использовать для исследований. А в составе буста вообще имеются уже готовые тестовые программы.

    ГВ>>[...] А буст вообще частью уже перекочевал в стандарт.

    I>Что с того что он в стандарте ? Его изучать чтоли не нужно ?

    Глупо от него отказываться, тем более, объясняя это трудностями поиска программистов.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[7]: С vs C++
    От: max-maxtor Россия www.rsdn.ru
    Дата: 26.05.10 11:01
    Оценка:
    Здравствуйте, bazis1, Вы писали:

    >>Или надо шашечки, а не ехать?


    зря вы так я вам не рекомендую так думать, можно больше заплатить можно не туда заехать и остаться без всех денег и ещё без здоровья или даже жизни. Это так уточнение, может вам пригодится. Я по телефону вызываю такси.
    Re[22]: дополню
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 26.05.10 15:59
    Оценка:
    ГВ>1. Yahoo покупает Viaweb как дойную корову, заранее предполагая его переписывание на C++, поскольку на самом деле покупается не столько техническая компонета, сколько клиентская база, модель сервиса, рыночный сектор... Да много чего ещё.

    1.1. Yahoo переписывает Viaweb, интегрируя его в свои инфраструктуры, не заморачиваясь каким-то поиском дополнительных специалистов вообще (кроме обыкновенной текучки). Тарахтеть в сети при этом она может о чём угодно — о том, что второго Грэма найти не удалось, о погоде на Марсе, о котировках акций Sun, о великом будущем интернета — это всё не имеет никакого значения.

    1.2. Грэму это вообще всё до лампочки — он продукт продал, а дальше не его дело. Больше того, такая трескотня ему даже на руку — "короля играет свита". Его персональных достоинств это никак не умаляет, а "корпорации" не ругает только ленивый — Yahoo от этого ни холодно, ни жарко.

    ГВ>2. Миллионы унылых менеджеров начинают засирать мозги молодняку: "они не нашли лисперов, лисп не нужен, нужны тупые обезьянки".


    ...правда, почему-то, эти "миллионы" даже в Yahoo не работают. Но точно знают, что лисп мешает бизнесу, иллюстрируя примером Yahoo.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[24]: К началу с начала
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 27.05.10 15:59
    Оценка:
    ГВ>Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир. У Yahoo — тоже никаких особых рисков, переписала и не развалилась. А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.

    Вот какая закавыка. Допустим, что у Yahoo нет денег на замену Грэма. Я не думаю, что в менеджменте Yahoo сидят кретины, не способные просчитать эту маленькую деталь: Грэму всё надоело — он свалил. Значит, Yahoo заранее предполагает вероятность сбегания команды. Следовательно — заранее резервирует бюджет на возможное переписывание. Во всяком случае — предполагает такую возможность, притом, что не удивительно — ничуть её не боится (за исключением менеджеров среднего звена, которым положено бояться всего). Иными словами, цена покупки Viaweb для Yahoo состоит из X+Y, где X — собственно цена продукта, а Y — цена возможного его переписывания. X определяется из переговоров с Грэмом (с определённой степенью условновсти можно сказать, что именно с Грэмом). Y — оценочно прикидывается специалистами Yahoo. Если Грэм не свалит — всем будет только лучше, но никто его не обязывает к альтруизму.

    Можно ещё немного пофантазировать. Конечно, Yahoo могла написать прямую альтернативу Viaweb своими средствами. Но здесь затыка: Грэм уже всем рассвистел, какой он поворотливый, плюс к тому — он и есть вполне поворотливый. Следовательно, обыгрывать его в прямой конкурентной свалке — это нудная, сложная задача. Зачем? Проще приобрести продукт вместе с сегментом рынка. Если Грэм сотоварищи останется в Yahoo — отлично, глядишь, он ещё чего прикольного начудит, а не останется — см. выше.

    Следовательно, напрашивается вот какой вывод (если принимать на веру грэмовское воспевание лиспа). Лисп — невероятно выгоден, как минимум, для стартапа (при условии, что стартап правильно вычислил рыночный сегмент). Если у покупателя нет денег на переписывание — поищем другого, более богатого, не больно-то и хотелось. Если у покупателя есть деньги на переписывание — заломим ту цену, которую удастся заломить. Просто, как не ходить в школу. Ну а если покупателя не нашлось — продолжаем сами развивать свой продукт, опираясь на своих специалистов (по совместительству — совладельцев). То есть продолжаем начатое — возможно, нанимаем зелёных школьников, которых обучаем премудростям лиспа (не такая уж сложная наука, на самом деле). Пущай богатые Буратино чешутся дальше, но "завтра будет дороже" (c).
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[24]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 28.05.10 09:32
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    I>>>>Ну так обучение, изучение оно не только в университете.

    I>>...
    I>>я тут скипнул, ни вижу смысла объяснять

    ГВ>Хорошо, слив засчитан.


    Ай, умно выпендрился, и, главное, оригинально

    ГВ>Молодняк мне твой жалко, конечно, но что поделаешь...


    У меня нету молодняка. Я девелопер вообще говоря. Смотрю бывает, на код молодняка, собеседования провожу и тд.

    ГВ>Ну, я уже понял, что согласованость посылок — ничто. Главное — что C++-отстой, лисп — опасность.


    Moq это пример того, как тесты помогают вникнуть в код. Никакие тестовые прожки этого не заменят.

    ГВ>Я одного не понимаю, как можно называть "непригодным для использования в бизнесе" инструмент, благодаря которому появился столь успешный продукт? 1 == 0? Эти люди допущены к обучению молодых, с такой-то кашей в голове. O tempora, o mores!


    Предствь себе, это решаю люди которые изучали лисп в университете. Именно они отказываются от лиспа в пользу с++.

    I>>Ушли вместе с Грехемом.


    ГВ>Угу, ну ладно. Испарились. Ну, бывает.


    Грехем продал проект, а не программистов. Вроде все ясно

    >>>Руководство — идиоты?

    I>>А как ты хотел, сначала бюджет, а потом разработчики ? Потребность вполне ясна, цели проекта — все предельно ясно.

    ГВ>Э... Я как раз хотел бы обратного — сначала разработчики, которые определяют потребность в бюджете, потом уже — сам бюджет.


    I>>А это неважно абсолютно. В данном случае Грехем сам продал свой бизнес.


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


    Примерно столько.

    ГВ>Если это топ-менеджмент Yahoo, принявший решение о покупке сервиса — тогда логика вполне ясна. Компания купила проект, ключевые специалисты свалили. Что делать? Отдали проект своим специалистам, а кому ещё? Те оказались перед дилеммой: изучать лисп, либо переписать всё на привычном языке.


    Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.

    >Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.


    Именно это и вносит огромные риски.

    >А тут можно начинать действовать прямо сейчас.


    О чем я тебе и говорю.

    ГВ>То есть вся эта ситуация никоим образом не бросает тень на сам лисп. Напротив: не будь лиспа, Грэм не заработал бы свои сколько-то там в шестой степени. У Грэма получился очень успешный бизнес. Yahoo тоже от этого не проиграла.


    На лисп как абстракцию, конечно тень не бросает.

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

    ГВ>Ну а ситуация, к которой ты клонишь: "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов" — это полный абсурд.


    Господи, сравни "компания купила продукт на LANG, и отказалась от LANG". Не нучно вычитывать то, чего нет.

    I>>Разумется они предполагали это. Только С++ не от балды взяли, а посчитали риски, затраты и тд.


    ГВ>Ты вторую часть моего предложения прочёл?


    Конечно. Там буквально написано, что ЗП можно выделить чуть не любые и привлечь нужных спецов.
    И несмотря на это люди, как ты сказал, изучавшие Лисп в университете, отказываются от него в пользу С++ и Перл.

    ГВ>Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир.


    Да, у Грема не было. Это мега показатель А у меня, представь, зависимости от меня самого тоже нет

    >У Yahoo — тоже никаких особых рисков, переписала и не развалилась.


    а чуть выше ты выдал бред "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов"

    Определись что ли ?

    > А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.


    ГВ>Потом знаешь, был бы топовый специалист — а зависимость от него всегда сложится, не зависимо от языка программирования. Почитай недавние истории от того же мыщъха — он тоже один из топовых специалистов в своей области. Что теперь? C — тоже плохой?


    Сишников в самом худшем случае где то на порядок больше чем лисперов .

    Это значит, что риски из за кадров несравнимы.

    I>>Даже в этой стране лисперов около нуля.

    I>>Вот, смотри, что сказал Грехем:

    I>>

    I>>Why? Because they didn't think they'd be able to find Lisp hackers.


    ГВ>Внимательно всматриваемся в выделенное.


    Т.е. просто специалистов для Лиспа было недостаточно ? Нахрена тогда этот Лисп нужен вообще ?
    Re[25]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 28.05.10 12:00
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>>>Ну так обучение, изучение оно не только в университете.

    I>>>...
    I>>>я тут скипнул, ни вижу смысла объяснять
    ГВ>>Хорошо, слив засчитан.
    I>Ай, умно выпендрился, и, главное, оригинально

    Заметь, я был вторым.

    ГВ>>Молодняк мне твой жалко, конечно, но что поделаешь...

    I>У меня нету молодняка. Я девелопер вообще говоря. Смотрю бывает, на код молодняка, собеседования провожу и тд.

    Уже легче.

    ГВ>>Ну, я уже понял, что согласованость посылок — ничто. Главное — что C++-отстой, лисп — опасность.

    I>Moq это пример того, как тесты помогают вникнуть в код. Никакие тестовые прожки этого не заменят.

    Ясно.

    ГВ>>Я одного не понимаю, как можно называть "непригодным для использования в бизнесе" инструмент, благодаря которому появился столь успешный продукт? 1 == 0? Эти люди допущены к обучению молодых, с такой-то кашей в голове. O tempora, o mores!

    I>Предствь себе, это решаю люди которые изучали лисп в университете. Именно они отказываются от лиспа в пользу с++.

    Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?

    I>>>Ушли вместе с Грехемом.

    ГВ>>Угу, ну ладно. Испарились. Ну, бывает.
    I>Грехем продал проект, а не программистов. Вроде все ясно

    Допустим. Что это меняет? Из моих рассуждений выпадает ровно одно звено — про пребывание Грэма в Yahoo.

    ГВ>>Если это топ-менеджмент Yahoo, принявший решение о покупке сервиса — тогда логика вполне ясна. Компания купила проект, ключевые специалисты свалили. Что делать? Отдали проект своим специалистам, а кому ещё? Те оказались перед дилеммой: изучать лисп, либо переписать всё на привычном языке.

    I>Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.

    Почему странная? Привычный язык на то и привычный. Потом, ты же знаешь корпоративную этику: а себя работой обеспечить? Так что, дилемма, подозреваю, не настолько сильная.

    >>Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.

    I>Именно это и вносит огромные риски.

    Обрати внимание — речь идёт о талантах, а не о "рядовых лисповиках". Пнимаешь, проблема в том, что рядовые — они везде рядовые, что на лиспе, что на бейсике. Это, если грубо, способ мышления.

    >>А тут можно начинать действовать прямо сейчас.

    I>О чем я тебе и говорю.

    Правильно! Только ты упускаешь главное: "действовать" — означает именно, что "двигаться с места на место". Прыгать, короче говоря. Шевелиться. Пыль поднимать.

    ГВ>>То есть вся эта ситуация никоим образом не бросает тень на сам лисп. Напротив: не будь лиспа, Грэм не заработал бы свои сколько-то там в шестой степени. У Грэма получился очень успешный бизнес. Yahoo тоже от этого не проиграла.


    I>На лисп как абстракцию, конечно тень не бросает.

    I>А на лисп как язык, сообщество и тд этот пример полностью дискредитирует.

    В чьих глазах? В моих, точно, не дискредитирует.

    ГВ>>Ну а ситуация, к которой ты клонишь: "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов" — это полный абсурд.

    I>Господи, сравни "компания купила продукт на LANG, и отказалась от LANG". Не нучно вычитывать то, чего нет.

    Дык. А отказалась-то она почему? Не из-за того ли, что иначе вставала перед угрозой разорения? Пойми, проблема твоих рассуждений в том, что они апеллируют к фантастической ситуации: здесь никто на самом деле не мог встать перед такой угрозой из-за лиспа. Ни Грэм, ни Yahoo. Соображения я изложил в соседнем постинге. Если вкратце, то Грэму по поределению не испытывает проблем "из-за лиспа", а Yahoo по-любому готова переписать продукт, а иначе она его попросту не купила бы.

    I>>>Разумется они предполагали это. Только С++ не от балды взяли, а посчитали риски, затраты и тд.

    ГВ>>Ты вторую часть моего предложения прочёл?
    I>Конечно. Там буквально написано, что ЗП можно выделить чуть не любые и привлечь нужных спецов.
    I>И несмотря на это люди, как ты сказал, изучавшие Лисп в университете, отказываются от него в пользу С++ и Перл.

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

    ГВ>>Какие ещё, к чёртовой бабушке, риски? У тебя всё с ног на голову поставлено. У Грэма таких рисков не было, он сам себе командир.

    I>Да, у Грема не было. Это мега показатель А у меня, представь, зависимости от меня самого тоже нет

    Это единственный показатель, на самом деле. При условии, что "майнстрим" не промыл дыру в башке своим мутным потоком.

    >>У Yahoo — тоже никаких особых рисков, переписала и не развалилась.

    I>а чуть выше ты выдал бред "компания купила продукт на LANG, а потом разорилась из-за отсутствия специалистов"

    Прости, к этому бреду всё время клонишь ты, постоянно апеллируя к какой-то "опасности лиспа". У компании есть ровно одна критичная опасность — разориться. Остальное — преодолимо, если оно не ведёт к гарантированному разорению. Я подозреваю, что Yahoo, покупая Viaweb, вообще могла не брать исходники. Кому они нужны при наличии своего штата специалистов?! Нужен рыночный сегмент, плюс — спецификация продукта, а сам Viaweb мог быть написан хоть на Brainfuck.

    I>Определись что ли ?


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

    >> А если бы риск ухода Грэма был на самом деле значимым, то Yahoo, подозреваю, просто не стала бы покупать Viaweb, следовательно — он остался бы у Грэма, начинай с начала.

    ГВ>>Потом знаешь, был бы топовый специалист — а зависимость от него всегда сложится, не зависимо от языка программирования. Почитай недавние истории от того же мыщъха — он тоже один из топовых специалистов в своей области. Что теперь? C — тоже плохой?
    I>Сишников в самом худшем случае где то на порядок больше чем лисперов .

    Зато сишников, с таким складом мышления, как у мыщъха — днём с огнём.

    I>Это значит, что риски из за кадров несравнимы.


    Ничего это не значит, пока сюда не доставлены количественные интерпретации рисков в виде затрат.

    I>>>Даже в этой стране лисперов около нуля.

    I>>>Вот, смотри, что сказал Грехем:

    I>>>

    I>>>Why? Because they didn't think they'd be able to find Lisp hackers.


    ГВ>>Внимательно всматриваемся в выделенное.

    I>Т.е. просто специалистов для Лиспа было недостаточно ? Нахрена тогда этот Лисп нужен вообще ?

    Это означает, что "просто специалисты" не смогли бы поддерживать продукт, написанный лучшими специалистами. Ситуация классическая. Но намного вероятнее, что это означает только лишь то, что Yahoo на самом деле не слишком мучилась "выбором технологии". Повторюсь: оказалось бы под рукой много джавистов — переписали бы на Java.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[27]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 28.05.10 22:09
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>>>я тут скипнул, ни вижу смысла объяснять

    ГВ>>>>Хорошо, слив засчитан.
    I>>>Ай, умно выпендрился, и, главное, оригинально
    ГВ>>Заметь, я был вторым.
    I>Ну да, это ведь я про слив написал твоей рукой, ага

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

    I>>>Предствь себе, это решаю люди которые изучали лисп в университете. Именно они отказываются от лиспа в пользу с++.

    ГВ>>Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?
    I>Да вобщем то Лисп изучают не только в Мит, а в подавляющем большинстве серьезных технических вузов.

    Так всё же — кто имеется в виду?

    I>>>Грехем продал проект, а не программистов. Вроде все ясно

    ГВ>>Допустим. Что это меняет? Из моих рассуждений выпадает ровно одно звено — про пребывание Грэма в Yahoo.
    I>Да ладн

    Угу.

    I>>>Очень странная дилема, если учесть что ИТ-специалисты в той стране чуть не поголовно учили лисп в университете.

    ГВ>>Почему странная? Привычный язык на то и привычный. Потом, ты же знаешь корпоративную этику: а себя работой обеспечить? Так что, дилемма, подозреваю, не настолько сильная.
    >>>>Действительно, тут есть ещё одна альтернатива — искать "lisp hackers", которые заменят Грэма, а не просто знают лисп, но это игра без определённого итога — то ли найдём, то ли нет.
    I>>>Именно это и вносит огромные риски.
    ГВ>>Обрати внимание — речь идёт о талантах, а не о "рядовых лисповиках". Пнимаешь, проблема в том, что рядовые — они везде рядовые, что на лиспе, что на бейсике. Это, если грубо, способ мышления.
    I>Рядовых лисперов тоже мало. Потому в любом случае,уже просто потому, что Лисп это будет " игра без определённого итога — то ли найдём, то ли нет."

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

    I>Т.е. по твоим же словам риск, неопределенность.

    I>По этой причине лисп все свои 50 лет все время был Неуловимым Джо.

    Ерунда. Если бы это было на самом деле так, откуда бы взялись стандарты? Он же никому не нужен? Ты покури историю лиспа — он очень даже нужен. Даже лисп-процессоры с аппаратно реализованным лиспом выпускали.

    У меня есть другая гипотеза, как мне кажется, более правдоподобная. Единственная проблема лиспа, действительно значимая для покупателей — существенно меньшее быстродействие, чем у того же C (по крайней мере, так было в старые добрые времена). Этот вот аргумент весит намного больше, чем все разговоры относительно недоступности специалистов. Почему? Потому что быстродействие — это критерий, по которому продукт оценивают покупатели, без которых никакого бизнеса, как ты понимаешь, не бывает. Особенно яростно эту оценку использовали в пору больших машин и маленьких (по нашим меркам) программ. Соответственно, продать медленную программу, да ещё и на интерпретируемом языке было гораздо сложнее, чем быструю, где, к тому же, алгоритмы превращены в бинарный код. ИМХО, именно это и послужило толчком к тому, что очень много места заняли алголоподобные языки. А сейчас — да, зачастую действуют "по традиции".

    >>>>А тут можно начинать действовать прямо сейчас.

    I>>>О чем я тебе и говорю.

    ГВ>>Правильно! Только ты упускаешь главное: "действовать" — означает именно, что "двигаться с места на место". Прыгать, короче говоря. Шевелиться. Пыль поднимать.


    I>Ну да, раз сиплюсники стало быть дураки ибо только пылить умеют Вообще говоря, чем больше выборка, тем больше шансов найти замену Грехему.


    Не надо передёргивать. Я имел в виду, что в первом случае (поиски Грэма-2) пришлось бы долго сидеть без дела, а в случае переписывания муравейник зашевелился немедленно. Сиплюсплюсники там, перлисты — никакой разницы. Важен сам процесс шевеления, он вообще может по кругу ходить.

    I>>>На лисп как абстракцию, конечно тень не бросает.

    I>>>А на лисп как язык, сообщество и тд этот пример полностью дискредитирует.
    ГВ>>В чьих глазах? В моих, точно, не дискредитирует.
    I>В твоих возможно и нет. А чем объяснить его распространенность ?

    Мы ещё не выяснили, в чьих глазах дискредитирован лисп.

    ГВ>>Дык. А отказалась-то она почему? Не из-за того ли, что иначе вставала перед угрозой разорения?

    I>Не было угрозы разорения. Был шанс упустить рынок и доход с этого рынка.

    Хорошо, пусть так. Да, была угроза упустить рынок из-за остановки развития Viaweb. Однако, не смотря на такую угрозу, Yahoo всё же приобрела Viaweb, считай, заплатив за него цену покупки + цену переписывания. Следовательно, лисп отлично показал себя, принеся прибыль:

    — Грэму (здесь всё очевидно);
    — Потребителям Viaweb (иначе бы их не было);
    — Yahoo (прототип экономит уйму времени и сил).

    Так какие угрозы создаёт лисп, не подскажешь?

    >>Пойми, проблема твоих рассуждений в том, что они апеллируют к фантастической ситуации: здесь никто на самом деле не мог встать перед такой угрозой из-за лиспа. Ни Грэм, ни Yahoo. Соображения я изложил в соседнем постинге. Если вкратце, то Грэму по поределению не испытывает проблем "из-за лиспа", а Yahoo по-любому готова переписать продукт, а иначе она его попросту не купила бы.


    I>Если в кратце, то про грема в твоей цепочке чисто тавтология, что я тебе показал в предыдущем сообщении. Остается только Яху с ей готовностью переписать продукт.


    Правильно. Цепочку с Грэмом я сюда добавил, чтобы отсечь возможный перенос "опасности" на его компанию. Здесь я напомню тебе, что компания Грэма — самый, что ни на есть бизнес.

    I>Их понять можно — никто не хочет играть в игру "найдем/ненайдем", потому как можно использовать готовых сиплюсников.

    I>В бизнесе принято работать с тем, что есть, а не с тем, чем удобно.

    Ну, если абстрагироваться от скулосводящей формулировки — то да, так и есть. Не хрен стоять на месте — нужно бежать.

    I>Лисп из этой формулы выпадает.


    Я тут формулы не увидел. Заклинание — да, а формулу — нет.

    ГВ>>А я это запросто списываю на: а) феномен привычного языка; б) спокойствие, присущее работе в "большой компании"; в) желание поднять собственную значимость; г) сложившуюся культуру производства ПО (схоже с пунктом "а)" ).


    I>Ага, и 50 лет Лиспу мешала эта формула.

    I>Почему же эта формула не мешала другим языкам ?

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

    I>>>Да, у Грема не было. Это мега показатель А у меня, представь, зависимости от меня самого тоже нет

    ГВ>>Это единственный показатель, на самом деле.
    I>Это тавтология а не показатель.

    Ну, если ты считаешь, что Грэм не занимался бизнесом, то продолжать дискуссию бессмысленно. А если считаешь, то перечитай поскипанное.

    >>При условии, что "майнстрим" не промыл дыру в башке своим мутным потоком.

    I>Майнстрим подчиняется бизнесу,а бизнес требует определенность.

    Бизнес бывает разный (говоря по-русски: дела бывают разными, или же — люди делают разное). Я никак не воткнусь: почему ты не считаешь бизнес Грэма достойным упоминания? Это же пример мегауспешного бизнеса, если разобраться.

    I>Люди готовы заплатить деньги, но хотят иметь определенность.

    I>Только зависимостью от топ-специалистов Лисп устраняет начисто эту определенность.

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

    >>У компании есть ровно одна критичная опасность — разориться. Остальное — преодолимо, если оно не ведёт к гарантированному разорению.

    I>Нужна определенность, которой нет у Лиспа.

    Почему-то Грэм обошёлся без этой самой определённости.

    >>Я подозреваю, что Yahoo, покупая Viaweb, вообще могла не брать исходники. Кому они нужны при наличии своего штата специалистов?! Нужен рыночный сегмент, плюс — спецификация продукта, а сам Viaweb мог быть написан хоть на Brainfuck.


    I>Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.


    Ну я уже понял, что то, чем занимался Грэм — это не бизнес, а вообще не пойми, что.

    I>>>Определись что ли ?


    ГВ>>Встречная просьба того же свойства: доведи свои посылки до конца, реши силлогизм(ы), наконец, которых ты сам понасоздавал.

    I>Посылки вполне простые.

    Реши, реши. Только прими во внимание, что Viaweb — это продукт, а Грэм тоже занимался бизнесом, при этом посмеиваясь над майнстримом. Вот прими во внимание эти условия, а потом докажи, что бизнес нуждается в майнстриме, ему не нужен лисп и т.п.

    ГВ>>Зато сишников, с таким складом мышления, как у мыщъха — днём с огнём.

    I>Много больше, чем лисперов.

    Считал?

    ГВ>>Ничего это не значит, пока сюда не доставлены количественные интерпретации рисков в виде затрат.

    I>Ну ты и дал. Кто ж тебе неопределенность числом определит ? Это ж секрет философского камня

    Как тогда рисками управлять? "Здесь страшно, сюда не ходи!", так, что ли?

    ГВ>>Это означает, что "просто специалисты" не смогли бы поддерживать продукт, написанный лучшими специалистами. Ситуация классическая. Но намного вероятнее, что это означает только лишь то, что Yahoo на самом деле не слишком мучилась "выбором технологии". Повторюсь: оказалось бы под рукой много джавистов — переписали бы на Java.


    I>Естественно. Бизнес работает с тем что есть, а не с тем, что удобно.


    Бизнес бывает разный.

    I>Лисп в бизнес за 50 лет и не попал.


    Это уже апофеоз. Грэм, надо думать, не бизнесмен.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[27]: С vs C++
    От: FR  
    Дата: 29.05.10 02:52
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:


    I>Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.


    Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.
    Re[28]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 10:50
    Оценка:
    Здравствуйте, FR, Вы писали:

    I>>Это значит, что ценность Лиспа в бизнесе равняется ценности Брейнфака этого.


    FR>Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.


    Ну то есть нулю
    Re[29]: С vs C++
    От: FR  
    Дата: 29.05.10 11:42
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    FR>>Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.


    I>Ну то есть нулю


    Если такие специалисты не нужны то да
    Re[28]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 12:13
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Не, сначала ты сказал, что не видишь смысла объяснять (я, правда, подозреваю, что дело в том, что ты где-то наскочил на неразрешимое противоречие в своих доводах, но это ведь пустые домыслы, правда?),


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

    ГВ>>>Каких людей ты имеешь в виду? Себя? Руководство Yahoo? Специалистов Yahoo?

    I>>Да вобщем то Лисп изучают не только в Мит, а в подавляющем большинстве серьезных технических вузов.

    ГВ>Так всё же — кто имеется в виду?


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

    Я более чем уверен, Яху прорабатывала этот вопрос очень тщательно.

    I>>Рядовых лисперов тоже мало. Потому в любом случае,уже просто потому, что Лисп это будет " игра без определённого итога — то ли найдём, то ли нет."


    ГВ>Тебе не кажется, что ты сам себе противоречишь? С одной стороны, ты соглашаешься со мной, что лисп изучал почти каждый IT-шник, а с другой — что рядовых лисперов мало. Ты уж определись, ладно?


    Лиспер, дотнетчих, сиплюсник, джавист — всегда и везде название дается по основному направлению.

    Потому если ты чего то изучал, а пишешь на С++ — значит ты сиплюсник.

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

    I>>По этой причине лисп все свои 50 лет все время был Неуловимым Джо.


    ГВ>Ерунда. Если бы это было на самом деле так, откуда бы взялись стандарты? Он же никому не нужен? Ты покури историю лиспа — он очень даже нужен. Даже лисп-процессоры с аппаратно реализованным лиспом выпускали.


    Болтается на грани статпогрешности. Его всегда обходили слабенькие, уродливые языки

    Лисп-процессоры никому не нужны. Потому и не прижилось это дело.

    ГВ>У меня есть другая гипотеза, как мне кажется, более правдоподобная. Единственная проблема лиспа, действительно значимая для покупателей — существенно меньшее быстродействие,


    Перформанс никогда не был определяющим фактором. Комфорт программиста, инструментарий — это много важнее.

    >Этот вот аргумент весит намного больше, чем все разговоры относительно недоступности специалистов.


    Этот аргумент ровно ничего не весит.

    >Особенно яростно эту оценку использовали в пору больших машин и маленьких (по нашим меркам) программ.


    В ту пору рулили такие же тормозные языки только убогие по своей природе.

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


    И поэтому люди писали на тормозных и убогих, а не на тормозных и мощных ?

    ГВ>Не надо передёргивать. Я имел в виду, что в первом случае (поиски Грэма-2) пришлось бы долго сидеть без дела, а в случае переписывания муравейник зашевелился немедленно. Сиплюсплюсники там, перлисты — никакой разницы. Важен сам процесс шевеления, он вообще может по кругу ходить.


    Ну то есть все равно дураки, пылить только могут и ходить кругами ? К этой формуле прилепить бы дороги — получится классическая дилема

    I>>В твоих возможно и нет. А чем объяснить его распространенность ?


    ГВ>Мы ещё не выяснили, в чьих глазах дискредитирован лисп.


    В глазах тех, кто изучал его и кто после этого не используеи этот язык.

    ГВ>Хорошо, пусть так. Да, была угроза упустить рынок из-за остановки развития Viaweb. Однако, не смотря на такую угрозу, Yahoo всё же приобрела Viaweb, считай, заплатив за него цену покупки + цену переписывания. Следовательно, лисп отлично показал себя, принеся прибыль:


    ГВ>- Грэму (здесь всё очевидно);

    ГВ>- Потребителям Viaweb (иначе бы их не было);
    ГВ>- Yahoo (прототип экономит уйму времени и сил).

    ГВ>Так какие угрозы создаёт лисп, не подскажешь?


    Дважды два это три или пять, не подскажешь ?

    " игра без определённого итога — то ли найдём, то ли нет."

    ГВ>Правильно. Цепочку с Грэмом я сюда добавил, чтобы отсечь возможный перенос "опасности" на его компанию. Здесь я напомню тебе, что компания Грэма — самый, что ни на есть бизнес.


    В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

    А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.


    I>>Лисп из этой формулы выпадает.


    ГВ>Я тут формулы не увидел. Заклинание — да, а формулу — нет.


    Ну попридирайся к словам

    I>>Ага, и 50 лет Лиспу мешала эта формула.

    I>>Почему же эта формула не мешала другим языкам ?

    ГВ>Как видишь, в случае Грэма эта формула лиспу не помешала.


    Это и ежу понятно. Лисп как был за пределами статпогрешности, так и остался


    ГВ>>>Это единственный показатель, на самом деле.

    I>>Это тавтология а не показатель.

    ГВ>Ну, если ты считаешь, что Грэм не занимался бизнесом, то продолжать дискуссию бессмысленно. А если считаешь, то перечитай поскипанное.


    Ну занимался он, что с того ? Зависимость его самого от него самого рассматривать будем ? Можешь развить эту идею, мне все равно

    ГВ>Бизнес бывает разный (говоря по-русски: дела бывают разными, или же — люди делают разное). Я никак не воткнусь: почему ты не считаешь бизнес Грэма достойным упоминания? Это же пример мегауспешного бизнеса, если разобраться.


    Согласно определению, это бизнес, но что толку ?

    Где гарантия что этот опыт можно хоть как то распространить ?

    Нет гарантии, на что указывает уже сам отказ Яхи от лиспа.

    ГВ>Почему-то Грэм обошёлся без этой самой определённости.


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

    ГВ>Реши, реши. Только прими во внимание, что Viaweb — это продукт, а Грэм тоже занимался бизнесом, при этом посмеиваясь над майнстримом. Вот прими во внимание эти условия, а потом докажи, что бизнес нуждается в майнстриме, ему не нужен лисп и т.п.


    I>>Много больше, чем лисперов.


    ГВ>Считал?


    А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.

    I>>Ну ты и дал. Кто ж тебе неопределенность числом определит ? Это ж секрет философского камня


    ГВ>Как тогда рисками управлять? "Здесь страшно, сюда не ходи!", так, что ли?


    Вобщем то да. Величина риска это некое среднепотолочное значение.

    I>>Естественно. Бизнес работает с тем что есть, а не с тем, что удобно.


    ГВ>Бизнес бывает разный.


    Бывает. Ограбить в подъезде — тож бизнес. Здесь работают с тем, что удобно.

    I>>Лисп в бизнес за 50 лет и не попал.


    ГВ>Это уже апофеоз. Грэм, надо думать, не бизнесмен.


    Грехем это исключение из правила, не более того.
    Re[30]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 12:16
    Оценка:
    Здравствуйте, FR, Вы писали:

    FR>>>Ценность лиспа равна возможности привлекать высококвалифицированных хорошо мотивированных специалистов.


    I>>Ну то есть нулю


    FR>Если такие специалисты не нужны то да


    "возможности привлекать высококвалифицированных хорошо мотивированных специалистов"

    1 нет надобности, нет возможности = 0
    2 нет надобности, есть возможность = 0
    3 есть надобность, нет возможности = 0
    4 есть надобность, есть возможность >0

    В случае с яхой был случай 3, о чм Грехем и поведал.
    Re[29]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 14:56
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    Я выделил главное.

    >>Этот вот аргумент весит намного больше, чем все разговоры относительно недоступности специалистов.

    I>Этот аргумент ровно ничего не весит.

    Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.

    I>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

    I>А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.

    О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

    ГВ>>Как видишь, в случае Грэма эта формула лиспу не помешала.

    I>Это и ежу понятно. Лисп как был за пределами статпогрешности, так и остался

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

    ГВ>>Ну, если ты считаешь, что Грэм не занимался бизнесом, то продолжать дискуссию бессмысленно. А если считаешь, то перечитай поскипанное.

    I>Ну занимался он, что с того ? Зависимость его самого от него самого рассматривать будем ? Можешь развить эту идею, мне все равно

    А больше ничего не требуется. Грэм занимался бизнесом, лиспу в бизнесе место есть, дискутировать больше не о чем.

    ГВ>>Бизнес бывает разный (говоря по-русски: дела бывают разными, или же — люди делают разное). Я никак не воткнусь: почему ты не считаешь бизнес Грэма достойным упоминания? Это же пример мегауспешного бизнеса, если разобраться.

    I>Согласно определению, это бизнес, но что толку ?

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

    I>Где гарантия что этот опыт можно хоть как то распространить ?


    Для этого нужно задаваться другими вопросами: выделять критерии подобия бизнесов, определять границы применимости и т.п. А я с тобой так, об общих определениях спорил.

    I>Нет гарантии, на что указывает уже сам отказ Яхи от лиспа.


    Априорных гарантий переносимости опыта одной компании на другую вообще никогда дать нельзя.

    ГВ>>Почему-то Грэм обошёлся без этой самой определённости.

    I>Потому что он зависел в основном сам от себя. Для него этой неопределенности не было, если говорить про разработку.

    Ну вот, видишь. Достаточно было признать, что то, чем занимался Грэм с Viaweb, называется "бизнес" — сразу всё становится на свои места. Вот тебе и один из критериев применимости опыта Грэма.

    ГВ>>Реши, реши. Только прими во внимание, что Viaweb — это продукт, а Грэм тоже занимался бизнесом, при этом посмеиваясь над майнстримом. Вот прими во внимание эти условия, а потом докажи, что бизнес нуждается в майнстриме, ему не нужен лисп и т.п.

    I>>>Много больше, чем лисперов.
    ГВ>>Считал?
    I>А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.

    У лиспа не такое уж и мелкое сообщество.

    I>>>Лисп в бизнес за 50 лет и не попал.

    ГВ>>Это уже апофеоз. Грэм, надо думать, не бизнесмен.
    I>Грехем это исключение из правила, не более того.

    О каких правилах речь? За 50 лет своего существования лисп прекрасно "обжился в бизнесе" (воспользуюсь оборотами жёлтых газет), пример Грэма это отлично доказывает.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[29]: Вот ещё...
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 15:03
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.


    Обрати внимание на эту реплику. Здесь ты вплотную подобрался к главному: к роли людей в бизнесе.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[29]: Ещё детали
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 15:10
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Т.е. в случае с лиспом — лисп изучали чуть не все поголовно, а лисперов, даже рядовых, днем с огнем не сыскать.


    Почему-то это не помешало AutoDesk-у встроить в свой AutoCAD диалект лиспа. Ещё можно назвать, пожалуй, Emacs. Так что, как видишь, лисп в современном мире — обыденное дело.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[30]: Ещё детали
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 15:29
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Почему-то это не помешало AutoDesk-у встроить в свой AutoCAD диалект лиспа. Ещё можно назвать, пожалуй, Emacs. Так что, как видишь, лисп в современном мире — обыденное дело.


    ...что, в общем, заставляет усомниться в том, что действительная распространённость лиспа близка к статпогрешности. Следовательно, я поторопился, говоря здесь
    Автор: Геннадий Васильев
    Дата: 29.05.10
    :

    А никто не пытался опровергать, что распространённость лиспа находится на уровне этой самой статпогрешности.

    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[30]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 15:50
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    >>>Этот вот аргумент весит намного больше, чем все разговоры относительно недоступности специалистов.

    I>>Этот аргумент ровно ничего не весит.

    ГВ>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.


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

    I>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

    I>>А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.

    ГВ>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".


    Да, а микроскопом можно гвоздь забить. Так и с Лиспом.

    ГВ>А никто не пытался опровергать, что распространённость лиспа находится на уровне этой самой статпогрешности. Hackers (в позитивном смысле) — это тоже статпогрешность, кстати. Иначе бы они не считались "хорошими", а были бы "обычными".


    А на лиспе других смысла не стоит нанимать.

    I>>Ну занимался он, что с того ? Зависимость его самого от него самого рассматривать будем ? Можешь развить эту идею, мне все равно

    ГВ>А больше ничего не требуется. Грэм занимался бизнесом, лиспу в бизнесе место есть, дискутировать больше не о чем.

    См выше про микроскоп.

    ГВ>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.


    Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.

    I>>А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.


    ГВ>У лиспа не такое уж и мелкое сообщество.


    Относительно языков вроде С++, джавы, С# он за гранью статпогрешности.

    Питон, перл, руби — каждый из них хотя и экзотика, тем не менее имеют сообщетво посильнее Лиспа.

    I>>Грехем это исключение из правила, не более того.


    ГВ>О каких правилах речь? За 50 лет своего существования лисп прекрасно "обжился в бизнесе" (воспользуюсь оборотами жёлтых газет), пример Грэма это отлично доказывает.


    Прекрасно обжился это когда хотя бы каждый десятый проект на нем создается. Это гарантирует что лет черз 10 будт спецы хотя бы для поддержки проектов.
    Re[30]: Вот ещё...
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 15:51
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    I>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.


    ГВ>Обрати внимание на эту реплику. Здесь ты вплотную подобрался к главному: к роли людей в бизнесе.


    У нас с тобой разные взгляды на это главное.
    Re[30]: Ещё детали
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 15:52
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Здравствуйте, Ikemefula, Вы писали:


    I>>Т.е. в случае с лиспом — лисп изучали чуть не все поголовно, а лисперов, даже рядовых, днем с огнем не сыскать.


    ГВ>Почему-то это не помешало AutoDesk-у встроить в свой AutoCAD диалект лиспа. Ещё можно назвать, пожалуй, Emacs. Так что, как видишь, лисп в современном мире — обыденное дело.


    Да, можно ажно десяток проектв крупных назвать, очень круто
    Re[32]: Ещё детали
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 16:07
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел


    Плохо искал: http://www.work.ua/jobs/548293/ Датирована 26/05/2010.

    I>Лисп уже давно сдох, и это подтвержается тем фактом, что о нем спорят только те, для кого это максимум основной язык.


    Скажем так, я ничего не имею против того, чтобы ты повторял это высказывание, как своеобразную мантру. На кучу неувязок в твоих рассуждениях я тебе уже показал, а дальше поступай, как знаешь.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[31]: Вот ещё...
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 16:09
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    I>>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

    ГВ>>Обрати внимание на эту реплику. Здесь ты вплотную подобрался к главному: к роли людей в бизнесе.
    I>У нас с тобой разные взгляды на это главное.

    Я уж догадался.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[33]: Это не последняя вакансия
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 16:11
    Оценка:
    Приватбанк, крупнейший розничный банк Украины ищет лисповиков: http://rabota.ua/company203681/vacancy4401282?utm_source=jooble&amp;utm_medium=cpc&amp;utm_campaign=specialists
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[31]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 16:21
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    ГВ>>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.

    I>Как бы да. Но почему то другим тормозам производительность не помешала.

    Какие именно языки ты имеешь в виду?

    I>>>В том клочке бизнеса, где люди вроде Грехема, зависящие от самих себя, на стартапе можно использовать даже Лисп.

    I>>>А как только проект перерастает во чтото более серьезное, то Лисп уже не представляет ценности.
    ГВ>>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".
    I>Да, а микроскопом можно гвоздь забить. Так и с Лиспом.

    Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.

    ГВ>>А никто не пытался опровергать, что распространённость лиспа находится на уровне этой самой статпогрешности. Hackers (в позитивном смысле) — это тоже статпогрешность, кстати. Иначе бы они не считались "хорошими", а были бы "обычными".

    I>А на лиспе других смысла не стоит нанимать.

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

    ГВ>>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.

    I>Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.

    Это справедливо по отношению к любому языку программирования, лисп — не исключение.

    I>>>А что тут считать ? Это число прямо пропорционально объему сообщества при условии что нет принудительного регулирования.

    ГВ>>У лиспа не такое уж и мелкое сообщество.
    I>Относительно языков вроде С++, джавы, С# он за гранью статпогрешности.

    Честно сказать, не знаю. Мне на это плевать, вообще-то.

    I>Питон, перл, руби — каждый из них хотя и экзотика, тем не менее имеют сообщетво посильнее Лиспа.


    См. выше.

    I>>>Грехем это исключение из правила, не более того.

    ГВ>>О каких правилах речь? За 50 лет своего существования лисп прекрасно "обжился в бизнесе" (воспользуюсь оборотами жёлтых газет), пример Грэма это отлично доказывает.
    I>Прекрасно обжился это когда хотя бы каждый десятый проект на нем создается. Это гарантирует что лет черз 10 будт спецы хотя бы для поддержки проектов.

    Ой, ну извините... Ладно, продолжай демонстрировать всяческое презрение к лиспу дальше, у тебя это хорошо получается.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[33]: Ещё детали
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 16:54
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Здравствуйте, Ikemefula, Вы писали:


    I>>Ага, сходи на сайты где вакансии разложены да посмотри. Я пока ни одной не нашел


    ГВ>Плохо искал: http://www.work.ua/jobs/548293/ Датирована 26/05/2010.


    Я пару сайтов проверил.

    Только что погуглил в рунете немного на тему работы, вакансий, проектов — Lisp начисто сливает даже экзотике вроде perl, python. Самый лучший результат, что удалось выбить — 9млн результатов, при этом джава, C# и C++ уходят за 60-70 млн.
    Re[32]: С vs C++
    От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
    Дата: 29.05.10 17:14
    Оценка:
    Здравствуйте, Геннадий Васильев, Вы писали:

    ГВ>Здравствуйте, Ikemefula, Вы писали:


    ГВ>>>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.

    I>>Как бы да. Но почему то другим тормозам производительность не помешала.

    ГВ>Какие именно языки ты имеешь в виду?


    Вот кобол тот же. А вообще лет 15-20 назад производительность уже точно не имела значения. Например первая джава была жутким тормозом и тем не менее основательно потеснила более шустрый С++. Перл, Питон первых версий так же были тормозами

    Вобщем лиспу все время что то мешало. Даже когда перформанс перстал определять что либо, у лиспа все равно какие то проблемы — слишком много диалектов, слабая читабельность, отсутствие инструментов

    ГВ>>>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

    I>>Да, а микроскопом можно гвоздь забить. Так и с Лиспом.

    ГВ>Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.


    Это не имеет значения, глядя на 40 лет кобола.

    I>>А на лиспе других смысла не стоит нанимать.


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


    ГВ>>>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.


    Я ж сказал — за гранью статпогрешности.

    I>>Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.


    ГВ>Это справедливо по отношению к любому языку программирования, лисп — не исключение.


    С++, Джава, С№ не надо никуда впихивать. Бизнес сам приходит и просит именно это.

    I>>Прекрасно обжился это когда хотя бы каждый десятый проект на нем создается. Это гарантирует что лет черз 10 будт спецы хотя бы для поддержки проектов.


    ГВ>Ой, ну извините... Ладно, продолжай демонстрировать всяческое презрение к лиспу дальше, у тебя это хорошо получается.


    Презрение это твоя проекция.
    Re[33]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 29.05.10 18:37
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    ГВ>>>>Здесь я говорил про "goog old-fashioned times". Если ты платишь за каждый час машинного времени, производительность — весьма даже аргумент.

    I>>>Как бы да. Но почему то другим тормозам производительность не помешала.
    ГВ>>Какие именно языки ты имеешь в виду?
    I>Вот кобол тот же. А вообще лет 15-20 назад производительность уже точно не имела значения. Например первая джава была жутким тормозом и тем не менее основательно потеснила более шустрый С++. Перл, Питон первых версий так же были тормозами
    I>Вобщем лиспу все время что то мешало. Даже когда перформанс перстал определять что либо, у лиспа все равно какие то проблемы — слишком много диалектов, слабая читабельность, отсутствие инструментов

    Если я правильно помню, то помимо всего прочего, во времена кобола лисп однозначно ассоциировался с задачами ИИ, но никак не с повседневными экономическими расчётами. Но, конечно, факторов тут много, спекулировать на каком-то одном — неблагодарное занятие даже для КСВ.

    ГВ>>>>О-о-о! Наконец-то мне удалось из тебя выдавить хоть какую-то связность тезисов. Долго, но для бешеной собаки... Итак, лисп всё же может иметь ценность, даже по словам Ikemefula, олицетворяющего в наших кругах "большой серьёзный бизнес".

    I>>>Да, а микроскопом можно гвоздь забить. Так и с Лиспом.
    ГВ>>Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.
    I>Это не имеет значения, глядя на 40 лет кобола.

    Не понял.

    I>>>А на лиспе других смысла не стоит нанимать.

    ГВ>>Парочка опубликованных рядом вакансий прямо опровергают это утверждение. Или Приватбанк — это тоже не бизнес, а так, погулять вышел?
    ГВ>>>>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.
    I>Я ж сказал — за гранью статпогрешности.

    Снова не врубился. Ты можешь не так туманно выражаться?

    I>>>Ну то есть надо еще поискать тот бизнес куда можно впихнуть Лисп.

    ГВ>>Это справедливо по отношению к любому языку программирования, лисп — не исключение.
    I>С++, Джава, С№ не надо никуда впихивать. Бизнес сам приходит и просит именно это.

    Повторяю, бизнес бывает разный.

    I>>>Прекрасно обжился это когда хотя бы каждый десятый проект на нем создается. Это гарантирует что лет черз 10 будт спецы хотя бы для поддержки проектов.

    ГВ>>Ой, ну извините... Ладно, продолжай демонстрировать всяческое презрение к лиспу дальше, у тебя это хорошо получается.
    I>Презрение это твоя проекция.

    Я не знаю, какой ещё вывод можно сделать из постоянно повторяемых тобой "не нужен" на пару с апелляциями к "статпогрешности", извини, если чего. Космический масштаб, однако...
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[35]: С vs C++
    От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
    Дата: 31.05.10 10:03
    Оценка:
    Здравствуйте, Ikemefula, Вы писали:

    ГВ>>Если я правильно помню, то помимо всего прочего, во времена кобола лисп однозначно ассоциировался с задачами ИИ, но никак не с повседневными экономическими расчётами. Но, конечно, факторов тут много, спекулировать на каком-то одном — неблагодарное занятие даже для КСВ.

    I>Лисп и сейчас недалеко ушел от ИИ, экспертных систем.

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

    ГВ>>>>Да, я совершенно согласен с тем, что лисп — весьма неплохой язык.

    I>>>Это не имеет значения, глядя на 40 лет кобола.
    ГВ>>Не понял.
    I>Кобол считается очень уродливым языком.

    Обратно не понял. К чему это всё?

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

    ГВ>>>>>>Толк здесь тот, что дальнейшие утверждения нужно перестраивать в зависимости от характеристик самого бизнеса.
    I>>>Я ж сказал — за гранью статпогрешности.
    ГВ>>Снова не врубился. Ты можешь не так туманно выражаться?
    I>Кол.во резюме за гранью статпогрешности, ты просто поторопился с выводами.

    С каким это выводами я поторопился? С теми, что иногда лисповиков таки ищут? Ну так ведь ищут же. А о количественной доле я, вроде как, никаких утверждений не делал.

    ГВ>>>>Ой, ну извините... Ладно, продолжай демонстрировать всяческое презрение к лиспу дальше, у тебя это хорошо получается.

    I>>>Презрение это твоя проекция.
    ГВ>>Я не знаю, какой ещё вывод можно сделать из постоянно повторяемых тобой "не нужен" на пару с апелляциями к "статпогрешности", извини, если чего. Космический масштаб, однако...
    I>Не нужен и статпогрешность никакого отношения к презрению не имеют и иметь не могут.

    Кое-какие основания у меня всё же есть, но не суть. Не буду заниматься мозговедением.
    Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
    P.S.: Винодельческие провинции — это есть рулез!
    Re[20]: Держи, пожалуйста, себя в рамках!
    От: esil  
    Дата: 07.06.10 00:18
    Оценка:
    Здравствуйте, Vamp, Вы писали:

    E>>То что я хотел сказать, я сказал уже много раз.

    Проблемы с декорайией С++ имён не так страшны, чтобы помешать использовать С++ в качестве языка части API OS


    V>Я так и не смог понять, почему для иллюстрации этого тезиса ты выбрал КОМ, который НЕ НАПИСАН НА С++, не экспортирует С++ интерфейсы и вообще не имеет отношения к С++.



    Ком написан на английском (скорее всего). Это стандарт. Наверное он вообще к языкам программирования отношения не имеет?
    Способ экспорта и язык реализации пяти сервисных функций — это мелкие детали.
    Re[3]: С vs C++
    От: vladimir.vladimirovich США  
    Дата: 09.06.10 18:21
    Оценка:
    Здравствуйте, TarasCo, Вы писали:

    TC>Э, да ты сразу на святое замахнулся! Все спипишники считают, что два креста благословят их код и спасут их ноги.


    И будут они на этих крестах дважды крусификнуты .
    Re[20]: С vs C++
    От: zverjuga Беларусь  
    Дата: 10.06.10 11:06
    Оценка:
    Здравствуйте, CreatorCray, Вы писали:

    I>>Отчасти это верно, потому что С++ уже вытеснен в дотаточно узкую нишу.

    CC>Твои фантазии касательно ниши С++ (и сопутствующий им флейм) оставим в стороне.

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