Re: За что я не люблю С++
От: LaptevVV Россия  
Дата: 26.05.09 11:00
Оценка: 3 (3) +4 -7 :))) :)
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

_>Он не просто его, не любит, он его ненавидит. И других заразить пытается.
_>Вот, думаю, тролль Отличная приманка для священной войны.
Кстати, хорошая статья...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 10:16
Оценка: 8 (4) -5 :))) :))) :)
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

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

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

1.

Впервые с зыком С++ я столкнулся почти 15 лет назад (почуствуйте какой стаж начав работать на Turbo C++. Тогда из доступной литературы по объектно-ориентированному программированию у меня было очень хорошее (как мне тогда казалсь) руководство по ООП на Turbo Pascal 5.5.


[0xC0000005]
Ха, вот имено столкнулся, лбами, и судя по всему скорлупа его мозга дала непоправимую трещину, сорри за лирику — не выдержал.
А по сути человек сам говорил что столкнулся впервые 15 лет назад, я тоже 15 лет назад столкнулся с бейсиком, но я считаю я не могу осуждать тот язык управляющий "Электроникой БК-10" за то что у меня что-то не получилось, что-то сломалось, и на экзамене я затёр учительскую дискету.
У него было руководство по ООП — книга по паскалю. Занятно, как такой гений (как о нём тут шарписты шаркают) выбрал имено Паскаль 5.5, ведь в нём небыло обьектов, если помните Pascal with Objects был введён с версии 7.0 борландовсой ИДЕ, и у меня в школе была эта замечательная книга, в которой строилась симуляция шахматной доски, и для Паскаля она была замечательной, но не для ООП, нет и ещё раз нет, ООП это не база для языка, ООП это методика организации логики которая может поддерживаться языком. Это как говорить о том, что я выучил курс гидромеханики разобрав медицинксий шприц или клизму — вы поймёте одно два правила, но не поймёте науки.

2.

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

И вот такого там 90%, изречения ничем не обоснованные, замете, что автор говорит сугубо о своём опыте, о неудачном опыте, он не говорит о том что этими корявыми средствами он делал шедевры, а говорит что в его кучерявом дизайне и коде виноват имено С++, это называется трезумция виновности, когда отталкиваются от обвинения, а не от защиты.
А примеры? Как такой крутой перец и гуру не наваял нам с десяток красивых примеров.


И вот тут я хочу остановиться на книге "Exceptional C++" в двух томах, где описывается как молодой девелопер может сделать криво, а как после прочтения это можно сделать шедеврально.


3.

Только вот как понимать ОО — я не думаю, что программисты, пишущие на Smalltalk'е, сочтут С++ объектно- ориентированным языком. Даже по сравнению с Java С++ явно в проигрыше — нет интерфейсов (зато есть множественное наследование со всеми его проблемами), объектная модель просто отсутствует.

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

Даже по сравнению с Java С++ явно в проигрыше

Вот это да, 4 года работаю с жабой в "огромных" (компания лидер в индустрии, не буду называть) индустриальных масштабах, и всегда видел интерфейс как "заплатку" на дырень моно-наследования. А дело было вот как, и это можно увидеть по эволюции, разработчики Явы сказали — нам не нужно множественное наследование, потому-что есть такие кучеряшки, которые могут при помощи паяльной лампы картошку варить, но при этом дерево иерархий превращялось в список, что делало из полиморфизма обрубок. Тогда решили сделать множественное наследование, и разрешить наследовать от одного класса, и одного и более недо-класса, который не мог бы вызвать испражнения из кучерявых пальцев говнокодеров, те никаких имплементаций, которые могут вызвать двоиственность сущностей, только описание метода, или словами микрософта — Pure Virtual Function.

Много ли Вы знаете простых и удобных persistence-библиотек для С++, которые бы сами могли сериализовать произвольные объекты ? Максимум, что есть, это сложные библиотек с кучей ограничений и необходимостью вручную (зачастую при помощи макросов) задавать фактически часть метаинформации.

Во первых зачем? А во вторых эти сахарные названия Persistence, Hibernate, DataObject, Serializable... как это всё напоминает ныне покойный билдер с его ВСПЛ(только не надо о его реинкорнации в кодгеар), и замете билдер был и под плюсы, и всё там было, но оказалось ненужным в настоящем языке, а всё потому-что плохому танцору... нужны контролы, компоненты, фичи, крутой язык, автоматика во всём, даже мозх автоматический, 500 крутых названий, зазубривши которые ты зовёшся гуру.

А много ли явошарпы знают удобных, простых и "интуитивно" понятных способов расширить функционал языка? Вот у меня требование к либе, я хочу регить callbackи вот таким способом:
alarmNotifier = GUIHandler::onAlarm + CoreRoutine::onAlarm
и что? у вас есть "костыль"? или всё чего нету нам не надо? Ха, это мертвецки неправильно, и обычно такое отмирает как несовершенное.

А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:
logger::log(__filename__, __line__, "log text")

Ой, а никак, и даже костыли такие не выпускают, фабрика ещё не открылась, ну ничё, когда дядя Билл захочет нам это надо будет


А вот в Smalltalk'е или в Python'е таких библиотек полно.

Ага, а теперь скажите мне, у меня огромный обьект, но я хочу сериализовать только, замете слово ТОЛЬКО хидеры во всей иерархий, вот так я это использовал:
dataStream << Modifiers::HeadersOnly << hugeObject;

Слабо? или вы можете кичиться только готовыми фичами, но поверте мне, до 50% времени у больших команий использующих управляемые языки уходит на обход невозможности что-то сделать самому. И давайте честно, с примерами — сделайте мне на Яве универсальный алгоритм, да, который берёт генерик класс и делает с ним что-то своё, что есть общее для генерика. И не говорите мне что этот обрубок шаблонного метода вообще можно считать генерик, напишите-ка

public <T> void f()
{
T t = new T();
t.f();
}

Аааа, какой ужос, нельзя вызвать ничего из общего класса, ничего, есть только мега-костыли которые опустим здесь дабы не говнокодить.
Знаете что было придумано дабы обойти всё это? был сделан препроцессор для Явы, да, препроцессор, вернулись к яблони таки.


А как дела у С++ с интеграцией со скриптовыми языками

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


Кроме того, С++ вообще не различает два существенно РАЗНЫХ понятия — абстрактнывй тип данных (АТД) и объект.

Те в С++ обьект и тип данных это одно и тоже? Не смешите мой зад.


А вот в Objective-C (другой вариант построения объектно-ориентированного языка на основе С, только в нем используется объектная модель языка Smalltalk) можно прямо на ходу узнать какие интерфейсы поддерживает объект, какие у него есть методы. Можно даже прямо на ходу добавить новый метод. И это компилируемый язык, весь графический интерфйес таких операционных систем как NeXTSTEP и Mac OS X построен именно на этом языке.

Хмм, всегда задавался вопросом о мозгах кодеров пишущих:
if(a instance of A1) ...
else if(a instance of A2) ...
else if(a instance of B) ...
else if(a instance of C) ...

Вот скажите мне серьёзно, хоть один реальный пример в рамках одного приложения(про распределённые системы отдельный разговор), когда на этапе компиляции тип обьекта не известен, а если он известен, то зачем его узнавать? Потеряли — плохой дизайн и кучерявые руки!!! + обрезанность языка.


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

А про шаблонные классы и алгоритмы автор видимо не читал, где вызов подставляется на этапе компиляции.


В С++ это практически невозможно сделать. Именно поэтому сперва в Delphi и C++ Builder, а затем и в остром С появилось возможность делегирования как расширение языка.

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


void func1 ( A& a );

void func2 ( A a );

В чем разница между этими описаниями (кроме того, что возможно программист просто пропустил символ '&') ?

а в чём разница между func1(a) и func1(a.clone()), в том что в первом варианте кодер забыл вызвать клон
А как передать строку в Яве, чтобы она была output parameter? Вот смеху то, надо создавать холдеры, и почему в яве


void f(String s)
{
    s = "I'm dummy";
}


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


Есть примеры на STL, когда эффективность на простых строковых операциях падала в десятки раз.


А так же примеры где производительность увеличивалась в 1000 раз, и тоже благодаря аллокаторам из СТЛя, а сделайте ка мне аллокатор на шарпе дорогой (только не надо что менеджер памяти мега умный и всё знает, он ничего не знает кроме вашего говнокода)


Т.е. на С++ МОЖНО писать очень эффективно. И НЕКОТОРЫЕ даже пишут. Вопрос только — относитесь ли Вы к их числу ?

Да, а вы?

TO BE CONTINUED!!!
Re[46]: Ну ты вообще многого не видишь... ;)
От: Хвост  
Дата: 07.06.09 23:02
Оценка: +7 -2 :))) :))
Здравствуйте, criosray, Вы писали:

C>Небольшой тест производительности std::wstring в сравнении со StringBuilder.


чем больше я вижу твоего С++ кода, тем больше понимаю почему тебе было мучительно больно на нём писать и ты перелез на C#
People write code, programming languages don't.
Re[6]: За что я не люблю С++
От: CreatorCray  
Дата: 01.06.09 13:58
Оценка: 3 (1) +4 -2 :))) :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Хм. Misusing = моветон? У тебя снова какое-то странное прочтение. Можно в микроволновку сунуть домашнюю собаку, это ещё не означает, что микроволновка или домашняя собака — моветон.

ГВ>При чём тут множественное наследование? В процитированной тобой статье речь идёт о наследовании вообще.

Я все больше склоняюсь к выводу, что под ником criosray скрывается флеймобот, с которым вообще невозможно конструктивно общаться.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re: За что я не люблю С++
От: -MyXa- Россия  
Дата: 26.05.09 12:19
Оценка: 5 (2) +3 -3 :))
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

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

[:]|||||[:]
Автор:
Дата: 30.03.07


Только в статье — всё не правда. А единственное, чем плох С++, так это тем, что с ним можно 1 раз 15 лет, а можно (как в случае с автором) 15 раз по 1-му году.

За 15 лет автор так и не осилил простые вещи:

1) Понятие метаинформации не то, что отсутствует, но в избытке (сомневаюсь, что он читал Александреску — скорее, он его под ножку стола подкладывал)
2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько. Можем и с сами написать — вон, на кывт-е есть статья про сериализацию в хмл, ещё другая есть, про которую все знают. "А вот ... в Python'е таких библиотек полно". Питон — программа на С, библиотека С-шная, а мужики-то не знают.
3) "А как дела у С++ с интеграцией со скриптовыми языками...". Boost.Python, CliPP, (шёпотом: COM) и др.
5) Про "addVector, subVector" я не понял. Про АТД я не понял тоже, Википедия говорит, что примеры АТД — это разные контейнеры, а отчего абстрагироваться в случае с Vector3D, я ума не приложу.
6) "Но все его чудеса относятся почему-то исключительно ко времени компиляции". Рассмешил до икоты. Если-б все эти чудеса никак не отражались на рантайме, то зачем-они тогда нужны?
7) "на каких компиляторах он весь код свой проверял, скорее всего вы ни одного из них просто не знаете". Ну, автор, может и не знает — я знаю. И чего? Короче, бла-бла.
8) "А как же исключения (exceptions), а как же RTII ?. За них то я всегда плачу всегда !!!". Караул! Заявляю — RTII в С++ никогда не было, и не предвидится следующие лет 10 точно. Мы тут, давеча, с коллегами драйвер писали, ядерный, для Виндовс — исключениями мы не смогли воспользоваться (не то, чтоб совсем не хотелось, но нужна ведь поддержка со стороны рантайма). STL и IOstreams чувствуют себя и без исключений хорошо.
9) "будет изменена лишь копия объекта, которая сразу же после этого будет разрушена. Здорово, а ?". А некоторые языки, например, не позвляют выразить тот факт, что переданный в метод объект не будет изменён методом, которые принимает этот объект в качестве параметра.
10) "А для всех остальных — это скорее игра случая". Ну, для тех, кто профайлер за 15 лет ни разу в руки не брал, да. Кстати, мне не встречались такие профессионалы (которым не нужен был бы профайлер), могущие на глаз найти _все_ проблемы с быстродействием.
11) "Откройте почти любую серьезную книгу (а не С++ за 24 часа) по С++ — о чем там написано ? Как НЕ НАДО делать". Откройте "Java(TM) Puzzlers: Traps, Pitfalls, and Corner Cases".
12) "Сравните объем описания языка С и С++ — разница в объеме во много раз". Ну, давайте сравним native для Явы (любители Явы — не бейте ногами, что использовал, про то и говорю) на JNI и аналог на С++ для Питона на Boost.Python.
13) "средств получить информацию о типе-параметре в языке просто нет" . Язык С++ на столько крут, что "в языке" это и не нужно — можно написать библиотеку. boost::is_abstract, is_arithmetic, is_array, is_base_and_derived, is_base_of, is_class, is_complex, is_compound, is_const...

После слов "Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" этого профана сил осиливать его поток у меня не осталось.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[2]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 13:05
Оценка: +3 :))) :))) :)
Здравствуйте, LaptevVV, Вы писали:

LVV>Кстати, хорошая статья...


Да, действует как "Ласковый май" на металлиста.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: За что я не люблю С++
От: jazzer Россия Skype: enerjazzer
Дата: 03.06.09 01:48
Оценка: 8 (4) +5
Здравствуйте, WolfHound, Вы писали:

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


J>>Там в полный рост зоопарк компиляторов.

J>>Это можно записать в недостатки С++ как платформы, но не С++ как языка.
WH>Далеко не только.
WH>Там тонны костылей для извлечения метаинформации.
WH>Куча костылей для того чтобы сделать какой нибудь трюк.
WH>Короче почти все решения из серии через зад автогеном.
Ну, если ориентироваться только на нормальные компиляторы, то костыли эти достаточно прямые и простые, а веселье начинается, когда пытаешься заставить это работать на всех компиляторах, включая уродцев типа мс-шестерки и сана. Наверное, если бы AT&T изначально владела языком и вкладывалась в него, как Сан с явой или Мелкософт с шарпом, не допуская зоопарка, то такого не было бы, но тогда другие времена были, у всех языков была масса диалектов (да и сейчас, вон посмотри на хаскель).
Но главное то, что все это внутри библиотеки и пока тебе не понадобилось туда нырнуть, пользоваться библиотекой легко и приятно и зоопарка под капотом не видно. И, имхо, то, что на таком старом языке можно написать библиотеки уровня Boost.Fusion и Boost.Proto, говорит только в пользу этого языка.
Хотя, конечно, неплохо было бы иметь все это (метаинформацию) встроенным непосредственно в язык, с этим никто не спорит.
Но метаинформации в С++ не было изначально, просто потому что он — наследник С, а там это чуждая концепция.
Сам понимаешь, в язык с таким наследием добавлять новые фичи нужно очень аккуратно, иначе С++ кончит как D, который сам с собой не совместим.
Так что что есть, то есть.
Конечно, она в том или ином виде будет добавлена в язык, но в каком именно — это большой вопрос, которым нужно заниматься, а на это у комитета банально нету времени, потому что гораздо больше народу требуют многопоточности и сборки мусора (последнюю так и не успели вставить в С++0х).
Собственно, то, что будет с С++ дальше, можно увидеть здесь:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2869.html (прокрути до "Not ready for C++0x, but open to resubmit in future").

J>>Имхо, это совершенно некритично, и никто не мешает к этому чистому контракту привернуть пару невиртуальных функций — это никак на чистоте контракта не скажется, так как то, что было чисто виртуальным, им и останется.

WH>Не согласен.
WH>В принципе можно иметь реализацию по умолчанию но возможность перекрытия должна быть в обязательном порядке.
Так она и есть, или я тебя не так понял.
Плюс контракт — это гораздо более широкое понятие, чем интерфейс. И в этом смысле класс С++ подходит для выражения концепции контракта лучше, чем просто интерфейс, потому что интерфейс редуцирует контракт до набора (причем фиксированного!) функций, что не всегда оправдано.
WH>Иначе могут быть проблемы связанные с тем что конкретную реализацию таки не устраивает реализация по умолчанию.
WH>Именно по этому вообще любое наследование реализации зло.
В С++ наследование — это не только наследование в классическом понимании ООП.
Там, например, наследуются типы/тайпдефы, и тому подобное. Вспомни CRTP хотя бы.

WH>Одним из приемлемых вариантов было бы что-то вроде этого:


WH>
WH>interface Iface1
WH>{
WH>...
WH>}
WH>interface Iface2
WH>{
WH>...
WH>}

WH>mixin Iface1Impl
WH>  implements Iface1
WH>{
WH>...
WH>}

WH>mixin Iface2Impl
WH>  implements Iface2
WH>  required Iface1
WH>{
WH>...
WH>}

WH>class SomeClass
WH>  implements Iface1
WH>  implements Iface2
WH>  aggregate Iface1Impl
WH>  aggregate Iface2Impl
WH>{
WH>...
WH>}
WH>

WH>Миксин может реализовывать один или несколько интерфейсов и требовать реализации некоторых интерфейсов.
Это можно и сейчас dynamic_cast-ом сделать.

WH>К миксину привести нельзя.

Почему? В чем смысл такого ограничения?

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

А чем тебя не устраивает подход ATL/WTL?
Он, кстати, позволяет частичную реализацию интерфейса — как насчет твоих миксинов? Они должны реализовывать интерфейс полностью или частично тоже сойдет? И если да и если ты хочешь собрать свой класс из вот таких вот частичных реализаций, ты разве не поимеешь все проблемы множественного наследования, которые есть сейчас? А если нет — так уж ли оно полезно, если вспомнить про какой-нть интерфейс OLE-объекта с 53 функциями?

J>>+1. Но это спор не о языках, а о библиотеках.

WH>Скажи это 0xC0000005
В смысле? Я не помню всех кодов ошибок, расшифруй, плиз

J>>+1. Макросы Немерле было бы очень здорово поиметь в плюсах. Много проблем бы сразу ушло.

WH>Макросы немерла имеют своих тараканов. А именно они совершенно не формализованы и осень сильно подвязаны на конкретную реализацию конкретного компилятора.
WH>Но этот недостаток можно устранить.
WH>Правда серьезной переработкой языка и компилятора.
О чем и речь
Так просто наскоком такую подсистему в язык не добавить — цена ошибки слишком велика.
Для этой цели (обкатки концепций) такие молодые языки, как Немерле, подходят идеально, и их ценность в этом смысле сложно переоценить, и в этом их отличие от промышленных языков.
А вот когда обкатают и будет наработана достаточно большая база решений и, что более важно, граблей, тогда можно думать и о встраивании концепции в промышленные языки.

WH>Но не до конца. .NET собака такая под ногами со своей кривостью путается.

Прям как в С++
Ну, в общем, как я и говорил энтузиастам дотнета сколько-то там лет назад ("У вас тяжкое наследие, а у нас все свежее и необремененное" — "Ничего, поговорим лет через 10"), как мы скрипим от унаследованных недостатков С++, так и явисты/дотнетчики заскрипят, когда осознают, что их новые свежие языки-платформы неидеальны, и не упрутся в их пределы и в никуда не девшиеся требования совместимости с существующим кодом (а в случае явы/дотнета — еще и с существующим байт-кодом).
А особенно когда еще через лет появится какая-нть модная технология, про которую все будут говорить: "Это must have, она должна быть в любом нормальном языке по умолчанию, все остальные на помойку!" (как сейчас с рефлексией, сериализацией и т.п.) а явисты/дотнетчики будут чесать репу, понимая, что на их языках невозможно по-человечески эту фичу реализовать, потому что она не будет ни с чем совместима и сломает язык. И будут предлагаться библиотеки, дающие требуемую функциональность, а неофиты будут плеваться и называть их костылями, и будут показывать пальцем на какой-нть новый язык Ветч или Гед, в котором эта фича уже есть сразу и выглядит красиво и непротиворечиво (но это только пока ею не начали пользоваться достаточно широко — тут-то и будет собран урожай граблей, которых вначале видно не было).

Нету идеальных решений на свете.
Как говаривал Страуструп, есть два вида языков (шире — технологий): те, которые все ругают, и те, которыми никто не пользуется.

Так что у С++ есть свой хорошо известный набор проблем, есть не менее хорошо известный (и зачастую вполне удобный) набор средств по их устранению/недопущению/предупреждению, и профессиональные программисты вполне комфортно себя чувствуют, хотя это и не значит, что они не будут приветствовать усилия комитета по уменьшению этого набора.
Ну и у явы/дотнета/шарпа/немерле/etc есть свои проблемы и свои инструменты.
Let it be.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
За что я не люблю С++
От: dmitry_npi Россия  
Дата: 26.05.09 10:21
Оценка: 1 (1) -4 :))
Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.
Он не просто его, не любит, он его ненавидит. И других заразить пытается.
Вот, думаю, тролль Отличная приманка для священной войны.
Атмосферная музыка — www.aventuel.net
Re[50]: Ну ты вообще многого не видишь... ;)
От: Mamut Швеция http://dmitriid.com
Дата: 08.06.09 14:41
Оценка: +4 :)))
Здравствуйте, criosray, Вы писали:

c> _>Не, не верю. Самописных систем я видел очень мало, а вот кастомизированных коробочных много.


c> Ну значит мы говорим о разных вещах. Если уж Вы мне не верите, то постарайтесь подумать логически и ответить себе на вопрос — чем заняты миллионы джавистов и дотнетчиков в корпоративном секторе (а именно этот сектор основной для этой категории программистов).


Создают видиость работы Как и большинство программистов, вне зависимости от языка программирования
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[4]: За что я не люблю С++
От: doarn Россия  
Дата: 26.05.09 20:08
Оценка: 1 (1) +5
Здравствуйте, LaptevVV, Вы писали:

LVV>Вроде это тот Боресков, который книжки по графике в ДиалогМИФИ печатает. Чел вполне квалифицированный...

Возможно писатель он и квалифицированный (не читал, не видел), но в голове у товарища явная каша.
Re[18]: интефейс и контракт...
От: criosray  
Дата: 01.06.09 21:48
Оценка: -3 :)))
Здравствуйте, Геннадий Васильев, Вы писали:

E>>>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:
struct IOrder {
E>>>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>>};

C>>Да, это вполне корректный интерфейс, хотя и костыль, т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.

ГВ>А кто сказал, что интерфейс должен содержать только абстрактные методы? Чем не абстрактные методы противоречат "интерфейсу"?

Абсолютно всем. Интерфейс с методами — не интерфейс, а просто класс.

E>>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

C>>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?

ГВ>При том, что эти утверждения — неотъемлемая часть интерфейса, которую могут (и должны) учитывать его пользователи.

Это может быть неотъемлимой частью объектов классов, реализующих данный интерфейс, но уж никак не интерфейса.

E>>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...

C>>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.

ГВ>Контракт формулируется для интерфейса, а реализуется — реализующим интерфейс классом.

Контракт формируется для класса, а не для интерфейса. Интерфейс это и есть контракт.

Вам не наскучило пороть чушь?
Re[38]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.05.09 05:04
Оценка: 2 (1) +1 -1 :))
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Тогда я смогу сделать так:

ГВ>
ГВ>template<typename T, ...> class Property : public PropertyBase<T> { ... };

ГВ>temaplate<typename T, ...> class MySmartProperty : public Property<T> {
ГВ>  private:
ГВ>    // Предположим, что такая проперть имеет какую-нибудь хитрую функцию,
ГВ>    // вызываемую, например, при изменении значения:
ГВ>    void HiddenSmartFunc() { ... }
ГВ>};

ГВ>// Тогда тестовая функция может выглядеть так:
ГВ>void MyTestFunc(PropertyBase<int> *prop){
ГВ>  *prop = 42;
ГВ>  // Проверяем - вызвалась ли HiddenSmartFunc
ГВ>}
ГВ>


void MyTestFunc(Action<int> propSet)
{
  propSet(42);
}

MyTestFunc((int i) =>{myObj.MyProp = i});



ГВ>Но это мелочи. Гораздо интереснее другое возможное применение. Например, у нас есть класс какого-нибудь развесистого окна с развесистым же управлением, например, свойствами Enabled. Если я могу оперировать свойствами, как отдельными объектами, то я могу написать функцию управления Enabled примерно так (пример сильно упрощённый):


void ManageEnabled(Action<bool> propOK, Action<bool> propCancel) {
  if (someCondition)
  {
    propOK(true);
    propCancel(false);
  }
  else if (otherCondition)
  {
    propOK(false);
    propCancel(true);
  }
  else // strangeCondition
  {
    propOK(false);
    propCancel(false);
  }
}


ГВ>Обрати внимание, что эта функция не зависит от типов объектов-носителей самих свойств. Ими могут быть и окна, и какие-нибудь другие классы.


ГВ>Но это ещё не всё. Эту же функцию можно обобщить:

ГВ>
ГВ>template<typename P1, typename P2>
ГВ>void ManageEnabled(P1 &propOK, P2 &propCancel) { ... }
ГВ>


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


bool bOK = false, bool bCancel = false;

someCondition = true; // Это упрощение - я имею в виду, что мы привели тестовое окружение в состояние,
// когда внутреннее условие someCondition станет true.
var propOk = (bool b)=>{bOK=b;};
var propCancel = (bool b)=>{bCancel=b;};
ManageEnabled(propOk, propCancel);

TEST_ASSERT(bOK && !bCancel);

otherCondition = true;

ManageEnabled(propOk, propCancel);

TEST_ASSERT(!bOK && bCancel);

someCondition = false;
otherCondition = false;

ManageEnabled(propOk, propCancel);

TEST_ASSERT(!bOK && !bCancel);

ГВ>Само собой, её можно перетаскивать из класса в класс, положить в библиотеку, использовать ещё как-то и т.п.

ГВ>Ну вот, примерно так. На вскидку. Пожалуй, ещё можно добавить, что можно собрать указатели на свойства в массив, ещё как-нибудь использовать. Короче говоря, применять к свойствам полный комплект методов работы с обычными классами.

Когда у тебя в руках молоток — всё кажется гвоздями. Когда С++ — всё кажется классами. Оказывается, не обязательно быть классом для того, чтобы успешно работать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 14:12
Оценка: +2 :)))
Здравствуйте, Геннадий Васильев, Вы писали:

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

C>>С мира по нитке..

ГВ>И будет гора ниток.


Гора ниток — очень точная характеристика с++.
Re[10]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 18:42
Оценка: -3 :))
Здравствуйте, Antikrot, Вы писали:

C>>>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.

A>вот тут осторожней ведь в ответ могут поставить условие чтобы твой код на C# c linq компилировался хотя бы тремя современными С# компиляторами хотя бы на трех архитектурно разных платформах

LINQ — стандартная языковая фича. В отличие от microsoft specific properties.

ГВ>>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx


C>>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк

A>а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?

В чем разница между стандартным решением и ужасным костылем?


class Test
{
    // outside the scope of class Test, 
    // set and get are both public
    typedef ::Property<    
        ::Test, 
        ::Number_Accessor<::Test>, 
        ::Number_Accessor<::Test>::value_type> Property_Number;

    // outside the scope of class Test, 
    // set is public and get is private
    typedef ::Property_Set_Public<    
        ::Test, 
        ::Number_Accessor<::Test>, 
        ::Number_Accessor<::Test>::value_type> Property_Set_Public_Number;

    // outside the scope of class Test, 
    // set is private and get is public
    typedef ::Property_Get_Public<    
        ::Test, 
        ::Number_Accessor<::Test>, 
        ::Number_Accessor<::Test>::value_type> Property_Get_Public_Number;

public:
    Property_Number               Number_A;
    Property_Set_Public_Number    Number_B;
    Property_Get_Public_Number    Number_C;
};



public class Test
{
   public int Number_A { get; set; }
   public int Number_B { private get; set; }
   public int Number_C { get; private set; }
}


Действительно... в чем разница...

Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.

A>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

A>ну если о костылях, так C# — костыль к IL, который костыль к machine code, который костыль к cpu uops, который... ну короче продолжите сами

Чушь.
Re[7]: За что я не люблю С++
От: CreatorCray  
Дата: 27.05.09 07:53
Оценка: +4 -1
Здравствуйте, MxKazan, Вы писали:

CC>>А тут написанные библиотеки в комплект не входят.

MK>В случае тех же свойств, не "библиотеку положили рядом", а компилятор научили работать. Всё-таки есть разница.
По мне так один хрен.
По мне так в компилятор надо впихивать то, что никак нельзя нормально реализовать через библиотеки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: За что я не люблю С++
От: COFF  
Дата: 28.05.09 09:02
Оценка: +3 :))
Здравствуйте, criosray, Вы писали:

C>Программисты С++ уже и гуглем пользоваться разучились? http://en.wikipedia.org/wiki/Associative_array


Жжошь неподецки
Re[16]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 06:04
Оценка: +2 -2 :)
E>Ну и так далее...
Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
0. Они не immutable.
1. Они слишком сильно сосредоточены на бинарном представлении.

Строки дотнета тоже не лишены недостатков, но об этих недостатках дефолтным строкам стандартной библиотеки плюсов еще приходится только мечтать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 04.06.09 10:25
Оценка: +1 :))) :)
Здравствуйте, Sinclair, Вы писали:

S>Вы, наверное не догадываетесь, но COM — далеко не всё, с чем может интероперировать шарп.

Программа на КОБОЛе.

*пошёл с горя уходить в запой*
Sapienti sat!
Re[69]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 13:39
Оценка: -2 :)))
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Собственно, снова два теста:

Этот маразм всем маразмам маразм.

ГВ>
ГВ>for (int i = 0; i < Count; i++)
ГВ>{
ГВ>    s = sb.ToString();
ГВ>}

ГВ>


ГВ>Соотношение времени выполнения... 6:1 в пользу C++


.NET
Elapsed 00:00:00.0765671
Copied chars: 25000000000
Average copy speed 653021,989862486 MB/s

C++
2605
50000000000 bytes copied, with speed of: 19193 MB/s

Исправленный код:
            const long count = 10000000;

            var sb = new StringBuilder();
            
            sb.EnsureCapacity(10000);

            for (int i = 0; i < 50; ++i)
                sb.Append("01234567890123456789012345678901234567890123456789");
            
            String s, s1;

            var stopwatch = new Stopwatch();

            stopwatch.Start();
            
            s = sb.ToString();
            for (int i = 0; i < count; i++)
            {
                s1 = s.Substring(0, s.Length);
            }
            
            stopwatch.Stop();
            
            Console.WriteLine("Elapsed {0}", stopwatch.Elapsed);
            Console.WriteLine("Copied chars: {0}", sb.Length * count);
            Console.WriteLine("Average copy speed {0} MB/s", (sb.Length * count * 2) / stopwatch.Elapsed.TotalMilliseconds / 1000);


Соотношение считайте сами.
Re[17]: Хватит ужо позорить шарпистов-то... ;)
От: Erop Россия  
Дата: 01.06.09 23:21
Оценка: 2 (1) +2 -1
Здравствуйте, criosray, Вы писали:

E>>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:
struct IOrder {
E>>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>};

C>Да, это вполне корректный интерфейс,
Значит ты используешь слово "интерфейс" в этаком COM-образном смысле, а не в смысле "интерфейс класса". Хорошо, давай придерживаться такой терминологии...

C> хотя и костыль,

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

C>т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.

Во-первых, это только вопрос об определениях. Интерфейс же нужен не для того, чтобы состоять только из чисто виртуальных методов, а для того, чтобы формально зафиксировать какой-то аспект взаимодействия объектов из объектной модели... Если используемые средства разработки (как COM, например) навязывают виртуальность всех аспектов интерфейса, то невиртуальные части в нём недопустимы, а если не навязывает, то от чего бы и нет? Это к основной, главной и единственной задачи интерфейса -- формализовать какой-то аспект взаимодействия с реализующим интерфейс объектом, не имеет прямого отношения -- виртуальный какой-то метод или нет...

E>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...


C>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?

При том, что интерфейс -- это формализация взаимодействия. Она требует декларации и соблюдения контракта, иначе ты не сможешь реализовать ни одну из сторон взаимодействия: ни реализовать интерфейс, ни воспользоваться им...

E>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...


C>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.


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


В целом постарайся не выглядеть менее образованным и умным, чем ты есть на самом деле. Потому что пока ты своими не особо интеллектуальными понтами всего лишь демонстрируешь ложный на самом деле тезис, что те кто людит ХиндиС слегка неладёкие люди...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.10.09 13:56
Оценка: 2 (1) :)))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Еще раз, Влад, пойми мою позицию — я не обсуждаю маргинальные направления.


А с чего ты взял, что С++ — это не маргинальное направление сдуру прошедшее в массы?

PD> Маргинальные в моем определении не значит плохие, а просто пока не употребляемые в реальном мире.


Маргинальное значит — граничное, стоящее на стыке культур.

PD> Например, Паскаль — маргинальный язык в СССР до появления персоналок. И если бы ты в 1980 году сказал мне, что Паскаль лучше Фортрана, я согласился бы или нет, но обсуждать бы не стал — Фортран есть и царствует, а по Паскалю пара книжек вышла и его в реальности нет. В 1990 году я бы говорил иначе. Поэтому если OCaml и D пойдут всерьез — может быть, я соглашусь, что они лучше. В конце концов, ты же не подозреваешь меня, надеюсь, в том. что я заявляю, что С++ лучше всего на вечные времена. Будет лучше — забудем С++, перейдем на эти языки. А сейчас ему замены нет. Как не было реальной замены Фортрану в 1980.


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

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

Так что их удел — низкоуровневые оптимизации, дрова для стремительно устаревающих ОС, софт для бюджетных самрфонов и места где основной объем кода — это вызов C API. И во всех этих местах С за глаза хватило бы. А с точки зрения удобства несомненно лучше применять Ди и ОКамл.

Так что С++ держится за косность мышления. Но оно со временем меняется. Так что он уверенно идет под горку. Лет через 10-15 он будет там же где Паскль и Фортран, т.е. вроде бы есть, но большая часть молодежи код на нем будет видеть только в ретроспективных книжках.

А лет через 20 при словах "я писал дрова для винды на плюсах" будут звучать как "я водил паровозы".

PD>>>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.


VD>>А что, ниша языка определяется только типом его компиляции?


PD>Зачем же "только". В определенной степени да.


Обоснуй.

PD>>>Нет ему замены, господа.


VD>>Для тех кто только его знает — несомненно, нет.


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


Да на фиг мне твои возражения. Я лично написал тонны кода как на С++, так и на других языках и меня даже за огромные деньги обратно не заманишь. Мне жалко свое время и нервы. Это точно так же как меня ни за какие скидки не заставить купить жигули. Я поездил на машине и на корыто пересаживаться не хочу.

PD>А я что, призываю тебя использовать ?


Не знаю. Рекламируешь — это точно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 19:03
Оценка: 1 (1) -1 :))
Здравствуйте, criosray, Вы писали:

[skip overquoting]

C>Действительно... в чем разница...


Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.

C>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.


Такая же, как и для обычной структуры данных.

A>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

C>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

Угу, "set; get;" как символ истинной лаконичности.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: За что я не люблю С++
От: CreatorCray  
Дата: 26.05.09 11:24
Оценка: +4
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

_>Он не просто его, не любит, он его ненавидит. И других заразить пытается.
Да придирается по-детски как то.
В сравнении с тутошними срачами "C++ vs *" — статья детский лепет и обидки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: За что я не люблю С++
От: March_rabbit  
Дата: 26.05.09 13:35
Оценка: :))) :)
Здравствуйте, Mamut, Вы писали:

M>Объект с циклическими ссылками и членами — указателями на другие объекты. Плюс является наследником другого объекта так, чтобы не надо было явно указывать:

M>
M>ar & boost::serialization::base_object<bus_stop>(*this) & name;
M>


M>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?
здорово, если так.
Re[26]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 09:08
Оценка: +1 -1 :))
Здравствуйте, COFF, Вы писали:



C>>Программисты С++ уже и гуглем пользоваться разучились? http://en.wikipedia.org/wiki/Associative_array


COF>Жжошь неподецки


Вы, молодой человек, постыдились бы своей необразованности вместо того, чтоб выставлять ее на показ.
Re[6]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 29.05.09 21:34
Оценка: +1 -1 :))
Здравствуйте, Erop, Вы писали:

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


WH>>Ничему из этого нативность не нужна.

WH>>Вообще не нужна.
E>Может быть и не нужна, но широко используется... Так что спецы в перечисленных областях делают иной выбор, чем ты...
А "спецы в перечисленных" областях чтонить кроме С++ знают?

WH>>Тут дело лишь в качестве оптимизатора и ни в чем больше.

E>Да не только. Дело вообще в контроле над компом...
Дело как раз в оптимизаторе.
Мне абсолютно пох будет что там происходит с компом если я на каком либо языке смогу писать код, который в 10 раз быстрее выполняется, чем любой другой, на линейных вычислениях.
И подавляющему большинству программистов тоже.

E>Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...

О ужас, ручками код оптимизировать... как же с этим жить?
Кроме того если и надо оптимизировать, то числомолотильные алгоритмы, в остальном и так .NET быстрее работает.
Re[38]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 30.05.09 13:46
Оценка: +2 :))
Здравствуйте, Erop, Вы писали:

Q>>Что-то я запутался, в этой ветке я за дотнет вразумляю, или за сиплюсплюс?

E>Да какая разница? Все хороши :)

Да тут без шуток — вопрос нетривиальный. Читаю топикстарт, там ссылка на статью «За что я не люблю С++». Дай, думаю, Ради Великой Справедливости впишусь за автора, уж больно название понравилось. Потом почитал этот опус, аж руки опустились. Много г**на можно про C++ сказать, но автор почему-то предпочёл придирки из разряда «докопаться до мышей». Это ж профанация критики C++! :)
Глаза у меня добрые, но рубашка — смирительная!
Re[15]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 01.06.09 23:36
Оценка: +2 -2
Здравствуйте, criosray, Вы писали:

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


Ну то, что ты чего-то не видишь, может обозначать всего лишь узость кругозора

Вот тебе проблемка: что таки считать за один символ в строке? Вот положим тот же юникод возьмём. Там бывают такие коды нехорошие, которые к предыдущим буквам диакритические знаки пририсовывают. Вот что соответствует одному символу в этом случае? знаки "U" и "приписать умляут к предыдущему символу" -- это два символа или один?

или вот тебе другая проблемка. Если у тебя есть ивритско-английская строка, например, то у неё есть два порядка итерации букв. Графический и логический. Какой из порядков должна предоставлять правильная строка по умолчанию?

А ещё есть довольно много буквочек, которые в юникоде не представлены. Например, это часть кантонских иероглифов. Зато есть куча других кодировок, популярных в ЮВА, где они все представлены. Вот как хранить в "правильной" строке такого рода символы?

А ещё у реальных строчек, которые в книжках встречаются, есть форматирование. Например строка может быть Allcfps, или иероглифы могут быть того или иного стиля, или текст может быть полужирным, или курсивом, цифры могут быть такими, как их принято писать в Европе (когда 9 и 6 пишется вровень с большой 0), а могут быть такими, какими их принято писать в США (когда кружочки цифр 9 и 6 пишут вровень с маленькой о, а хвосты соответственно торчат вниз и вверх), а ещё могут быть верхние и нижние индексы, ну и т. д... Это всё должна нормальная строка поддерживать или нет?

Вот, например, как в "нормальную" строку должны попадать верхние индексы (которыми обычно сноски обозначают)?..

Ну и так далее...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 10:52
Оценка: +1 -1 :))
Здравствуйте, CreatorCray, Вы писали:
CC>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
Очень простая. Например, иммутабельные строки могут быть ключами в хештаблицах.
Вообще, многие алгоритмы шибко выигрывают от того, что иммутабельность известна заранее.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 07:46
Оценка: +1 -2 :)
Здравствуйте, CreatorCray, Вы писали:

S>>Зато гарантированная константность позволяет использовать хеш строки в качестве части ключа.

CC>Для этого не обязательно вообще все строки принудительно делать константными.
Обязательно. Еще раз: реализация строк в С++ — убожество с точки зрения архитектуры.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 04.06.09 07:35
Оценка: +3 :)
Здравствуйте, WolfHound, Вы писали:

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


PD>>Операционные системы, драйверы, утилиты. (только ради бога не надо про Сингуларити)

WH>Надо.

Меня не интересуют вообще маргинальные направления. Если есть язык/средство/инструмент/и т.д, которое хотя бы 10% рынка имеет — велкам, будем обсуждать. Если же это пусть сколь угодно интересная поделка, реально не применяющаяся, обсуждай не со мной.

PD>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).

PD>>ПО с серьезными расчетами.
WH>Ничему из этого нативность не нужна.
WH>Вообще не нужна.
WH>Тут дело лишь в качестве оптимизатора и ни в чем больше.

Тут дело в том, что в настоящее время эти программы пишутся в основном на нативном коде. Я не хочу заново начинать дискусию, почему это так и может ли это когда-нибудь быть иначе. Может, в светлом будущем, когда память будет терабайтовой , а оптимизация в управляемой среде дойдет до недосягаемых вершин, это и будет иначе. А пока что факт есть факт — такое ПО пишут либо на С++, либо вообще на С.
With best regards
Pavel Dvorkin
Re[26]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 14:26
Оценка: +1 -1 :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>char szString[N];

PD>gets(szString);
PD>strupr(szString);

PD>и ни одного лишнего байта. Можно такое сделать ?

Что сделать?
Проезд по памяти?
Конечно нет.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 09:41
Оценка: +1 -2 :)
Здравствуйте, criosray, Вы писали:


C>Так когда будет дан аналог с указателями с++ для


C>
C>int? a = 1;
C>int c = 10;
C>int? b = (a == null ? a : c) / 100;
C>


C>И давайте без создания лишних сущностей — ввода доп. переменных, ок?


Зачем? Подобный код в плюсах не имеет смысла.
Получится что-то вроде :
    int a = 0;
    int c = 10;
    int b = 0;
    (*(&b)) = ( &a == NULL ? *(&a) : c) / 100;


А давайте MSDN почитаем :

Nullable types can represent all the values of an underlying type, and an additional null value. Nullable types are declared in one of two ways:
System.Nullable<T> variable
-or-
T? variable


Чем это от указателя отличается ?
Можно какой нибудь менее надуманный пример полезности nullable ?
Re[61]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.06.09 05:16
Оценка: +3 :)
Здравствуйте, skeptik_, Вы писали:
_>;####! в код заглядывал? Там unsafe code. К тому StringBuilder — класс заточенный на данную задачу. В итоге мы имеем фактически специальный нейтивный код, против all purpose. Ну и чему тут удивляться?
Удивляться можно только тому, что фанаты плюсов сначала давили на то, что "нет смысла делать два разных класса строк для разных сценариев", а когда их ткнули носом в то, что это таки эффективнее, они тут же стали апеллировать именно к тому, что им с самого начала и говорили: "у вас класс заточен на данную задачу".
Правильно! Совершенно верно! Заточен. Оба класса заточены под свои задачи. И это позволяет получать хороший результат. А вот по соседству бродит некий Егор, который ставит минусы на все мои посты, вот он уверен, что std::wstring — это епик вин С++, и что он не "гора компромиссов между ужами и ежами", а спроектирован побеждать во всех обстоятельствах.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[49]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 17.06.09 04:47
Оценка: +1 -2 :)
Здравствуйте, WolfHound, Вы писали:

Как я понял, ввиду неответа Синклера ты решил взять на себя его функции. OK.

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


PD>>Я уже устал повторять — не собираюсь я применять их к управляемой среде. Не собираюсь, понятно ? Я не принимаю эту управляемую среду именно за то, что к ней нельзя эти образы (коль уж такой термин тебе нравится, пусть так) применить. Именно поэтому она мне и не нравится.

WH>Этим ты выдал всю свою сущность.
WH>Ты не хочешь учится.

Я учитЬся хочу, но только тому, что мне для работы годится. Например, CUDA — годится, поэтому я недавно ее и осваивал. .Net, VB, Python и прочие Хаскели — не годится, а поэтому мне на них время тратить незачем.

WH>А это значит что как профессионал ты уже мертв.


Ну-ну... Скажи об этом моему заказчику

PD>>Пошел делать другую задачу.

PD>>А теперь продолжение.
WH>А чаще всего нету этого продолжения...

Вот на это вы все и рассчитываете. Сделаем как-нибудь, работать все же будет (а кто спорит — будет!), а оптимизировать и не придется. И чаще всего, ты прав, так и получается. У вас.. А у меня — ровным счетом наоборот.

О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы

S>>>Ну, тогда мир СУБД от тебя далёк. Очень жаль — там есть крайне интересные вещи про оптимизацию производительности. Шибко помогает отвлечься от трактовки программирования как == алгоритмы + структуры данных.

PD>>"Нелья объять необъятное" (К. Прутков). В мире программирования есть много чего интересного...
WH>Можно и нужно.
WH>Я имею в виду не детали как работает оракл версии ХХХ, а общие принципы.

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

Кстати, написан MySQL на чистом С. Из чего с неизбежностью следует, что нет там ни геттеров, ни сеттеров, ни интерфейсов, ни темплейтов , ни итераторов и вообще ничего из той кунсткамеры, без которой вы теперь жить не можете. И ничего — вполне себе живет и неплохо себя чувствует.
With best regards
Pavel Dvorkin
Re[5]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 26.10.09 11:22
Оценка: +4
Здравствуйте, VladD2, Вы писали:

PD>>Еще раз, Влад, пойми мою позицию — я не обсуждаю маргинальные направления.


VD>А с чего ты взял, что С++ — это не маргинальное направление сдуру прошедшее в массы?


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

PD>> Маргинальные в моем определении не значит плохие, а просто пока не употребляемые в реальном мире.


VD>Маргинальное значит — граничное, стоящее на стыке культур.


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

VD>Ну, так загляни в угол экрана. На дворе идет конец первого десятилетия нового тысячалетия.

VD>Здоровые люди плюсы используют все реже и реже. Его популярность неуклонно падает.

Не похоже. Скорее так — появились новый области, где С++ никогда и не использовался всерьез. Например, в Интернете — не считать же серьезным использованием CGI или ISAPI. А больше ничего и не было. И в этой области его как не было, так и нет. А где он есть — я уже писал.

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


Ну кто кого тут рвет — из твоей фразы понять невозможно. То ли С рвет С++, то ли кто-то еще рвет кого-то еще...

А насчет половины — такую вот притчу расскажу.

Я не грибник вообще, но в детстве любил читать книги о грибах. И вот в одной книге мне попалась такая фраза про опят : "Очень много, но в массе очень мало". То есть набредешь на колонию опят — их много, а в кузов положишь — вроде как почти пустой кузов и остался. В то время как всего лишь десяток-два белых — и вот тебе полный кузов.
Вот и тех приложений, что не на С++ , очень много, а в массе довольно-таки мало

VD>Сказки про десктоп и редакторы уже порядком надоели. Только совсем отсталый человек сегодня начнет разрабатывать новый десктопный софт на плюсах.


Ну-ну...

VD>Так что их удел — низкоуровневые оптимизации


Именно. И там им конкурента нет.


>дрова для стремительно устаревающих ОС


Wiindows и Linux , без которых твой любимый .Net существовать не может.

>софт для бюджетных самрфонов и места где основной объем кода — это вызов C API.


То есть все то, что использует средства ОС. Правильно.


>И во всех этих местах С за глаза хватило бы


Особенно с твоей идеей насчет инкапсуляции. Чудный код получится.


>А с точки зрения удобства несомненно лучше применять Ди и ОКамл.


Может и да, да ведь не используют же.

VD>Так что С++ держится за косность мышления. Но оно со временем меняется. Так что он уверенно идет под горку. Лет через 10-15 он будет там же где Паскль и Фортран, т.е. вроде бы есть, но большая часть молодежи код на нем будет видеть только в ретроспективных книжках.


Вполне возможно. Ничего тут особенного нет, и плохого ничего нет. Придет время — настанет и пора, как один мой друг говорит. Поживем — увидим.

VD>А лет через 20 при словах "я писал дрова для винды на плюсах" будут звучать как "я водил паровозы".


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

PD>>>>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.


VD>>>А что, ниша языка определяется только типом его компиляции?


PD>>Зачем же "только". В определенной степени да.


VD>Обоснуй.


Я этому вопросу сотни своих сообщений здесь посвятил. Поищи — найдешь.

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


Да кто тебя заманивает ? Я — не буду ни за что. Судя по твоим постингам по С++, твое отсутствие в этом языке только желательно — меньше дилетантского кода будет.

>Мне жалко свое время и нервы. Это точно так же как меня ни за какие скидки не заставить купить жигули. Я поездил на машине и на корыто пересаживаться не хочу.


Не покупай Жигули и не программируй на С++. Лучше будет С++ и даже ВАЗу лучше будет.

PD>>А я что, призываю тебя использовать ?


VD>Не знаю. Рекламируешь — это точно.


А как ты думаешь, зачем я это пишу ? Тебя переубедить ?
With best regards
Pavel Dvorkin
Re[18]: За что я не люблю С++
От: metaprogrammer  
Дата: 06.11.09 20:45
Оценка: +1 -3
Здравствуйте, Игoрь, Вы писали:

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


Не верю. С C++ проблемы всегда. Он не может не создавать проблем, просто в силу низкоуровневости.

И> Потом я просто перерос этот уровень и сменил работу. Дальше были проблемы только с проектами, а не с языком. Да, были ужасные проекты на С++, но были ужасные и на php, и на С#/javascript.


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

M>> Неподдерживаемость кода — это не вред?!? :-O

И>Да поддерживается С++ код.

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

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


На C++ легко поддерживаемых проектов нет.

M>> На C# эта проблема решаема. На C++ — нет. И если коду двадцать лет, то проблемы в нём будут обязательно. Кричать про "квалификацию" просто глупо. Невозможно сделать всё красиво в таких масштабах.

И>Когда С# будет 20 лет, тогда и поговорим. Но уже сейчас поддерживать код, написанный на первой версии языка — удовольствие ниже среднего.

Ничего сравнимого с проблемами C++ нет и быть не может. Язык тупой, примитивный, легко поддаётся автоматическому анализу. Рефакторинг легко автоматизируется.

И>Я согласен, что С++ код даже 15 летней давности — еще та байда, но не стоит забывать, что тогда С++ еще только появился и не были выработаны best practices.


Какое там "только появился"?!? 15 лет назад на нём уже вовсю писали.

И> С# код начала двухтысячных — говно еще то.


И пусть себе. Зато это говно можно легко распарсить и переписать автоматом во что либо меньшей степени говняности. С C++ этот номер не проходит, даже если это managed C++. Недавно имел сомнительное удовольствие переводить код со старого синтаксиса managed C++ на новый — автоматом меньше половины получилось исправить, остальное только вручную.

И> Кстати! Есть у нас один проект, там есть два клиента — один на Java, другой на С++. Оба написаны в конце 90-ых. Разницы абсолютно никакой — что на Java код полное говно, что на С++.


Ну бред же! Зачем такой бред говорить? Java тупа как пробка, анализируется тривиально, десятки автоматов существует для рефакторинга и анализа. Сравнивать с С++ её просто стыдно.

И>Нет, знаем.


Не поверю.

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


AS/400 миллион лет как существует. Лисп-машины Symbolics давным давно были. Только вот Дворкиных всегда слишком много было, с их религией "мои регистры — не отдам!".

M>> Умелых рук в промышленных масштабах не бывает. И, да, сам C++ неуклюж независимо от квалификации программиста — язык нелеп, он заставляет простые вещи делать сложно.

И>А никто и не говорит, что С++ для простых вещей.

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

И>Лепите формочки на С# Я тут, конечно, передернул, но каков аргумент — таков и ответ. "Умелые руки" — означает всего лишь знание инструмента. Ты считаешь, что такого не бывает? Представь себе бывает.


Повторю ещё раз — "умелых рук" в промышленных масштабах не бывает. Любые руки, любые коллективы будут косячить. А язык такой, что косяки не прощает. Чем старше и крупнее проект, тем большее количество неисправимых косяков в нём скапливается.

M>> Естественно. Практикой обоснованное.

И>Если бы твое утверждение было обосновано практикой, то большинство системных процессов windows подгружало бы не msvcrt.dll, а какой-то fortran.dll. И я бы сейчас это сообщение набирал не из google chrome, написанного на С++, а из чего-то другого.

Легаси, легаси. Давно бы все выбросили C++ на помойку, где ему самое место, да легаси не позволяет.
Re[2]: А я вот, например жену люблю, а к языкам равнодушен ;
От: Erop Россия  
Дата: 29.05.09 11:01
Оценка: 3 (2) +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вот что не ладно — какие альтернативы С++ можете предложить в ЕГО НИШЕ ? Вот представьте себе — исчез он. Чем замените ?

PD>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.

Ну замена есть, и она никуда не девалась -- это собственно С. Может быть С с каким-то другими объектными расширениями. Например Objective-C... (типа всё умное в проекте пишем с объектами, а всё быстрое на чистом С)...

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

А так, да, ХиндиС -- гениальное, IMHO, изобретений. Круче VB даже. Для случая "педалить код быстро-быстро, так как готово должно быть уже вчера" -- это самое то. Тут C++ просто сливает со страшной неодолимой силой.
А написать что-то такое сложно-умное, много насилующее память и процессор, то тут уже ХиндиС не тянет. Можно, конечно всякими ужимками и наймом супер-профи противиться очевидному и в том и в другом случае, но это тупо НЕ ВЫГОДНО...

Да, кстати, я не хочу сказать, что есть только два указанных полюса ("быстропедальный" код vs многосчитающий), полюсов на самом деле много, они все в разной степени важны и нужны, но в целом более или менее одинаково почётны. Эти два я привёл просто для примера...


Вывод:
Нет смысла спорить о том, что круче -- шаблоны или свойства. Надо спорить о том, какие программисты более настоящие? Системные или вычислительные? Энтерпрайз или ретейл и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: За что я не люблю С++
От: yuriylsh  
Дата: 31.05.09 07:26
Оценка: 3 (1) +1 :)
Здравствуйте, hattab, Вы писали:

Y>>Ага, точно, и вообще, для графики и редактирования видео многопоточность категорически противопоказана (а особенно в 4-5 VirtualDub'ах)!!!

Y>>

H>VirtualDub таки распараллеливается, чего ты так возбудился? А 4-5 инстансов использую т.к. он (VirtualDub), не то из-за кодеков, не то из-за ошибок во входящем потоке, иногда таки падает, и если использовать его очередь, то очередь он унесет вместе с собой. А так, один из 4-5 упал ночью, так и не страшно -- другие-то проболжают работать.


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

То что VirtualDub распараллеливается я то как раз прекрасно понимаю, я думаю, иронию в моих словах сложно было не уловить. Обрати внимание на категорию приложений указанных мной (хинт, чтобы избежать повторного недопонимания и грез о возбужденных от твоих слов собеседников — графика и видео как раз те области, которым многопоточность — то что доктор прописал). Просто ты похаял одно приложение за использование многопоточности, ибо твоей одноядерной "бутявке" сложно это переварить и тут же приводишь другое, использующее многопоточность во весь рост да еще и в 4-5 экземплярах одновременно. Так держать!
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[32]: Ну ты вообще многого не видишь... ;)
От: Mamut Швеция http://dmitriid.com
Дата: 04.06.09 11:04
Оценка: 3 (1) +1 :)
a> M>Угу, потом пытаешься скрестить QString с bt_str и материшься трехэтажным матом

a> Угу. Бывает конечно и такое. Если самому можно определять какую библиотеку использовать то вопросы межвидового взаимодействия как правило не стоят, или решаются административным порядком. Но дело в том что я довольно много занимаюсь вопросами интеграции и взаимодействия с сторонними аппликациями ( иногда весьма старыми и экзотическими) и здесь "окружающая среда" имеет решающее значение. Я далеко не всегда могу выбирать то что мне нравиться ( в том числе иногда и сам язык),часто приходиться мириться с тем что есть. . В этом плане С++ с его многообразием библиотек более универсален чем С#.



Да ничего он не универсален. Весь этот «внешний» мир и появился из-за такой вот «универсальности». В идеальном мире, где строка была бы встроена в язык С++, броблемы QString <-> bt_str просто не появилось бы. А так, создали кучу проблем, миллион несовместимых классов строк, активно с тим все боремся, но при этом гордо: «а посмотрите, какой С++ универсальный»
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[4]: За что я не люблю С++
От: WolfHound  
Дата: 29.05.09 20:14
Оценка: 2 (1) +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Операционные системы, драйверы, утилиты. (только ради бога не надо про Сингуларити)

Надо.

PD>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).

PD>ПО с серьезными расчетами.
Ничему из этого нативность не нужна.
Вообще не нужна.
Тут дело лишь в качестве оптимизатора и ни в чем больше.

PD>Это то,что первым в голову пришло. Подумать — можно еще добавить.

Подумай.
Но ничего кроме соооовсем мелких железок у которых соооовсем мало памяти не придумаешь.
Более того туда лучше форт засовывать, а не С++.
Хотя и туда ВМ можно затолкать. Кросскомпиляцией...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 11:09
Оценка: 2 (1) +2
Здравствуйте, 0xC0000005, Вы писали:

C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:


C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


C>Надеюсь в этот раз я вас не запутал и привёл нормальные доводы.

Проблемы с логикой. Из того, что интерфейс — не более чем контракт, никак не следует, что и контракт — не более чем интерфейс.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: За что я не люблю С++
От: Antikrot  
Дата: 26.05.09 18:11
Оценка: 1 (1) +1 :)
Здравствуйте, criosray, Вы писали:

C>>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.

вот тут осторожней ведь в ответ могут поставить условие чтобы твой код на C# c linq компилировался хотя бы тремя современными С# компиляторами хотя бы на трех архитектурно разных платформах

ГВ>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx


C>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк

а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?

насколько принципиально тащить в язык всё то, что можно вынести в библиотеку? (или C# настолько убог, что не позволяет все перечисленные тобой ранее фичи вынести в библиотеку? )

ну если о костылях, так C# — костыль к IL, который костыль к machine code, который костыль к cpu uops, который... ну короче продолжите сами
в C++ в настоящий момент в большинстве реализаций цепочка костылей на один (IL) меньше, так что добавив эмуляцию пропертей и всего остального не запиханного в непосредственно язык, мы только уровняем ситуацию
Re: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 29.05.09 09:42
Оценка: 1 (1) +2
Решил я вмешаться в эту дискуссию, но немного с другой стороны. Статью не читал и не буду — что там может быть, и так представляю, а почитав дискуссию, представляю вполне.

Я другой вопрос хочу задать. Ладно, не любите С++ — имеете право. Ладно, у C#/Java что-то такое есть, чего там нет — вполне возможно.

А вот что не ладно — какие альтернативы С++ можете предложить в ЕГО НИШЕ ? Вот представьте себе — исчез он. Чем замените ?

Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.

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

Фортран ?

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

И если при этих тяжелых наследственных заболеваниях он все же выжил, и не только выжил, но является становым хребтом ИТ — жить ему долго!

А есть в нем property или нет, и как там с сериализацией — господи, какие мелочи и пустяки!
With best regards
Pavel Dvorkin
Re[4]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 14:17
Оценка: -1 :))
Здравствуйте, Геннадий Васильев, Вы писали:

C>>В статье почти все правда. Просто преподнесена она так, чтоб сильно задеть программистов С++ и местами немного искажена.


ГВ>Угу, искажена вплоть до своей противоположности.


Нет.

C>>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.


ГВ>свойства — синтезируется;

Нет.
ГВ>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;
Нет.
ГВ>события — синтезируется;
Нет.
ГВ>делегаты — синтезируется;
Нет.
ГВ>лямбда-выражения — есть в C++0x;
Не есть, а будет. В данном топике речь вроде как не о C++0x вовсе.
ГВ>замыкания — есть в C++0x;
Не есть, а будет. В данном топике речь вроде как не о C++0x вовсе.
ГВ>duck typing — статический (и это очень хорошо);
Может Вы для начала узнаете для себя что такое утятина?
ГВ>интерфейсы — полностью выражается средствами pure virtual;
Костыль.
ГВ>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
Нигде их нет.

MX>>>13) "средств получить информацию о типе-параметре в языке просто нет" . Язык С++ на столько крут, что "в языке" это и не нужно — можно написать библиотеку. boost::is_abstract, is_arithmetic, is_array, is_base_and_derived, is_base_of, is_class, is_complex, is_compound, is_const...

C>>О, ужас.
ГВ>А что не так?
А Вы сами не видете?

MX>>>После слов "Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" этого профана сил осиливать его поток у меня не осталось.

C>>Он правду сказал, а Вы классически "съехали на оскорбления", не могучи аргументированно ответить.

ГВ>Глупость он сказал. Элементарных типов очень мало, указатели и ссылочные типы определяются на раз. И таких натяжек полна статья.

Нет.
Re[8]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 17:34
Оценка: :)))
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.


ГВ>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx


Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк
Re[23]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 13:46
Оценка: -1 :))
Здравствуйте, Sinclair, Вы писали:

NBN>>А если память нужна кому-то ещё?

S>Это то же самое. Когда память становится нужна кому-то еще, GC это замечает и начинает уборку.

Вот отсюда главные тормоза и растут.
Нужно разобрать угил.
Re[27]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 15:03
Оценка: +3
Здравствуйте, MxKazan, Вы писали:

COF>>Выяснили, что действительно синтезируется, не совсем так как в C#, но есть. Галочку можно поставить Особенно, если они не абсолютная необходимость. Но изначально-то вопрос стоял о том, что свойства — это базовое понятие, только потом был умело повернут на соответствие свойств в C++ и C#.

MK>И повернул его тот самый ответ, что синтезируются И галочку поставить у меня лично рука не поднимется. Ведь синтезируют. Значит нужно, но нету

Да, возможно. Это обычный полемический приём — в ответ на вопрос "где штука X?" ответить "а на хрена она вообще сдалась? ну если очень хочется — на, забирай". С пропертями то же самое. Я не стал добавлять, что они хоть и синтезируются, но это происходит обычно ради развлечения или спору для. Но ради развлечения на C++ и Lisp синтезируют в терминах шаблонов. Это ещё не повод говорить, что C++ остро нуждается во встроенном Lisp. Хотя... Это ещё как посмотреть.

Забавно в этом обсуждении получилось то, что защитники "свойств" даже не сформулировали толком, что из себя означенные свойства должны представлять (это, кстати, обычный прокол любых "провозвестников" — прямая претензия на сакральность). Например, можно ли оперировать таким явлением, как "ссылка на свойство"? Может ли "свойство" выступать аргументом шаблона? Ну и так далее. Получилось как всегда — C++ плох тем, что это не C#.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 00:55
Оценка: +3
Здравствуйте, COFF, Вы писали:

COF>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время.


C++ тут не при чём. Тут весь цимес в библиотечном классе shared_ptr.

COF>Как это сделать на C#?


Как сделать на C# что? Подсчёт ссылок а-ля shared_ptr? :) Он хрестоматийно реализуется в любом современном языке. В C# аналогом плюсового деструктора является метод Dispose() (а не финализатор, как думают некоторые), в нём надо декрементировать счётчик, а при его обнулении — освобождать неуправляемый ресурс. Если идиома RAII реализована последовательно, то 1) освобождение неуправляемых ресурсов будет строго детерменированным (а не по велению сборщика), 2) сборка самого экземпляра твоего ResourceWrapper'а будет дешёвой — просто освобождение памяти, в очерердь на финализацию он не попадёт (если логика по освобождению ресурса уже была выполнена, с последующим вызовом GC.SuppressFinalize()).
Глаза у меня добрые, но рубашка — смирительная!
Re[3]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 29.05.09 10:39
Оценка: +2 -1
Здравствуйте, MxKazan, Вы писали:

PD>>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.

MK>Конкретнее, что за ниша?

Операционные системы, драйверы, утилиты. (только ради бога не надо про Сингуларити)
Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).
ПО с серьезными расчетами.

Это то,что первым в голову пришло. Подумать — можно еще добавить.
With best regards
Pavel Dvorkin
Re[5]: За что я не люблю С++
От: COFF  
Дата: 29.05.09 11:39
Оценка: +2 :)
Здравствуйте, Qbit86, Вы писали:

Q>Я бы предпочёл, чтобы в разработке языка обошлась без «естественных причин» типа совместимости с Си на уровне исходных кодов.


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

COF>>Начни разрабатывать подобный язык с нуля, то в итоге либо C++ и получится


Q>Голословное заблуждение.


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

Q>О какой эволюции может идти речь по отношению к языку, стандарт которого законсервирован на десяток лет? (Предупреждая возможные вопросы — да, я читал «D&E» Страуструпа.) Только сейчас в нём начинают появляться языковые средства (которым, по сути, сто лет в обед), которые уже давно стали нормой для современных ЯП. И ещё не скоро эти нововведения войдут в обиход (учитывая консервативность адептов).


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

Q>Через двадцать лет он скорее всего благополучно преставится, и никто не станет по нему особо сокрушаться. Потому что на смену придут более удачные и удобные инструменты.


Про кобол тоже так думали
Re[7]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 29.05.09 12:17
Оценка: :)))
Здравствуйте, Qbit86, Вы писали:

Q>Как должно быть приятно себя чувствуешь, программируя на крестах, вроде как к вечности приобщаешься, да? Тёплый ламповый звук, всё такое?


Я, конечно, дико извиняюсь, но можно поподробнее про теплый ламповый звук ? . У меня лампы звук иногда издают, когда перегорают, но теплым и ласковым я бы этот звук не назвал.
With best regards
Pavel Dvorkin
Re[5]: За что я не люблю С++
От: hattab  
Дата: 29.05.09 17:16
Оценка: +2 -1
Здравствуйте, gandjustas, Вы писали:

PD>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).

G>Расскажи это создателям AutoCad.

Не, ну надоело уже... Что, правда, кроме WPF-морды Автокада упомянуть больше нечего? Вот незадача то... (ах да, ты еще Paint.NET с Photoshop'ом не сравнил )
Re[6]: За что я не люблю С++
От: WolfHound  
Дата: 29.05.09 21:34
Оценка: +1 -1 :)
Здравствуйте, Erop, Вы писали:

E>Может быть и не нужна, но широко используется...

Можешь назвать причины кроме исторических и личностных?

E>Так что спецы в перечисленных областях делают иной выбор, чем ты...

Апеллирование к личности. Железный аргумент.

WH>>Тут дело лишь в качестве оптимизатора и ни в чем больше.

E>Да не только. Дело вообще в контроле над компом...
И что ты контролировать собрался?

E>Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...

А где я сказал .NET?
Я к этой поделке отношусь весьма отрицательно.
В дизайне этой ВМ слишком много косяков. Но это тема для другого флейма.

Кстати, хватит тролить.
Я про "ХиндиС".
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 22:57
Оценка: :)))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.

MK>>Конкретнее, что за ниша?

PD>Операционные системы,

С
PD>драйверы,
С
PD>утилиты. (только ради бога не надо про Сингуларити)
Утилиты прекрасно на С# пишутся. У меня даже FAR обзавелся плагинами на дотнет.

PD>Десктопное ПО с существенными требованиями по быстродействию (

PD>граф. редакторы,
Paint.NET
PD>серьезные текстовые редакторы,
VS2010 — редактор полностью на WPF и позволяет такое, что неуправляемому GDI только мечтать.
PD>системы автоматизации проектироваия,системы распознавания образов разного рода).
AutoCAD.
PD>ПО с серьезными расчетами.
PD>Это то,что первым в голову пришло. Подумать — можно еще добавить.
Это все замечательно, но Вы выпускаете из виду одну простую истину — производительность важна только там, где ее не хватает. В недавнем обсуждении выяснилось, например, что числомолотилка на дотнет работает быстрее, чем числомолотилка на С++, если компилировать со стандартными настройками. Да, пересобрав ее с SSE3 и всеми возможными оптимизациями получили выигрышь примерно в три раза. Ну и замечательно — нашли узкое место, переписали на С или С++, собрали, подключили и пишем все остальное в значительно более удобной среде с модульными тестами, управляемой сборкой мусора, мощным и выразительным языком, и прочими плюшками.
Re[14]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 08:21
Оценка: :)))
Здравствуйте, Erop, Вы писали:

E>Ну тут-то про эффективность программ тёрки, а не про интерфейсы... Иди в форум по юзабилити и там три про удобство интерфейса... Я думаю, что там Paint.Net огребёт заслуженной критики...

Пока Вы будете так примитивно мыслить, оценивая только один единственный и далеко не самый важный для пользователя параметр, Ваш софт никто покупать не будет.

Что до юзабили — пэинт дот нет на голову выше Гимпа в этом плане. Я уже приводил цитаты и это взятые наугад ссылки из топа поиска в гугле по выражению gimp vs paint.net

E>>>После гонки мегапикселей даже средненькие мыльницы от 8 начинаются...

E>>>5 -- это ближе к камерофону...
C>>Мегапиксели это маркетинговая фишка — замануха для глупых покупателей. Хорошие бюджетные зеркалки как раз те самые 5-6 МП.

E>Это тут тоже офтоп, но, что-то как-то вызывает сомнение сочетание выделенного и 5 МП...

nikon d40
E>Кста, я согласен, что мегапиксели не так уж однозначно хороши, но хорошие фотики уже с маленькими мегапикселями не делают...
не путайте мыльницы с хорошими фотиками. Мегапиксели это что-то вроде процессорных мегагерцев — чисто маркетинговые попугайчики.
Re[2]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 11:31
Оценка: +1 -2
Здравствуйте, 0xC0000005, Вы писали:

(бред г-на с хацкерским ником вырезан цензурой)

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


Дотнет и джава прекрасно обходятся без недоразумения под названием "множественное наследование". boost и stl по структуре и удобству смотряться очень и очень бедно на фоне .NET Framework.

Множественное наследование такой же моветон, как и goto.

(остальной бред г-на с хацкерским ником вырезан цензурой)

C>А много ли явошарпы знают удобных, простых и "интуитивно" понятных способов расширить функционал языка? Вот у меня требование к либе, я хочу регить callbackи вот таким способом:

C>alarmNotifier = GUIHandler::onAlarm + CoreRoutine::onAlarm
C>и что? у вас есть "костыль"? или всё чего нету нам не надо? Ха, это мертвецки неправильно, и обычно такое отмирает как несовершенное.
То, что есть у Вас еще бОльший костыль.

obj.Alarm += OnAlarm;
obj.Alarm += (arg1, arg2) => { /* обработчик здесь */ };

Что до расширяемых .NET языков — смотрите Nemerle и Boo.

C>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>logger::log(__filename__, __line__, "log text")


catch(Exception e) {
   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
   throw;
}



И Вы осмеливались утверждать, что Вы что-то знаете об управляемых языках? Да уж по части логеров управляемые языки рвут неуправляемые (в т.к. С++), как тузик — грелку. Вам только мечтать об удобстве отладки и логирования, предоставляемых средствами управляемых сред.

C>Ага, а теперь скажите мне, у меня огромный обьект, но я хочу сериализовать только, замете слово ТОЛЬКО хидеры во всей иерархий, вот так я это использовал:

C>dataStream << Modifiers::HeadersOnly << hugeObject;

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

    [JsonObject(MemberSerialization.OptIn)]
    public class LoginResult
    {
        private ResultErrors errors = new ResultErrors();

        [JsonProperty("success")]
        public bool Success { get; set; }

        [JsonProperty("errors")]
        public ResultErrors Errors
        {
            get { return errors; } 
        }
    }



C>Слабо? или вы можете кичиться только готовыми фичами, но поверте мне, до 50% времени у больших команий использующих НЕуправляемые языки уходит на обход невозможности что-то сделать самому.

Исправил.

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

Вы сначала заставьте это компиллироваться под С++

C>public <T> void f()

C>{
C> T t = new T();
C> t.f();
C>}

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

Что это за чушь?

C>Знаете что было придумано дабы обойти всё это? был сделан препроцессор для Явы, да, препроцессор, вернулись к яблони таки.

Какой еще препроцессор? Опишите задачу, чтоли. Посмотрим в чем у Вас ошибка дизайна.

C>Вот скажите мне серьёзно, хоть один реальный пример в рамках одного приложения(про распределённые системы отдельный разговор), когда на этапе компиляции тип обьекта не известен, а если он известен, то зачем его узнавать? Потеряли — плохой дизайн и кучерявые руки!!! + обрезанность языка.

COM


C>

C>void func1 ( A& a );

C>void func2 ( A a );

C>В чем разница между этими описаниями (кроме того, что возможно программист просто пропустил символ '&') ?

C>а в чём разница между func1(a) и func1(a.clone()), в том что в первом варианте кодер забыл вызвать клон
C>А как передать строку в Яве, чтобы она была output parameter? Вот смеху то, надо создавать холдеры, и почему в яве

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

C>
C>void f(String s)
C>{
C>    s = "I'm dummy";
C>}
C>


C>переданный параметр не поменяется? и Вообще ни один параметр не поменяется? ах сколько говна было сьедено на этом миллионами программистами и тестерами. И вы говорите о том что управляемые языки там просты?

Миллионами индусокодеров?

Опять же, в С# есть out параметры.

А уж если кидаться какашками, то давайте вспомним в С/С++ классическую ошибку:
if (a = 1) { ... }

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

if (1 == a) { ... }

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


C>TO BE CONTINUED!!!

Не позорьтесь так больше.
Re[2]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 13:52
Оценка: +3
Здравствуйте, 0xC0000005, Вы писали:

C>У него было руководство по ООП — книга по паскалю. Занятно, как такой гений (как о нём тут шарписты шаркают) выбрал имено Паскаль 5.5, ведь в нём небыло обьектов, если помните Pascal with Objects был введён с версии 7.0 борландовсой ИДЕ [...]


Тут ты ошибаешься. Ошибка простительная, ты мог этого просто не знать по юности. На самом деле, классы появились в 5.5, а в 6.0 уже появился Turbo Vision, в 7.0 — редактор с подсветкой синтаксиса. Это так, не полемики ради, а энциклопедистики для.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 14:42
Оценка: -2 :)
Здравствуйте, Геннадий Васильев, Вы писали:

(троллинг и ламерствования ГВ вырезаны цензурой)

C>>>И какой-же геморой вас ждёт, когда интерфейс должен иметь один маленький метод.

C>>Что должен делать интерфейс?
C>>Сморозили очередную глупость. Интерфейс — это просто контракт.

ГВ>Интерфейс — это интерфейс. Контракт — гораздо более общая штука.

Демагогия.
Интерфейс в С# — это и есть контракт.
Re[11]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 14:57
Оценка: +2 -1
Здравствуйте, criosray, Вы писали:

ГВ>>Интерфейс — это интерфейс. Контракт — гораздо более общая штука.

C>Демагогия.
C>Интерфейс в С# — это и есть контракт.

"Контракт" подразумевает соглашения о побочных эффектах, которые интерфейсом прямо не выражаются ни на C++, ни на C#. "Интерфейс в С# — это и есть контракт." — не более, чем сужение семантики термина "контракт". Зачем тебе это надо — я не знаю.

Собственно, самой проблеме соблюдения контрактов глубоко начхать на то, что чем где считается. Можно хоть топать ногами, хоть приплясывать, хоть изойти в нуль в процессе обзывания окружающих — ничего не изменится.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 16:49
Оценка: -2 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>"что должен делать интерфейс" — интерфейс может верифицировать часть более общего контракта класса.


Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

Цитирую:

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


"Приемы объектно-ориентированного проектирования. Патерны проектирования" Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес

Если для Вас это облегчит понимание, то уточню, что книга эта была написана ДО дотнет и все примеры в книге приведены на С++.

Садитесь — еще одна двойка. Третья на сегодня.
Re[2]: За что я не люблю С++
От: WolfHound  
Дата: 01.06.09 18:33
Оценка: +1 -1 :)
Здравствуйте, 0xC0000005, Вы писали:

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

А я пройдусь по твоему проходу. Ибо я знаю оба мира очень хорошо. Ибо и на том и на другом пописал весьма не мало.

C>И вот такого там 90%, изречения ничем не обоснованные, замете, что автор говорит сугубо о своём опыте, о неудачном опыте, он не говорит о том что этими корявыми средствами он делал шедевры, а говорит что в его кучерявом дизайне и коде виноват имено С++, это называется трезумция виновности, когда отталкиваются от обвинения, а не от защиты.

Ну а я воял. И вполне успешно. Сейчас одно крутится 7х24 с фаиловером и прочими радостями на кластере и еще очень долго будет крутиться, другое на куче нефтяных заводов понатыкано,...
Правда всегда чувствовал что что-то тут не то.
Как-то все очень сложно.
А все почему?
А по тому что кривой язык заставляет делать кривой дизайн для того чтобы компенсировать кривизну языка.
Понял я это когда начал изучать другие и сильно другие языки.

C>А примеры? Как такой крутой перец и гуру не наваял нам с десяток красивых примеров.

Исходники буста почитай... Там вся "красота" С++ в полный рост.

C>И вот тут я хочу остановиться на книге "Exceptional C++" в двух томах, где описывается как молодой девелопер может сделать криво, а как после прочтения это можно сделать шедеврально.

Молодой "девелопер" может сделать только криво. Тем более на С++. Тем более после того как начитается.

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

Ты отказал куче языков в звании ОО ибо там классов нет.

C>Вот это да, 4 года работаю с жабой в "огромных" (компания лидер в индустрии, не буду называть) индустриальных масштабах, и всегда видел интерфейс как "заплатку" на дырень моно-наследования.

Как по мне наследование реализации нужно вообще отменить.
А вот так.
Не нужно оно.
Только лишнюю связанность на ровном месте создает.

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

Ну полиморфизм бывает разным.
Порой весьма разным.
В прочем жаба сама по себе один сплошной обрубок.

C>Тогда решили сделать множественное наследование, и разрешить наследовать от одного класса, и одного и более недо-класса, который не мог бы вызвать испражнения из кучерявых пальцев говнокодеров, те никаких имплементаций, которые могут вызвать двоиственность сущностей, только описание метода, или словами микрософта — Pure Virtual Function.

Интерфейс это чистый контракт.
Тем он собственно и хорош.
Ибо SRP никто не отменял. А нарушать такие вещи в дизайне языка это совсем не хорошо.

C>Во первых зачем? А во вторых эти сахарные названия Persistence, Hibernate, DataObject, Serializable... как это всё напоминает ныне покойный билдер с его ВСПЛ(только не надо о его реинкорнации в кодгеар), и замете билдер был и под плюсы, и всё там было, но оказалось ненужным в настоящем языке, а всё потому-что плохому танцору...

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

C>нужны контролы, компоненты, фичи, крутой язык, автоматика во всём, даже мозх автоматический, 500 крутых названий, зазубривши которые ты зовёшся гуру.

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

C>А много ли явошарпы знают удобных, простых и "интуитивно" понятных способов расширить функционал языка?

Ну так свет на явашарпах не сошелся.

C>Вот у меня требование к либе, я хочу регить callbackи вот таким способом:

C>alarmNotifier = GUIHandler::onAlarm + CoreRoutine::onAlarm
C>и что? у вас есть "костыль"? или всё чего нету нам не надо? Ха, это мертвецки неправильно, и обычно такое отмирает как несовершенное.
Ты попал пальце в небо.
alarmNotifier += GUIHandler.onAlarm;
alarmNotifier += CoreRoutine.onAlarm;


C>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>logger::log(__filename__, __line__, "log text")
Ну если вспомнить что языки не ограничены жабошарпами. Причем есть куда более умные языки на тех же платформах.
И тоже самое там можно написать куда проще.

C>Ой, а никак, и даже костыли такие не выпускают, фабрика ещё не открылась, ну ничё, когда дядя Билл захочет нам это надо будет

Когда там комитет научит С++ делать такое:
  macro @while (cond, body)
  syntax ("while", "(", cond, ")", body) 
  {
    def loop = Nemerle.Macros.Symbol (Util.tmpname ("while_"));

    <[ 
      ($("_N_break" : global) : {
        def $(loop : name) () : void {
          when ($cond) {
            ($("_N_continue" : global) : {
              $body
            }) : void;
            $(loop : name) ()
          }
        } 
        $(loop : name) (); 
      }) : void
    ]>
  }

Получается while не отличимый от встроеного в язык.
Вот это макросы.
А то что в С++ это полное угрЁбище.

C>Ага, а теперь скажите мне, у меня огромный обьект, но я хочу сериализовать только, замете слово ТОЛЬКО хидеры во всей иерархий, вот так я это использовал:

C>dataStream << Modifiers::HeadersOnly << hugeObject;
Кто такие хидеры?

C>Слабо?

Нет.

C>или вы можете кичиться только готовыми фичами, но поверте мне, до 50% времени у больших команий использующих управляемые языки уходит на обход невозможности что-то сделать самому. И давайте честно, с примерами — сделайте мне на Яве универсальный алгоритм, да, который берёт генерик класс и делает с ним что-то своё, что есть общее для генерика. И не говорите мне что этот обрубок шаблонного метода вообще можно считать генерик, напишите-ка

В C# так сделать можно.

C>Знаете что было придумано дабы обойти всё это? был сделан препроцессор для Явы, да, препроцессор, вернулись к яблони таки.

Ну ява это ява. Но не одной явой...

C>Вот скажите мне серьёзно, хоть один реальный пример в рамках одного приложения(про распределённые системы отдельный разговор), когда на этапе компиляции тип обьекта не известен, а если он известен, то зачем его узнавать? Потеряли — плохой дизайн и кучерявые руки!!! + обрезанность языка.

Да пожалуйста:
Простенький оптимизатор грамматики.
  partial internal class Optimizer
  {
    public static CanInline(name : string, grammar : Grammar) : bool
    {
      def canInline(rule, recRules)
      {
        match (rule : Rule)
        {
        | Call(name)               =>
          if (recRules.Contains(name))
            false;
          else
            canInline(grammar.GetRule(name), recRules.Add(name));
        | Choice(rules)            => rules.ForAll(rule => canInline(rule, recRules));
        | Sequence(rules)          => rules.ForAll(rule => canInline(rule, recRules));
        | Capture(_, rule)         => canInline(rule, recRules);
        | RepeatMin(_, rule)       => canInline(rule, recRules);
        | RepeatMinMax(_, _, rule) => canInline(rule, recRules);
        | Not(rule)                => canInline(rule, recRules);
        | And(rule)                => canInline(rule, recRules);
        | Chars                    => true;
        | ExtensionPoint           => true;
        }
      }
      canInline(grammar.GetRule(name), Set().Add(name));
    }

    public static OptimizeRule(rule : Rule, grammar : Grammar) : Rule
    {
      def optimize(_ : Rule)
      {
      | Choice(rules) =>
        def rules = rules.Map(optimize);
        def rules = rules.Map(fun(_)
        {
        | Rule.Choice(rules) => rules;
        | rule => [rule];
        });
        def rules = rules.Flatten();
        def catChars(_)
        {
        | Rule.Chars([chars1]) :: Rule.Chars([chars2]) :: rules =>
          catChars(Rule.Chars([chars1.Sum(chars2)]) :: rules);
        | rule :: rules =>
          rule :: catChars(rules);
        | [] => [];
        }
        def rules = catChars(rules);
        match (rules)
        {
        | [rule] => rule;
        | _      => Rule.Choice(rules);
        }

      | Sequence(rules) =>
        def rules = rules.Map(optimize);
        def rules = rules.Map(fun(_)
        {
        | Rule.Sequence(rules) => rules;
        | rule => [rule];
        });
        def rules = rules.Flatten();
        def catChars(_)
        {
        | Rule.Chars(chars1) :: Rule.Chars(chars2) :: rules =>
          catChars(Rule.Chars(chars1.Append(chars2)) :: rules);
        | rule :: rules =>
          rule :: catChars(rules);
        | [] => [];
        }
        def rules = catChars(rules);
        match (rules)
        {
        | [rule] => rule;
        | _      => Rule.Sequence(rules);
        }

      | RepeatMin(min, rule)         => Rule.RepeatMin(min, optimize(rule));
      | RepeatMinMax(min, max, rule) => Rule.RepeatMinMax(min, max, optimize(rule));

      | Not(Not(rule))         => optimize(Rule.And(rule));
      | And(Not(rule))         => optimize(Rule.Not(rule));
      | Not(And(rule))         => optimize(Rule.Not(rule));
      | And(And(rule))         => optimize(Rule.And(rule));
      | Not(rule)              => Rule.Not(optimize(rule));
      | And(rule)              => Rule.And(optimize(rule));

      | Capture(name, rule)    => Rule.Capture(name, optimize(rule));
      | Chars as rule          => rule;
      | ExtensionPoint as rule => rule;

      | Call(name)             =>
        if (CanInline(name, grammar))
          optimize(grammar.GetRule(name));
        else
          Rule.Call(name);
      }
      optimize(rule);
    }
  }

Я конечно понимаю что это далеко не жаба и даже C#'у до этого языка пилить и пилить но тем не мение.
Кстати обрати внимание ни одной переменной. Только константы.

Я уже молчу про компонентный подход.
Там и на С++ dynamic_cast дергать приходиться.

C>А про шаблонные классы и алгоритмы автор видимо не читал, где вызов подставляется на этапе компиляции.

Только без лямбды которая только в C++0x планируется толку от этого как от козла молока.

C>

C>В С++ это практически невозможно сделать. Именно поэтому сперва в Delphi и C++ Builder, а затем и в остром С появилось возможность делегирования как расширение языка.

C>Именно поэтому два первых на сегодняшний день скончались а третий живёт только за счёт огромных вложений
Первые два скончались совсем по другим причинам.
Дельфя по тому что это просто недоязык которым невозможно пользоваться.
А дебилдер глючил так что работать было не реально.

C>переданный параметр не поменяется? и Вообще ни один параметр не поменяется? ах сколько говна было сьедено на этом миллионами программистами и тестерами. И вы говорите о том что управляемые языки там просты?

Правильные языки просты.
Ява просто не правильный язык.
C# объективно лучше. Но тоже не фонтан.

C>А так же примеры где производительность увеличивалась в 1000 раз, и тоже благодаря аллокаторам из СТЛя,

В 1000 раз от смены аллокатора?
Не верю.

C>а сделайте ка мне аллокатор на шарпе дорогой

Зачем тебе дорогой аллокатор? Чтобы на его фоне сделать в 1000 раз быстрее?

C>(только не надо что менеджер памяти мега умный и всё знает, он ничего не знает кроме вашего говнокода)

Он уже очень умный.
Можно сделать еще умнее.
А если сделать ВМ без тех косяков что во все щели насовали авторы жабы и нета то можно сделать такой что руками не догнать.

C>

C>Т.е. на С++ МОЖНО писать очень эффективно. И НЕКОТОРЫЕ даже пишут. Вопрос только — относитесь ли Вы к их числу ?

C>Да, а вы?
Я относился.
Еще раз за С++ возьмусь только за очень большие деньги.
А может и не возьмусь, а напишу язык который компилируется в С или в LLVM.
Ну это если натив будет реально нужен.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 09:28
Оценка: -1 :))
Здравствуйте, 0xC0000005, Вы писали:


C>>>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:

C>>>Колесо — это чисто машина.
MK>>По такой логике criosray должен был написать, что интерфейс — это чисто класс. Вроде такого не было

C>Он написал что интерфейс это чисто контракт, а не класс, я продолжил логику показывая что связь Is Contained не является IS A


Что за бред? При чем тут агрегирование?? Вы вообще понимате ЧТО пишете? А то меня начинают грызть смутные сомнения по этому поводу.
Re[26]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 12:26
Оценка: -1 :))
Здравствуйте, CreatorCray, Вы писали:

C>>>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.

E>>>Ты не поймёшь.
C>>Ну если Вы поняли, то любой поймет.
CC>Ну ты ж вот никак не можешь понять
Что я не могу понять?

E>>>Но если ты всё-таки готов напрячься и понять, то почитай исходники CString из MFC, например...

C>>Посмотрю когда СString станет immutable.
CC>Мне что, написать для тебя immutable СString чтоб ты наконец понял как это делаетcя?
Я не сомневаюсь, что можно, но между можно и есть очень большая разница.
Re[25]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 14:47
Оценка: +2 -1
Здравствуйте, criosray, Вы писали:

C>Если Вы в курсе, тогда к чему было писать про некие "проблемы при работе с большим количеством текста"? Флейма ради?

Ничуть. StringBuilder практически ничего не предоставляет для нормальной работы. К примеру, в String классе есть много полезных методов для работы со строками, например Trim. Как мне его заюзать для StringBuilder без лишнего копирования? Я не говорю уже о том, что для того, чтобы хоть как-то работать со StringBuilder я должен оперировать сразу двумя классами — String и StringBuilder.
И>>Второе. Если хочешь, чтобы тебе отвечали не в стиле — "сам дурак", научись нормально разговаривать.
C>Иначе на тупые попытки троллинга я уже не реагирую. Если не рубить с плеча, то будет продолжаться поток глупостей.
Только троллишь тут в основном ты.
Re[28]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 03:47
Оценка: -2 :)
Здравствуйте, Erop, Вы писали:
E>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки.
от этого есть реальная польза. И во фреймворках, разработанных после С++, такое разделение уже существует пятнадцать лет.
E>В книжках бы были кучи примеров, как это реализовать и т. п.
E>Тем более, что никаких принципиальных трудностей на этом пути нет...
Принципиальные трудности есть. Ты можешь ставить мне сколько угодно минусов, но от этого факты не перестанут быть фактами: сделать мало-мальски полезные иммутабельные строки в плюсах не получится. Из-за того, что с самого начала были допущены архитектурные просчёты.

E>2) Хотелось бы понять, чем строка отличается от числа. Почему числа могут представлять сами себя и иметь модифицирующие себя же операторы, а строки -- нет? Что этому препятствует? Эффективность? Какая-то особенность семантики строк? Что-то ещё?

Иммутабельная строка как раз ничем не отличается от числа. Числа не имеют модифицирующих себя операторов. Попробуй изменить число 47586.

E>3)Должны ли, кроме строк, ещё и массивы букв иметь иммутабельную семантику? Если да, то почему это не так в большинстве языков, во всяком случае? Если нет, то в чём принципиальная разница между массивом букв и строкой?

Принципиальная разница — в контракте. Массив — это абстракция хранения. Про сценарии использования строки мы знаем гораздо больше, благодаря чему можем выбрать более вменяемую реализацию. То, что в С/С++ вшитые в язык строки представлены массивами — это незначительная подробность. В Хаскеле строки устроены совершенно по-другому, в результате операция конкатенации, к примеру, стоит O(1). В отличие от вашего "суперэффективного" C++.

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

Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 05:50
Оценка: -2 :)
Здравствуйте, Erop, Вы писали:
E>Зачем куда-то передавать сhar*, и как C# этого удаётся избежать?
В C# char* запрещён.
E>Если речь идёт об API, то там обычно входные строки именно const char*... Просто иногда С-шные хедеры декларируют функции без const, но это не является содержательной проблемой. Можно, например, написать к нужному API обёртки...
Речь идет о реальных библиотеках и реальном API. Эти гигабайты кода никто не будет оборачивать и переписывать.

E>1 -- это литерал. Литералы иммутабельны по своей семантике. Строковые литералы тоже иммутабельны. Скажем "мама".clear() ты тоже написать не можешь.

Правильно. А почему можно сделать std::string("мама").clear()?
E>А если число не литерал, а неконстантная переменная, то ты можешь написать так:
int i = 1;
E>i |= ( 1 << 4 );

Прекрасно. Вопрос: куда делась "1"? Ты не изменил число. Ты заменил его другим. У тебя есть заранее созданные четыре миллиарда целых чисел; то, чем ты пользуешься — это номера этих заранее созданных объектов.
операция 1 << 4 ничего не делает ни с четвёркой, ни с единицей. Она возвращает номер того числа, которое является результатом операции <<.
И в конце, когда ты производишь присваивание в i, ты просто заменяешь номер числа 1 на номер числа 17.
Давай посмотрим на такой же пример со строками:
var i = "hello";
i += " world";

Здесь фигурируют три строки. Сначала i указывала на строку "hello", потом была создана новая строка (путем конкатенации двух строк), и i стала указывать на эту новую строку. Сама строка "hello" (байты, на которые указывала i вначале) никак не поменялась. Это и есть семантика value-типа: значение измениться никак не может.

E>В STL std:vector требует семантику значения (это как у чисел) от своих элементов, и сам, в свою очередь, имеет такую семантику. Так, например, возможен вектор векторов.

Ты, по-видимому, не понимаешь, что такое "семантика значения".

E>Кста, в С++ нет проблем задавать строку в виде списка. Мало того, stl::basic_string не обязана хранить строку в массиве... Просто таких реализаций stl нет, я думаю потому, что они не нужны...

Это замечательный подход. Он гарантирует тебе, что ничего полезного ты никогда не изучишь. Ты только послушай себя: "раз в С++ нет, значит не надо". Ок, хорошо. Зачем тогда весь этот ритуальный танец вокруг нового стандарта? Ведь если лямбд не было в stl, то они гарантированно не нужны.

E>Да нет, я вообще не вижу разницы между списком и массивом. Если тебе список букв милее, пусть будет список. Любой контейнер для хранения ПОСЛЕДОВАТЕЛЬНОСТИ элементов годится. Мы же о семантике говорим вроде, а не о чём-то ещё? Какая тогда разница, как именно это реализовано?

E>Итак, нужно ли требовать иммутабельности от любой последовательности букв? Если да, то почему не требуют? Если нет, то чем строка так отличается от последовательности букв?
Не от любой. Есть последовательность букв, которая ведет себя как value — от неё можно и нужно требовать иммутабельности. Если я поместил Иванова на букву И в телефонной книге, пусть он будет любезен оставаться Ивановым.
Контракт такой строки вполне известен: от нее можно вычислить хеш, который гарантированно будет совпадать для одинаковых строк (и всегда будет соответствовать содержимому строки); строки можно конкатенировать; можно порождать подстроку.
Но главное в контракте этой строки — гарантия иммутабельности. То что результат произвольной F(s) будет оставаться ровно таким же, до тех пор, пока мы не переприсвоим в s что-то еще.

E>Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ...

Ок. Это примерно как я бы наезжал на C++ "не смогли эффективно реализовать работу с данными, не разделяя их на строки и числа". Мутабельная и иммутабельная строка — разные контракты.

E>Кста, по поводу того, что про сценарии со строками мы знаем намного больше чем про сценариями с последовательностями букв -- хотелось бы поконкретнее этот тезис чтобы был развёрнут! А то как-то не понятно что мы такое знаем про строки, чего про последовательности букв не знаем...

Мы знаем, что строкам не нужно изменение по месту. Что если я сконструировал объект WebRequest(string url), то он может и будет полагаться на неизменность переданного адреса вплоть до вызова GetResponse().

E>ПОЧЕМУ нужны иммутабельные и нет строки, но НЕ НУЖНЫ иммутабельные последовательности букв?

Что такое "иммутабельная последовательность букв"?

E>Как-то вы ребята исключительно неконкретны...

E>Если gandjustas хотя бы попробовал привести пару доводов от чего иммутабельную строку якобы нельзя создать на С++, то второй собеседник ограничивается исключительно декларациями и отсылками к весьма бессмысленным, IMHO, документам.
Ок. Эти документы окажутся осмысленными, когда у читателя вырастет нужный опыт — я думаю, что это связано не с количеством извилин, а исключительно с кругозором.

E>Например я могу назвать фреймворк, который был разработан после появления С++ и строки там мутабельные, так же как и числа: MFC, STL, ATL, QT... хватит?

Юноша, stl — это часть стандарта С++. До него вообще никаких строк в С++ не было. В MFC строки — вообще кошмар проектировщика. Я уже писал в этом форуме другим упёртым фанатам — например, на тему втискивания внутрь строки всех сервисных методов, которые должны быть снаружи. В QT тут, как вроде только что писали, строки иммутабельны. Врут?
Да, мутабельных чисел нет нигде. Учите матчасть — это value типы. И думайте головой.
Собственно, основной подвиг дотнета по отношению к строкам — то, что разработчики сделали так, чтобы строки вели себя как числа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 07:09
Оценка: +2 -1
Здравствуйте, Sinclair, Вы писали:

.

E>>IMHO, разделение на два класса происходит именно оттуда...

S>Разделение на два класса происходит из глубокого понимания окружающей действительности. Равно как и, к примеру, отделение кодировки от строки.
Только вот к сожалению, окружающая среда про это ничего не знает Иногда в программе бывает очень полезно удобно и самое главное — эффективно использовать разные типы строк (wstring, string, bstr — разные и т.п, в том числе и самописные строки) именноо из-за разнообразия окружающей среды.
Re[28]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 07:33
Оценка: +2 -1
Здравствуйте, alexey_ma, Вы писали:
_>Только вот к сожалению, окружающая среда про это ничего не знает Иногда в программе бывает очень полезно удобно и самое главное — эффективно использовать разные типы строк (wstring, string, bstr — разные и т.п, в том числе и самописные строки) именноо из-за разнообразия окружающей среды.
Все эти типы строк, которые кажутся вам разными, отличаются в незначительных аспектах представления. Поведение строк сводится всего к двум контрактам, для которых в дотнете и предусмотрены разные типы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: i++; ++i; ;) (-)
От: Erop Россия  
Дата: 04.06.09 10:40
Оценка: +1 -2
Здравствуйте, Serginio1, Вы писали:

S>Если ты хочешь найти в хэштаблице сначало по Хэшу, то и Хэш должен соответствовать значению,

S>если в сортированном списке ты меняешь строку, то должен изменить ее местоположение в списке.
Это-то понятно. Но в С++ нет никаких проблем не давать менять содержимое подобного контейнера...

S> Экономия при интернировании, т.к. не хронятся дубли. Если хэш лежит рядом, то и строка должна быть неизменяема, смоьри выше.

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

S>Ну в нативе мы если захотим можем изменить любой участок памяти

Ну пока комп внутри нативный это всегда будет можно...

Тут есть таки принципиальное, IMHO, отличие в подходах плюсов и шарпа. В одном случае предполагается вменяемость разработчика, поэтому ему предоставляется значительный контроль над тем, что и как делает его программа на самом деле. Ну да если при этом накосячил, то и сам дурак.
А в шарпе, насколько я понимаю, изначально ставилась задача возможности разработки не очень квалифицированными разработчиками, так скажем, что бы индусов не обижать
Собственно в этом состоит принципиальное отличие. А дальше уже частности идут...
Собственно говоря что тебе важнее: контроль или возможность нанимать кого попало...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[38]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 12:57
Оценка: +1 -1 :)
Здравствуйте, alexey_ma, Вы писали:

_>Сlarify сам написан на MFC использует стороний компонет ObjectivGrid (тоже MFC) многие методы которого возвращают СString. Чтобы поиметь какую-то информацию от этого грида я внедряю свою MFC дллку в Сlarifу, получаю указатель на грид и начинаю работать с его методами используя родной для этого грида СString. В данном случае никакой дотнетовский интероп не будет работать более эффективно( Проверяно на практике, коллеги пытались это сделать на C#).

Это правда. Дотнет не рассчитан на внедрение в адресное пространство чужого неуправляемого процесса.
Это не столько интероп, сколько хак. Опять же, вы путаете причину и следствие. То, что вам приходится компилировать DLL с той версие CString, которая у хоста — это не возможность, это необходимость. Вызванная ровно тем, что в С++ нет двух одинаковых классов строк. Если бы в стандарте с самого начала была приличная строка, вы бы и не знали о том, что могут потребоваться какие-то QString.
_>Я очень рад что шарп интероперирует с COM, только вот я в многих случаях могу работая из плюсов с СОМ могу избежать ненужного мне маршаллинга, в дотнете это у вас не получиться.
А, ну это уж конечно недостаток из недостатков.

_>Как я говорил так уж и прекрасно

_>

_>На собственном опыте вижу что ВНО написанный на плюсах работает бодрее, жрет меньше cpu, на порядок потребляет меньше памяти чем BHO написанный на шарпе с аналогичной функциональностью.

Вы невнимательно читаете. Для девелопера это очень плохо.
BHO — это та самая реализация inproc COM server, о которой я говорил абзацем выше.

_>Да

В таком случае давайте не будем обсуждать этот код.
_>Конечно, все в конце-концов сводится к вопросам примитивной технической реализации, но согласитесь что писать инжектируемую в
_>чюжой unmanaged процесс дллк на дотнете удовольствие сомнительное, а выгода не очевидна.
Я согласен. Но согласитесь, что разработка DLL для инжектирования в чужой процесс никак не назовешь мейнстримом. Так я могу сходу еще назвать тонну областей, куда управляемая среда подойдет плохо.

S>>Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.

_>Нет не покажу . Если интересно пробуйте сами. Дело даже не в том что код невоспроизводим на шарпе, дело в целесообразности этого воспроизведения. Зачем?
Ну, например чтобы показать наглядную разницу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 04.06.09 19:01
Оценка: +2 :)
Здравствуйте, WolfHound, Вы писали:

ГВ>>Вот-вот. Возвращаемся к тому, с чего начали: к внутренней структуре строки.

WH>И как грамотная реализация строки относится к тому что строк должно быть много?
Нуу... Для редактора текстов представление строк (буфферов) будет отличаться от обычных коротких строк.
Sapienti sat!
Re[11]: За что я не люблю С++
От: jazzer Россия Skype: enerjazzer
Дата: 05.06.09 08:12
Оценка: +2 :)
Здравствуйте, criosray, Вы писали:

C>http://hestia.typepad.com/flatlander/2008/12/c-covariance-and-contravariance-by-example.html


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

Шаблонов у вас нету в шарпе нормальных, вот и приходится извращаться.
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[48]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 09:36
Оценка: -1 :))
Здравствуйте, gandjustas, Вы писали:

C>>>Небольшой тест производительности std::wstring в сравнении со StringBuilder.

Х>>чем больше я вижу твоего С++ кода, тем больше понимаю почему тебе было мучительно больно на нём писать и ты перелез на C#
G>Чего словами кидаться. Давай соптимизируй плюсовый код criosray, чтобы он был быстрее, так чтобы там stl остался.

Лучше чуточку к реальности приблизить. Скопируем полученные строки в массив:

Это — C#/.Net 2.0 (под рукой другого нет)
const int Count = 25000;

StringBuilder stringBuilder = new StringBuilder();
String[] s = new String[Count];

Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();

for (int i = 0; i < Count; i++)
{
  stringBuilder.Append("c1");
  s[i] = stringBuilder.ToString();
}

stopwatch.Stop();

Console.WriteLine("append: elapsed {0}", stopwatch.Elapsed);
Console.WriteLine(stringBuilder.Length);


А это — С++:
static const size_t count = 25000;

std::vector<std::wstring> wv;
std::wstring ws;

DWORD dwStart = ::GetTickCount();

for(int i = 0; i < count; ++i)
{
  ws.append(L"c1");
  wv.push_back(ws);
}

DWORD dwEnd = ::GetTickCount();

std::cout << (dwEnd - dwStart) << " ms" << std::endl;


Соотношение в пользу C++ примерно 1 : 1.8.

Разрыв превращается в примерно шестикратный в пользу C++ (на 100 тысячах итераций), если тела циклов выглядят примерно так:

String s;
// ...
for (int i = 0; i < Count; i++)
{
  stringBuilder.Append("c1");
  s = stringBuilder.ToString();
}


std::wstring ws1;
for(int i = 0; i < count; ++i)
{
  ws.append(L"c1");
  ws1 = ws;
}


То есть не массив заполняем строками, а копируем результат каждой итерации в одну и ту же переменную.

Да, если количество итераций увеличить до 200 тысяч, C++ отрывается ещё дальше. Но это .Net 2.0, может быть, в .Net 3.5 всё не так плохо. Для C++ включена оптимизация по скорости, инлайнирование всего, что под руку подвернётся (/Ob2) и глобальная оптимизация.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[52]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 10:03
Оценка: :)))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А теперь перечитай внимательно мою с WolfHound дискуссию. WolfHound утверждал, что достаточно положить в узлы длины собственных подстрок.


Это они и есть. Смысл дискуссии был в том нужно ли обходить все узлы для доступа по индексу — правильный ответ — нет.

Я объясняю как работают бинарные деревья поиска пользователю из ТОП100 rsdn. Сюрреализм происходящего поражает мое воображение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[49]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 11:16
Оценка: -1 :))
Здравствуйте, Геннадий Васильев, Вы писали:

C>>>>Небольшой тест производительности std::wstring в сравнении со StringBuilder.

Х>>>чем больше я вижу твоего С++ кода, тем больше понимаю почему тебе было мучительно больно на нём писать и ты перелез на C#
G>>Чего словами кидаться. Давай соптимизируй плюсовый код criosray, чтобы он был быстрее, так чтобы там stl остался.

ГВ>Лучше чуточку к реальности приблизить. Скопируем полученные строки в массив:


ГВ>Это — C#/.Net 2.0 (под рукой другого нет)

ГВ>
ГВ>String[] s = new String[Count];
ГВ>


ГВ>А это — С++:

ГВ>
ГВ>std::vector<std::wstring> wv;
ГВ>


С каких пор вектор стал массивом?

ГВ>Соотношение в пользу C++ примерно 1 : 1.8.


А теперь приведем к общему знаменателю:


            const int count = 5000;

            var stringBuilder = new StringBuilder();
            var s = new List<string>(count);

            var stopwatch = new Stopwatch();
            stopwatch.Start();

            for (int i = 0; i < count; i++)
            {
                stringBuilder.Append("Карл у Клары украл кораллы в количестве ");
                stringBuilder.Append(i);
                stringBuilder.AppendLine(" штук");
                
                s.Add(stringBuilder.ToString(0, stringBuilder.Length));
            }

            stopwatch.Stop();

            Console.WriteLine("append: elapsed {0}", stopwatch.Elapsed);



inline std::wstring StringToWString(const std::string& s)
{
    std::wstring temp(s.length(),L' ');
    std::copy(s.begin(), s.end(), temp.begin());
    return temp;
}

int _tmain(int argc, _TCHAR* argv[])
{
    static const size_t count = 5000;

    std::vector<std::wstring> wv;
    std::wstring ws;
    std::string temp;
    char buffer[20];
    DWORD dwStart = ::GetTickCount();


    for(int i = 0; i < count; ++i)
    {
      ws.append(L"Карл у Клары украл кораллы в количестве ");
      _itoa_s(i,buffer,10);
      temp = buffer;
      ws.append(StringToWString(temp));
      ws.append(L" штук\n");
      wv.push_back(ws);
    }

    DWORD dwEnd = ::GetTickCount();

    std::cout << (dwEnd - dwStart) << " ms" << std::endl;
}


C++ 858 ms
C# 823 ms

Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.

Но самое замечательное, что С++ вариант банально крашился, если Count = 10000 (и возможно меньше... не проверял между 5к и 10к).

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.



Что до дотнет 3.5 и дотнет 2.0 — сколько раз говорить, что рантайм у них ИДЕНТИЧНЫЙ. Не может быть никакой разницы в производительности.
Re[42]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 12:43
Оценка: -1 :))
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.


PD>Пойми наконец, что никакой проверки не будет вообще.


Проверки не будет — запрета не будет. "Так в чем сила, брат?"
Re[54]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 08.06.09 13:55
Оценка: +3
Здравствуйте, criosray, Вы писали:

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


C>>>Кстати, С++ вариант по прежнему падает, если count >= 10000

C>>>Прекрасный пример — тут Вы правы.
CC>>Ну, этож твой код падает
C>Ну напишите такой, чтоб не падал.
Ай повеселил!

C>Или здесь все такие умные, что им это не по силам?

Ты еще "на слабо" предложи.

Ты посчитай сколько памяти займут эти строки?

На 10к строк С# падает с out of memory
В С++ у тебя вылетает bad_alloc на ~1.4 Гб занятой памяти.
Почему не может выделить еще? Возьми VMMap и посмотри что творится в памяти процесса.
По сути у тебя синтетический тест на хаотическую аллокацию.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[66]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 10.06.09 11:31
Оценка: +2 -1
Здравствуйте, Sinclair, Вы писали:

S>В общем, это мне уже как-то становится скучно. Есть медицинский факт: строки в С++ спроектированы отвратительно.

S>Я достаточно хорошо понимаю все исторические причины, которые привели к этому архитектурному убожеству.
Какие строки? "const char *"?

С++ как обычно даёт кучу возможностей сделать что-то красивое (как и выстрелить себе в ногу). Например, я писал свой пакет строк на основе Александресковских. С фичами, которых нет в С# (и не будет). Например, возможностью превратить immutable-строку в mutable при необходимости с почти нулевыми затратами.

Или с возможностью подсунуть хранилище с gap buffer'ом. Сейчас вот пытаюсь этот код найти....
Sapienti sat!
Re[70]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 10.06.09 15:07
Оценка: :)))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>строка — это строка, дерево — это дерево, узлы — это узлы.


Таким глубоким, бесконечно глубоким, я бы сказал, возражениям я не могу ничего противопоставить. Такую рекурсию мой ограниченный умишко не вместит. Еще Энштейн говорил, что знает только две бесконечные вещи: вселенную и определение строки через строку. Да и то, насчет вселенной он был не совсем уверен.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[67]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.06.09 04:09
Оценка: +2 -1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не "строки в C++", а "строки MS STL".

При чём тут MS?
ГВ>Даже не смотря на то, что эти строки описаны в стандарте, нет никаких оснований переносить недостатки, свойственные тем или иным реализциям std::basic_string на весь C++.
Дети, STL и ASCIIZ — это единственные строки, стандартизованные в С++. И проблема у них — вовсе не в реализации. А в архитектуре, т.е. в том контракте, которым авторы наделили std::string. Сколько можно объяснять одно и то же? Вам показывают на пальцах: иммутабельные строки — эффективнее. Отдельный от них стрингбилдер — эффективнее. А вы опять за своё: "ой, так нечестно, ваши классы спроектированы под свои задачи". Конечно std::wstring неизбежно будет плодом компромиссов — потому что перед ней поставили противоречивые задачи.

ГВ>Не смеши меня, ладно? Никто из C++-ников не говорил (AFAIR), что std::wstring есть лучшее решение на все случаи жизни. Это только строка, предусмотренная стандартной библиотекой. Но "стандартная" не означает "обязательная к применению", поэтому нельзя апеллировать к этой реализации, как к обязательно используемой везде в C++ ("строка в C++" — фраза содержит именно такое неявное обобщение). Сама по себе подобная апелляция уже ошибочна. Не нравятся те или иные строки? Сделай другие.

Копец. Я уже семь раз написал на эту тему: самописанные строки не будут ни с кем интероперировать. Если бы с самого начала был спроектирован нормальный фреймворк, с раздельными контрактами на mutable и immutable строку — вот тогда да, могли бы существовать различные реализации, которые бы интероперировали на основе этих контрактов. Но в жизни ничего похожего нет — покажите мне хоть одну вменяемую реализацию строк, и хоть один непустой проект на её основе.

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

Не вижу, чтобы что-то было известно "любому С++-нику". Пока что любые C++ ники сопротивляются любым попыткам объяснить им, что std::string — УГ. Независимо от реализации.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[43]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 04:29
Оценка: -2 :)
Здравствуйте, criosray, Вы писали:

C>Проверки не будет — запрета не будет. "Так в чем сила, брат?"


Сила, как всегда, в знании, которого в этом плане у тебя нет. Проверки не будет , а будет Access Violation при попытке модификации.
With best regards
Pavel Dvorkin
Re[48]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 15.06.09 10:34
Оценка: +1 -1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я уже устал повторять — не собираюсь я применять их к управляемой среде. Не собираюсь, понятно ? Я не принимаю эту управляемую среду именно за то, что к ней нельзя эти образы (коль уж такой термин тебе нравится, пусть так) применить. Именно поэтому она мне и не нравится.

Этим ты выдал всю свою сущность.
Ты не хочешь учится.
А это значит что как профессионал ты уже мертв.

PD>Пошел делать другую задачу.

PD>А теперь продолжение.
А чаще всего нету этого продолжения...

S>>Ну, тогда мир СУБД от тебя далёк. Очень жаль — там есть крайне интересные вещи про оптимизацию производительности. Шибко помогает отвлечься от трактовки программирования как == алгоритмы + структуры данных.

PD>"Нелья объять необъятное" (К. Прутков). В мире программирования есть много чего интересного...
Можно и нужно.
Я имею в виду не детали как работает оракл версии ХХХ, а общие принципы.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[52]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 19.06.09 07:16
Оценка: +1 :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Я учитЬся хочу, но только тому, что мне для работы годится. Например, CUDA — годится, поэтому я недавно ее и осваивал. .Net, VB, Python и прочие Хаскели — не годится, а поэтому мне на них время тратить незачем.

WH>>Ты очень сильно ошибаешься.

PD>Голословные утверждения особой ценности не представляют. У меня основное требование — скорость, второе — объем памяти. И всякие лишние действия мне ни к чему. Поэтому я вряд ли сильно ошибаюсь, тем более, что я и сам тестировал (.Net) и читал, что тут писали (другие системы).

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

PD>Вот именно. Интересное кино, между прочим. Вы тут одним из основных принципов выставили хорошую сопровождаемость. Не буду спорить. Иными словами, вы утверждаете, что хороший продукт должен быть легко модифицируем, адаптируем к новым условиям и т.д. Однако при этом как-то стыдливо подразумевается, что мол, если нужно добавить новую страницу на сайте или же даже внести изменения в его структуру — это мол, важно, а вот сделать так, чтобы он работал быстрее в 5 раз — это не так уж важно, мы же уложились в требования...

PD>А ведь вы правы. Реально ваши задачи таковы, что от вас ускорить быстродействие в 5 раз не потребуют. Ну выросла компания в 2 раза, ну увеличилась нагрузка в 2 раза, ну замедлился ответ в 2 раза (а может, и не замедлился, было 5 посетителей в день, стало 10 , ну и ладно. А когда компания сильно разрастется, то выкинут они этот сатй на помойку и сделают новый.
Не пиши чушь. Тебе привели пример, что сервисы разгоняли в сотню раз за короткое время.

PD>Но не у всех такие задачи. Вот поэтому ты и неправ в общем случае.

Это ты неправ в общем случае, ибо если программа не выполняет требования, то она нафиг не нужна независимо от скорости её работы.
Есть конечно торгаши, которые умеют впаривать неработающие программы, но таким программистам как ты это чести не делает.
Re[7]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 26.10.09 12:38
Оценка: +2 :)
Здравствуйте, VladD2, Вы писали:

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


PD>>Ты волен считать, что сдуру или как-то еще. Это, кроме как для тебя, не так уж и важно.


VD>Гы. Это все что ты говоришь не важно.


Для тебя не важно, да

PD>>Но язык, на котором столько написано, маргинальным быть не может по определению.


VD>Еще как может. Скажем, сейчас художников-абстракционистов чуть ли не больше чем нормальных. Что же мне теперь не считать их маргиналами?

VD>Еще раз повторюсь, маргинал — это человек стоящий на стыке культур. С++ совершеенно маргинальный язык. Он скрещивает ужа с колючей проволокой.

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

PD>>>> Маргинальные в моем определении не значит плохие, а просто пока не употребляемые в реальном мире.


VD>Для этого есть более подходящий термин — непопулярные.


Не совсем точно, но сойдет. Мне, в общем, все равно.

PD>>Ты прекрасно понял, что я имею в виду, а поэтому не стоит заниматься играми в дефиниции.


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


Именно.

VD>>>Ну, так загляни в угол экрана. На дворе идет конец первого десятилетия нового тысячалетия.

VD>>>Здоровые люди плюсы используют все реже и реже. Его популярность неуклонно падает.

PD>>Не похоже.


VD>Гы-гы.


Исключительно убедительный аргумент.

PD>>Скорее так — появились новый области, где С++ никогда и не использовался всерьез. Например, в Интернете — не считать же серьезным использованием CGI или ISAPI.


VD>Ага. Не стоит считать серьезным использование С++ там где всегда использовался только С.


Ну вот что, стравливать С и С++ я не буду. Для меня это одно направление языка — С/C++. Где лучше С, а где и С++

PD>> А больше ничего и не было. И в этой области его как не было, так и нет. А где он есть — я уже писал.


VD>То что ты глаза от пола не хочешь оторвать еще не значит, что ничего вокруг не происходит.

VD>Корпоративное ПО давно ушло от С++ и даже Дельфи. Сейчас там царствуют ява и дотнет.

А раньше царствовали Delphi и Visual Basic. Ну и что ? Какое мне дело до них ?

VD>Серверный софт разрабатываемый с нуля тоже пишется в основном на управляемом коде. Погляди хотя бы на бизтолк.


Пишется, да, кое-что. Вот когда IIS напишут — тогда можно будет обсудить.

VD>Рынок массового софта более консервативен. Но и он потихонечку прогибается. Скоро, если захочешь использовать VC++, то тебе придется писать С++-код в среде на 90 написанной на управляемых языках.


И что ? То, что MS в угоду C# испортила свою среду — это верно. В VC 6.0 проект открывался мгновенно, а теперь порой 10-20 сек открывается. А уж диалог показать, или, не дай бог, ToolBox впервые открыть — это вообще дикие тормоза.

VD>Верефицирующие компиляторы для С тоже пишут на управляемых языках. Так что скоро С-шные драйверы будут проверены F#-ом и Немерле.


Пусть пишут. Это имеет такое же отношение к реальности , как мартышкин труд к бизнес-процессу.

PD>>Ну кто кого тут рвет — из твоей фразы понять невозможно. То ли С рвет С++, то ли кто-то еще рвет кого-то еще...


VD>Опять не хочешь слышать то что тебе говорят.


Не то, что "не хочу слышать" , а не могу понять


PD>>Ну-ну...


VD>Что "Ну-ну"? Ты VC используешь? Ну, так или завязывай, или приготовься, что IDE для него на шарпе будет написана.


Она давно уже на чем-то таком и написана. Эффект — см. выше.

VD>>>Так что их удел — низкоуровневые оптимизации


PD>>Именно. И там им конкурента нет.


VD>Ну, как же? С отличный конкурент в этой области.


Насчет противопоставления С и С++ — уже писал.

VD>Ди тоже вряд ли уступит.


Может, и не уступит, только его же нет

>>>дрова для стремительно устаревающих ОС


PD>>Wiindows и Linux , без которых твой любимый .Net существовать не может.


VD>Он не то что любимый. Он шаг в почти правильном направлении.

VD>Что дло Виней и Линей, то их сроки сочтены. Еще 10-15 лет и на помойку.

Обсудим через 10-15 лет.

>>>софт для бюджетных самрфонов и места где основной объем кода — это вызов C API.


PD>>То есть все то, что использует средства ОС. Правильно.


VD>Во как? Я грешным делом думал, что окромя чисто функциональных программ (т.е. сферофкоеней вакуумных) остальные все как одна используют сервисы ОС.

VD>А оказывается — это прерогатива С++.

Шут тебя поймет. То "места где основной объем кода — это вызов C" (видимо, ты даже не знаешь, что WIN API в значительной части на С++), то все используют ОС. За твоим полетом мысли мне как-то трудно угнаться

>>>И во всех этих местах С за глаза хватило бы


PD>>Особенно с твоей идеей насчет инкапсуляции. Чудный код получится.


VD>А идея не моя. Твои любимые ОС с ее помощь написаны. Кстати, на том самом С в основном.


Кстати, Windows все же на С++ написана.

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


Си счастлив

>>>А с точки зрения удобства несомненно лучше применять Ди и ОКамл.


PD>>Может и да, да ведь не используют же.


VD>Дык посмотри в зеркало и скажи себе и своей лени спасибо.


Да я тут при чем ? Его неиспользуют. Не я. Другие. А я просто предпочитаю немаргинальные направления. За них деньги платят. А за маргинальные — нет.

PD>>Вполне возможно. Ничего тут особенного нет, и плохого ничего нет. Придет время — настанет и пора, как один мой друг говорит. Поживем — увидим.


VD>Пора уже настала. Просто многие до смерти ждут лучших времен.


Пока они не настали — все это болтовня. Вот когда у С++ будет судьба Фортрана — тогда и поговорим. Если я доживу.

PD>>Ну может и "я работал в Windows" будет звучать так же. Не стоит пытаться предсказывать будущее, неблагодарное это дело.


VD>Ничего. У меня это уже раз 5 получалось. С Нетварью и ВиньНТ было очень забавно. Меня так высмеивали, так высмеивали. А теперь нет ни Нетвари, ни тех кто смеялся. Все куда-то испарились.


Насчет нетвари угадать было несложно. Насчет NT — не понял. Чего нет, Windows NT ?

PD>>Да кто тебя заманивает ? Я — не буду ни за что. Судя по твоим постингам по С++, твое отсутствие в этом языке только желательно — меньше дилетантского кода будет.


VD>Хамите, парниша. (с) Таким как ты про дилетантство помалкивать лучше.


Лишь констатирую факт. Посмотри свои постинги по С++ — они чаще всего и не минусы, а смайлики вызывали.

PD>>Не покупай Жигули и не программируй на С++. Лучше будет С++ и даже ВАЗу лучше будет.


VD>Ну, не знаю чем этим гробам на колесиках будет от того лучше, но я так и поступаю. При этом получаю огромное удовольствие.


Бога ради. Ей — богу, С++ от этого никак хуже не будет.

PD>>А как ты думаешь, зачем я это пишу ? Тебя переубедить ?


VD>Да, кто же тебя знает? Ты иной раз такие вещи говоришь, что хот стой хоть падай.


А это для тебя специально — чтобы читал мои постинги исключительно лежа.

Ладно. И лишь последнее — всерьез. Все же ответь на один вопрос — ты хоть иногда допускаешь, что ты в чем-то можешь быть неправ ? Мне просто интересно знать. Психологически любопытно.
With best regards
Pavel Dvorkin
Re[19]: За что я не люблю С++
От: Хвост  
Дата: 10.11.09 11:02
Оценка: +2 :)
Здравствуйте, metaprogrammer, Вы писали:

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

M> На C++ легко поддерживаемых проектов нет.

ну точно тролль.
People write code, programming languages don't.
Re[20]: За что я не люблю С++
От: metaprogrammer  
Дата: 10.11.09 22:00
Оценка: -2 :)
Здравствуйте, CreatorCray, Вы писали:

M>> Не верю. С C++ проблемы всегда. Он не может не создавать проблем, просто в силу низкоуровневости.

CC>Ясно.

Тебе? Тебе ничего не ясно.

CC>Если у тебя заведомо предвзятое отношение то о чем с тобой вообще можно вести разговор?


У меня достаточно объективное отношение.

M>> Хреновейше поддерживается. Достаточно посмотреть на любой крупный опенсорс-проект.

CC>например на те, что написаны не на С++, ага.

Хотя бы. Бардака меньше там, где меньше C++.

M>> На C++ легко поддерживаемых проектов нет.

CC>-100

Назови. Хоть один.

M>> Недавно имел сомнительное удовольствие переводить код со старого синтаксиса managed C++ на новый — автоматом меньше половины получилось исправить, остальное только вручную.

CC>Это ты претензии к МС предъявляй. МС++ это их творение.

Претензии к C++ вообще. К его уродской грамматике. Что, спорить будешь, что она уродская?!? Чтоб с этим спорить, надо быть уж совсем неадекватным.

M>>Давно бы все выбросили C++ на помойку, где ему самое место, да легаси не позволяет.

CC>Отучаемся говорить за всех.

Ну, про неадекватов, которые C++ любят, говорить не будем, ладно.
Re[66]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 15:57
Оценка: 6 (2)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ни в коем случае я этого так не понимаю. Собственная — это собственная. "Слева" — это "слева". Хорош уже передёргивать — если под белым понимать синее, а под синим оранжевое, то и радуги нет.


Ну в каком она еще смысле может быть собственной, при том, что собственные строки есть у всех узлов?

... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[38]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 30.05.09 13:30
Оценка: 3 (1) :)
Здравствуйте, Erop, Вы писали:

E>Да какая разница? Все хороши :)


Ящитаю, в этой ветке мало Хаскеля. Реквестирую в каменты хаскельщика, чтобы разнообразить наш уютный междусобойчик.
Глаза у меня добрые, но рубашка — смирительная!
Re[23]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 02.06.09 12:00
Оценка: 3 (2)
Здравствуйте, criosray, Вы писали:

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



C>Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?

Я полагаю что вы хотели получить пример этого :

CC>>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
C>>>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.

В QT это есть( и не только для строк кстати).

Many C++ classes in Qt use implicit data sharing to maximize resource usage and minimize copying. Implicitly shared classes are both safe and efficient when passed as arguments, because only a pointer to the data is passed around, and the data is copied only if and when a function writes to it, i.e., copy-on-write.

здесь
Re[68]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 11.06.09 13:24
Оценка: 3 (1) +1
Здравствуйте, Sinclair, Вы писали:

ГВ>>Не "строки в C++", а "строки MS STL".

S>При чём тут MS?

Да, это я не удачно высказался, потом перечитал — "MS STL" выглядело как попытка акцентировать внимание на MS. Нет, я имел в виду тут целую иерархию: STL — это одна из библиотек, MS STL — одна из реализаций STL.

ГВ>>Даже не смотря на то, что эти строки описаны в стандарте, нет никаких оснований переносить недостатки, свойственные тем или иным реализциям std::basic_string на весь C++.

S>Дети, STL и ASCIIZ — это единственные строки, стандартизованные в С++.

Ну да, и что? Ты думаешь, кого-то это смущает? Повторюсь: если мне не понравятся строки, то хай ANSI вместе XJ21 подавятся своим стандартом — я сделаю новые хранилища/манипуляторы строк и вся идеология C++ тут мне помощником. Единственное место, где неизбежно придётся учитывать наличие ASCIIZ — строковые литералы, так их вообще, чем меньше — тем лучше. А сторонние API — это всегда сторонние API со своими приколами (CRT — тоже один из API).

S>И проблема у них — вовсе не в реализации. А в архитектуре, т.е. в том контракте, которым авторы наделили std::string. Сколько можно объяснять одно и то же? Вам показывают на пальцах: иммутабельные строки — эффективнее. Отдельный от них стрингбилдер — эффективнее. А вы опять за своё: "ой, так нечестно, ваши классы спроектированы под свои задачи". Конечно std::wstring неизбежно будет плодом компромиссов — потому что перед ней поставили противоречивые задачи.


Хорошо, пусть проблема будет в контракте. Но и это не повод переносить недостатки контракта basic_string на весь C++. Если хочешь, давай отдельно поругаем контракт basic_string, я не против. Мне он тоже не во всём нравится.

ГВ>>Не смеши меня, ладно? Никто из C++-ников не говорил (AFAIR), что std::wstring есть лучшее решение на все случаи жизни. Это только строка, предусмотренная стандартной библиотекой. Но "стандартная" не означает "обязательная к применению", поэтому нельзя апеллировать к этой реализации, как к обязательно используемой везде в C++ ("строка в C++" — фраза содержит именно такое неявное обобщение). Сама по себе подобная апелляция уже ошибочна. Не нравятся те или иные строки? Сделай другие.

S>Копец. Я уже семь раз написал на эту тему: самописанные строки не будут ни с кем интероперировать.

Кто тебе сказал такую глупость? Они будут интероперировать через промежуточные абстракции. Никто не мешает выполнять преобразование из rope к ASCIIZ в последний момент перед вызовом функции, требующей именно ASCIIZ. В чём прикол твоего утверждения о невозможности интероперабельности?

S>Если бы с самого начала был спроектирован нормальный фреймворк, с раздельными контрактами на mutable и immutable строку — вот тогда да, могли бы существовать различные реализации, которые бы интероперировали на основе этих контрактов. Но в жизни ничего похожего нет — покажите мне хоть одну вменяемую реализацию строк, и хоть один непустой проект на её основе.


Надо посмотреть, обещать ничего не могу, но, вроде бы, какая-то из реализаций STL выполняла преобразование к ASCIIZ по запросу c_str(). А формат хранения был как раз каким-то сложным — не обычный линейный буфер. Ну и потом, проект на основе реализации строки — это сильное колдунство... Шутка.

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

S>Не вижу, чтобы что-то было известно "любому С++-нику". Пока что любые C++ ники сопротивляются любым попыткам объяснить им, что std::string — УГ. Независимо от реализации.

Тройной одеколон вам в перегонку... С++-ники сопротивляются переносу оценки "УГ" по маршруту: std::basic_string -> C++ -> C++-ники. Не трещите так много про унылость "самих C++-ников" и C++ — и прекрасно услышите, как сами C++-ники ругают и ASCIIZ, и std::basic_string. Понимаешь? Вот не надо неправомерных обобщений и всё будет намного проще.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: За что я не люблю С++
От: -MyXa- Россия  
Дата: 26.05.09 15:33
Оценка: 2 (1) +1
Здравствуйте, criosray, Вы писали:

C>В статье почти все правда. Просто преподнесена она так, чтоб сильно задеть программистов С++ и местами немного искажена.


Почти всё? Примеры?

C>Отлично. Напишите универсальный сериализатор в XML/Json.


Жду списка недостатков следующих библиотек:

TinyJSON
jsoncpp
zoolib
Jaula
JOST
JSON Spirit
CAJUN

C>RTTI очень слабое подобие метаинформации в управляемых языках.


Я пишу веб-сервисы на С++, биндинг одному малоизвестному языку программирования, библиотеку seamless integration для написания хранимых процедур на С++ для MS-SQL и много ещё чего, но НИГДЕ мне не нужен был RTTI. А Вы для чего RTTI использовали?

MX>>2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько.


C>Простых? Удобных?

C>"Огласите весь список пжалуста!"

"Всего даже я не знаю". Я пользовлся Boost.Serialization, SF из RCF и одной собственного изготовления.
А по поводу простоты, расскажите нам на пальцах — как в Яве не сериализовать какое-нубудь поле в сериализуемом классе? И ещё хотелось бы про версионизацию тоже узнать.

MX>>8) "А как же исключения (exceptions), а как же RTII ?. За них то я всегда плачу всегда !!!". Караул! Заявляю — RTII в С++ никогда не было,

C>RTTI, а не RTII в С++ было, есть и будет.

У аффтара — RTII. Вообще, у него в тексте вагон опечаток. У него, наверное, ко всему такой подход.

MX>>и не предвидится следующие лет 10 точно.

C>Какой кошмар...

Зато — правда.

MX>>9) "будет изменена лишь копия объекта, которая сразу же после этого будет разрушена. Здорово, а ?". А некоторые языки, например, не позвляют выразить тот факт, что переданный в метод объект не будет изменён методом, которые принимает этот объект в качестве параметра.


А на это есть что ответить?

C>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.


Вы считает это _базовыми_ понятиями? Очень интересно. А Вы знаете, что даже цикл — не базовое понятие?
свойств в языке нет, но это не значит, что нельзя написать window.visible = true, чтобы лучше разглядеть окно.
атрибуты? простите, за безграмотность.
события, делегаты? они в каком-то есть языке? круто. а мы, опять-таки — библиотеками обходимся.
лямбда-выражения, замыкания? в старом стандерте-таки да — нет. Но это не мешает нам написать std::for_each(c.begin(), c.end(), std::cout << _1 * _1 << std::endl);
duck typing? покажите пример на Яве, скажу спасибо. А template в С++ — это не оно? Точно? А почему?
интерфейсы? тоже отсутствуют. Покажите пример кода на С++, который будет красивее, будь в нём интерфейсы.
covariance и contravariance?

This variance refers to the parameters and return types of an overridden method in a descendant class. C++ supports this for covariance of return types. Return types and out parameters may be covariant, input parameters may be contravariant, and in-out parameters must be invariant. C++ example: ...

и дальше

"Neither C#, the CLI nor Java support override variance. C++ supports return type override covariance, but not override contravariant input arguments. C++/CLI doesn't support override covariant return types for managed classes. It gives this error:

error C2392: 'Dog ^Dog::GetValue(void)' : covariant returns types are
not supported in managed types, otherwise 'Mammal ^Mammal::GetValue(void)' would be overridden



MX>>13) "средств получить информацию о типе-параметре в языке просто нет" . Язык С++ на столько крут, что "в языке" это и не нужно — можно написать библиотеку. boost::is_abstract, is_arithmetic, is_array, is_base_and_derived, is_base_of, is_class, is_complex, is_compound, is_const...

C>О, ужас.

Подробности будут?

MX>>После слов "Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" этого профана сил осиливать его поток у меня не осталось.

C>Он правду сказал, а Вы классически "съехали на оскорбления", не могучи аргументированно ответить.

Таки-да, отвечать на весь текст мне не захотелось. Если-б у него было достаточно ума, чтобы обсуждать дефекты стандарта С++ — другое дело. "аргументированно ответить", говорите? Среди моих ответов нет таких — "О, ужас.". А про "как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" я ответил выше.
Если не поможет, будем действовать током... 600 Вольт (C)
Re: За что я не люблю С++
От: doarn Россия  
Дата: 26.05.09 21:26
Оценка: 2 (2)
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

_>Он не просто его, не любит, он его ненавидит. И других заразить пытается.
Слишком эмоционально и слишком просвечивает отсутствие опыта разработки/поддержки приложений сколько-нибудь существенной сложности и объема — иначе бы претензии были бы совсем другими...

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

1. А сколько ж здесь способов убиться ап стену.
2. Метаинформацию приходится вносить ручками.
3. В языке нет фичи N (не, лучше M, M — больше).

Ну ответ на это опять же классический.

1. Да, чистая правда — можно при желании. Любая серьезная разработка в итоге ведется не на С++, а на некотором подможножестве языка и надмножестве библиотек, подкрепленном внутренними стандартами. Так что говорить о
2. То же правда, размер декларации данных при этом раздувается в разных пропорциях — от двухкратной (при рукопашном биндинге) до двух строк на класс — при реализации как макроса среды разработки. Большим минусом будет что при этом разные реализации несовместимы между собой.
3. Нельзя объять необъятное, значительная часть запрошенных фичей эмулируется либо 1:1 (что чаще), либо с потерями в объеме кода ну максимум в два раза. Есть конечно вещи, которые толково не реализуются ну никак. Ну дык никто не будет спорить что язык придавлен грузом легаси и в общем-то на данный момент устарел. Но! Это еще не повод его демонизировать.

PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность (собственно упираемся в скорость чтения/записи памяти) на данных умеренно-сложной структуры (поддерживая при этом возможность частичной десериализации кстати, что совсем нелишнее), как там с этим дело у опирающихся на рантайм-метаинформацию сериализаторов Java или, zomg, Питона? =)

PPS: а вот на шарпе аккуратное освобождение ресурсов приходится эмулировать жуткими костылями, дискасс

_>Вот, думаю, тролль Отличная приманка для священной войны.

Да как-то тухло пока — неужели к С++ .vs. весь мир можно добавить что-то новое?
Re[20]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 12:50
Оценка: 2 (1) +1
Здравствуйте, COFF, Вы писали:

COF>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?

GC.Collect();
GC.WaitForPendingFinalizers();


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

Но, конечно же, если хочется такого же секса, как в С++, то можно сделать и вектора с подсчётом ссылок. Объем кода будет сравним с shared_ptr.

Секс — это в смысле возможность сохранить указатель на битмэп мимо вектора, и после освобождения получить InvalidOperationException.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 12:19
Оценка: 2 (2)
Здравствуйте, CreatorCray, Вы писали:
CC>Опять приходим к вопросу: если две одинаковые (в итоге) строки получены из разных источников, будут ли они ссылаться на одну и ту же область памяти?
Нет, не будут. По очевидным причинам: заниматься ерундой типа проверки уникальности при каждой операции получения строки — тратить перформанс непонятно на что.

Но это не так важно. Соображения, по которым все нормальные фреймворки уже 15 лет как используют немутабельные строки, можно прочитать вот здесь.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 27.05.09 06:47
Оценка: 1 (1) :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> M>Дело не в том, что считается базовой вещбю, а что — нет. Дело в том, что с теми же properties можно сразу использовать их из коробки, рыть гугл в поисках их замены, или писать boilerplate code каждый раз, сли их нет. Препочту первое. И так — со многим


ГВ> Да и на здоровье. Но ты же не несёшь по белу свету пургу наподобие статьи в топикстарте.


При желании могу

Вообще-то, все аргументы против С++ уже давно собраны в C++ FQA, имхо
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[29]: За что я не люблю С++
От: -MyXa- Россия  
Дата: 27.05.09 16:32
Оценка: 1 (1) +1
Здравствуйте, Sinclair, Вы писали:

S>Нет. Поскольку свойство — это не тип. В С++, впрочем, метод тоже не может быть аргументом шаблона.


А почему свойство — это не тип? И Вы ошибаетесь — в С++ метод может быть параметром шаблона:
template<typename T, void (T::*m)()>
struct zz
{
    zz()
    {
        T t;
        (t.*m)();
    }
};
Если не поможет, будем действовать током... 600 Вольт (C)
Re[30]: Подсчёт ссылок
От: MxKazan Португалия  
Дата: 28.05.09 17:19
Оценка: 1 (1) +1
Здравствуйте, COFF, Вы писали:

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


MK>>А когда counter уменьшается? Не может случится, что я сошлюсь лишний раз и объект повиснет в памяти? Помнится когда-то я слышал аргумент в пользу сборщика мусора, мол, он помогает избежать проблем, связанных с циклическими ссылками, основанных на счетчиках.


COF>Может конечно, это надо специально разруливать — например использовать пару shared_ptr/weak_ptr

Вот знаешь, почему хорошо, что в C# нет перегрузки присваивания? Как раз чтобы голова не занималась подсчетом этих операцией или выбором вида указателей. А еще ведь надо будет глядеть не перекрыт ли оператор присваивания, а то мало ли чего на самом деле делается. В C# я всегда знаю, что a = b — есть только копирование указателя в случае ссылочного типа и копирование значения в случае value-типа. Всё четко и ясно. По-моему, это плюс.
Re[3]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 23.10.09 13:03
Оценка: 1 (1) +1
Здравствуйте, VladD2, Вы писали:

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


PD>>А вот что не ладно — какие альтернативы С++ можете предложить в ЕГО НИШЕ ? Вот представьте себе — исчез он. Чем замените ?


VD>Определите его нишу, плиз.


Так я уже определил. Ты мне уже минус за это определение поставил

http://www.rsdn.ru/forum/flame.comp/3409448.1.aspx
Автор: Pavel Dvorkin
Дата: 29.05.09


Хочешь еще один минус поставить ? Ставь

VD>Если речь о компилируемых в иполнимый код, то пожалуй OCaml и D.

VD>Есть сомнения, что этим языкам плюсы сливают по полной?

Еще раз, Влад, пойми мою позицию — я не обсуждаю маргинальные направления. Маргинальные в моем определении не значит плохие, а просто пока не употребляемые в реальном мире. Например, Паскаль — маргинальный язык в СССР до появления персоналок. И если бы ты в 1980 году сказал мне, что Паскаль лучше Фортрана, я согласился бы или нет, но обсуждать бы не стал — Фортран есть и царствует, а по Паскалю пара книжек вышла и его в реальности нет. В 1990 году я бы говорил иначе. Поэтому если OCaml и D пойдут всерьез — может быть, я соглашусь, что они лучше. В конце концов, ты же не подозреваешь меня, надеюсь, в том. что я заявляю, что С++ лучше всего на вечные времена. Будет лучше — забудем С++, перейдем на эти языки. А сейчас ему замены нет. Как не было реальной замены Фортрану в 1980.


PD>>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.


VD>А что, ниша языка определяется только типом его компиляции?


Зачем же "только". В определенной степени да.

PD>>Нет ему замены, господа.


VD>Для тех кто только его знает — несомненно, нет.


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

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


VD>Да, ничего не хочется. Потому и не используем.


А я что, призываю тебя использовать ?
With best regards
Pavel Dvorkin
Re[3]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 13:02
Оценка: +1 :)
Здравствуйте, Mamut, Вы писали:

M>И что, прямо-таки можно легко сериализовать объект любой сложности?


Сериализация почти всегда нужна в контексте решения задач наподобие построения протокола обмена данными и тут уже трудозатраты на дублирование названий членов структур уезжают в такой микроскопический масштаб, что о них и рассуждать не стоит.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 26.05.09 13:17
Оценка: +2
Здравствуйте, -MyXa-, Вы писали:

MX> MX>> 1) Понятие метаинформации не то, что отсутствует, но в избытке (сомневаюсь, что он читал Александреску — скорее, он его под ножку стола подкладывал)

MX> MX>> 2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько. Можем и с сами написать — вон, на кывт-е есть статья про сериализацию в хмл, ещё другая есть, про которую все знают.

MX> M>И что, прямо-таки можно легко сериализовать объект любой сложности?


MX> Например?


Объект с циклическими ссылками и членами — указателями на другие объекты. Плюс является наследником другого объекта так, чтобы не надо было явно указывать:
ar & boost::serialization::base_object<bus_stop>(*this) & name;


Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[2]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 13:25
Оценка: +1 -1
Здравствуйте, -MyXa-, Вы писали:

_>>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

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

MX>[:]|||||[:]
Автор:
Дата: 30.03.07


MX>Только в статье — всё не правда. А единственное, чем плох С++, так это тем, что с ним можно 1 раз 15 лет, а можно (как в случае с автором) 15 раз по 1-му году.


В статье почти все правда. Просто преподнесена она так, чтоб сильно задеть программистов С++ и местами немного искажена.

MX>За 15 лет автор так и не осилил простые вещи:


MX>1) Понятие метаинформации не то, что отсутствует, но в избытке (сомневаюсь, что он читал Александреску — скорее, он его под ножку стола подкладывал)

Отлично. Напишите универсальный сериализатор в XML/Json.

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

MX>2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько.


Простых? Удобных?
"Огласите весь список пжалуста!"

MX>Можем и с сами написать — вон, на кывт-е есть статья про сериализацию в хмл, ещё другая есть, про которую все

К Вашему сведенью под persistance библиотеками подразумевается O/RM в первую очередь.

MX>знают. "А вот ... в Python'е таких библиотек полно". Питон — программа на С, библиотека С-шная, а мужики-то не знают.

Вообще-то интерпретатор можно на любом языке написать. Тот же IronPython, IronRuby и т.д. вовсе не на С написаны. Ну и кроме того С++ != С.

MX>3) "А как дела у С++ с интеграцией со скриптовыми языками...". Boost.Python, CliPP, (шёпотом: COM) и др.

Да плохо с интеграцией. Работать с COM в .NET на много проще.

MX>8) "А как же исключения (exceptions), а как же RTII ?. За них то я всегда плачу всегда !!!". Караул! Заявляю — RTII в С++ никогда не было,

RTTI, а не RTII в С++ было, есть и будет.
MX>и не предвидится следующие лет 10 точно.
Какой кошмар...
MX>9) "будет изменена лишь копия объекта, которая сразу же после этого будет разрушена. Здорово, а ?". А некоторые языки, например, не позвляют выразить тот факт, что переданный в метод объект не будет изменён методом, которые принимает этот объект в качестве параметра.
А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.

MX>13) "средств получить информацию о типе-параметре в языке просто нет" . Язык С++ на столько крут, что "в языке" это и не нужно — можно написать библиотеку. boost::is_abstract, is_arithmetic, is_array, is_base_and_derived, is_base_of, is_class, is_complex, is_compound, is_const...

О, ужас.

MX>После слов "Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" этого профана сил осиливать его поток у меня не осталось.

Он правду сказал, а Вы классически "съехали на оскорбления", не могучи аргументированно ответить.
Re[10]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 26.05.09 18:03
Оценка: +2
ГВ> C>Еще раз для тех, кто читать не умеет: открываем стандарт С++, смотрим, не находим, извиняемся.

ГВ> Я потому тебя в гугль и отправил, чтоб ты почитал дискуссии по поводу пропертей для C++. Очень неоднозначно всё получается. Это с одной стороны. А с другой — не так уж и плоха жизнь без оных пропертей, хотя я понимаю — если в язык не затащено всё, что на сегодня считается "базовой вещью" — это плохой язык.



Дело не в том, что считается базовой вещбю, а что — нет. Дело в том, что с теми же properties можно сразу использовать их из коробки, рыть гугл в поисках их замены, или писать boilerplate code каждый раз, сли их нет. Препочту первое. И так — со многим
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[11]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 18:49
Оценка: +1 -1
Здравствуйте, Mamut, Вы писали:

M>Дело не в том, что считается базовой вещбю, а что — нет. Дело в том, что с теми же properties можно сразу использовать их из коробки, рыть гугл в поисках их замены, или писать boilerplate code каждый раз, сли их нет. Препочту первое. И так — со многим


Да и на здоровье. Но ты же не несёшь по белу свету пургу наподобие статьи в топикстарте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:04
Оценка: +1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>[skip overquoting]


C>>Действительно... в чем разница...


ГВ>Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.


Вы бьете рекорды по фанатичной чуши... Вы сами хоть верите в то, что пишете?

C>>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.


ГВ>Такая же, как и для обычной структуры данных.


То есть никакая. Так и запишем.

A>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

C>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

ГВ>Угу, "set; get;" как символ истинной лаконичности.


Куда лаконичнее?
Re[13]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 19:32
Оценка: +2
Здравствуйте, criosray, Вы писали:

ГВ>>Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.


C>Вы бьете рекорды по фанатичной чуши... Вы сами хоть верите в то, что пишете?


Я это знаю. Это ярые (подчёркиваю — ярые) противники C++ обычно верят в какие-то невероятные мифы. Я уж не знаю, почему так складывается, но как только кто-то выступает с резкой критикой C++, так такую пургу нести начинает — уши вянут.

C>>>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.

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

Любая. В твоем мире — если сериализация не встроена в платформу, то её нет, я уже понял. В моём — если какой-то фишки нет, то это означает, что она может быть любой.

A>>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

C>>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

ГВ>>Угу, "set; get;" как символ истинной лаконичности.


C>Куда лаконичнее?


Откуда я знаю? Но затычка отсутствия умолчаний налицо. И это в языке, для которого проперти — роднее всех родных.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 26.05.09 19:36
Оценка: +2
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Хвост, Вы писали:


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


C>1. Читабельность кода.

C>2. Compile time проверка корректности типов и именования.
3. Атрибуты
4. Обзёрвер INotifyPropertyChanged

наверно еще чего-то наберется, сразу и не вспомнишь...
Re[2]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 26.05.09 21:12
Оценка: +2
Здравствуйте, CreatorCray, Вы писали:

CC>В сравнении с тутошними срачами "C++ vs *" — статья детский лепет и обидки.


Да тутошние срачи тоже так себе в плане профессионализма, особенно свеженькие.
Re[3]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 02:24
Оценка: +1 :)
Здравствуйте, Ночной Смотрящий, Вы писали:

CC>>В сравнении с тутошними срачами "C++ vs *" — статья детский лепет и обидки.

НС>Да тутошние срачи тоже так себе в плане профессионализма, особенно свеженькие.

Да, оппоненты стали уже не те.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[4]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 07:22
Оценка: :))
Здравствуйте, CreatorCray, Вы писали:

CC>>>В сравнении с тутошними срачами "C++ vs *" — статья детский лепет и обидки.

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

Про идиотизм это Вы хорошо заметили...

Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая).

(с) ГВ
Re[8]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 07:56
Оценка: +1 :)
Здравствуйте, CreatorCray, Вы писали:

CC>>>А тут написанные библиотеки в комплект не входят.

MK>>В случае тех же свойств, не "библиотеку положили рядом", а компилятор научили работать. Всё-таки есть разница.
CC>По мне так один хрен.
CC>По мне так в компилятор надо впихивать то, что никак нельзя нормально реализовать через библиотеки.
Почему же Вы на Lisp`е не пишете? Там вообще кроме скобочек и нескольких арифметических операторов ничего нету.
Re[19]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 12:19
Оценка: -2
Здравствуйте, Sinclair, Вы писали:

S>Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось.

F>>по сути это что то схожее с property от микрософта..
S>Да-да, я в курсе про многообразные костыли.

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

Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?
Re[13]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 12:24
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

C>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).


По большому счёту, это довольно опасная штука — развешивать "обработчики" на "события". Как минимум, всякий раз рискуешь нарваться на что угодно — от бесконечной рекурсии, до дедлоков. Хотя да, лежащий на поверхности наивный подход как раз и состоит в том, чтобы понавешать "сигналов", т.е. — callbacks.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 13:01
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

S>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет.


Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?

S>Но, конечно же, если хочется такого же секса, как в С++, то можно сделать и вектора с подсчётом ссылок. Объем кода будет сравним с shared_ptr.


А каком сексе вы говорите уважаемый? секс это оба ваших решения, а в C++ все просто и прозрачно.

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


В общем, в очередной раз, если чего-то нет в C++ — это секс, а если чего-то нет в C# — это так и надо :)
Re[28]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 15:40
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>Например, можно ли оперировать таким явлением, как "ссылка на свойство"?
Можно. См. PropertyInfo
ГВ>Может ли "свойство" выступать аргументом шаблона?
Нет. Поскольку свойство — это не тип. В С++, впрочем, метод тоже не может быть аргументом шаблона.
ГВ>Ну и так далее. Получилось как всегда — C++ плох тем, что это не C#.
Да нет, не тем. Тем, что многабукаф на ровном, тскать, месте.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: За что я не люблю С++
От: Хвост  
Дата: 27.05.09 21:29
Оценка: -1 :)
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Хвост, Вы писали:

C>>>Не можете, очевидно. В С++ не возможно генерировать и исполнять произвольный код в рантайм. В лучшем случае сможете распарсить в структуру словарного типа, но это решение для бедных и не является десериализацией.
Х>>очевидно что в C++ нет emit, ну дык ето понятно почему, а вот то что в рантайм генерировать и исполнять код нельзя ето горячка, потому как есть элементарное "сгенерить код и отдать компилятору для сборки dll" или более сложное как LLVM, что первое что второе вполне себе удобные и рабочие решения.

C>О производительности и масштабируемости данного решения Вы конечно не задумывались?

конечно не задумывался, решения очевидно производительные и масштабируемые, етож не какой-то там дотнетный emit.
People write code, programming languages don't.
Re[23]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 22:04
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

C>Во-первых, не ясно при чем тут это.

C>Во-вторых, это вам требуется несколько часов (максимум день???) на то, что в дотнет делается за 5 минут? Да уж, нашли повод для гордости.

В реальной жизни примерно столько же, хотя конечно всёравно проще (про пятиминутные исправления обычно говорят люди с 1-2 годами опыта реальной работы и ещё не умеющие отвечать за базар). Главный тормоз в этом не само подключение, а формализация процесса.
И я встрял исключительно чтобы показать тебе ещё один твой пробел в знаниях.

P.S.
Кончай фанатствовать
Нужно разобрать угил.
Re[9]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 22:06
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

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


C>Начнем с того, что С++ не является универсальным языком. На этом и закончим.


Универсальным не является, но является (со своей сопутствующей поддержкой) наиболее универсальным среди распространённых.
Нужно разобрать угил.
Re[26]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 01:00
Оценка: -2
Здравствуйте, NikeByNike, Вы писали:


NBN>Ты смешной Давно не наблюдал такой откровенной страусной тактики. Спасибо!


Поставьте зеркало рядом с монитором. Будете радоваться каждой минуте.
Re[5]: За что я не люблю С++
От: Antikrot  
Дата: 28.05.09 06:26
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

C>>>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.

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

C>Какой еще костыль? Вы хоть поняли какую глупость сморозили?

костыль-костыль. как еще назвать дополнительное приложение, встроенное в билд-процесс и исправляющее [потенциальные] ошибки программиста? ведь в стандарте языка-то его нет
получается, что использование препроцессора в QT — это костыль и проблемы C++, а использование постпроцессора в C# — это так и надо?

C>Сходите чтоли почитайте.. http://msdn.microsoft.com/en-us/library/bb429476.aspx

ну, в отличии от некоторых почитателей отдельных ОС/браузеров тут, я таки сначала прочитал
Re[24]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 08:57
Оценка: :))
Здравствуйте, COFF, Вы писали:


ГВ>>>Так что такое "структура словарного типа"? Ты можешь объяснить или нет?


C>>Понятно. Дожились. Нынче программисты даже таких базовых вещей не знают. Тьфу.


COF>Самое прикольное, что гугл с яндексом тоже не знают Поделись же сокровенным знанием, о наимудрейший?


Программисты С++ уже и гуглем пользоваться разучились? http://en.wikipedia.org/wiki/Associative_array

Действительно... дожились.
Re[3]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 11:45
Оценка: +1 :)
Здравствуйте, _d_m_, Вы писали:

___>Ты как страус зарыл голову с песок.


Ну и что! Тут есть люди, зарывшие далеко не одну голову в песок.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 13:05
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:


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


C>>Про совершенно неизвестные это Вы сами придумали. Достаточно, чтоб класс реализовал заранее известный контракт, ака интерфейс.


ГВ>

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


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

Это Вы себе сами придумали. Что Вы от меня хотите услышать?
Re[27]: Подсчёт ссылок
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 16:07
Оценка: +1 :)
Здравствуйте, Qbit86, Вы писали:
Q>Найди 33 отличия.
Достаточно одного

S>>Поэтому соглашение об инкременте указателя придется выполнять самостоятельно.

Q>Поясни.
Очень просто. Вот у нас есть
public static void EpicFail(HugeBitmap bmp)
{
  RefCounter<HugeBitmap> c;
  using(var a = new RefCounter<HugeBitmap>(bmp)); // bmp.refCount++;
    {
      var b = new RefCounter(a); // bmp.refCount++
      c = a; // oops... вот в этот момент С++ инкрементирует указатель. С# - нет.
    b.Dispose(); //bmp.refCount-- 
    } // bmp.refCount-- => bmp.Release()
    c.Reference.Draw(); // InvalidOperationException!
}

Вся дупа в том, что нет в дотнете перегрузки оператора присваивания. А конструктором копирования обязательно нужно не забыть попользоваться. Непонятно даже, насколько это плохо по сравнению с плюсами, в которых можно забыть воспользоваться shared_ptr.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: За что я не люблю С++
От: drol  
Дата: 28.05.09 16:29
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

MX>>>А почему свойство — это не тип?

D>>А почему поле класса — это не тип ?

ГВ>Как раз таки — тип.


Неправда.

MX>>>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:

D>>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.

ГВ>Where is a difference?


Вам неясна разница между указателем и тем на что он указывает ???
Круто. И эти люди пишут на C++
Re[29]: Подсчёт ссылок
От: MxKazan Португалия  
Дата: 29.05.09 09:47
Оценка: +2
Здравствуйте, Eugeny__, Вы писали:

E__>Я чего-то не понимаю, на кой вообще битмапу(который, по сути, тупо массив байт, вполне себе менеджед, а значит, подвластен GC(или в шарпе это не так? Я только про джаву знаю достоверно)) Release? Не нужен — просто обнуляешь все ссылки на него, пусть сборщик сам разбирается, он прекрасно увидит, что есть крупный массив байт, и на него нету ссылок ни у одного из потоков, и соберет его, когда память начнет кончаться. Зачем вообще эти пляски с бубном?

Ключевое выделено. Парням из банды С++ хочется, чтобы объект собрался не когда память начнет кончаться, а именно когда не будет ссылок. И еще такой момент: текущая реализации битмапа в Windows Forms — это таки нативный хэндл ОС, в котором GC не властен.
Re[2]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 29.05.09 09:59
Оценка: +1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вот что не ладно — какие альтернативы С++ можете предложить в ЕГО НИШЕ ? Вот представьте себе — исчез он. Чем замените ?

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

PD>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.

Конкретнее, что за ниша?
Re[3]: А я вот, например жену люблю, а к языкам равнодушен ;
От: Qbit86 Кипр
Дата: 29.05.09 11:40
Оценка: :))
Здравствуйте, Erop, Вы писали:

E>А написать что-то такое сложно-умное, много насилующее память и процессор, то тут уже ХиндиС не тянет.


«Насилование памяти и процессора» к «сложно-умному» не имеет никакого отношения. «У нас в студии это называется „пидарасить пиксели“ или „тихановщина“. Вообще, я дизайнерам запрещаю это делать.» (© Некий Артемий Л.) В нашем случае это надо назвать «пидарасить байты или такты процессора». Работа иногда нужная, и порой весьма полезная. Как, например, работа ассинезатора. Но гордиться тут нечем. «Сложно-умное» как раз-таки делается на адекватных высокоуровневых языках. А «грязно-рутинную оптимизацию» можно и на C†† каком-нибудь. (Но не нужно.)
Глаза у меня добрые, но рубашка — смирительная!
Re[41]: Ответ настоящего джедая
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.05.09 12:22
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Добавим тривиальное усложнение в функцию управления Enabled:
S>Ничего военного.

Ну как же, ничего военного?! Зато ты теперь не сможешь с лёгкостью неимоверной приклеить одну и ту же функцию к свойствам, переменным и вообще к классам, реализующим семантику присвоения значения. Я уж не говорю об эстетике:

var bOk = new StoredProperty<bool>(false);
var bCancel = new StoredProperty<bool>(true);


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


Извини, я не удержался.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.05.09 13:05
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

ГВ>>Понятно. Значит, я придумал цитату из твоего собственного постинга. А сам твой постинг мне привиделся.

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

Э... Ты понимаешь в чём дело, пресловутые "произвольные типы" берущиеся ниоткуда, это своего рода фишка полемики C++ vs. Вот потому я и ответил тебе в том же духе. Но ты тоже хорош: мало ли что у тебя не сказано? У тебя там, может быть, нехорошее слово из трёх букв не сказано — я его тоже должен подразумевать и соответственно реагировать? Есть правило — читать ровно то, что написано (и не больше). Чтобы ему все следовали, нужно ещё и писать то, что хочешь высказать, не заставляя собеседника додумывать.

C>>>Что Вы от меня хотите услышать?

ГВ>>Да я уж не знаю, что от тебя можно хотеть услышать — у тебя ж перл на перле. Моя фантазия не хватать такой предел.
C>Да. Вашей фантазии хватает только на детские попытки цепляться к словам и переиначивать слова собеседника. Достаточно вспомнить про "словарным структурам" и приписанные мне, выдуманное вами в данной ветке.

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

Так что, если хочешь продолжить обсуждение, будь добр сформулировать толком, что ты хочешь узнать. А то вариантов очень много.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: А я вот, например жену люблю, а к языкам равнодушен ;
От: Qbit86 Кипр
Дата: 29.05.09 13:07
Оценка: +1 :)
Здравствуйте, Erop, Вы писали:

Q>>«Насилование памяти и процессора» к «сложно-умному» не имеет никакого отношения. «У нас в студии это называется „пидарасить пиксели“ или „тихановщина“. Вообще, я дизайнерам запрещаю это делать.» (© Некий Артемий Л.) В нашем случае это надо назвать «пидарасить байты или такты процессора». Работа иногда нужная, и порой весьма полезная. Как, например, работа ассинезатора. Но гордиться тут нечем. «Сложно-умное» как раз-таки делается на адекватных высокоуровневых языках. А «грязно-рутинную оптимизацию» можно и на C†† каком-нибудь. (Но не нужно.)


E>1) мат тут запрещён.


За мат (хоть он исходил не от меня, а из цитаты) готов извиниться.

E>2) Я вообще-то не понимаю, от чего ты считаешь, что ресурсоёмкие приложения обязательно простые...


Аналогично, я не понимаю, почему ты считаешь, что программисты на C# — это недоученный быдлоиндусы. У меня противоположный опыт общения с шарпистами и плюсистами. Первые, как правило, неплохо разбираются и в плюсах, потому что имеют соответствующий background, посему более критичны в суждениях. Вторые, как правило, воинствующие снобы, считающие владение плюсовыми аббревиатурами типа SFINAE или CRTP мерилом умения программировать.

E>Но я ещё призываю таки в таком русле продолжать тут
Автор: Erop
Дата: 29.05.09
... ;)


Там вроде какой-то опрос предлагается, я не в курсе. Дело в том, что я не читаю текст, чрезмерно изобилующий значками «☺» и «!!!» Так что «в таком русле продолжать» — это без меня.
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: Жена-то при чём?
От: Qbit86 Кипр
Дата: 29.05.09 13:27
Оценка: -1 :)
Здравствуйте, Erop, Вы писали:

Q>>Аналогично, я не понимаю, почему ты считаешь, что программисты на C# — это недоученные быдлоиндусы.

E>Что C# -- настолько классный язык, что на нём могут прогать и индусы ;)

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

E>Ну не повезло тебе, или, наоборот, повезло... Не знаю...


В конце этой строчки ты забыл поставить смайлик. Будь внимательнее.

E>В любом случае -- зачем обобщать-то? ;)


«Золотые слова» ©

E>Не волнуйся, ты там со своими "цитатами" и "ассенизаторами" вполне органичен будешь ;)


Как же мне не волноваться-то? Информативный, должно быть, опрос, но совершенно не досягаемый, в виду моего лексического фильтра. Сколько полезных вещей мимо проходит! Я в печали.
Глаза у меня добрые, но рубашка — смирительная!
Re[7]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 22:14
Оценка: +1 -1
Здравствуйте, gandjustas, Вы писали:

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

G>А "спецы в перечисленных" областях чтонить кроме С++ знают?
AFAIK, знают. Кроме того, это странно предполагать, что самые умные и знающие программисты формочки к базам клепают
Но в целом лучше спроси у спецов. В тех из перечисленных областях, где я со спецами знаком лично -- знают...

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

G>И подавляющему большинству программистов тоже.
Да подавляющему большинству программистов вообще всё по, кроме зряплаты...
Но в целом опыт пока что учит нас тому, что на С++ пока что удаётся получше разгонять ресурсоёмкий код...
Как только это изменитися, так сразу все переметнутся, я думаю...

G>О ужас, ручками код оптимизировать... как же с этим жить?

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

G>Кроме того если и надо оптимизировать, то числомолотильные алгоритмы, в остальном и так .NET быстрее работает.

Это я не понял. Попробуй выразить ту же мысль другими словами...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Эх, выдыхай, однако...
От: Erop Россия  
Дата: 29.05.09 23:35
Оценка: :))
Здравствуйте, criosray, Вы писали:

C>Где Вы узрели русский слог?

В слове Иван...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[36]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 30.05.09 12:56
Оценка: +2
Что-то я запутался, в этой ветке я за дотнет вразумляю, или за сиплюсплюс?

Здравствуйте, -MyXa-, Вы писали:

MX>Инкремент/декремент не может быть лишним.

MX>Я не знаю, зачем вы это повторяете. Я никогда boost::shared_ptr по ссылке не передаю. А Вы?

Я же выше намекнул, что проверить можно через use_count(), почему ты этого не сделал? Я должен за тебя код набирать? Хорошо, в последний раз я это сделаю.

void Foo(std::tr1::shared_ptr<int> p)
{
  std::cout << p.use_count() << std::endl;
}

void Bar(std::tr1::shared_ptr<int> const& p)
{
  std::cout << p.use_count() << std::endl;
}

int main () 
{
  std::tr1::shared_ptr<int> const p(new int(2));
  std::tr1::shared_ptr<int> const q(new int(1));

  Foo(p);
  Bar(q);
}


MX>Инкремент/декремент не может быть лишним. Я не знаю, зачем вы это повторяете.


Я не знаю, зачем ты упорно отрицаешь вещи, очевидные любому C++-программисту. Алсо, почитай книжки, где рассказывается про 1) ссылки/уазатели, 2) влавдение/аггрегацию/композицию, etc.

MX>И где экономия?


Я уже отчаялся тебе хоть что-то объяснить. Впредь я не буду даже пытаться.

MX>_Просто_ "ссылаются два человека" и ни один не владеет? ЗдОрово!


Ты ничего не понимаешь в понятиях «ссылается» и «владеет». Точка, абзац. Вот тебе пример на C++ (потому что C#, очевидно, для тебя слишком сложен тем, что значок «=» означает в нём копирование ссылки):
  std::tr1::shared_ptr<int> p(new int(42));
  std::tr1::shared_ptr<int>& ref1(p);
  std::tr1::shared_ptr<int>& ref2(p);

Здесь есть 3 идентификатора — p, ref1, ref2. Чем-то владеет только p. Остальные — это ссылки на него, объявление ссылки не приводит к разделению владения. Не веришь — проверь:
  ref1.reset();
  std::cout << *ref2 << std::endl;


MX>Короче, нет никакого способа в C# передать поле (вообще объект) в метод, не передав владения. Так и запишем.


Ага, так и запиши. Повторяй, как мантру. Совершенно очевидно, что ты не заинтересован в «понять», а заинтересован в «переспорить». Вообще-то, встречая явно провокационные (читай «толстый троллинг») фразы типа «В общем, картина начинает проясняться»
Автор: COFF
Дата: 28.05.09
и «Так и запишем»
Автор: -MyXa-
Дата: 29.05.09
, полезно заблаговременно вносить собеседника в реестр недостойных внимания и не тратить на них более времени.
Глаза у меня добрые, но рубашка — смирительная!
Re[12]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 13:44
Оценка: :))
Здравствуйте, Erop, Вы писали:

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


G>>Поэтому в unmanaged занимаются или созданием кучи потоков, или оптимизируют только на высоком уровне. Оба варианта заметно влияют на производительность.


E>Ну и где управляемые базы данных, например, которые рвут неуправляемые по производительности?

Есть CouchDB например. Только сравнить её пока не с чем.

Что касается РСУБД, то все еще впереди. МС только-только создает VS на .NET.
До SQL Server дойдет нескоро.
Другие вендоры вряд ли решаться выкинуть существующий codebase.
Re[13]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 30.05.09 16:21
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

E>>Ну и где управляемые базы данных, например, которые рвут неуправляемые по производительности?

G>Есть CouchDB например. Только сравнить её пока не с чем.

CouchDB не на Эрланге разве? Это ж не совсем то, что мы понимаем под managed.

G>Что касается РСУБД, то все еще впереди. МС только-только создает VS на .NET.


В кассу:

(01:40:18) With Sun releasing some hardware which runs Java bytecode, are you afraid that it could take away C++’s embedded position?

* A: Java would kill C++ totally in 2 years, Sun said in 1996. They sort of been repeating this story over and over again. There is a lot of Java, and there is a lot of C++ and it’s a big world.


Вопрос: Как вы думаете, не потеряет C++ своих позиций в embedded из-за того, что Sun выпустил устройства с аппаратной поддержкой Java-байткода?

Ответ: Java полностью вытеснит C++ за два года, говорили в Sun в 1996 году. Они и сейчас так же говорят. Мир велик и места хватает всем — и Java, и C++.


Лекция Страуструпа и частичная её расшифровка.

G>До SQL Server дойдет нескоро.

G>Другие вендоры вряд ли решаться выкинуть существующий codebase.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: За что я не люблю С++
От: CreatorCray  
Дата: 01.06.09 11:39
Оценка: -2
Здравствуйте, criosray, Вы писали:

C>Множественное наследование такой же моветон, как и goto.

Какое смелое заявление.

C>>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>>logger::log(__filename__, __line__, "log text")

C>
C>catch(Exception e) {
C>   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
C>   throw;
C>}
C>


А ничего что то, что ты написал к logger::log(__filename__, __line__, "log text") не имеет вообще никакого отношения даже близко.

C>Не позорьтесь так больше.

Как же ты любишь эту фразу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[5]: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 12:18
Оценка: -2
Здравствуйте, criosray, Вы писали:

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


C>>>Множественное наследование такой же моветон, как и goto.

CC>>Какое смелое заявление.
C>Это факт.
C>http://c2.com/cgi/wiki?MisUsingMultipleInheritance
C>http://www.gotw.ca/publications/mill06.htm


C>

C>Scott Meyers is one of the leading gurus in the C++ languages, in his book "Effective C++", the "is a" relationship for public inheritance is being mentioned in item 35: Make sure public inheritance models "is a".

C>Beside that, the current chairman of the ISO C++ Standard Committee, Herb Sutter, have also mentioned that in one of his articles.


C>We need "controlled polymorphism" LSP IS-A, but in certain code only. Public inheritance should always model IS-A as per the Liskov Substitution Principle (LSP).[3] Nonpublic inheritance can express a restricted form of IS-A, even though most people identify IS-A with public inheritance alone. Given class Derived : private Base, from the point of view of outside code, a Derived object IS-NOT-A Base, and so of course can't be used polymorphically as a Base because of the access restrictions imposed by private inheritance. However, inside Derived's own member functions and friends only, a Derived object can indeed be used polymorphically as a Base (you can supply a pointer or reference to a Derived object where a Base object is expected), because members and friends have the necessary access. If instead of private inheritance you use protected inheritance, then the IS-A relationship is additionally visible to further-derived classes, which means subclasses can also make use of the polymorphism.


Многа букаф и ничего по существу.

C>>>>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>>>>logger::log(__filename__, __line__, "log text")

C>>>
C>>>catch(Exception e) {
C>>>   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
C>>>   throw;
C>>>}
C>>>


CC>>А ничего что то, что ты написал к logger::log(__filename__, __line__, "log text") не имеет вообще никакого отношения даже близко.

C>Конечно имеет. Но если хотите один в один, то ради бога:
C>Log.Info("log text");

А кто просил время выводить? По рукам, по рукам и никакой премии, хакер узнал лишнюю инфу из пользовательского лога, вы уволены.
Re[4]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 12:53
Оценка: +1 -1
Здравствуйте, 0xC0000005, Вы писали:


C>>(бред г-на с хацкерским ником вырезан цензурой)


C>Никогда не думал что код ошибки доступа к памяти известен лишь хацкерам, печально...


Не только, но только "кулхацкеры" вбирают себе в качестве ника "код ошибки доступа к памяти в 16ричном формате".

C>>Дотнет и джава прекрасно обходятся без недоразумения под названием "множественное наследование". boost и stl по структуре и удобству смотряться очень и очень бедно на фоне .NET Framework.


C>Итак начнём с реального примера, представте себе ОО дизаин, в котором есть ядро и то что доделывает сам клиент у себя, клиент не может менять код ядра, а только насоедовать классы, менять некоторый функционал и подменять core класс своим в рантайм. Так вот есть структура:

C>ClassA
C> | \
C>ClassB ClassC
C>/|\
C>ClassB1 ClassB2 ClassB3

C>В класс Α необходимо добавить один метод, если вы унаследуете от А, то он подменится, НО потомки оригинального А всё равно будут юзать оригинального родителя.


C>При множественном наследовании данная зада решается очень просто всего одним классом, думаю вам как мега-кодеру не надо примеров. На ненастоящих языках все все потомки которые не абстрактные должны добавить этот метод. Тут ещё убирается нафиг полиморфизм и новые костыли вставляются в код.


Не надо тут никакого многожественного наследования:
СlassA
|
OpenForModificationsClassA — добавляем методы сюда
| \
ClassB СlassC
/ | \


C>>Множественное наследование такой же моветон, как и goto.


C>А у вас смотрю стиль автора текста, хотите так же о шарпе? Утка это так же тупо как аддресс функции, Делегация это так же наивно как сдвиг в сегменте


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

C>>>А много ли явошарпы знают удобных, простых и "интуитивно" понятных способов расширить функционал языка? Вот у меня требование к либе, я хочу регить callbackи вот таким способом:

C>>>alarmNotifier = GUIHandler::onAlarm + CoreRoutine::onAlarm
C>>>и что? у вас есть "костыль"? или всё чего нету нам не надо? Ха, это мертвецки неправильно, и обычно такое отмирает как несовершенное.
C>>То, что есть у Вас еще бОльший костыль.

C>>obj.Alarm += OnAlarm;

C>>obj.Alarm += (arg1, arg2) => { /* обработчик здесь */ };

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


Объясните.

C>>Что до расширяемых .NET языков — смотрите Nemerle и Boo.


C>Я не говорю о других языках, я говорю о расширении в рамках одного языка, или Немерил с Бу компилятся родным шарповским компилятором?


Зачем? Язык абсолютно не важен. Дотнет сборки Nemerle и Boo (С#, VB.NET, F# и т.д. — любом дотнет языке) подключаются к любому дотнет проекту. Интеграция полностью прозрачная.

C>>
C>>catch(Exception e) {
C>>   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
C>>   throw;
C>>}
C>>


C>А вот это красота которую я от вас ожидал Как меня достали эти криворучки, которые думают что кинуть в лог всё что можно из стека это так круто, ведь там разберуться.

Не понял полета мысли. Что значит "все, что можно из стека"? Естественно, при логировании имеет смысл писать в лог максимум информации. Что не так?

C>Вы опять кинули мне пример готового тёплого коричневого батончика, я просил номер строки, вы кинули весь Stack Trace, я знаю что это такое, и я знаю что взять стэк вызовов в С++ не составляет проблем.

Нет, Вы не знаете что такое StackTrace. Открою Вам глазки:

            StackTrace stackTrace = new StackTrace(true);
            var frame = stackTrace.GetFrame(1);
            frame.GetFileColumnNumber();
            frame.GetFileLineNumber();
            frame.GetFileName();
            frame.GetILOffset();
            frame.GetMethod();
            frame.GetNativeOffset();


Еще вопросы будут?

C>А как взять имено номер строки в файле? Или это бага щарпа ещё не разработана?

C>Или в новой версии появится printFileAndLine и вы будете выдирать и парсить номер строки? Ах скока кода я перевидал с такими заплатками
Рассказывайте свои фантазии в другом месте, ок.

C>>И Вы осмеливались утверждать, что Вы что-то знаете об управляемых языках? Да уж по части логеров управляемые языки рвут неуправляемые (в т.к. С++), как тузик — грелку. Вам только мечтать об удобстве отладки и логирования, предоставляемых средствами управляемых сред.


C>Я осмеливаюсь утверждать что за такой код я бы вас уволил, будь то Ява или Шарп или Плюсы, этот стиль называется есть ошибка — нет ошибки.

Что значит есть — нет? Вы throw не заметили? Так это Вас, а не меня увольнять надо.

C>А ЕСЛИ это не исключение?

Что "это"? сatch(Exception e) ловит все исключения (т.к. он является базовым классом для классов исключений в дотнет). Не знали об этом?
Можно конечно прицепиться, что делать сatch (Exception e) {} тоже моветон, но я привел этот код как простейший пример. Если не нравится, то можно переписать


сatch(MyAppFaultConditionException e)
{
    Log.Error(e);
    throw;   
}

Cути это не поменяет.

C>>>Ага, а теперь скажите мне, у меня огромный обьект, но я хочу сериализовать только, замете слово ТОЛЬКО хидеры во всей иерархий, вот так я это использовал:

C>>>dataStream << Modifiers::HeadersOnly << hugeObject;

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


C>>
C>>    [JsonObject(MemberSerialization.OptIn)]
C>>    public class LoginResult
C>>    {
C>>        private ResultErrors errors = new ResultErrors();

C>>        [JsonProperty("success")]
C>>        public bool Success { get; set; }

C>>        [JsonProperty("errors")]
C>>        public ResultErrors Errors
C>>        {
C>>            get { return errors; } 
C>>        }
C>>    }
C>>



C>Не не не дядя, ты не понял меня, есть класс который тебе дал один мужик, и надо его сериализовать для бор машинки другого дяди, ты тут всего-то один программер в большом проекте, а не Вася Пупкин с проектом Хелло Бил где можно менять всё что под руку попало, Слабо повторяю?


И какие проблемы? Делаем DTO и атрибутами описываем какие поля сериализовать, какие — не сериализовать, какие сериализовать как атрибуты, а какие — как ноды (если речь о Xml-сериализации).

Кстати, как там с Xml-сериализацией в С++?

C>>Вы сначала заставьте это компиллироваться под С++


C>>>public <T> void f()

C>>>{
C>>> T t = new T();
C>>> t.f();
C>>>}

C>Под плюсы подобный код? Давайте прямо так навскидку с компиляцией


    class A : IAinterface
    {
        public void f() {}
    }

    internal interface IAinterface
    {
        void f();
    }

    class Program
    {
        static public void foo<T>() where T : IAinterface
        {
            var a = new A();
        }

        static void Main(string[] args)
        {
            foo<A>();
        }
    }


C>Компилится, работает.

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

C>>>Вот скажите мне серьёзно, хоть один реальный пример в рамках одного приложения(про распределённые системы отдельный разговор), когда на этапе компиляции тип обьекта не известен, а если он известен, то зачем его узнавать? Потеряли — плохой дизайн и кучерявые руки!!! + обрезанность языка.

C>>COM

C>КОМ это прадед распределённой модели — это отдельный разговор, если уж хотите посмотреть как это может работать без мета инфы красиво, посмотрите на внука КОМа — CORBA в имплементации Шмидта над ACE

Да при чем тут DCOM? Я говорю о классическом COM.

C duck typing (boo):

import System.Threading

def CreateInstance(progid):
   type = System.Type.GetTypeFromProgID(progid)    
   return type()    

ie as duck = CreateInstance("InternetExplorer.Application")
ie.Visible = true
ie.Navigate2("http://www.go-mono.com/monologue/")

Thread.Sleep(50ms) while ie.Busy

document = ie.Document
print("${document.title} is ${document.fileSize} bytes long.")


теперь то же самое без duck typing (boo):


import System.Threading
import System.Reflection

def CreateInstance(progid):
    type = System.Type.GetTypeFromProgID(progid)    
    return type()    
    
def SetProperty(target, name, value):
    target.GetType().InvokeMember(name, BindingFlags.SetProperty, null, target, (value,))
    
def GetProperty(target, name):
    return target.GetType().InvokeMember(name, BindingFlags.GetProperty, null, target, null)
    
def Invoke(target, name, arg):
    return target.GetType().InvokeMember(name, BindingFlags.InvokeMethod, null, target, (arg,))

ie = CreateInstance("InternetExplorer.Application")
SetProperty(ie, "Visible", true)
Invoke(ie, "Navigate2", "http://www.go-mono.com/monologue/")

Thread.Sleep(50ms) while GetProperty(ie, "Busy")

document = GetProperty(ie, "Document")
print("${GetProperty(document, 'title')} is ${GetProperty(document, 'fileSize')} bytes long.")


В С++ будет еще (на порядок) уродливее.


C>Это хорошо что в шарпах есть аут параметры, хоть чего-то увидели в ошибках Явы.

C>А как строки относятся к языку? Этож не паскаль
Строка такой же базовый тип данных, как и int, double, bool, и т.д. Если этого не понимать, то получится тот зоопарк реализаций с миллионом граблей, который мы наблюдаем в С++.

C>и чем вам std::string не строка, когда-то веб сервак делал заточенный под одного клиента, так там все буфера отлично на этих строках работали.

Одна из реализаций. Как-там у нее с юникодом, кстати?

C>>>TO BE CONTINUED!!!

C>>Не позорьтесь так больше.
C>Ну к вам это более применимо, 2 неправильных примера и незнание тематики (на С++ это не компилится итп)
Каких примера, какой терминологии. Не стесняйтесь — выкладывайте.
Re[5]: За что я не люблю С++
От: Antikrot  
Дата: 01.06.09 14:17
Оценка: +1 :)
Здравствуйте, criosray, Вы писали:

C>Это все замечательно, но Вы выпускаете из виду одну простую истину — производительность важна только там, где ее не хватает. В недавнем обсуждении выяснилось, например, что числомолотилка на дотнет работает быстрее, чем числомолотилка на С++, если компилировать со стандартными настройками. Да, пересобрав ее с SSE3 и всеми возможными оптимизациями получили выигрышь примерно в три раза.


offtopic:
не всеми возможными
векторизация sincos в том примере позволяет на плюсах отыграть еще секунду но это тааакая ересь в коде получается
Re[25]: За что я не люблю С++
От: March_rabbit  
Дата: 01.06.09 14:33
Оценка: +1 :)
Здравствуйте, Mamut, Вы писали:

M>> M>Лучше, если эти пять строк уже встроены в язык


M>> осторожно! Можно ведь и захотеть декодер mpc поиметь встроенный в язык


M>Пусть будет


M>> Ограничивать себя в сладостях надо


M>Зачем?

как зачем? потом устраивают флуд на тему "почему в винде только ИЕ встроен".
Встрой туда кодек mpc тут же начнутся вопли "почему такой, почему не другой, где свобода выбора"
Re[12]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 14:58
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>"Контракт" подразумевает соглашения о побочных эффектах


Занавес. Апплодисменты.
Re[10]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 16:32
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.


C>>ЧТД.


ГВ>int != double. Потому int — маздай, а double — рулит. Сила слова, да.


Садитесь — два.

Целые числа и числа с плавающей запятой это разные понятия. Строка это одно понятие, а уж ANSI она или Unicode — детали реализации, которые у С++ в виду примитивизма языка торчат наружу.
Re[15]: Неясно сформулировал
От: criosray  
Дата: 01.06.09 18:12
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

C>>>А строки "они и в африке" строки.


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


ГВ>Собственно, самое главное — строки в "общечеловеческом" смысле в принципе не могут совпадать со строками в "компьютерном" смысле.


Тип может совпадать (конечно же) и совпадает. Примером тому c#, java, python, ruby — и другие нормальные языки.

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


И снова Вы говорите не о типе, а о реализации. Тип строка — один единственный. Точка.
Re[17]: интефейс и контракт...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 20:09
Оценка: +2
Здравствуйте, criosray, Вы писали:

E>>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:
struct IOrder {
E>>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>>};

C>Да, это вполне корректный интерфейс, хотя и костыль, т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.

А кто сказал, что интерфейс должен содержать только абстрактные методы? Чем не абстрактные методы противоречат "интерфейсу"?

E>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

C>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?

При том, что эти утверждения — неотъемлемая часть интерфейса, которую могут (и должны) учитывать его пользователи.

E>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...

C>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.

Контракт формулируется для интерфейса, а реализуется — реализующим интерфейс классом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 21:43
Оценка: -1 :)
Здравствуйте, NikeByNike, Вы писали:


C>>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.

C>>А строки "они и в африке" строки.
NBN>Да-да-да
NBN>А что творится айфоне?
И что же творится в айфоне?

NBN>А с китайским языком знаешь какие приколы бывают?

Нет, расскажите.

Не вижу ни одной причины почему нельзя было бы обойтись одним единственным типом string как в нормальных языках, вместо того, чтоб плодить вагон и маленькую тележку кривых классов, как в С++.
Re[9]: За что я не люблю С++
От: 0xC0000005  
Дата: 02.06.09 05:51
Оценка: -1 :)
Здравствуйте, criosray, Вы писали:

C>>я могу сказать что С++ для тебя это Си с классами(если помнишь), и обсуждать темы такого порядка ты может только на уровне "Мне это не нравится и ВСЁ".

C>По сути что можете сказать?
C>Хотите услышать чем вариант дотнет лучше шаблона из Вашего примера?
C>Тем, что ошибка будет указана прямо в редакторе во время набора на строке f<B>(), где B — класс, не реализующий интерфейс, а в С++ только во время компилляции будет выдана ошибка при чем совсем в другом месте — на вызове
C>t.f() — будет указано, что класс B НЕ имеет метода f().

Это проблема языка или IDE? Я работал под расширениями емакса, которые производят все операции проверки шаблона в редакторе, так что это далеко не проблема языка, а среды разработки.

C>>Что за цитаты, примеры кода? Приведи реальный пример когда из-за кривизны языка, а не программера получаются неявные ошибки не описанные и заранее не продуманные в языке.

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

Жаль что моя идея не дошла, наверно сильно завернул, под ошибками языка, которые приводят к неявным проблемам, но для которых есть "обходы" я называю к примеру множественное наследование приводящее к брилианту смерти, в С++ это обходится виртуальным наследованием, в управляемых языках запретом имплементации в "виртуальных" базовых классов, и кто вам сказал что интерфейс это и есть контракт? Интерфейсом можно описать часть контракта, по вашему это называется "Костыль", а что такое на самом деле контракт в шарпе и какие утилиты используются для полного цикла использования контракта почитайте у мелкомягких:
http://research.microsoft.com/en-us/projects/contracts/
Re[10]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 06:40
Оценка: -1 :)
Здравствуйте, 0xC0000005, Вы писали:

C>>>я могу сказать что С++ для тебя это Си с классами(если помнишь), и обсуждать темы такого порядка ты может только на уровне "Мне это не нравится и ВСЁ".

C>>По сути что можете сказать?
C>>Хотите услышать чем вариант дотнет лучше шаблона из Вашего примера?
C>>Тем, что ошибка будет указана прямо в редакторе во время набора на строке f<B>(), где B — класс, не реализующий интерфейс, а в С++ только во время компилляции будет выдана ошибка при чем совсем в другом месте — на вызове
C>>t.f() — будет указано, что класс B НЕ имеет метода f().

C>Это проблема языка или IDE? Я работал под расширениями емакса, которые производят все операции проверки шаблона в редакторе, так что это далеко не проблема языка, а среды разработки.


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

C>>>Что за цитаты, примеры кода? Приведи реальный пример когда из-за кривизны языка, а не программера получаются неявные ошибки не описанные и заранее не продуманные в языке.

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

C>Жаль что моя идея не дошла, наверно сильно завернул, под ошибками языка, которые приводят к неявным проблемам, но для которых есть "обходы" я называю к примеру множественное наследование приводящее к брилианту смерти, в С++ это обходится виртуальным наследованием, в управляемых языках запретом имплементации в "виртуальных" базовых классов, и кто вам сказал что интерфейс это и есть контракт? Интерфейсом можно описать часть контракта, по вашему это называется "Костыль", а что такое на самом деле контракт в шарпе и какие утилиты используются для полного цикла использования контракта почитайте у мелкомягких:

C>http://research.microsoft.com/en-us/projects/contracts/
Вы что же совсем не понимаете разницы между interface as contract и между code contracts?

Действительно, спорить мне с Вами не о чем.
Re[17]: За что я не люблю С++
От: 0xC0000005  
Дата: 02.06.09 09:43
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, 0xC0000005, Вы писали:



C>>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:


C>>

C>>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


C>>Потом вы пишете


C>>

C>>А никто и не утверждал, что интерфейс является полным контрактом класса


C>Почему Вы упорно не желаете читать дальше первого предложения?


C>Читайте и перечитывайте пока до Вас не дойдет смысл сказанного:



C>

C>Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе


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

И ну хватит ответов в стиле вы недочитали, я писал так, я писал сяк, потому-что ваши изречения противоречят друг другу, к примеру "Интерфейс это чисто контракт" и "Я не писал что интерфейс это контракт".

И просьба — либо ответ на поставленный вопрос и потом ваши аргументы, либо не пишите вообще и будем считать что мы друг друга не понимаем.
Re[18]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 09:54
Оценка: :))
Здравствуйте, 0xC0000005, Вы писали:

C>Вы нагло увиливаете от прямого ответа, грубите итп, у меня закрадывается мнение что с вами лучше не вести такие беседы.

Нет, это Вы не способны прочитать один маленький абзац где я объясняю, что:
1. Интерфейс — это контракт класса.
2. Полный контракт класса состоит из совокупности всех контрактов класса — все интерфейсов-контрактов, всех код-контрактов.

Вам по прежнему не понятно? Тогда я умываю руки — если человек не может сложить в уме 2 и 2, и получить в результате 4, то что-то объяснять ему — пустая трата времени.
Re[17]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 10:02
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

E>>Ну и так далее...

S>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>0. Они не immutable.
S>1. Они слишком сильно сосредоточены на бинарном представлении.

Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:
const std::string &str = string(src);


А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder. Лично мне, как пользователю, больше нравится С++ подход, когда константный и не констатный интерфейсы реализуются в одном классе (для произвольного объекта), и доступность/недоступность того или иного интерфейса определяется спец модификатором при определении объекта. Хотя, конечно, здесь все тоже не очень гладко.
Re[19]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 10:31
Оценка: +2
Здравствуйте, criosray, Вы писали:

C>Это совсем не то. В данном случае запрещено вызывать методы над этой строкой.

Неа. Запрещено вызывать методы, меняющие эту строку.

C>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

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

C>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:

C>var str = "abc";
C>var str2 = "abc2";
C>ссылаются на один и тот же участок памяти str == str2 true.
Эээээ....
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[18]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 10:52
Оценка: +2
Здравствуйте, Игoрь, Вы писали:

И>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:

И>
И>const std::string &str = string(src);
И>


И>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.

Не стоит мерить дотнет мерками C++.
String и StringBuilder имеют принципиально разное поведение, которое не сводится к запрету вызова неконстантных мемберов. В частности, у них разная трактовка идентичности.
Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
И>Лично мне, как пользователю, больше нравится С++ подход, когда константный и не констатный интерфейсы реализуются в одном классе (для произвольного объекта), и доступность/недоступность того или иного интерфейса определяется спец модификатором при определении объекта. Хотя, конечно, здесь все тоже не очень гладко.
Совершенно верно. Не очень гладко — это еще слабо сказано.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 12:02
Оценка: +1 :)
Здравствуйте, Игoрь, Вы писали:
S>>Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
И>Например, и почему эти алгоритмы нельзя сделать эффективно на С++?
Например потому, что придется делать по две версии алгоритмов — на случай передачи в них константной строки, и неконстантной строки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 02.06.09 12:07
Оценка: +2
Здравствуйте, criosray, Вы писали:

CC>>Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?

C>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).

а как оно узнаёт, что строки таки одинаковые? Зависит ли эффективность этого поиска от того, сколько строк одновременно хранится в программе или в системе?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[23]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 02.06.09 12:08
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

C>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.

Ты не поймёшь. Но если ты всё-таки готов напрячься и понять, то почитай исходники CString из MFC, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 02.06.09 12:19
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

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

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


S>В строках С++ сделано сразу несколько принципиальных ошибок:

S>0. Они не immutable.
Ну и что? Зачем это вообще надо? Для того, чтобы удобно было switch по строкам писать? Это же редкая очень нужда! На кой нужно обеспечивать уникальность каждой из строк? Ну нужно тебе в каких-то алгоритмах, ну пользуйся такими строками в тех местах, хотя, IMHO, логичнее было бы сделать какую-то в обобщённом смысле аддитивную хэш-функцию и хранить хфши кусков строки, а не искать те же строки среди всех существующих в памяти...

S>1. Они слишком сильно сосредоточены на бинарном представлении.

Да ладно тебе. Чем это std::basic_string<wchar_t> -- не цепочка юнкодов?
Просто весь STL "слишком сосредоточен на подробностях реализации", и при этом ещё умудряется почти ничего из их не гарантировать Ну да это вопросы к авторам и приверженцам STL, а не к кому-то или чему-то ещё...
Есть куча менее кудрявых библиотек та же QT, например...

S>Строки дотнета тоже не лишены недостатков, но об этих недостатках дефолтным строкам стандартной библиотеки плюсов еще приходится только мечтать.

Тема того, что перечисленные обстоятельства -- недостатки не нраскрыта. А вот то, что в std::basic_string можно хранить не только юникод -- это, IMHO, РЕАЛЬНЫЙ ПЛЮС...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 12:21
Оценка: :))
Здравствуйте, CreatorCray, Вы писали:


C>>>>Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.

CC>>>Не, ну это уже оголтелый фанатизм, иначе уже и не назовешь.

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

CC>Ты до сих пор не доказал что она плохая.
CC>В С++ можно заимплементить какие угодно строки.
CC>То, что в STL есть какая то обобщенная реализация строки имеет отношение к библиотеке STL а не к языку С++.
CC>Благо STL в компилер не встроен, тьфу тьфу тьфу.

Так и есть — в С++ зоопарк глючных, несовместимых реализаций строк. А в исходниках каша из std::wstring, CWSTRPTR (spelling), CString, QString, wchar и десятков аллиасов.
Re[24]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 12:58
Оценка: :))
Здравствуйте, CreatorCray, Вы писали:


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

CC>Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.

Все дело именно в таких вот мелочах.

Кстати, а С++ уже научился nullable типам?

int? a = null; // nullable
a = 1;
bool? b = false; // nullable

...


Re[25]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 13:29
Оценка: +1 -1
C>Кстати, а С++ уже научился nullable типам?

int* n = null;


Нашел чем гордиться
Re[26]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 14:01
Оценка: :))
Здравствуйте, alexey_ma, Вы писали:

C>>Кстати, а С++ уже научился nullable типам?

_>Нет, А нафига?
Потому, что удобно и временами банально необходимо.
_>Но в принципе можно поизвращаться и научить
_>Class nullable
Не сомнваюсь, что можно поизвращаться. С++ идеальный язык для того, чтоб извращаться.
Re[4]: За что я не люблю С++
От: WolfHound  
Дата: 02.06.09 14:32
Оценка: -1 :)
Здравствуйте, jazzer, Вы писали:

J>Там в полный рост зоопарк компиляторов.

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

J>Имхо, это совершенно некритично, и никто не мешает к этому чистому контракту привернуть пару невиртуальных функций — это никак на чистоте контракта не скажется, так как то, что было чисто виртуальным, им и останется.

Не согласен.
В принципе можно иметь реализацию по умолчанию но возможность перекрытия должна быть в обязательном порядке.
Иначе могут быть проблемы связанные с тем что конкретную реализацию таки не устраивает реализация по умолчанию.
Именно по этому вообще любое наследование реализации зло.
Одним из приемлемых вариантов было бы что-то вроде этого:

interface Iface1
{
...
}
interface Iface2
{
...
}

mixin Iface1Impl
  implements Iface1
{
...
}

mixin Iface2Impl
  implements Iface2
  required Iface1
{
...
}

class SomeClass
  implements Iface1
  implements Iface2
  aggregate Iface1Impl
  aggregate Iface2Impl
{
...
}

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

J>+1. Но это спор не о языках, а о библиотеках.

Скажи это 0xC0000005

J>+1. Макросы Немерле было бы очень здорово поиметь в плюсах. Много проблем бы сразу ушло.

Макросы немерла имеют своих тараканов. А именно они совершенно не формализованы и осень сильно подвязаны на конкретную реализацию конкретного компилятора.
Но этот недостаток можно устранить.
Правда серьезной переработкой языка и компилятора.
Но не до конца. .NET собака такая под ногами со своей кривостью путается.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 05:15
Оценка: -1 :)
Здравствуйте, CreatorCray, Вы писали:
C>>Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?
CC>Это у тебя они все immutable. А реальный мир прекрасно живет и с mutable и c immutable строками.
Реальный мир имеет дело с двумя принципиально разными видами "строк".
Одни из них имеют value-type семантику, и, естественно, неизменны и постоянны.
Другие имеют семантику ref-type, и занимаются построением текстов.
В С++ по давней традиции, смешивают две эти сущности в одну. Итоговый результат одинаково плохо выполняет обе задачи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 03.06.09 22:22
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>Мало того, поскольку традиции разделения примитивов в С++ нет, то и "недефолтные" реализации в массе своей страдают от всех недостатков "дефолтных". Смотреть, например, в класс CString. К сожалению, этот подход обеспечивает бесполезность написания хороших "недефолтных" реализаций — они будут замкнуты в своём мирке. К примеру, нельзя опубликовать библиотеку строковых алгоритмов, оптимизированных под иммутабельные строки — они не будут нормально интероперировать с другими библиотеками.


1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п.
Тем более, что никаких принципиальных трудностей на этом пути нет...

2) Хотелось бы понять, чем строка отличается от числа. Почему числа могут представлять сами себя и иметь модифицирующие себя же операторы, а строки -- нет? Что этому препятствует? Эффективность? Какая-то особенность семантики строк? Что-то ещё?

3)Должны ли, кроме строк, ещё и массивы букв иметь иммутабельную семантику? Если да, то почему это не так в большинстве языков, во всяком случае? Если нет, то в чём принципиальная разница между массивом букв и строкой?

А то ты всё каким-то декларациями кидаешься, что что-то там убогое, а что-то не убогое. А это как-то не убеждает. Скорее похоже больше на то, что изменяемые строки в твоём любимом языке просто не смогли эффективно реализовать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[29]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 04.06.09 04:41
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

Чтобы не дробить обсуждение, я сразу на оба отвечу...

E>>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п.

E>>Тем более, что никаких принципиальных трудностей на этом пути нет...
G>Есть, причем офигеть какие.
G>1)Совместимость. Даже если сделать immutable-строки, все равно во многих местах понадобится передавать char*. Если этот char* отдавать из внутреннего буфера, то попа ибо от иммутабельности ничего не останется. Если копировать, то перфоманс просядет заничтельно.
Зачем куда-то передавать сhar*, и как C# этого удаётся избежать? Если речь идёт об API, то там обычно входные строки именно const char*... Просто иногда С-шные хедеры декларируют функции без const, но это не является содержательной проблемой. Можно, например, написать к нужному API обёртки...

G>2)Управление памятью. Если выполнить a = b + c для строк, то кто будет освобождать b и с? Повесить все это на shared_ptr — тормоза начнутся похлеще .net_овсих

Почему? Можно же не в shared_ptr всё засунуть, а в аналог imtrusive_ptr...

G>Где такую траву берешь? Какие у чисел возожности по модификации себя? Ты разыве можешь написать 1.setBit(4)?

1 -- это литерал. Литералы иммутабельны по своей семантике. Строковые литералы тоже иммутабельны. Скажем "мама".clear() ты тоже написать не можешь. А если число не литерал, а неконстантная переменная, то ты можешь написать так:
int i = 1;
i |= ( 1 << 4 );


G>В том то и дело что в большинстве программ строкам нужна семантика значений, как у чисел. Только в малом проценте нужна семантика массива.

В STL std:vector требует семантику значения (это как у чисел) от своих элементов, и сам, в свою очередь, имеет такую семантику. Так, например, возможен вектор векторов.

E>>...Если да, то почему это не так в большинстве языков, во всяком случае?

G>Не недо показвать свою безграмотность. В некоторых языках...
Ну если под безграмотностью ты понимаешь неумение читать, то да, не надо.
Кста, в С++ нет проблем задавать строку в виде списка. Мало того, stl::basic_string не обязана хранить строку в массиве... Просто таких реализаций stl нет, я думаю потому, что они не нужны...

G>...строки ассоциируются не с массивами, а с immutable списками. Ты же смотришь на строки только как на массивы байт.

Да нет, я вообще не вижу разницы между списком и массивом. Если тебе список букв милее, пусть будет список. Любой контейнер для хранения ПОСЛЕДОВАТЕЛЬНОСТИ элементов годится. Мы же о семантике говорим вроде, а не о чём-то ещё? Какая тогда разница, как именно это реализовано?

Итак, нужно ли требовать иммутабельности от любой последовательности букв? Если да, то почему не требуют? Если нет, то чем строка так отличается от последовательности букв?

S>Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.

Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ... А что, смогли что ли?
Кста, по поводу того, что про сценарии со строками мы знаем намного больше чем про сценариями с последовательностями букв -- хотелось бы поконкретнее этот тезис чтобы был развёрнут! А то как-то не понятно что мы такое знаем про строки, чего про последовательности букв не знаем... ПОЧЕМУ нужны иммутабельные и нет строки, но НЕ НУЖНЫ иммутабельные последовательности букв?

E>>Если нет, то в чём принципиальная разница между массивом букв и строкой?

G>Огромная разница.
S>от этого есть реальная польза. И во фреймворках, разработанных после С++, такое разделение уже существует пятнадцать лет.

Как-то вы ребята исключительно неконкретны...
Если gandjustas хотя бы попробовал привести пару доводов от чего иммутабельную строку якобы нельзя создать на С++, то второй собеседник ограничивается исключительно декларациями и отсылками к весьма бессмысленным, IMHO, документам.
Например я могу назвать фреймворк, который был разработан после появления С++ и строки там мутабельные, так же как и числа: MFC, STL, ATL, QT... хватит?

Вы можете таки ответить конкретно:
Преимущества такие: раз, два, три.
Отличие по семантике от последовательности букв (списка, массива, верёвки, очереди и т. д.) состоит в том-то и том-то, из чего следует нужда в иммутабельности.
Отличие по сеантике значения от чисел такие: раз, два, три...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[30]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 07:00
Оценка: +2
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Игoрь, Вы писали:


И>>Можно чуть короче, явно не делать проверку на NULL:


И>>
И>>int* p = NULL;
И>>int a = 1, c = 10;

И>>int b = (p? *p : c) / 100;
И>>


C>То есть ради такой єлементарщины надо вводить доп. переменную?

Так это для наглядности. На самом деле вместо указателя можно изпользовать address-of operator — & для конкретной переменной. Просто такой код не имееет смысла в С++, поскольку адресс переменной не бывает нулевой. Я вообще-то склонен согласиться с Игорем что кода вида
int* n = null

вполне достаточно , а бустовые затыки типа nullable нужны для решения проблем с использованием умных указателей( которые могут принимать нулевое значение) в контейнерах. Я бы в таких случаях вместо затык порекомендовал бы пересмотреть дизайн.
Давайте посмотрим на nullable с другой точки зрения, я думаю что nullable в С# это как вы говорите, "костыль", из-за того что в C# нет типа указатель на что-то, а в плюсах есть (даже со своей адресной арифметикой), следовательно в плюсах nullable не особенно нужен. Обойдемся как нибудь проверкой указателя на null.
Re[15]: про старые проекты и переписывание
От: Pavel Dvorkin Россия  
Дата: 04.06.09 07:48
Оценка: +2
Здравствуйте, gandjustas, Вы писали:

G>>>До SQL Server дойдет нескоро.


До Office, BackOffice, IIS,... тоже нескоро

G>>>Другие вендоры вряд ли решаться выкинуть существующий codebase.


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


Вот с этим хочу поспорить.

Переписывание переписыванию рознь. Зависит о того, что с помощью этого переписывания можно получить.

Мозилла/Netscape в свое время полностью переписала свой броузер и mail клиент. Модифицируя и модифицируя свой старый Netscape Navigator от 2.0 к 4.x, она довела его до полной невменяемости, выбросила наконец и переписала заново. Многие оценили этот шаг как самоубийственный, но теперь-то всем ясно, что это было правильное решение.

Если есть серьезные причины для переписывания — перепишут, будьте спокойны. Как в свое время переписали программы с DOS на Win16, а потом с Win16 на Win32. Необходимость и того и другого была совершенно очевидна, а выгоды от такого переписывания тоже достаточно ясны. Проще сказать, надо было. И сделали.

И если Win64 пойдет всерьез — перепишут под Win64. Но не все, а только то, для чего профит от такого переписывания будет. Остальным жить под WOW64.

А переписывать на .Net — не надо. Потому что никакого серьезного профита от этого не получится. Поэтому и не переписывают.
With best regards
Pavel Dvorkin
Re[19]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 08:12
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

И>>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.

WH>Этот огород исключительно из-за того что мелкософты не осилили эффективную реализацию строк.

А до них Sun в Java тоже не освоила, так ? Не осваивается оно...
With best regards
Pavel Dvorkin
Re[20]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 08:35
Оценка: +1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

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


И>>>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.

WH>>Этот огород исключительно из-за того что мелкософты не осилили эффективную реализацию строк.

PD>А до них Sun в Java тоже не освоила, так ? Не осваивается оно...

Точно. Универсальное редко бывает максимально эффективным. Возможно что лучше иметь несколько алтернативных реализаций.
Re[23]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 08:46
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

Можно я свои 3 копейки добавлю ?

S>Да-да, вы как раз вносите путаницу. Конечно же, алгоритм, заложившийся на константность объекта, никак не сможет работать с неконстантым. Например, из константности мы можем вывести возможность не делать блокировок при обращении; можем полагаться на то, что хеш будет неизменным; много на что еще можем полагаться. Неконстантность ничего этого не даёт, поэтому алгоритмы на С++ невозможно оптимизировать подобным образом.


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

Что такое иммутабельность, в конце концов ? Грубо говоря, это порождение констант в рантайме. С++ этого не умеет. Java и C# умеют, но только для типа string. Как только мы попробуем развить идею иммутабельности для любых классов, так мы сразу придем к задаче, примерно эквивалентной работе GC — проверке на каждой операции, не достижим ли данный объект из какого-нибудь иммутабельного объекта. string слишком прост, поэтому для него такое возможно, в нем нет вложенных объектов.

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

С другой стороны, необходимо ответить на вопрос — насколько часто придется все же менять эти иммутабельные объекты. Я не оговорился, слово "менять" я понимаю здесь в широком смысле, то есть создавать их измененные версии, независимо от того, как именно. Если объекты не являются иммутабельными, то во многих случаях эти изменения можно делать inplace (примеры — преобразование к иному регистру, замена символа на другой, реверс). Если объект является иммутабельным, то эти действия приходится выполнять с помощью создания нового объекта, нового string в конечном счете, опять же иммутабельного.

Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.

Так что истина конкретна. Иногда это хорошо, иногда нет. Но то, что в Java/C# это есть, а в C++ — нет — в общем-то, плюс этим двум языкам.
With best regards
Pavel Dvorkin
Re[32]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 08:46
Оценка: :))
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хм. А в MSDN я вот такое увидел


PD>fixed (char* p = str) ... // equivalent to p = &str[0]

Угу. Это ансейф, и он по умолчанию запрещен.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 08:53
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

S>Угу. Это ансейф, и он по умолчанию запрещен.


Перефразируя не помню уж кого, скажу, что между "запрещен" и "по умолчанию запрещен" разница такая же, как между государем и милостивым государем
With best regards
Pavel Dvorkin
Re[31]: А теперь забань себя сам!
От: Erop Россия  
Дата: 04.06.09 09:11
Оценка: +1 -1
Здравствуйте, Sinclair, Вы писали:

E>>Зачем куда-то передавать сhar*, и как C# этого удаётся избежать?

S>В C# char* запрещён.
Очень хорошо и я рад за него.
А как стронние API-то вызывать при этом предлагается? Может быть всё-таки не совсем таки запрещён?
S>Речь идет о реальных библиотеках и реальном API. Эти гигабайты кода никто не будет оборачивать и переписывать.
А как же их вызывать из С#, если таки const сhar* запрещёно, а в "гигабайтах кода" в интерфейсных функциях довольно таки популярен?

S>Правильно. А почему можно сделать std::string("мама").clear()?

А почему нет? Это всего лишь вопрос к тому, как в языке устроены переменные, выражения и их взаимодействия...
Вообще не понятно, чем такое выражение
std::string("мама").clear()
вредно? Ведь такое:
std::string str( "мама" );
str.clear();
написать можно? А первое это несколько сокращённая запись второго и всё...

S>Давай посмотрим на такой же пример со строками:

S>
S>var i = "hello";
S>i += " world";
S>

S>Здесь фигурируют три строки. Сначала i указывала на строку "hello", потом была создана новая строка (путем конкатенации двух строк), и i стала указывать на эту новую строку. Сама строка "hello" (байты, на которые указывала i вначале) никак не поменялась. Это и есть семантика value-типа: значение измениться никак не может.
Ты зачем-то путаешь объекты, существующие только у тебя в голове ("заранее сконструированные числа", "значение строки") и их представление в памяти ЭВМ. Первые меняться не могут, а вторые очень даже... В С++ для того, чтобы ограничить какую-то переменную, хранящую неизменное значение, так, чтобы оно реально не могло меняться, можно использовать QV-квалификатор. В C# оказалось органичнее заиметь для этой цели другой тип. Ну и что? Это же только мелкие подробности реализации организации такого ограничения на операции с ПЕРЕМЕННОЙ. И всё. В каждом языке это делают так, как там удобно. В С удобно просто расставить модификатор const у нужных методов, а в C# приходится иметь два класса. Ну и хорошо. Пусть себе приходится. Зато там другие преимущества есть. Но ты, если я тебя верно понял, пока спорил вменяемо, утверждал, что наличие двух строк -- иммутабельного "значения" и некой фабрики по производству таких значений, это более правильно и удобно... Вот этот тезис очень странен для меня. И почему для операций с плавающей точкой нам неудобно использовать какой-то FPU_calculator, а для операций со строками -- якобы удобно StringBuilder...
Ты писал, что фишка в том, что создание копии строки дорого стоит, ну так это тогда всё в неэффективность мутабельной строки в С# упирается выходит? Потому, как в С++ удобно и легко получается COW и нет никаких мегапроблем. А для константных строк тоже нет проблем...

S>Ты, по-видимому, не понимаешь, что такое "семантика значения".

S>Да, мутабельных чисел нет нигде. Учите матчасть — это value типы. И думайте головой.
Ну я предлагаю не спорить о терминах. В данном контексте "семантика значения" -- это было ровно то, что std::vector требует от своего элемента... (иммутабельность, если ты не в курсе, не входит...)

S>Это замечательный подход. Он гарантирует тебе, что ничего полезного ты никогда не изучишь. Ты только послушай себя: "раз в С++ нет, значит не надо". Ок, хорошо. Зачем тогда весь этот ритуальный танец вокруг нового стандарта? Ведь если лямбд не было в stl, то они гарантированно не нужны.

Ну я тем, не менее изучаю что-то. Вот и у тебя прошу ПОНЯТНО, объяснить, в чём, С ТВОЕЙ точки зрения так уж хороши иммутабельные строки + билдер?
Пункт 1 -- типа так проще писать многопоточный код. Но многопоточный код, работающий с зашаренными константными данными легко писать и так и этак, поэтому я не совсем тебя понял, почему это преимущество...

S>Не от любой. Есть последовательность букв, которая ведет себя как value — от неё можно и нужно требовать иммутабельности. Если я поместил Иванова на букву И в телефонной книге, пусть он будет любезен оставаться Ивановым.

S>Контракт такой строки вполне известен: от нее можно вычислить хеш, который гарантированно будет совпадать для одинаковых строк (и всегда будет соответствовать содержимому строки); строки можно конкатенировать; можно порождать подстроку.
Ну и что? На С++ эта задача решается легко и непринуждённо. Если уж тебе так надо, чтобы его фамилия не менялась, то делаешь это поле const и всё...
Про хэш там или подстроки -- тем более нет проблем...

S>Но главное в контракте этой строки — гарантия иммутабельности. То что результат произвольной F(s) будет оставаться ровно таким же, до тех пор, пока мы не переприсвоим в s что-то еще.

Ну так и у С++ объекта та же есть особенность. Но тут есть беда, что могут быть сторонние эффекты у F(s)...
Но ПРИ ЧЁМ ТУТ ИМЕННО СТРОКИ? Это же с любыми данными может быть?

S>Ок. Это примерно как я бы наезжал на C++ "не смогли эффективно реализовать работу с данными, не разделяя их на строки и числа".

Да не смогли. А вот в перле, например, смогли...

S>Мутабельная и иммутабельная строка — разные контракты.

CString и const CString -- тоже...
Тебе в дизайне С++ строк не нравится то, что с константной строки можно легко получить неконстантную копию? Ну это же легко закрывается, если кому-то такое РЕАЛЬНО НУЖНО... А больше отличий как-то нет. Ну ещё копировать мутабельную С++ строку можно так же хорошо, как и иммутабельну. Но разве это недостаток, с которым нужно бороться?

S>Мы знаем, что строкам не нужно изменение по месту. Что если я сконструировал объект WebRequest(string url), то он может и будет полагаться на неизменность переданного адреса вплоть до вызова GetResponse().

Так пусть копирует ОБЪЕКТ строка себе и будет уверен. А как там разрулить копирование и владение буферами -- это пусть сам объект разбирается...
Но я всё равно не понимаю, ни почему не нужно, ни чем это от любого другого типа данных отличается?

E>>ПОЧЕМУ нужны иммутабельные и нет строки, но НЕ НУЖНЫ иммутабельные последовательности букв?

S>Что такое "иммутабельная последовательность букв"?
Последовательность букв, которую нельзя менять, очевидно...

S>Ок. Эти документы окажутся осмысленными, когда у читателя вырастет нужный опыт — я думаю, что это связано не с количеством извилин, а исключительно с кругозором. Ну ты вроде тут модер? Правила своего форума знаешь? Вот и оставь свои мысли о моём кругозоре при себе... Ну чиста, чтобы не нарушать твои же правила...

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

E>>Например я могу назвать фреймворк, который был разработан после появления С++ и строки там мутабельные, так же как и числа: MFC, STL, ATL, QT... хватит?

S>Юноша, stl — это часть стандарта С++. До него вообще никаких строк в С++ не было. Ну стандарты С++ выходят время от времени. Который из них ты считаешь за "появление С++" я не знаю. Зато знаю кучу С++ кода, написанного и даже проданного задолго до 1998-го года...
Я там выделил какие фреймворки ты указал, в качестве образца ("который был разработан после появления С++")...
AFAIK STL появился после MFC, и уж подавно после С++...
Кстати, в МFC тех лет какие-то строки уже были...

S>В MFC строки — вообще кошмар проектировщика. Я уже писал в этом форуме другим упёртым фанатам — например, на тему втискивания внутрь строки всех сервисных методов, которые должны быть снаружи.

Это как-то связанно с вопросом об имуутабельности или с тем, что MFC появилась после С++?

S>В QT тут, как вроде только что писали, строки иммутабельны. Врут?

Ну врут обычно те, кто не интересуются первоисточниками... Смотри: QString и QConstString.
Насколько я понял, что именно ты понимаешь под "иммутабельностью" всё сделано мутабельно.
И совсем не так, как в С#...

S>Собственно, основной подвиг дотнета по отношению к строкам — то, что разработчики сделали так, чтобы строки вели себя как числа.

IMHO уже std::string ведут себя как числа, так же как и complex<double>, например...

S>Юноша, stl — это ... И думайте головой.

Ты вилимо не Юноша, да?
Я подозреваю, что я старше тебя...
Поэтому либо извинись, либо забань себя сам.
А разговаривать с человеком, который сам допускает нарушение своих же правил и сам потом банит собеседников, когда сказать ничего не может -- это себя не любить...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[32]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 04.06.09 09:55
Оценка: +2
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>В бусте как раз есть optional<T> (и умные указатели здесь не причем), и его семантика ближе к Nullable в C#, чем к указателям в С++:


Он конечно есть, но, IMHO, не так чтобы совсем-совсем необходим.
Тем не менее, это ещё раз демонстрирует, что если концепция не является совсем уж бесполезной, то её обычно реализуют как-то и в С++ библиотеке какой-нибудь
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: За что я не люблю С++
От: WolfHound  
Дата: 04.06.09 11:05
Оценка: -1 :)
Здравствуйте, jazzer, Вы писали:

J>Ну, если ориентироваться только на нормальные компиляторы, то костыли эти достаточно прямые и простые,

Да хоть на какие ориентируйся. Все равно все страшно.
Я как бы сам все видел и даже писал.

J>Но главное то, что все это внутри библиотеки и пока тебе не понадобилось туда нырнуть, пользоваться библиотекой легко и приятно и зоопарка под капотом не видно. И, имхо, то, что на таком старом языке можно написать библиотеки уровня Boost.Fusion и Boost.Proto, говорит только в пользу этого языка.

Почитал. Но так и не понял на кой черт это нужно.
Что оно может такого что не может нормальный функциональный язык с нормальным оптимизатором?

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

Каким местом она чуждая?
Какие проблемы дать пройтись по классу во время компиляции?

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

Их проблема в том что они изначально толком не проектировались.
Ковбойский подход "ЙО! Я тут классную фичу придумал! Айда добавим!" никогда ни к чему хорошему не приводил.

J>Конечно, она в том или ином виде будет добавлена в язык, но в каком именно — это большой вопрос, которым нужно заниматься, а на это у комитета банально нету времени, потому что гораздо больше народу требуют многопоточности и сборки мусора (последнюю так и не успели вставить в С++0х).

Многопоточность это полезно.
А вот сборка мусора нет. Ибо мусорщик должен быть либо точным либо никаким. А в С++ точный не сделаешь. Ибо прямой доступ к памяти и прочие радости.

J>Так она и есть, или я тебя не так понял.

J>Плюс контракт — это гораздо более широкое понятие, чем интерфейс. И в этом смысле класс С++ подходит для выражения концепции контракта лучше, чем просто интерфейс, потому что интерфейс редуцирует контракт до набора (причем фиксированного!) функций, что не всегда оправдано.
Чтобы задать контракт в широком смысле этого слова нужна система типов с зависимыми типами.
А это уже мягко говоря другой уровень проектирования языка.
http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.Documentation

J>В С++ наследование — это не только наследование в классическом понимании ООП.

J>Там, например, наследуются типы/тайпдефы, и тому подобное. Вспомни CRTP хотя бы.
Тем хуже для С++.

J>Это можно и сейчас dynamic_cast-ом сделать.

Что это?

WH>>К миксину привести нельзя.

J>Почему? В чем смысл такого ограничения?
По тому что SRP никто не отменял.
Реализация отдельно. Контракт отдельно.
Интерфейсы это контракт. По крайней мере та его часть которую дает формализовать язык.
Миксины это чистая реализация которую в конкретном классе можно использовать, а можно и нет.

J>А чем тебя не устраивает подход ATL/WTL?

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

J>И если да и если ты хочешь собрать свой класс из вот таких вот частичных реализаций, ты разве не поимеешь все проблемы множественного наследования, которые есть сейчас?

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

J>А если нет — так уж ли оно полезно, если вспомнить про какой-нть интерфейс OLE-объекта с 53 функциями?

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

J>О чем и речь

О чем?

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

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

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

Грабля там ровно одна: Отсутствие формализации.

WH>>Но не до конца. .NET собака такая под ногами со своей кривостью путается.

J>Прям как в С++
Ага. .NET как и С++ тоже никто не проектировал, а чисто навояли как придется.

J>Ну, в общем, как я и говорил энтузиастам дотнета сколько-то там лет назад ("У вас тяжкое наследие, а у нас все свежее и необремененное" — "Ничего, поговорим лет через 10"), как мы скрипим от унаследованных недостатков С++, так и явисты/дотнетчики заскрипят, когда осознают, что их новые свежие языки-платформы неидеальны, и не упрутся в их пределы и в никуда не девшиеся требования совместимости с существующим кодом (а в случае явы/дотнета — еще и с существующим байт-кодом).

Не осознают также как и С++ники.
Для того чтобы это понять нужно знать намного больше чем собственную песочницу.

J>А особенно когда еще через лет появится какая-нть модная технология, про которую все будут говорить: "Это must have, она должна быть в любом нормальном языке по умолчанию, все остальные на помойку!"

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

J>(как сейчас с рефлексией, сериализацией и т.п.) а явисты/дотнетчики будут чесать репу, понимая, что на их языках невозможно по-человечески эту фичу реализовать, потому что она не будет ни с чем совместима и сломает язык.

Ты удивишься что можно реализовать на .NET'е и жабе.
Там же код во время исполнения можно генерировать... а значит можно реализовать ВСЕ!

J>Так что у С++ есть свой хорошо известный набор проблем, есть не менее хорошо известный (и зачастую вполне удобный) набор средств по их устранению/недопущению/предупреждению, и профессиональные программисты вполне комфортно себя чувствуют, хотя это и не значит, что они не будут приветствовать усилия комитета по уменьшению этого набора.

Проблемы С++ столь ужасны что их можно решить только выкинув С++ на свалку.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 11:45
Оценка: -1 :)
Здравствуйте, alexey_ma, Вы писали:
_>Ясень пень что не решают, но иногда помогают. Разговор вроде был о возможности выбора оптимальной реализации строк в зависимости от задачи и о проблемах интеграции. Так вот, когда я из хука лезу в Сlarify11 (он почему-то написан на MFC 7.0) чтобы прочитать там пару строчек из ObjectivGrid я использую СString ( мало того я вынужден компилировать хук с той же версией MFC что и Сlarify — иначе не работает), если работаю с CОМ — использую BSTR и т.п — так понятно?
Нет, непонятно. Я не понимаю, что там делается внутри Clarify и каким боком тут вид строки, но вот про BSTR более-менее понятно. Вот в шарпе нет никакого BSTR, но при этом каким-то волшебным образом он интероперирует с COM. Вы не задумывались, почему?


_>Про замечательный интероп шарпа c CОМ на примере ВНО, я полагаю замнем

Можно и замять — мне всё равно. В принципе, на текущем фреймворке реализация in-proc COM серверов для unmanaged хостов — не лучший способ скрасить себе жизнь. А вот в обратную сторону интероп работает просто прекрасно.

S>>Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.

_>Не могу я код показать, но он есть и работает
А что, стеснительность не позволяет?
_>Возможно что подобный код какой нибудь гений может написать и на шарпе , но вряд-ли он будет короче и понятней.
При чём тут гений — это вопросы примитивной технической реализации. В принципе, ничего страшнее platform invoke нам всё равно не светит.

_>Да чего там PowerBuilder, набросайте VB6 апликацию с MSFlexGlig и попробуйте получить из этого грида пару строчек или хотя-бы текст какого нибудь Label тоже из VB6. К сожалению ( или к счастью) мир пока не весь еще дотнет, с дотнетом кстати интегрировться легко.

Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 12:16
Оценка: -1 :)
Здравствуйте, Erop, Вы писали:

E>Ну то есть выражения вида a |= 16 не нужны, и даже вредны?

Ты путаешь объекты и переменные.
Есть объект число. Этот объект не изменяемый.
Есть переменная. Она может быть изменяемая или не изменяемая.

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

Это не возможно.

E>IMHO, разделение на два класса происходит именно оттуда...

Нет.
Они не осилили поискать в интернете эффективную структуру для неизменяемой строки.
И из-за этого тупо клонировали явовский стрингбильдер.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 04.06.09 15:02
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А оно таки всегда надо ? Строки, конечно, могут быть в кэше, кэш доступен из разных потоков, тут нужна потокобезопасность и другие случаи есть. Но если я в своей C/C++ функции завел локальную auto переменную (хоть std::string, хоть char[N]), то к ней все равно никто добраться не может, и почему я должен платить за эту потокобезопасность ? Ну а если уж она нужна, кто мешает обертку в виде thread_safe_string соорудить ?


Ну в случае когда GC нет, ты всё более или мене верно говоришь, но в шарпее есть GC а COW фиг реализуешь, наоборот...
Так что фишка в том, получается, что в до-диезе хоршо одно работает, а в плюсах другое...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[29]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 15:04
Оценка: +1 :)
Здравствуйте, Serginio1, Вы писали:

ГВ>>Так грамотная — это rope или линейный буфер?

S> Все же для разных задач разные алгоритмы. В С# досих пор стандартных Б+ деревьев нет.

Угу, угу.

S>Все что требует частого удаления всавок по аналогии с б деревьями должны иметь такую структуру.

S>Либо буилдер стрингбуилдеров с ограничением на длину стрингбуилдера.
S> Но нелинейность оправдывает себя на больших размеров, и соответсвенно частые вставки и удаления.
S>Все под задачу. Поэтому 3 вида строк вполне оправдано.

О! Итак, ты уже нашёл оправдания для трёх видов строк. Кто больше?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[29]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 04.06.09 19:25
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

C>>Нуу... Для редактора текстов представление строк (буфферов) будет отличаться от обычных коротких строк.

WH>И чем конкретно ропы не подходят для редактора текста?
Для редактора текстов заметно лучше подходят строки с gap-буффером.
Sapienti sat!
Re[34]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.06.09 03:53
Оценка: -1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:
S>>Потому что это не С++ здесь некоторые решения приняты за тебя. В частности, написать свою потокобезопасную строку намного сложнее, чем взять готовую.
PD>Ну это что-то не очень ясное. Готовая отличается от моей тем, что писал ее не я, вот и все. Если это не так, это лишь значит, что МС использует нечто, что не дает мне использовать. Это, кстати, за ней не раз замечалось еще с ДОС времен.
Почему — даёт. Свой стрингбилдер можно запросто написать.

PD>А блоки памяти в большом количестве порожденные все же надо убирать ? пусть по алгоритму GC, но все же надо...

Нет, не надо. Читать RTFM про то, как работает GC. Он не занимается уборкой.

PD>Это твое утверждение можно преобразовать в эквивалентное "сделаем что-то, а потом посмотрим, что из этого получилось". Профалер же не дух святой, а просто средство посмотреть, что в итоге вышло. И не очень хорошо, что нельзя a priory сделать какие-то соображения, а можно только a posteriory смотреть, что вышло.

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

PD>А теперь по существу этой самой иммутабельности. Все же это должно быть свойство не типа , а экземпляра. Экземпляр может быть константой, порождаемой в рантайме, а тип вообще-то не должен. Если нам надо число PI вычислить , то результат должен впоследствии не изменяться, но не потому, что он float или double, а потому что он по смыслу не должен изменяться. А сам тип — не должен быть иммутабельным. Это и к строкам относится.

Нет. Это трагическое заблуждение. Свойство экземпляра даёт слишком мало информации среде исполнения для эффективной оптимизации.
PD>Что же касается решения Java/.Net о константности типов, то это полурешение, со своими недостатками, о которых тут говорили. И со своими плюсами, о которых тоже говорили.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.06.09 03:53
Оценка: -1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Угу. С преобразованием к верхнему регистру для каждого проезжаемого символа.
Включая те, которые вылезли за пределы N. У тебя нелимитированный gets в программе — а это классика buffer overrun. И не говори мне, что реальные программы так не пишут — вот только что ажно преподаватель попросил нас написать аналог именно этой программы на С#. Чего уж тогда от студентов ожидать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[38]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.06.09 10:00
Оценка: +1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Хм... Что такое ссылки наружу — я не знаю, а вот про блоки памяти вроде Рихтер говорит, что он их просматривает, ну и дальше — что именно делает.
Объект может содержать в себе ссылки, а может не содержать. В отличие от С++/native, про все объекты заранее известно, есть ли в них ссылки. В строках — нет. Поэтому "просматривать" их не нужно.

PD>Вот допустим я, отнюдь не гуру в .Net, написал что-то, а быстродействие этого чего-то меня не устраивает. Пустил профайлер — что-то узнал. Как мне это применить для следующей задачи?


PD>Пуд соли я не съел, и не скоро съем. Для C++ все ясно — используешь медленную функцию, поставил не лучший алгоритм N^2 вместо Nlog(N), память выделяешь не оптимально.

Это тебе ясно исключительно потому, что ты провёл сотни экспериментов с С++. Теперь тебе сразу видно — где стоит поменять алгоритм, где заменить аллокатор, а где сразу нужно переходить на MMX и прочую низкоуровневую химию. Для новичка С++ — точно такая же непредсказуемая штука. Типа поставил где-то в неочевидном месте слово const — бах, сразу скорость подпрыгнула на 20%. Почему, отчего — хрен поймешь. Потому что не все могут выполнять в уме частичную специализацию и определять на глаз, где компилятор сможет выкинуть конструктор копирования временного экземпляра.

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

Это неправда.
PD>Нашел bottleneck — определи суть — больше так не делай.
Это неправда.
PD>Не потому, что профайлер показал его, а по определенной сути.
Это неправда.
PD>В принципе я мог бы и без профалера эту суть найти, просто анализом, медленнее, конечно, будет.
Анализом? Это каким? Ну-ка, ну-ка, покажи мне способ при помощи "анализа" за конечное время выяснить, где порылась собака в быстродействии программы на основе того же boost::lambda?

PD>А ты сам говоришь — попробуешь улучшить — чего доброго ухудшишь, пока пуд соли не съешь и эмпирические правила не освоишь. Вот так не делай, не потому что суть этого плохая, а потому что прошлый раз плохо получилось

Я говорю, что суть показывает только профайлер. В современном программировании это именно так уже лет двадцать как. Тот же SQL Server — есть масса факторов, влияющих на производительность запросов. Неопытный DBA может, конечно, на основе прочитанных книжек попытаться угадать план исполнения по запросу, а также прикинуть, какие факторы определяют быстродействие. Опытный DBA сделает это гораздо быстрее — и не потому, что он читал больше книжек, а потому, что наблюдал глазами результат применения различных сочетаний этих факторов на реальных условиях. Этого ни в каких книжках не пишут. Разве что в блогах иногда. Но опытный DBA всё равно не станет пренебрегать профайлером, несмотря на то, что суть вроде как всегда одна. Потому, что слишком много есть "факторов" в этой сути, и какой именно перевесит можно сказать априори исключительно в самых простых случаях.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[50]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 10:22
Оценка: +2
Здравствуйте, criosray, Вы писали:

ГВ>>Лучше чуточку к реальности приблизить. Скопируем полученные строки в массив:


C>К какой реальности?


К повседневной, в которой строки, синтезированные StringBuilder-ом не хранятся в самом StringBuilder-е.

C>Никто в здравом уме не станет 25 тыс. раз в цикле вызывать ToString для StringBuilder`а.


Ну никто в здравом уме не станет и 100000000 раз вызывать в цикле append для std::wstring.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[41]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 12:04
Оценка: +1 -1
Здравствуйте, gandjustas, Вы писали:

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


См. мой ответ выше.

G>Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.


Пойми наконец, что никакой проверки не будет вообще.
With best regards
Pavel Dvorkin
Re[52]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 08.06.09 16:35
Оценка: :))
Здравствуйте, criosray, Вы писали:

M>>Создают видиость работы Как и большинство программистов, вне зависимости от языка программирования

C>Мы таких не держим.

Ну ты вот, например, тут почти круглосуточно трендишь...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[51]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 17:02
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:


C>>C++ 858 ms

C>>C# 823 ms

ГВ>Это называется "равны с точностью до погрешности измерения".


Конечно. Но вот чисто append сливает в три раза, а чисто replace так вообще в десятки раз (по крайней мере наколенковая реализация на базе wstring.find/wstring.replace.

C>>Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.


ГВ>Мне из моего колодца трудно судить о недостаточной эстетике, я, так сказать, привык по-простому, "от сохи":

ГВ>
ГВ>ws += L"Карл у Клары украл кораллы в количестве ";
ГВ>ws += _itow(i,buffer,10);
ГВ>ws += L" штук\n";
ГВ>


ГВ>И не надо никаких append и преобразований из MBCS.

Принято.

C>>Но самое замечательное, что С++ вариант банально крашился, если Count = 10000 (и возможно меньше... не проверял между 5к и 10к).


ГВ>У меня было всё ровно наоборот: C++ вариант попыхтел на пару с виндой, но таки 10K строк отработал, тогда как C# пыхтел столько же, а потом сказал OutOfMemoryException.

У меня дотнет вариант отработал за примерно 4 секунды, С++ тут же крашнулся без вменяемого сообщения о роде проблемы.
Re[60]: Ну ты вообще многого не видишь... ;)
От: skeptik_  
Дата: 08.06.09 22:11
Оценка: +1 -1
Здравствуйте, criosray, Вы писали:

C>Хм? append — идентично по скорости. replace — StringBuilder на много быстрее. Это при том, что дотнет не занимается оптимизацией на этапе компилляции в IL, а в runtime, как мы выяснили, у компиллятора IL нет времени для особых оптимизаций. Не говоря уж о том, что StringBuilder в отличии от std::wstring — гарантированно потоко безопасный.


;####! в код заглядывал? Там unsafe code. К тому StringBuilder — класс заточенный на данную задачу. В итоге мы имеем фактически специальный нейтивный код, против all purpose. Ну и чему тут удивляться?
Re[67]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 09.06.09 06:41
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:

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


C>>>>Например, проскочила информация, что QString immutable...

ГВ>>>Для immutable у неё слишком много методов append/insert/replace. Так что, пускай информация скачет дальше.
C>>А чем эти методы мешают immutable природе QString? Дотнетовский String тоже имеет эти методы. Не знали?

ГВ>Дотнетовский, например, String.insert возвращает string. А QT-шный QString::insert возвращает QString&. Разница понятна?

Хочу уточнить насчет immutable QString. Дословно было так :
здесь
Автор: alexey_ma
Дата: 02.06.09
. QString — он несоммненно СOW.

QString uses implicit sharing (copy-on-write) to reduce memory usage and to avoid the needless copying of data. This also helps reduce the inherent overhead of storing 16-bit characters instead of 8-bit characters.

хurl=http://doc.trolltech.com/4.5/qstring.html]здесь[/url]

Implicit sharing automatically detaches the object from a shared block if the object is about to change and the reference count is greater than one. (This is often called copy-on-write or value semantics.)
An implicitly shared class has total control of its internal data. In any member functions that modify its data, it automatically detaches before modifying the data.

здесь
ИМХО СOW != immutable
Re[61]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 08:40
Оценка: -1 :)
Здравствуйте, Erop, Вы писали:

C>>STL это что?

E>STL -- это часть средства для изготовления фрейсворков. Сам по себе STL фреймворком не является, так как без кучи великов на нём не поедешь...

STL это и есть фреймворк. Убогий — да. Но тем не менее фреймворк.
Давайте без домыслов и фантазий бабушки-гадалки, окей?
Re[67]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 12:34
Оценка: +1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Спасибо, кстати. Я сам на C# практически ничего не пишу, а так сцепишься с кем — и апеллировать не к чему.

C# не основной язык. Просто очень удобно посмотреть внутренности, иногда подсмотреть алгоритмы.
Читается код очень легко. (есть конечно и навороты бошку сломаешь).
Кстати заметь в этой ветке рефлектор многократно упоминается. А врага надо знать в лицо, а там и в друга превратится
и солнце б утром не вставало, когда бы не было меня
Re[68]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 13:23
Оценка: -1 :)
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Спасибо, кстати. Я сам на C# практически ничего не пишу, а так сцепишься с кем — и апеллировать не к чему.

S>C# не основной язык. Просто очень удобно посмотреть внутренности, иногда подсмотреть алгоритмы.
S> Читается код очень легко. (есть конечно и навороты бошку сломаешь).
S> Кстати заметь в этой ветке рефлектор многократно упоминается. А врага надо знать в лицо, а там и в друга превратится

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

Собственно, снова два теста:

C++:
static const unsigned long long count = 10000000ULL;
typedef std::wstring mwstring;
mwstring ws, ws1;
for(int i = 0; i < 50; ++i)
{
  ws += L"01234567890123456789012345678901234567890123456789";
}

ws1 = ws;

DWORD dwStart = ::GetTickCount();
for(int j = 0; j < count; ++j)
{
  ws1 = ws;
}
DWORD dwEnd = ::GetTickCount();

unsigned long long copied = (unsigned long long)ws.length() * sizeof(wchar_t) * count;
unsigned long long speedKBps = (unsigned long long)copied / (unsigned long long)(dwEnd - dwStart);

std::cout << (dwEnd - dwStart) << std::endl;
std::cout << copied << " bytes copied, with speed of: " << speedKBps / 1000ULL << " MB/s" << std::endl;


C#:
const int Count = 10000000;

StringBuilder sb = new StringBuilder();
sb.EnsureCapacity(10000);
for (int i = 0; i < 50; ++i)
    sb.Append("01234567890123456789012345678901234567890123456789");
String s;

Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
for (int i = 0; i < Count; i++)
{
    s = sb.ToString();
}
stopwatch.Stop();
Console.WriteLine("Elapsed {0}", stopwatch.Elapsed);
Console.WriteLine("Copied chars: {0}", (Int64)sb.Length * (Int64)Count);
Console.WriteLine("Average copy speed {0} MB/s", ((Int64)sb.Length * (Int64)Count * 2) / stopwatch.Elapsed.TotalMilliseconds / 1000);


Соотношение времени выполнения... 6:1 в пользу C++
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[70]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 13:56
Оценка: :))
Здравствуйте, criosray, Вы писали:

ГВ>>Собственно, снова два теста:

C>Этот маразм всем маразмам маразм.
C>Исправленный код:
Плохо исправил... кто там меня обвинял в изобретение велосипедов (_itoa -> _itow)?

Console.WriteLine("Average copy speed {0} MB/s", (sb.Length * count * 2) / stopwatch.Elapsed.TotalMilliseconds / 1000);


Конечно же


Console.WriteLine("Average copy speed {0} MB/s", (s1.Length * count * 2) / stopwatch.Elapsed.TotalSeconds);


В итоге

Elapsed 00:00:00.0734006
Copied chars: 25000000000
Average copy speed 681193341743,801 MB/s



C>Соотношение считайте сами.
Re[72]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:25
Оценка: -1 :)
Здравствуйте, criosray, Вы писали:

ГВ>>P.S.: Ты хоть понял, что я мерил?

C>Я же говорю: то, что Вы меряете — маразм. Сравнивать StringBuffer.ToString и обычное копирование С++.

Отнюдь. Я "сравнил" не только копирование, но ещё и несколько распространённых мифов. Например, то, что создание нового объекта в .Net — едва ли не бесплатная операция вкупе с выделением памяти, каковая, судя по высказываниям апологетов, никогда не вылезает из пределов L2-кэша. Ну и потом, где же очень умные JIT+GC, которые "в принципе" могли бы чуть ли не сразу удалять распределённую память, да и делать это в параллельном потоке по цене картофельной шелухи?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[71]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 14:30
Оценка: :))
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Да какой из .Net враг-то? Потешный, разве что.

C>>Ну уж С++ дотнету точно не враг. Вот джава — да.

ГВ>Да ясное дело — куда ж дотнет без C++?


Ну да, куда же С++ без дотнет: AutoCAD, VS 10, и т.д. и т.д.
Re[76]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:35
Оценка: +1 :)
Здравствуйте, criosray, Вы писали:

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


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

Ладно, ладно, я тоже хорошо знаю, что 2x2=5 при очень больших значениях 2.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[76]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 15:46
Оценка: +1 -1
Здравствуйте, Serginio1, Вы писали:

ГВ>>Трудно сказать. Больше похоже на то, что отставание в производительности у C# будет всегда, если не прибегнуть к мерам типа прямой работы с памятью, от чего пытаются шугаться. Ну не бывает чудес, кроме алгоритмической оптимизации.


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

S>Вторая это NGen оптимизировать уже под процессор, если JIT этим заниматься не хочет.

Так я-то всё это понимаю. Но ты ж послушай наших боевых анти-C++-ников. .Net разве что курицу не жарит за программиста.

S>>>Главное вектор развития выбран верно. А С++ с C# будут ещё долго существовать вместе.


ГВ>>"Верно" — это что означает?

S> Это развитие как манагед сред так и нативных, во многих случаях сближаясь. В многих случаях не нужна супер пупер скорость, нужны удобные средства разработки с минимальным затратами, с приемлемой скоростью работы. Поверь мне 1С ку.

Да нет, это всё понятно. Хотя мне кажется, что .Net развивается немного ради других целей. Ну там, у Java кусок отгрызть, индусов привлечь и т.п. Прагматично и объяснимо. Но это "кажется" супротив "кажется" — ни к чему не придём.

S> Вот тут насчет веревок диспут шел, да эффективны,можно и другие структуры более эффективные создать, а будут пользоваться стрингбуилдером. Потому, что для большинства задач его хватает за глаза. Процессор в основном то простаивает.


Вот в том-то и дело, что если процессор простаивает, то без разницы. Но он-то не всегда занят на 5%. Есть и другие задачи, которые не предполагают, что у нас всегда имеется 20-кратный запас производительности. Тут, понимаешь, прикол в другом, в том, что если следовать апологетам... Короче говоря, всё и так понятно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[72]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 18:20
Оценка: -1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Не-е-е, Дэвид Блейн, строка — это строка, дерево — это дерево, узлы — это узлы.

C>>Одно из двух: либо Вы откровенно глупы, либо просто пытаетесь троллить.

ГВ>Охрененно, ты мне оставил целых две возможности для выбора.


Не я Вам, а Вы сами себе.
Re[68]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 10.06.09 07:27
Оценка: +1 :)
Здравствуйте, criosray, Вы писали:

ГВ>>Дотнетовский, например, String.insert возвращает string. А QT-шный QString::insert возвращает QString&. Разница понятна?

C>Разница понятна — и то и другое есть ссылка.
О да!

Как ты там говорить любишь: "не позорьтесь"
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[65]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.06.09 11:25
Оценка: +2
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А где там про эпик вин std::wstring? Я что-то тоже такого не припоминаю.

IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки.

http://rsdn.ru/Forum/Message.aspx?mid=3415700&amp;only=1
Автор: Erop
Дата: 04.06.09

E>Ты писал, что фишка в том, что создание копии строки дорого стоит, ну так это тогда всё в неэффективность мутабельной строки в С# упирается выходит? Потому, как в С++ удобно и легко получается COW и нет никаких мегапроблем. А для константных строк тоже нет проблем...

Ну то есть вот, наша неэффективная мутабельная строка порвала, значит, "удобные и лёгкие" строки в C++.

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

А нефанаты тем временем изучают вопросы типа "как правильно проектировать строки, чтобы получать эффективную реализацию". Я вовсе не считаю StringBuilder идеалом. Но то, что порвёт StringBuilder, оставит от ваших std::* кровавые ошмётки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[44]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.06.09 07:03
Оценка: -2
Здравствуйте, Pavel Dvorkin, Вы писали:

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


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


G>>>>Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.

PD>>>Пойми наконец, что никакой проверки не будет вообще.
G>>Ага, процессор магическим образом будет узнавать куда писать не надо.

PD>Нет, процессор ничего знать не будет. Просто при попытке записи в R/O секцию произойдет исключение Access Violation. Ознакомься с основными принципами страничного механизма процессора.


А кто будет знать? Дева мария или еще кто-то?
Именно процессор и делает такие провеки.

Кстати, что ты пытаешь доказать то? Что играться с атрибутами доступа к страницам памяти лучше, чем использовать иммутабельность?
Re[46]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.06.09 07:50
Оценка: :))
Здравствуйте, Pavel Dvorkin, Вы писали:

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


G>>А кто будет знать? Дева мария или еще кто-то?

G>>Именно процессор и делает такие провеки.

PD>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?

Да не нервничай, проверки-то все равно есть. А "всегда" или "не всегда" зависит уже от ОС и процессора.

G>>Кстати, что ты пытаешь доказать то? Что играться с атрибутами доступа к страницам памяти лучше, чем использовать иммутабельность?

PD>Я лишь хочу сказать, что константые объекты можно в принципе делать для любого класса, размещая их в R/O памяти.
Так в этом никто и не сомневается. Можно много всего делать, другой вопрос зачем и с какими затратами.
Re[72]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 11.06.09 17:40
Оценка: +2
Здравствуйте, Sinclair, Вы писали:

ГВ>>Почему это он без STL не заработает?

S>Потому что RTFM. Потому что ему нечего будет бросать в случае нехватки памяти.
Все известные мне компиляторы позволяют обойтись без использования стандартной библиотеки совсем (частью которой и является STL). Стандартные исключения можно заменить на свои с помощью:
1) Своего ::operator new
2) Платформенно-зависимых трансляторов исключений и т.п.
Sapienti sat!
Re[73]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 17.06.09 06:16
Оценка: +1 :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Да??? То есть не с десятилетиями предыдущей истории в которой было всё: от ограничений по объёму памяти до неразберихи с кодировками, а с тем, что сейчас изменились представления о нормальной архитектуре?

S>>Да, представления изменились. Увы. Давайте теперь говорить, что ВАЗ 2101 — классная машина, потому что десятилетия назад это был ФИАТ.
S>>Извини, с тех пор представления о "классной машине" немножко изменились. ВАЗ 2101 в этом не виноват. А вот те, кто упорно за него цепляется, отказываясь понимать преимущества инжекторного двигателя, коробки-автомата, кондиционера — виноваты.

ГВ>Некорректная аналогия. С другой стороны, дороги, которые разбивали вдребезги подвеску ВАЗ 2101 в такой же хлам разнесут современную "классную машину", даже быстрее. Если это не БТР.


Судя по всему, этих устриц ты не ел. Что не мешает тебе об этом говорить. Аналогия Sinclair про ВАЗ 2101 какбэ о другом, но видно не всем это понятно. Помимо морально устаревшей конструкции, в ВАЗ есть сыромятное железо там где должна быть сталь, есть услуги по подтяжке болтов машины которая абсолютно новая, есть факты, когда колесо отваливается на ходу казалось бы при исправной подвеске. У меня есть опыт эксплуатации современных классных машин на убитых дорогах — поэтому я знаю о чем говорю — от Toyota Mark II до бюджетного Toyota Probox. Так что кавычки ты поставил зря.
Re[51]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.06.09 20:32
Оценка: +1 -1
Здравствуйте, WolfHound, Вы писали:

WH> Я в недавнем прошлом работал в Яндексе старшим разработчиком.

WH>И именно так все и было. После того как сервис был написан его за пару дней разгоняли в сотни раз.

То-то за яндексом (за narod-ом, вернее) уж давно закрепилась слава тормоза...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[57]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 18.06.09 10:11
Оценка: +2
Здравствуйте, kuj, Вы писали:

kuj>Это ты пытался оспорить и обосрался. ;]

Когда ж тебя опять забанят то?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[54]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 22.06.09 06:33
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Правда, такой подход имел один своеобразный эффект. Не то, чтобы неожиданный, я понимал, что таким дело может кончиться. Заказчик уверился, что я все могу , и на следующий раз, для другой задачи, прислал мне требования по времени, от которых у меня волосы дыбом стали — мне показалось, что такое невозможно, о чем я ему тут же и заявил. В ответ пришло — "постарайтесь все же сделать". Оказалось, что можно Правда, с помощью CUDA.


Только те, кто ставит себе невозможные цели — дотигают невозможного

Re[57]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 09:00
Оценка: -2
Здравствуйте, WolfHound, Вы писали:

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


PD>>Я многое про что говорил. Но об основной своей работе — нигде и никогда.

WH>Ну так расскажи что же такого супер крутое ты там делаешь что нам всем до тебя как до луны?

Нет. Не расскажу. Есть на то причины

PD>>Ну что же, если это так, +1 тебе. Для задач этого рода, вполне допскаю, такой подход может и работать.

WH>Оно для любых задач подходит.



WH>Просто ты это понять не можешь.

WH>А вообще забавно получается. Ты кричишь что я не смогу написать мелкософт.ком
WH>

WH>О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы

WH>А когда выясняется что я таки писал сайты такого класса то начинаешь что-то бурчать в свое оправдание.

Я же признал, что это может быть верным. Считай, что твой аргумент подействовал


PD>>О сколько нам открытий чудных

PD>>Готовит просвещенья дух...
WH>Ага. На разных уровнях абстракции дисковой подсистемой могут быть разные вещи...

Лучше просто разберись, где файлы, где в/в, где драйверы, а где прикладные программы (в т.ч MySQL). А пока что ты, извини, ерунду говоришь.

WH>А то что ты не умеешь абстрагироваться это твои проблемы.


Слава богу, я еще не научился настолько абстрагироваться, чтобы спутать файловый ввод-вывод с работой дисковой подсистемы.
With best regards
Pavel Dvorkin
Re[59]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 10:55
Оценка: :))
Здравствуйте, WolfHound, Вы писали:

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


PD>>Нет. Не расскажу. Есть на то причины

WH>Боишься что перехвачу?
WH>Или что нечем народ на форуме пугать будет?

Не провоцируй, бесполезно

PD>>>>Ну что же, если это так, +1 тебе. Для задач этого рода, вполне допскаю, такой подход может и работать.

WH>>>Оно для любых задач подходит.
PD>>
WH>Ты не лыбся. Про мелкософт.ком ты уже промазал. И со всем остальным при разборе полетов будет также.

. Ох...

PD>>Лучше просто разберись, где файлы, где в/в, где драйверы, а где прикладные программы (в т.ч MySQL). А пока что ты, извини, ерунду говоришь.

WH>Если говорить про классические ОС то единственная разница мжеду драйвером и MySQL это то что драйвер в нулевом кольце работает.

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

Предлагаю тебе повторить эту фразу где-нибудь в тематическом форуме, например, в "Низкоуровневом программировании". Приди туда и скажи, что MySQL можно использовать как дисковую подсистему и что единственная разница между драйвером и MySQL — это то что драйвер в нулевом кольце работает. Может, там кто-нибудь и возьмется тебе объяснить основы. А с меня хватит. Чепуху обсуждать я не буду.
With best regards
Pavel Dvorkin
Re[14]: За что я не люблю С++
От: metaprogrammer  
Дата: 05.11.09 21:14
Оценка: +1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Извини, но нет решительно никакого желания вести это флейм. Я уже десятки раз эти аргументы слышал и столько же раз отвечал.


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

PD> Если хочешь — поищи в моих постингах.


Не хочу.
Re[58]: Ну ты вообще многого не видишь... ;)
От: VoidEx  
Дата: 22.06.09 12:41
Оценка: 3 (1)
Здравствуйте, Eugeny__, Вы писали:

E__>Здравствуйте, Anton Batenev, Вы писали:



AB>>"Никодим! Да тыж леший!"


E__>Жесткий оффтоп, но, блин, не знаешь, где можно найти этот мультик? Я в свое время все интернеты перекопал, не нашел .


Ссылку выше дали. Если вдруг забыли название, то вот
Re[37]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 18:37
Оценка: 2 (1)
Здравствуйте, MxKazan, Вы писали:

ГВ>>Вот это как раз и интересно. Например, на C++ я могу написать функцию, которая будет требовать в качестве параметра именно "свойство". Примерно так:

MK>Да пускай требует. Свойство от этого типом не становится.

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

ГВ>>void func(PropertyBase<int> *prop){ ... }

MK>Я в С++ не силен. Напиши как ты будешь это юзать.

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

Тогда я смогу сделать так:

template<typename T, ...> class Property : public PropertyBase<T> { ... };

temaplate<typename T, ...> class MySmartProperty : public Property<T> {
  private:
    // Предположим, что такая проперть имеет какую-нибудь хитрую функцию,
    // вызываемую, например, при изменении значения:
    void HiddenSmartFunc() { ... }
};

// Тогда тестовая функция может выглядеть так:
void MyTestFunc(PropertyBase<int> *prop){
  *prop = 42;
  // Проверяем - вызвалась ли HiddenSmartFunc
}


Но это мелочи. Гораздо интереснее другое возможное применение. Например, у нас есть класс какого-нибудь развесистого окна с развесистым же управлением, например, свойствами Enabled. Если я могу оперировать свойствами, как отдельными объектами, то я могу написать функцию управления Enabled примерно так (пример сильно упрощённый):

void ManageEnabled(PropertyBase<bool> &propOK, PropertyBase<bool> &propCancel) {
  if (someCondition)
  {
    propOK = true;
    propCancel = false;
  }
  else if (otherCondition)
  {
    propOK = false;
    propCancel = true;
  }
  else // strangeCondition
  {
    propOK = false;
    propCancel = false;
  }
}


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

Но это ещё не всё. Эту же функцию можно обобщить:
template<typename P1, typename P2>
void ManageEnabled(P1 &propOK, P2 &propCancel) { ... }


И после обобщения, например, такую функцию можно легко (если, конечно, мы смогли обобщить ещё и условия) протестировать на другом наборе типов данных, главное, чтобы совпадала семантика чтения и присвоения значений:

bool bOK = false, bool bCancel = false;

someCondition = true; // Это упрощение - я имею в виду, что мы привели тестовое окружение в состояние,
// когда внутреннее условие someCondition станет true.

ManageEnabled(bOK, bCancel);

TEST_ASSERT(bOK && !bCancel);

otherCondition = true;

ManageEnabled(bOK, bCancel);

TEST_ASSERT(!bOK && bCancel);

someCondition = false;
otherCondition = false;

ManageEnabled(bOK, bCancel);

TEST_ASSERT(!bOK && !bCancel);


Само собой, её можно перетаскивать из класса в класс, положить в библиотеку, использовать ещё как-то и т.п.

Ну вот, примерно так. На вскидку. Пожалуй, ещё можно добавить, что можно собрать указатели на свойства в массив, ещё как-нибудь использовать. Короче говоря, применять к свойствам полный комплект методов работы с обычными классами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 29.05.09 00:56
Оценка: 2 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>Ещё раз, медленно: Найк, вроде бы, со мной согласен. Другого источника информации у меня нет.


Я абстрагировался до определённого уровня, на котором сериализация стала протоколом обмена данными одной структуры данных с другой
Т.е. превращение какой-то сложной структуры данных в другое представление (хмл, бинарный формат, трансформированная структура данных, та же самая структура данных с шарингом нужных данных, опять же сетевой протокол реализовался силами той же реализации сериализации).
Вопрос в том — кто до какого уровня абстрагировался
Нужно разобрать угил.
Re[40]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.05.09 11:35
Оценка: 2 (1)
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Добавим тривиальное усложнение в функцию управления Enabled:
Ничего военного.
void ManageEnabled(IProperty<bool> propOK, IProperty<bool> propCancel) {
  if (propOK.Value)
    {
      ...
    }
  if (someCondition)
  {
    propOK.Value=true);
    propCancel.Value=false;
  }
  else if (otherCondition)
  {
    propOK.Value=false;
    propCancel.Value=true;
  }
  else // strangeCondition
  {
    propOK.Value=false;
    propCancel.Value=false;
  }
}

Как-то так:
var bOk = new StoredProperty<bool>(false);
var bCancel = new StoredProperty<bool>(true);

someCondition = true; // Это упрощение - я имею в виду, что мы привели тестовое окружение в состояние,
// когда внутреннее условие someCondition станет true.
ManageEnabled(bOk, bCancel);


Boilerplate:
    public interface IReadProperty<T>
    {
        T Value { get; }
    }
    public interface IWriteProperty<T>
    {
        T Value { set; }
    }
    public interface IProperty<T> : IReadProperty<T>, IWriteProperty<T>
    {
    }

    public class CustomProperty<T> : IProperty<T>
    {
        private Func<T> _get;
        private Action<T> _set;
        public CustomProperty(Func<T> get, Action<T> set)
        {
            _get = get;
            _set = set;
        }

        public T Value
        {
            get { return _get(); }
            set { _set(value); }
        }
    }

    public class StoredProperty<T> : IProperty<T>
    {
        private T _value;
        public StoredProperty(T value)
        {
            _value = value;
        }
        public T Value
        {
            get { return _value; }
            set { _value = value; }
        }
    }

    public class ReflectionProperty<T> : CustomProperty<T>
    {
        public ReflectionProperty(object obj, string propName)
            : base(GetGetter(obj, propName), GetSetter(obj, propName))
        {
        }

        private static Action<T> GetSetter(object obj, string propName)
        {
            var pi = obj.GetType().GetProperty(propName);
            if (pi.PropertyType != typeof(T))
                throw new InvalidOperationException("Incorrect property type");

            return (Action<T>)Delegate.CreateDelegate(typeof(Action<T>), obj, pi.GetSetMethod());
        }

        private static Func<T> GetGetter(object obj, string propName)
        {
            var pi = obj.GetType().GetProperty(propName);
            if (pi.PropertyType != typeof(T))
                throw new InvalidOperationException("Incorrect property type");

            return (Func<T>)Delegate.CreateDelegate(typeof(Func<T>), obj, pi.GetGetMethod());
        }
    }
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[38]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 30.05.09 20:42
Оценка: 2 (1)
Здравствуйте, -MyXa-, Вы писали:

Q>>Вообще-то, встречая явно провокационные (читай «толстый троллинг») фразы типа «В общем, картина начинает проясняться» и «Так и запишем», полезно заблаговременно вносить собеседника в реестр недостойных внимания и не тратить на них более времени.

MX>Я про "запишем" — исключительно для того, чтоб Вы меня не забыли опровергнуть и правильно процитировали.

Я прошу прощения, если обидел тебя незаслуженно.

MX>Другими словами, Вы часто передаёте shared_ptr по ссылке...


Не то чтобы часто, потому что благополучно мигрировал на .NET (чего и всем желаю). Но когда писал на C++ — да, передавал по ссылке на константу.

MX>а внутри не создаёте копию прежде, чем делать что-либо ещё


Это зависит от того, «моя» ли это функция. Если бы это была моя функция, то при необходимости я делал бы копию внутри (или сразу принимал по значению, depends on). Если бы это была не моя функция, и при этом 1) она принимала аргумент по ссылке, 2) в документации говорилось, что у неё есть (извратные) побочные действия, то я бы делал копию снаружи.

MX>и нет, по Вашему мнению, с этим никаких проблем, одна только экономия?


Здесь проблема не «с этим», а с логикой. (Подробности будут ниже.)

MX>Тогда Вы ошибаетесь...


Я отлично знаю разницу между передачей по значению и по ссылке.

MX>вот смотрите:
MX>boost::shared_ptr<int> g;

MX>void Bar(boost::shared_ptr<int> const & o)
MX>{
MX>    g.reset(); // не обязательно прямо так, это м.б. и вызов какой-нибудь функции, которая из какого-нибудь list-а удаляет shared_ptr
MX>    *o = 42;
MX>}


Корни той проблемы, что ты описал, не имеют отношения к подсчёту ссылок вообще и к boost::shared_ptr в частности. [offtopic]Кстати, C# хорош тем, что упрощает использование идиомы иммутабельности, которая, в свою очередь, уменьшает количество разделяемых изменяемых состояний. Соответственно уменьшает зависимости от data flow и control flow (что помимо прочего улучшает распараллеливаемость). С переходом на C# я почти забыл про ошибки такого рода.[/offtopic]

MX>Всё замечательно, пока мы не делаем Bar(g). По-этому НИКОГДА нельзя передавать shared_ptr по ссылке.


О противного. Последовательно следуя твоей логике получим, что «НИКОГДА» нельзя передавать любые объекты по ссылке — в виду следующего аналогичного кода:
class VeryLargeObject
{
private:
  int value_;
  bool valid_;
public:
  explicit VeryLargeObject(int value) : value_(value), valid_(true) { }
  ~VeryLargeObject() { valid_ = false; }
  int GetValue() const
  {
    if (!valid_)
      throw std::runtime_error("Trying to get member of destroyed object.");
    return value_;
  }
};

std::vector<VeryLargeObject> g;

void Foo(VeryLargeObject o)
{
  g.clear();
  o.GetValue();
}

void Bar(VeryLargeObject const& o)
{
  g.clear();
  o.GetValue();
}

int main () 
try
{
  g.push_back(VeryLargeObject(42));

  Foo(g[0]); // OK.
  Bar(g[0]); // UB в теории, и (возможно) наш runtime_error на практике.
}
catch (std::exception const& ex)
{
  std::cout << ex.what() << std::endl;
}


MX>Мне книжки уже не помогут, дурака учить — только портить.


И всё-таки советую.

MX>А почему Вы цитируете мои слова, которые относятся к С#, не полностью, отрывая самое важное, а потом ещё и перепрыгиваете на С++?


Перепрыгиваю на C++, чтобы отделить те ньюансы, которые свойственны исключительно C#, от тех ньюансов, которые справедливы вообще.

MX>А я, между прочим, спрашивал "Ну-ка, покажите мне — как уничтожить, в таком случае, почку по полной программе (и я опять не имею в виду Dispose...


Это всё равно, что спрашивать «как уничтожить почку на C++, удалив из исходника shared_ptr'а деструктор».

MX>не имею в виду Dispose, потому, что он — не уничтожение


Я настаиваю, что Dispose — уничтожение. Это логическое уничтожение, типа свойству Valid почки присвоить false (аналог освобождения неуправляемого ресурса). Физическое удаление сборщиком — это просто возвращение памяти менеджеру управляемой кучи, никаких дополнительных действий типа вызова финализатора выполняться не будет (если правильно реализовать паттерн Disposable).

MX>Как на С# записать аналог "ref1.reset()", в моём примере про почку и 2-х человек, Вы так и не ответили.


a.Dispose() (или что там было, я не помню уже).

MX>Вы не правы, т.е. невозможно уничтожить насовсем объект, пока на него есть хоть одна ссылка


Наличие ссылки ровным счётом ничего не говорит кроме того, что память под объект пока не возвращена менеджеру. Объект может быть уничтожен логически (отпущены все ресурсы (битмапы, кисти, стримы, etc.), обнулены ссылки на них, на объект повешена табличка «невалиден»), а физически просто болтается немного памяти под экземпляр. Если у тебя есть ссылка на эту область, эта память не будет освобождена, ты по-прежнему можешь обращаться к ней. Результат такого обращения всецело зависит от разработчика класса, что он предусмотрел в вызове свойств логически уничтоженного объекта.

MX>а вызов какого-то там Dispose ничего не говорит о владении.


При правильной реализации паттерна Disposable, Dispose() убивает те объекты, какими владеет этот класс. Например, вызывает для них Dispos'ы, ссылкам на dispos'нутые части присваивает null, etc.

MX>Короче, нет никакого способа в C# передать поле (вообще объект) в метод, не передав владения.


Ещё раз, мы просто передаём ссылку: «void Foo(RefCounter<Bitmap> h)». Если разработчикам функции вдруг понадобилась глубокая копия, они всегда могут сделать Copy()/Dispose() внутри:
void Foo(RefCounter<Bitmap> h)
{
  using (var temp = h.Copy())
  {
    ...
  } // Dispose()
}


Если глубокая копия понадобилась пользователям функции, то они всегда могут сделать Copy()/Dispose() снаружи:
using (var temp = hugeBitmap.Copy())
{
  ...
  Foo(temp);
  ...
} // Dispose()


Но делать так, как ты сказал — снаружи Copy(), внутри Dispose() — нонсенс.

MX>* в C# есть только передача владения (предположу, что есть исключение — встроенные типы, чтоб было не без аномалий)


Это не так.

MX>* shared_ptr — только по значению, без вариантов


Ты согласен, что если в твоих обоснованиях этого утверждения заменить boost::shared_ptr<int> на std::vector<VeryLargeObject>, то с помощью тех же рассуждений можно прийти к заведомо абсурдному выводу «большие объекты — только по значению, без вариантов»?

MX>* подсчёт ссылок в C# только так (2 места, где можно ошибиться — забыть Clone или Using):

MX>
MX>void foo(RefCounter<HugeBitmap> h)
MX>{
MX>  using (h)
MX>  {
MX>  }
MX>}
MX>foo(hugeBitmap.Clone());


Не так, а чтобы Copy() и Dispose() были на одном уровне:
// 1) Просто используем h, если разработчику функции не нужна особая логика.
void Foo(RefCounter<HugeBitmap> h)
{
  ...
}

// 1) В случае, если разработчику функции нужна особая логика.
void Foo(RefCounter<HugeBitmap> h)
{
  using (var temp = h.Copy())
  {
    ...
  }
}

...

// A) Если пользователю не нужна особая логика.
Foo(hugeBitmap);

// B) Если пользователю нужна дополительная логика.
using (var temp = hugeBitmap.Copy())
{
  ...
  Foo(temp);
  ...
}
Глаза у меня добрые, но рубашка — смирительная!
Re[43]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 08.06.09 16:08
Оценка: 2 (1)
Здравствуйте, criosray, Вы писали:

C>Ссылку эту я видел, но исходника я там не нашел. Плохо искал?

2 клика: http://ahmadsoft.org/ropes/release.html

C>И хотелось бы все-таки .NET реализацию увидеть...

Незнаю не искал.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 16:21
Оценка: 2 (1)
Здравствуйте, criosray, Вы писали:

C>Ссылку эту я видел, но исходника я там не нашел. Плохо искал? И хотелось бы все-таки .NET реализацию увидеть...


Например, здесь
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[59]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 10:08
Оценка: 2 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

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



ГВ>Как это, не будет копирования строки?


А говоришь код понятный.

public override string ToString()
{
    string stringValue = this.m_StringValue;
    .....................................
    stringValue.ClearPostNullChar();// добиваем пространство за Length + 1 нулями
    this.m_currentThread = IntPtr.Zero; // устанавливаем флаг на то что есть ссылка на строку
    return stringValue; // возвращаем ссылку на внутреннюю строку
}




public StringBuilder Append(string value)
{
    if (value != null)
    {
        string stringValue = this.m_StringValue;
        IntPtr currentThread = Thread.InternalGetCurrentThread();
        if (this.m_currentThread != currentThread) // Вот здесь если m_currentThread == IntPtr.Zero
        {                                          // Выделяется новая строка
            stringValue = string.GetStringForStringBuilder(stringValue, stringValue.Capacity);
        }
        int length = stringValue.Length;
        int requiredLength = length + value.Length;
        if (this.NeedsAllocation(stringValue, requiredLength))
        {// если места нехватает выделяется новая строка с новым капасити currentString.Capacity * 2;
            string newString = this.GetNewString(stringValue, requiredLength);
            newString.AppendInPlace(value, length);
            this.ReplaceString(currentThread, newString); 
        }
        else
        {
            stringValue.AppendInPlace(value, length);
            this.ReplaceString(currentThread, stringValue); // зписывается вместо старой
        }
    }
    return this;
}
и солнце б утром не вставало, когда бы не было меня
Re[65]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 12:16
Оценка: 2 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

S>>Особенностью FW наверное является присутствие методов с Internal


S>>
S>>Thread.InternalGetCurrentThread()
S>>string.InternalCopy
S>>


ГВ>Как я понимаю, как раз в InternalCopy зарыта синхронизация.

В основном это унсейвные или extern закрытые методы.
Кстати поставь себе reflector http://www.red-gate.com/products/reflector/
Очень поучительная штука.
и солнце б утром не вставало, когда бы не было меня
Re[74]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 18:49
Оценка: 2 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>>>Не-е-е, Дэвид Блейн, строка — это строка, дерево — это дерево, узлы — это узлы.

C>>>>Одно из двух: либо Вы откровенно глупы, либо просто пытаетесь троллить.
ГВ>>>Охрененно, ты мне оставил целых две возможности для выбора.
C>>Не я Вам, а Вы сами себе.

ГВ>Я сам себе оставил только две возможности выбора тобой твоих оценок. Дзен... Коан...

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

ГВ>

Папаша ходил на голове и горланил песню "Весь мир вверх тормашками".

(c) Р. Шекли.

А Шекли в курсе, что Вы ему приписали выдуманное Вами же?
Re[58]: Ну ты вообще многого не видишь... ;)
От: Mamut Швеция http://dmitriid.com
Дата: 22.06.09 11:42
Оценка: 2 (1)
Здравствуйте, Eugeny__, Вы писали:

E> AB>"Никодим! Да тыж леший!"


E> Жесткий оффтоп, но, блин, не знаешь, где можно найти этот мультик? Я в свое время все интернеты перекопал, не нашел .


Что за мультик, не знаю, но на http://multiki.arjlover.net/ нет?
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[2]: За что я не люблю С++
От: dds777  
Дата: 27.05.09 21:42
Оценка: 1 (1)
Здравствуйте, Sorantis, Вы писали:

S>Сложилось ощущение, что автор долго искал баг, дооолго искал, но не нашел и свалил все на язык.


Вы это зря, автор довольно известный и уважаемый. Лично я думаю, что вся проблема в том, что он имеет удовольствие (впрочем как и я) писать под мак на Objective-C, поэтому когда в проекте встречаются эти два языка (такое частенько бывает), сложно себя удержать от ругани C++
Re[27]: За что я не люблю С++
От: dr.Chaos Россия Украшения HandMade
Дата: 28.05.09 10:04
Оценка: 1 (1)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Деталей сейчас уже не помню, но идея, думаю, понятна.

S>Конечно понятна. Непонятно, каким образом собираются работать простейшие запросы. Само отображение — это натурально прошлый век, конец девяностых.
S>Я в своё время пытался придумать такую штуку; в итоге кончилось ничем — на макросах такое не залудишь, потому что нужно два разных класса — один для данных, другой для метаданных. Ну, разве что компилять один хидер дважды с разными дефайнами, а это уже плохо дружит со всякими прекомпиляциями и всё такое. И всё равно не получается сделать полноценные запросы.

У нас это решается внешним кодогенератором, который генерит перситы по объектной схеме и связывает их с метаинформацией, а метаинформация вычитывается из схемы данных. Отношения сделаны таким образом что с ними работаешь как со списком, есть ленивая загрузка, есть способ строить запросы с проверкой типов в рантайме, можно прикрутить и чтоб в компаил тайме работало, но когда делали это всё компилилось, в том числе, древним VS6. Правда стоит заметить, что это всё делалось для сетевой БД с сишным АПИ без SQL-я, но перейдя на SQL особых изменений в самой модели не произошло, просто читать стали пачками.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[9]: За что я не люблю С++
От: Erop Россия  
Дата: 28.05.09 23:31
Оценка: 1 (1)
Здравствуйте, Eugeny__, Вы писали:

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

E__>2. Послать пользователай на###, и просто рестартануться, забив на данные.
3. Разослать приложениям уведомление о том, что сейчас рестарт...
Вдруг на том конце что-то нельзя просто так взять и бросить... TCP\IP соединяния надо бы восстановит после рестарта ну и мало ли что там на другом конце? Может АЭС, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: За что я не люблю С++
От: LaptevVV Россия  
Дата: 29.05.09 04:44
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>>>Каких проблем?
LVV>>По этому поводу вспомнилось из его статьи: любая книжка по С++ описывает, как не надо делать при множественном наследовании. Я сам писал — тут он прав...
ГВ>Мне такие заявления всегда кажутся излишне самонадеянными. Ну, сам знаешь, нет такой конструкции в языке программирования, которую нельзя было бы применить неправильно.
Естественно. Но в С++ таких уж больно много. Более того, я сейчас общаюсь с оберонцами на их формуме. В Хабаровске один из них, Попков, создал школу юных программистов. Он описывал свой опыт использования С++ для обучения начинающих — те же впечатления. Приходится в основном предупреждать, как не следует делать, чтобы не было лишних проблем.
Когда в С++ погрузился, то это уже на автомате происходит, а для входящих в язык — это настоящая проблема.
LVV>>Ну, кое-что подсматриваю и использую. Но небольшие вещи. Типа интеллектуальных указателей.
ГВ>На самом деле, там много интересного. Мне сильно понравился boost::spirit — полезная штука для мелких парсеров. И наглядно записывается, и быстро работает. В подробности вдаваться не стал. Ну и по мелочи много всего. boost::bind, boost::function, само собой. Не пойму только, как обстоит дело с boost::channel — будет он когда-нибудь внесён в релиз, или нет.
Да я знаю. Спасибо за подсказку по парсеру — посмотрю, мож включу в учебный курс по системному программированию. А bind и function я смотрел — пришлось студентам в книжке писать: как написать обобщенный алгоритм...

LVV>>Объективно я осенью напишу. Вот сравню БлэкБокс с С++ на одних и тех же задачах — и напишу...

ГВ>О-о-о! Это было бы интересно — я про одни и те же задачи.
Я сейчас на С++ проги для книжки по системному ПО пишу. Вот эти проги для освоения ББ и попробую. Там входной язык — компонентный паскаль. Но сама среда — ну очень интересна.

LVV>>Вот раньше был фортран — на нем все и писали...

ГВ>А... Да-да. Настоящие программисты работают в NASA и пишут на Фортране. И программы настоящих программистов исполняются в режиме супервизора. Я в курсе.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[11]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 05:58
Оценка: 1 (1)
Здравствуйте, criosray, Вы писали:

C>>>Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального.


H>>30%? Шутишь? У меня даже на глаз видно, что там отрыв в разы, в большие разы.


C>Не шучу. Замерял с секундомером. Если быть точным, то 27.5% выходит. Может у Вас более старая версия Paint.NET?


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

Дана картинка, известная, Dawn Of Ubuntu 1920x1200x24. Pentium M 1.7. 512 RAM. Все лишнее выгрузил.

1. Paint.NET 3.31. Фильтр Gaussian Blur (200px) — 2мин. 28 сек (148 сек)
2.1. GIMP 2.2.11. Фильтр Гауcсово размывание (200x200px. IRR) — 4сек.
2.2. GIMP 2.2.11. Фильтр Гаусcово размывание (200x200px. RLE) — 20сек.

Цифры говорят сами за себя. Списывать отставание на несвежесть версии Paint.NET просто смешно.

C>>>Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.


H>>Как в Paint.NET вырезать часть картинки выделенную Magic Wand, чтоб у вырезаемой части растушевались границы? Я в удобном интерфейсе Paint.NET этого не нашел, а в неудобном GIMP'е нашел сразу.


C>Не знаю. Я не занимаюсь профессиональным фотомонтажем. Вы уверены, что пользователям Paint.NET это нужно?


Это самый обычный юзкейс -- вырезать что-то с картинки и бесшовно (без зазубренных краев) вставить в другую. Что тут необычного?
Re[36]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 17:49
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Так собственно, речь-то о чём была? О том, что дублирование узлов при соблюдении требования immutability неизбежно.

И в чем проблема?
Ибо даже с учетом этого все работает быстрее.

WH>>Нет. Им достаточно хранить количество символов в собственной подстроке.

ГВ>Нет, этого мало.
Для чего конкретно этого не хватает?

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

http://www.ibm.com/developerworks/java/library/j-ropes/index.html
Там есть места где ропы тормознее но это исключительно из-за ущербности самой жабы.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.06.09 12:07
Оценка: 1 (1)
Здравствуйте, alexey_ma, Вы писали:

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


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


_>>>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?

C>>Загнулись. Потому 99% enterprise это Java и .NET
_>Насчет Jаva соглашусь. А пример широко известной дотнет enterprise системы ( ну там CRM — ЕRP какой-нибудь)?

Sharepoint, Dynamics
Re[57]: Ну ты вообще многого не видишь... ;)
От: hattab  
Дата: 08.06.09 19:52
Оценка: 1 (1)
Здравствуйте, criosray, Вы писали:

C>>>Попробуйте Replace('1','2') заменить на Replace('c1', 'abc4') Будет куда интереснее, чем замена одного символа.


H>>Померял -- не дождался


C>Уменьшите количество итераций при формировании еще на порядок (больше, если потребуется). У меня Делфи нет, так что проверить у себя не могу, а узнать интересно.


Результа удалось дождаться лишь на 100,000 итераций.

C#:
append: elapsed 00:00:00.0049570
200000
replace: elapsed 00:00:00.0097196
400000
insert: elapsed 00:00:00.0345641
400090

Delphi 2009 (миллисекунды):
string.append: elapsed 4 (200000)
string.insert: elapsed 12 (200090)
-----------
sb.append: elapsed 8 (200000)
sb.replace: elapsed 4840 (300000)
sb.insert: elapsed 21 (300090)

Впрочем, я не удивлен. Судя по всему (по алгоритмам, структуре, набору методов) TStringBuilder был добавлен чтоб облегчить создание форматированных строк, и по скорости не оптимизировался (хотя у меня только Update 1, в поздних, а их уже 4, его кажется пилили).
Re[63]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 09.06.09 10:11
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Тогда берём такой пример:


ГВ>
ГВ>const int Count = 1000000;
ГВ>String str = "Text";

ГВ>StringBuilder sb = new StringBuilder();
ГВ>for(int i = 0; i < 10; ++i)
ГВ>sb.Append("0123456789");
ГВ>String s;

ГВ>Stopwatch stopwatch = new Stopwatch();
ГВ>stopwatch.Start();
ГВ>for (int i = 0; i < Count; i++)
ГВ>{
ГВ>    s = sb.ToString();
ГВ>}
ГВ>stopwatch.Stop();
ГВ>Console.WriteLine("Elapsed 1 {0}", stopwatch.Elapsed);

ГВ>stopwatch.Reset();
ГВ>stopwatch.Start();
ГВ>for (int i = 0; i < Count; i++)
ГВ>{
ГВ>    s = sb.ToString();
ГВ>    s = sb.ToString();
ГВ>    s = sb.ToString();
ГВ>    s = sb.ToString();
ГВ>    s = sb.ToString();
ГВ>}
ГВ>stopwatch.Stop();
ГВ>Console.WriteLine("Elapsed 5 {0}", stopwatch.Elapsed);
ГВ>


ГВ>Если твоё предположение верно, то соотношение времен Elapsed1:Elapsed5 должно быть близко к 1:1. Прокрути тест, посмотри на результаты.


Я не делаю предположений, я смотрю рефлектором. Но там не всё так прозрачно. Судя по коду, есть подозрение, что только первый .ToString не вызовет копирования.
Re[69]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 13:29
Оценка: 1 (1)
Здравствуйте, Геннадий Васильев, Вы писали:

В свое время обплевавшись на стандартный стрингбуилдер народ начал делать свои.
Посмотри http://www.rsdn.ru/forum/dotnet/3303143.flat.aspx#3303143
Автор: Serginio1
Дата: 24.02.09

там есть RStringBuilder тоже сделанный для тестов, но чиста манагедный.
и солнце б утром не вставало, когда бы не было меня
Re: За что я не люблю С++
От: vladpol Украина http://vlad-mislitel.livejournal.com/
Дата: 26.05.09 10:36
Оценка: +1
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

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


Хм, пишу на C#, но к С++ всегда относился с "уважением". По-моему данная статья — это явное перекручивание фактов, с жутко предвзятой точки зрения
С уважением, Владислав Полищук
Re[2]: За что я не люблю С++
От: 0x7be СССР  
Дата: 26.05.09 11:17
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>Кстати, хорошая статья...

Слишком эмоциональная.
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 14:01
Оценка: :)
Здравствуйте, criosray, Вы писали:

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

C>С мира по нитке..

И будет гора ниток.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 14:19
Оценка: +1
Здравствуйте, March_rabbit, Вы писали:

M>>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

M_>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?
M_>здорово, если так.

Конечно есть. Только этим не язык занимается.
Re[6]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 26.05.09 14:22
Оценка: +1
MX> M>Объект с циклическими ссылками и членами — указателями на другие объекты.

MX> libs\serialization\test\test_cyclic_ptrs.cpp


MX> M>Плюс является наследником другого объекта так, чтобы не надо было явно указывать:

MX> M>
MX> M>ar & boost::serialization::base_object<bus_stop>(*this) & name;
MX> M>


MX> Думаю, что от этого можно избавиться.


Можно быо бы, в boost:serialize избавились бы

MX> Библиотека знает обо всех типах — могла бы сложить их в список типов, а при сериализации — найти все базы данного типа. Не думаю, что бывают случаи, когда (де)сериализовать наследника надо, на базу — нет. Хотя, с другой стороны, базЫ можно ситать такими же полямИ, и библиотека сама никак не может догадаться — сериализовать ли базу, или нет (если данная база не сериализуется, то понятно, что не надо, а если сериализуется?)


Все она может догадаться. Не в С++, естественно
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[4]: За что я не люблю С++
От: LaptevVV Россия  
Дата: 26.05.09 14:29
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>свойства — синтезируется;

ГВ>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;
ГВ>события — синтезируется;
ГВ>делегаты — синтезируется;
Это говорит только о том, что в языке их не хватает.
ГВ>лямбда-выражения — есть в C++0x;
ГВ>замыкания — есть в C++0x;
Ага... Не прошло и 0х лет, как...
ГВ>duck typing — статический (и это очень хорошо);
Ну, нормально... Но не так строго, как в Виртовских языках...
ГВ>интерфейсы — полностью выражается средствами pure virtual;
Нормально. Но почему-то в других языках сочли необходимым такую конструкцию явно определить
ГВ>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
А ковариантные — это какие?
MX>>>13) "средств получить информацию о типе-параметре в языке просто нет" . Язык С++ на столько крут, что "в языке" это и не нужно — можно написать библиотеку. boost::is_abstract, is_arithmetic, is_array, is_base_and_derived, is_base_of, is_class, is_complex, is_compound, is_const...
C>>О, ужас.
ГВ>А что не так?
Дык ПИСАТЬ НАДО... А в других языках писать НЕ НАДО...
А челу требуется задачу решать, а не писать библиотеку...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 14:43
Оценка: -1
Здравствуйте, LaptevVV, Вы писали:

ГВ>>свойства — синтезируется;

ГВ>>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;
ГВ>>события — синтезируется;
ГВ>>делегаты — синтезируется;
LVV>Это говорит только о том, что в языке их не хватает.

Ну вот, теперь твоя очередь. ИМХО, если фича синтезируется, то и рассуждать не о чем.

ГВ>>лямбда-выражения — есть в C++0x;

ГВ>>замыкания — есть в C++0x;
LVV>Ага... Не прошло и 0х лет, как...

Ну, тем не менее.

ГВ>>duck typing — статический (и это очень хорошо);

LVV>Ну, нормально... Но не так строго, как в Виртовских языках...

Так и способ использования другой, AFAIK.

ГВ>>интерфейсы — полностью выражается средствами pure virtual;

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

Видимо, из-за отсутствия множественного наследования.

ГВ>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?

LVV>А ковариантные — это какие?

class A {
  public:
    virtual A *f(){ ... }
};

class B : public A {
  public:
    virtual B *f(){ ... }
};



MX>>>>13) "средств получить информацию о типе-параметре в языке просто нет" . Язык С++ на столько крут, что "в языке" это и не нужно — можно написать библиотеку. boost::is_abstract, is_arithmetic, is_array, is_base_and_derived, is_base_of, is_class, is_complex, is_compound, is_const...

C>>>О, ужас.
ГВ>>А что не так?
LVV>Дык ПИСАТЬ НАДО... А в других языках писать НЕ НАДО...
LVV>А челу требуется задачу решать, а не писать библиотеку...

Дык — не надо ж. Он там в качестве контраргумента всё время рассуждает о непонятности внутреннего устройства буста.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: За что я не люблю С++
От: blackhearted Украина  
Дата: 26.05.09 14:47
Оценка: +1
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

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

Это чё еще за фигня?


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

Re[8]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.05.09 14:48
Оценка: +1
Здравствуйте, March_rabbit, Вы писали:

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


M>>>>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

M_>>>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?
M_>>>здорово, если так.

G>>Ты удиишься.

M_>и где?
Везде. java и .NET точно умеет, в остальных не проверял.
Вообще говоря в основе такой сериализации лежит алгоритм нахождения связных кусков на графе.
Если есть нормальные метаданные в языке, то с объектами такое выполняется элементарно.
Re[6]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 14:50
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Угу, искажена вплоть до своей противоположности.

C>>Нет.

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

Ну и где тут противоположность?

C>>>>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.

ГВ>>>свойства — синтезируется;
C>>Нет.

ГВ>Поиск тебе в помощь.


Открываем стандарт С++, смотрим, не находим, извиняемся?

ГВ>>>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;

C>>Нет.
ГВ>Как так? Неужто нельзя приклеить к объекту никаких данных? Ни указателем, ни базовым классом?
Это не атрибуты. Почитайте чтоли что такое атрибуты.

public  class TraceAttribute : OnMethodBoundaryAspect
{
  public override void OnEntry( MethodExecutionEventArgs eventArgs)
  {
    Trace.TraceInformation("Entering {0}.", eventArgs.Method);
    Trace.Indent();
  }
  public override void OnExit( MethodExecutionEventArgs eventArgs)
  {
    Trace.Unindent();
    Trace.TraceInformation("Leaving {0}.", eventArgs.Method);
  }
}



    [Trace( "MyCategory" )]
    private static void SayHello()
    {
        Console.WriteLine("Hello, world." );
    }
 
    [Trace("MyCategory")]
    private static void SayGoodBye()
    {
        Console.WriteLine("Good bye, world.");
    }




MyCategory: Entering Program.SayHello.
Hello world.
MyCategory: Leaving Program.SayHello.
MyCategory: Entering Program.SayGoodBye.
Good bye, world.
MyCategory: Leaving Program.SayGoodBye.




ГВ>>>события — синтезируется;

C>>Нет.
ГВ>>>делегаты — синтезируется;
C>>Нет.

ГВ>Этому топику
Автор: Геннадий Васильев
Дата: 28.08.02
больше шести лет.


Это костыли, пытающиеся их эмулировать. В языке их НЕТ.

ГВ>>>лямбда-выражения — есть в C++0x;

C>>Не есть, а будет. В данном топике речь вроде как не о C++0x вовсе.
ГВ>>>замыкания — есть в C++0x;
C>>Не есть, а будет. В данном топике речь вроде как не о C++0x вовсе.
ГВ>Уже есть. Что там когда было — не суть.
Не уже есть, а будет тогда, когда будет выпущен релиз компилятора языка С++0x.
И повторяю С++0x != C++, о котором речь.

ГВ>>>duck typing — статический (и это очень хорошо);

C>>Может Вы для начала узнаете для себя что такое утятина?
ГВ>Раньше предлагали устрицы. Снижается классность, снижается.
Ликбез: утятина не может быть статической. По определению. Не пишите больше таких глупостей, ок?


ГВ>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?

C>>Нигде их нет.
ГВ>А в документации есть. Дока врёт?
Ссылку на соответствующий раздел документации в студию.

C>>>>О, ужас.

ГВ>>>А что не так?
C>>А Вы сами не видете?
ГВ>А по сути?
А по сути — О, ужас. Других слов нет.
Re[7]: За что я не люблю С++
От: esil  
Дата: 26.05.09 15:19
Оценка: +1
Здравствуйте, criosray, Вы писали:

ГВ>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
C>>>Нигде их нет.
ГВ>>А в документации есть. Дока врёт?
C>Ссылку на соответствующий раздел документации в студию.


ISO/IEC 14882, пункт 10.3.5
Re[8]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 15:33
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Поиск тебе в помощь.

C>>Открываем стандарт С++, смотрим, не находим, извиняемся?

ГВ>Нет, в смысле — в гугль. Слова C++ и property.


Еще раз для тех, кто читать не умеет: открываем стандарт С++, смотрим, не находим, извиняемся.

ГВ>>>>>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;

C>>>>Нет.
ГВ>>>Как так? Неужто нельзя приклеить к объекту никаких данных? Ни указателем, ни базовым классом?
C>>Это не атрибуты. Почитайте чтоли что такое атрибуты.

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


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

ГВ>>>Этому топику
Автор: Геннадий Васильев
Дата: 28.08.02
больше шести лет.

C>>Это костыли, пытающиеся их эмулировать. В языке их НЕТ.
ГВ>О-о-о... Это повод для большого флейма — какими должны быть делегаты.
Какого флейма? Они либо есть, либо их нет. В С++ их нет. О чем тут флеймить? Аналогично linq, lambda, events, attributes, properties, implicit typing, duck typing и многое другое.

C>>Не уже есть, а будет тогда, когда будет выпущен релиз компилятора языка С++0x.

C>>И повторяю С++0x != C++, о котором речь.
ГВ>Я тебе скажу больше MSVC6 != MSVC2K5, MSVC2K5 != MSVC2K10 и т.п. Что теперь, ругаться на C++, оперируя глюками MSVC6? И кроме того, внимательно смотрим на дату сообщения.
Замечательно. "Все смешалось в доме Облонских". Вы разницу между языком программирования и средой разработки не видите совсем?

ГВ>>>>>duck typing — статический (и это очень хорошо);

C>>>>Может Вы для начала узнаете для себя что такое утятина?
ГВ>>>Раньше предлагали устрицы. Снижается классность, снижается.
C>>Ликбез: утятина не может быть статической. По определению. Не пишите больше таких глупостей, ок?
ГВ>Что-то ничего не понимаю
Автор: VladD2
Дата: 25.05.09
.

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

ГВ>>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?

C>>>>Нигде их нет.
ГВ>>>А в документации есть. Дока врёт?
C>>Ссылку на соответствующий раздел документации в студию.

ГВ>ISO/ANSI 14882:1998, Раздел 10.3.5.


Нету там contravariance.
Re[7]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 15:34
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>>>Это говорит только о том, что в языке их не хватает.

ГВ>>Ну вот, теперь твоя очередь. ИМХО, если фича синтезируется, то и рассуждать не о чем.
LVV>Не... Есть... Синтезируется — это не стандарт определения языка, а реализация конкретного разработчика интегрированной среды...
LVV>При переходе со среды на среду — придется разбираться, как там эти фичи синтезированы.

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

LVV>Ну так еще и нет жиж...


Блин, Валерий Викторыч, Intel C++ 11.0. И ещё сейчас MS выложила бету VS2010.

ГВ>>>>интерфейсы — полностью выражается средствами pure virtual;

LVV>>>Нормально. Но почему-то в других языках сочли необходимым такую конструкцию явно определить
ГВ>>Видимо, из-за отсутствия множественного наследования.
LVV>Видимо, множественное наследование ликвидировали из-за наличия озвученных проблем. И сочли за благо ввести отдельную конструкцию.

Каких проблем?

ГВ>>Дык — не надо ж. Он там в качестве контраргумента всё время рассуждает о непонятности внутреннего устройства буста.

LVV>Для него — действительно жуть... Меня тоже только крайняя нужда заставит буст использовать...

ИМХО, это зря.

LVV>Но вообще статья, конечно, оставляет впечатление, что писал достаточно опытный программер, которому ПРИШЛОСЬ перейти на С++ по необходимости.

LVV>А это — действительно УЖОСССССС!!!!!

Не знаю, у меня ощущение, что программер-то, может быть, и опытный, но очень сильно путает субъективное и объективное.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 15:48
Оценка: :)
Здравствуйте, esil, Вы писали:


C>>Нету contravariance. Нету.


C>>

C>>The return type of an overriding function shall be either identical to the return type of the overridden func-
C>>tion or covariant
with the classes of the functions.



E>Это как, простите?


http://hestia.typepad.com/flatlander/2008/12/c-covariance-and-contravariance-by-example.html
Re[4]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 16:20
Оценка: :)
Здравствуйте, -MyXa-, Вы писали:

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


C>>В статье почти все правда. Просто преподнесена она так, чтоб сильно задеть программистов С++ и местами немного искажена.


MX>Почти всё? Примеры?


C>>Отлично. Напишите универсальный сериализатор в XML/Json.


MX>Жду списка недостатков следующих библиотек:


MX>TinyJSON

MX>jsoncpp
MX>zoolib
MX>Jaula
MX>JOST
MX>JSON Spirit
MX>CAJUN

Это все просто парсеры. Сериализатор это не парсер (точнее парсинг конечно же является элементов десериализации).
Сериализация это способ автоматически преобразовать граф объектов в текстовое в данном случае — JSON представление.
Иными словами:


var myComplexObjectGraph1 = IoC.Get<ComplexObjGraph>();

var jsonString = JsonHelper.Serialize(myComplexObjectGraph1);

...

var myComplexObjectGraph2 = JsonHelper.Deserialize<ComplexObjGraph>(jsonString);

Debug.Assert( myComplexObjectGraph1 == myComplexObjectGraph2);


MX>>>2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько.


C>>Простых? Удобных?

C>>"Огласите весь список пжалуста!"

MX>"Всего даже я не знаю". Я пользовлся Boost.Serialization, SF из RCF и одной собственного изготовления.

MX>А по поводу простоты, расскажите нам на пальцах — как в Яве не сериализовать какое-нубудь поле в сериализуемом классе? И ещё хотелось бы про версионизацию тоже узнать.

Повторяю еще раз. "Persistance библиотека" это в первую очередь различные O/RM: nHibernate, LightSpeed, EntityFramework, и т.д.

Список аналогов на С++ в студию.

MX>>>8) "А как же исключения (exceptions), а как же RTII ?. За них то я всегда плачу всегда !!!". Караул! Заявляю — RTII в С++ никогда не было,

C>>RTTI, а не RTII в С++ было, есть и будет.
MX>У аффтара — RTII. Вообще, у него в тексте вагон опечаток. У него, наверное, ко всему такой подход.
MX>>>и не предвидится следующие лет 10 точно.
C>>Какой кошмар...
MX>Зато — правда.
Только в Ваших фантазиях.

http://en.wikipedia.org/wiki/Run-time_type_information

MX>>>9) "будет изменена лишь копия объекта, которая сразу же после этого будет разрушена. Здорово, а ?". А некоторые языки, например, не позвляют выразить тот факт, что переданный в метод объект не будет изменён методом, которые принимает этот объект в качестве параметра.


MX>А на это есть что ответить?


public void Foo(Object obj) 
{
   obj = obj.MemberwiseClone();
   ...
}



C>>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.


MX>Вы считает это _базовыми_ понятиями? Очень интересно. А Вы знаете, что даже цикл — не базовое понятие?

Базовое.
MX>свойств в языке нет, но это не значит, что нельзя написать window.visible = true, чтобы лучше разглядеть окно.
Замечательно. Только после window.visible = true Вам придется написать еще window.refresh()
А как на счет проверки корректности ввода? А read-only свойства?
В итоге придете getVisible(), setVisible().
Очень удобно и выразительно... ничего не скажешь.
MX>события, делегаты? они в каком-то есть языке? круто. а мы, опять-таки — библиотеками обходимся.
И мне Вас очень жаль.
MX>лямбда-выражения, замыкания? в старом стандерте-таки да — нет. Но это не мешает нам написать std::for_each(c.begin(), c.end(), std::cout << _1 * _1 << std::endl);

Зато мешает Вам писать так:

var employees = db.Employees.Single(e => e.id == id);


и так:

foreach(var mult in arrNumbers.Where(n => n % Convert.ToInt16(strNum) == 0))


и так:


double Sqrt(double x)
{
    Func<double, bool> Good_Enough = (guess) => 
        Math.Abs(Square(guess) - x) < 0.001;
    Func<double, double> Improve = (guess) =>
        Average(guess, x / guess);
    Func<double, double> Iter = null;
    Iter = (guess) =>
        {
            if (Good_Enough(guess))
                return guess;
            else
                return Sqrt(Improve(guess));
        };
    return Iter(1.0);
}


MX>duck typing? покажите пример на Яве, скажу спасибо. А template в С++ — это не оно? Точно? А почему?

Ява тут при чем?


import System.Threading

def CreateInstance(progid):
   type = System.Type.GetTypeFromProgID(progid)    
   return type()    

ie as duck = CreateInstance("InternetExplorer.Application")
ie.Visible = true
ie.Navigate2("http://www.go-mono.com/monologue/")

Thread.Sleep(50ms) while ie.Busy

document = ie.Document
print("${document.title} is ${document.fileSize} bytes long.")



MX>интерфейсы? тоже отсутствуют. Покажите пример кода на С++, который будет красивее, будь в нём интерфейсы.

MX>covariance и contravariance?
MX>

MX>This variance refers to the parameters and return types of an overridden method in a descendant class. C++ supports this for covariance of return types. Return types and out parameters may be covariant, input parameters may be contravariant, and in-out parameters must be invariant. C++ example: ...

MX>и дальше
Замечательно. А теперь прочитайте ссылку, которую я привел раньше и попробуйте привести пример generic (co)contravariance на С++.


MX>>>После слов "Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" этого профана сил осиливать его поток у меня не осталось.

C>>Он правду сказал, а Вы классически "съехали на оскорбления", не могучи аргументированно ответить.

MX>Таки-да, отвечать на весь текст мне не захотелось. Если-б у него было достаточно ума, чтобы обсуждать дефекты стандарта С++ — другое дело. "аргументированно ответить", говорите? Среди моих ответов нет таких — "О, ужас.". А про "как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" я ответил выше.


Ваши ответы все в духе "о, ужас", так как Вы банально не знаете возможностей других языков.
Re[9]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 18:48
Оценка: -1
Здравствуйте, criosray, Вы писали:

ГВ>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx

C>Это не свойства.

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

C>Это костыль, который пытается их эмулировать.


Ну знаешь, если любую библиотеку так называть, то библиотеки вообще не стоит разрабатывать.

C>В языке С++ нету свойств. тчк


Никто и не говорил, что в самом языке C++ есть "свойства".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:12
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Действительно... в чем разница...


ГВ>Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.


И, кстати, небольшой ликбез для Вас:


public class Test<T>
{
   public T GenericAutoProperty { get; set; }
   ...
}

...

ver testString = new Test<string>();
var str = testString.GenericAutoProperty;
Re[14]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:30
Оценка: +1
Здравствуйте, Хвост, Вы писали:

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


1. Читабельность кода.
2. Compile time проверка корректности типов и именования.

void setBAr(int a);
long getBaR();


vs

public int Bar { get; set; }
Re[14]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.05.09 19:59
Оценка: +1
Здравствуйте, Хвост, Вы писали:

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


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


Х>
Х>class Foo
Х>{
Х>public:
Х>  void bar(int bar) { m_bar = bar; }
Х>  int bar() const { return m_bar; }
Х>private:
Х>  int m_bar;
Х>};

Х>//...
Х>Foo f;
Х>f.bar(10);
Х>int bar = f.bar();
Х>//...

Х>


Х>?

Х>вот реально, в чём цимес пропертей? не, ну я вижу ужасающий синтаксический оверхед в вслучае геттера в виде двух скобок, и в случае сеттера тоже, да (правда '=' писать не надо), однако всё ещё не считаю ето поводом для внесения пропертей в фичу языка, а ты как считаешь?

Тривиальный пример:
f.Bar += 10;


Тоже самое без пропертей:
f.setBar(f.getBar() + 10);



Обычно наличие пропетей сопровождается метаданными. Это позволяет делать байндинги, property-gridы и прочие разодсти связывания с данными.
Очень показательный пример с Java,где на уровне языка пропетри не поддерживаются, то многие фреймворки в своих метаданных оперируют именно пропертями, которые в коде обязытельно должны соотвествовать методам getPropName и setPropName. Надеюсь не надо объяснять какие грабли это создает
Re[18]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 20:32
Оценка: +1
Здравствуйте, MxKazan, Вы писали:


MK>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.


Кстати, единственное чего не хватает в С# — макроподстановки имени свойства:

public int Height
{
   get { return _height; }
   set {
      _height = value;
      OnPropertyChanged("Height");
   }
}


Есть конечно вариант решения с лямбдой и рефлексией: OnPropertyChanged(o => o.Height);
Но очевидный перформанс хит в данном случае делает такое решение часто недопустимым...

Конечно генерация кода с помощью T4-шаблонов ликвидирует возможность опечатки, но хотелось бы все-таки макроподстановку. Тем более, что это совсем не сложно сделать, имхо.
Re[4]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 26.05.09 21:12
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Сериализация почти всегда нужна в контексте решения задач наподобие построения протокола обмена данными


Это называется взгляд через замочную скважину.
Re[2]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 21:58
Оценка: -1
Здравствуйте, doarn, Вы писали:

D>3. Нельзя объять необъятное, значительная часть запрошенных фичей эмулируется либо 1:1 (что чаще), либо с потерями в объеме кода ну максимум в два раза. Есть конечно вещи, которые толково не реализуются ну никак. Ну дык никто не будет спорить что язык придавлен грузом легаси и в общем-то на данный момент устарел. Но! Это еще не повод его демонизировать.

C++ подвергался "демонизации" добрых 10 лет тому назад. Его жестко критиковали даже такие личности, как небезызвестный Линус Торвальдс.

D>PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность (собственно упираемся в скорость

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

D>кстати, что совсем нелишнее), как там с этим дело у опирающихся на рантайм-метаинформацию сериализаторов Java или, zomg, Питона? =)

Конкретно на нащих проектах — более чем достаточная (речь о С#, но Java тоже где-то там).

D>PPS: а вот на шарпе аккуратное освобождение ресурсов приходится эмулировать жуткими костылями, дискасс

Ну уж точно менее жуткими, чем С++ с зоопарками shared_ptr<> auto_ptr<> и прочих костылей. Да и что такого жуткого в операторе using? Вы можете предложить лучшее решение?
Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.
Re[3]: За что я не люблю С++
От: doarn Россия  
Дата: 26.05.09 22:35
Оценка: +1
Здравствуйте, criosray, Вы писали:

C>C++ подвергался "демонизации" добрых 10 лет тому назад. Его жестко критиковали даже такие личности, как небезызвестный Линус Торвальдс.

10 лет назад, С++ несколько другой был, как и сознание о способах использования. + альтернативы ему в мейнстриме — не существовало в принципе, так что в 1999м наезды на С++ были разговорами в пользу бедных. Когда там Java 1.5 вышла, где-то в районе 2003-2004го? А второй шарп?

D>>PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность (собственно упираемся в скорость

C>чтения/записи памяти) на данных умеренно-сложной структуры (поддерживая при этом возможность частичной десериализации
C>Эта цифра абсолютно ни о чем не говорит. Да и сериализация-то у Вас поди бинарная?
Эта цифра например позволяет в терминах сериализации описывать внутренний ABI, не плодя сущностей для перевода сервиса в distributed состояние с сублинейной масшатабируемостью.

Цифра для бинарного варианта, в XML понятное дело помедленнее будет, да и используется только что бы веб-морде данные выплевывать. ORM на наших задачах использовать не только бессмысленно, но и вредно.

D>>PPS: а вот на шарпе аккуратное освобождение ресурсов приходится эмулировать жуткими костылями, дискасс

C>Ну уж точно менее жуткими, чем С++ с зоопарками shared_ptr<> auto_ptr<> и прочих костылей.
Стандартизованный костыль перестает быть костылем. Стандартизованный языковым комитетом или внутренним стандартом кодирования — то не суть важно при сколько-нибудь существенных масштабах. ГОСТ — хорошо, но на безрыбье и ТУ сгодится =)

C>Да и что такого жуткого в операторе using?

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

C>Вы можете предложить лучшее решение?

Последовательное применение концепции владения и времени жизни + инструментальные средства реализации. Второе зависит от языка/платформы, первое — дело сугубо дизайна и дает одинаковый результат будучи реализованных хоть на С++, хоть на Java, хоть другими средствами.
Re[2]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 26.05.09 22:51
Оценка: :)
Здравствуйте, doarn, Вы писали:

D>PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность


Угу. Отличная титановая лопата.
Re[15]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 01:59
Оценка: +1
Здравствуйте, criosray, Вы писали:

ГВ>>Я уж не знаю, почему так складывается, но как только кто-то выступает с резкой критикой C++, так такую пургу нести начинает — уши вянут.

C>Такой, как эта?
[...]

Да нет, такой как в топикстарте.

ГВ>>Любая. В твоем мире — если сериализация не встроена в платформу, то её нет, я уже понял. В моём — если какой-то фишки нет, то это означает, что она может быть любой.

C>Я еще раз прошу показать универсальный С++ сериализатор XML или Json для любого графа объектов. Двунаправленный. Дженерик (шаблонный).

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

C>Покажете или будете продолжать разводить демагогию и фанатичную чушь без единого факта по теме?


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

C>PS: Правильно тут кто-то недавно заметил, что те, кто хаят С# знают его на уровне чайника...


Как это давно замечено всеми, громче всех хают C++ те, у кого 15 лет опыта — это 15 раз по году, а больше похоже на 30 раз по 6 месяцев.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re: За что я не люблю С++
От: Sorantis Швеция  
Дата: 27.05.09 02:46
Оценка: +1
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

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

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

Откройте почти любую серьезную книгу (а не С++ за 24 часа) по С++ — о чем там написано ?
Как НЕ НАДО делать.


Scott Meyers: Effective C++, More Effective C++.
Книги о том как НАДО делать.
Да имхо действительно хороших книг по С++, таких как книги Мейерса, не очень то и много.

В связи с довольно частым упоминанием различия между ссылкой и указателем можно сделать смелый однако субъективный вывод что автор
за 15 лет работы понял истинное значение только на седьмом году.


Не так давно я узнал, когда именно г-ну Степанову пришла идея библиотеки STL — когда он находился в отделении интенсивной терапии (после отравления рыбой) в, как он сам написал, "delirium state", по-просту — в состоянии БРЕДА.

А это пять!

Вобщем, кг/ам
As long as there is life, there is hope
Re[10]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 04:45
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну знаешь, если любую библиотеку так называть, то библиотеки вообще не стоит разрабатывать.
Не, не любую. Но если самая-пресамая библиотека всё еще требует для использовании некоторого паттерна писать кучу кода руками — то это однозначно костыль.
Если посмотреть на linq, то всё становится ясным. Код, который он генерирует для случая linq-to-sql, при конверсии обратно в C#2.0 просто взрывается. Потому что простейшие выражения превращаются в рутинный код порождения метаданных для разнообразных Expression<...>.
Что можно сделать в языке, где нет linq? Правильно, библиотеку для порождения Expression<...>. Увы — многословность будет зашкаливать.

ГВ>Никто и не говорил, что в самом языке C++ есть "свойства".

Да это не проблема. Проблема — в том, что их туда и вставить-то нельзя.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 07:16
Оценка: :)
Здравствуйте, doarn, Вы писали:

C>>>>Да и что такого жуткого в операторе using?

D>>>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.
D>>А можно парочку примеров непримитивных случаев ?
D>Когда ресурс (скажем read лок объекта) сохраняется в процессах неизвестного в точке вызова количества с непрогнозируемым временем жизни.
D>А если время жизни самого ресурса ограниченно?
D>А если ресурс нужно версионировать? =)

Вы вообще знаете что такое using?


try 
{
   ...
}
finally
{
   if (obj != null)
       obj.Dispose();
}



Все.

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


Ну и бред...

Можно поинтересоваться, а Вы Александреску на ночь читаете?
Re[10]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 07:53
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

ГВ>>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx

C>>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк
CC>А тебе надо чтоб именно в стандарте было вбито гвоздями?

Мне надо, чтоб свойства были в языке — чтоб ради определения одного свойства не требовалось возиться с созданием типов, шаблоноалександрескумагией и прочей мутотенью. Я должен решать задачи проекта, а не возиться с костылями языка.
Re[8]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 08:06
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

CC>>>А тут написанные библиотеки в комплект не входят.

MK>>В случае тех же свойств, не "библиотеку положили рядом", а компилятор научили работать. Всё-таки есть разница.
CC>По мне так один хрен.
CC>По мне так в компилятор надо впихивать то, что никак нельзя нормально реализовать через библиотеки.
В том то и дело, что нормально реализовать свойства через библиотеки нельзя — это будет мега пупер изврат. Страшно представить хотя-бы то, как со всеми этими библиотечными наворотами отлаживаться. Ведь аналога метаданных, понимаемых дебаггером, не будет.
Re[12]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 08:49
Оценка: +1
Здравствуйте, neFormal, Вы писали:
F>должно компиляться и нормально работать..
Нет, не должно. Ну, то есть кроме компиляться.
Во-первых, то, что после "//или" делает не то что нужно.
Во-вторых, покажи мне, как будет выглядеть аналог Test.A+=5?
К примеру, отрезаем последний символ в StringBuilder:
sb.Length--;
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 09:22
Оценка: +1
Здравствуйте, neFormal, Вы писали:

F>да, оно делает не всё, что делается в шарпах, я знаю..

Нет, оно делает не то. Ты же оператор перегрузил не для свойства, а для класса.
F>на этом пытаются подловить все поклонники шарпов в этом треде..
F>но в ограниченных условиях — работает :Р
Ни в каких не работает.

S>>Во-вторых, покажи мне, как будет выглядеть аналог Test.A+=5?

F>на голых плюсах нельзя же..
Можно, но будет очень многословно.
F>можно, наверное, сделать шаблон типа shared_ptr, который будет реализовывать всё это.. правда пухло получится..
Нужный шаблон был приведён выше по ветке. Ну вот только пример с его применением написать поклонники С++ стесняются.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 12:37
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>В итоге всё и кончается

S>
S>  BEGIN_PROPERTY_LIST(Test)
S>  END_PROPERTY_LIST(Test)
S>


хе, примерно о подобном тоже думал..

F>>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..

S>Ну так это и есть костыль — неэстетично выглядящая подробность реализации.

-1.. "костыльность" — это вопрос не эстетики, а общепринятости..

F>>по сути это что то схожее с property от микрософта..

S>Да-да, я в курсе про многообразные костыли.

так можно дойти до идеи, что не встроенный ORM — жуткий костыль..
...coding for chaos...
Re[20]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 27.05.09 13:29
Оценка: +1
ГВ>
ГВ> class Test
ГВ> {
ГВ>   public:
ГВ>     PROPERTY(Test, int, a, get_a, set_a);
ГВ>     PROPERTY(Test, int, b, get_b);

ГВ>   protected:
ГВ>     void set_a(int v){ ... }
ГВ>     int get_a() const {  ... }
ГВ> }
ГВ>


ГВ> F>>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..


Угу. Вспоминатся Qt, где подобное реализовано для событий. Приходится препроцессор отдельный прогонять. А как только где-то что-то навернется, ни один дебаггер не спасет
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[22]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 13:41
Оценка: :)
Здравствуйте, NikeByNike, Вы писали:
NBN>А если память нужна кому-то ещё?
Это то же самое. Когда память становится нужна кому-то еще, GC это замечает и начинает уборку.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 13:57
Оценка: :)
Здравствуйте, COFF, Вы писали:

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


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

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

COF>Посмотрел начало ветки:

>>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.
COF>Логично предположить, что свойства как базовые понятия таки необходимость.
Оууу. Понятно. Приношу извинения. Это скорее я начал читать не с того поста.

COF>Первый ответ:

>>свойства — синтезируется;

COF>Выяснили, что действительно синтезируется, не совсем так как в C#, но есть. Галочку можно поставить Особенно, если они не абсолютная необходимость. Но изначально-то вопрос стоял о том, что свойства — это базовое понятие, только потом был умело повернут на соответствие свойств в C++ и C#.

И повернул его тот самый ответ, что синтезируются И галочку поставить у меня лично рука не поднимется. Ведь синтезируют. Значит нужно, но нету
Re[24]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 14:15
Оценка: +1
Здравствуйте, COFF, Вы писали:
COF>То есть, если я в конце любой функции буду писать GC.Collect — то это будет абсолютно нормально?
Нет, не будет. Я уже писал — само желание срочно пособирать мусор появляется от неправильного подхода. Пытаясь улучшить производительность, ты ее ухудшишь.
А задурить коллектору голову количеством потоков всё равно не получится.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: За что я не люблю С++
От: Antikrot  
Дата: 27.05.09 14:40
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.

вот это всем костылям костыль. так с языком чуть ли не что угодно сделать можно, не только проперти в плюсах приделать
Re[21]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 15:16
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Общепринятые костыли не становятся менее костыльными. См.напр. MFC.


MFC, кстати, вообще интересный феномен. Столько, сколько ругали MFC, наверное, не ругали ни одну другую библиотеку. А ей всё фиолетово — цветёт и пахнет.

S>Впрочем, по сравнению с джавой ORM для C++ будут вообще инвалидной коляской.


Спорный вопрос. Очень спорный. Я вообще подозреваю, что ORM — это какая-то большая ошибка природы. Но это пока только подозрения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 15:40
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>MFC, кстати, вообще интересный феномен. Столько, сколько ругали MFC, наверное, не ругали ни одну другую библиотеку. А ей всё фиолетово — цветёт и пахнет.

Так в том-то и дело, что цветёт. И даже (ой!) пахнет.

ГВ>Спорный вопрос. Очень спорный. Я вообще подозреваю, что ORM — это какая-то большая ошибка природы. Но это пока только подозрения.

Надеюсь, это не от того, что их в плюсах хрен поддержишь?

Между прочим, исторически первая ООDB до сих пор жива и работает на Smalltalk. Там как раз всё построено на фичах, аналогичных применямым в Linq. Безо всяких костылей. А вот Verant, к примеру, включал в себя отдельный компилятор метаданных, без натравления которого на С++ исходник ничерта не работало.

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

Фишка в том, что ORM, как таковые, в общем-то, не нужны. Что нужно — так это нормальный типизированный доступ к данным (lightweight-ORM) без геморроя.
Ну так вот даже такую малость, без change tracking, lazy loading, и identity map, на плюсах нормальным образом не вырулишь. Даже с помощью макросов. Всё время будет не хватать каких-то мелочей.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: За что я не люблю С++
От: blackhearted Украина  
Дата: 27.05.09 16:09
Оценка: :)
Я вот чё-то не пойму...

Ну не нравится вам С++, ну так не пишите на нём,не читайте форумы,установите себе в почтовой программе фильтр на слово "С++", аналогично поступите в браузере и мессенджере...
И будет вам — спокойно.
Зачем лаять с видом знатока с 15и летним опытом (именно видом,так как некоторые тезисы очень напоминают одного местного фаната одной ОС с ником на букву S.)?
Re[2]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 16:27
Оценка: +1
Здравствуйте, blackhearted, Вы писали:

B>Я вот чё-то не пойму...


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

B>И будет вам — спокойно.
B>Зачем лаять с видом знатока с 15и летним опытом (именно видом,так как некоторые тезисы очень напоминают одного местного фаната одной ОС с ником на букву S.)?
B>
Мы ж в КСВ!!!
Re[4]: За что я не люблю С++
От: crable США  
Дата: 27.05.09 16:59
Оценка: +1
Здравствуйте, Antikrot, Вы писали:

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


C>>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.

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

не покажешь аналог FxCop для C++, сравнимого качества, бесплатный и расширяемый?
The last good thing written in C was Franz Schubert's Symphony No. 9.
Re[18]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:54
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Значит показать не можете? "Слив засчитан" (уж простите мой жаргон, которому я набрался в этом форуме).


ГВ>Могу, разумеется, но не буду. Могу даже сам написать, но мне хватило твоей реакции на IoC-контейнер. Лишний раз выслушивать рассуждения об ужасе, затычках и уродстве... Есть одна поговорка на этот счёт, которую я не хочу прилюдно напоминать.


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

Не надоело писать глупости, уважаемый? Вы уже сидите в такой луже, что мне Вас становится жаль... и каждым подобным ответом только усугубляете свое положение.
Re[20]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 01:03
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

C>>В С++ не возможно генерировать и исполнять произвольный код в рантайм.


ГВ>Это на каком заборе так написано? Или опять — в википедии?


Это на каком заборе написано что можно?

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


ГВ>"Структура словарного типа" — это что такое?


Почитайте в википедии или на том заборе, где Вы вычитали, что в С++ есть возможность генерации машинного кода на лету.
Re[12]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 01:05
Оценка: +1
Здравствуйте, NikeByNike, Вы писали:

C>>>>Начнем с того, что С++ не является универсальным языком. На этом и закончим.


NBN>>>Универсальным не является, но является (со своей сопутствующей поддержкой) наиболее универсальным среди распространённых.


C>>Поделитесь критериями универсальности?


NBN>А головкой подумать?


Если подумать головкой, то С++ по ряду критериев более далек от универсальности чем, например, Java.
Re[2]: За что я не люблю С++
От: _d_m_  
Дата: 28.05.09 08:47
Оценка: :)
Здравствуйте, Sheridan, Вы писали:

S>dmitry_npi wrote:


>> Да нет, я-то сам его люблю. Случайно наткнулся на статью

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

S>Я даже читать не буду


Ты как страус зарыл голову с песок.
Re[27]: За что я не люблю С++
От: COFF  
Дата: 28.05.09 09:35
Оценка: :)
Здравствуйте, criosray, Вы писали:

COF>>Жжошь неподецки


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


Согласен, правильнее писать Жжош Посыпаю голову пеплом
Re[28]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 09:52
Оценка: :)
Здравствуйте, Хвост, Вы писали:

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


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

C>>>>Программисты С++ уже и гуглем пользоваться разучились? http://en.wikipedia.org/wiki/Associative_array
COF>>>Жжошь неподецки
C>>Вы, молодой человек, постыдились бы своей необразованности вместо того, чтоб выставлять ее на показ.
Х>Я конечно люблю и уважаю русский язык тоже, но извольте, барин, где вы взяли ету "структуру словарного типа"? А так ведь можно и КД-ПЗУ ввернуть ненароком, дескать, чтоб "уровень образованности" показать

Сегодня просто повальное количество откровений г-д С++ников. Оказываются они совсем не в курсе о базовой структуре данных, называемой словарем (ассоциативным массивом, картой и т.д.).
Ликбез:
Что до того зачем я "ввернул", как Вы соизволили выразиться, так вот за тем, что объект есть суть ассоциативный массив. В динамических языках типа джаваскрипта так вообще объекты есть ни что иное, как словари.

http://www.quirksmode.org/js/associative.html
Re[4]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 10:07
Оценка: :)
Здравствуйте, blackhearted, Вы писали:

B>А где же сам Шеридан?

B>Тут же говорят плохие вещи на "Цэ два плюса и куча минусов"
В КСВ мы все немножко Шериданы Так что считай он как суслик
Re[31]: За что я не люблю С++
От: Хвост  
Дата: 28.05.09 10:30
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>>>Ликбез:

C>>>Что до того зачем я "ввернул", как Вы соизволили выразиться, так вот за тем, что объект есть суть ассоциативный массив. В динамических языках типа джаваскрипта так вообще объекты есть ни что иное, как словари.
Х>>ну вы так за все реализации жаваскрипта не говорите, в V8 например от етого отказались и поимели нехилый профит, за подробностями — в гугол.
C>Это тут вообще при чем?
притом, что выделенная фраза не верна
People write code, programming languages don't.
Re[12]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 10:56
Оценка: :)
Здравствуйте, Antikrot, Вы писали:

MK>>>>>Так я не понял: он "энфорсит" или просто предупреждения выдает?

C>>>>Энфорсит, выдавая предупреждения. fxcop и stylecop — составная часть автоматического билда у нас.

A>>>так бы и написал сразу — "бьёт по рукам"


C>>А я так и написал. Кто Вам виноват, что Вы не знаете, что слово "энфорсить" означает "вынуждать", "обязывать", "заставлять".


A>Я еще с десяток переводов знаю.


Не заметно.

A>Гугл вам поможет понять разницу между "error" и "warning". А вот понять разницу между "предупредить" и "заставить" вам помогут в старших классах.


Вам к сожалению не помогли.
Re[24]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 11:31
Оценка: :)
Здравствуйте, COFF, Вы писали:

COF>О, как! Когда я в соседней ветке написал, что придется после (ну или вместо — что смысла не меняет) присваивания звать подобный метод, то меня обвинили в ламерстве. Теперь оказывается, что таки да. Еще можно вспомнить ручной инлайнинг...


Почти всегда ты захватываешь владение, получая ресурс или другой ResourceWrapper в аргументы конструктора. Эти два конструктора аналогичны конструкторам std::tr1::shared_ptr'а. В остальных случаях можешь вызывать «p.Assign(other)», что аналогично плюсовому «p.operator =(other)».

COF>В общем, картина начинает проясняться


Ага, поставь ещё больше этих забавных жОлтеньких смайликов. А то сразу и не понятно, насколько ловко ты всех уел своим «картина начинает проясняться (жОлтенький смайлик)». Впредь я не буду тратить времени на подобные дешёвые заманухи.

Ты таки настаиваешь на том, что подсчёт ссылок — техника исключительно приплюснутых?
Глаза у меня добрые, но рубашка — смирительная!
Re[13]: За что я не люблю С++
От: Antikrot  
Дата: 28.05.09 11:42
Оценка: :)
Здравствуйте, criosray, Вы писали:

тьфу на ВАс

A>>Гугл вам поможет понять разницу между "error" и "warning". А вот понять разницу между "предупредить" и "заставить" вам помогут в старших классах.

C>Вам к сожалению не помогли.

ну у ВАс всё впереди. было бы неправильно, если бы молодые поколения не выучили что-нибудь сверх предыдущих
Re[32]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 11:59
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>>>Знаешь, первый раз слышу, чтобы "Objects as associative arrays" переводилось "объект есть суть ассоциативный массив". Это ты сильно задвинул.

C>>Я ничего не переводил. Вам по теме сказать больше нечего? Что такое словарная структура данных теперь знаете? Вот и отличненько.

ГВ>Исходно ты употребил словосочетание "Структура словарного типа". Разницу понимаешь?


Нет, не понимаю. У Вас проблемы с русским языком?

Понятия:

структура словарного типа
словарная структура данных
структура данных "словарь"

абсолютно идентичны.

Вам было банально нечего ответить по теме, вот Вы и решили потроллить... Но к несчастью для Вас факир оказался пьян...
Re[33]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 12:24
Оценка: +1
Здравствуйте, criosray, Вы писали:

ГВ>>Исходно ты употребил словосочетание "Структура словарного типа". Разницу понимаешь?

C>Нет, не понимаю. У Вас проблемы с русским языком?
C>Понятия:
C>структура словарного типа

Это структура типа "словарь" или некая структура, упомянутая в каком-то словаре? Кто на ком стоял?

C>словарная структура данных


Тот же вопрос. И между прочим, наиболее естественным выглядит ответ, что это некая структура данных, упомянутая в каком-то словаре.

C>структура данных "словарь"


Ну вот если бы так и было сказано...

C>абсолютно идентичны.


Да не идентичны они, в том-то и дело. Что интересно, в дальнейшем из контекста последовало, что лучше всего было бы сказать "ассоциативный массив", или "хэш-таблица", или вообще "мап" (транлитерация английского map — карта). Все бы тебя прекрасно поняли.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Подсчёт ссылок
От: COFF  
Дата: 28.05.09 13:00
Оценка: -1
Здравствуйте, Qbit86, Вы писали:

Q>Ага, поставь ещё больше этих забавных жОлтеньких смайликов. А то сразу и не понятно, насколько ловко ты всех уел своим «картина начинает проясняться (жОлтенький смайлик)». Впредь я не буду тратить времени на подобные дешёвые заманухи.


Нет, просто у меня была некая картина мира, которая была, что уж тут скрывать, поколеблена уверенными заявлениями от здешних евангелистов C#. И якобы все проблемы решены, и последняя версия фреймворка летает. А кто это понять не способен, тот ламер. Я пристально за управляемыми языками не слежу, был период, когда интересовался, нашел несколько возможных проблем и отошел от этого дела до лучших времен. Сейчас, было такое впечатление, лучшие времена настали. Но, поставил приложение которое тут порекомендовали — тормозит как и прежде, даже память утекает, все проблемы как были, так и остались. В общем, прояснилось, что это не я ламер, а что сторонники управляемых языков часто не понимают проблем, которые такой подход вызывает. Может быть, конечно, эти проблемы и преувеличены, но для меня существенны. В общем, подождем лучших времен, а там опять посмотрим.
Спасибо, кстати, Синклеру — он не стал скрывать проблемы, а честно написал, что они таки есть, в то время как остальные писали, что это баг и такого быть в принципе не может. В общем, я для себя выводы сделал, всем спасибо

Q>Ты таки настаиваешь на том, что подсчёт ссылок — техника исключительно приплюснутых?


Автоматический подсчет ссылок — да
Re[4]: За что я не люблю С++
От: blackhearted Украина  
Дата: 28.05.09 14:05
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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


___>>Ты как страус зарыл голову с песок.


S>Ну и что! Тут есть люди, зарывшие далеко не одну голову в песок.


Несогласных с мнением общественности убирают?
Re[31]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 14:23
Оценка: -1
Здравствуйте, criosray, Вы писали:

ГВ>>

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


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

C>Это Вы себе сами придумали.

Понятно. Значит, я придумал цитату из твоего собственного постинга. А сам твой постинг мне привиделся.

C>Что Вы от меня хотите услышать?


Да я уж не знаю, что от тебя можно хотеть услышать — у тебя ж перл на перле. Моя фантазия не хватать такой предел.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 15:09
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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


В C# отлично можно определить конструктор, принимающий параметр того же типа.

Класс shared_ptr выглядит примерно так:
template<class T> class shared_ptr
{
public:
  explicit shared_ptr(T* p);
  shared_ptr(shared_ptr const& other);
  shared_ptr const& operator =(shared_ptr const& other);
  ~shared_ptr();
}


Подстрочный перевод на C# выглядит так:
class RefCounter<T> : IDisposable
{
  public RefCounter(T t) { ... }
  public RefCounter(RefCounter<T> other) { ... }
  public void Assign(RefCounter<T> other) { ... }
  public void Dispose() { ... }
}

Найди 33 отличия.

S>Поэтому соглашение об инкременте указателя придется выполнять самостоятельно.


Поясни.
Глаза у меня добрые, но рубашка — смирительная!
Re[26]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 15:15
Оценка: :)
Здравствуйте, COFF, Вы писали:

Q>>Ты таки настаиваешь на том, что подсчёт ссылок — техника исключительно приплюснутых?


COF>Автоматический подсчет ссылок — да


Обоснуй.

int main()
{
  int const* const p_raw = new int(42);
  std::tr1::shared_ptr<int const> p(p_raw);
  std::tr1::shared_ptr<int const> q(p_raw);
  return EXIT_SUCCESS;
}

Почему тут не работает «автоматический» подсчёт ссылок? Что нужно сделать, чтобы заработал? Что мешает сделать то же самое в C#? Алсо, смотри здесь
Автор: Qbit86
Дата: 28.05.09
.
Глаза у меня добрые, но рубашка — смирительная!
Re[27]: Подсчёт ссылок
От: COFF  
Дата: 28.05.09 15:27
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

Q>
Q>int main()
Q>{
Q>  int const* const p_raw = new int(42);
Q>  std::tr1::shared_ptr<int const> p(p_raw);
Q>  std::tr1::shared_ptr<int const> q(p_raw);
Q>  return EXIT_SUCCESS;
Q>}
Q>

Q>Почему тут не работает «автоматический» подсчёт ссылок? Что нужно сделать, чтобы заработал? Что мешает сделать то же самое в C#? Алсо, смотри здесь
Автор: Qbit86
Дата: 28.05.09
.


На самом деле я понимаю куда ты клонишь, определенный смысл в этом есть. Основное отличие, что в C++ ты создаешь shared_ptr и потом работаешь только с ним (одно место о котором стоит помнить — создание объекта), т.е. чтобы сделать как ты написал надо специально постараться. А в C# очень легко написать аналог a = b вместо a = b.Copy() (а присваивание может встречаться произвольное количество раз) и в этом случае весь подсчет ссылок идет лесом. В принципе, я это имел в виду. То, что при должной дисциплине проблем можно избежать, я не сомневаюсь. Так же, как впрочем, и при должной дисциплине можно легко избегать проблем с памятью и циклическими ссылками в C++.
Re[28]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 20:28
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>>>Поэтому соглашение об инкременте указателя придется выполнять самостоятельно.

Q>>Поясни.
S>Очень просто. Вот у нас есть
S>
S>public static void EpicFail(HugeBitmap bmp)
S>{
S>  RefCounter<HugeBitmap> c;
S>  using(var a = new RefCounter<HugeBitmap>(bmp)); // bmp.refCount++;
S>    {
S>      var b = new RefCounter(a); // bmp.refCount++
S>      c = a; // oops... вот в этот момент С++ инкрементирует указатель. С# - нет.
S>    b.Dispose(); //bmp.refCount-- 
S>    } // bmp.refCount-- => bmp.Release()
S>    c.Reference.Draw(); // InvalidOperationException!
S>}
S>

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

А причём тут RefCounter, а? Эдак можно по отношению к любому disposable типу сказать, что им опасно пользоваться, потому что «c = a;». Подставь вместо RefCounter StreamReader, и увидишь ту же проблему, когда через одну ссылку ты уже закрыл поток, а через другую пытаешься из него считать.

S>
S>c = a; // oops... вот в этот момент С++ инкрементирует указатель. С# - нет.

Это не имеет абсолютно никакого отношения к оператору присваивания. Это имеет отношение лишь к пониманию человеком семантики косвенности. Я тебе такой же пример могу и на C++ слабать:
int* q = new int(3);
int* p = q;
*q = 42;
cout << *p << endl;  // «oops...» © Как же так, а куда делась старая тройка? Я ж её сохранил посредством p?

Человек либо понимает «семантику указателей», либо нет. «Помнить о том, что её надо не забыть» — ну ведь бред же! Потенциальная возможность запутаться в «c = a;» может быть спровоцирована, например, предшествующим C++-background'ом. То есть это не свойство языка, а скорее свойство программиста. Опытный дотнетчик со временем перестаёт воспринимать значок «=» в контексте плюсовой «перегрузки оператора присваивания».

S>Вся дупа в том, что нет в дотнете перегрузки оператора присваивания.


А я утверждаю, что есть. Называется Assign(), или Clone(), или Copy(), как удобно. Правда, не «перегрузка», и не «оператора», but who cares?

S>А конструктором копирования обязательно нужно не забыть попользоваться.


Вот не понимаю я этой фразы. Как так, не забыть? Типа, нужно мне отсортировать массив функцией Quicksort, но я её забыл, поэтому переставил в нём элементы функцией Reverse, так что ли? Либо мне нужна семантика обычного копирования ссылок, тогда я использую значок «=». Либо мне нужна какая-то другая логика, тогда я вызываю предусмотренную для того функцию.

S>>>Поэтому соглашение об инкременте указателя придется выполнять самостоятельно.


В .NET ты должен «помнить» (хотя при чём тут помнить, должен знать семантику операторов языка, если называешь себя .NET-программистом), что в нашей задаче так нельзя:
c = a;

а нужно так:
c.Assign(a);


В C†† ты должен «помнить» (опять же, лучше не помнить, а понимать), что вот так нельзя:
std::tr1::shared_ptr<int const> const q(p.get());

а нужно так:
std::tr1::shared_ptr<int const> const q(p);

33 отличия? :)
Глаза у меня добрые, но рубашка — смирительная!
Re[34]: За что я не люблю С++
От: drol  
Дата: 28.05.09 20:31
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Как раз таки — тип.

D>>Неправда.

ГВ>Я имел в виду именно тип самого члена класса.


А зачем Вы его имели в виду ? Он ведь и там, и сям есть.

ГВ>>>Where is a difference?

D>>Вам неясна разница между указателем и тем на что он указывает ???

ГВ>В терминах C++ метод нельзя передать как параметр иначе, чем в виде указателя.


Это личные проблемы C++. Разница между указателем и тем на что он указывает от этого не исчезает.
D>>Круто. И эти люди пишут на C++

ГВ>О! В том, что я не понимаю, что такое указатель, меня ещё никто не обвинял.


Вы что-то путаете. Свои заблуждения Вы демонстрируете сами. Я тут совершенно непричём
Re[29]: Подсчёт ссылок не получится!!!
От: Erop Россия  
Дата: 28.05.09 22:19
Оценка: :)
Здравствуйте, Qbit86, Вы писали:


Q>В C†† ты должен «помнить» (опять же, лучше не помнить, а понимать), что вот так нельзя:

Q>
std::tr1::shared_ptr<int const> const q(p.get());

Q>а нужно так:
Q>
std::tr1::shared_ptr<int const> const q(p);

Q>33 отличия?

Вообще-то в С++ в shared_ptr свет клином-то не упёрся. Бывают, например, интрузивные владеющие COW указаетли.
Мало того, в С++ я могу заиметь класс, в котором одно из полей будет таким умным указателем, при этом пользователи этого класса ничего про это знать не обязаны. А в ХиндиСи придётся и пользователю объемлющего классу от использования значка = воздерживаться и т. д...
Короче, IMHO? лучше в ХиндиСи парадигму COW не использовать... Ясно же, раз Хинди, значит на COW замахиваться нельзя!!!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[23]: Подсчёт ссылок
От: drol  
Дата: 28.05.09 22:19
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

using (StreamReader s = ...)
{

} // Dispose здесь «решает ту же проблему: забыли освободить ресурс нормальным образом.» ©

Я совсем про другое веду речь. Перечитайте мой предыдущий постинг ещё пару-тройку раз
*Намекаю — не о "неявности" разговор

using — это как раз тот самый "нормальный образ". От того что вызов Dispose() "вывалян в синтаксическом сахаре", он не перестаёт быть обычным вызовом метода в нормальном контексте исполнения кода. Деструкторы и финализаторы же вызываются совсем другим макаром.
Re[9]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 00:05
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>Вообще говоря в основе такой сериализации лежит алгоритм нахождения связных кусков на графе.

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

Можно проще. Хранить в архиве (объекте в памяти) указатели на всё, что в него записали. И перед записью очередного объекта, проверять, а не записан ли он уже? И если таки да, то сериализовать хитрую ссылку назад... То же и с типами. Типа когда тип встречаем впервые -- пишем метаданные, имя, или ещё чего, что там у нас предусмотренно. А потом только ссылки на это описание пишем и всё...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 29.05.09 08:36
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ещё раз, медленно: Найк, вроде бы, со мной согласен.


Еще раз, медленно — он может быть миллион раз с тобой согласен, но это никак не обесценивает приведенные им примеры и не делает эти примеры построением протокола обмена данными.
Re[33]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 29.05.09 08:51
Оценка: +1
Здравствуйте, criosray, Вы писали:

c> ГВ>>>

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


c> ГВ>Понятно. Значит, я придумал цитату из твоего собственного постинга. А сам твой постинг мне привиделся.


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


И наоборот, там нигде не говорится, что он должен каком-уто контракту соответствовать
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[3]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 29.05.09 10:33
Оценка: +1
Здравствуйте, Qbit86, Вы писали:

Q>Если бы это сборище костылей с 1K-страничным стандартом исчезло, это послужило бы толчком к появлению и развитию более удачных низкоуровневых языков. Современные компиляторы с C++ выдают эффективный код не благодаря языку C++, а вопреки. Создать компилятор C++ чрезвычайно трудно, причём это не столько объективная трудность, сколько борьба с тёмными углами языка.


Что-то в этой мвсли есть, но если бы такой язык был нужен, он бы ВЫТЕСНИЛ С++. Как в свое время вытеснили Фортран
With best regards
Pavel Dvorkin
Re[4]: За что я не люблю С++
От: Qbit86 Кипр
Дата: 29.05.09 11:18
Оценка: :)
Здравствуйте, COFF, Вы писали:

COF>Но с другой стороны, все это вызвано вполне естественными причинами.


Я бы предпочёл, чтобы в разработке языка обошлась без «естественных причин» типа совместимости с Си на уровне исходных кодов.

COF>Начни разрабатывать подобный язык с нуля, то в итоге либо C++ и получится


Голословное заблуждение.

COF>Сила (и слабость) C++ в том, что он результат более чем тридцатилетней эволюции (если и C тоже считать).


О какой эволюции может идти речь по отношению к языку, стандарт которого законсервирован на десяток лет? (Предупреждая возможные вопросы — да, я читал «D&E» Страуструпа.) Только сейчас в нём начинают появляться языковые средства (которым, по сути, сто лет в обед), которые уже давно стали нормой для современных ЯП. И ещё не скоро эти нововведения войдут в обиход (учитывая консервативность адептов).

COF>Посмотрим во что через двадцать лет превратится C# :)


Через двадцать лет он скорее всего благополучно преставится, и никто не станет по нему особо сокрушаться. Потому что на смену придут более удачные и удобные инструменты.
Глаза у меня добрые, но рубашка — смирительная!
Re[6]: За что я не люблю С++
От: Qbit86 Кипр
Дата: 29.05.09 12:09
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>А плюсы, в каком-то виде, продолжат таки небо коптить ;)


Как должно быть приятно себя чувствуешь, программируя на крестах, вроде как к вечности приобщаешься, да? Тёплый ламповый звук, всё такое?
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: Слова, золотые, как загар!!! ;)
От: Qbit86 Кипр
Дата: 29.05.09 12:40
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>Вот!!! Золотые слова!!! ХиндиС -- это СУРОГАТ!!! ;)


«Вы говорите об этом так, как будто это что-то плохое.»
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 29.05.09 16:06
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.

MK>>Конкретнее, что за ниша?

PD>Операционные системы, драйверы, утилиты. (только ради бога не надо про Сингуларити)

А ты там С++ много видел, особенно в ОС и дровах?

PD>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).

Расскажи это создателям AutoCad.

PD>ПО с серьезными расчетами.

Пока вы будете писать их на С++, вариант на F# уже давно все посчитает.
А есть еще runtime кодогенерация.


PD>Это то,что первым в голову пришло. Подумать — можно еще добавить.
Re[6]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 29.05.09 20:31
Оценка: :)
Здравствуйте, hattab, Вы писали:

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


PD>>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).

G>>Расскажи это создателям AutoCad.

H>Не, ну надоело уже... Что, правда, кроме WPF-морды Автокада упомянуть больше нечего? Вот незадача то... (ах да, ты еще Paint.NET с Photoshop'ом не сравнил )

Да, незадача. Приводили тут списочек прог, да только некоторым пофиг на него, делают вид, что его нет.. Кстати, о Paint.Net. Я тогда искренне поверил, что прога тормознутая. Так как сейчас обильно приходится заниматься дизайном приложения, потребовался редактор покруче Paint, но простой. Скачал Paint.Net Portable, 1.5 мега весом. И прямо вообще офигел. А обещанных тормозов то нет! На моем домашнем компе, который и 3 года назад то был средний и с тех пор не видел ничего нового, кроме винтов, Paint.Net просто летает. Так что, всё больше убеждаюсь, что приставка ".Net" действует на некоторых как красная тряпка для быка, хочется искать тормоза даже когда их нет.
Re[9]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 21:39
Оценка: +1
Здравствуйте, MxKazan, Вы писали:

CC>>По мне так в компилятор надо впихивать то, что никак нельзя нормально реализовать через библиотеки.

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

Некоторые дебагеры позволяют предоставлять им правила показа объектов...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[8]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 22:29
Оценка: :)
Здравствуйте, hattab, Вы писали:


H>Предлагаю объективный тест Выбери картинку побольше и наложи на нее фильтр Gaussian Blur с радиусом в 200 (побольше и 200 это для того, чтоб было что посмотреть). Теперь запусти GIMP и проделай то же самое (к слову, в GIMP'е настроек фильтра больше, можешь попробовать со всякими -- картины это не меняет). Уверяю тебя, приставка .Net будет порвана на твоих глазах раз десять точно (чем больше картинка тем ощутимее).


Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального. Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.
Re[2]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 22:34
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А есть в нем property или нет, и как там с сериализацией — господи, какие мелочи и пустяки!

Сразу видно как много (нет) Вам доводиться(лось) писать на дотнет и на С++.

Что до незаменимости С++ Вы не правы.
На МакОСи, например, не пишут почти на С++. У них есть Objective-C, которого как оказывается тоже на многое хватает.
Re[8]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 22:37
Оценка: -1
Здравствуйте, Erop, Вы писали:

E>>>

E>
E>
E>
E>

Очень содержательные у Вас ответы. Можно поинтересоваться какой у Вас опыт работы программистом дотнет?
Re[8]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 22:39
Оценка: :)
Здравствуйте, Erop, Вы писали:

MK>>Ты наверное искренне считаешь, что ХиндиС — это мега-супер-пупер прикол, из-за чего мы все испадстола пишем. Ахха


E>Да нет, набирать просто удобнее...


А мне удобнее набирать Иван, а не Егор. Вы не обидетесь, если впредь буду звать Вас Иван?
Re[34]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 22:44
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Так что, если хочешь продолжить обсуждение, будь добр сформулировать толком, что ты хочешь узнать. А то вариантов очень много.


Да нет, я вижу, что с Вами обсуждать нечего. Человеку, который так упорно доказывает, что 2+2=5, все-равно ничего не доказать.
Re[10]: Эх, выдыхай, однако...
От: criosray  
Дата: 29.05.09 23:00
Оценка: :)
Здравствуйте, Erop, Вы писали:

E>>>Да нет, набирать просто удобнее...

C>>А мне удобнее набирать Иван, а не Егор. Вы не обидетесь, если впредь буду звать Вас Иван?

E>А я тебя по складам тогда буду: Кри-О-Срай?


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

PS: Вы случайно не альтер-эго г-на Шеридана, кстати?
Re[12]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 23:42
Оценка: :)
Здравствуйте, Erop, Вы писали:


C>>>>Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального. Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.


E>>>Речь шла вроде о тормознутости .net, а не о удобстве интерфейсов...

C>>Так где тормознутость-то?
E>Ну там, у тебя, выделено...
И? Где тормознутость? Мне знаете ли как-то все-равно будет разовая операция выполняться n секунд или n+n*0.3 секунд. Гораздо важнее для меня как пользователя интуитивность и удобство интерфейса.

E>>>Кста, 5мп -- это довольно маленькая картинка...

C>>5мп довольно большая картинка. Особенно для непрофессионального использования.

E>После гонки мегапикселей даже средненькие мыльницы от 8 начинаются...

E>5 -- это ближе к камерофону...
Мегапиксели это маркетинговая фишка — замануха для глупых покупателей. Хорошие бюджетные зеркалки как раз те самые 5-6 МП.
Re[9]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 08:20
Оценка: +1
Здравствуйте, gandjustas, Вы писали:

G>не пондменяй понятия. не ресурсоемкий код, а линейные вычисления.

G>именно ресурсоемкий код выходит на managed быстрее.

Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 08:37
Оценка: +1
Здравствуйте, Erop, Вы писали:


C>>кстати, а зачем нужен этот blur в 200 (!) пикселей?


E>Например размыть фон


Чтоб размыть фон совсем не нужно 200 пикселей.
Re[14]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 09:59
Оценка: -1
Здравствуйте, Mamut, Вы писали:

c>> M>Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо


c>> Возможно. Опять же это уже скорее профессиональный уровень.


M>Далеко не профессиональный


А что тогда профессиональный уровень? А какой процент пользователей вообще знает, что такое "работа с RAW"?

Мамут, ей богу, Вы как ребенок...
Re[13]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 11:17
Оценка: +1
Здравствуйте, hattab, Вы писали:

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


E>>>>Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...


H>>>Если много винта, то скорее в винт все и упрется. Другое дело память и проц


G>>Тут еще вопрос насколько рано быстродействие программы упрется в быстродествие винта.


H>Как встретит нечто вроде "update xxxx where yyyy" на многомиллионной табличке, да с обновлением ключевых/индексируемых полей, так и упрется


Ты наивен как ребенок. Если не требуется как можно быстрее получить результаты апдейта, то и на быстродействие это сисльно не повлияет.
Re[18]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 12:03
Оценка: :)
Здравствуйте, hattab, Вы писали:


C>>>>Непринципиально быстрее. Было бы принципиально, переписали бы алгоритм на С и собрали бы каким-нибудь Intel C++.


H>>>Так не о том же речь


C>>А о чем речь? О ветренных мельницах?


H>Придется повториться:

H>

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


H>И как мы увидели, даже параллельность не спасла приставку...


Нет, это Вы перевели тему на обычное для вас меряние органов. Изначально речь шла о том, что мол Paint.NET "в десять раз" хуже, чем Гимп, что совсем не так. Мне абсолютно по барабану — будет блуринг выполняться 7 секунд или 10 секунд или даже 30 секунд. Мне важно в первую очередь удобство и интуитивность программы, а в этом плане пэинт далеко впереди.
Re[19]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 12:24
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>>>А о чем речь? О ветренных мельницах?


H>>Придется повториться:

H>>

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


H>>И как мы увидели, даже параллельность не спасла приставку...


C>Нет, это Вы перевели тему на обычное для вас меряние органов. Изначально речь шла о том, что мол Paint.NET "в десять раз" хуже, чем Гимп, что совсем не так.


Иди читать
Автор: hattab
Дата: 30.05.09
с чего все началось (особенно выделенное и дальнейшие слова MxKazan о Paint.NET. Видишь, даже не я это начал). Это раз. Я показал корректный замер где GIMP таки рвет Paint.NET, пусть не в 10, но в 7.4 раза (а вот это не принцпипиально ). Это два. Твой замер не корректен т.к. Paint.NET использовал преимущества двуядерного проца. Это три.

C>Мне абсолютно по барабану — будет блуринг выполняться 7 секунд или 10 секунд или даже 30 секунд. Мне важно в первую очередь удобство и интуитивность программы, а в этом плане пэинт далеко впереди.


Мне абсолютно пофиг на этот частный случай, однако он прекрасно демонстрирует картину в общем.
Re[13]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 14:02
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

G>До SQL Server дойдет нескоро.

G>Другие вендоры вряд ли решаться выкинуть существующий codebase.

Значит не даёт управляемая среда мега преимуществ выходит? Раз старый код жалко?

Но может быть это специфика БД. Но давай какую-нибудь другую область возмём? 3Д движки к играм, например, или распознавалки чего-нибудь, или редакторы видео, или сам предлагай...

Для всего этого производительность -- это ключевая фича. И где управляемые аналоги, которые рвут неуправляемые по производительности?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 14:16
Оценка: :)
Здравствуйте, Erop, Вы писали:

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


G>>До SQL Server дойдет нескоро.

G>>Другие вендоры вряд ли решаться выкинуть существующий codebase.

E>Значит не даёт управляемая среда мега преимуществ выходит? Раз старый код жалко?

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

E>Но может быть это специфика БД. Но давай какую-нибудь другую область возмём? 3Д движки к играм, например, или распознавалки чего-нибудь, или редакторы видео, или сам предлагай...

E>Для всего этого производительность -- это ключевая фича. И где управляемые аналоги, которые рвут неуправляемые по производительности?
Подожди, ты сам только что говорил про ресурсоемкие программы, а теперь говоришь исключительно о том, что требует только процессора.
Re[39]: Подсчёт ссылок
От: criosray  
Дата: 30.05.09 18:55
Оценка: :)
Здравствуйте, criosray, Вы писали:

MyXa, настоятельно рекомендую почитать http://www.codeproject.com/KB/dotnet/IDisposable.aspx
Re[22]: За что я не люблю С++
От: yuriylsh  
Дата: 30.05.09 23:47
Оценка: +1
Здравствуйте, hattab, Вы писали:

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


H>>>Paint.NET использовал преимущества двуядерного проца. Это три.


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


H>Я с Paint.NET'ом это удовольствие огреб в полной мере, со своим-то одноядерником Запускаю генерирование фрактала Мандельброт. Paint.NET открывает диалог с настройками этой отрисовки, а сам в фоне начинает считать и рисовать с текущими настройками (правда у меня есть сомнения, что настройки дефолтные, а не оставшиеся от предыдущих экспериментов). Что я имею? Я имею 100% загрузку проца и неотвечающие контролы. В общем, Paint.NET моей бутявке противопоказан


Да вааще что творят, а?!! Придумали тут многопоточность и многоядерность, ща вот еще GPGPU подятнеться. Это что ж твоя бутявка то делать будет? В топку их всех, в топку!!!

E>>У меня часто так бывает, что идёт какой-то долгий процесс и я в это время в чём-то ещё ковыряюсь. Так вот Я БЫ ХОТЕЛ, ЧТОБЫ ЭТО "ЧТО_ТО ЕЩЁ" НЕ ТОРМОЗИЛО МОЙ ДОЛГИЙ ПРОЦЕССС!!!


H>Решение есть Ставишь Prio (это экстендер к таск-менеджеру) (ссылки нет у меня ) и выставляешь тяжелому процессу самый низкий приоритет (Prio эти настройки сохраняет поэтому сделать это нужно только один раз). Я так видео иногда перекодирую, сразу в 4-5 VirtualDub'ах (про очередь знаю, если что ).


Ага, точно, и вообще, для графики и редактирования видео многопоточность категорически противопоказана (а особенно в 4-5 VirtualDub'ах)!!!
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[23]: За что я не люблю С++
От: hattab  
Дата: 31.05.09 06:11
Оценка: -1
Здравствуйте, yuriylsh, Вы писали:

H>>Я с Paint.NET'ом это удовольствие огреб в полной мере, со своим-то одноядерником Запускаю генерирование фрактала Мандельброт. Paint.NET открывает диалог с настройками этой отрисовки, а сам в фоне начинает считать и рисовать с текущими настройками (правда у меня есть сомнения, что настройки дефолтные, а не оставшиеся от предыдущих экспериментов). Что я имею? Я имею 100% загрузку проца и неотвечающие контролы. В общем, Paint.NET моей бутявке противопоказан


Y>Да вааще что творят, а?!! Придумали тут многопоточность и многоядерность, ща вот еще GPGPU подятнеться. Это что ж твоя бутявка то делать будет? В топку их всех, в топку!!!


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

E>>>У меня часто так бывает, что идёт какой-то долгий процесс и я в это время в чём-то ещё ковыряюсь. Так вот Я БЫ ХОТЕЛ, ЧТОБЫ ЭТО "ЧТО_ТО ЕЩЁ" НЕ ТОРМОЗИЛО МОЙ ДОЛГИЙ ПРОЦЕССС!!!


H>>Решение есть Ставишь Prio (это экстендер к таск-менеджеру) (ссылки нет у меня ) и выставляешь тяжелому процессу самый низкий приоритет (Prio эти настройки сохраняет поэтому сделать это нужно только один раз). Я так видео иногда перекодирую, сразу в 4-5 VirtualDub'ах (про очередь знаю, если что ).


Y>Ага, точно, и вообще, для графики и редактирования видео многопоточность категорически противопоказана (а особенно в 4-5 VirtualDub'ах)!!!

Y>

VirtualDub таки распараллеливается, чего ты так возбудился? А 4-5 инстансов использую т.к. он (VirtualDub), не то из-за кодеков, не то из-за ошибок во входящем потоке, иногда таки падает, и если использовать его очередь, то очередь он унесет вместе с собой. А так, один из 4-5 упал ночью, так и не страшно -- другие-то проболжают работать.
Re[42]: Ответ настоящего джедая
От: Sinclair Россия https://github.com/evilguest/
Дата: 31.05.09 17:34
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

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

За неимением классов, реализующих семантику присвоения значения, приклеить к ним ничего не удастся. Увы.
ГВ>Я уж не говорю об эстетике:
ГВ>
ГВ>var bOk = new StoredProperty<bool>(false);
ГВ>var bCancel = new StoredProperty<bool>(true);
ГВ>


ГВ>Это ж кошмар какой-то: алгебраические типы (!), new (!!), рефлексия (!!!),

Здесь нет никакой рефлексии. Рефлексия предусмотрена для другого случая.
ГВ>Извини, я не удержался.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 12:07
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, 0xC0000005, Вы писали:


C>(бред г-на с хацкерским ником вырезан цензурой)


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

C>Дотнет и джава прекрасно обходятся без недоразумения под названием "множественное наследование". boost и stl по структуре и удобству смотряться очень и очень бедно на фоне .NET Framework.


Итак начнём с реального примера, представте себе ОО дизаин, в котором есть ядро и то что доделывает сам клиент у себя, клиент не может менять код ядра, а только насоедовать классы, менять некоторый функционал и подменять core класс своим в рантайм. Так вот есть структура:
ClassA
| \
ClassB ClassC
/|\
ClassB1 ClassB2 ClassB3

В класс Α необходимо добавить один метод, если вы унаследуете от А, то он подменится, НО потомки оригинального А всё равно будут юзать оригинального родителя.

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

C>Множественное наследование такой же моветон, как и goto.


А у вас смотрю стиль автора текста, хотите так же о шарпе? Утка это так же тупо как аддресс функции, Делегация это так же наивно как сдвиг в сегменте

C>>А много ли явошарпы знают удобных, простых и "интуитивно" понятных способов расширить функционал языка? Вот у меня требование к либе, я хочу регить callbackи вот таким способом:

C>>alarmNotifier = GUIHandler::onAlarm + CoreRoutine::onAlarm
C>>и что? у вас есть "костыль"? или всё чего нету нам не надо? Ха, это мертвецки неправильно, и обычно такое отмирает как несовершенное.
C>То, что есть у Вас еще бОльший костыль.

C>obj.Alarm += OnAlarm;

C>obj.Alarm += (arg1, arg2) => { /* обработчик здесь */ };

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

C>Что до расширяемых .NET языков — смотрите Nemerle и Boo.


Я не говорю о других языках, я говорю о расширении в рамках одного языка, или Немерил с Бу компилятся родным шарповским компилятором?

C>>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>>logger::log(__filename__, __line__, "log text")


C>
C>catch(Exception e) {
C>   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
C>   throw;
C>}
C>


А вот это красота которую я от вас ожидал Как меня достали эти криворучки, которые думают что кинуть в лог всё что можно из стека это так круто, ведь там разберуться.
Вы опять кинули мне пример готового тёплого коричневого батончика, я просил номер строки, вы кинули весь Stack Trace, я знаю что это такое, и я знаю что взять стэк вызовов в С++ не составляет проблем.

А как взять имено номер строки в файле? Или это бага щарпа ещё не разработана?
Или в новой версии появится printFileAndLine и вы будете выдирать и парсить номер строки? Ах скока кода я перевидал с такими заплатками

C>И Вы осмеливались утверждать, что Вы что-то знаете об управляемых языках? Да уж по части логеров управляемые языки рвут неуправляемые (в т.к. С++), как тузик — грелку. Вам только мечтать об удобстве отладки и логирования, предоставляемых средствами управляемых сред.


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

А ЕСЛИ это не исключение?

C>>Ага, а теперь скажите мне, у меня огромный обьект, но я хочу сериализовать только, замете слово ТОЛЬКО хидеры во всей иерархий, вот так я это использовал:

C>>dataStream << Modifiers::HeadersOnly << hugeObject;

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


C>
C>    [JsonObject(MemberSerialization.OptIn)]
C>    public class LoginResult
C>    {
C>        private ResultErrors errors = new ResultErrors();

C>        [JsonProperty("success")]
C>        public bool Success { get; set; }

C>        [JsonProperty("errors")]
C>        public ResultErrors Errors
C>        {
C>            get { return errors; } 
C>        }
C>    }
C>



Не не не дядя, ты не понял меня, есть класс который тебе дал один мужик, и надо его сериализовать для бор машинки другого дяди, ты тут всего-то один программер в большом проекте, а не Вася Пупкин с проектом Хелло Бил где можно менять всё что под руку попало, Слабо повторяю?

C>Вы сначала заставьте это компиллироваться под С++


C>>public <T> void f()

C>>{
C>> T t = new T();
C>> t.f();
C>>}

Под плюсы подобный код? Давайте прямо так навскидку с компиляцией

template<class T>
void f()
{
T t;
t.f();
}

class A
{
public:
void f(){}
};

int main()
{
f<A>();

return 0;
}

Компилится, работает.

C>>Вот скажите мне серьёзно, хоть один реальный пример в рамках одного приложения(про распределённые системы отдельный разговор), когда на этапе компиляции тип обьекта не известен, а если он известен, то зачем его узнавать? Потеряли — плохой дизайн и кучерявые руки!!! + обрезанность языка.

C>COM

КОМ это прадед распределённой модели — это отдельный разговор, если уж хотите посмотреть как это может работать без мета инфы красиво, посмотрите на внука КОМа — CORBA в имплементации Шмидта над ACE

C>>

C>>void func1 ( A& a );

C>>void func2 ( A a );

C>>В чем разница между этими описаниями (кроме того, что возможно программист просто пропустил символ '&') ?

C>>а в чём разница между func1(a) и func1(a.clone()), в том что в первом варианте кодер забыл вызвать клон
C>>А как передать строку в Яве, чтобы она была output parameter? Вот смеху то, надо создавать холдеры, и почему в яве

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


C>>
C>>void f(String s)
C>>{
C>>    s = "I'm dummy";
C>>}
C>>


C>>переданный параметр не поменяется? и Вообще ни один параметр не поменяется? ах сколько говна было сьедено на этом миллионами программистами и тестерами. И вы говорите о том что управляемые языки там просты?

C>Миллионами индусокодеров?

C>Опять же, в С# есть out параметры.


C>А уж если кидаться какашками, то давайте вспомним в С/С++ классическую ошибку:

C>if (a = 1) { ... }

C>об которую спотыкаются даже опытные программисты. Что заставляет многих применять костыль:


C>if (1 == a) { ... }


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



Это хорошо что в шарпах есть аут параметры, хоть чего-то увидели в ошибках Явы.
А как строки относятся к языку? Этож не паскаль
и чем вам std::string не строка, когда-то веб сервак делал заточенный под одного клиента, так там все буфера отлично на этих строках работали.

C>>TO BE CONTINUED!!!

C>Не позорьтесь так больше.
Ну к вам это более применимо, 2 неправильных примера и незнание тематики (на С++ это не компилится итп)
Re[3]: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 14:14
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, 0xC0000005, Вы писали:


C>>У него было руководство по ООП — книга по паскалю. Занятно, как такой гений (как о нём тут шарписты шаркают) выбрал имено Паскаль 5.5, ведь в нём небыло обьектов, если помните Pascal with Objects был введён с версии 7.0 борландовсой ИДЕ [...]


ГВ>Тут ты ошибаешься. Ошибка простительная, ты мог этого просто не знать по юности. На самом деле, классы появились в 5.5, а в 6.0 уже появился Turbo Vision, в 7.0 — редактор с подсветкой синтаксиса. Это так, не полемики ради, а энциклопедистики для.


Насколько я помню в 6-ке классы появились как адд-он, хотя уже не вспомню точно как было.
Re[6]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 14:15
Оценка: +1
Здравствуйте, 0xC0000005, Вы писали:



C>>>>COM


C>>>КОМ это прадед распределённой модели — это отдельный разговор, если уж хотите посмотреть как это может работать без мета инфы красиво, посмотрите на внука КОМа — CORBA в имплементации Шмидта над ACE


C>>Кстати, совсем забыл указать на еще один ляп в Вашем посте. CORBA ну никак не может быть "внуком COM", т.к. появилась за два года до COM — в 91ом.


C>Давайте пробежимся по иерархий названий, но ActiveX, DCOM, OLE, DDE — это всё КОМ, и то что мелкомягкие называют новую версию не заставит меня называть одно другим, COM DDE

C>CORBA внук DDE, так вас больше устроит?
C>И говорив Внук я вовсе не имел ввиду что КОРБу сделали на основе КОМа, боже упаси, а вот по эволюции — КОМ это предшественник КОРБы
Чушь полная.

Немного ликбеза: COM и DDE были созданы с целью коммуникации между процессами в пределах одного компьютера.
CORBA и (много позже) DCOM были созданы для коммуникации между приложениями в сети.

Разницу чувствуете?

А Ваши бурные фантазии на тему кто чей внук/правну/дедушка/папка/мамка лучше оставьте при себе.
Re[4]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 14:22
Оценка: +1
Здравствуйте, 0xC0000005, Вы писали:

ГВ>>Тут ты ошибаешься. Ошибка простительная, ты мог этого просто не знать по юности. На самом деле, классы появились в 5.5, а в 6.0 уже появился Turbo Vision, в 7.0 — редактор с подсветкой синтаксиса. Это так, не полемики ради, а энциклопедистики для.

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

Я точно помню, как было — это был мой первый ОО-язык. Addon-ом, вернее библиотекой, был Turbo Vision (уже — в 6.0). Собственно, я хотел тебе намекнуть на другое: то, что ты говоришь, оно по сути правильно, но небрежность в исторических отсылках даёт лишний повод проигнорировать твои доводы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 14:39
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>>Во первых переход на личности не показывает вас с лучшей стороны,

C>Где Вы увидели личности?

Сиречь, хамишь ты даже сам не замечая этого. Почему я не удивлён?

C>>во вторых я говорил о вашей цитате Майерса, а не о самой его цитате. То что вы впихнули сюда это, вот что не по существу, не поленитесь написать одинм-двумя предложениями в чём проблема С++ поддержки множественного наследования, а не множественного наследования такогого.

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

Ты забыл добавить, что МН — это такой страшный монстр, который выскакивает из ниоткуда и живёт своей собственной жизнью. Всё смешалось в датском королевстве.

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

C>Вы не путайте наследование (inheritance) с реализацией (implementation). Так вот интерфейсы не наследуются, а реализуются. А наследование и в С# и в Java есть только одинарное.

Об том, в частности, и речь, что вместо одного полного механизма Java и C# дают кучу обрезков со своими названиями. А потом появляется, то строка — базовый тип, то цикл — базовая конструкция, то linq — foundation всея программирования.

C>>И какой-же геморой вас ждёт, когда интерфейс должен иметь один маленький метод.

C>Что должен делать интерфейс?
C>Сморозили очередную глупость. Интерфейс — это просто контракт.

Интерфейс — это интерфейс. Контракт — гораздо более общая штука.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 14:40
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

C>>>>>А ЕСЛИ это не исключение?

C>>>>Что "это"? сatch(Exception e) ловит все исключения (т.к. он является базовым классом для классов исключений в дотнет). Не знали об этом?
CC>>>Он о том, что запись в лог вызвана не в результате исключения или какой либо ошибки.
C>>Какая разница?
CC>Однако.
По существу какая разница?

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

C>>Наверно потому, что мы кроме С++ видели много более современных и качественных языков, чтоб иметь возможность судить здраво.
CC>Неа.
Да.

C>>>>Одна из реализаций. Как-там у нее с юникодом, кстати?

CC>>>y wstring USC2 100% поддерживается
C>>Разницу между std::string и std::wstring улавливаете?

CC>typedef basic_string<char, char_traits<char>, allocator<char> > string;

CC>typedef basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > wstring;

Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.

ЧТД.
Re[8]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 14:51
Оценка: :)
Здравствуйте, 0xC0000005, Вы писали:

C>И Ком и Корба имплементируют "КОМПОНЕНТНУЮ" модель, и даже idl у них на 99% одинаковый, и всё сводится к общению между компонентами, но КОРБА имеет дополнительные аспекты.

Одинаковый? А разработчики корбы и DCOM об этом уже знают?

C>В общем начали с одного, закончили терминами, как обычно и делает crioSray.


C>Кстати, криоСрэй, какой стаж работы на С++?

7 лет подряд с 95го по 2002ой. А Ваш?
C>На примере когда ты сказал что в С++ шаблоне нельзя вызвать неделарированный метод из T,
Где я это сказал? Опять фантазируете?

C>я могу сказать что С++ для тебя это Си с классами(если помнишь), и обсуждать темы такого порядка ты может только на уровне "Мне это не нравится и ВСЁ".

По сути что можете сказать?
Хотите услышать чем вариант дотнет лучше шаблона из Вашего примера?
Тем, что ошибка будет указана прямо в редакторе во время набора на строке f<B>(), где B — класс, не реализующий интерфейс, а в С++ только во время компилляции будет выдана ошибка при чем совсем в другом месте — на вызове
t.f() — будет указано, что класс B НЕ имеет метода f().

C>Что за цитаты, примеры кода? Приведи реальный пример когда из-за кривизны языка, а не программера получаются неявные ошибки не описанные и заранее не продуманные в языке.

Ошибки заранее не продуманные в языке? Это Вы сильно сказали. К сожалению, мне слишком далеко до Вашего интеллектуального уровня, чтоб был смысл продолжать этот неконструктивный спор.
Re[13]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 16:14
Оценка: -1
Здравствуйте, criosray, Вы писали:

ГВ>>"Контракт" подразумевает соглашения о побочных эффектах

C>Занавес. Апплодисменты.

А что не так?

Интерфейс (в терминах C#) — это только перечисление методов, pure virtual на C++ — то же самое. Конечно, это выражение некоторой части контракта класса, но только некоторой. И возвращаясь к твоему риторическому вопросу, "что должен делать интерфейс" — интерфейс может верифицировать часть более общего контракта класса. Как раз на C++ это реализовать особого труда не составляет, например, разделив интерфейс на public и protected секции:

class ISomeAction {
  public:
    // Вот это - "публичный контракт"
    // Здесь даже не нужно virtual
    void actOn(ISomeOther *pOther) {

      ASSERT(pOther->getSome() > 10); // Предусловие
      ASSERT(getMyData() > 5 && getMyData() < 8); // Ещё одно предусловие

      actOnImpl(pOther); // Собственно действие

      ASSERT(pOther->getSome() < 100); // Постусловие
      ASSERT(getMyData() > 5 && getMyData() < 8); // Обратно постусловие
    }
  protected:
    // А вот это - то, что должно быть реализовано классом, реализующим интерфейс
    virtual void actOnImpl(ISomeOther *pOther) = 0;
    virtual int getMyData() const = 0;
};
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 16:21
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.


C>ЧТД.


int != double. Потому int — маздай, а double — рулит. Сила слова, да.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 16:45
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>Целые числа и числа с плавающей запятой это разные понятия.


Почему? И то, и другое суть "число". int, double, short int, BCD — это всё детали реализации.

C>Строка это одно понятие, а уж ANSI она или Unicode — детали реализации, которые у С++ в виду примитивизма языка торчат наружу.


"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 16:57
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:


C>>Целые числа и числа с плавающей запятой это разные понятия.


ГВ>Почему? И то, и другое суть "число".

Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
А строки "они и в африке" строки.

ГВ>"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.

Нет, не может их быть великое множество. Заканчивайте фантазировать.
Re[14]: Неясно сформулировал
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 17:29
Оценка: :)
C>>А строки "они и в африке" строки.

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


Собственно, самое главное — строки в "общечеловеческом" смысле в принципе не могут совпадать со строками в "компьютерном" смысле. Потому что второе — это всегда реализация, так или иначе приближенная к компьютерным реалиям. Даже если таковая реализация "высокоабстрактна" и содержит, например, тучу преобразователей, она не может строиться на слабых определениях — то есть абстрактное "всё" тем или иным образом обязано превратиться в "то, то, это и это".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 18:09
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:


C>>>>Целые числа и числа с плавающей запятой это разные понятия.


ГВ>>>Почему? И то, и другое суть "число".

C>>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.

C>>А строки "они и в африке" строки.


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

Нет, это все одна и та же строка. Вы говорите о разном способе ее представления. Тип строка — один единственный.

ГВ>>>"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.

C>>Нет, не может их быть великое множество. Заканчивайте фантазировать.

ГВ>Отнюдь. Строка может представляться как:

Опять же — представления типа. Тип строка — один единственный.

ГВ>Естественно, может быть всё разнообразие кодировок: с фиксированным или плавающим количеством байт на символ. Так же естественно, что строка (как "объект") может содержать или не содержать операции поиска, конкатенации, выделения подстроки и т.п. И само собой, строки могут быть изменяемыми и не изменяемыми.

Это детали реализации. Тип строка — один единственный.

ГВ>Ну и какую комбинацию мы примем за единственно правильную?

А она всего одна — строка как тип данных.
Re[16]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 18:18
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>"что должен делать интерфейс" — интерфейс может верифицировать часть более общего контракта класса.


C>>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


ГВ>Зависит от того, как мы определяем сам термин "интерфейс". Если это только конструкция языка программирования вроде C# или Java — да, не может. Если это часть "контракта" — то не только может, но ещё и, не побоюсь этого слова, должен.


Ничего он не должен.

C>>Цитирую:


C>>

C>>Интерфейс — набор всех сигнатур, определенных операциями объекта. Интерфейс описывает множество запросов, на которые может отвечать объект.


C>>"Приемы объектно-ориентированного проектирования. Патерны проектирования" Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес


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

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

Вопросов больше не имею. Не утруждайте себя больше ответами по этой теме.
Re[16]: Неясно сформулировал
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 18:43
Оценка: :)
Здравствуйте, criosray, Вы писали:

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

ГВ>>Собственно, самое главное — строки в "общечеловеческом" смысле в принципе не могут совпадать со строками в "компьютерном" смысле.
C>Тип может совпадать (конечно же) и совпадает. Примером тому c#, java, python, ruby — и другие нормальные языки.

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

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

C>И снова Вы говорите не о типе, а о реализации. Тип строка — один единственный. Точка.

Ну, попробуй тогда ответить на вопрос, что такое тип.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[18]: Неясно сформулировал
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 19:16
Оценка: :)
Здравствуйте, criosray, Вы писали:

ГВ>>Мда? Надо думать, что общечеловеческое начертание строк символов тоже предполагает их закавычивание? Остроумно.

C>Какое еще "заковычивание"? Вам самому еще не смешно от той билеберды, что Вы тут выдумываете?

Ну что, моя очередь ставить двойки?

ГВ>>Ну, попробуй тогда ответить на вопрос, что такое тип.


C>http://en.wikipedia.org/wiki/Data_type читайте до полного просвящения.


Хорошо. Допустим. Что считать определением? Вот это:

Тип (сорт) – относительно устойчивая и независимая совокупность элементов, которую можно выделить во всем рассматриваемом множестве (предметной области).

?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: интефейс и контракт...
От: criosray  
Дата: 01.06.09 19:24
Оценка: :)
Здравствуйте, Erop, Вы писали:

C>>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


E>Эх, кажется мне, что вы о разных сущностях говоррите. Где-то об интерфейсе, как конструкции того или иного языка, а где-то об интерфейсе, как о контракте класса...


E>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:
struct IOrder {
E>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>};

Да, это вполне корректный интерфейс, хотя и костыль, т.к. придет Вася Пупкин в проект и порушит всю чистоту конструкции, добавив неабстрактный метод.


E>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...


Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?

E>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...


Это контракт не интерфейса, а объекта, который реализует данный интерфейс.
Re[19]: Неясно сформулировал
От: criosray  
Дата: 01.06.09 19:26
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Мда? Надо думать, что общечеловеческое начертание строк символов тоже предполагает их закавычивание? Остроумно.

C>>Какое еще "заковычивание"? Вам самому еще не смешно от той билеберды, что Вы тут выдумываете?

ГВ>Ну что, моя очередь ставить двойки?


Попробуйте — снова посажу Вас в лужу.
Re[21]: Неясно сформулировал
От: criosray  
Дата: 01.06.09 19:56
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ну что, моя очередь ставить двойки?

C>>Попробуйте — снова посажу Вас в лужу.

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


И я ответил, а Вы троллите. Не утруждайтесь — на остальные Ваши попытки потроллить я отвечать не стану.
Re[19]: интефейс и контракт...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.09 00:13
Оценка: -1
Здравствуйте, criosray, Вы писали:

ГВ>>А кто сказал, что интерфейс должен содержать только абстрактные методы? Чем не абстрактные методы противоречат "интерфейсу"?

C>Абсолютно всем. Интерфейс с методами — не интерфейс, а просто класс.

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

E>>>>При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

C>>>Замечательно, что оно у Вас там где-то подразумевается, но при чем тут интерфейс?
ГВ>>При том, что эти утверждения — неотъемлемая часть интерфейса, которую могут (и должны) учитывать его пользователи.
C>Это может быть неотъемлимой частью объектов классов, реализующих данный интерфейс, но уж никак не интерфейса.

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

Всё просто, как видишь.

E>>>>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...

C>>>Это контракт не интерфейса, а объекта, который реализует данный интерфейс.
ГВ>>Контракт формулируется для интерфейса, а реализуется — реализующим интерфейс классом.
C>Контракт формируется для класса, а не для интерфейса. Интерфейс это и есть контракт.

Не-а. Интерфейс — это часть контракта.

C>Вам не наскучило пороть чушь?


Знаешь, есть вопросы на которые в принципе нельзя отвечать. Вот, например: ты перестал пить коньяк по утрам?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Неясно сформулировал
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.09 04:51
Оценка: -1
Здравствуйте, criosray, Вы писали:

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

C>И я ответил, а Вы троллите. Не утруждайтесь — на остальные Ваши попытки потроллить я отвечать не стану.

Короче говоря, обопрёмся на википедию. Хорошо.

Тип (сорт) – относительно устойчивая и независимая совокупность элементов, которую можно выделить во всем рассматриваемом множестве (предметной области).


Итак, выдели, пожалуйста, эту самую устойчивую и независимую совокупность элементов для строки. Ты уверяешь, что этот тип — один-единственный, следовательно, хотя бы несколько характерных его элементов можно выделить запросто. Просто назови эти элементы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 07:30
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

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


C>>>http://research.microsoft.com/en-us/projects/contracts/

C>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?

ГВ>Прикольный постинг по этому поводу: API Design Myth: Interface as Contract


А никто и не утверждал, что интерфейс является полным контрактом класса. Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе точно так же как и code сontracts в конкретной реализации интерфейса — в классе, описывают пред- и пост- условия в методе или еще более специфичные соглашения, как тут вчера приводили о порядке вызовов методов, т.п. — это тоже контракты КЛАССА. У классов естественно может быть целое множество контрактов, которое в совокупности составляет полный контракт этого класса. Вы же пытаетесь смешивать теплое с мягким, грубейше нарушая принцип single responsibility, когда добавляете КОД в интерфейс. О чем Вам, кстати, и господин WolfHound твердил.
Re[13]: За что я не люблю С++
От: 0xC0000005  
Дата: 02.06.09 08:42
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Геннадий Васильев, Вы писали:


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


C>>>>http://research.microsoft.com/en-us/projects/contracts/

C>>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?
[...]
C>А никто и не утверждал, что интерфейс является полным контрактом класса.

Я о том же, интерфейс — это не контракт, а вы разве не писали обратного?
http://rsdn.ru/forum/flame.comp/3412734.1.aspx
Автор: criosray
Дата: 01.06.09


Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


То что он ничего не может делать это с какой стороны посмотреть и что делать, а вот контракт как раз должен делать кое-что, в чём заключается его цель.
Re[15]: За что я не люблю С++
От: 0xC0000005  
Дата: 02.06.09 09:12
Оценка: -1
Здравствуйте, criosray, Вы писали:

...
C>Специально для Вас выделил ключевое.

Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:

Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


Потом вы пишете

А никто и не утверждал, что интерфейс является полным контрактом класса


Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:
Колесо — это чисто машина.
Надеюсь в этот раз я вас не запутал и привёл нормальные доводы.
Re[17]: За что я не люблю С++
От: 0xC0000005  
Дата: 02.06.09 09:21
Оценка: :)
Здравствуйте, MxKazan, Вы писали:

MK>Здравствуйте, 0xC0000005, Вы писали:


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

C>>...
C>>>Специально для Вас выделил ключевое.
C>>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:
C>>

C>>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>>Потом вы пишете
C>>

C>>А никто и не утверждал, что интерфейс является полным контрактом класса


C>>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:

C>>Колесо — это чисто машина.
MK>По такой логике criosray должен был написать, что интерфейс — это чисто класс. Вроде такого не было

Он написал что интерфейс это чисто контракт, а не класс, я продолжил логику показывая что связь Is Contained не является IS A
Re[14]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 10:44
Оценка: -1
Здравствуйте, March_rabbit, Вы писали:

C>>>>Целые числа и числа с плавающей запятой это разные понятия.


ГВ>>>Почему? И то, и другое суть "число".

C>>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
C>>А строки "они и в африке" строки.
M_>гм... неужто это говорит программист???
M_>неее, не верю. Он прикалывается.

Нет, не прикалываюсь. Фундаментальный тип строка — один единственный. Реализации могут различаться.
Re[19]: За что я не люблю С++
От: 0xC0000005  
Дата: 02.06.09 10:45
Оценка: -1
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, 0xC0000005, Вы писали:


C>>Вы нагло увиливаете от прямого ответа, грубите итп, у меня закрадывается мнение что с вами лучше не вести такие беседы.

C>Нет, это Вы не способны прочитать один маленький абзац где я объясняю, что:
C>1. Интерфейс — это контракт класса.
C>2. Полный контракт класса состоит из совокупности всех контрактов класса — все интерфейсов-контрактов, всех код-контрактов.

C>Вам по прежнему не понятно? Тогда я умываю руки — если человек не может сложить в уме 2 и 2, и получить в результате 4, то что-то объяснять ему — пустая трата времени.


Контракт класса? Сами термин придумали? В литературе по контрактному программированию ни слова о "Контрактах класса", можно разузнать что такое контракт класса с первоисточниками?
Re[18]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 10:49
Оценка: -1
Здравствуйте, March_rabbit, Вы писали:

E>>>Ну и так далее...

S>>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>>0. Они не immutable.
S>>1. Они слишком сильно сосредоточены на бинарном представлении.

S>>Строки дотнета тоже не лишены недостатков, но об этих недостатках дефолтным строкам стандартной библиотеки плюсов еще приходится только мечтать.

M_>было бы странно, если в дотнете недостатки были бы хуже
M_>учитывая, когда кто из них появился.

Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.
Re[21]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 02.06.09 11:07
Оценка: +1
Здравствуйте, criosray, Вы писали:

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


C>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

CC>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
C>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
Посмотрите QString из QT, вроде неплохо работает, да еще и cross-platform . А "дикий оверхед", обычно появляется в результате неумелого и непродуманного использования библиотечных классов как в С++ так в С#.
Re[22]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 11:50
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

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


C>>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

CC>>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
CC>>>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
C>>Конечно никакой — ведь std::string не могут использовать общий буффер, как это делается в дотнет.
CC>Какая в этом выгода?
CC>Не, ну если у тебя в проге есть куча одинаковых строк, раскиданных по всему коду то да, на спичках сэкономить можно.
CC>А так смысла особого не видно.
Вот и пришли наконец от "В С++ нет оверхеда!!!11111" (с) уж и не помню кто из местных "гуру" к "зачем экономить на спичках".
CC>Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?
Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).

C>>Вот так они будут ссылаться на один и тот же буфер. Тем самым будет использовано всего 6 байт под буфер вместо 12, как это было бы в С++

CC>В С++ для кода:
CC>
CC>const char* str = "abc";
CC>const char* str2 = "abc";
CC>

CC>в случае включения опции Enable string pooling тоже будет str == str2
Потому что это константы.

CC>А вообще, как-то тут давно пробегала мессага, в которой кто-то сорвал покровы почему в шарпе строки сделаны через стрингбилдер. Там была какая то техническая причина, вроде как связанная с особенностями аллокации в .NET. Не упомню уже.

Что значит "строки сделаны через стрингбилдер"? Что это еще за чушь? StringBuilder это чисто вспомогательный класс, позволяющий очень быстро перемалывать списки символов. Зачем он нужен понятно всякому, кто понимает что значит immutable природа типа string. К тому же, как я уже упоминал специфика использования StringBuilder такова, что оверхед по памяти для него абсолютно не релевантен, что позволяет оптимизировать его максимум на скорость выполнения операций вставки/удаления/поиска и т.д.

Будет время напишу синтетический тест с молотилками больших объемов текста средствами std::string и StringBuilder для сравнения.

CC>Кроме того, сталкивался с реализацией STL в которых basic_string сделан через COW с подсчетом ссылок.


C>> (впрочем, std::string даже не юникодный, так что там было бы 3+3).

CC>Базовой реализации строк в STL на это вообще пофигу — хоть UTF32 на них реализуй.

И что у Вас std::string UTF32? Что за STL у Вас такой можно поинтересоваться?
Re[21]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 11:50
Оценка: +1
Здравствуйте, criosray, Вы писали:

CC>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.

C>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
Интрузивный счетчик в буфере строки.

Забудь вообще про shared_ptr — он кривой изначально.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[22]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 11:54
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:


CC>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.

C>>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
CC>Интрузивный счетчик в буфере строки.
Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.
Re[23]: Ну ты вообще многого не видишь... ;)
От: Юрий Жмеренецкий ICQ 380412032
Дата: 02.06.09 12:08
Оценка: +1
Здравствуйте, criosray, Вы писали:
...
CC>>Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?
C>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).

Если это так, то время появления нового объекта (строки) должно зависеть от количества существующих объектов (строк) в программе.
Re[23]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:15
Оценка: +1
Здравствуйте, criosray, Вы писали:

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



CC>>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.

C>>>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
CC>>Интрузивный счетчик в буфере строки.
C>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.
Ты точно на С или С++ писал? Или как работать с памятью и указателями уже забыл?
На пальцах: на хипе вместо массива под строку аллоцируется структура переменной длины:

struct StringBuffer
{
 int m_refCounter;
 int m_stringLength;
 char m_stringBody[]; // отсюда собственно тело строки и начинается
};
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[24]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 12:23
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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

C>>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).
S>Нет. Более того, в последних версиях даже принудительный вызов Intern() не приводит к желаемым результатам.

Принято.
Но
var a = "str";
var b = "str";

Точно ref equal.
Re[23]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:54
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[24]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 12:59
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

CC>Ну наконец то спокойный ответ с полезной ссылкой без фанатских причитаний.

Теперь осталось дождаться от Вас хоть одного ответа без "фанатских причитайний".
Re[24]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 13:00
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

C>>Так и есть — в С++ зоопарк глючных, несовместимых реализаций строк. А в исходниках каша из std::wstring, CWSTRPTR (spelling), CString, QString, wchar и десятков аллиасов.

CC> Это скорее проблемы человеческой неорганизованности нежели языка.

Ну конечно. Это не проблемы языка. У языка вообще проблем нет. Проблемы есть у программистов, которые пишут на этом языке.
Re[18]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 02.06.09 13:40
Оценка: +1
Здравствуйте, Игoрь, Вы писали:

И>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:

const это фигня на постном масле.
Ибо изменяемость/не изменяемость должны быть неотъемлемым свойством типа, а не модификатором.
Тогда сразу открывается возможность для кучи доказательства кучи свойств кода и как следствие более агрессивных оптимизаций. Про такую "мелочь" как увеличение надежности и предсказуемости кода для разработчика я вообще молчу.

И>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.

Этот огород исключительно из-за того что мелкософты не осилили эффективную реализацию строк.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 13:57
Оценка: :)
Здравствуйте, Игoрь, Вы писали:


C>>Откройте для себя System.Text.StringBuilder.

И>Первое. Читай внимательно, я в курсе.
Если Вы в курсе, тогда к чему было писать про некие "проблемы при работе с большим количеством текста"? Флейма ради?
И>Второе. Если хочешь, чтобы тебе отвечали не в стиле — "сам дурак", научись нормально разговаривать.
Иначе на тупые попытки троллинга я уже не реагирую. Если не рубить с плеча, то будет продолжаться поток глупостей.
Re[22]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 04:06
Оценка: +1
Здравствуйте, Игoрь, Вы писали:
И>Опять начинается путаница. Если мы говорим в пониманиии константности С++, то это неверно. Алгоритм требующий константности объекта, априори будет работать и для неконстантного объекта, просто из-за того, что константность более жесткое ограничение.
Да-да, вы как раз вносите путаницу. Конечно же, алгоритм, заложившийся на константность объекта, никак не сможет работать с неконстантым. Например, из константности мы можем вывести возможность не делать блокировок при обращении; можем полагаться на то, что хеш будет неизменным; много на что еще можем полагаться. Неконстантность ничего этого не даёт, поэтому алгоритмы на С++ невозможно оптимизировать подобным образом.
И>С другой стороны, если мы в понятие константности строки включаем еще и фиксированное размещение ее в памяти или в каком-то сторадже. Ну да, там можно использовать какие-то оптимизации в виде хэш == адрес. Но таких алгоритмов раз два и обчелся,
Всё как раз наоборот — подавляющее большинство алгоритмов сильно выигрывает от константности. К тому же 90% строк в приложениях никогда не модифицируются — они применяются в семантике value типов.
И>а кроме того ведь в таком подходе C# есть и недостатки. Например, если идет относительно активная работа с текстом, включая его изменения, то почему я должен на каждый чих создавать копию строки? Опять эффективность, но уже в другую сторону.
Если идет активная работа с текстом, что очень редко, то нужен совсем другой контракт. Для этого применяют StringBuilder.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 03.06.09 07:15
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

CC>>А если это не так (что скорее всего) то тогда получается что уже в качестве ключей их использовать упс... И память они уже не экономят...

S>Экономия памяти — ерунда. Шансов на то, что две строки совпадут — практически нуль.
Ну тут просто от криоса крику было про экономию памяти: 3 байта вместо 6ти.

S>Зато гарантированная константность позволяет использовать хеш строки в качестве части ключа.

Для этого не обязательно вообще все строки принудительно делать константными.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: За что я не люблю С++
От: jazzer Россия Skype: enerjazzer
Дата: 03.06.09 07:48
Оценка: +1
Здравствуйте, 0xC0000005, Вы писали:

C>Контракт класса? Сами термин придумали? В литературе по контрактному программированию ни слова о "Контрактах класса", можно разузнать что такое контракт класса с первоисточниками?


Сразу скажу, что всю ветку не читал, только это сообщение, так что прошу прощения за возможное "не в тему".
Контракт чего бы то ни было — это, по сути, требования к этому, ожидания, которым оно будет удовлетворять всегда, даже при смене реализации.
Если говорить о первоисточниках С++, то можно открыть стандарт и посмотреть, например, главу "Container requirements" — там как раз описываются контракты всех стандартных контейнеров, т.е. набор методов, их сложность, пре-пост-утверждения, смысл (!) каждого метода, а также, помимо методов, еще и типы (например, value_type), что, несомненно, шире интерфейса в понимании Java (просто набор виртуальных функций).
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[22]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 03.06.09 11:42
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

E__>>Кстати, а что мешает и варианты "abc" и "abc2" хранить в одной области(имеется ввиду сами буфферы, объекты будут разными в любом варианте)?
E__>>Длина заключена в объекте(а не определяется положением терминирующего символа), при этом строки никогда не будут изменены.
E__>>Так ли это в реале, не знаю, но ничего не мешает так устроить.
S>В Java именно так работает выделение подстроки.

Ну да, знаю. То есть, если "abc" получено из "abc2", то буфер они будут один использовать. А вот при создании, по ходу, нет, хотя и можно было бы так сделать.

У такого подхода есть как плюсы, так и минусы. Основной плюс в том, что несмотря на неизменяемость строк, если в программе много строк, которые созданы как подстроки, экономится память(а во многих задачах строки составляют большинство данных). Основной минус в том, что если есть хоть одна активная ссылка на махонькую подстроку, которая ранее была выделена из огромной(на которую ссылок уже нет), то GC не сможет освободить весь буфер.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[24]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 03.06.09 12:03
Оценка: +1
Здравствуйте, Игoрь, Вы писали:

И>Не, ну хорошо, кто бы спорил. Раз подходит для каких-то задач, замечательно. Мне такое пока не нужно.

Нужно просто ты сам пока этого не понимаешь.
Дело в том что тут работает парадокс блаба
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.
.
Те пока ты смотришь на мир с точки зрения С++ ты будешь видеть только более слабые языки и языки с не понятными заморочками.

И>Вот как раз с многопоточностью и строками я как-то никогда проблем не имел.

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

И>Иногда для оптимизации и не такое приходится делать, например выкидывать std::vector, из-за того, что тот свой буфер зануляет.

А что reserve + push_back не помогает?
А в случае с функциональным языком для которого не поленились сделать нормальный оптимизатор это вообще не вопрос.
Просто пишешь что-то вроде:
def arr = array(1000, i => i * i);

И получаешь массив заполненный тем чем тебе надо. Причем память не будет предварительно обнулена.

И>Например есть строки размером от 50КБ до 5МБ, надо найти и вырезать какие-то куски без лишних релокейшинов. Все что мне нужно — хоть простой набор алгоритмов над текстовым writable буфером.

Это решается умным представлением строк. Одна из возможных структур данных называется rope.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[25]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.09 23:49
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

И>>Не, ну хорошо, кто бы спорил. Раз подходит для каких-то задач, замечательно. Мне такое пока не нужно.

WH>Нужно просто ты сам пока этого не понимаешь.
WH>Дело в том что тут работает парадокс блаба
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.
.

WH>Те пока ты смотришь на мир с точки зрения С++ ты будешь видеть только более слабые языки и языки с не понятными заморочками.

Опять мозговедение?

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

И>>Например есть строки размером от 50КБ до 5МБ, надо найти и вырезать какие-то куски без лишних релокейшинов. Все что мне нужно — хоть простой набор алгоритмов над текстовым writable буфером.

WH>Это решается умным представлением строк. Одна из возможных структур данных называется rope.

Вот-вот. Возвращаемся к тому, с чего начали: к внутренней структуре строки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 01:39
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Еще раз: реализация строк в С++ — убожество с точки зрения архитектуры.


Знайте — истина в том,
Что повторено трижды подряд!


(c) Л. Кэррол, Охота на Снарка
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[29]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 04.06.09 07:38
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

А можно как нибудь подтвердить реальными фактами это утверждение?
Или "мало-мальски полезные иммутабельные строки" это 1:1 как в шарпе и никак иначе?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 04.06.09 07:38
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Да, совершенно верно. Что такое "константная строка"???

S>Вот я отдал в другой тред указатель на строку. Ну, то есть понятно, что выполнять полное копирование — слишком дорого. Если у этого указателя семантика реф-типа, то необходимо обеспечить механизмы блокировки. Чтобы два треда не поменяли содержимое строки.
Так отдавай туда const char * — и ежу понятно что менять сие без хака низя.

А если авторы кода, куда ты передаешь строку, внутрях снимают константность, то тебе в этом случае вообще никакие иммутабельные строки не помогут. Если уж тут сняли константность то в случае иммутабельной строки — полезут напрямую в память и поменяют буфер "иммутабельной" строки.
Это С++!!! (СПАРТААААА!!!!)
Это не C# — тут суровые бородатые викинги с топорами.

S> В иммутабл строках никаких блокировок не нужно — если указатель указывал на Hello World, то он всегда будет указывать на Hello World.

Если есть в руках индуса указатели — тебя ничего не спасёт.
В шарпе отобрали возможность делать что угодно с любой областью памяти — поэтому там можно надеяться на "гарантии иммутабельности". Впрочем все равно можно дёрнуть native код и поковыряться указателем в памяти. И тогда все надежды гарантии пойдут лесом, как и в С++ случае.
Поэтому не надо тащить методы работы с C# в С++ где всё совсем по другому.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[30]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 08:29
Оценка: +1
Здравствуйте, alexey_ma, Вы писали:
_>Вон оказывается оно как Только причем здесь окружающая среда? Замечательно если вы сами можете определять контракты и аспекты представления, ну а если Вам нужно взаимодествовать с какой-то legacy аппликацией написанной 20 лет назад и использующей свой собственный извращенный стринг, что делать то?
Читать инструкцию про platform invoke. Вопросы конвертации представления строк там решены. Благодаря тому, что они отделены от контракта собственно строки, конвертеры стоят не так дорого, как типичный "класс строка" из произвольной плюсовой библиотеки.

_>Впрочем спорить не буду, возможно в 95% процентах случаев дотнетовский стринг вполне удобен, используйте и радуйтесь. Меня же радует в С++ многообразие стрингов из разных библиотек и возможность выбора наиболее подходящего и эффективного для каждого конкретного случая.

Не путайте возможность и необходимость. Именно такое похабное отношение к строкам с самого начала и привело к тому, что в С++ появилось "многообразие стрингов из разных библиотек" и необходимость трахаться с их интероперабельностью.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 08:46
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

CC>Так отдавай туда const char * — и ежу понятно что менять сие без хака низя.

Опять упорствующее непонимание. Отдать-то я могу. А как мне при приёме обеспечить константность?
CC>А если авторы кода, куда ты передаешь строку, внутрях снимают константность, то тебе в этом случае вообще никакие иммутабельные строки не помогут. Если уж тут сняли константность то в случае иммутабельной строки — полезут напрямую в память и поменяют буфер "иммутабельной" строки.
Всё наоборот. Вот у меня код
void ProcessInAnotherThread(const char* achtung);


Этот код пишу я. Вызывают его другие. Вот этот const означает, что я не имею права его менять. Но вызывающая сторона имеет полную свободу — я не могу, оставаясь в рамках С++, обеспечить неизменность этой строки.
CC>Это С++!!! (СПАРТААААА!!!!)
Это отстой, а не спарта.
CC>Это не C# — тут суровые бородатые викинги с топорами.

CC>Если есть в руках индуса указатели — тебя ничего не спасёт.

Не надо вот этих вот "ля-ля". В руках индуса... Ничто не спасёт... Этими мантрами люди, покусанные плюсами, убеждают себя уже двадцать лет. А тем временем другие люди, с более взвешенным отношением к индустрии, демонстрируют, что можно значительно увеличивать надёжность программ безо всяких мантр и подготовок личного состава.
Да, я в курсе, что при особом желании высокодоверенный код в С# может сломать иммутабельность строк. Но это — малоизвестная и труднодостижимая техника. А в вашей убогой спарте запросто можно отчудить вот такое:
std:string hello("hello");
void ProcessInAnotherThread(hello.c_str());
hello.clear(); // oops!

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

CC>В шарпе отобрали возможность делать что угодно с любой областью памяти — поэтому там можно надеяться на "гарантии иммутабельности". Впрочем все равно можно дёрнуть native код и поковыряться указателем в памяти. И тогда все надежды гарантии пойдут лесом, как и в С++ случае.

CC>Поэтому не надо тащить методы работы с C# в С++ где всё совсем по другому.
Я в курсе, как там что в С++. Я, вообще-то, не с С# работать начал.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 08:46
Оценка: -1
Здравствуйте, CreatorCray, Вы писали:

CC>А можно как нибудь подтвердить реальными фактами это утверждение?

CC>Или "мало-мальски полезные иммутабельные строки" это 1:1 как в шарпе и никак иначе?
Не обязательно 1:1. Достаточно иметь просто иммутабельные строки, которые не требуют O(N) при интеропе с окружающим кодом.
Увы, сие в плюсах решительно невозможно. Единственный способ для библиотеки потребовать от внешнего кода передачи иммутабл строки — это выполнить копию в момент передачи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Ну ты вообще многого не видишь... ;)
От: Юрий Жмеренецкий ICQ 380412032
Дата: 04.06.09 09:06
Оценка: +1
Здравствуйте, alexey_ma, Вы писали:
...
_>Так это для наглядности. На самом деле вместо указателя можно изпользовать address-of operator — & для конкретной переменной. Просто такой код не имееет смысла в С++, поскольку адресс переменной не бывает нулевой. Я вообще-то склонен согласиться с Игорем что кода вида
_>
_>int* n = null
_>

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

В бусте как раз есть optional<T> (и умные указатели здесь не причем), и его семантика ближе к Nullable в C#, чем к указателям в С++:

For instance, optional<> does not have shallow-copy so does not alias: two different optionals never refer to the same value unless T itself is a reference (but may have equivalent values). The difference between an optional<T> and a pointer must be kept in mind, particularly because the semantics of relational operators are different: since optional<T> is a value-wrapper, relational operators are deep: they compare optional values; but relational operators for pointers are shallow: they do not compare pointee values. As a result, you might be able to replace optional<T> by T* on some situations but not always.
...
bool operator < ( optional<T> const& x, optional<T> const& y );
Returns: If y is not initialized, false. If y is initialized and x is not initialized, true. If both x and y are initialized, (*x < *y).

...
bool operator == ( optional<T> const& x, optional<T> const& y );
Returns: If both x and y are initialized, (*x == *y). If only x or y is initialized, false. If both are uninitialized, true.

Re[26]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 04.06.09 09:17
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

CC>В шарпе отобрали возможность делать что угодно с любой областью памяти — поэтому там можно надеяться на "гарантии иммутабельности".

Ну так его же и проектировали так, что бы индусы могли на нём относительно безопасно писать! Потому такой хороший язык и получился!

CC>Впрочем все равно можно дёрнуть native код и поковыряться указателем в памяти. И тогда все надежды гарантии пойдут лесом, как и в С++ случае.

Да и вообще пока у нас есть компьютер... Я вот помню как на ZX Spectrum извращались, например...

CC>Поэтому не надо тащить методы работы с C# в С++ где всё совсем по другому.

Да, и обратно не надо. У всех подходов свои сильные и слабые стороны...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[28]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 09:39
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

могу, оставаясь в рамках С++, обеспечить неизменность этой строки.
CC>Дык этож C# подход, для С++ надо делать иначе.
Как именно?
CC>Это средство называется головной мозг.
Спасибо, на этом всё.

CC>Мне почему-то в голову такую дурость на С++ утворить не приходит.

Да-да, не приходит. Это просто короткий пример. В более длинных примерах просто будет трудноуловимый баг, который станет проявляться только, к примеру, на многопроцессорной машине.

CC>>>Поэтому не надо тащить методы работы с C# в С++ где всё совсем по другому.

S>>Я в курсе, как там что в С++. Я, вообще-то, не с С# работать начал.
CC>Я понимаю. Но у тебя моск уже заражён шарпом, раз ты пытаешься писать на С++ как на шарпе.
Ты ничего не знаешь о том, как я пытаюсь писать на С++.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: i++; ++i; ;) (-)
От: Erop Россия  
Дата: 04.06.09 09:53
Оценка: -1
Здравствуйте, Serginio1, Вы писали:

S>В данном случае ты говоришь об эксклюзивном ключе. Здесь есть езменяемая и неизменяемая часть.

S> разделение строк на 2 типа необходимо по нескольким причинам.
Как связанна эксклюзивность ключа с тем, что ключ -- строка, а не double, например?

S>1. Хэш неизменен, а значит хранение в хэштаблице в том числе для интернирования для скорости сравнения по указателям и экономии памяти.

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

S>2. Для мутабельной строки как в стрингбуилдере для скорости нужно иметь выделенную память больше чем размер строки на данный момент

S>для быстрого изменния длины строки.
Это всего лишь подробности реализации той самой мутабелной строки. Мне, например, нравится реализация, которая содержит коллекцию пулов буферов. Размеры буферов в каждом из пулов подобраны так, чтобы каждый следующий пул хранил строки во сколько-то раз (например в полтора) большие, чем предыдущий. Аллокация -- быстрая, освобождение -- ещё более быстрое, работа с COW...


S>3. Отсутствие синхронизации при чтении строк.

При чтении любых константных данных синхронизация вроде как не нужна...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[25]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 04.06.09 09:53
Оценка: +1
Здравствуйте, Sinclair, Вы писали:


PD>>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.

S>Совершенно верно. К счастью, обычно автор программы достаточно хорошо себе представляет, какие операции он хочет делать с текстом и насколько часто. И если ему нужно часто вносить изменения в строку, он применяет StringBuilder.
Проблема в том, что StringBuilder не имеет полноценного интерфейса для редактирования строк. Например, там нет даже поиска подстроки. О каком редактировании может идти речь? StringBuilder вообще предназначен исключительно для конструирования строк, но не для их редактирования. И я думаю, что из-за этого в Java, которая применяет тот же принцип — String + StringBuffer, появилась альтернатива String — Rope, которая с одной стороны имеет интерфейс String, но оптимизирована под редактирование. В общем в MS хотели как лучше, а получилось как всегда.
Re[33]: Ну ты вообще многого не видишь... ;)
От: Юрий Жмеренецкий ICQ 380412032
Дата: 04.06.09 10:16
Оценка: +1
Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Юрий Жмеренецкий, Вы писали:


ЮЖ>>В бусте как раз есть optional<T> (и умные указатели здесь не причем), и его семантика ближе к Nullable в C#, чем к указателям в С++:


E>Он конечно есть, но, IMHO, не так чтобы совсем-совсем необходим.

Необходимость — это дело другое, просто я не видел что в споре Nullable vs pointer были озвучены основные различия оных. Имхо, это довольно разные вещи с частично совпадающими возможностями.

E>Тем не менее, это ещё раз демонстрирует, что если концепция не является совсем уж бесполезной, то её обычно реализуют как-то и в С++ библиотеке какой-нибудь

+1.
Re[25]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 12:15
Оценка: +1
Здравствуйте, Eugeny__, Вы писали:

PD>>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.


E__>Если бы в java/.NET не было StringBuffer/StringBuilder, это было бы проблемой. А так это станет проблемой только если у программера, писавшего этот алгоритм, кривые руки.


Ну кривые или не кривые — это не вопрос, а вот то, что на Яве/C# без особой надобности создают новые куски памяти из символов (специально даю такое низкоуровневое определение) там, где это совсем не обязательно — это факт.
With best regards
Pavel Dvorkin
Re[26]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 13:20
Оценка: +1
Здравствуйте, Игoрь, Вы писали:

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

Не могу согласиться.
Ибо тот же код на С++ будет раз в 10 больше.
А это уже жопа.

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

И что за задача?

И>Да, оказывается я этот rope несколько лет назад реализовывал, только не знал как оно называется. Но вопрос был по С#, String + StringBuilder не покрывают даже вполне распространенных сценариев, в частности элементарного редактирования текста средних и более размеров.

Но ропы это покрывают.

И>Вон в той же Java (откуда, я так понимаю, и были слизаны String+StringBuilder), таки появился Rope. Вот тебе и зоопарк реализаций. То, что иммутабельные строки могут быть полезны — согласен, но и должна быть возможность для нормального редактирования строк хотя бы средних размеров (нормального редактирования, а не с помощью обрубка вроде StringBuilder). И здесь иммутабельность не особо и нужна.

Пойми в чем прикол. Нужны только ропы.
Их редактирование вполне дешево.
Если бы в жабе строки изначально были бы ропами то никакого зоопарка бы не было. И StringBuilder'а тоже.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 14:05
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А оно таки всегда надо ? Строки, конечно, могут быть в кэше, кэш доступен из разных потоков, тут нужна потокобезопасность и другие случаи есть. Но если я в своей C/C++ функции завел локальную auto переменную (хоть std::string, хоть char[N]), то к ней все равно никто добраться не может, и почему я должен платить за эту потокобезопасность ? Ну а если уж она нужна, кто мешает обертку в виде thread_safe_string соорудить ?
Thread_safe_string крайне труден в написании. Более того, использование "обычной" строки вместо thread_safe — прямой путь к трудноуловимым граблям. А судя по количеству вопросов в наших форумах на тему "почему мне label.Text = "..." выкидывает исключение", рассчитывать на лёгкость применения здесь не стоит.
В дотнете баланс смещен с лозунга "не плати за то, чего не используешь" на лозунг "TANSTAAFL". Зато ленчи — гарантированные .

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

... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 15:02
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Так грамотная — это rope или линейный буфер?

rope. Другие не нужны.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.06.09 05:54
Оценка: +1
Здравствуйте, WFrag, Вы писали:

WF>Да, но тут нужно создавать новый экземпляр rope (а это память).

Э-э, как только память станет проблемой, её уберёт GC.
С System.String корень неэффективности именно в копировании буферов, т.е. стоимость любой операции в O(N). В rope это будет O(Log(N)), стремящийся к O(1) в простых случаях.

WF>Если бы речь шла просто о замене внутренней структуры String и StringBuilder-а с массива на rope (с тем отличием, что StringBuilder может менять своё состояние), то я бы согласился — никаких проблем, можно сделать не хуже обычных String/StringBuilder на массивах. Но, насколько я понял, речь-то идёт о том, что оставить один контракт, иммутабельный String.


Тут нужно много чего мерить, и следить за поведением VM. Я так понял, что не всякая VM даст реализовать rope с такой эффективностью, чтобы забить StringBuilder на всех сценариях.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 05.06.09 12:17
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

WH>>>>2)А если рассматривать задачу в комплексе те вспомнить про undo/redo то кто кого порвет мы еще посмотрим...

C>>>А что с ними не так у gap buffers?
WH>>А то что их нужно делать.
C>Как и верёвки...

Т.е. тот факт, что undo/redo для персистентной структуры это два списка, а для неперсистентной нечто принципиально другое по сложности, трудозатратам и эффективности — это значения не имеет? А имеет значение, что и то и другое надо делать? Интересное мнение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[36]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 05.06.09 12:55
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>>>Такая структура называется "finger tree" — http://en.wikipedia.org/wiki/Finger_tree

WH>>Пальчиковые деревья альтернатива ропам, а не undo/redo стеку.
C>Rope с undo/redo стеком в них вырождается.

Finger Tree — это дерево с "с пальцем" для быстрого доступа к элементу, а "палец" — это скорее такой прото-зиппер. Может я что-то не так понимаю, но как тут одно в другое выражается не вижу, можно это как-то продемонстрировать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[45]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 07.06.09 16:16
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

Не совсем понимаю смысла в immutable rope`ах. Можно где-то скачать реализацию на дотнет?



(это не к вопросу о веревках, но в контексте дискуссии):

Небольшой тест производительности std::wstring в сравнении со StringBuilder.

std::wstring

append: elapsed: 6 seconds.
replace: (стандартной реализации нет, как ни странно, а написанная на коленке функция работала так долго, что я просто не дождался выполнения)
insert: elapsed: 22 seconds.

System.Text.StringBuilder

append: elapsed 00:00:02.0856345
replace: elapsed 00:00:02.8668542
insert: elapsed 00:00:18.0279118

Исходники


inline void replace(std::wstring &text, std::wstring &s, std::wstring &d)
{
    for(unsigned index=0; index=text.find(s, index), index!=std::string::npos;)
    {
        text.replace(index, s.length(), d);
        index+=d.length();
    }
}

int _tmain(int argc, _TCHAR* argv[])
{
     time_t t1, t2;

    time(&t1);

    std::wstring *str1 = new std::wstring();
    
    for(int i = 0; i<100000000; i++)
    {
        str1->append(L"c1");
    }

        time(&t2);

    std::cout << "append: elapsed: " << difftime(t2, t1) << " seconds." << std::endl;
    std::cout << str1->length() << std::endl;

    time(&t1);
    int ind;
    for(int ind = 10000; ind<100000; ind+=1000)
    {
        str1->insert(ind, std::wstring(L"7"));
    }
        time(&t2);

    std::cout << "insert: elapsed: " << difftime(t2, t1) << " seconds." << std::endl;

    delete str1;

    return 0;
}




            var stopwatch = new Stopwatch();

            stopwatch.Start();
            var stringBuilder = new StringBuilder();

            for (int i = 0; i < 100000000; i++)
            {
                stringBuilder.Append("c1");
            }
            stopwatch.Stop();
            Console.WriteLine("append: elapsed {0}", stopwatch.Elapsed);
            Console.WriteLine(stringBuilder.Length);

            stopwatch.Start();
            stringBuilder.Replace('1', '2');
            stopwatch.Stop();
            Console.WriteLine("replace: elapsed {0}", stopwatch.Elapsed);

            stopwatch.Start();
            for (int ind = 10000; ind < 100000; ind += 1000)
                stringBuilder.Insert(ind, '7');
            stopwatch.Stop();
            Console.WriteLine("insert: elapsed {0}", stopwatch.Elapsed);
Re[38]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.06.09 07:17
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>Попробуй обоснуй. Экземпляр привязан к типу, так что информация о типе всегда налицо. Чего ей не хватает ? Она может даже поместить этот объект в R/O секцию, так что все попытки его модифицировать вызовут exception

G>>R/O секцию чего? Стека? Кучи?

PD>Просто R/O секцию. Создается в C++ #pragma dataseg(имя). Ей можно поставить атрибуты без W. Некая функция (конструктор констант , получив ее базовый адрес, ставит разрешение по записи, записывает, снимает опять. А что и как там хранить — предмет отдельного разговора. Например, куча константных объектов, которые можно туда добавлять и оттуда удалять (эти методы могут снимать защиту), но функции их изменения получат exception просто по защите на уровне процессора, так как снимать защиту не умеют.


Выделенное — дикий оверхед, оптимизацей в таком случае и не пахнет.
Оно нафиг не нужно, если неизменяемость доказана компилятором из системы типов.
Re[47]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 07:22
Оценка: :)
Здравствуйте, Хвост, Вы писали:


C>>Небольшой тест производительности std::wstring в сравнении со StringBuilder.


Х>чем больше я вижу твоего С++ кода, тем больше понимаю почему тебе было мучительно больно на нём писать и ты перелез на C#


Так что скажете по делу? Этот "исправленный" код (или по прежнему есть притензии к его качеству?) ни на йоту производительнее того что был и до сих пор в разы проигрывает .NET StringBuilder на операции аккумуляции строки.

int _tmain(int argc, _TCHAR* argv[])
{
    time_t t1, t2;

    time(&t1);

    std::wstring str1;
    
    for(int i = 0; i<100000000; i++)
        str1.append(L"c1");

    time(&t2);

    std::cout << "append: elapsed: " << difftime(t2, t1) << " seconds." << std::endl;
    std::cout << str1.length() << std::endl;
    
    time(&t1);
    
    for(int ind = 10000; ind<100000; ind+=1000)
        str1.insert(ind, std::wstring(L"7"));

    time(&t2);

    std::cout << "insert: elapsed: " << difftime(t2, t1) << " seconds." << std::endl;

    return 0;
}
Re[31]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 08:14
Оценка: :)
Здравствуйте, alexey_ma, Вы писали:

И>>>Можно чуть короче, явно не делать проверку на NULL:


И>>>
И>>>int* p = NULL;
И>>>int a = 1, c = 10;

И>>>int b = (p? *p : c) / 100;
И>>>


C>>То есть ради такой єлементарщины надо вводить доп. переменную?

_>Так это для наглядности. На самом деле вместо указателя можно изпользовать address-of operator — & для конкретной переменной. Просто такой код не имееет смысла в С++, поскольку адресс переменной не бывает нулевой. Я вообще-то склонен согласиться с Игорем что кода вида
_>
_>int* n = null
_>

_>вполне достаточно ,

Так когда будет дан аналог с указателями с++ для

int? a = 1;
int c = 10;
int? b = (a == null ? a : c) / 100;


И давайте без создания лишних сущностей — ввода доп. переменных, ок?
Re[33]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.06.09 10:00
Оценка: :)
Здравствуйте, alexey_ma, Вы писали:
_>Зачем? Подобный код в плюсах не имеет смысла.
_>Получится что-то вроде :
_>
_>    int a = 0;
_>    int c = 10;
_>    int b = 0;
_>    (*(&b)) = ( &a == NULL ? *(&a) : c) / 100;
_>

Это не эквивалентный код.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 10:08
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

_>>Зачем? Подобный код в плюсах не имеет смысла.
_>>Получится что-то вроде :
_>>
_>>    int a = 0;
_>>    int c = 10;
_>>    int b = 0;
_>>    (*(&b)) = ( &a == NULL ? *(&a) : c) / 100;
_>>

S>Это не эквивалентный код.
Хорошо. Измените сами по вкусу .
Зачем мне такой код ? Какой нибудь толковый пример есть?
Re[54]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 10:18
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Кто????? Длины собственных подстрок узлов — это теперь то же самое, что длина слева?


Да не длина слева, а суммарная длина собственных (те, что в левом поддереве узла) подстрок узла.
Дерево — рекурсивная структура.
Без картинки не понятно что-ли?

ГВ>Я пытался уяснить магию с длинами собственных подстрок.


Эта магия называется аккумулятор. Проходят в первом классе, когда складывают (мысленно) яблоки из маленьких корзин в большую.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[50]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 08.06.09 11:40
Оценка: +1
Здравствуйте, criosray, Вы писали:

C> _itoa_s(i,buffer,10);

C> temp = buffer;
C> ws.append(StringToWString(temp));

C>Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.

Ай хорошо!
Прекрасный пример!

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

itow спасет отца русской демократии.
wchar_t * _itow(
   int value,
   wchar_t *string,
   int radix 
);


На С++ говоришь несколько лет прогил, да?
Ну ну...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[57]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:09
Оценка: :)
Здравствуйте, alexey_ma, Вы писали:



_>>>У вас в коде вроде тоже замена одиночного символа

C>>Речь шла о замене именно подстроки. Я могу поменять замену символа на замену подстроки из десятков символов и принципиального падения производительности не будет.
_>Уверены ?
_>У меня ваш код при замене
_>

_>stringBuilder.Replace('1', '2');

_>на
_>

_>stringBuilder.Replace("c1", "12");

_>Выбрасывает System.OutOfMemoryException.

У меня отрабатывает за 4.9 сек (против 2.9 сек на замену одного символа). Ну раз у Вас не достаточно памяти, то уменьшите количество иттераций в несколько раз.
Re[57]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:49
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

C>>Ну и кроме того, я могу сполна доверять стандартным классам фреймворка, а вот левой библиотеке некоего Васи Пупкина (ничего личного, я так для примера) — без соответствующего code review доверять ну никак не смогу.

C>>Да и вообще зачем изобретать велосипед? Сколько уже было потрачено человеко часов для такой банальщины, как преобразование базовых типов для вывода в строку?..
CC>Ну .NET FW же изобрели.
CC>Опять куда то не туда ушла дискуссия.

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

C>>>>Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".

CC>>>Мне тоже не приходится.
C>>Про _itow_s Вы знали на генетическом уровне? Да?
CC>Ага. Зная про itoa "гены" начали мне подсказывать что есть и itow.
itoa Вы, поди, тоже знали на генетическом уровне?
Re[53]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 17:26
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:


C>>>>C++ 858 ms

C>>>>C# 823 ms

ГВ>>>Это называется "равны с точностью до погрешности измерения".


C>>Конечно. Но вот чисто append сливает в три раза, а чисто replace так вообще в десятки раз (по крайней мере наколенковая реализация на базе wstring.find/wstring.replace.


ГВ>Тут на самом деле не надо путать StringBuilder, специально заточенный на модификации, и std::wstring, которая, по сути, своего рода компромисс между хранилищем строки (добавь требование преобразования к zero-terminated) и StringBuilder.

О том и речь. Потому я и утверждал, что разделение на immutable класс строк и mutable класс аккумулятор строк позволяют достич значительно большей эфективности.

ГВ>Забавляет другое — что некоторый выигрыш Append/Replace нивелируется медленным ToString.

Обычно ToString вызывается гораздо реже Append`ов и крайне редко, чтоб он вызывался в цикле, как было предложено.

C>>>>Но самое замечательное, что С++ вариант банально крашился, если Count = 10000 (и возможно меньше... не проверял между 5к и 10к).

ГВ>>>У меня было всё ровно наоборот: C++ вариант попыхтел на пару с виндой, но таки 10K строк отработал, тогда как C# пыхтел столько же, а потом сказал OutOfMemoryException.
C>>У меня дотнет вариант отработал за примерно 4 секунды, С++ тут же крашнулся без вменяемого сообщения о роде проблемы.

ГВ>На 10000 строк 4 секунды? Интересно.

Да чуть меньше 4х. На 5000 меньше секунды. С2D 3Ghz, 6GB RAM, Win7 64bit.
Re[58]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 08.06.09 19:37
Оценка: +1
Здравствуйте, criosray, Вы писали:

C>А куда ей еще уйти? Все еще раз и еще раз сводится к примитивизму С++, как платформы, где даже такая элементращина, как преобразование типов, требует штудирования MSDN, а для банального replace всех вхождений подстроки в строку надо подкючать стороннюю библиотеку типа boost.


Так С++ это не фреймворк для разработки приложений.. Фреймворк это QT, например...
А С++ это стредство разработки фреймворков...
Если тебе хочется именно мощь фреймворков сравнивать, то имеет смысл сравнивать какие-то фреймворки, а не "голый С++", при этом стоит учесть, что С++ на самом деле предлагает широкий выбор фреймворков. Иногда это хорошо, а иногда плохо...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[61]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 21:49
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

E>>>Если тебе хочется именно мощь фреймворков сравнивать, то имеет смысл сравнивать какие-то фреймворки, а не "голый С++", при этом стоит учесть, что С++ на самом деле предлагает широкий выбор фреймворков. Иногда это хорошо, а иногда плохо...

C>>STL это что?

ГВ>Библиотека, которой повезло быть включенной в стандарт C++. Библиотека. Хочешь — пользуйся, не хочешь — нет.

.NET Framework это тоже библиотека "которой повезло", а String это тоже просто класс.

Только в дотнет к счастью не наплодили зоопарка лишних сущностей. С++ по-сути уникальный язык в плане того, что каждый норовит создать свою реализацию типа строк только потому, что стандартная — ущербна/неудобна... Или Вы знаете другие причины для появления СString, QString и иже с ними?

C>>Да и вообще Вас не поймешь... то "зачем добавлять в язык то, что можно сделать в стандартной библиотеке", то "следует учесть, что С++ предлагает широкий выбор".

C>>Ну учли. И что дальше? Ну давайте сравнивать не std::wstring, а СString, QString или что там еще есть в зоопарке строк С++...

ГВ>Такое сравнение сможет ответить только на один вопрос — насколько хороша или плоха та или иная реализация строк.

Само собою. С реализацией std::wstring разобрались. Какая будет следущей?
Re[63]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 22:08
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Библиотека, которой повезло быть включенной в стандарт C++. Библиотека. Хочешь — пользуйся, не хочешь — нет.

C>>.NET Framework это тоже библиотека "которой повезло", а String это тоже просто класс.

ГВ>Ты можешь выкинуть String из .Net? А я вот, std::wstring смогу запросто.

+1 — зоопарку строк С++ самое место там — на помойке. Выкидывайте.

C>>Только в дотнет к счастью не наплодили зоопарка лишних сущностей. С++ по-сути уникальный язык в плане того, что каждый норовит создать свою реализацию типа строк только потому, что стандартная — ущербна/неудобна... Или Вы знаете другие причины для появления СString, QString и иже с ними?

ГВ>CString точно старше std::wstring. На счёт QString точно не знаю.

Так узнайте.
Например, проскочила информация, что QString immutable...

ГВ>>>Такое сравнение сможет ответить только на один вопрос — насколько хороша или плоха та или иная реализация строк.

C>>Само собою. С реализацией std::wstring разобрались. Какая будет следущей?

ГВ>Можно продолжить играться с std::wstring. Например, подсунуть ей другой аллокатор.


Ну да. А еще можно переписать ее так, чтоб внутри было concatenation tree — сугубо, чтоб заточить под задачу аккумулирования строк.
Re[66]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 23:58
Оценка: +1
Здравствуйте, criosray, Вы писали:

C>>>Например, проскочила информация, что QString immutable...

ГВ>>Для immutable у неё слишком много методов append/insert/replace. Так что, пускай информация скачет дальше.
C>А чем эти методы мешают immutable природе QString? Дотнетовский String тоже имеет эти методы. Не знали?

Дотнетовский, например, String.insert возвращает string. А QT-шный QString::insert возвращает QString&. Разница понятна?

ГВ>>Как вариант. Потом, можно взять другую реализацию STL (не от Microsoft), например, широко известную STLPort.

C>Да уж, скучать не приходится.

Странно, что здесь эдакого?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[67]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 06:36
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:


C>>>>Например, проскочила информация, что QString immutable...

ГВ>>>Для immutable у неё слишком много методов append/insert/replace. Так что, пускай информация скачет дальше.
C>>А чем эти методы мешают immutable природе QString? Дотнетовский String тоже имеет эти методы. Не знали?

ГВ>Дотнетовский, например, String.insert возвращает string. А QT-шный QString::insert возвращает QString&. Разница понятна?

Разница понятна — и то и другое есть ссылка.

Я не знаю immutable ли QString или нет — за что купил, за то и продаю. Если можете доказать обратное — милости просим, но пока Ваши доводы ничего не доказали, равно как ничего и не опровергли.
Re[60]: Ну ты вообще многого не видишь... ;)
От: neFormal Россия  
Дата: 09.06.09 07:47
Оценка: -1
Здравствуйте, criosray, Вы писали:

E>>Если тебе хочется именно мощь фреймворков сравнивать, то имеет смысл сравнивать какие-то фреймворки, а не "голый С++", при этом стоит учесть, что С++ на самом деле предлагает широкий выбор фреймворков.

C>STL это что?

книжки читать надо перед тем, как лезть в споры.. глупостей будет на порядок меньше..
...coding for chaos...
Re[61]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 08:36
Оценка: :)
Здравствуйте, neFormal, Вы писали:

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


E>>>Если тебе хочется именно мощь фреймворков сравнивать, то имеет смысл сравнивать какие-то фреймворки, а не "голый С++", при этом стоит учесть, что С++ на самом деле предлагает широкий выбор фреймворков.

C>>STL это что?

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


Не стоит выставлять на показ свои проблемы с логикой. Не берите пример с Шеридана.
Re[63]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 09:32
Оценка: :)
Здравствуйте, neFormal, Вы писали:

C>>>>STL это что?

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

F>ну, прочитай что ли значение слов "фреймворк" и "библиотека".. вики в помощь:

F>Фреймворк
F>Библиотека
И? STL подходит 100% под определение фреймворка из приведенных Вами ссылок. "Акелла промахнулся".
F>и не пишите больше таких глупостей.. а то сишники полопаются от смеха..
Смейтесь на здоровье. Хорошо смеется тот, кто смеется последним, и это явно будете не Вы.
Re[62]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 11:49
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

ГВ>>Это-то я всё понял, но за комментарии отдельное спасибо.

S>А зачем же я коментарии то пишу?
S>Там есть такая запись после отдачи строки.

S>
S>this.m_currentThread = IntPtr.Zero; 
S>


Судя по всему, это просто маркер текущего потока, который модифицирует строку. Кстати, я не сообразил, что ты привёл код FW-шного стрингбилдера.

public override string ToString()
{
    /*
      this.m_currentThread - маркер "нахожусь в процессе модификации".
    */
    string stringValue = this.m_StringValue;
    if (this.m_currentThread != Thread.InternalGetCurrentThread()) // Вот здесь если IntPtr.Zero идет копирование строки
    {
      /*
        Это происходит в потоке, "чужом" по отношению к тому, который сейчас модифицирует строку.
        Другой случай - никто ничего не модифицирует, просто висит буфер с какими-то оставшимися данными.
      */
        return string.InternalCopy(stringValue);
    }
    if ((2 * stringValue.Length) < stringValue.ArrayLength)
    {
      /*
        А вот это - в том потоке, который сейчас занят модификацией.
        Если буфер заполнен меньше, чем на половину, то копируем строку.
        Маркер "продолжающейся модификации" при этом не снимается.
      */
        return string.InternalCopy(stringValue);
    }

    /*
      Если буфер заполнен больше, чем на половину, имеется активная модификация, и всё это происходит в потоке,
      осуществляющем эту модификацию, то считаем, что этим вызовом ToString текущая модификация заканчивается.
      Вот такая эвристика.
    */

    stringValue.ClearPostNullChar();
    this.m_currentThread = IntPtr.Zero;
    return stringValue;
}


ClearPostNullChar() вероятно, нужен для оптимизации по памяти.

В сумме, если это код FW-шного StringBuildera, то понятно, что он заточен на быструю отдачу строки при условии, что заполнено не менее половины буфера. То есть, EnsureCapacity(очень много) может привести к обратным результатам — StringBuilder будет считать, что всё ещё только начинается.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[64]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 12:03
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>Еще по умолчанию Capacity он же ArrayLength = 16,

S>Если строка меньше 8 то будет постоянно копироваться.

Угу. Ну, тогда результаты тестов становятся объяснимыми. По сути StringBuilder заточен под определённый паттерн использования: создать строку, при необходимости зарезервировав не более, чем 2xLength символов, и отдать строку единственным ToString. Дальше StringBuilder уходит в GC.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[68]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 12:42
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

ГВ>>Спасибо, кстати. Я сам на C# практически ничего не пишу, а так сцепишься с кем — и апеллировать не к чему.

S>C# не основной язык. Просто очень удобно посмотреть внутренности, иногда подсмотреть алгоритмы.
S> Читается код очень легко. (есть конечно и навороты бошку сломаешь).
S> Кстати заметь в этой ветке рефлектор многократно упоминается. А врага надо знать в лицо, а там и в друга превратится

Да какой из .Net враг-то? Потешный, разве что.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[70]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 13:52
Оценка: +1
Здравствуйте, criosray, Вы писали:

C>.NET

C>Average copy speed 653021,989862486 MB/s

C>C++

C>50000000000 bytes copied, with speed of: 19193 MB/s

C>Соотношение считайте сами.


650 GB/sec? Слушай, а бесконечный цикл за сколько секунд прокрутит?

P.S.: Ты хоть понял, что я мерил?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[72]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:06
Оценка: :)
Здравствуйте, Геннадий Васильев, Вы писали:


C>>Average copy speed 681193341743,801 MB/s


ГВ>В общем, слив засчитан. Хотя съехать на "хи-хи" тоже неплохо.


То есть ответить Вам нечего? Отлично.
Re[71]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 14:10
Оценка: +1
Здравствуйте, criosray, Вы писали:


по моему правильно мегабайты будут так

C>
C>Console.WriteLine("Average copy speed {0} MB/s", (sb.Length * count * 2) / stopwatch.Elapsed.TotalMilliseconds/1.024);
C>


или

C>
C>Console.WriteLine("Average copy speed {0} MB/s", (s1.Length * count * 2) / stopwatch.Elapsed.TotalSeconds/1024);
C>

и солнце б утром не вставало, когда бы не было меня
Re[72]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:16
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

S>по моему правильно мегабайты будут так


C>>
C>>Console.WriteLine("Average copy speed {0} MB/s", (sb.Length * count * 2) / stopwatch.Elapsed.TotalMilliseconds/1.024);
C>>


S>или


C>>
C>>Console.WriteLine("Average copy speed {0} MB/s", (s1.Length * count * 2) / stopwatch.Elapsed.TotalSeconds/1024);
C>>

S>

Ха! Точно, но даже не так. А вот так: 1024*1024 байт = 1 MB

To ГВ: "слив засчитан"
Re[72]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:17
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

S>по моему правильно мегабайты будут так


C>>
C>>Console.WriteLine("Average copy speed {0} MB/s", (sb.Length * count * 2) / stopwatch.Elapsed.TotalMilliseconds/1.024);
C>>


S>или


C>>
C>>Console.WriteLine("Average copy speed {0} MB/s", (s1.Length * count * 2) / stopwatch.Elapsed.TotalSeconds/1024);
C>>

S>

Не правильно. Если в компьютерные мегабайты переводить, то надо делить на 1024*1024 с соответственным домножением числителя на 1000.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[77]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 16:28
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

Хочу добавить, что развитие одного благосклонно сказывается на развитие другого. Как говорится борьба и единство противоположностей.
и солнце б утром не вставало, когда бы не было меня
Re[70]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 17:16
Оценка: -1
Здравствуйте, Геннадий Васильев, Вы писали:

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

K>>Но строка — это дерево. И она ни в каком ином виде кроме поддерева, т.е. в виде всех подстрок потомков существовать не может.
K>>Собственное поддерево узла — это собственная подстрока.

ГВ>Не-е-е, Дэвид Блейн, строка — это строка, дерево — это дерево, узлы — это узлы.


Одно из двух: либо Вы откровенно глупы, либо просто пытаетесь троллить.
Re[64]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.06.09 11:00
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

CC>>Что то я такого в этой теме не припомню.
S>Чего ты не припомнишь? Егора?
S>Вот: http://rsdn.ru/Forum/Message.aspx?mid=3415798&amp;only=1
Автор: Erop
Дата: 04.06.09

S>Цитирую:
S>

S>>Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.
S>Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ... А что, смогли что ли?


А где там про эпик вин std::wstring? Я что-то тоже такого не припоминаю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[66]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.06.09 12:35
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

ГВ>>А где там про эпик вин std::wstring? Я что-то тоже такого не припоминаю.

S>

IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки.

S>http://rsdn.ru/Forum/Message.aspx?mid=3415700&amp;only=1
Автор: Erop
Дата: 04.06.09

S>

E>Ты писал, что фишка в том, что создание копии строки дорого стоит, ну так это тогда всё в неэффективность мутабельной строки в С# упирается выходит? Потому, как в С++ удобно и легко получается COW и нет никаких мегапроблем. А для константных строк тоже нет проблем...

S>Ну то есть вот, наша неэффективная мутабельная строка порвала, значит, "удобные и лёгкие" строки в C++.

В упомянутом тобой постинге Егора нет никаких восхвалений в адрес std::wstring (отучаемся додумывать ненаписанное), да и сама std::wstring не упоминается. COW — это не std::wstring.

Так где про эпик вин std::wstring?

S>В общем, это мне уже как-то становится скучно. Есть медицинский факт: строки в С++ спроектированы отвратительно.


Не "строки в C++", а "строки MS STL". Даже не смотря на то, что эти строки описаны в стандарте, нет никаких оснований переносить недостатки, свойственные тем или иным реализциям std::basic_string на весь C++.

S>Я достаточно хорошо понимаю все исторические причины, которые привели к этому архитектурному убожеству.

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

Не смеши меня, ладно? Никто из C++-ников не говорил (AFAIR), что std::wstring есть лучшее решение на все случаи жизни. Это только строка, предусмотренная стандартной библиотекой. Но "стандартная" не означает "обязательная к применению", поэтому нельзя апеллировать к этой реализации, как к обязательно используемой везде в C++ ("строка в C++" — фраза содержит именно такое неявное обобщение). Сама по себе подобная апелляция уже ошибочна. Не нравятся те или иные строки? Сделай другие.

S>А нефанаты тем временем изучают вопросы типа "как правильно проектировать строки, чтобы получать эффективную реализацию". Я вовсе не считаю StringBuilder идеалом. Но то, что порвёт StringBuilder, оставит от ваших std::* кровавые ошмётки.


Ну, поздравляю нефанатов. Наконец-то они дошли до того, что известно любому C++-нику. Что универсальных решений не бывает.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[68]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.06.09 12:48
Оценка: -1
Здравствуйте, Serginio1, Вы писали:

C>>С++ как обычно даёт кучу возможностей сделать что-то красивое (как и выстрелить себе в ногу). Например, я писал свой пакет строк на основе Александресковских. С фичами, которых нет в С# (и не будет). Например, возможностью превратить immutable-строку в mutable при необходимости с почти нулевыми затратами.

S>Stringbuilder занимается таким превращением. http://rsdn.ru/forum/flame.comp/3421959.1.aspx
Автор: Геннадий Васильев
Дата: 09.06.09


Занимается, но только при одном сценарии использования.

var sb = new StringBuilder();
/* цикл модификаций */
string result = sb.ToString();
/* забыли про sb */
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[71]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 10.06.09 16:16
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

C>>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.

G>const — это не то.
G>Вот ты написал метод, который получает const char*.
А зачем я буду писать такой метод?
Sapienti sat!
Re[63]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 10.06.09 20:57
Оценка: :)
Здравствуйте, Erop, Вы писали:


C>>Давайте без домыслов и фантазий бабушки-гадалки, окей?

E>Ну расскажи нам как на "фреймворке STL" передать что-то по сети, или окошко написать, или, хотя бы, прочитать/записать UTF-16 текстовый файл...

И? .NET FW тоже не всемогущ. То, что он гораздо мощнее STL говорит лишь о том, что он гораздо мощнее убогой STL. Что Вам не понятно?
Re[43]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 04:27
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

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


G>>>Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.

PD>>Пойми наконец, что никакой проверки не будет вообще.
G>Ага, процессор магическим образом будет узнавать куда писать не надо.

Нет, процессор ничего знать не будет. Просто при попытке записи в R/O секцию произойдет исключение Access Violation. Ознакомься с основными принципами страничного механизма процессора.
With best regards
Pavel Dvorkin
Re[46]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.06.09 08:35
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Впрочем, дело не в этом. Посмотри, из-за чего весь разговор начался. Дескать, выделение памяти в упроавлеямой куче очень быстрое — так Антон мне заявил. Я с этим и не спорю, но удаление их будет намного менее быстрым — вот и все.

Рихтер очень много пишет о достижимых объектах, поколениях информации о достижимых ссылках итд.
Влад в своей статье тоже неплохо все написал http://rsdn.ru/article/dotnet/GC.xml
Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.
. На самом деле основная работа это поиск достижимых объектов. Если мы не касаемся объектов в старших поколениях а в 0 поколении нет достижимых объектов, то указатель кучи просто сдвигается на ее начало. На самом деле очень много ньюансов где ГС очень хорош, а где и проседает по полной. Смотри в этой же статье насет врайт барьера, а так же не дефрагментируемые Лохи (старый опыт) итд. Все зависит от кокретных условий.
и солнце б утром не вставало, когда бы не было меня
Re[48]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 11.06.09 08:37
Оценка: :)
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>Да не нервничай, проверки-то все равно есть. А "всегда" или "не всегда" зависит уже от ОС и процессора.

PD>Все, моих педагогических способностей больше не хватает . Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
PD>вынести не в состоянии
Дык гони его на пересдачу через деканатскую комиссию, делов то!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[70]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 11.06.09 13:57
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

ГВ>>Ну да, и что? Ты думаешь, кого-то это смущает?

S>Я не думаю, я знаю. Еще раз: покажите мне хоть одну нормальную реализацию строк, вместе с проектом, который на ней построен.
S>Очевидно, разработчиков каких-нибудь XML парсеров всё-таки смущает то, что в базовой комплектации нет внятных строк. Поэтому имеем то, что имеем. А не возможность подсунуть твою мега-гитлер-строку в XML парсер и ускорить его на порядок.
Фигня эти строки. НАСТОЯЩИЕ пацаны пишут XML-парсеры с использованием SSE-инструкций — работает быстрее раз в 10, чем обычные парсеры.

Или библиотеку контейнеров и алгоритмов с поддержкой SSE.

Повтори такое на C#.
Sapienti sat!
Re[70]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 11.06.09 14:49
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

ГВ>>Ну да, и что? Ты думаешь, кого-то это смущает?

S>Я не думаю, я знаю. Еще раз: покажите мне хоть одну нормальную реализацию строк, вместе с проектом, который на ней построен.

Нормальная — это какая? Список требований в студию!

S>Очевидно, разработчиков каких-нибудь XML парсеров всё-таки смущает то, что в базовой комплектации нет внятных строк. Поэтому имеем то, что имеем. А не возможность подсунуть твою мега-гитлер-строку в XML парсер и ускорить его на порядок.


А с чего ты взял, что подсовывание мега-гитлер-строки в XML-парсер ускорит его на порядок?

ГВ>>Повторюсь: если мне не понравятся строки, то хай ANSI вместе XJ21 подавятся своим стандартом — я сделаю новые хранилища/манипуляторы строк и вся идеология C++ тут мне помощником.

S>Смелая гипотеза. Юношеский задор

Цену якобы догматичности стандарта я знаю очень хорошо и до того, чтобы делать глобальные индукции на его базе не опускаюсь уж лет восемь как. Стандарт — это компромисс, но те, кто его разрабатывал, даже не знали о том, с какой спецификой я столкнусь в своих проектах. И кроме того, стандарт в части core language проработан на порядок лучше, чем в части STL. И что мне теперь, сделать из STL икону только потому, что она под одной обложкой с core language?

S>Нет. Вся идеология С++ тут же гирей повиснет у тебя на ногах. Потому что в современном мире только редкие люди могут себе позволить писать без использования сторонних библиотек.


Прости, я говорю об идеологии C++ core language, а не коктейля C++ core language + STL. Во-вторых, я не сказал, что откажусь от всего STL. В-третьих, даже MFC в своё время не повисала гирей у меня на ногах. ЧЯДНТ?

ГВ>>Единственное место, где неизбежно придётся учитывать наличие ASCIIZ — строковые литералы, так их вообще, чем меньше — тем лучше. А сторонние API — это всегда сторонние API со своими приколами (CRT — тоже один из API).

S>Все приколы сторонних АПИ связаны именно с тем, что нет нормальной архитектуры.

Да??? То есть не с десятилетиями предыдущей истории в которой было всё: от ограничений по объёму памяти до неразберихи с кодировками, а с тем, что сейчас изменились представления о нормальной архитектуре? Welcome to the real world, коллега.

ГВ>>Хорошо, пусть проблема будет в контракте. Но и это не повод переносить недостатки контракта basic_string на весь C++. Если хочешь, давай отдельно поругаем контракт basic_string, я не против. Мне он тоже не во всём нравится.

S>Ишь, какой ты хитрый! Нет уж, хрен там. Это не я придумал вносить STL в стандарт языка. Поэтому я имею полное право критиковать "строки в С++" именно в том виде, в каком их предложил комитет.

Хорошо, понятно. Говоря о строках в C++ ты имеешь в виду "строки, описанные в стандарте C++". Тут есть некоторая разница со "строками в C++", не находишь?

S>Или ты рассчитывал, что я буду обсуждать исключительно компилятор С++? Спору нет, компилятор в С++ просто прекрасен. Но без STL он даже не заработает.


Почему это он без STL не заработает? Ты про type_info и xxxxx_cast, которые поддерживаются компилятором? Это микроскопический кусок STL. Зато ни один из известных мне компиляторов не порождает std::string заметив в тексте программы строковый литерал. И это, ИМХО, хорошо.

ГВ>>Кто тебе сказал такую глупость? Они будут интероперировать через промежуточные абстракции. Никто не мешает выполнять преобразование из rope к ASCIIZ в последний момент перед вызовом функции, требующей именно ASCIIZ. В чём прикол твоего утверждения о невозможности интероперабельности?

S>В том, что нет никакого смысла держать "эффективные строки", которые один хрен нужно неэффективно преобразовывать в непонятно что при отдаче в любой внешний код. Ты не можешь прочитать "эффективную строку" из файла, ты не можешь передать "эффективную строку" для вывода на экран. Всё, что ты можешь делать — это жонглировать ей внутри узкого кусочка своей программы.

Гы-гы. Так затраты на чтение из файла и на выдачу на экран с лихвой покрывают почти любую неэффективность преобразований (кроме того, из файлов читают линейные последовательности байтов, а не строки). Эффективные строки мне понадобятся, когда возникнет необходимость, например, оптимизировать операции модификации строк. Или когда строк окажется тыща мильёнов и понадобится разобраться с фрагментированием памяти. А в "типичных" программах потери на хранение и операции даже с такими строками, как std::wstring так же комичны, как тестирование StringBuilder на неэффективность.

И потом, что за пренебрежительный тон? Жонглировать... Не жонглировать, а решать задачу.

ГВ>>Надо посмотреть, обещать ничего не могу, но, вроде бы, какая-то из реализаций STL выполняла преобразование к ASCIIZ по запросу c_str().

S>А что, не все реализации возвращают ASCIIZ по запросу с_str()???

Вроде бы, не все хранят ASCIIZ. А возвращать должны все. То есть c_str() может неявно вызывать дополнительное распределение буфера под ASCIIZ-представление.

S>Я тебе на всякий случай напомню, что это — небезопасная строка. На ее константность полагаться нельзя, т.к. по контракту std::string рушит этот буфер после первого же неконстантного вызова.


Одно другому не противоречит.

ГВ>>Тройной одеколон вам в перегонку... С++-ники сопротивляются переносу оценки "УГ" по маршруту: std::basic_string -> C++ -> C++-ники. Не трещите так много про унылость "самих C++-ников" и C++ — и прекрасно услышите, как сами C++-ники ругают и ASCIIZ, и std::basic_string. Понимаешь? Вот не надо неправомерных обобщений и всё будет намного проще.

S>Я делаю обобщения совершенно правомерно. Показываю еще раз: std::basic_string, как и std::wstring — отстой. Это мы уже выяснили путём непросредственного сравнения.

Ещё раз. В сравнении участвовала одна из реализаций STL. Проблемы контракта std::basic_string очень далеки от мутабельности/иммутабельности, если тебе это интересно. Например, на мой взгляд, недостатком является засовывание методов find в сам класс строки. Даже не недостатком, а странностью: на фига он там, если есть итераторы?

S>И проблема — не в конкретной реализации, а в том, что хреново спроектированы контракты этих классов.


Ты постулируешь таким образом, что в рамках текущего контракта basic_string нельзя "порвать" StringBuilder? С чего ты взял? Вопрос только в степени наивности индукций о реализации, сделанных разработчиками данной версии STL на основе прочтения контракта. ИМХО — так.

S>Именно контракты являются частью стандарта С++, что даёт мне право говорить о том, что "строки в стандарте С++ — говно".


В стандарте C++, правильно.

S>Про с++ников я такого не говорил, хотя люди, готовые закидать меня минусами только за то, что я повторяю банальную истину, вместо того, чтобы хоть на минуту о ней задуматься, доброго слова не заслуживают. Мне, собственно, всё равно — можете засунуть голову в песок хоть по пояс. Хороших строк в С++ от этого не появится.


Что-то твои "банальные истины" очень сильно граничат с трюизмами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[72]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 11.06.09 16:58
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

S>Ну, к примеру с того, что подсовывание стрингбуфера в своё время на порядок подняло перформанс компилятора Явы.

При чём тут Ява?

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

S>Мне всё равно, по каким причинам разработчики стандарта сделали его таким. Ну, то есть не всё равно — я читал, к примеру, Дизайн и Эволюцию, и историю вопроса представляю себе достаточно хорошо. Но это никак не отменяет того факта, что результат недостаточно хорош.

С этим фактом никто и не спорит.

ГВ>>И кроме того, стандарт в части core language проработан на порядок лучше, чем в части STL. И что мне теперь, сделать из STL икону только потому, что она под одной обложкой с core language?

S>А куда тебе деваться? Или ты готов объявить "языком C++" только то, что тебе нравится? Отлично. Ну так поздравляю — в твоём С++ недостатков вовсе нет. Потому что твоя позиция позволяет "не делать из них икону".

Отнюдь. Дело не в том, что мне нравится, а что нет.

ГВ>>Прости, я говорю об идеологии C++ core language, а не коктейля C++ core language + STL.

S>Прости, что такое "идеология core language"?

Не платить за то, чем не пользуешься.

ГВ>>Во-вторых, я не сказал, что откажусь от всего STL.

S>Да? Ты сразу перечисли то, от чего откажешься. Чтобы я знал, что критиковать нельзя.

Да критикуй на здоровье всё, что угодно.

ГВ>>В-третьих, даже MFC в своё время не повисала гирей у меня на ногах. ЧЯДНТ?

S>Ты? Не сравниваешь с другими возможностями.

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

S>Я, когда программировал на MFC, тоже не представлял себе, в чём там может быть проблема.


Оба-на! Какое знаменательное во многих отношения признание. Значит, у нас с тобой диаметрально противоположная оценка MFC. Меня понимание неудобоваримостей MFC вовсе не сковывало, хотя я тоже называл её разными нехорошими словами, мне мешало только то, что я не мог остановиться на какой-то определённой модели её совершенствования. Ах, юность, юность.

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


Ну поздравляю. Тебя ждёт ещё уйма удивительных открытий, например, что корректная и непротиворечивая постановка задачи решающим образом сказывается на скорости производства и качестве ПО, а вовсе не +- 100 строк на сериализацию. А из корректной постановки задачи уже растут остальные хорошо-плохо и правильно-неправильно. Тогда как сама по себе корректная постановка задачи непосредственно касается психологии, подчас — психиатрии.

ГВ>>Да??? То есть не с десятилетиями предыдущей истории в которой было всё: от ограничений по объёму памяти до неразберихи с кодировками, а с тем, что сейчас изменились представления о нормальной архитектуре?

S>Да, представления изменились. Увы. Давайте теперь говорить, что ВАЗ 2101 — классная машина, потому что десятилетия назад это был ФИАТ.
S>Извини, с тех пор представления о "классной машине" немножко изменились. ВАЗ 2101 в этом не виноват. А вот те, кто упорно за него цепляется, отказываясь понимать преимущества инжекторного двигателя, коробки-автомата, кондиционера — виноваты.

Некорректная аналогия. С другой стороны, дороги, которые разбивали вдребезги подвеску ВАЗ 2101 в такой же хлам разнесут современную "классную машину", даже быстрее. Если это не БТР.

ГВ>>Хорошо, понятно. Говоря о строках в C++ ты имеешь в виду "строки, описанные в стандарте C++". Тут есть некоторая разница со "строками в C++", не находишь?

S>Да-да, можно еще и так попытаться выкрутиться. Ок. Давай тогда так: о чём ты говоришь, говоря о "строках в С++"?

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

S>Вот варианты:

S>1. Только строковые константы. STL — не часть языка, а core language ничего, кроме ASCIIZ, не умеет
S>2. Все стандартизованные строки, то есть std::string и ASCIIZ
S>3. Все классы строк, реально написанные в реальных фреймворках на основе C++: MFC, ATL, QT, etc.
S>4. Те классы строк, которые могли бы быть потенциально написаны на C++, если бы кто-то взялся за этот непосильный труд, и это имело какой-то практический смысл, с учётом объема легаси-кода, построенного на строках из п.3.
S>Я предлагаю пункт 2, но он тебе не подходит. Пункт 3, по какому-то неудачному стечению обстоятельств, тоже предлагает какое-то ужасное г. (по сравнению с CString, STL-ный вариант еще ничо). Опровергни меня, если я неправ.

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

S>Против пункта 4 я решительно возражаю: я тогда ему противопоставлю еще более потенциальные строки, которые могли бы быть написаны на гипотетической VM. Я говорил об имеющихся фактах, а не о сослагательном наклонении.


Э-э-э... Гипотетическая VM будет проще в реализации, чем гипотетическая строка?

ГВ>>Почему это он без STL не заработает?

S>Потому что RTFM. Потому что ему нечего будет бросать в случае нехватки памяти.

А... Тут ты прав. Исключения описаны в рамках STL. Правда, в стандарте, тем не менее, не сказано, что исключения должны быть реализованы именно через std::string. Кстати, код std::exception из MS STL сюда загнать или сам посмотришь? Там никакими std::string даже не пахнет.

ГВ>>Ты про type_info и xxxxx_cast, которые поддерживаются компилятором? Это микроскопический кусок STL. Зато ни один из известных мне компиляторов не порождает std::string заметив в тексте программы строковый литерал. И это, ИМХО, хорошо.

S>Это, имхо, плохо. Ну, то есть порождение std::string его бы, конечно, не спасло. Но и то, что он сейчас порождает, плохо. Потому что ASCIIZ-литералы лишены даже длины, что для современных строковых литералов недопустимо. Даже холлеритовские строки в фортране и то были лучше спроектированы (хоть и ужасно выглядели).

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

ГВ>>Гы-гы. Так затраты на чтение из файла и на выдачу на экран с лихвой покрывают почти любую неэффективность преобразований (кроме того, из файлов читают линейные последовательности байтов, а не строки). Эффективные строки мне понадобятся, когда возникнет необходимость, например, оптимизировать операции модификации строк. Или когда строк окажется тыща мильёнов и понадобится разобраться с фрагментированием памяти. А в "типичных" программах потери на хранение и операции даже с такими строками, как std::wstring так же комичны, как тестирование StringBuilder на неэффективность.

S>А-а, ну-ну. Третий способ вильнуть, значит. Ок, производительность строк вообще никого не интересует. И это у нас, значит, позиция поклонников "самого эффективного в мире языка". Отлично. Можно, я буду ссылаться на этот пост всякий раз, когда кто-то будет гнобить С# за, к примеру, проверки на выход за границы массива?

Во-первых, не надо обобщать мою позицию на всех. Во-вторых, повторюсь — это всё ровно до той поры, пока производительность на самом деле никого не волнует. Если она вдруг взволнует, то на C++ у меня несколько больше возможностей для манёвра, нежели на C#. Понимаешь, о чём я?

ГВ>>Вроде бы, не все хранят ASCIIZ. А возвращать должны все. То есть c_str() может неявно вызывать дополнительное распределение буфера под ASCIIZ-представление.

S>Может. Это она запросто.

ГВ>>Ещё раз. В сравнении участвовала одна из реализаций STL. Проблемы контракта std::basic_string очень далеки от мутабельности/иммутабельности, если тебе это интересно.

S>Ок. Приведи хорошую реализацию wstring с тем же контрактом.

Осталось её найти... Или написать.

ГВ>>Например, на мой взгляд, недостатком является засовывание методов find в сам класс строки. Даже не недостатком, а странностью: на фига он там, если есть итераторы?

S>Недостаток-недостаток. Это правда. Вообще, очень-очень многие фреймворки на C++ грешат злоупотреблением методами экземпляров.

Да это всему ООП-нутому свойственно. Ладно, фиг с ним.

ГВ>>Ты постулируешь таким образом, что в рамках текущего контракта basic_string нельзя "порвать" StringBuilder? С чего ты взял?

S>Из опыта, который сын ошибок трудных.

Скорее, из того, что ты этого ни разу не видел.

ГВ>>Вопрос только в степени наивности индукций о реализации, сделанных разработчиками данной версии STL на основе прочтения контракта. ИМХО — так.

S>В таком случае тебя, наверное, не затруднит "починить" данную версию STL так, чтобы она опередила управляемые строки, не изменяя контракта. С потокобезопасностью, всё такое.
Лето, солнце, море, почему бы и не переписать std::basic_string? Кстати, потокобезопасность не входит в контракт std::basic_string.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[52]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.06.09 08:18
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>>>Какой тест?

PD>>>http://rsdn.ru/forum/flame.comp/3419879.1.aspx
Автор: Pavel Dvorkin
Дата: 08.06.09

G>>Прекрасно, а теперь напиши аллокатор для таких "констант" минимально дефрагментирующий память.

PD>Тот же самый, что и в .Net или в C++.

Это принципиально разные аллокаторы, ты определись.

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

Не надо голословных заявлений. Поркажи код.

PD>А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.

Так детали тут — самое интересное. Пока нету практического подтверждения полезности твоей теории все что ты говоришь — фуфло.

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

PD>А ты подумай насчет того, что это можно применть к объектам любого типа, а не только к тем, что объявлены иммутабельными по типу.
Я то подуал, и пришел к мысли что нафиг оно не надо. Если компилятор и так будет анализировать неизменность объекта, то зачем лишние действия в рантайме?
Re[49]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 15.06.09 09:19
Оценка: :)
Здравствуйте, Antikrot, Вы писали:

PD>>Если она не включена, то, очевидно, мы имеем дело с некоторой иной ОС, а там все, конечно, может быть иначе. Я это не обсуждал и не буду.


A>а как же:

A>

A>Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
A>вынести не в состоянии


Имелось в виду, разумеется, при включенном страничном механизме.
With best regards
Pavel Dvorkin
Re[53]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 15.06.09 09:27
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

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


G>>>>>Какой тест?

PD>>Тот же самый, что и в .Net или в C++.
G>Это принципиально разные аллокаторы, ты определись.

Незачем мне определяться. Если речь идет о добавлении этой функциональности к C++, то и куча типа C++. Если к .Net — то и куча от .Net. Если к некоей мной системе — то ее куча.


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

G>Не надо голословных заявлений. Поркажи код.

Ничего себе! Я , видимо, должен для тебя прямо-таки менеджер кучи написать! Сейчас и не сходя с места.
А впрочем, исходники CRT кучи для С++ есть в комплекте VS. Исходники .Net кучи где взять — тебе лучше знать

PD>>А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.

G>Так детали тут — самое интересное. Пока нету практического подтверждения полезности твоей теории все что ты говоришь — фуфло.

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

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

PD>>А ты подумай насчет того, что это можно применть к объектам любого типа, а не только к тем, что объявлены иммутабельными по типу.
G>Я то подуал, и пришел к мысли что нафиг оно не надо. Если компилятор и так будет анализировать неизменность объекта, то зачем лишние действия в рантайме?

М-да... Хоть кол на голове теши... Ему объясняешь, что это может применяться к любым объектам — а он все за свое.

Ладно, все, с меня хватит.
With best regards
Pavel Dvorkin
Re[50]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 17.06.09 05:48
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Кстати, написан MySQL на чистом С. Из чего с неизбежностью следует, что нет там ни геттеров, ни сеттеров, ни интерфейсов, ни темплейтов , ни итераторов и вообще ничего из той кунсткамеры, без которой вы теперь жить не можете. И ничего — вполне себе живет и неплохо себя чувствует.



Б-г-г )))
Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".
Очень показательно, что ты привел в качестве этакого эталона это УГ
Re[50]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 17.06.09 13:49
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я учитЬся хочу, но только тому, что мне для работы годится. Например, CUDA — годится, поэтому я недавно ее и осваивал. .Net, VB, Python и прочие Хаскели — не годится, а поэтому мне на них время тратить незачем.

Ты очень сильно ошибаешься.

PD>Вот на это вы все и рассчитываете. Сделаем как-нибудь, работать все же будет (а кто спорит — будет!), а оптимизировать и не придется.

Не как-нибудь, а так чтобы уложится в требования.

PD>О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы

Я в недавнем прошлом работал в Яндексе старшим разработчиком.
И именно так все и было. После того как сервис был написан его за пару дней разгоняли в сотни раз.
Так что давай ты больше при мне не будешь заикаться про что-то вроде www.microsoft.com ибо как работает это самое что-то вроде я знаю неизмеримо лучше тебя.

PD>А общие принципы я , конечно, знаю.

Сомнительно.
К тому же я имел в виду не только СУБД, а вообще все.
Включая "ненужные" тебе .Net, хаскель и многое другое.

PD>Кстати, написан MySQL на чистом С. Из чего с неизбежностью следует, что нет там ни геттеров, ни сеттеров, ни интерфейсов, ни темплейтов , ни итераторов и вообще ничего из той кунсткамеры, без которой вы теперь жить не можете. И ничего — вполне себе живет и неплохо себя чувствует.

Ну если использовать его только как дисковую подсистему и делать свою БД поверх него то может и не плохо.
Но шаг в сторону и приплыли.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[52]: Ну ты вообще многого не видишь... ;)
От: kuj  
Дата: 17.06.09 22:01
Оценка: :)
Здравствуйте, Anton Batenev, Вы писали:

_>> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


AB>Типа YouTube?


Как будто ютюб хранит ролики в майсикле.
Re[53]: Ну ты вообще многого не видишь... ;)
От: Anton Batenev Россия https://github.com/abbat
Дата: 17.06.09 22:23
Оценка: +1
Здравствуйте, kuj, Вы писали:

kuj> _>> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


kuj> AB>Типа YouTube?


kuj> Как будто ютюб хранит ролики в майсикле.


А что, подобный кретинизм стал отличительным признаком "чиста пацанских сайтов"? Речь шла про "моя первая пага". И эта... выдыхай...
avalon 1.0rc1 rev 247, zlib 1.2.3
Re[56]: Ну ты вообще многого не видишь... ;)
От: kuj  
Дата: 18.06.09 09:49
Оценка: -1
Здравствуйте, Anton Batenev, Вы писали:

kuj>> kuj>> _>> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


kuj>> kuj>> AB>Типа YouTube?


kuj>> kuj>> Как будто ютюб хранит ролики в майсикле.


kuj>> AB>А что, подобный кретинизм стал отличительным признаком "чиста пацанских сайтов"? Речь шла про "моя первая пага". И эта... выдыхай...


kuj>> Угу, и кто из нас спорит с тем, что майсикел не годится для "моя первая пага"? ;]


AB>Ютуб — это "моя первая пага"?! Для моей первой паги годится. Для ютуба (который первой пагой не является) годится. Ну а хранить ролики в MySQL это тебе твой друг обкуренный чебурашка на ухо нашептал. Ты сейчас какой из тезисов оспорить-то пытаешься?


Это ты пытался оспорить и обосрался. ;]
Re[58]: Ну ты вообще многого не видишь... ;)
От: kuj  
Дата: 18.06.09 10:14
Оценка: :)
Здравствуйте, CreatorCray, Вы писали:

kuj>>Это ты пытался оспорить и обосрался. ;]

CC>Когда ж тебя опять забанят то?

Наверно тогда, когда ты наконец начнешь писать осмысленные посты — не скоро, то бишь. ;]
Re[52]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 19.06.09 07:29
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Голословные утверждения особой ценности не представляют. У меня основное требование — скорость, второе — объем памяти. И всякие лишние действия мне ни к чему. Поэтому я вряд ли сильно ошибаюсь, тем более, что я и сам тестировал (.Net) и читал, что тут писали (другие системы).


На самом деле разные языки разные подходы, их-за возможностей. Знание обогащает, и в редких моментах натыкают на нужный алгоритм, чегобез знания не было бы возможно. Да и для различных задач нужны разные инструменты. Да и в конце то в концов получкние новых знаний и навыков доставляет удовольствие. Не всё упирается в узкую специализацию.
и солнце б утром не вставало, когда бы не было меня
Re[52]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 19.06.09 09:03
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Голословные утверждения особой ценности не представляют. У меня основное требование — скорость, второе — объем памяти. И всякие лишние действия мне ни к чему. Поэтому я вряд ли сильно ошибаюсь, тем более, что я и сам тестировал (.Net) и читал, что тут писали (другие системы).


Ты создал себе идолов, догматы, стереотипы и истово в них веришь.
Re[54]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 19.06.09 10:20
Оценка: +1
Здравствуйте, Eugeny__, Вы писали:


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


Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.
Про Ютуб
От: Mamut Швеция http://dmitriid.com
Дата: 19.06.09 15:09
Оценка: +1
E> E__>>Самое забавное, что похоже, именно так и есть(гугл поможет найти еще подтверждения). Для меня, кстати, это новость(я как-то не задумывался раньше, в чем гугл хранит видео), я и сам удивился.

E> C>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.


E> Возможно. У меня недостаточно инфы, чтобы подтвердить это, или опровергнуть.


Все здесь: http://highscalability.com/youtube-architecture

Видео естественно хранится отдельно, в мини-кластерах
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[50]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 20.06.09 07:24
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы
Павел, я боюсь тебя разочаровать, но я разрабатывал сайт с количеством посетителей в сутки примерно в десять раз выше, чем на RSDN. Это, конечно, не microsoft.com, но вполне себе hi load.

И именно таким способом — сначала сделали "что-нибудь", а потом улучшали с помощью профайлера. И сайт www.microsoft.com, уверяю тебя, делался точно так же. Никто не гулял в саду неделями, ожидая, когда же его осенит "идея алгоритма".

И яндекс разрабатывают именно так — почитай блоги разработчиков, где-то была статья на похожую тему.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[52]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 20.06.09 09:29
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Голословные утверждения особой ценности не представляют. У меня основное требование — скорость, второе — объем памяти. И всякие лишние действия мне ни к чему. Поэтому я вряд ли сильно ошибаюсь, тем более, что я и сам тестировал (.Net) и читал, что тут писали (другие системы).

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

PD>А ведь вы правы. Реально ваши задачи таковы, что от вас ускорить быстродействие в 5 раз не потребуют. Ну выросла компания в 2 раза, ну увеличилась нагрузка в 2 раза, ну замедлился ответ в 2 раза (а может, и не замедлился, было 5 посетителей в день, стало 10 , ну и ладно. А когда компания сильно разрастется, то выкинут они этот сатй на помойку и сделают новый.

Ты даже не представляешь насколько ты не прав.

PD>Но не у всех такие задачи. Вот поэтому ты и неправ в общем случае.

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

PD>Ты Яндексовый движок писал ? Или что-то к движку ?

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

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

Обычные такие программисты.
И пишут они правильно.
И именно по тому что все написано правильно при нагрузочном тестировании так все и разгоняется.
Причем оно все не только разгоняется но еще и масштабируется.

PD>Извини, но для того, чтобы с этим согласиться, нужен ответ на вопрос, что именно ты писал. Естественно, ты вправе его не давать.

То что живет под нагрузкой.

WH>>Ну если использовать его только как дисковую подсистему

PD>???
WH>>и делать свою БД поверх него то может и не плохо.
PD>???
Во-во как обычно полное не понимание того о чем вообще разговор... и еще говоришь что понимаешь как это все работает...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[58]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 21.06.09 09:13
Оценка: -1
Здравствуйте, _d_m_, Вы писали:

C>>>>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.


___>>>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.


C>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


___>Стереотипы, догматы, верим, поклоняемся, забываем — что ничто не вечно, все течет, изменяется...

___>http://blogs.technet.com/josebda/archive/2007/10/25/the-legend-of-the-single-multi-terabyte-replicating-sharepoint-database.aspx
___>http://www.rsdn.ru/forum/db/3038587.flat.aspx
Автор: megapoliss
Дата: 28.07.08


Нет, хранение бинарной информации больших объемов в БД совершенно неприемлимо. Мы говорим о терабайтах информации. Информации, которую не возможно практически кешировать (точнее возможно, но в ограниченном объеме). Нагрузка на базу будет колоссальной и совершенно неприемлимой.
Re[59]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 09:25
Оценка: +1
Здравствуйте, criosray, Вы писали:

C>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


___>>Стереотипы, догматы, верим, поклоняемся, забываем — что ничто не вечно, все течет, изменяется...

___>>http://blogs.technet.com/josebda/archive/2007/10/25/the-legend-of-the-single-multi-terabyte-replicating-sharepoint-database.aspx
___>>http://www.rsdn.ru/forum/db/3038587.flat.aspx
Автор: megapoliss
Дата: 28.07.08


C>Нет, хранение бинарной информации больших объемов в БД совершенно неприемлимо. Мы говорим о терабайтах информации. Информации, которую не возможно практически кешировать (точнее возможно, но в ограниченном объеме). Нагрузка на базу будет колоссальной и совершенно неприемлимой.



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

Оттуда:

>>Подумай над возможностью хранить сами документы на файловой системе (FTP/HTTP/.. сервере), а в базе только ссылки на них.
M>Имею глубокое убеждение, что блобам вобще не место в БД.

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


По теме:
http://www.terraserver.com/
Re[61]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 10:12
Оценка: +1
Здравствуйте, criosray, Вы писали:

___>>

___>>Ну ты бы ссылочки почитал для начала, прежде чем постить — там речь о терабайтах.
C>Я почитал. Не нашел ничего, что противоречило бы утверждению о том, что большие объемы бинарной информации хранить в БД крайне неэффективно.

Б-г-г
Там нет и подверждения того:

что большие объемы бинарной информации хранить в БД крайне неэффективно.


___>>По теме:

___>>http://www.terraserver.com/
C>И где доказательства, что бинарные данные там хранятся именно в файле(ах) БД?

http://terraserver-usa.com/about.aspx?n=AboutTechDbschema

The Imagery table in the logical Imagery database partition contains the majority of data stored within TerraServer-USA. The Imagery table contains the "blob" field where the imagery data is stored.

Re[60]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 21.06.09 12:13
Оценка: -1
Здравствуйте, _d_m_, Вы писали:


___>Несколько о другом. О раздельном хранении в ФС и в БД.

Я говорил именно так: "ютюб скорее всего хранит ролики не в бд, а на файловой системе, а в бд только ссылки на файлы".

___>Кстати, ссылки приведенные мной — про MS SQL до версии 2008. Я за хранение блобов в БД, даже без FILESTREAM.

Это годится только для очень малых объемов бинарной информации.
Re[53]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 03:51
Оценка: :)
Здравствуйте, Serginio1, Вы писали:

S> На самом деле разные языки разные подходы, их-за возможностей. Знание обогащает, и в редких моментах натыкают на нужный алгоритм, чегобез знания не было бы возможно.


Честно говоря, не очень пойму, как переход , скажем, с паскаля на С++ или с С++ на C# может натолкнуть на новый алгоритм. ИМХО все же первичен алгоритм, а потом уж его реализация на каком-то языке.

>Да и для различных задач нужны разные инструменты.


Совершенно согласен. Но вот это мои оппоненты понять и принять никак не хотят. Я им в сотый раз объясняю, что у меня другие задачи, а они мне в ответ — C# лучше всего

>Да и в конце то в концов получкние новых знаний и навыков доставляет удовольствие.


+1
With best regards
Pavel Dvorkin
Re[54]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 22.06.09 06:31
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

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


S>> На самом деле разные языки разные подходы, их-за возможностей. Знание обогащает, и в редких моментах натыкают на нужный алгоритм, чегобез знания не было бы возможно.


PD>Честно говоря, не очень пойму, как переход , скажем, с паскаля на С++ или с С++ на C# может натолкнуть на новый алгоритм. ИМХО все же первичен алгоритм, а потом уж его реализация на каком-то языке.

Delphi C# различная архитектура классов (хотя ооочень похожа), различные подходы для решения задач из-за встроенных возможностей например метаклассы (виртуальные кострукторы, виртуальные методы классов), итд.
Функциональное и империческое программирование. Здесь много различий. В том числе различные алгоритмы для решения оджних и тех же задач
Самое главное это менять навыки, которые не всегда оптимальны для любых задач. А вот получение дополнительных навыков позволяет варьировать ими. Именно навыки, т.к. знания без навыков, это только верхушка айсберга.
Если честно то твоя позиция мне близка, но я стараюсь от нее отходить
и солнце б утром не вставало, когда бы не было меня
Re[54]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 22.06.09 06:37
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

___>>Т.е. ты просто выполнял требования работодателя. Ну это несколько другое.


PD>Интересное кино начинается опять. То тут мне всякие (вроде не ты) доказывают, что соответствие требования заказчика — это , мол, самое главное (с чем я не вполне согласен), то вдруг, когда обнаруживается, что я их выполнил — это мол, несколько другое


PD>На самом деле я их не выполнил.


Еще бы при таком неверном в корне способе разработки Вы их выполнили...
Re[55]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 22.06.09 06:41
Оценка: +1
Здравствуйте, Serginio1, Вы писали:

S>>> На самом деле разные языки разные подходы, их-за возможностей. Знание обогащает, и в редких моментах натыкают на нужный алгоритм, чегобез знания не было бы возможно.


PD>>Честно говоря, не очень пойму, как переход , скажем, с паскаля на С++ или с С++ на C# может натолкнуть на новый алгоритм. ИМХО все же первичен алгоритм, а потом уж его реализация на каком-то языке.

S> Delphi C# различная архитектура классов (хотя ооочень похожа), различные подходы для решения задач из-за встроенных возможностей например метаклассы (виртуальные кострукторы, виртуальные методы классов), итд.
S>Функциональное и империческое программирование. Здесь много различий. В том числе различные алгоритмы для решения оджних и тех же задач

+ аспект-ориентированное программирование, +domain specific languages. Если говорить о Nemerle, то еще и метапрограммирование добавляется...
Re[55]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 08:11
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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


PD>>Супер! Поскольку о задаче ты не имеешь никакого представления, то это твое утверждение означает, что ты готов решить любую задачу, причем с блеском, да еще и неожиданным для меня способом! Ну и ну!

WH>Ты сам не раз говорил про числомолотилки.

Я многое про что говорил. Но об основной своей работе — нигде и никогда.

WH>Я это умею. Через одну из них прошло никак не меньше 50 миллионов изображений.


Я рад за тебя

WH>Причем умею применять в том числе волшебные методы...

WH>Сейчас изучаю очередную магию на эту тему...

Успехов!

WH>>>Яндекс большой и движков там много.

WH>>>И таки да я писал движки которые живут в продакшене под нагрузкой.
PD>>Это не ответ. Являются ли эти движки (или их части) критическими по времени ?
WH>Прочитай выделенное.

Ну что же, если это так, +1 тебе. Для задач этого рода, вполне допскаю, такой подход может и работать.

PD>>Супер! В общем , все ясно — "по этому вопросу есть два мнения, одно мое, другое неправильное"

WH>Зеркало принести?

Зачем ? Ты же можешь сам в него посмотреть!

PD>>Точно, полное непонимание. До сих пор дисковой подсистемой называлось нечто иное.

WH>Дисковая подсистема это то что работает с дисками.

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

М-да... Не мог бы ты объяснить, как именно MySQL напрямую работает с дисками ? Или, может, с дисками все же работают драйверы и диспетчер ввода-вывода, а MySQL, как впрочем, и другие программы, работает с этим драйвером и ДВВ через АПИ В/В, которая есть часть Win API в случае Windows ?

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

При таком твоем понимании базовых механизмов ОС я вынужден с тобой согласиться, когда ты пишешь, что готов решить любую задачу самым неожиданным способом! Действительно, неожиданностей будет хоть отбавляй!
With best regards
Pavel Dvorkin
Re[56]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 22.06.09 08:30
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я многое про что говорил. Но об основной своей работе — нигде и никогда.

Ну так расскажи что же такого супер крутое ты там делаешь что нам всем до тебя как до луны?

PD>Ну что же, если это так, +1 тебе. Для задач этого рода, вполне допскаю, такой подход может и работать.

Оно для любых задач подходит.
Просто ты это понять не можешь.
А вообще забавно получается. Ты кричишь что я не смогу написать мелкософт.ком

О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы

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

PD>Зачем ? Ты же можешь сам в него посмотреть!

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

PD>О сколько нам открытий чудных

PD>Готовит просвещенья дух...
Ага. На разных уровнях абстракции дисковой подсистемой могут быть разные вещи...
А то что ты не умеешь абстрагироваться это твои проблемы.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[55]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 08:54
Оценка: -1
Здравствуйте, Serginio1, Вы писали:

S> Delphi C# различная архитектура классов (хотя ооочень похожа), различные подходы для решения задач из-за встроенных возможностей например метаклассы (виртуальные кострукторы, виртуальные методы классов), итд.


И все же в начале алгоритмы, а не структура классов. Тем более те случаи, когда приходится эти алгоритмы самому реализовать, а не использовать существующие классы. А у меня в основном именно такое

S>Функциональное и империческое программирование. Здесь много различий. В том числе различные алгоритмы для решения оджних и тех же задач


+1. Но не мое это (функциональное)

S> Самое главное это менять навыки, которые не всегда оптимальны для любых задач.


+1

S>Если честно то твоя позиция мне близка, но я стараюсь от нее отходить


With best regards
Pavel Dvorkin
Re[69]: Но продолжим органометрию
От: Воронков Василий Россия  
Дата: 24.07.09 20:55
Оценка: +1
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>for (int i = 0; i < Count; i++)

ГВ>{
ГВ> s = sb.ToString();
ГВ>}

ГВ>Соотношение времени выполнения... 6:1 в пользу C++


А смысл теста какой? Ты неправильно используешь класс. В результате чего доказал, что если на шарпе писать криво, то код тормозит. Хотя если использовать StringBuilder по прямому назначению он будет побыстрее, чем wstring.
Re[13]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 28.10.09 05:47
Оценка: +1
Здравствуйте, VladD2, Вы писали:

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


VD>Так что потрудись найти реальные доказательства своих слов или перестать нести чушь и нарушать правила форума.


Держи.

http://www.rsdn.ru/forum/philosophy/1441496.1.aspx
Автор: VladD2
Дата: 18.10.05
With best regards
Pavel Dvorkin
Re[14]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.10.09 15:13
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Держи.


PD>http://www.rsdn.ru/forum/philosophy/1441496.1.aspx
Автор: VladD2
Дата: 18.10.05


И что ты там узрел?

ЗЫ

Собственно, очевидно, что подтверждения твоим словам не будет.
Мое мнение такое.... Хочешь общаться — общайся. Хочешь спорить — спорь. Но в рамках приличия. Я вот стараюсь не обсуждать твою квалификацию. Хотя порой и очень хочется (особенно учитывая то где ты работаешь).
Так что или очень советую добровольно вернуться в рамки приличия.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.10.09 02:30
Оценка: +1
Здравствуйте, VladD2, Вы писали:
VD>И что ты там узрел?
Как что? С точки зрения Павла, человек, не сумевший увидеть неверно поставленную скобку — плохо знает язык.
Это же специальный такой язык, где важно знать не какие-то конструктивные особенности, вроде частичной специализации шаблонов — некоторые этим вовсе не пользуются. А важно быть внимательным и осторожным. Вот эта вот внимательность и осторожность и возводится в доблесть апологетами языка.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.11.09 23:14
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Что за роппы?

В данном случае я имел в виду Rope — структуру данных (Ropes: Theory and practice)

A rope data structure represents an immutable sequence of characters, much like a Java String. But ropes' highly efficient mutations make ropes — unlike Strings and their mutable StringBuffer and StringBuilder cousins — ideal for applications that do heavy string manipulation, especially in multithreaded environments.


VD>Что касается проблем, то ты их явно из пальца высосал.

Как сказать. StringBuilder предназначен исключительно для конструирования строк. Если возникает необходимость в редактировании больших объемов данных, то обычный String не подходит из-за эффективности, а StringBuilder крайне неудобен, так как у него отсутствует интерфейс для этого (поиск подстроки, к примеру). Как результат пишутся свои велосипеды над StringBuilder. Собственно, строки на основе ropes и были введены для устранения этого недостатка в Java.
Re[12]: За что я не люблю С++
От: metaprogrammer  
Дата: 03.11.09 08:53
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

M>> Singularity видел?


PD>Видеть не видел, но мне WolfHound о ней уже столько раз говорил, что почти что и видел. Но это вроде ОС, а не язык ?


ОС, да, но я говорю именно про язык. Подмножество C# с аннотациями, компилируемый в нейтив. Так что, разница между managed и native давно уже размыта начисто.

PD>>>3. Я перейду на этот новый язык при двух условиях 1) на него перейдет мир и 2) я доживу.


M>> Тю... Не понимаю такого подхода.


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


Не стоит предполагать, что я ничего не знаю о "реальной деятельности". Всё, что я о ней знаю, весь мой опыт, просто кричит, что С++ — это всегда ОГРОМНЫЕ ПРОБЛЕМЫ. Никто другой столько не навредил, ни Fortran, ни PL/I, ни plain C, ни прочее, в реальной деятельности употреблявшееся.

PD> Никто не призывает использовать С++ для написания сайтов, или Java — для написания драйверов. Но и С++ и Java имею области, где именно их стоит употреблять. И в той области, где С++, ему альтернативы сейчас нет.


Примерчики можно? Кроме использования существующих C++ API. Я таких областей не знаю, при том, что знаю я очень много всякого разного.

>>Ещё более не понимаю тех, кто считает возможным использование одного единственного языка.


PD>А разве я утверждал, что надо использовать именно один язык ? Вообще-то я знаю около десяти языков, одни лучше, другие хуже. Но для тех задач, которые я решаю , есть сейчас потенциально 2 языка — С++ и Паскаль.


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

Вот, например, как можно было забыть про старую добрую Аду?!?

PD> И не потому, что они хорошие, а другие хуже, а потому, что они компилируются в машинный код, а другие нет.


Как нет? С каких пор? Фортран уже не компилируется? Ада не компилируется? Common Lisp не компилируется? Да блин, даже Прологи многие, и те компилируются.
Re[15]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 06.11.09 03:23
Оценка: :)
Здравствуйте, metaprogrammer, Вы писали:

M> Искать влом. Очень интересно, что же такое убойное можно вообще ответить на аргумент (странно, что только десятки раз услышанный, а не сотни), что Ада — компилируемый и низкоуровневый язык.


Ничего. Ада — хороший язык. У него масса преимуществ и только один недостаток — его нет, кроме как в МО США.
With best regards
Pavel Dvorkin
Re[15]: За что я не люблю С++
От: Игoрь Украина  
Дата: 06.11.09 08:10
Оценка: +1
Здравствуйте, metaprogrammer, Вы писали:

M> Может, его просто маловато, или просто слишком в жизни везло? Я видел разные проекты, в диапазоне от плохих до кошмарных. Многие были весьма древними, и в таких обычно употреблялось сразу много языков. Самой проблемной частью было всегда то, что написано на C++.

Опыта более чем достаточно.

И>> Кстати, можно расшифровать — какой такой вред нанес С++?

M> Самый разнообразный. Главная проблема C++-проектов в их неподдерживаемости. Главная проблема C++ как языка в практической невозможности его автоматизированного анализа. Он слишком мощный и разнообразный, это для промышленного языка недопустимо.
Во-первых, я не увидел ответа на свой вопрос. Ты утверждал о вреде, который нанес С++, я так и не понял в чем был вред? И пожалуй не соглашусь по анализу, прогресс не стоит на месте, современные средства разработки сделали приличный шаг вперед. Неподдерживаемость проекта — это скорее баг в организации процесса разработки, точнее в его отсутствии, и низкой квалификации программистов. Я и на С# видел такие проекты.

M>>> Примерчики можно? Кроме использования существующих C++ API. Я таких областей не знаю, при том, что знаю я очень много всякого разного.

И>>C++ отлично подходит для околосистемных вещей, всевозможные системные сервисы, фильтры.
M> А я так не считаю. Я думаю, что C++ абсолютно для таких вещей не подходит, есть гораздо лучшие и значительно более надежные и безопасные решения.
Ага, есть, но только не надежные и не безопасные.

M>Тем более — зачем тут C++ со всей его неуклюжей и бессистемной мощью?

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

И>> Управляемые языки здесь слишком громоздки и не достаточно предсказуемы.

M> Ничем не обоснованное утверждение. Да и неуправляемых языков предостаточно, и многие для этих целей лучше подошли бы.
А твое типа обоснованное? ха-ха.

И>> Эту нишу С++ занял с самого своего появления и никто его отсюда выбить пока не сумел.


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

Давай миллионы примеров в студию, и покажи как потом эти проблемы были элегантно решены с помощью других языков.
Re[21]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 06.11.09 08:43
Оценка: -1
Здравствуйте, metaprogrammer, Вы писали:

M> Флейм мне не интерестен. Мне просто неприятно, когда так цинично врут, что мол "нет ничего, кроме C++". Есть, до фига всякого разного. И бредовые аргументы про "а где же вакансии?" просто не котируются, именно в силу бредовости самого подхода к вопросу.


M> Вообще, занятная позиция — высказать бредовое утверждение, и отметать любые возражения как якобы "флейм". Трусливая позиция. Некрасивая.


И даже после всех этих высказываний я не намерен ни их обсуждать, ни продолжать с тобой дискуссию. Впрочем. судя по этому сообщению, с тобой дискуссию вообще не стоит вести.
With best regards
Pavel Dvorkin
Re[15]: За что я не люблю С++
От: CreatorCray  
Дата: 09.11.09 12:24
Оценка: +1
Здравствуйте, metaprogrammer, Вы писали:

M>Он слишком мощный и разнообразный, это для промышленного языка недопустимо.

Вот уж как раз избыток возможностей прекрасно решаем административными методами.

И>>C++ отлично подходит для околосистемных вещей, всевозможные системные сервисы, фильтры.

M> А я так не считаю. Я думаю, что C++ абсолютно для таких вещей не подходит, есть гораздо лучшие и значительно более надежные и безопасные решения.
Например?

И>> Или, например, когда сам драйвер режима ядра пишется на С, а в пользовательском режиме обвязка с логикой пишется на С++.

M>Тем более — зачем тут C++ со всей его неуклюжей и бессистемной мощью?
Вот почему все "критиканы" всегда считают что раз С++ так это значит надо применять сразу все возможности языка в наихудшем их сочетании.
Многим вообще хватает того сабсета, что называют "Си с классами".
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[2]: За что я не люблю С++
От: dmitry_npi Россия  
Дата: 26.05.09 11:36
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Да придирается по-детски как то.

CC>В сравнении с тутошними срачами "C++ vs *" — статья детский лепет и обидки.

Это вы правы. Ну а вдруг, сторонники найдутся?
Атмосферная музыка — www.aventuel.net
Re[2]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 26.05.09 12:27
Оценка:
MX> 1) Понятие метаинформации не то, что отсутствует, но в избытке (сомневаюсь, что он читал Александреску — скорее, он его под ножку стола подкладывал)
MX> 2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько. Можем и с сами написать — вон, на кывт-е есть статья про сериализацию в хмл, ещё другая есть, про которую все знают.


И что, прямо-таки можно легко сериализовать объект любой сложности?
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[3]: За что я не люблю С++
От: -MyXa- Россия  
Дата: 26.05.09 12:49
Оценка:
Здравствуйте, Mamut, Вы писали:

MX>> 1) Понятие метаинформации не то, что отсутствует, но в избытке (сомневаюсь, что он читал Александреску — скорее, он его под ножку стола подкладывал)

MX>> 2) "Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько. Можем и с сами написать — вон, на кывт-е есть статья про сериализацию в хмл, ещё другая есть, про которую все знают.

M>И что, прямо-таки можно легко сериализовать объект любой сложности?


Например?
Если не поможет, будем действовать током... 600 Вольт (C)
Re[4]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 26.05.09 13:17
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ> M>И что, прямо-таки можно легко сериализовать объект любой сложности?


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


Ну, мы же говорим о ""Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько"
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[3]: За что я не люблю С++
От: LaptevVV Россия  
Дата: 26.05.09 13:19
Оценка:
Здравствуйте, 0x7be, Вы писали:

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


LVV>>Кстати, хорошая статья...

0>Слишком эмоциональная.
Дык, видимо достало чела...
Вроде это тот Боресков, который книжки по графике в ДиалогМИФИ печатает. Чел вполне квалифицированный...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 13:28
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

С мира по нитке..
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 13:29
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Ну, мы же говорим о ""Много ли Вы знаете простых и удобных persistence-библиотек". Ды, уж знаем, несколько"


А... А я думал, что о "сериализации объектов любой сложности".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: За что я не люблю С++
От: -MyXa- Россия  
Дата: 26.05.09 13:37
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Объект с циклическими ссылками и членами — указателями на другие объекты.


libs\serialization\test\test_cyclic_ptrs.cpp

M>Плюс является наследником другого объекта так, чтобы не надо было явно указывать:

M>
M>ar & boost::serialization::base_object<bus_stop>(*this) & name;
M>


Думаю, что от этого можно избавиться. Библиотека знает обо всех типах — могла бы сложить их в список типов, а при сериализации — найти все базы данного типа. Не думаю, что бывают случаи, когда (де)сериализовать наследника надо, на базу — нет. Хотя, с другой стороны, базЫ можно ситать такими же полямИ, и библиотека сама никак не может догадаться — сериализовать ли базу, или нет (если данная база не сериализуется, то понятно, что не надо, а если сериализуется?)

M>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?
Если не поможет, будем действовать током... 600 Вольт (C)
Re[3]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 13:59
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, -MyXa-, Вы писали:


C>В статье почти все правда. Просто преподнесена она так, чтоб сильно задеть программистов С++ и местами немного искажена.


Угу, искажена вплоть до своей противоположности.

C>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.


свойства — синтезируется;
атрибуты (в смысле сопоставляемых метаданных) — синтезируется;
события — синтезируется;
делегаты — синтезируется;
лямбда-выражения — есть в C++0x;
замыкания — есть в C++0x;
duck typing — статический (и это очень хорошо);
интерфейсы — полностью выражается средствами pure virtual;
covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?

MX>>13) "средств получить информацию о типе-параметре в языке просто нет" . Язык С++ на столько крут, что "в языке" это и не нужно — можно написать библиотеку. boost::is_abstract, is_arithmetic, is_array, is_base_and_derived, is_base_of, is_class, is_complex, is_compound, is_const...

C>О, ужас.

А что не так?

MX>>После слов "Это конечно здорово, но вот как узнать является ли этот тип каким-либо из элементарных типов, указателем или ссылкой ? Является ли он const или нет ?" этого профана сил осиливать его поток у меня не осталось.

C>Он правду сказал, а Вы классически "съехали на оскорбления", не могучи аргументированно ответить.

Глупость он сказал. Элементарных типов очень мало, указатели и ссылочные типы определяются на раз. И таких натяжек полна статья.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.05.09 14:04
Оценка:
Здравствуйте, March_rabbit, Вы писали:

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


M>>Объект с циклическими ссылками и членами — указателями на другие объекты. Плюс является наследником другого объекта так, чтобы не надо было явно указывать:

M>>
M>>ar & boost::serialization::base_object<bus_stop>(*this) & name;
M>>


M>>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

M_>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?
M_>здорово, если так.

Ты удиишься.
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 14:30
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Угу, искажена вплоть до своей противоположности.

C>Нет.

Да ну? А как же RTTI, за который автору почему-то всегда приходится платить? Определение типов данных — из той же оперы.

C>>>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.

ГВ>>свойства — синтезируется;
C>Нет.

Поиск тебе в помощь.

ГВ>>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;

C>Нет.

Как так? Неужто нельзя приклеить к объекту никаких данных? Ни указателем, ни базовым классом?

ГВ>>события — синтезируется;

C>Нет.
ГВ>>делегаты — синтезируется;
C>Нет.

Этому топику
Автор: Геннадий Васильев
Дата: 28.08.02
больше шести лет.

ГВ>>лямбда-выражения — есть в C++0x;

C>Не есть, а будет. В данном топике речь вроде как не о C++0x вовсе.
ГВ>>замыкания — есть в C++0x;
C>Не есть, а будет. В данном топике речь вроде как не о C++0x вовсе.

Уже есть. Что там когда было — не суть.

ГВ>>duck typing — статический (и это очень хорошо);

C>Может Вы для начала узнаете для себя что такое утятина?

Раньше предлагали устрицы. Снижается классность, снижается.

ГВ>>интерфейсы — полностью выражается средствами pure virtual;

C>Костыль.

Понятно. "Толстенькая — скоро лопнет с жиру." (c)

ГВ>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?

C>Нигде их нет.

А в документации есть. Дока врёт?

C>>>О, ужас.

ГВ>>А что не так?
C>А Вы сами не видете?

А по сути?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: За что я не люблю С++
От: March_rabbit  
Дата: 26.05.09 14:36
Оценка:
Здравствуйте, gandjustas, Вы писали:

M>>>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

M_>>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?
M_>>здорово, если так.

G>Ты удиишься.

и где?
Re[7]: За что я не люблю С++
От: March_rabbit  
Дата: 26.05.09 14:37
Оценка:
Здравствуйте, criosray, Вы писали:

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


M>>>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

M_>>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?
M_>>здорово, если так.

C>Конечно есть. Только этим не язык занимается.

ТОгда вопрос: при чем тут С++?
Re[6]: За что я не люблю С++
От: LaptevVV Россия  
Дата: 26.05.09 15:08
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

LVV>>Это говорит только о том, что в языке их не хватает.

ГВ>Ну вот, теперь твоя очередь. ИМХО, если фича синтезируется, то и рассуждать не о чем.
Не... Есть... Синтезируется — это не стандарт определения языка, а реализация конкретного разработчика интегрированной среды...
При переходе со среды на среду — придется разбираться, как там эти фичи синтезированы.
ГВ>>>лямбда-выражения — есть в C++0x;
ГВ>>>замыкания — есть в C++0x;
LVV>>Ага... Не прошло и 0х лет, как...
ГВ>Ну, тем не менее.
Ну так еще и нет жиж...
ГВ>>>duck typing — статический (и это очень хорошо);
LVV>>Ну, нормально... Но не так строго, как в Виртовских языках...
ГВ>Так и способ использования другой, AFAIK.
Ну, в этом вопросе более-менее нормально.
ГВ>>>интерфейсы — полностью выражается средствами pure virtual;
LVV>>Нормально. Но почему-то в других языках сочли необходимым такую конструкцию явно определить
ГВ>Видимо, из-за отсутствия множественного наследования.
Видимо, множественное наследование ликвидировали из-за наличия озвученных проблем. И сочли за благо ввести отдельную конструкцию.
ГВ>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
LVV>>А ковариантные — это какие?
ГВ>
ГВ>class A {
ГВ>  public:
ГВ>    virtual A *f(){ ... }
ГВ>};
ГВ>class B : public A {
ГВ>  public:
ГВ>    virtual B *f(){ ... }
ГВ>};
ГВ>

А, ну да... Видимо противники имеют ввиду, что полноценный объект ковариантно возвратить нельзя.

ГВ>>>А что не так?

LVV>>Дык ПИСАТЬ НАДО... А в других языках писать НЕ НАДО...
LVV>>А челу требуется задачу решать, а не писать библиотеку...
ГВ>Дык — не надо ж. Он там в качестве контраргумента всё время рассуждает о непонятности внутреннего устройства буста.
Для него — действительно жуть... Меня тоже только крайняя нужда заставит буст использовать...
Но вообще статья, конечно, оставляет впечатление, что писал достаточно опытный программер, которому ПРИШЛОСЬ перейти на С++ по необходимости.
А это — действительно УЖОСССССС!!!!!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[7]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 15:22
Оценка:
Здравствуйте, criosray, Вы писали:

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

C>Ну и где тут противоположность?

Дык, отключается же RTTI даже в одиозном MSVC6. Определить типы данных — опять таки можно.

ГВ>>Поиск тебе в помощь.

C>Открываем стандарт С++, смотрим, не находим, извиняемся?

Нет, в смысле — в гугль. Слова C++ и property.

ГВ>>>>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;

C>>>Нет.
ГВ>>Как так? Неужто нельзя приклеить к объекту никаких данных? Ни указателем, ни базовым классом?
C>Это не атрибуты. Почитайте чтоли что такое атрибуты.

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

ГВ>>Этому топику
Автор: Геннадий Васильев
Дата: 28.08.02
больше шести лет.

C>Это костыли, пытающиеся их эмулировать. В языке их НЕТ.

О-о-о... Это повод для большого флейма — какими должны быть делегаты.

C>Не уже есть, а будет тогда, когда будет выпущен релиз компилятора языка С++0x.

C>И повторяю С++0x != C++, о котором речь.

Я тебе скажу больше MSVC6 != MSVC2K5, MSVC2K5 != MSVC2K10 и т.п. Что теперь, ругаться на C++, оперируя глюками MSVC6? И кроме того, внимательно смотрим на дату сообщения.

ГВ>>>>duck typing — статический (и это очень хорошо);

C>>>Может Вы для начала узнаете для себя что такое утятина?
ГВ>>Раньше предлагали устрицы. Снижается классность, снижается.
C>Ликбез: утятина не может быть статической. По определению. Не пишите больше таких глупостей, ок?

Что-то ничего не понимаю
Автор: VladD2
Дата: 25.05.09
.

ГВ>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?

C>>>Нигде их нет.
ГВ>>А в документации есть. Дока врёт?
C>Ссылку на соответствующий раздел документации в студию.

ISO/ANSI 14882:1998, Раздел 10.3.5.

ГВ>>А по сути?

C>А по сути — О, ужас. Других слов нет.

Понятно. Нет, так нет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 15:25
Оценка:
Здравствуйте, esil, Вы писали:

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


E>

ГВ>>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
C>>>>Нигде их нет.
ГВ>>>А в документации есть. Дока врёт?
C>>Ссылку на соответствующий раздел документации в студию.


E>ISO/IEC 14882, пункт 10.3.5


Нету contravariance. Нету.


The return type of an overriding function shall be either identical to the return type of the overridden func-
tion or covariant
with the classes of the functions.

Re[6]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 26.05.09 15:34
Оценка:
MX> M>Объект с циклическими ссылками и членами — указателями на другие объекты.

MX> libs\serialization\test\test_cyclic_ptrs.cpp


MX> M>Плюс является наследником другого объекта так, чтобы не надо было явно указывать:

MX> M>
MX> M>ar & boost::serialization::base_object<bus_stop>(*this) & name;
MX> M>


MX> Думаю, что от этого можно избавиться.


Можно быо бы, в boost:serialize избавились бы

MX> Библиотека знает обо всех типах — могла бы сложить их в список типов, а при сериализации — найти все базы данного типа. Не думаю, что бывают случаи, когда (де)сериализовать наследника надо, на базу — нет. Хотя, с другой стороны, базЫ можно ситать такими же полямИ, и библиотека сама никак не может догадаться — сериализовать ли базу, или нет (если данная база не сериализуется, то понятно, что не надо, а если сериализуется?)


Все она может догадаться. Не в С++, естественно
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[9]: За что я не люблю С++
От: esil  
Дата: 26.05.09 15:36
Оценка:
Здравствуйте, criosray, Вы писали:

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


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


E>>

ГВ>>>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?
C>>>>>Нигде их нет.
ГВ>>>>А в документации есть. Дока врёт?
C>>>Ссылку на соответствующий раздел документации в студию.


E>>ISO/IEC 14882, пункт 10.3.5


C>Нету contravariance. Нету.



C>

C>The return type of an overriding function shall be either identical to the return type of the overridden func-
C>tion or covariant
with the classes of the functions.



Это как, простите?

class A {
};

class B: public A {
};


class C {
public:
    virtual A * func();
};


class D: public C {
public:
    virtual B * func();
};


Вот это то что есть. А Вы ещё хотели бы, чтобы C::func возвращала B, а D::func возвращала A. Разве это не бред?
Re[11]: За что я не люблю С++
От: esil  
Дата: 26.05.09 16:03
Оценка:
Здравствуйте, criosray, Вы писали:

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



C>>>Нету contravariance. Нету.


C>>>

C>>>The return type of an overriding function shall be either identical to the return type of the overridden func-
C>>>tion or covariant
with the classes of the functions.



E>>Это как, простите?


C>http://hestia.typepad.com/flatlander/2008/12/c-covariance-and-contravariance-by-example.html


Ну так а слобо было сразу ответить какая именно ковариантность вам нужна, когда Вас спросили об этом?
Ковариантность возвращаемых значений виртуальных функций имеется.
Re[9]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 16:44
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>>>Поиск тебе в помощь.

C>>>Открываем стандарт С++, смотрим, не находим, извиняемся?
ГВ>>Нет, в смысле — в гугль. Слова C++ и property.
C>Еще раз для тех, кто читать не умеет: открываем стандарт С++, смотрим, не находим, извиняемся.

Я потому тебя в гугль и отправил, чтоб ты почитал дискуссии по поводу пропертей для C++. Очень неоднозначно всё получается. Это с одной стороны. А с другой — не так уж и плоха жизнь без оных пропертей, хотя я понимаю — если в язык не затащено всё, что на сегодня считается "базовой вещью" — это плохой язык.

ГВ>>>>>>атрибуты (в смысле сопоставляемых метаданных) — синтезируется;

C>>>>>Нет.
ГВ>>>>Как так? Неужто нельзя приклеить к объекту никаких данных? Ни указателем, ни базовым классом?
C>>>Это не атрибуты. Почитайте чтоли что такое атрибуты.

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

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

В примере — использование AOP и неявно должен быть задействован Emit и ещё куча всего. Самих атрибутов там — только сопоставление AOP-вызовов. Ты хочешь, чтобы я AOP-фреймворк слабал по-быстрому?

Что касается C++, то простая привязка данных к классу настолько тривиальна, что я не знаю даже, какой тут тебе пример попроще привести. Например, наследование от общей базы.

ГВ>>>>Этому топику
Автор: Геннадий Васильев
Дата: 28.08.02
больше шести лет.

C>>>Это костыли, пытающиеся их эмулировать. В языке их НЕТ.
ГВ>>О-о-о... Это повод для большого флейма — какими должны быть делегаты.
C>Какого флейма? Они либо есть, либо их нет. В С++ их нет. О чем тут флеймить? Аналогично linq, lambda, events, attributes, properties, implicit typing, duck typing и многое другое.

Что-то больно много базовых вещей появляется, не находишь? Уже и linq в качестве базовых замаячил. Интересно, что дальше будет? Ладно, не суть. Суть в том, что делегаты прекрасно заменяются лямбдами, а евенты — лямбда + vector.

C>>>Не уже есть, а будет тогда, когда будет выпущен релиз компилятора языка С++0x.

C>>>И повторяю С++0x != C++, о котором речь.
ГВ>>Я тебе скажу больше MSVC6 != MSVC2K5, MSVC2K5 != MSVC2K10 и т.п. Что теперь, ругаться на C++, оперируя глюками MSVC6? И кроме того, внимательно смотрим на дату сообщения.
C>Замечательно. "Все смешалось в доме Облонских". Вы разницу между языком программирования и средой разработки не видите совсем?

Ах, ну да, я ж совсем забыл, что это для C++-ников MSVC6 — нарицательное. На самом деле, это очень неплохая среда с очень поганым C++, реализованным тогдашним компилятором MS C++. кстати, именно этим компилятором спровоцировано высказывание автора статьи о 255 символах в идентификаторе.

ГВ>>>>>>duck typing — статический (и это очень хорошо);

C>>>>>Может Вы для начала узнаете для себя что такое утятина?
ГВ>>>>Раньше предлагали устрицы. Снижается классность, снижается.
C>>>Ликбез: утятина не может быть статической. По определению. Не пишите больше таких глупостей, ок?
ГВ>>Что-то ничего не понимаю
Автор: VladD2
Дата: 25.05.09
.

C>Да я заметил, что Вы ничего не понимаете. Даже не пытаетесь. Пишете всякую, извините, билеберду. Хотя б в вики заглянули, чтоб хоть какое-то представление иметь...

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

ГВ>>>>>>covariance/contravariance — где именно их нет (ковариантные возвращаемые значения есть)?

C>>>>>Нигде их нет.
ГВ>>>>А в документации есть. Дока врёт?
C>>>Ссылку на соответствующий раздел документации в студию.
ГВ>>ISO/ANSI 14882:1998, Раздел 10.3.5.
C>Нету там contravariance.

Contravariance — нет. Надо же, какой чудовищный недостаток!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 16:53
Оценка:
Здравствуйте, criosray, Вы писали:

MX>>Вы считает это _базовыми_ понятиями? Очень интересно. А Вы знаете, что даже цикл — не базовое понятие?

C>Базовое.

Феерично!!!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 16:59
Оценка:
Здравствуйте, criosray, Вы писали:

MX>>свойств в языке нет, но это не значит, что нельзя написать window.visible = true, чтобы лучше разглядеть окно.

C>Замечательно. Только после window.visible = true Вам придется написать еще window.refresh()
C>А как на счет проверки корректности ввода? А read-only свойства?
C>В итоге придете getVisible(), setVisible().

Ты, оказывается, действительно не в курсе. Я не даром тебя в гугль отправил. Точно такой же синтаксис можно получить на C++: с неявным вызовом setVisible() в ответ на window.visible = true, с вызовом getVisible() в ответ на bool v = window.visible, и с read-only (то есть — const) в комплекте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 17:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

MX>>>свойств в языке нет, но это не значит, что нельзя написать window.visible = true, чтобы лучше разглядеть окно.

C>>Замечательно. Только после window.visible = true Вам придется написать еще window.refresh()
C>>А как на счет проверки корректности ввода? А read-only свойства?
C>>В итоге придете getVisible(), setVisible().

ГВ>Ты, оказывается, действительно не в курсе. Я не даром тебя в гугль отправил. Точно такой же синтаксис можно получить на C++: с неявным вызовом setVisible() в ответ на window.visible = true, с вызовом getVisible() в ответ на bool v = window.visible, и с read-only (то есть — const) в комплекте.


Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.
Re[7]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 26.05.09 17:27
Оценка:
Здравствуйте, criosray, Вы писали:

C>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.


Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: За что я не люблю С++
От: Antikrot  
Дата: 26.05.09 19:18
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.

A>>вот тут осторожней ведь в ответ могут поставить условие чтобы твой код на C# c linq компилировался хотя бы тремя современными С# компиляторами хотя бы на трех архитектурно разных платформах
C>LINQ — стандартная языковая фича. В отличие от microsoft specific properties.

не-не. я не про это. никто не предлагал использовать microsoft specific properties, предложили "ужасный костыль".
ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?

C>>>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк

A>>а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?

C>В чем разница между стандартным решением и ужасным костылем?


<костыль скиппед>

C>
C>public class Test
C>{
C>   public int Number_A { get; set; }
C>   public int Number_B { private get; set; }
C>   public int Number_C { get; private set; }
C>}
C>


C>Действительно... в чем разница...

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

A>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

C>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.
я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.
Re[13]: За что я не люблю С++
От: Хвост  
Дата: 26.05.09 19:24
Оценка:
Здравствуйте, criosray, Вы писали:

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

class Foo
{
public:
  void bar(int bar) { m_bar = bar; }
  int bar() const { return m_bar; }
private:
  int m_bar;
};

//...
Foo f;
f.bar(10);
int bar = f.bar();
//...


?
вот реально, в чём цимес пропертей? не, ну я вижу ужасающий синтаксический оверхед в вслучае геттера в виде двух скобок, и в случае сеттера тоже, да (правда '=' писать не надо), однако всё ещё не считаю ето поводом для внесения пропертей в фичу языка, а ты как считаешь?
People write code, programming languages don't.
Re[12]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:25
Оценка:
Здравствуйте, Antikrot, Вы писали:

C>>>>>>Замечательно. Пример на С++ со свойствами в студию. Естественное условие — код должен компиллироваться во всех современных С++ компиляторах.

A>>>вот тут осторожней ведь в ответ могут поставить условие чтобы твой код на C# c linq компилировался хотя бы тремя современными С# компиляторами хотя бы на трех архитектурно разных платформах
C>>LINQ — стандартная языковая фича. В отличие от microsoft specific properties.

A>не-не. я не про это. никто не предлагал использовать microsoft specific properties, предложили "ужасный костыль".

A>ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?

Сколько? Он всего один.

C>>>>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк

A>>>а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?

C>>В чем разница между стандартным решением и ужасным костылем?


A><костыль скиппед>


C>>
C>>public class Test
C>>{
C>>   public int Number_A { get; set; }
C>>   public int Number_B { private get; set; }
C>>   public int Number_C { get; private set; }
C>>}
C>>


C>>Действительно... в чем разница...

A>это простейшее использование. если туда напихать кода, он тоже будет вполне пухлым.
Если туда еще и кода напихать, то это будет тихий ужас.

A>к тому же непрозрачным — автор того что написано по ссылке в первом сообщении вроде жаловался что компилятор генерит что-то еще. уж лучше прямо написать get_Number_A, что в C#, что в C++

В С++ лучше за не имением стандартного/нормального/вменяемого способа решения. В С# ну уж никак не лучше.

A>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

C>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.
A>я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.
Вы это у Майкрософт спрашивайте, а не у меня.
Re[15]: За что я не люблю С++
От: Хвост  
Дата: 26.05.09 19:37
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Хвост, Вы писали:


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


C>1. Читабельность кода.

а что не читабельно в моём примере? возникли какие-то затруднения?

C>2. Compile time проверка корректности типов и именования.

C>
C>void setBAr(int a);
C>long getBaR();
C>


C>vs


C>
C>public int Bar { get; set; }
C>


гхм, с чем с чем, а вот с такими проблемами в отношении пропертей не сталкивался даже в с++, вот те крест: +
People write code, programming languages don't.
Re[14]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>>>Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.


C>>Вы бьете рекорды по фанатичной чуши... Вы сами хоть верите в то, что пишете?


ГВ>Я это знаю. Это ярые (подчёркиваю — ярые) противники C++ обычно верят в какие-то невероятные мифы. Я уж не знаю, почему так складывается, но как только кто-то выступает с резкой критикой C++, так такую пургу нести начинает — уши вянут.


Такой, как эта?

Ясное дело, в чём разница. В первом случае "свойство" — это независимый тип, который можно переопределить, обобщённо реализовать, перенести из класса в класс, и вообще накрутить уйму всего, оставив единый синтаксис собственно объявления и использования. А во втором нужно каждый раз бегать и ручками привязывать свойства к типу ("set; get;" как символ настоящего джедая). В остальном — никакой разницы.


Вот уж вянут, так вянут...

C>>>>Еще будет интересно посмотреть на сериализацию/десериализацию объекта Test С++.

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

ГВ>Любая. В твоем мире — если сериализация не встроена в платформу, то её нет, я уже понял. В моём — если какой-то фишки нет, то это означает, что она может быть любой.


Я еще раз прошу показать универсальный С++ сериализатор XML или Json для любого графа объектов. Двунаправленный. Дженерик (шаблонный).

Покажете или будете продолжать разводить демагогию и фанатичную чушь без единого факта по теме?

A>>>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

C>>>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.

ГВ>>>Угу, "set; get;" как символ истинной лаконичности.


C>>Куда лаконичнее?


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


Каких еще умолчаний? Расшифруйте полет мысли.

PS: Правильно тут кто-то недавно заметил, что те, кто хаят С# знают его на уровне чайника...
Re[16]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:41
Оценка:
Здравствуйте, Хвост, Вы писали:


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


C>>1. Читабельность кода.

Х>а что не читабельно в моём примере? возникли какие-то затруднения?
Возникнут. Когда у Вас будут тысячи бизнес-классов с нетривиальной логикой.

C>>2. Compile time проверка корректности типов и именования.

C>>
C>>void setBAr(int a);
C>>long getBaR();
C>>


C>>vs


C>>
C>>public int Bar { get; set; }
C>>


Х>гхм, с чем с чем, а вот с такими проблемами в отношении пропертей не сталкивался даже в с++, вот те крест: +

Ну да, ну да.
Re[16]: За что я не люблю С++
От: Хвост  
Дата: 26.05.09 19:43
Оценка:
Здравствуйте, MxKazan, Вы писали:

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


C>>Здравствуйте, Хвост, Вы писали:


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


C>>1. Читабельность кода.

C>>2. Compile time проверка корректности типов и именования.
MK>3. Атрибуты
MK>4. Обзёрвер INotifyPropertyChanged

MK>наверно еще чего-то наберется, сразу и не вспомнишь...

ето уже получше, хотя опять же что то что другое можно семулировать и на с++
People write code, programming languages don't.
Re[16]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:43
Оценка:
Здравствуйте, MxKazan, Вы писали:

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


C>>1. Читабельность кода.

C>>2. Compile time проверка корректности типов и именования.
MK>3. Атрибуты
MK>4. Обзёрвер INotifyPropertyChanged

MK>наверно еще чего-то наберется, сразу и не вспомнишь...


Еще, например, переопределение в классе-наследнике.
Re[17]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 19:45
Оценка:
Здравствуйте, Хвост, Вы писали:

MK>>наверно еще чего-то наберется, сразу и не вспомнишь...

Х>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
Сэмулировать можно много чего. Только это все-равно будет убогим/неудобным/ущербным костылем...
Re[17]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 26.05.09 19:53
Оценка:
Здравствуйте, Хвост, Вы писали:

C>>>1. Читабельность кода.

C>>>2. Compile time проверка корректности типов и именования.
MK>>3. Атрибуты
MK>>4. Обзёрвер INotifyPropertyChanged

MK>>наверно еще чего-то наберется, сразу и не вспомнишь...

Х>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.
Re[13]: За что я не люблю С++
От: Antikrot  
Дата: 26.05.09 19:55
Оценка:
Здравствуйте, criosray, Вы писали:

A>>ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?

C>Сколько? Он всего один.
Как линия Партии. И чего все такие тупые, что не делают реализаций C#?

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

C>Если туда еще и кода напихать, то это будет тихий ужас.
с ростом объема кода отношение V(C++)/V(C#) будет стремиться к 1. и код там будет осмысленный, а не костыльная обвязка, как в C++, и не синтаксический сахар, как в C#. но если писать код ради красоты кода, то конечно на это пофиг.

A>>>>насколько принципиально тащить в язык всё то, что можно вынести в библиотеку?

C>>>Если Вы не заботитесь о чистоте, читабельности, лаконичносте кода, то действительно незачем.
A>>я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.
C>Вы это у Майкрософт спрашивайте, а не у меня.
очень мне надо. я вообще под линукс пишу.
мне интересен предел разбухания языка (неважно какого), при котором *пользователи* (то есть программисты в данном случае) будут считать язык неизбыточным.
Re[14]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 20:04
Оценка:
Здравствуйте, Antikrot, Вы писали:

A>>>ты сказал про компиляторы, то есть фактически про реализацию стандарта. костыль, насколько мне известно, скомпилируется. а вот сколько компиляторов C# (если конечно о них пристойно говорить во множественном числе) реализуют все фичи последнего официального стандарта C# ?

C>>Сколько? Он всего один.
A>Как линия Партии. И чего все такие тупые, что не делают реализаций C#?
Зачем? Гораздо лучше, если голова всему одна, а не "комитет — существо с шестью ногами", как цитировал кого-то Влад не столь давно.

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

C>>Если туда еще и кода напихать, то это будет тихий ужас.
A>с ростом объема кода отношение V(C++)/V(C#) будет стремиться к 1.
Соотношение никогда не будет стремиться к 1. Кроме свойств в С++ еще оооооочень много другого раздувающего непомерно код, делающего его нечитабельным.

A>и код там будет осмысленный, а не костыльная обвязка, как в C++, и не синтаксический сахар, как в C#. но если писать код ради красоты кода, то конечно на это пофиг.

Да уж лучше синтаксический сахар, чем синтаксическая, извините, куча (не будем уточнять чего — сами дофантазируете, коли есть желание), которую мы наблюдаем на примере С++.


A>>>я тогда боюсь предположить, что туда еще затолкают. кстати, а Parallel.For, почему он не в языке? ведь лаконичнее же написать "parallel for(......)", чем цеплять библиотеку и т.д.

C>>Вы это у Майкрософт спрашивайте, а не у меня.
A>очень мне надо. я вообще под линукс пишу.
A>мне интересен предел разбухания языка (неважно какого), при котором *пользователи* (то есть программисты в данном случае) будут считать язык неизбыточным.
Спрашивайте у Хайлсберга. Ему лучше знать.
Re[18]: За что я не люблю С++
От: Хвост  
Дата: 26.05.09 20:17
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Здравствуйте, Хвост, Вы писали:


C>>>>1. Читабельность кода.

C>>>>2. Compile time проверка корректности типов и именования.
MK>>>3. Атрибуты
MK>>>4. Обзёрвер INotifyPropertyChanged

MK>>>наверно еще чего-то наберется, сразу и не вспомнишь...

Х>>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
MK>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.
а мне интересно как вяжется ето с compile-time проверкой.
People write code, programming languages don't.
Re[19]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 26.05.09 20:43
Оценка:
Здравствуйте, Хвост, Вы писали:

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


MK>>Здравствуйте, Хвост, Вы писали:


C>>>>>1. Читабельность кода.

C>>>>>2. Compile time проверка корректности типов и именования.
MK>>>>3. Атрибуты
MK>>>>4. Обзёрвер INotifyPropertyChanged

MK>>>>наверно еще чего-то наберется, сразу и не вспомнишь...

Х>>>ето уже получше, хотя опять же что то что другое можно семулировать и на с++
MK>>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.
Х>а мне интересно как вяжется ето с compile-time проверкой.
Ну, оставим compile-time, я даже не обратил на это внимание, т.к. за последнее время привык, что под корректностью именования подразумевают именно ту процедуру, которую описал. Так как оно на С++?
Re[19]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.05.09 20:55
Оценка:
Здравствуйте, criosray, Вы писали:

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



MK>>Интересно как на С++, например, реализовать второй пункт для четвертого. Идея проста: перед генерацией события INotifyPropertyChanged.PropertyChanged при помощи Рефлексии проверяется, что свойство с заданным именем действительно есть в классе. Тем самым при отладке мы защищаемся от кривого указания имени в аргументах события.


C>Кстати, единственное чего не хватает в С# — макроподстановки имени свойства:


C>
C>public int Height
C>{
C>   get { return _height; }
C>   set {
C>      _height = value;
C>      OnPropertyChanged("Height");
C>   }
C>}
C>


C>Есть конечно вариант решения с лямбдой и рефлексией: OnPropertyChanged(o => o.Height);

C>Но очевидный перформанс хит в данном случае делает такое решение часто недопустимым...

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


Особенно в Nemerle
Re[20]: За что я не люблю С++
От: criosray  
Дата: 26.05.09 21:01
Оценка:
Здравствуйте, gandjustas, Вы писали:


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


G>Особенно в Nemerle


Совсем забыл — еще один вариант это PostSharp.
Re[20]: За что я не люблю С++
От: Хвост  
Дата: 26.05.09 21:08
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Ну, оставим compile-time, я даже не обратил на это внимание, т.к. за последнее время привык, что под корректностью именования подразумевают именно ту процедуру, которую описал. Так как оно на С++?

Очевидно руками, т.е. проперти будут выглядеть как некий шаблонный класс вида property<T>, который будет хранить всю необходимую для рантайма-проверок информацию
People write code, programming languages don't.
Re[2]: За что я не люблю С++
От: doarn Россия  
Дата: 26.05.09 21:28
Оценка:
Здравствуйте, doarn, Вы писали:

D>1. Да, чистая правда — можно при желании. Любая серьезная разработка в итоге ведется не на С++, а на некотором подможножестве языка и надмножестве библиотек, подкрепленном внутренними стандартами. Так что говорить о

Так что говорить следует о совсем-совсем разных примерах использования. И при должной аккуратности в построении окружения — количество способов отстрелить ногу сокращается до вполне приемлимого.
Re[5]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 26.05.09 21:34
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Сериализация почти всегда нужна в контексте решения задач наподобие построения протокола обмена данными


НС>Это называется взгляд через замочную скважину.


Раскрыть можешь?

У нас в старом проекте (игровой движок) через сериализацию решалось:
— сохранение/восстановление в хмл/нативный формат
— клонирование графа
— конвертация графа в нативный формат
Нужно разобрать угил.
Re[6]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 26.05.09 22:47
Оценка:
Здравствуйте, NikeByNike, Вы писали:

НС>>Это называется взгляд через замочную скважину.


NBN>Раскрыть можешь?


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

NBN>- сохранение/восстановление в хмл/нативный формат

NBN>- клонирование графа
NBN>- конвертация графа в нативный формат

Это все "построение протокола обмена данными"?
Re[4]: За что я не люблю С++
От: drol  
Дата: 26.05.09 22:55
Оценка:
Здравствуйте, doarn, Вы писали:

C>>Да и что такого жуткого в операторе using?

D>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.

А можно парочку примеров непримитивных случаев ?

C>>Вы можете предложить лучшее решение?

D>Последовательное применение концепции владения и времени жизни + инструментальные средства реализации. Второе зависит от языка/платформы, первое — дело сугубо дизайна и дает одинаковый результат будучи реализованных хоть на С++, хоть на Java, хоть другими средствами.

Ой, как много умных слов... Давайте Вы всё-таки лучше код покажете, особенно интересует участок, коий "зависит от языка/платформы". И мы сравним с "примитивизмом using'а".
Re[5]: За что я не люблю С++
От: doarn Россия  
Дата: 27.05.09 00:18
Оценка:
Здравствуйте, drol, Вы писали:

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


C>>>Да и что такого жуткого в операторе using?

D>>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.
D>А можно парочку примеров непримитивных случаев ?
Когда ресурс (скажем read лок объекта) сохраняется в процессах неизвестного в точке вызова количества с непрогнозируемым временем жизни.

А если время жизни самого ресурса ограниченно?

А если ресурс нужно версионировать? =)

D>Ой, как много умных слов... Давайте Вы всё-таки лучше код покажете, особенно интересует участок, коий "зависит от языка/платформы". И мы сравним с "примитивизмом using'а".

Не хочу
А слова только выглядят умными, реально все сводиться к простейшему принципу — "выстраивай иерархию владения и не передавай владение ресурсом, которым владаеешь, вниз по иерархии". Универсально, практически серебрянная пуля
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 02:23
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>>Сериализация почти всегда нужна в контексте решения задач наподобие построения протокола обмена данными

НС>Это называется взгляд через замочную скважину.

Отлично. Расширь моё сознание альтернативными примерами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 04:29
Оценка:
Здравствуйте, Antikrot, Вы писали:
A>а собственно, и что с того? в чем разница между "нарисовать костыль с operator= " и определить set/get?
В чём разница?

Есть более-менее стандартные вещи, типа "известить об изменении свойства".
Вот, допустим, как-то так:
public class Test
{
  public event Action<Test> OnChanged;
    private int _a;
    public int A
    { 
      get {return _a;}
        set
        {
            if (value == a)
                return;
            _a = a;
            if (OnChanged!=null)
                OnChanged(this);
        }
    }
}

Покажи мне аналог этого кода на C++. И мы поймем разницу невооруженным мозгом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: За что я не люблю С++
От: LaptevVV Россия  
Дата: 27.05.09 04:47
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Блин, Валерий Викторыч, Intel C++ 11.0. И ещё сейчас MS выложила бету VS2010.

А, ну да... Я пока на 2008 сижу...
LVV>>Видимо, множественное наследование ликвидировали из-за наличия озвученных проблем. И сочли за благо ввести отдельную конструкцию.
ГВ>Каких проблем?
По этому поводу вспомнилось из его статьи: любая книжка по С++ описывает, как не надо делать при множественном наследовании. Я сам писал — тут он прав...
ГВ>>>Дык — не надо ж. Он там в качестве контраргумента всё время рассуждает о непонятности внутреннего устройства буста.
LVV>>Для него — действительно жуть... Меня тоже только крайняя нужда заставит буст использовать...
ГВ>ИМХО, это зря.
Ну, кое-что подсматриваю и использую. Но небольшие вещи. Типа интеллектуальных указателей.
LVV>>Но вообще статья, конечно, оставляет впечатление, что писал достаточно опытный программер, которому ПРИШЛОСЬ перейти на С++ по необходимости.
LVV>>А это — действительно УЖОСССССС!!!!!
ГВ>Не знаю, у меня ощущение, что программер-то, может быть, и опытный, но очень сильно путает субъективное и объективное.
Объективно я осенью напишу. Вот сравню БлэкБокс с С++ на одних и тех же задачах — и напишу...
А от субъективного восприятия никуда не деться.
Особенно программистам-непрофессионалам, которые используют программирование по необходимости только для решения своих задач. Им даже адекватный инструмент для решения подобрать сложно. Ведь не хочется изучать лишний инструменть, чтобы один-два раза решить задачу.
Вот раньше был фортран — на нем все и писали...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 05:15
Оценка:
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

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

фигня.. в книжках по разным языкам до сих пор встречаются главы "Как интегрироваться с C++"..
не ява, не шарп, не смалталк.. вот она — популярность
...coding for chaos...
Re[5]: За что я не люблю С++
От: CreatorCray  
Дата: 27.05.09 06:49
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>Дык ПИСАТЬ НАДО... А в других языках писать НЕ НАДО...

Дык разница тогда тока в том, что для других ЯП написали библиотеку и положили рядом.
А тут написанные библиотеки в комплект не входят.

LVV>А челу требуется задачу решать, а не писать библиотеку...

Хай возьмет готовую.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 07:03
Оценка:
Здравствуйте, doarn, Вы писали:

C>>C++ подвергался "демонизации" добрых 10 лет тому назад. Его жестко критиковали даже такие личности, как небезызвестный Линус Торвальдс.

D>10 лет назад, С++ несколько другой был, как и сознание о способах использования. + альтернативы ему в мейнстриме — не существовало в принципе, так что в 1999м наезды на С++ были разговорами в пользу бедных. Когда там Java 1.5 вышла, где-то в районе 2003-2004го? А второй шарп?
Да не был С++ другим. Точно тот же самый уродец.

D>>>PS: наш сериализатор дает 1.2 гигабайта/секунду потоковую производительность (собственно упираемся в скорость

C>>чтения/записи памяти) на данных умеренно-сложной структуры (поддерживая при этом возможность частичной десериализации
C>>Эта цифра абсолютно ни о чем не говорит. Да и сериализация-то у Вас поди бинарная?
D>Эта цифра например позволяет в терминах сериализации описывать внутренний ABI, не плодя сущностей для перевода сервиса в distributed состояние с сублинейной масшатабируемостью.
Чертовски за вас рад. Но повторюсь: цифра абсолютно ни о чем не говорит.

D>Цифра для бинарного варианта, в XML понятное дело помедленнее будет, да и используется только что бы веб-морде данные выплевывать. ORM на наших задачах использовать не только бессмысленно, но и вредно.

O/RM тут при чем?

D>>>PPS: а вот на шарпе аккуратное освобождение ресурсов приходится эмулировать жуткими костылями, дискасс

C>>Ну уж точно менее жуткими, чем С++ с зоопарками shared_ptr<> auto_ptr<> и прочих костылей.
D>Стандартизованный костыль перестает быть костылем.
Костыль, даже стандартизованный, остается костылем. Не фантазируйте.

C>>Да и что такого жуткого в операторе using?

D>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.
Да ну? Серьезно? И в каких же случаях сей оператор "не решает задачу"? Назовите парочку.

C>>Вы можете предложить лучшее решение?

D>Последовательное применение концепции владения и времени жизни + инструментальные средства реализации. Второе зависит от языка/платформы, первое — дело сугубо дизайна и дает одинаковый результат будучи реализованных хоть на С++, хоть на Java, хоть другими средствами.
Много пустых слов. Вы не ответили на поставленный вопрос: вы можете предложить лучшее решение по освобождению ресурсов (не памяти — она-то в отличие от.. освобождается автоматически) в управляемых средах?
Re[3]: За что я не люблю С++
От: CreatorCray  
Дата: 27.05.09 07:08
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

CC>>В сравнении с тутошними срачами "C++ vs *" — статья детский лепет и обидки.

НС>Да тутошние срачи тоже так себе в плане профессионализма, особенно свеженькие.
Это да.
Зато накал идиотизма и объем какашек, выливаемый друг на друга впечатляют.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[16]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 07:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Я уж не знаю, почему так складывается, но как только кто-то выступает с резкой критикой C++, так такую пургу нести начинает — уши вянут.

C>>Такой, как эта?
ГВ>[...]

ГВ>Да нет, такой как в топикстарте.

Эта — которую Вы вырезали (стыдно уже стало, да?) — дает хорошую фору тому, что в топик старте.

ГВ>>>Любая. В твоем мире — если сериализация не встроена в платформу, то её нет, я уже понял. В моём — если какой-то фишки нет, то это означает, что она может быть любой.

C>>Я еще раз прошу показать универсальный С++ сериализатор XML или Json для любого графа объектов. Двунаправленный. Дженерик (шаблонный).

ГВ>Сериализовать можно всё, что угодно, только не всякий раз это становится показателем здравого ума и трезвой памяти.


Значит показать не можете? "Слив засчитан" (уж простите мой жаргон, которому я набрался в этом форуме).

C>>Покажете или будете продолжать разводить демагогию и фанатичную чушь без единого факта по теме?


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


"Слив засчитан".
Re[6]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 07:22
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


LVV>>Дык ПИСАТЬ НАДО... А в других языках писать НЕ НАДО...

CC>Дык разница тогда тока в том, что для других ЯП написали библиотеку и положили рядом.
CC>А тут написанные библиотеки в комплект не входят.
В случае тех же свойств, не "библиотеку положили рядом", а компилятор научили работать. Всё-таки есть разница.
Re[10]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 07:42
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Какого флейма? Они либо есть, либо их нет. В С++ их нет. О чем тут флеймить? Аналогично linq, lambda, events, attributes, properties, implicit typing, duck typing и многое другое.

ГВ>Что-то больно много базовых вещей появляется, не находишь? Уже и linq в качестве базовых замаячил. Интересно, что дальше будет?

например, вывод на консоль.. в питоне(про 3ю версию не уверен) print — это оператор языка, а не функция.. базовая штука ведь
...coding for chaos...
Re[9]: За что я не люблю С++
От: CreatorCray  
Дата: 27.05.09 07:48
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Тебя гугль забанил? Первая ссылка по запросу "C++ property implementation": http://www.codeproject.com/KB/cpp/cpp_property_indexer.aspx

C>Это не свойства. Это костыль, который пытается их эмулировать. В языке С++ нету свойств. тчк
А тебе надо чтоб именно в стандарте было вбито гвоздями?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[11]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 07:55
Оценка:
Здравствуйте, neFormal, Вы писали:

C>>>Какого флейма? Они либо есть, либо их нет. В С++ их нет. О чем тут флеймить? Аналогично linq, lambda, events, attributes, properties, implicit typing, duck typing и многое другое.

ГВ>>Что-то больно много базовых вещей появляется, не находишь? Уже и linq в качестве базовых замаячил. Интересно, что дальше будет?

F>например, вывод на консоль.. в питоне(про 3ю версию не уверен) print — это оператор языка, а не функция.. базовая штука ведь


Аналогично было в Pascal. Только там это было нужно из-за примитивизма языка, не позволяющего создавать методы с переменным количеством аргументов.
Re[11]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 08:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Есть более-менее стандартные вещи, типа "известить об изменении свойства".

S>Вот, допустим, как-то так:
S>
S>public class Test
S>{
S>  public event Action<Test> OnChanged;
S>    private int _a;
S>    public int A
S>    { 
S>      get {return _a;}
S>        set
S>        {
S>            if (value == a)
S>                return;
S>            _a = a;
S>            if (OnChanged!=null)
S>                OnChanged(this);
S>        }
S>    }
S>}
S>

S>Покажи мне аналог этого кода на C++. И мы поймем разницу невооруженным мозгом.

вот, например.. объясни разницу, пожалуйста..
class Test
{
    int _a;
    boost::function<void (Test*)> OnChanged;

public:
    int A(){return _a;}

    void A(int a){_a = a; if(OnChanged != NULL) OnChanged(this);}
// или
    void operator=(int& a){_a = a; if(OnChanged != NULL)OnChanged(this);}

};

должно компиляться и нормально работать..
...coding for chaos...
Re[12]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 08:26
Оценка:
Здравствуйте, criosray, Вы писали:

F>>например, вывод на консоль.. в питоне(про 3ю версию не уверен) print — это оператор языка, а не функция.. базовая штука ведь

C>Аналогично было в Pascal. Только там это было нужно из-за примитивизма языка, не позволяющего создавать методы с переменным количеством аргументов.

ты не понял, print — это не базовая фича языка.. вот совсем ни разу..
но его внесли, посчитав это выгодным.. и что теперь, оглядываться на них и повторять то же самое?.
...coding for chaos...
Re[6]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 27.05.09 08:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Отлично. Расширь моё сознание альтернативными примерами.


А смысл? Вон рядом тебе примеров привели даже для С++.
Re[13]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 09:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

F>>должно компиляться и нормально работать..

S>Нет, не должно. Ну, то есть кроме компиляться.
S>Во-первых, то, что после "//или" делает не то что нужно.

да, оно делает не всё, что делается в шарпах, я знаю..
на этом пытаются подловить все поклонники шарпов в этом треде..
но в ограниченных условиях — работает :Р

S>Во-вторых, покажи мне, как будет выглядеть аналог Test.A+=5?


на голых плюсах нельзя же..
можно, наверное, сделать шаблон типа shared_ptr, который будет реализовывать всё это.. правда пухло получится..
...coding for chaos...
Re[12]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 09:36
Оценка:
Здравствуйте, neFormal, Вы писали:

F>вот, например.. объясни разницу, пожалуйста..

F>
F>class Test
F>{
F>    int _a;
F>    boost::function<void (Test*)> OnChanged;

F>public:
F>    int A(){return _a;}

F>    void A(int a){_a = a; if(OnChanged != NULL) OnChanged(this);}
F>// или
F>    void operator=(int& a){_a = a; if(OnChanged != NULL)OnChanged(this);}

F>};
F>

F>должно компиляться и нормально работать..

Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).
Re[13]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 09:38
Оценка:
Здравствуйте, neFormal, Вы писали:

F>>>например, вывод на консоль.. в питоне(про 3ю версию не уверен) print — это оператор языка, а не функция.. базовая штука ведь

C>>Аналогично было в Pascal. Только там это было нужно из-за примитивизма языка, не позволяющего создавать методы с переменным количеством аргументов.

F>ты не понял, print — это не базовая фича языка.. вот совсем ни разу..

F>но его внесли, посчитав это выгодным.. и что теперь, оглядываться на них и повторять то же самое?.

Я все понял. Это Вы не поняли того, что я Вам ответил.
Re[6]: За что я не люблю С++
От: Eugeny__ Украина  
Дата: 27.05.09 09:39
Оценка:
Здравствуйте, March_rabbit, Вы писали:


M>>Ведь в С++ тонны метаинформации! © Он что, не может сам узнать, что там сериализовывать из родительского класса?

M_>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?
M_>здорово, если так.

А в чем проблема? Та же java это умеет с версии 1.1, которая была выпушена много лет назад.
Вообще говоря, на java или .NET собственный сериализатор(в любой произвольный формат) пишется за час максимум.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[15]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 10:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

F>>да, оно делает не всё, что делается в шарпах, я знаю..

S>Нет, оно делает не то. Ты же оператор перегрузил не для свойства, а для класса.

ага, облажался..

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

S>Нужный шаблон был приведён выше по ветке. Ну вот только пример с его применением написать поклонники С++ стесняются.

а как насчёт чего нибудь вроде этого:
class Test
{
int a;
public:
 Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
};
// и использование будет таким:
test.a() = 123;
int b = test.a();
...coding for chaos...
Re[13]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 10:08
Оценка:
Здравствуйте, criosray, Вы писали:

C>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).


google -> boost::singnal
я использую boost::function просто по привычке..
...coding for chaos...
Re[14]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 10:11
Оценка:
Здравствуйте, neFormal, Вы писали:

C>>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).


F>google -> boost::singnal

F>я использую boost::function просто по привычке..

Посмотрите внимательно на свой код.
Re[16]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 10:12
Оценка:
Здравствуйте, neFormal, Вы писали:

F>а как насчёт чего нибудь вроде этого:

F>
F>class Test
F>{
F>int a;
F>public:
F> Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
F>};
F>// и использование будет таким:
F>test.a() = 123;
F>int b = test.a();
F>


Спрячьте и никому больше не показывайте.
Re[16]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 10:32
Оценка:
Здравствуйте, neFormal, Вы писали:

F>а как насчёт чего нибудь вроде этого:

F>
F>class Test
F>{
F>int a;
F>public:
F> Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
F>};
F>// и использование будет таким:
F>test.a() = 123;
F>int b = test.a();
F>

А ты полный пример кода приведи — посмотришь, как оно будет "удобно". А то у тебя тут ни set_func, ни get_func нету.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 11:12
Оценка:
Здравствуйте, criosray, Вы писали:

C>Эта — которую Вы вырезали (стыдно уже стало, да?) — дает хорошую фору тому, что в топик старте.


Да нет, если и стало стыдно, то только за то, что упомянул {get; set;}. Приношу извинения — {get;set;} не является признаком настоящего джедая и не архикакая лаконичность. Надо признать, это высказывание было ошибкой. Сорвался, признаю.

C>Значит показать не можете? "Слив засчитан" (уж простите мой жаргон, которому я набрался в этом форуме).


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

C>>>Покажете или будете продолжать разводить демагогию и фанатичную чушь без единого факта по теме?


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


C>"Слив засчитан".


Ну то есть, как всегда: главное — технология, а "зачем" — по ходу дела разберёмся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[15]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 11:30
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Замечательно. А теперь объясните нам как Вы будете на этот Changed навешивать обработчики (1+).

F>>google -> boost::singnal
C>Посмотрите внимательно на свой код.

да, не public, я знаю.. так просто короче..
...coding for chaos...
Re[17]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 11:32
Оценка:
Здравствуйте, Sinclair, Вы писали:

F>>а как насчёт чего нибудь вроде этого:

F>>
F>> Wrapper<int> a(){return Wrapper<int>(this, set_func, get_func);}
F>>

S>А ты полный пример кода приведи — посмотришь, как оно будет "удобно". А то у тебя тут ни set_func, ни get_func нету.

да то же самое.. get/set спрятанные внутрь метода или "мясом наружу" работают одинаково..
единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..

по сути это что то схожее с property от микрософта..
__declspec(property(get = getprop, put = putprop)) int the_prop;

http://msdn.microsoft.com/en-us/library/yhfk0thd.aspx
...coding for chaos...
Re[7]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 11:34
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

NBN>>- сохранение/восстановление в хмл/нативный формат

NBN>>- клонирование графа
NBN>>- конвертация графа в нативный формат

НС>Это все "построение протокола обмена данными"?


В некотором роде. Сериализация в данном случае работает конвертером из данного формата в множество каких-то других.
Нужно разобрать угил.
Re[18]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 11:59
Оценка:
Здравствуйте, neFormal, Вы писали:
F>да то же самое.. get/set спрятанные внутрь метода или "мясом наружу" работают одинаково..
Работают — одинаково. Выглядят — по разному.
В итоге всё и кончается
class Test
{
  BEGIN_PROPERTY_LIST(Test)
  BEGIN_PROPERTY (int, A)
    PROPERTY_GET()
        {
          return _a;
        }
        PROPERTY_SET()
        {
          _a = value;
        }
  END_PROPERTY(int, A)
  END_PROPERTY_LIST(Test)
}


F>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..

Ну так это и есть костыль — неэстетично выглядящая подробность реализации.
Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось.
F>по сути это что то схожее с property от микрософта..
Да-да, я в курсе про многообразные костыли.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 12:08
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

F>>да то же самое.. get/set спрятанные внутрь метода или "мясом наружу" работают одинаково..
S>Работают — одинаково. Выглядят — по разному.
S>В итоге всё и кончается
S>
S>class Test
S>{
S>  BEGIN_PROPERTY_LIST(Test)
S>  BEGIN_PROPERTY (int, A)
S>    PROPERTY_GET()
S>        {
S>          return _a;
S>        }
S>        PROPERTY_SET()
S>        {
S>          _a = value;
S>        }
S>  END_PROPERTY(int, A)
S>  END_PROPERTY_LIST(Test)
S>}
S>


Вот тут ты не прав. Проперти могут выглядеть и по-другому:

class Test
{
  public:
    PROPERTY(Test, int, a, get_a, set_a);
    PROPERTY(Test, int, b, get_b);
  
  protected:
    void set_a(int v){ ... }
    int get_a() const {  ... }
}


F>>единственное что — неэстетично выгдядит обёртка.. но с этим ещё можно подумать..

S>Ну так это и есть костыль — неэстетично выглядящая подробность реализации.
S>Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось.

Не преувеличивай.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 12:28
Оценка:
Здравствуйте, neFormal, Вы писали:

ГВ>>Что-то больно много базовых вещей появляется, не находишь? Уже и linq в качестве базовых замаячил. Интересно, что дальше будет?

F>например, вывод на консоль.. в питоне(про 3ю версию не уверен) print — это оператор языка, а не функция.. базовая штука ведь

Питон... WriteLn — встроенный оператор (процедура) Паскаля!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 12:50
Оценка:
Здравствуйте, COFF, Вы писали:

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


S>>Там достаточно сделать опечатку типа int& в декларации проперти типа — и упс! Будешь потом неделю бороду чесать, разбираясь что куда девалось.

F>>>по сути это что то схожее с property от микрософта..
S>>Да-да, я в курсе про многообразные костыли.

COF>По моему, свойства прекрасно заменяются get и set функциями, но если считается, что любая возможность которая есть в одном языке, но которой нет в другом языке однозначно свидетельствует о превосходстве первого над вторым, сколь ни натянутой и бесполезной эта возможность на самом деле является, то повторите на C# вот такое вот поведение.

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

COF>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?

GC.Collect
Re[20]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 13:07
Оценка:
Здравствуйте, neFormal, Вы писали:
F>-1.. "костыльность" — это вопрос не эстетики, а общепринятости..
Общепринятые костыли не становятся менее костыльными. См.напр. MFC.

F>так можно дойти до идеи, что не встроенный ORM — жуткий костыль..

В правильную сторону мыслишь. Но дело не во встроенности, а именно в эстетике. К примеру, ни в С# 3.0, ни в Java 6 ORM не встроены.
Но при этом в шарп можно встроить офигительный ORM, а в джаве один хрен будут костыли.

Впрочем, по сравнению с джавой ORM для C++ будут вообще инвалидной коляской.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 13:07
Оценка:
Здравствуйте, MxKazan, Вы писали:

COF>>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?

MK>GC.Collect

Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?
Re[22]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 13:12
Оценка:
Здравствуйте, COFF, Вы писали:

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


S>>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет.

COF>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?
На каждый чих? Это видать, что ни программа на C#, то сплошь воротилка произвольного числа векторов битмапов
Re[23]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 13:15
Оценка:
Здравствуйте, MxKazan, Вы писали:

COF>>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?

MK>На каждый чих? Это видать, что ни программа на C#, то сплошь воротилка произвольного числа векторов битмапов :)))

А почему нет? Для тебя вот важным является свойства чтоб были, а для меня — нет, зато для меня важно не думать когда GC.Collect звать и как это повлияет на всю остальную систему. Кому, как говорится, арбуз, а кому свиной хрящик :)
Re[21]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 13:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет.


А если память нужна кому-то ещё?
Нужно разобрать угил.
Re[22]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 13:18
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?

Ты знаешь, я честно говоря, не силен в вызове GC.Collect, т.к. не использую этого метода вообще. И в многопоточных приложениях в том числе.
Re[23]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 13:21
Оценка:
Здравствуйте, MxKazan, Вы писали:

S>>>Все недоступные битмапы будут освобождены. Хотя ты явно преувеличиваешь про "не могу держать в памяти произвольное время" — пока память тебе реально не потребуется, повода паниковать нет.

COF>>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?
MK>На каждый чих? Это видать, что ни программа на C#, то сплошь воротилка произвольного числа векторов битмапов

Моя последняя именно такой и являлась Мне смешно становится, когда я представляю что было бы если бы я затеял её на шарпе

P.S.
Хотя конечно с удовольствием перешёл бы на шарп — если бы была такая техническая возможность. Но жизнь сурова и ради хорошей зп приходится мучиться
Нужно разобрать угил.
Re[23]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 13:22
Оценка:
Здравствуйте, MxKazan, Вы писали:

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


COF>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?

MK>Ты знаешь, я честно говоря, не силен в вызове GC.Collect, т.к. не использую этого метода вообще. И в многопоточных приложениях в том числе.

Но ты же сам его предложил? Теперь оказывается, что ты в нем не силен, зачем предлагал? ;) Я понимаю, что можно сказать, что много программ написано (и тобой в том числе) на C# где такие проблемы не возникают, соответственно это все не актуально. Но ведь на C++ написано еще больше программ безо всяких лямбд и свойств, так ведь?
Re[22]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 13:24
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Я так и думал, что единственным решением будет вызывать сборщик мусора на каждый чих, но вообще-то часто его вызывать это нехорошо, нет?

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

COF>А каком сексе вы говорите уважаемый? секс это оба ваших решения, а в C++ все просто и прозрачно.

Я написал детали секса строчкой ниже. На С++ ничего прозрачного нету — просто есть "типа указатели" с семантикой владения. И есть все остальные указатели, которые приводят к undefined behavior в случае чего.

Эмулировать требуемое задачей поведение на C# не слишком сложно — с точки зрения пользователя коллекций всё будет выглядеть практически так же. Ну, кроме того, что вместо UB будет таки InvalidOperationException.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 13:26
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Эмулировать требуемое задачей поведение на C# не слишком сложно — с точки зрения пользователя коллекций всё будет выглядеть практически так же. Ну, кроме того, что вместо UB будет таки InvalidOperationException.


Ну так и на C++ эмулировать свойства не слишком сложно, и с точки зрения пользователей все будет выглядеть практически так же с той же степенью достоверности, так в чем вопрос?
Re[21]: За что я не люблю С++
От: neFormal Россия  
Дата: 27.05.09 13:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

F>>-1.. "костыльность" — это вопрос не эстетики, а общепринятости..
S>Общепринятые костыли не становятся менее костыльными. См.напр. MFC.

не знаю, не успел её распробовать..

F>>так можно дойти до идеи, что не встроенный ORM — жуткий костыль..

S>В правильную сторону мыслишь. Но дело не во встроенности, а именно в эстетике. К примеру, ни в С# 3.0, ни в Java 6 ORM не встроены.
S>Но при этом в шарп можно встроить офигительный ORM, а в джаве один хрен будут костыли.

а в чём принципиальное преимущество шарпа в этом плане?. какое нибудь дополнительное указание мета-информации?.
...coding for chaos...
Re[24]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 13:33
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Но ты же сам его предложил? Теперь оказывается, что ты в нем не силен, зачем предлагал?

Затем что ты просил.

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

Ты по-моему влез в спор, не удосужившись глянуть о чем он. Никто ведь не говорит, что свойства — абсолютная необходимость. Где такое написано? Я не писал по крайней мере. Хотя на мой взгляд — это очень удобная фича во многих отношениях. И то, что порой методы в С++ маскируют под свойства только доказывает это. Однако, изначально спор пошел на тему, что эмуляция свойств на С++ не является полноценной и уступает C#. Есть что возразить на это?
Re[9]: За что я не люблю С++
От: March_rabbit  
Дата: 27.05.09 13:36
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Ведь аналога метаданных, понимаемых дебаггером, не будет.

а что, дебаггер не люди пишут? И они не могут с компиляторописателями утрясти формат?
Дебажную инфу вроде как утрясли.
Re[25]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 13:41
Оценка:
Здравствуйте, MxKazan, Вы писали:

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

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

Посмотрел начало ветки:
>А некоторые языки (а именно С++) не имеют таких базовых понятий как: свойства, атрибуты, события, делегаты, лямбда-выражения, замыкания, duck typing, интерфейсы, covariance и contravariance, и много другого.

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

Первый ответ:
>свойства — синтезируется;

Выяснили, что действительно синтезируется, не совсем так как в C#, но есть. Галочку можно поставить :) Особенно, если они не абсолютная необходимость. Но изначально-то вопрос стоял о том, что свойства — это базовое понятие, только потом был умело повернут на соответствие свойств в C++ и C#.
Re[22]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 13:41
Оценка:
Здравствуйте, COFF, Вы писали:
COF>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?
Конечно. Ты не поверишь — ему поровну, сколько там потоков.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 13:44
Оценка:
Здравствуйте, Sinclair, Вы писали:

COF>>А каком сексе вы говорите уважаемый? секс это оба ваших решения, а в C++ все просто и прозрачно.

S>Я написал детали секса строчкой ниже. На С++ ничего прозрачного нету — просто есть "типа указатели" с семантикой владения. И есть все остальные указатели, которые приводят к undefined behavior в случае чего.
Не аргумент. Прочие указатели используются только в критических местах.
Нужно разобрать угил.
Re[23]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 13:44
Оценка:
Здравствуйте, Sinclair, Вы писали:

COF>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?

S>Конечно. Ты не поверишь — ему поровну, сколько там потоков.

То есть, если я в конце любой функции буду писать GC.Collect — то это будет абсолютно нормально?
Re[10]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 13:49
Оценка:
Здравствуйте, March_rabbit, Вы писали:

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


MK>>Ведь аналога метаданных, понимаемых дебаггером, не будет.

M_>а что, дебаггер не люди пишут? И они не могут с компиляторописателями утрясти формат?
M_>Дебажную инфу вроде как утрясли.
Речь идет о сторонней библиотеке эмуляции пропертей, которые не поддерживаются компилятором.
Re[24]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.05.09 13:55
Оценка:
Здравствуйте, NikeByNike, Вы писали:

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


NBN>>>А если память нужна кому-то ещё?

S>>Это то же самое. Когда память становится нужна кому-то еще, GC это замечает и начинает уборку.

NBN>Вот отсюда главные тормоза и растут.


Доказательсва будут? или очередное голословное утверждение?
Re[22]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 13:58
Оценка:
Здравствуйте, neFormal, Вы писали:

F>а в чём принципиальное преимущество шарпа в этом плане?. какое нибудь дополнительное указание мета-информации?.

Принципиальное — в лаконичности и типобезопасности. Читать про Linq. Аналоги на джаве либо многословны, либо не проверяются статически, либо и то и другое.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 14:15
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>И повернул его тот самый ответ, что синтезируются ;) И галочку поставить у меня лично рука не поднимется. Ведь синтезируют. Значит нужно, но нету :)


Я думаю, что многие люди, перейдя скажем с дельфи (где свойства есть) на C++ пытаются перетащить привычную идиому с собой. Ну и игра ума еще, естественно.
Re[22]: За что я не люблю С++
От: Eugeny__ Украина  
Дата: 27.05.09 14:15
Оценка:
Здравствуйте, COFF, Вы писали:

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


COF>>>Предположим, что у меня есть некий ресурс, пусть битмап, есть произвольное количество векторов std::vector< boost::shared_ptr<bitmap> > которые содержат пересекающиеся множества битмапов. Например, я делаю какие-то сложные вычисления над графическими примитивами. Теперь, мне нужно очистить один из векторов, я делаю v.clear(), при этом все битмапы, на которые нет ссылок в других векторах тут же должны быть тут же освобождены, так как битмапов много и я не могу их держать в памяти произвольное время. Как это сделать на C#?

MK>>GC.Collect

COF>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?


А чем это усложняет задачу?

Впрочем, звать сборщик обычно не требуется. Когда надо будет, он сам придет.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[21]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 15:09
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Угу. Вспоминатся Qt, где подобное реализовано для событий. Приходится препроцессор отдельный прогонять. А как только где-то что-то навернется, ни один дебаггер не спасет


Угу, только в данном случае под PROPERTY скрывается тривиальное упрощение синтаксиса объявления инстанцированного шаблонного типа и соответствующей переменной-члена. Никаких вывертов. Я сам противник того, чтобы прятать под макросами какую-нибудь суровую магию. Лучше уж лишние пять строк написать, если что.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 15:40
Оценка:
Здравствуйте, LaptevVV, Вы писали:

ГВ>>Блин, Валерий Викторыч, Intel C++ 11.0. И ещё сейчас MS выложила бету VS2010.

LVV>А, ну да... Я пока на 2008 сижу...

Я вообще по большей части на VS2K5. Но одно другому не мешает.

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

ГВ>>Каких проблем?
LVV>По этому поводу вспомнилось из его статьи: любая книжка по С++ описывает, как не надо делать при множественном наследовании. Я сам писал — тут он прав...

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

ГВ>>>>Дык — не надо ж. Он там в качестве контраргумента всё время рассуждает о непонятности внутреннего устройства буста.

LVV>>>Для него — действительно жуть... Меня тоже только крайняя нужда заставит буст использовать...
ГВ>>ИМХО, это зря.
LVV>Ну, кое-что подсматриваю и использую. Но небольшие вещи. Типа интеллектуальных указателей.

На самом деле, там много интересного. Мне сильно понравился boost::spirit — полезная штука для мелких парсеров. И наглядно записывается, и быстро работает. В подробности вдаваться не стал. Ну и по мелочи много всего. boost::bind, boost::function, само собой. Не пойму только, как обстоит дело с boost::channel — будет он когда-нибудь внесён в релиз, или нет.

LVV>>>Но вообще статья, конечно, оставляет впечатление, что писал достаточно опытный программер, которому ПРИШЛОСЬ перейти на С++ по необходимости.

LVV>>>А это — действительно УЖОСССССС!!!!!
ГВ>>Не знаю, у меня ощущение, что программер-то, может быть, и опытный, но очень сильно путает субъективное и объективное.
LVV>Объективно я осенью напишу. Вот сравню БлэкБокс с С++ на одних и тех же задачах — и напишу...

О-о-о! Это было бы интересно — я про одни и те же задачи.

LVV>А от субъективного восприятия никуда не деться.


Скажем так, в "плюс" автору можно поставить, что он в заголовке так и сказал: "...мне НЕ НРАВИТСЯ". Но это, по-моему, единственный "плюс". Дальше он стал изъясняться в стиле констатации имманентных проблем C++, а это уже с "не нравится" читателю довольно таки трудно увязывать.

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


Честно говоря, из статьи следует нечто прямо противоположное — к чему тогда декларации о том, что он 15 лет работает на C++?

LVV>Вот раньше был фортран — на нем все и писали...


А... Да-да. Настоящие программисты работают в NASA и пишут на Фортране. И программы настоящих программистов исполняются в режиме супервизора. Я в курсе.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 15:41
Оценка:
Здравствуйте, Eugeny__, Вы писали:

COF>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?


E__>А чем это усложняет задачу?


В том смысле, что если у нас крутятся параллельно несколько функций, то хорошо ли будет в каждой звать GC.Collect? Не приведет ли это к проблемам с производительностью, например?

E__>Впрочем, звать сборщик обычно не требуется. Когда надо будет, он сам придет. :)


Он придет, когда посчитает нужным, а не когда надо :) Кстати, раньше я помню была проблема с GC, когда сам объект маленький, но держит внешние ресурсы, то CG мог не вызваться за обозримое время. В контексте данной задачи, я ведь могу загрузить битмап как отображаемый файл, в этом случае в объекте будет лежать четыре байта. Сможет ли GC правильно понять эту ситуацию?
Re[24]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 27.05.09 15:59
Оценка:
Здравствуйте, COFF, Вы писали:

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


COF>>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?


E__>>А чем это усложняет задачу?


COF>В том смысле, что если у нас крутятся параллельно несколько функций, то хорошо ли будет в каждой звать GC.Collect? Не приведет ли это к проблемам с производительностью, например?

Можно после каждого оператора для верности вставить GC.Collect, тогда ормоза обеспечены.
На самом деле в программе можно определить место где какая-то часть тяжелой работы сделана, в этом месте можно вызвать GC.Collect. Просто так тыкать везде не стоит.

E__>>Впрочем, звать сборщик обычно не требуется. Когда надо будет, он сам придет.


COF>Он придет, когда посчитает нужным, а не когда надо

А когда надо?
COF>Кстати, раньше я помню была проблема с GC, когда сам объект маленький, но держит внешние ресурсы, то CG мог не вызваться за обозримое время. В контексте данной задачи, я ведь могу загрузить битмап как отображаемый файл, в этом случае в объекте будет лежать четыре байта. Сможет ли GC правильно понять эту ситуацию?
Не было никогда такой проблемы. Еще с первых версий можно подсказать GC сколько реально выделяется памяти.
Re[25]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 16:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Не было никогда такой проблемы. Еще с первых версий можно подсказать GC сколько реально выделяется памяти.


Может быть, насчет этого не уверен.
Re[11]: За что я не люблю С++
От: March_rabbit  
Дата: 27.05.09 16:12
Оценка:
Здравствуйте, MxKazan, Вы писали:

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


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


MK>>>Ведь аналога метаданных, понимаемых дебаггером, не будет.

M_>>а что, дебаггер не люди пишут? И они не могут с компиляторописателями утрясти формат?
M_>>Дебажную инфу вроде как утрясли.
MK>Речь идет о сторонней библиотеке эмуляции пропертей, которые не поддерживаются компилятором.
"сторонняя" не обязательно по отношению к компилятору/дебаггеру
так же, что может запретить разработчикам дебаггера (того же gcc) реализовать поддержку той же либы с пропертями?
Думаю ,эта задача вполне себе решаема
Re[24]: За что я не люблю С++
От: Eugeny__ Украина  
Дата: 27.05.09 16:12
Оценка:
Здравствуйте, COFF, Вы писали:


COF>В том смысле, что если у нас крутятся параллельно несколько функций, то хорошо ли будет в каждой звать GC.Collect? Не приведет ли это к проблемам с производительностью, например?


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

E__>>Впрочем, звать сборщик обычно не требуется. Когда надо будет, он сам придет.


COF>Он придет, когда посчитает нужным, а не когда надо Кстати, раньше я помню была проблема с GC, когда сам объект маленький, но держит внешние ресурсы, то CG мог не вызваться за обозримое время. В контексте данной задачи, я ведь могу загрузить битмап как отображаемый файл, в этом случае в объекте будет лежать четыре байта. Сможет ли GC правильно понять эту ситуацию?


Не слышал про такое, но если и было, то это просто баг реализации конкретного сборщика, а баги имеют тенденцию к исправлению в следующих версиях.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[12]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 27.05.09 16:25
Оценка:
Здравствуйте, March_rabbit, Вы писали:

MK>>>>Ведь аналога метаданных, понимаемых дебаггером, не будет.

M_>>>а что, дебаггер не люди пишут? И они не могут с компиляторописателями утрясти формат?
M_>>>Дебажную инфу вроде как утрясли.
MK>>Речь идет о сторонней библиотеке эмуляции пропертей, которые не поддерживаются компилятором.
M_>"сторонняя" не обязательно по отношению к компилятору/дебаггеру
M_>так же, что может запретить разработчикам дебаггера (того же gcc) реализовать поддержку той же либы с пропертями?
M_>Думаю ,эта задача вполне себе решаема
Конечно решаемо. Только люди то пишут "достаточно сделать либу". Так вот недостаточно. А когда пойдут договариваться с командами компилятора/дебаггера, то уже совсем другой уровень, практически фича языка
Re[29]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 16:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Например, можно ли оперировать таким явлением, как "ссылка на свойство"?

S>Можно. См. PropertyInfo

А без PropertyInfo никак? Это, в общем-то, прослойка из метаданных получается.

ГВ>>Может ли "свойство" выступать аргументом шаблона?

S>Нет. Поскольку свойство — это не тип.

Понятно.

S>В С++, впрочем, метод тоже не может быть аргументом шаблона.


Может:

template<typename T, void (T::*M)()> class Foo { ... };

class Bar { public: void bar(){ ... } }

Foo<Bar, &Bar::bar> foo;


ГВ>>Ну и так далее. Получилось как всегда — C++ плох тем, что это не C#.

S>Да нет, не тем. Тем, что многабукаф на ровном, тскать, месте.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 17:04
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Спорный вопрос. Очень спорный. Я вообще подозреваю, что ORM — это какая-то большая ошибка природы. Но это пока только подозрения.

S>Надеюсь, это не от того, что их в плюсах хрен поддержишь?

Нет, конечно (skip флейм "хрен поддержишь"). Скорее от того, что модель реляционных данных и "объектная модель" — совсем не одно и то же. Например, объектная модель много сильнее подвержена изменениям, в отличие от модели данных — тут и соображения оптимальности, и иной раз недопустимость реструктуризации БД. Короче говоря, эти две модели живут в разных контекстах требований, и апеллировать непременно к "отображению" тут несколько некорректно.

S>Между прочим, исторически первая ООDB до сих пор жива и работает на Smalltalk. Там как раз всё построено на фичах, аналогичных применямым в Linq. Безо всяких костылей. А вот Verant, к примеру, включал в себя отдельный компилятор метаданных, без натравления которого на С++ исходник ничерта не работало.


OODB тут вообще к делу не относятся. Это своя ветка развития баз данных.

S>Так что С++ — это, в некотором смысле, не олдскул, а шаг назад по сравнению с олдскулом.


S>Фишка в том, что ORM, как таковые, в общем-то, не нужны. Что нужно — так это нормальный типизированный доступ к данным (lightweight-ORM) без геморроя.


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

S>Ну так вот даже такую малость, без change tracking, lazy loading, и identity map, на плюсах нормальным образом не вырулишь. Даже с помощью макросов. Всё время будет не хватать каких-то мелочей.


Не совсем тебя понял — ты имеешь в виду, что на плюсах непременно нужны change tracking, lazy loading и identity map, или что даже самый минимум без этих фич, на плюсах не сделаешь?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 17:05
Оценка:
Здравствуйте, Eugeny__, Вы писали:
E__>Не слышал про такое, но если и было, то это просто баг реализации конкретного сборщика, а баги имеют тенденцию к исправлению в следующих версиях.
Это не баг. Это суровая правда жизни. В некоторых случаях неверна даже она: к примеру, если реально кому-то надо захватить неуправляемый ресурс, а в пуле их больше нет (залочены управляемыми обертками), то он встанет на ожидании освобождения; рано или поздно все потоки встанут, и останется только GC+finalizer thread, который наконец разблокирует заблокированное. Но это — очень некоторые случаи. В более частых такая стратегия просто приведет к тому, что все начнут быстро-быстро получать ошибки обращения, а GC будет думать, что так и должно быть.

Впрочем, "более частые" случаи всё еще очень-очень редки по сравнению с частотой случаев, в которых инстинктивно применяемый using() спасает всё.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: За что я не люблю С++
От: drol  
Дата: 27.05.09 17:08
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>А почему свойство — это не тип?


А почему поле класса — это не тип ?

MX>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:


Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.
Re[7]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 17:08
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>>Отлично. Расширь моё сознание альтернативными примерами.

НС>А смысл? Вон рядом тебе примеров привели даже для С++.

Ткни в урл.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 17:10
Оценка:
Здравствуйте, drol, Вы писали:

MX>>А почему свойство — это не тип?

D>А почему поле класса — это не тип ?

Как раз таки — тип.

MX>>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:

D>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.

Where is a difference?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: За что я не люблю С++
От: -MyXa- Россия  
Дата: 27.05.09 17:33
Оценка:
Здравствуйте, drol, Вы писали:

D>Здравствуйте, -MyXa-, Вы писали:


MX>>А почему свойство — это не тип?


D>А почему поле класса — это не тип ?


Конечно не тип, ни то ни это. Я имел в виду вот что:
struct bar
{
    int f;
};

typeid(&bar::f) != typeid(int)


MX>>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:


D>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.


Интересно послушать про тараканов.
И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[2]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:35
Оценка:
Здравствуйте, blackhearted, Вы писали:

B>Я вот чё-то не пойму...


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

B>И будет вам — спокойно.
B>Зачем лаять с видом знатока с 15и летним опытом (именно видом,так как некоторые тезисы очень напоминают одного местного фаната одной ОС с ником на букву S.)?
B>

Лучше поставить автозамену "С++" на "Цэ два плюса и куча минусов".
Re[24]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:37
Оценка:
Здравствуйте, COFF, Вы писали:

COF>>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?


Явно вызывать GC.Collect — моветон.
Re[24]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.05.09 17:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Нет, конечно (skip флейм "хрен поддержишь"). Скорее от того, что модель реляционных данных и "объектная модель" — совсем не одно и то же. Например, объектная модель много сильнее подвержена изменениям, в отличие от модели данных — тут и соображения оптимальности, и иной раз недопустимость реструктуризации БД. Короче говоря, эти две модели живут в разных контекстах требований, и апеллировать непременно к "отображению" тут несколько некорректно.

А, ну про это я сразу соглашусь. Без флейма.

S>>Между прочим, исторически первая ООDB до сих пор жива и работает на Smalltalk. Там как раз всё построено на фичах, аналогичных применямым в Linq. Безо всяких костылей. А вот Verant, к примеру, включал в себя отдельный компилятор метаданных, без натравления которого на С++ исходник ничерта не работало.


ГВ>OODB тут вообще к делу не относятся. Это своя ветка развития баз данных.

Ну, не то чтобы. В принципе, на Старшей Речи и Linq нарулить — невелика проблема. Там весь код — одно сплошное Expression Tree.

ГВ>Мда, что-то в этом роде. Хотя тяжелое отображение (по сути — эмуляция персистентных объектов) тоже иной раз имеет смысл.

Имеет, но редко и недаром.

ГВ>Не совсем тебя понял — ты имеешь в виду, что на плюсах непременно нужны change tracking, lazy loading и identity map, или что даже самый минимум без этих фич, на плюсах не сделаешь?

Второе. Если в новом 0x не сделают expression trees, то всё это будет практически невозможно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:39
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

S>>Общепринятые костыли не становятся менее костыльными. См.напр. MFC.


ГВ>MFC, кстати, вообще интересный феномен. Столько, сколько ругали MFC, наверное, не ругали ни одну другую библиотеку. А ей всё фиолетово — цветёт и пахнет.


Хотя б WTL развивали... а не эту ошибку природы...
Re[4]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:41
Оценка:
Здравствуйте, Antikrot, Вы писали:


C>>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.

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

Какой еще костыль? Вы хоть поняли какую глупость сморозили? Сходите чтоли почитайте.. http://msdn.microsoft.com/en-us/library/bb429476.aspx
..и не пишите больше таких глупостей.
Re[24]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:42
Оценка:
Здравствуйте, NikeByNike, Вы писали:


NBN>>>А если память нужна кому-то ещё?

S>>Это то же самое. Когда память становится нужна кому-то еще, GC это замечает и начинает уборку.

NBN>Вот отсюда главные тормоза и растут.


Только в Вашем бол.. богатом воображении.
Re[22]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:44
Оценка:
Здравствуйте, neFormal, Вы писали:

S>>Но при этом в шарп можно встроить офигительный ORM, а в джаве один хрен будут костыли.


F>а в чём принципиальное преимущество шарпа в этом плане?. какое нибудь дополнительное указание мета-информации?.


Свойства и LINQ
Re[24]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 17:46
Оценка:
Здравствуйте, COFF, Вы писали:


COF>>>Хорошо, усложним задачу, предположим, что обработка ведется несколькими потоками, битмапы передаются из потока в поток во время обработки, тоже будете GC.Collect звать?

MK>>Ты знаешь, я честно говоря, не силен в вызове GC.Collect, т.к. не использую этого метода вообще. И в многопоточных приложениях в том числе.

COF>Но ты же сам его предложил? Теперь оказывается, что ты в нем не силен, зачем предлагал? Я понимаю, что можно сказать, что много программ написано (и тобой в том числе) на C# где такие проблемы не возникают, соответственно это все не актуально. Но ведь на C++ написано еще больше программ безо всяких лямбд и свойств, так ведь?


А еще больше программ написано без классов и ООП. Your point?
Re: За что я не люблю С++
От: Sheridan Россия  
Дата: 27.05.09 18:17
Оценка:
dmitry_npi wrote:

> Да нет, я-то сам его люблю. Случайно наткнулся на статью

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

Я даже читать не буду
Posted via RSDN NNTP Server 2.1 beta
Matrix has you...
Re[25]: За что я не люблю С++
От: COFF  
Дата: 27.05.09 18:58
Оценка:
Здравствуйте, criosray, Вы писали:

C>А еще больше программ написано без классов и ООП. Your point?


А какой тут может быть поинт, за исключением того, что важен не инструмент, а тот, кто его применяет То, что ядро линукс например написано на чистом С, является доказательством того, что сложные работающие системы можно писать без классов и поддержки ООП на уровне языка.
Re[26]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 20:09
Оценка:
Здравствуйте, COFF, Вы писали:

C>>А еще больше программ написано без классов и ООП. Your point?


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


Все важно — и инструмент, и тот, кто его применяет.

А писать можно и на ассемблере.
Re[5]: За что я не люблю С++
От: doarn Россия  
Дата: 27.05.09 20:51
Оценка:
Здравствуйте, criosray, Вы писали:

D>>10 лет назад, С++ несколько другой был, как и сознание о способах использования. + альтернативы ему в мейнстриме — не существовало в принципе, так что в 1999м наезды на С++ были разговорами в пользу бедных. Когда там Java 1.5 вышла, где-то в районе 2003-2004го? А второй шарп?

C>Да не был С++ другим. Точно тот же самый уродец.
Ага, ага. И никакой разницы между gcc 2.95 и хотя бы даже mvsv2k5 нету.
И опыт использования не накоплен никакой?

C>Чертовски за вас рад. Но повторюсь: цифра абсолютно ни о чем не говорит.

Да это я по поводу "рантайм-метаинформация спасет мир" позлобствовал )

C>>>Да и что такого жуткого в операторе using?

D>>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.
C>Да ну? Серьезно? И в каких же случаях сей оператор "не решает задачу"? Назовите парочку.
Выше, аж три =)

C>Много пустых слов. Вы не ответили на поставленный вопрос: вы можете предложить лучшее решение по освобождению ресурсов (не памяти — она-то в отличие от.. освобождается автоматически) в управляемых средах?

Вы этот вопрос уже задавали, я на него уже ответил.
Ни повторяться, ни разжевывать — не буду.
Re[6]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 21:08
Оценка:
Здравствуйте, doarn, Вы писали:

D>>>10 лет назад, С++ несколько другой был, как и сознание о способах использования. + альтернативы ему в мейнстриме — не существовало в принципе, так что в 1999м наезды на С++ были разговорами в пользу бедных. Когда там Java 1.5 вышла, где-то в районе 2003-2004го? А второй шарп?

C>>Да не был С++ другим. Точно тот же самый уродец.
D>Ага, ага. И никакой разницы между gcc 2.95 и хотя бы даже mvsv2k5 нету.
D>И опыт использования не накоплен никакой?

Разница есть. Но не в языке С++.

C>>Чертовски за вас рад. Но повторюсь: цифра абсолютно ни о чем не говорит.

D>Да это я по поводу "рантайм-метаинформация спасет мир" позлобствовал )
А при чем тут рантайм метаинформация?

C>>>>Да и что такого жуткого в операторе using?

D>>>Ничего, только вот сам по себе, кроме как в примитивных случаях — задачу не решает.
C>>Да ну? Серьезно? И в каких же случаях сей оператор "не решает задачу"? Назовите парочку.
D>Выше, аж три =)
Хм? Дайте ссылку. Только пожалуйста не на тот пост, где Вы дали туманный и бессмысленный ответ.

C>>Много пустых слов. Вы не ответили на поставленный вопрос: вы можете предложить лучшее решение по освобождению ресурсов (не памяти — она-то в отличие от.. освобождается автоматически) в управляемых средах?

D>Вы этот вопрос уже задавали, я на него уже ответил.
Нет, не ответили.
Re[19]: За что я не люблю С++
От: Хвост  
Дата: 27.05.09 21:16
Оценка:
Здравствуйте, criosray, Вы писали:

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

очевидно что в C++ нет emit, ну дык ето понятно почему, а вот то что в рантайм генерировать и исполнять код нельзя ето горячка, потому как есть элементарное "сгенерить код и отдать компилятору для сборки dll" или более сложное как LLVM, что первое что второе вполне себе удобные и рабочие решения.
People write code, programming languages don't.
Re[20]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 21:18
Оценка:
Здравствуйте, Хвост, Вы писали:

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

Х>очевидно что в C++ нет emit, ну дык ето понятно почему, а вот то что в рантайм генерировать и исполнять код нельзя ето горячка, потому как есть элементарное "сгенерить код и отдать компилятору для сборки dll" или более сложное как LLVM, что первое что второе вполне себе удобные и рабочие решения.

О производительности и масштабируемости данного решения Вы конечно не задумывались?
Re[19]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 21:39
Оценка:
Здравствуйте, criosray, Вы писали:

C>Не можете, очевидно. В С++ не возможно генерировать и исполнять произвольный код в рантайм.


Да-да-да
Нужно разобрать угил.
Re[21]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 21:48
Оценка:
Здравствуйте, criosray, Вы писали:

Х>>очевидно что в C++ нет emit, ну дык ето понятно почему, а вот то что в рантайм генерировать и исполнять код нельзя ето горячка, потому как есть элементарное "сгенерить код и отдать компилятору для сборки dll" или более сложное как LLVM, что первое что второе вполне себе удобные и рабочие решения.


C>О производительности и масштабируемости данного решения Вы конечно не задумывались?


Я тут ещё добавлю, что за несколько часов (максимум рабочий день, для новичка) можно подключить систему позволяющую подхватывать CPP файлы в проект и динамически переподключать их при изменении. Тут даже проблем никаких нет, кроме формализации процесса (чисто менеджерско/архитекторская задача).
Нужно разобрать угил.
Re[7]: За что я не люблю С++
От: doarn Россия  
Дата: 27.05.09 21:50
Оценка:
Здравствуйте, criosray, Вы писали:

C>Разница есть. Но не в языке С++.

Кому-то нужен язык вне контекста? Мне — нет.
10 лет назад альтернативы С++ в качестве универсального языка — не существовало.
Сейчас — в 2009м — это уже чаще всего неправда, но далеко не всегда — и не потому что С++ такой хороший, а потому что универсальной замены как не было, так и нет — что вот лично для меня — печаль.

D>>Да это я по поводу "рантайм-метаинформация спасет мир" позлобствовал )

C>А при чем тут рантайм метаинформация?
При том что с подходом "а вот теперь мы скормим наше абстрактное нечто хитрому механизму сериализации и будет счастьЕ" (а именно такой вывод я извлек из обсуждаемой статьи) не всегда тру.

D>>Вы этот вопрос уже задавали, я на него уже ответил.

C>Нет, не ответили.
Ну нет так нет
Re[22]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 21:51
Оценка:
Здравствуйте, NikeByNike, Вы писали:

Х>>>очевидно что в C++ нет emit, ну дык ето понятно почему, а вот то что в рантайм генерировать и исполнять код нельзя ето горячка, потому как есть элементарное "сгенерить код и отдать компилятору для сборки dll" или более сложное как LLVM, что первое что второе вполне себе удобные и рабочие решения.


C>>О производительности и масштабируемости данного решения Вы конечно не задумывались?


NBN>Я тут ещё добавлю, что за несколько часов (максимум рабочий день, для новичка) можно подключить систему позволяющую подхватывать CPP файлы в проект и динамически переподключать их при изменении. Тут даже проблем никаких нет, кроме формализации процесса (чисто менеджерско/архитекторская задача).


Во-первых, не ясно при чем тут это.
Во-вторых, это вам требуется несколько часов (максимум день???) на то, что в дотнет делается за 5 минут? Да уж, нашли повод для гордости.
Re[8]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 21:59
Оценка:
Здравствуйте, doarn, Вы писали:

C>>Разница есть. Но не в языке С++.

D>Кому-то нужен язык вне контекста? Мне — нет.
D>10 лет назад альтернативы С++ в качестве универсального языка — не существовало.
D>Сейчас — в 2009м — это уже чаще всего неправда, но далеко не всегда — и не потому что С++ такой хороший, а потому что универсальной замены как не было, так и нет — что вот лично для меня — печаль.

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

D>>>Да это я по поводу "рантайм-метаинформация спасет мир" позлобствовал )

C>>А при чем тут рантайм метаинформация?
D>При том что с подходом "а вот теперь мы скормим наше абстрактное нечто хитрому механизму сериализации и будет счастьЕ" (а именно такой вывод я извлек из обсуждаемой статьи) не всегда тру.

Откройте для себя WCF.
Re[10]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 22:15
Оценка:
Здравствуйте, NikeByNike, Вы писали:

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


C>>Начнем с того, что С++ не является универсальным языком. На этом и закончим.


NBN>Универсальным не является, но является (со своей сопутствующей поддержкой) наиболее универсальным среди распространённых.


Поделитесь критериями универсальности?
Re[24]: За что я не люблю С++
От: criosray  
Дата: 27.05.09 22:17
Оценка:
Здравствуйте, NikeByNike, Вы писали:


C>>Во-первых, не ясно при чем тут это.

C>>Во-вторых, это вам требуется несколько часов (максимум день???) на то, что в дотнет делается за 5 минут? Да уж, нашли повод для гордости.

NBN>В реальной жизни примерно столько же, хотя конечно всёравно проще (про пятиминутные исправления обычно говорят люди с 1-2 годами опыта реальной работы и ещё не умеющие отвечать за базар). Главный тормоз в этом не само подключение, а формализация процесса.

Да уж, задача невиданной сложности. Несколько часов, а то и день, чтоб формализовать... Похоже, что и среди плюсистов есть индусокодеры...
NBN>И я встрял исключительно чтобы показать тебе ещё один твой пробел в знаниях.
В итоге показали пробел в своих собственных знаниях. Так держать.


NBN>P.S.

NBN>Кончай фанатствовать
Начните с себя.
Re[19]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 27.05.09 22:21
Оценка:
Здравствуйте, criosray, Вы писали:

C>В С++ не возможно генерировать и исполнять произвольный код в рантайм.


Это на каком заборе так написано? Или опять — в википедии?

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


"Структура словарного типа" — это что такое? Какова связь "исполнения произвольного кода" с "десериализацией"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[11]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 22:27
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Начнем с того, что С++ не является универсальным языком. На этом и закончим.


NBN>>Универсальным не является, но является (со своей сопутствующей поддержкой) наиболее универсальным среди распространённых.


C>Поделитесь критериями универсальности?


А головкой подумать?
Нужно разобрать угил.
Re[25]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 27.05.09 22:29
Оценка:
Здравствуйте, criosray, Вы писали:

Ты смешной Давно не наблюдал такой откровенной страусной тактики. Спасибо!
Нужно разобрать угил.
Re[3]: За что я не люблю С++
От: Sorantis Швеция  
Дата: 28.05.09 01:38
Оценка:
Здравствуйте, dds777, Вы писали:

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


S>>Сложилось ощущение, что автор долго искал баг, дооолго искал, но не нашел и свалил все на язык.


D>Вы это зря, автор довольно известный и уважаемый. Лично я думаю, что вся проблема в том, что он имеет удовольствие (впрочем как и я) писать под мак на Objective-C, поэтому когда в проекте встречаются эти два языка (такое частенько бывает), сложно себя удержать от ругани C++


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

Я с Objective-C дело никогда не имел, а С++ ругал в случаях когда отлавливал баг. А потом ругал себя за свое ламерство.
Берясь за С++ не стоит ожидать сахара и шоколада.
Я на С++ фактически уже не пишу (недавно только пришлось разбирать один метод программирования используя С++сную библиотеку)
Пишу на Шарпах, Джаве, и прочих "не трушных" языках. И что-то не могу припомнить, что я ругал С++ за его недостатки кодя на управляемых языках.
Вот джаву ругал, да, было дело, долго ругал
As long as there is life, there is hope
Re[21]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 03:03
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>В С++ не возможно генерировать и исполнять произвольный код в рантайм.

ГВ>>Это на каком заборе так написано? Или опять — в википедии?
C>Это на каком заборе написано что можно?

Э-э-э... У тебя что-то не то с логикой. Я спрашивал — где написан тот запрет, о котором ты упомянул? Тут ведь вот какое свинство, C++ подразумевает возможность генерировать и исполнять машинный код в рантайме. Знаешь, это настолько общеизвестная возможность, что некоторые горячие головы C++ за это даже ругают. Да-да!

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

ГВ>>"Структура словарного типа" — это что такое?
C>Почитайте в википедии или на том заборе, где Вы вычитали, что в С++ есть возможность генерации машинного кода на лету.

Так что такое "структура словарного типа"? Ты можешь объяснить или нет?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 03:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Не совсем тебя понял — ты имеешь в виду, что на плюсах непременно нужны change tracking, lazy loading и identity map, или что даже самый минимум без этих фич, на плюсах не сделаешь?

S>Второе. Если в новом 0x не сделают expression trees, то всё это будет практически невозможно.

Мне доводилось плотно возиться с полновесным отображением, и все эти фичи вводились сразу — и отслеживание изменений, и ленивая подгрузка, и отображение ключей. Всё это на C++. Единственная характерная черта, в прочем, как это свойственно для C++, так это то, что классы, отображаемые на БД записываются примерно так (ща раскудахчутся, чую):

class Department;

class Personnel : public DBClass {
  MYMACRO_KEY(int, m_Key)
  MYMACRO(string, m_Name)
  MYMACRO(string, m_Family)
  MYMACRO_REFS(Department)
};


Деталей сейчас уже не помню, но идея, думаю, понятна.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[26]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 05:47
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Деталей сейчас уже не помню, но идея, думаю, понятна.

Конечно понятна. Непонятно, каким образом собираются работать простейшие запросы. Само отображение — это натурально прошлый век, конец девяностых.
Я в своё время пытался придумать такую штуку; в итоге кончилось ничем — на макросах такое не залудишь, потому что нужно два разных класса — один для данных, другой для метаданных. Ну, разве что компилять один хидер дважды с разными дефайнами, а это уже плохо дружит со всякими прекомпиляциями и всё такое. И всё равно не получается сделать полноценные запросы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 06:57
Оценка:
Здравствуйте, Antikrot, Вы писали:

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

C>>>>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.
A>>>вот это всем костылям костыль. так с языком чуть ли не что угодно сделать можно, не только проперти в плюсах приделать

C>>Какой еще костыль? Вы хоть поняли какую глупость сморозили?

A>костыль-костыль. как еще назвать дополнительное приложение, встроенное в билд-процесс и исправляющее [потенциальные] ошибки программиста? ведь в стандарте языка-то его нет
A>получается, что использование препроцессора в QT — это костыль и проблемы C++, а использование постпроцессора в C# — это так и надо?
Собстенно да, вот с этим я полностью согласен. С тем, что данная фича FxCop скорее зло, чем благо, и в пример ее лучше не приводить
Re[21]: Подсчёт ссылок
От: COFF  
Дата: 28.05.09 07:29
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Как сделать на C# что? Подсчёт ссылок а-ля shared_ptr? :) Он хрестоматийно реализуется в любом современном языке. В C# аналогом плюсового деструктора является метод Dispose() (а не финализатор, как думают некоторые), в нём надо декрементировать счётчик, а при его обнулении — освобождать неуправляемый ресурс.


Хм, а где его надо инкрементировать?
Re[22]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 28.05.09 07:43
Оценка:
ГВ> M>Угу. Вспоминатся Qt, где подобное реализовано для событий. Приходится препроцессор отдельный прогонять. А как только где-то что-то навернется, ни один дебаггер не спасет

ГВ> Угу, только в данном случае под PROPERTY скрывается тривиальное упрощение синтаксиса объявления инстанцированного шаблонного типа и соответствующей переменной-члена.


Если чо, до ошибки все равно не докопаться

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


Лучше, если эти пять строк уже встроены в язык
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[27]: За что я не люблю С++
От: COFF  
Дата: 28.05.09 07:53
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Я в своё время пытался придумать такую штуку; в итоге кончилось ничем — на макросах такое не залудишь, потому что нужно два разных класса — один для данных, другой для метаданных. Ну, разве что компилять один хидер дважды с разными дефайнами, а это уже плохо дружит со всякими прекомпиляциями и всё такое. И всё равно не получается сделать полноценные запросы.


Ну, зато нам не надо фреймворк за собой тащить :) Вообще, если серьезно, то я бы сделал что-то типа IDL, но для описания не интерфейсов, а метаданных, потом это дело компилится в C++ код, создаются базовые классы с данными, от которых нужно наследоваться, плюс классы с метаданными. С другой стороны, если такие штуки действительно нужны в программе на C++, то тут уже можно подумать о яве или .нет, правда не везде они есть или работают удовлетворительно.
Re[22]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 08:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

C>>>>В С++ не возможно генерировать и исполнять произвольный код в рантайм.

ГВ>>>Это на каком заборе так написано? Или опять — в википедии?
C>>Это на каком заборе написано что можно?

ГВ>Э-э-э... У тебя что-то не то с логикой. Я спрашивал — где написан тот запрет, о котором ты упомянул? Тут ведь вот какое свинство, C++ подразумевает возможность генерировать и исполнять машинный код в рантайме. Знаешь, это настолько общеизвестная возможность, что некоторые горячие головы C++ за это даже ругают. Да-да!


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

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

ГВ>>>"Структура словарного типа" — это что такое?
C>>Почитайте в википедии или на том заборе, где Вы вычитали, что в С++ есть возможность генерации машинного кода на лету.

ГВ>Так что такое "структура словарного типа"? Ты можешь объяснить или нет?


Понятно. Дожились. Нынче программисты даже таких базовых вещей не знают. Тьфу.
Re[6]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 08:46
Оценка:
Здравствуйте, Antikrot, Вы писали:

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


C>>>>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.

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

C>>Какой еще костыль? Вы хоть поняли какую глупость сморозили?

A>костыль-костыль. как еще назвать дополнительное приложение, встроенное в билд-процесс и исправляющее [потенциальные] ошибки программиста?
fxcop к Вашему сведенью ничего не исправляет. fxcop проверяет сборку на соответствие определенному набору правил и выдает предупреждения в тех местах, где таковые были нарушены. Для С++ ничего и близко подобного нету.

A>ведь в стандарте языка-то его нет

Чего нет в стандарте языка?

A>получается, что использование препроцессора в QT — это костыль и проблемы C++, а использование постпроцессора в C# — это так и надо?

Понятно. Ссылку Вы так и не прочитали. fxcop не является постпроцессором. Садитесь два.

C>>Сходите чтоли почитайте.. http://msdn.microsoft.com/en-us/library/bb429476.aspx

A>ну, в отличии от некоторых почитателей отдельных ОС/браузеров тут, я таки сначала прочитал
Заметно как Вы прочитали.
Re[23]: За что я не люблю С++
От: COFF  
Дата: 28.05.09 08:48
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Так что такое "структура словарного типа"? Ты можешь объяснить или нет?


C>Понятно. Дожились. Нынче программисты даже таких базовых вещей не знают. :down: Тьфу.


Самое прикольное, что гугл с яндексом тоже не знают :) Поделись же сокровенным знанием, о наимудрейший? ;)
Re[3]: За что я не люблю С++
От: blackhearted Украина  
Дата: 28.05.09 08:49
Оценка:
Здравствуйте, MxKazan, Вы писали:
B>>Зачем лаять с видом знатока с 15и летним опытом (именно видом,так как некоторые тезисы очень напоминают одного местного фаната одной ОС с ником на букву S.)?
B>>
MK>Мы ж в КСВ!!!

А где же сам Шеридан?
Тут же говорят плохие вещи на "Цэ два плюса и куча минусов"
Re[7]: За что я не люблю С++
От: Antikrot  
Дата: 28.05.09 09:00
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Сходите чтоли почитайте.. http://msdn.microsoft.com/en-us/library/bb429476.aspx

A>>ну, в отличии от некоторых почитателей отдельных ОС/браузеров тут, я таки сначала прочитал
C>Заметно как Вы прочитали.
и еще более заметно как вы его используете:
C>>>>>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.
Re[3]: За что я не люблю С++
От: Antikrot  
Дата: 28.05.09 09:01
Оценка:
Здравствуйте, _d_m_, Вы писали:

>>> Да нет, я-то сам его люблю. Случайно наткнулся на статью

>>> здесь. Он не просто его, не
>>> любит, он его ненавидит. И других заразить пытается. Вот, думаю, тролль Отличная приманка для
>>> священной войны.
S>>Я даже читать не буду
___>Ты как страус зарыл голову с песок.
а нафига ему читать, если там про линукс ни слова?
Re[27]: За что я не люблю С++
От: Хвост  
Дата: 28.05.09 09:15
Оценка:
Здравствуйте, criosray, Вы писали:

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

C>>>Программисты С++ уже и гуглем пользоваться разучились? http://en.wikipedia.org/wiki/Associative_array
COF>>Жжошь неподецки
C>Вы, молодой человек, постыдились бы своей необразованности вместо того, чтоб выставлять ее на показ.
Я конечно люблю и уважаю русский язык тоже, но извольте, барин, где вы взяли ету "структуру словарного типа"? А так ведь можно и КД-ПЗУ ввернуть ненароком, дескать, чтоб "уровень образованности" показать
People write code, programming languages don't.
Re[7]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 10:09
Оценка:
Здравствуйте, criosray, Вы писали:

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

A>>Здравствуйте, criosray, Вы писали:
C>>>>>Тем более, что в автобилд встроен fxcop, энфорсящий вызов Dispose для объектов, реализующих IDisposable.
A>>>>вот это всем костылям костыль. так с языком чуть ли не что угодно сделать можно, не только проперти в плюсах приделать
C>>>Какой еще костыль? Вы хоть поняли какую глупость сморозили?
A>>костыль-костыль. как еще назвать дополнительное приложение, встроенное в билд-процесс и исправляющее [потенциальные] ошибки программиста?

C>fxcop к Вашему сведенью ничего не исправляет. fxcop проверяет сборку на соответствие определенному набору правил и выдает предупреждения в тех местах, где таковые были нарушены. Для С++ ничего и близко подобного нету.


Так я не понял: он "энфорсит" или просто предупреждения выдает?
Re[29]: За что я не люблю С++
От: Хвост  
Дата: 28.05.09 10:16
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Хвост, Вы писали:


C>Сегодня просто повальное количество откровений г-д С++ников. Оказываются они совсем не в курсе о базовой структуре данных, называемой словарем (ассоциативным массивом, картой и т.д.).

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

C>Ликбез:

C>Что до того зачем я "ввернул", как Вы соизволили выразиться, так вот за тем, что объект есть суть ассоциативный массив. В динамических языках типа джаваскрипта так вообще объекты есть ни что иное, как словари.
ну вы так за все реализации жаваскрипта не говорите, в V8 например от етого отказались и поимели нехилый профит, за подробностями — в гугол.
People write code, programming languages don't.
Re[8]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 10:16
Оценка:
Здравствуйте, MxKazan, Вы писали:

C>>fxcop к Вашему сведенью ничего не исправляет. fxcop проверяет сборку на соответствие определенному набору правил и выдает предупреждения в тех местах, где таковые были нарушены. Для С++ ничего и близко подобного нету.


MK>Так я не понял: он "энфорсит" или просто предупреждения выдает?


Энфорсит, выдавая предупреждения. fxcop и stylecop — составная часть автоматического билда у нас.
Re[30]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 10:20
Оценка:
Здравствуйте, Хвост, Вы писали:


C>>Сегодня просто повальное количество откровений г-д С++ников. Оказываются они совсем не в курсе о базовой структуре данных, называемой словарем (ассоциативным массивом, картой и т.д.).

Х>Что-то мне подсказывает что г-да С++ники в курсе о существовании структуры данных называемой "словарём", и их удивление вызвало несколько иное словосочетание, ну да ничего страшного, и ваш язык научимся понимать, всё приходит с опытом.

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

Структура данных "словарь" тождественно словарная структура данных.

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

C>>Ликбез:

C>>Что до того зачем я "ввернул", как Вы соизволили выразиться, так вот за тем, что объект есть суть ассоциативный массив. В динамических языках типа джаваскрипта так вообще объекты есть ни что иное, как словари.
Х>ну вы так за все реализации жаваскрипта не говорите, в V8 например от етого отказались и поимели нехилый профит, за подробностями — в гугол.
Это тут вообще при чем?
Re[9]: За что я не люблю С++
От: Antikrot  
Дата: 28.05.09 10:20
Оценка:
Здравствуйте, criosray, Вы писали:

MK>>Так я не понял: он "энфорсит" или просто предупреждения выдает?

C>Энфорсит, выдавая предупреждения. fxcop и stylecop — составная часть автоматического билда у нас.

так бы и написал сразу — "бьёт по рукам"
Re[22]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 10:20
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Хм, а где его надо инкрементировать?


В кторе и в методе типа Copy() или там ShareOwnership().
Глаза у меня добрые, но рубашка — смирительная!
Re[10]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 10:25
Оценка:
Здравствуйте, Antikrot, Вы писали:


MK>>>Так я не понял: он "энфорсит" или просто предупреждения выдает?

C>>Энфорсит, выдавая предупреждения. fxcop и stylecop — составная часть автоматического билда у нас.

A>так бы и написал сразу — "бьёт по рукам"


А я так и написал. Кто Вам виноват, что Вы не знаете, что слово "энфорсить" означает "вынуждать", "обязывать", "заставлять".
Re[11]: За что я не люблю С++
От: Хвост  
Дата: 28.05.09 10:31
Оценка:
Здравствуйте, criosray, Вы писали:

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



MK>>>>Так я не понял: он "энфорсит" или просто предупреждения выдает?

C>>>Энфорсит, выдавая предупреждения. fxcop и stylecop — составная часть автоматического билда у нас.
A>>так бы и написал сразу — "бьёт по рукам"
C>А я так и написал. Кто Вам виноват, что Вы не знаете, что слово "энфорсить" означает "вынуждать", "обязывать", "заставлять".

и всё-таки мне решительно не понятно почему ето не "костыль".
People write code, programming languages don't.
Re[26]: За что я не люблю С++
От: Eugeny__ Украина  
Дата: 28.05.09 10:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

E__>>Не слышал про такое, но если и было, то это просто баг реализации конкретного сборщика, а баги имеют тенденцию к исправлению в следующих версиях.
S>Это не баг. Это суровая правда жизни. В некоторых случаях неверна даже она: к примеру, если реально кому-то надо захватить неуправляемый ресурс, а в пуле их больше нет (залочены управляемыми обертками), то он встанет на ожидании освобождения; рано или поздно все потоки встанут, и останется только GC+finalizer thread, который наконец разблокирует заблокированное. Но это — очень некоторые случаи. В более частых такая стратегия просто приведет к тому, что все начнут быстро-быстро получать ошибки обращения, а GC будет думать, что так и должно быть.

Ну, я не имел ввиду неуправляемые ресурсы. При работе с таквыми действительно нужно быть аккуратным, и явно освобождать, здесь вопросов нет. Пользуясь случаем, передаю привет Сану, который до сих пор не удосужился ввести конструкцию using в жабу, из-за чего получается либо многословный try-finally, либо нужно городить огороды с АОП.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[32]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 10:40
Оценка:
Здравствуйте, Хвост, Вы писали:


C>>>>Ликбез:

C>>>>Что до того зачем я "ввернул", как Вы соизволили выразиться, так вот за тем, что объект есть суть ассоциативный массив. В динамических языках типа джаваскрипта так вообще объекты есть ни что иное, как словари.
Х>>>ну вы так за все реализации жаваскрипта не говорите, в V8 например от етого отказались и поимели нехилый профит, за подробностями — в гугол.
C>>Это тут вообще при чем?
Х>притом, что выделенная фраза не верна

Верна. А Вам советую поменьше балаболить.
Re[23]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 10:41
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Э-э-э... У тебя что-то не то с логикой. Я спрашивал — где написан тот запрет, о котором ты упомянул? Тут ведь вот какое свинство, C++ подразумевает возможность генерировать и исполнять машинный код в рантайме. Знаешь, это настолько общеизвестная возможность, что некоторые горячие головы C++ за это даже ругают. Да-да!

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

Ответь мне на один наводящий вопрос: а что дальше делать с этой сгенерированной и полностью новой структурой?

Вот, приехало мне описание класса, например, такое:

<class Name="NewClass">
<member type="int" Name="m_i"/>
</class>

Сгенерировал я программу на C++, натравил компилятор, получил загрузочный модуль, загрузил этот модуль. Где-то в недрах у меня сгенерировался класс NewClass, допустим, унаследованный от некоторого GeneratedClassBase. Сгенерировался и экземпляр этого класса. Что дальше должен со всем этим делать? Ни одна другая часть программы знать ничего не знает о том, что третьего дня в потрохах адресного пространства появился указатель 0x3F5849AC, указывающий не на что-нибудь, а на экземпляр типа NewClass (хотя про сам этот указатель все, кому надо знать, уже знают). Тем более об этом не догадывается, например, визуализатор — вот не знает он, что по смещению 0x30 от адреса 0x3F5849AC лежат четыре байта, представляющие собой NewClass::m_i.

Так что делать-то софтинке? Куда податься?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Подсчёт ссылок
От: COFF  
Дата: 28.05.09 10:50
Оценка:
Здравствуйте, Qbit86, Вы писали:

COF>>Хм, а где его надо инкрементировать?


Q>В кторе и в методе типа Copy() или там ShareOwnership().


О, как! Когда я в соседней ветке написал, что придется после (ну или вместо — что смысла не меняет) присваивания звать подобный метод, то меня обвинили в ламерстве. Теперь оказывается, что таки да. Еще можно вспомнить ручной инлайнинг... В общем, картина начинает проясняться
Re[11]: За что я не люблю С++
От: Antikrot  
Дата: 28.05.09 10:53
Оценка:
Здравствуйте, criosray, Вы писали:

MK>>>>Так я не понял: он "энфорсит" или просто предупреждения выдает?

C>>>Энфорсит, выдавая предупреждения. fxcop и stylecop — составная часть автоматического билда у нас.

A>>так бы и написал сразу — "бьёт по рукам"


C>А я так и написал. Кто Вам виноват, что Вы не знаете, что слово "энфорсить" означает "вынуждать", "обязывать", "заставлять".


Я еще с десяток переводов знаю.
Гугл вам поможет понять разницу между "error" и "warning". А вот понять разницу между "предупредить" и "заставить" вам помогут в старших классах.
Re[27]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 10:58
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Деталей сейчас уже не помню, но идея, думаю, понятна.

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

S>Я в своё время пытался придумать такую штуку; в итоге кончилось ничем — на макросах такое не залудишь, потому что нужно два разных класса — один для данных, другой для метаданных. Ну, разве что компилять один хидер дважды с разными дефайнами, а это уже плохо дружит со всякими прекомпиляциями и всё такое. И всё равно не получается сделать полноценные запросы.


Зависит от того, когда ты это пытался сделать. Если во времена MSVC6 (как раз, когда я этим занимался), то это в самом деле почти невозможно. Если не так давно, то посмотри, например, в boost::lambda — вот тебе пример того, как на C++ синтезируется совсем другой язык.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 11:11
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>У нас это решается внешним кодогенератором, который генерит перситы по объектной схеме и связывает их с метаинформацией, а метаинформация вычитывается из схемы данных.

Да-да, я так и думал, что дойдем до кодогенератора.
Собственно, оба ответа про DSL были очевидны, и по этой дороге я тоже ходил.
DC> Отношения сделаны таким образом что с ними работаешь как со списком, есть ленивая загрузка, есть способ строить запросы с проверкой типов в рантайме, можно прикрутить и чтоб в компаил тайме работало, но когда делали это всё компилилось, в том числе, древним VS6.
Ленивая загрузка пусть убъет себя болезненно, а вот насчет построения запросов с проверкой типов в компайл тайме я бы посмотрел. Всегда полезно расширить кругозор.
Предположим у нас есть классические таблички из а-ля Нортвинд: Employee(ID, FirstName, LastName, ManagerId FK Employee.ID), Order(EmployeeID FK Employee.ID, Amount, Date).
Хотим посмотреть, у кого подчинённые наторговали больше продаж в январе. Аналог вот такого запроса на SQL:
select m.FirstName, m.LastName, sum(o.Amount) as TotalAmount 
 from Employee m 
 inner join Employee e on m.id = e.ManagerID
 inner join Order o on o.EmployeeId = e.ID
 where Order.Date between '20080101' and '20080131'

Как будет выглядеть на этой гипотетической системе?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 11:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Сгенерировал я программу на C++, натравил компилятор, получил загрузочный модуль, загрузил этот модуль.

ЧТД.
Re[29]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 11:15
Оценка:
Здравствуйте, Sinclair, Вы писали:


S>
S>select m.FirstName, m.LastName, sum(o.Amount) as TotalAmount 
S> from Employee m 
S> inner join Employee e on m.id = e.ManagerID
S> inner join Order o on o.EmployeeId = e.ID
S> where Order.Date between '20080101' and '20080131'
S>


Не суть важно конечно, но забыли group by.
Re[29]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 11:18
Оценка:
Здравствуйте, criosray, Вы писали:

C>Ликбез:

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

C>http://www.quirksmode.org/js/associative.html


Хм. Да ты не только альтернативно по-русски изъясняешься, ты ещё и с альтернативного английского переводишь. Знаешь, первый раз слышу, чтобы "Objects as associative arrays" переводилось "объект есть суть ассоциативный массив". Это ты сильно задвинул.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 11:19
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Сгенерировал я программу на C++, натравил компилятор, получил загрузочный модуль, загрузил этот модуль.

C>ЧТД.

То есть от заданного мной наводящего вопроса ты ушёл?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 11:22
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Ликбез:

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

C>>http://www.quirksmode.org/js/associative.html


ГВ>Хм. Да ты не только альтернативно по-русски изъясняешься, ты ещё и с альтернативного английского переводишь.

Я ничего не перевожу. Если у Вас проблемы с пониманием и русского и английского, то это Ваши проблемы, а не мои.

ГВ>Знаешь, первый раз слышу, чтобы "Objects as associative arrays" переводилось "объект есть суть ассоциативный массив". Это ты сильно задвинул.

Я ничего не переводил. Вам по теме сказать больше нечего? Что такое словарная структура данных теперь знаете? Вот и отличненько.

Надеюсь, мне не придется в будущем объяснять Вам что такое "списочная структура данных", что такое "древовидная структура данных" и т.п.?


PS: Ей богу, не надоело позориться, Геннадий?
Re[24]: Подсчёт ссылок
От: MxKazan Португалия  
Дата: 28.05.09 11:22
Оценка:
Здравствуйте, COFF, Вы писали:

COF>О, как! Когда я в соседней ветке написал, что придется после (ну или вместо — что смысла не меняет) присваивания звать подобный метод, то меня обвинили в ламерстве. Теперь оказывается, что таки да. Еще можно вспомнить ручной инлайнинг... В общем, картина начинает проясняться

И что же тебе прояснилось?
Re[26]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 11:24
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Сгенерировал я программу на C++, натравил компилятор, получил загрузочный модуль, загрузил этот модуль.

C>>ЧТД.

ГВ>То есть от заданного мной наводящего вопроса ты ушёл?


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

Заниматься восполнением пробелов в Вашем образовании я не намерен.
Re[27]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 11:43
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>То есть от заданного мной наводящего вопроса ты ушёл?

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

Спасибо, я знаю, зачем генериуются прокси-классы. Проблема в том, что прокси не являются "абсолютно новыми" во всех отношениях. Система, образно выражаясь, "знает", куда их нужно помещать, что с ними делать и т.п. Но я так понял, что ты вёл речь о совершенно новых и неизвестных программе классах. Вот мне и интересно стало — как же система будет использовать эти самые новые и неизвестные классы?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[29]: За что я не люблю С++
От: dr.Chaos Россия Украшения HandMade
Дата: 28.05.09 11:44
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ленивая загрузка пусть убъет себя болезненно, а вот насчет построения запросов с проверкой типов в компайл тайме я бы посмотрел. Всегда полезно расширить кругозор.

S>Предположим у нас есть классические таблички из а-ля Нортвинд: Employee(ID, FirstName, LastName, ManagerId FK Employee.ID), Order(EmployeeID FK Employee.ID, Amount, Date).
S>Хотим посмотреть, у кого подчинённые наторговали больше продаж в январе. Аналог вот такого запроса на SQL:
S>
S>select m.FirstName, m.LastName, sum(o.Amount) as TotalAmount 
S> from Employee m 
S> inner join Employee e on m.id = e.ManagerID
S> inner join Order o on o.EmployeeId = e.ID
S> where Order.Date between '20080101' and '20080131'
S>

S>Как будет выглядеть на этой гипотетической системе?

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

template<class T>
SimpleCondition Equal( Parameter<T> , T );


Для джоинов можно было б, например, так:

template <class X, class Y>
JoinCondition Join(Parameter<X> , Parameter<Y>)
{
   static_assert(is_types_compatible<X,Y>);
}


Ну и соответствующие специализации этого шаблона нагенерить.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[28]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 11:45
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Зависит от того, когда ты это пытался сделать. Если во времена MSVC6 (как раз, когда я этим занимался), то это в самом деле почти невозможно. Если не так давно, то посмотри, например, в boost::lambda — вот тебе пример того, как на C++ синтезируется совсем другой язык.
Ну а конкретнее — позволяет мне этот другой язык получать Expression Trees, которые строго контролируются в компайл тайме, а исследуются в рантайме?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 11:45
Оценка:
Здравствуйте, criosray, Вы писали:
C>Не суть важно конечно, но забыли group by.
Да, конечно. Конечно важно.

select m.FirstName, m.LastName, to.TotalAmount
  from Employee m 
  inner join 
  (
    select e.ManagerId, sum(o.Amount) as TotalAmount
    from Employee e inner join Orders o on o.EmployeeId = e.ID
    where o.Date between '20080101' and '20080131'
    group by e.ManagerId
  ) to on m.id = to.ManagerID
 order by TotalAmount desc
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 11:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>То есть от заданного мной наводящего вопроса ты ушёл?

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

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


Про совершенно неизвестные это Вы сами придумали. Достаточно, чтоб класс реализовал заранее известный контракт, ака интерфейс.

Я не зря упоминал WCF, но Вы проигнорировали.

Что до конкретных практических задач — тут совсем недавно обсуждали одну. Будьте внимательнее.
Re[31]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 11:56
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Знаешь, первый раз слышу, чтобы "Objects as associative arrays" переводилось "объект есть суть ассоциативный массив". Это ты сильно задвинул.

C>Я ничего не переводил. Вам по теме сказать больше нечего? Что такое словарная структура данных теперь знаете? Вот и отличненько.

Исходно ты употребил словосочетание "Структура словарного типа". Разницу понимаешь?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 12:02
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Не-не-не Девид Блейн .

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

DC>А вот проверки соответсвия передаваемого значения довольно просто сделать, например так:


DC>
DC>template<class T>
DC>SimpleCondition Equal( Parameter<T> , T );
DC>

И? Пример использования можно?
Давайте получим хотя бы
select * from Orders where Date between '20080101' and '20080131'


Если выйдет — напишите мне
select EmployeeID from Orders where Date between '20080101' and '20080131'
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 12:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Зависит от того, когда ты это пытался сделать. Если во времена MSVC6 (как раз, когда я этим занимался), то это в самом деле почти невозможно. Если не так давно, то посмотри, например, в boost::lambda — вот тебе пример того, как на C++ синтезируется совсем другой язык.
S>Ну а конкретнее — позволяет мне этот другой язык получать Expression Trees, которые строго контролируются в компайл тайме, а исследуются в рантайме?

Естественно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: За что я не люблю С++
От: Eugeny__ Украина  
Дата: 28.05.09 12:10
Оценка:
Здравствуйте, doarn, Вы писали:


D>>>Да это я по поводу "рантайм-метаинформация спасет мир" позлобствовал )

C>>А при чем тут рантайм метаинформация?
D>При том что с подходом "а вот теперь мы скормим наше абстрактное нечто хитрому механизму сериализации и будет счастьЕ" (а именно такой вывод я извлек из обсуждаемой статьи) не всегда тру.


Я могу назвать реальный пример, когда универсальный сериалайзер жизненно необходим.
Сервер веб-приложений. В нем крутятся N веб-приложений, структура и данные которых серверу неизвестны. Приложения хранят некоторые данные в сессиях. Веб-серверу по независящим от него причинам нужно рестартануться. У нас 2 варианта:
1. Сохранить данные сессий универсальным сериализатором на диск, чтобы после рестарта поднять их и продолжить работу.
2. Послать пользователай на###, и просто рестартануться, забив на данные.

Других решений я не вижу.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[29]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 12:30
Оценка:
Здравствуйте, criosray, Вы писали:

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


C>Про совершенно неизвестные это Вы сами придумали. Достаточно, чтоб класс реализовал заранее известный контракт, ака интерфейс.


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


Где здесь про контракт? Ты говоришь про спецификацию, переданную из текстового файла. Никаких дополнительных оговорок нет, значит, спецификация может быть, скажем так, практически любой, то есть специфицировать любой класс, в принципе допустимый данным языком программирования. Интерфейс это, прокси, мок, ещё какая вода на киселе — то нам не ведомо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[24]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 12:36
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ответь мне на один наводящий вопрос: а что дальше делать с этой сгенерированной и полностью новой структурой?
Ну хорошо. Пусть это будет не совсем новая структура.
Пусть это будет, скажем, наследник некоего известного интерфейса. Впрочем, нет — этого нам недостаточно. Потребуется еще какая-то функция со стандартной сигнатурой.
Скажем,
IStandardObject factory()

Насколько практично порождать новый код такого рода на С++? К примеру, если у меня есть регулярное выражение — сколько вызовов Match() на нескомпилированном выражении скомпенсируют стоимость компиляции выражения? Тысяча? Миллион?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Подсчёт ссылок
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.05.09 12:36
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Ты таки настаиваешь на том, что подсчёт ссылок — техника исключительно приплюснутых?

Он намекает на то, что в плюсах можно перегрузить конструктор копирования и оператор присваивания, а в дотнете нельзя. Поэтому соглашение об инкременте указателя придется выполнять самостоятельно. Это, конечно, не совсем то, чего хочется. Но лучше бы посмотреть на сценарии реального использования.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: За что я не люблю С++
От: Константин Б. Россия  
Дата: 28.05.09 13:00
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Зависит от того, когда ты это пытался сделать. Если во времена MSVC6 (как раз, когда я этим занимался), то это в самом деле почти невозможно. Если не так давно, то посмотри, например, в boost::lambda — вот тебе пример того, как на C++ синтезируется совсем другой язык.


А вы все эти темплейтные навороты реально используете или так флейма ради упоминаете? Те кто использует обычно жалуются на неприлично долгую линковку. А иной раз приходится приседания делать чтобы компилятор не падал.
Re[29]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 14:03
Оценка:
Здравствуйте, Константин Б., Вы писали:

ГВ>>Зависит от того, когда ты это пытался сделать. Если во времена MSVC6 (как раз, когда я этим занимался), то это в самом деле почти невозможно. Если не так давно, то посмотри, например, в boost::lambda — вот тебе пример того, как на C++ синтезируется совсем другой язык.


КБ>А вы все эти темплейтные навороты реально используете или так флейма ради упоминаете?


Использую, конечно. И не только буст.

КБ>Те кто использует обычно жалуются на неприлично долгую линковку.


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

КБ>А иной раз приходится приседания делать чтобы компилятор не падал.


Падения компилятора были серьёзной проблемой в одиозном MSVC6. Начиная с 2K3 в этом отношении особых проблем нет. Бывают случаи, но достаточно редко, чтобы не обращать внимания.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 14:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Насколько практично порождать новый код такого рода на С++? К примеру, если у меня есть регулярное выражение — сколько вызовов Match() на нескомпилированном выражении скомпенсируют стоимость компиляции выражения? Тысяча? Миллион?


Если говорить о полном цикле "генерация текста на C++ — компиляция — линковка — подгрузка", то я бы оценил примерно в сотни тысяч — единицы миллионов. То есть приблизительно секунды (цикл генерации) против микросекунд (выигрыш от скомпилированного выражения). Хотя сам понимаешь, зависит ещё и от структуры выражения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: За что я не люблю С++
От: March_rabbit  
Дата: 28.05.09 15:19
Оценка:
Здравствуйте, Mamut, Вы писали:

ГВ>> M>Угу. Вспоминатся Qt, где подобное реализовано для событий. Приходится препроцессор отдельный прогонять. А как только где-то что-то навернется, ни один дебаггер не спасет


ГВ>> Угу, только в данном случае под PROPERTY скрывается тривиальное упрощение синтаксиса объявления инстанцированного шаблонного типа и соответствующей переменной-члена.


M>Если чо, до ошибки все равно не докопаться


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


M>Лучше, если эти пять строк уже встроены в язык

осторожно! Можно ведь и захотеть декодер mpc поиметь встроенный в язык
Ограничивать себя в сладостях надо
Re[32]: За что я не люблю С++
От: criosray  
Дата: 28.05.09 15:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>>>

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


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

C>>Это Вы себе сами придумали.

ГВ>Понятно. Значит, я придумал цитату из твоего собственного постинга. А сам твой постинг мне привиделся.


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

C>>Что Вы от меня хотите услышать?


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


Да. Вашей фантазии хватает только на детские попытки цепляться к словам и переиначивать слова собеседника. Достаточно вспомнить про "словарным структурам" и приписанные мне, выдуманное вами в данной ветке.
Re[28]: Подсчёт ссылок
От: MxKazan Португалия  
Дата: 28.05.09 16:24
Оценка:
Здравствуйте, COFF, Вы писали:

COF>На самом деле я понимаю куда ты клонишь, определенный смысл в этом есть. Основное отличие, что в C++ ты создаешь shared_ptr и потом работаешь только с ним (одно место о котором стоит помнить — создание объекта), т.е. чтобы сделать как ты написал надо специально постараться. А в C# очень легко написать аналог a = b вместо a = b.Copy() (а присваивание может встречаться произвольное количество раз) и в этом случае весь подсчет ссылок идет лесом. В принципе, я это имел в виду. То, что при должной дисциплине проблем можно избежать, я не сомневаюсь. Так же, как впрочем, и при должной дисциплине можно легко избегать проблем с памятью и циклическими ссылками в C++.

А когда counter уменьшается? Не может случится, что я сошлюсь лишний раз и объект повиснет в памяти? Помнится когда-то я слышал аргумент в пользу сборщика мусора, мол, он помогает избежать проблем, связанных с циклическими ссылками, основанных на счетчиках.
Re[29]: Подсчёт ссылок
От: COFF  
Дата: 28.05.09 16:39
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>А когда counter уменьшается? Не может случится, что я сошлюсь лишний раз и объект повиснет в памяти? Помнится когда-то я слышал аргумент в пользу сборщика мусора, мол, он помогает избежать проблем, связанных с циклическими ссылками, основанных на счетчиках.


Может конечно, это надо специально разруливать — например использовать пару shared_ptr/weak_ptr
Re[33]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 16:46
Оценка:
Здравствуйте, drol, Вы писали:

ГВ>>Как раз таки — тип.

D>Неправда.

Я имел в виду именно тип самого члена класса.

MX>>>>И Вы ошибаетесь — в С++ метод может быть параметром шаблона:

D>>>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.
ГВ>>Where is a difference?
D>Вам неясна разница между указателем и тем на что он указывает ???

В терминах C++ метод нельзя передать как параметр иначе, чем в виде указателя.

D>Круто. И эти люди пишут на C++


О! В том, что я не понимаю, что такое указатель, меня ещё никто не обвинял.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[34]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 17:13
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>>>Как раз таки — тип.
D>>Неправда.
ГВ>Я имел в виду именно тип самого члена класса.
Оригинально. Ну тогда и свойства — тип.
Re[32]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 17:23
Оценка:
Здравствуйте, -MyXa-, Вы писали:

D>>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.

MX>Интересно послушать про тараканов.
Не переводи тему. Попался ведь

MX>И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.

Я не фига не понял эту фразу. Какие не типы по-чем совать generic зря? Что там нельзя в generic засунуть?
Re[33]: За что я не люблю С++
От: drol  
Дата: 28.05.09 17:42
Оценка:
Здравствуйте, MxKazan, Вы писали:

MX>>И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.

MK>Я не фига не понял эту фразу. Какие не типы по-чем совать generic зря?

Которые non-type. В C++ аргументом шаблона может быть не только тип, но и значение какого-то типа.
Re[34]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 17:47
Оценка:
Здравствуйте, drol, Вы писали:

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


MX>>>И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.

MK>>Я не фига не понял эту фразу. Какие не типы по-чем совать generic зря?
D>Которые non-type. В C++ аргументом шаблона может быть не только тип, но и значение какого-то типа.
Ааа.. понятно.
Re[35]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 17:50
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Здравствуйте, Геннадий Васильев, Вы писали:


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

ГВ>>>>Как раз таки — тип.
D>>>Неправда.
ГВ>>Я имел в виду именно тип самого члена класса.
MK>Оригинально. Ну тогда и свойства — тип.

Вот это как раз и интересно. Например, на C++ я могу написать функцию, которая будет требовать в качестве параметра именно "свойство". Примерно так:

void func(PropertyBase<int> *prop){ ... }


То есть на вход ей должно поступить именно свойство. И соответственно, могу сделать шаблон, предполагающий использование классов свойств:

template<typename Property_>
class Foo
{
  public:
    typedef typename Property_::value_type value_type;
    typedef typename Property_::host_type host_type;
};


И т.д. Короче говоря, могу обращаться со свойством, как с полноценным типом. На C#, насколько я знаю, так поступить нельзя (за исключением использования PropertyInfo, но это несколько иной механизм).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 17:56
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


MK>>Здравствуйте, Геннадий Васильев, Вы писали:


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

ГВ>>>>>Как раз таки — тип.
D>>>>Неправда.
ГВ>>>Я имел в виду именно тип самого члена класса.
MK>>Оригинально. Ну тогда и свойства — тип.

ГВ>Вот это как раз и интересно. Например, на C++ я могу написать функцию, которая будет требовать в качестве параметра именно "свойство". Примерно так:

Да пускай требует. Свойство от этого типом не становится.

ГВ>void func(PropertyBase<int> *prop){ ... }

Я в С++ не силен. Напиши как ты будешь это юзать.
Re[38]: Опечатка:
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 18:40
Оценка:
В примере test-case стоит запятая вместо точки с запятой:
bool bOK = false;
bool bCancel = false;

А то ещё подумаешь чего дурного.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[21]: Подсчёт ссылок
От: drol  
Дата: 28.05.09 19:12
Оценка:
Здравствуйте, Qbit86, Вы писали:

QВ> C# аналогом плюсового деструктора является метод Dispose() (а не финализатор, как думают некоторые),


Не соглашусь. В C#, как языке, нет прямого аналога деструкторам из C++. Их признаки распилены между финализаторами и реализацией соглашений по IDisposable.

Как и деструкторы в C++, финализаторы вызываются runtime'ом вне нормального контекста исполнения кода, и ограничены в том что могут безопасно делать "унутре". Dispose() выступает второй половиной — детерминированный вызов, в конкретном месте, в конкретное время.

Однако если посмотреть на дело с точки зрения логической организации работы с ресурсами, то именно финализатор аналог деструктора. Бо решает ту же проблему: забыли освободить ресурс нормальным образом.
Re[33]: За что я не люблю С++
От: -MyXa- Россия  
Дата: 28.05.09 20:28
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Здравствуйте, -MyXa-, Вы писали:


D>>>Ну какой же это метод ??? Это обычный указатель на член класса (pointer to member), со всеми своими дежурными тараканами.

MX>>Интересно послушать про тараканов.
MK>Не переводи тему. Попался ведь

MX>>И, если знаете, про то, почему не-типы нельзя в generic-и по-чём зря совать.

MK>Я не фига не понял эту фразу. Какие не типы по-чем совать generic зря? Что там нельзя в generic засунуть?

Своим "Попался ведь" попались Вы, MxKazan. Вы мало того, что не знаете, что такое template non-type parameter (как тут правильно подсказывают). Вы не понимаете, что нет контекста, в котором было бы важно — указатель там или не указатель. И, судя по тому, что Вы повелись на слова "pointer to member" (где на самом деле должно быть "pointer to member function"), поторопившись сказать "Не переводи тему", Вы просто не понимаете, что это одна тема, т.к. в данном случае "член класса" = метод. Велика беда указатель на метод! Очевидно, что мой код, в котором вызывается переданный метод, Вы не осилили тоже. Я так понимаю, Вы просто из группы поддержки — руками-ногами помахать, вклиниться в чужой разговор.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[22]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 20:39
Оценка:
Здравствуйте, drol, Вы писали:

D>Как и деструкторы в C++, финализаторы вызываются runtime'ом вне нормального контекста исполнения кода, и ограничены в том что могут безопасно делать "унутре". Dispose() выступает второй половиной — детерминированный вызов, в конкретном месте, в конкретное время.


D>Однако если посмотреть на дело с точки зрения логической организации работы с ресурсами, то именно финализатор аналог деструктора. Бо решает ту же проблему: забыли освободить ресурс нормальным образом.


using (StreamReader s = ...)
{

} // Dispose здесь «решает ту же проблему: забыли освободить ресурс нормальным образом.» ©

Финализатор в этом случае скорее всего даже не вызовется, если конкретная реализация стримридера грамотно реализует Dispose (с вызовом GC.SupressFinalize).
Глаза у меня добрые, но рубашка — смирительная!
Re[8]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 28.05.09 20:54
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>В некотором роде.


Re[8]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 28.05.09 20:54
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ткни в урл.


Re[5]: За что я не люблю С++
Автор: NikeByNike
Дата: 27.05.09
Re[38]: За что я не люблю С++
От: drol  
Дата: 28.05.09 21:00
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вариантов может быть много.


Это всё, конечно, очень интересно, но только причём здесь свойства-то ?

Ну наваяли Вы какую-то инфраструктуру, и что ? Частью языка она ведь от этого не стала. Обычные классы. На .NET/C# всё можно сделать аналогично, но только чуть лучше Бо есть свойства, и можно связать их с полученным framework'ом. Более того, такие вещи уже давно входят в комплект — в WPF и WF есть могучая конструкция DependencyProperty, например.
Re[34]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 21:07
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>Своим "Попался ведь" попались Вы, MxKazan. Вы мало того, что не знаете, что такое template non-type parameter (как тут правильно подсказывают). Вы не понимаете, что нет контекста, в котором было бы важно — указатель там или не указатель. И, судя по тому, что Вы повелись на слова "pointer to member" (где на самом деле должно быть "pointer to member function"), поторопившись сказать "Не переводи тему", Вы просто не понимаете, что это одна тема, т.к. в данном случае "член класса" = метод. Велика беда указатель на метод! Очевидно, что мой код, в котором вызывается переданный метод, Вы не осилили тоже. Я так понимаю, Вы просто из группы поддержки — руками-ногами помахать, вклиниться в чужой разговор.

Ну что я могу сказать. Если я действительно неправильно понял код, то виноват, да.
Re[35]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 21:30
Оценка:
Здравствуйте, drol, Вы писали:

ГВ>>>>Как раз таки — тип.

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

Ну, давай поделим. Тип значения свойства и тип объекта, представляющего собой свойство. Я говорю о типе объекта, представляющего собой свойство.

ГВ>>>>Where is a difference?

D>>>Вам неясна разница между указателем и тем на что он указывает ???
ГВ>>В терминах C++ метод нельзя передать как параметр иначе, чем в виде указателя.
D>Это личные проблемы C++. Разница между указателем и тем на что он указывает от этого не исчезает.

Очень смешно. И что?

Кстати, можешь предложить не-хакерский способ оперирования телом функции "по значению"?

D>>>Круто. И эти люди пишут на C++

ГВ>>О! В том, что я не понимаю, что такое указатель, меня ещё никто не обвинял.
D>Вы что-то путаете. Свои заблуждения Вы демонстрируете сами. Я тут совершенно непричём

А... Не забудь сказать, что я сел в лужу, проявил истинное ламерство и самое главное — не меньше трёх раз призвать меня признать своё поражение. Только это всё не в одном постинге, конечно, а так, в разбивку. В одном сообщении про лужу, в другом про ламерство. Одним словом, я в тебя верю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 21:43
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

ГВ>>Ткни в урл.

НС>Re[5]: За что я не люблю С++
Автор: NikeByNike
Дата: 27.05.09


Найк, вроде, со мной согласен.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 28.05.09 21:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>>>>>Как раз таки — тип.

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

ГВ>Ну, давай поделим. Тип значения свойства и тип объекта, представляющего собой свойство. Я говорю о типе объекта, представляющего собой свойство.

Блин. Я не въезжаю. Что это за тип такой, "представляющий свойство"? Т.е. ты берешь и объявляешь какой-то свой тип и говоришь, мол, оно есть свойство? Тогда можно в пример привести DependencyProperty
Re[29]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 28.05.09 22:02
Оценка:
Здравствуйте, Qbit86, Вы писали:

S>>А конструктором копирования обязательно нужно не забыть попользоваться.


Q>Вот не понимаю я этой фразы. Как так, не забыть?


Предположу, что имеется в виду, например, передача RefCounter<HugeBitmap> в качестве параметра метода:
void foo(RefCounter<HugeBitmap> hugeBitmap);

тогда вызывать её надо так:
using (RefCounter<HugeBitmap> hugeBitmap = new RefCounter<HugeBitmap>(new HugeBitmap()))
{
   foo(hugeBitmap.Clone()); // правильно
   //foo(hugeBitmap); // ошибка
}
Если не поможет, будем действовать током... 600 Вольт (C)
Re[39]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 22:14
Оценка:
Здравствуйте, drol, Вы писали:

ГВ>>Вариантов может быть много.

D>Это всё, конечно, очень интересно, но только причём здесь свойства-то ?

Меня спросили — я ответил.

D>Ну наваяли Вы какую-то инфраструктуру, и что ? Частью языка она ведь от этого не стала. Обычные классы. На .NET/C# всё можно сделать аналогично, но только чуть лучше Бо есть свойства, и можно связать их с полученным framework'ом. Более того, такие вещи уже давно входят в комплект — в WPF и WF есть могучая конструкция DependencyProperty, например.


DependencyProperty — это тоже самый обычный класс. Пример его привязки к классу-носителю показан прямо в MSDN:

public class MyStateControl : ButtonBase
{
  public MyStateControl() : base() { }
  public Boolean State
  {
    get { return (Boolean)this.GetValue(StateProperty); }
    set { this.SetValue(StateProperty, value); } 
  }
  public static readonly DependencyProperty StateProperty = DependencyProperty.Register(
    "State", typeof(Boolean), typeof(MyStateControl),new PropertyMetadata(false));
}


Читаем документацию дальше:

Dependency properties and the WPF property system extend property functionality by providing a type that backs a property, as an alternative implementation to the standard pattern of backing the property with a private field. The name of this type is DependencyProperty. The other important type that defines the WPF property system is DependencyObject. DependencyObject defines the base class that can register and own a dependency property.

Following is a summation of the terminology that is used in this software development kit (SDK) documentation when discussing dependency properties:

*Dependency property: A property that is backed by a DependencyProperty.
*Dependency property identifier: A DependencyProperty instance, which is obtained as a return value when registering a dependency property, and then stored as a member of a class. This identifier is used as a parameter in many of the APIs that interact with the WPF property system.
*CLR "wrapper": The actual get and set implementations for the property. These implementations incorporate the dependency property identifier by using it in the GetValue and SetValue calls, thus providing the backing for the property using the WPF property system.


Вот мы сейчас говорим на самом деле о том самом "set/get implementation". Хотя по сути мой пример со "сложным свойством" отдалённо перекликается с идеей DependencyProperty.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[40]: За что я не люблю С++
От: drol  
Дата: 28.05.09 22:26
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>DependencyProperty — это тоже самый обычный класс.


Про то и базар. Так вот ещё раз повторяю вопрос: причём тут свойства-то ? Они ведь как были, так и остались конструкцией языка, независимо от потрохов set/get. И все их полезные фичи никуда не делись.
Re[37]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 22:33
Оценка:
Здравствуйте, MxKazan, Вы писали:

ГВ>>Ну, давай поделим. Тип значения свойства и тип объекта, представляющего собой свойство. Я говорю о типе объекта, представляющего собой свойство.

MK>Блин. Я не въезжаю. Что это за тип такой, "представляющий свойство"?
MK>Т.е. ты берешь и объявляешь какой-то свой тип и говоришь, мол, оно есть свойство? Тогда можно в пример привести DependencyProperty

Похоже, но не совсем. DependencyProperty, это, приблизительно, HiddenSmartFunc из моего примера. Тогда как тип "представляющий свойство", это примерный аналог set/get wrapper-ов для экземпляра DependencyProperty. В моём примере "тип, представляющий свойство" — это ни что иное, как сам класс Property, у которого должны быть переопределены два оператора: оператор присвоения значения и оператор приведения к константной ссылке. Эти переопределения нужны для синтаксического сахара, т.е. чтобы можно было писать вот так:
obj.prop = 42;
int n = obj.prop;

а не так:
obj.prop.set(42);
int n = obj.prop.get();
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 22:39
Оценка:
Здравствуйте, -MyXa-, Вы писали:

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


S>>>А конструктором копирования обязательно нужно не забыть попользоваться.


Q>>Вот не понимаю я этой фразы. Как так, не забыть?


MX>Предположу, что имеется в виду, например, передача RefCounter<HugeBitmap> в качестве параметра метода:


Передача владения в метод — не такой уж частый случай. Скорее всего, на C++ ваша функция будет выглядеть так:
void foo(bitmap const& b);

а не так:
void foo(shared_ptr<bitmap> b);

или так:
void foo(shared_ptr<bitmap> const& b);

правда ведь? Ок, пусть надо передавать именно wrapper.

MX>using (RefCounter<HugeBitmap> hugeBitmap = new RefCounter<HugeBitmap>(new HugeBitmap()))

MX>{
MX> foo(hugeBitmap.Clone()); // правильно
MX> //foo(hugeBitmap); // ошибка
MX>}
MX>[/c#]

Похоже, всё-таки наоборот.
Глаза у меня добрые, но рубашка — смирительная!
Re[41]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 22:57
Оценка:
Здравствуйте, drol, Вы писали:

ГВ>>DependencyProperty — это тоже самый обычный класс.

D>Про то и базар. Так вот ещё раз повторяю вопрос: причём тут свойства-то ?

Ну как при чём? Марат (MxKazan) спросил, как я собираюсь пользоваться "отдельным типом, представляющим свойство". Я ответил.

D>Они ведь как были, так и остались конструкцией языка, независимо от потрохов set/get. И все их полезные фичи никуда не делись.


В C# — безусловно. В C++ нет языковой конструкции, в точности аналогичной C#-ным property. Но всё то же самое, что доступно свойствам C# вполне доступно и их эмуляции в C++. То есть с одной стороны мы получаем традиционный синтаксис операций присвоения и чтения значения (obj.prop = val и val = obj.prop), а с другой — можем скрыть за этими операциями всё, что захочется (полная аналогия с парой set/get).

Крме того, на C++, ИМХО, получается даже интереснее, чем на C#. Чем именно — я показал в своём примере с обобщением функции, оперирующей свойствами.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[10]: За что я не люблю С++
От: Ночной Смотрящий Россия  
Дата: 28.05.09 22:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

НС>>Re[5]: За что я не люблю С++
Автор: NikeByNike
Дата: 27.05.09


ГВ>Найк, вроде, со мной согласен.


И чего? Ты тоже считаешь, что он привел примеры "построения протокола обмена данными"? Не, в принципе я понимаю, что практически любые программистские задачи можно натянуть на этот самый протокол, аки презерватив на глобус, только тогда смысл исходной фразы полностью теряется.
Re[6]: За что я не люблю С++
От: Erop Россия  
Дата: 28.05.09 23:12
Оценка:
Здравствуйте, March_rabbit, Вы писали:

M_>а что, какой-нибудь мегаумный мегаязык способен провести сериализацию объекта с циклическими ссылками?

Это даже MFC умеет

M_>здорово, если так.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 28.05.09 23:13
Оценка:
Здравствуйте, drol, Вы писали:

D>using — это как раз тот самый "нормальный образ". От того что вызов Dispose() "вывалян в синтаксическом сахаре", он не перестаёт быть обычным вызовом метода в нормальном контексте исполнения кода.


D>Деструкторы и финализаторы же вызываются совсем другим макаром.


Финализаторы — да, совсем другим макаром. Но шарпные Dispose при выходе из using-скоупа семантически ведут себя почти так же, как и плюсовые деструкторы по выходу из области видимости переменной. (Не важно, как выходим из скоупа — добравшись до конца, выходя по return в середине или при возникновении исключения.) «Почти» — по тем причинам, что ты назвал. Так, например, Dispose(), будучи обычным методом, вполне может содержать вызовы виртуальных функций, и их поведение будет отличаться от вызова виртуальных функций в плюсовом деструкторе. Потому я и говорю об «аналоге» а не об «эквиваленте».
Глаза у меня добрые, но рубашка — смирительная!
Re[31]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 28.05.09 23:27
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, -MyXa-, Вы писали:


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


S>>>>А конструктором копирования обязательно нужно не забыть попользоваться.


Q>>>Вот не понимаю я этой фразы. Как так, не забыть?


MX>>Предположу, что имеется в виду, например, передача RefCounter<HugeBitmap> в качестве параметра метода:


Q>Передача владения в метод — не такой уж частый случай.

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

Q>Скорее всего, на C++ ваша функция будет выглядеть так:

Q>
void foo(bitmap const& b);


Скорее всего. никаких указателей, все жили долго и счастливо.

Q>а не так:

Q>
void foo(shared_ptr<bitmap> b);


Почему-же? Он хоть и умный, а всё-таки указатель. Легковесная штука, как итератор например, везде ходит по значению. Чем это отличается от
void foo(bitmap *); // угадай в каком напёрстке объект  :xz:

Q>или так:
Q>
void foo(shared_ptr<bitmap> const& b);

Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае, а букв больше. Всё одно, что:
void foo(bitmap * const&);

Q>правда ведь? Ок, пусть надо передавать именно wrapper.

MX>>using (RefCounter<HugeBitmap> hugeBitmap = new RefCounter<HugeBitmap>(new HugeBitmap()))

MX>>{
MX>> foo(hugeBitmap.Clone()); // правильно
MX>> //foo(hugeBitmap); // ошибка
MX>>}
MX>>[/c#]

Q>Похоже, всё-таки наоборот.


Почему-же? Создаём hugeBitmap, счётчик = 1.

в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using, который уменьшает счётчик; при выходе из foo счётчик = 1; using (внутри которого битмап создавался) вызывает Dispose, счётчик уменьшается до 0, убивается объект.

во втором случае: счётчик = 1; передаём в foo; в foo свой using, который уменьшает счётчик до 0, убивается объект; при выходе из foo счётчик = 0; пытаемся дальше работать с битмапом, а он не живой — пора палочкой его тыкать.

Правильно?
Если не поможет, будем действовать током... 600 Вольт (C)
Re[11]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 28.05.09 23:30
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

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


Ещё раз, медленно: Найк, вроде бы, со мной согласен. Другого источника информации у меня нет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: Подсчёт ссылок не получится!!!
От: Qbit86 Кипр
Дата: 28.05.09 23:48
Оценка:
Здравствуйте, Erop, Вы писали:

E>А в ХиндиСи придётся и пользователю объемлющего классу от использования значка = воздерживаться и т. д... ;)


Не придётся, значок по прежнему «=» удобен и всяко полезен. Разве что он право владения не даёт. Например, при передаче аргумента в функцию обработки шарить владение не надо, знай себе, передавай ссылку. Никаких накладных расходов вроде инкремента/декремента. Если же хочешь стать совладельцем (то есть заиметь право вызвать Dispose()) — будь добр, вызови метод.

E>Короче, IMHO? лучше в ХиндиСи парадигму COW не использовать...


Чем тебе стандартный System.String не COW?
Глаза у меня добрые, но рубашка — смирительная!
Re[31]: Подсчёт ссылок не получится!!!
От: Erop Россия  
Дата: 29.05.09 00:00
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Никаких накладных расходов вроде инкремента/декремента. Если же хочешь стать совладельцем (то есть заиметь право вызвать Dispose()) — будь добр, вызови метод.


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

E>>Короче, IMHO? лучше в ХиндиСи парадигму COW не использовать...

Q>Чем тебе стандартный System.String не COW?
А оно COW? Разве не GC? В любом случае момент освобождения ресурсов разве детерминирован?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[32]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 29.05.09 00:40
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>Статистикой не владею. А в С#, разве, передача владения в метод — не единственно возможный способ?


Ты это серьёзно? Ок, что по-твоему значит термин «владение»?

MX>Скорее всего. никаких указателей, все жили долго и счастливо.


Зачем передавать владение в функцию, которая, скажем, просто читает из твоего битмапа? Чтобы просто вернуть владение по выходу из функции? Эта функция вообще, может быть, разработана без знания о всяких boost::shared_ptr.

Q>>
void foo(shared_ptr<bitmap> b);

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

Инкремент/декремент на каждый вызов происходит.

Q>>
void foo(shared_ptr<bitmap> const& b);

MX>Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае...

Кому здесь передаётся владение?

MX>а букв больше.


Букв больше, да изменений счётчика меньше.

MX>>>using (RefCounter<HugeBitmap> hugeBitmap = new RefCounter<HugeBitmap>(new HugeBitmap()))

MX>>>{
MX>>> foo(hugeBitmap.Clone()); // правильно
MX>>> //foo(hugeBitmap); // ошибка
MX>>>}
MX>>>[/c#]

Q>>Похоже, всё-таки наоборот.

MX>Почему-же? Создаём hugeBitmap, счётчик = 1.
MX>в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using,

С какой целью в foo свой using? Ты предлагаешь захватывать ресурс во внешней функции (посредством Clone), а освободить его во внутренней (через Dispose посредством using)? Странные представления о дизайне.

MX>Правильно?


Нет. Либо в Foo есть и using, и hugeBitmap.Clone(), либо ни того, ни другого, что вероятнее. Для использования ресурса не обязательно разделять владение им.
Глаза у меня добрые, но рубашка — смирительная!
Re[32]: Подсчёт ссылок не получится!!!
От: Qbit86 Кипр
Дата: 29.05.09 00:45
Оценка:
Здравствуйте, Erop, Вы писали:

E>Вопрос не в накладных расходах, а в том, что тебе снаружи надо знать о том, что находится внутри... :xz:


Не нужно знать, что там внутри.

E>А оно COW? Разве не GC?


COW — это Copy-on-Write. GC — это Garbage Collector. Ты так построил фразу, будто считаешь COW и GC антонимами.

E>В любом случае момент освобождения ресурсов разве детерминирован?


Для строк — нет. Потому что у них нет других ресурсов, кроме управляемой памяти.
Глаза у меня добрые, но рубашка — смирительная!
Re[33]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 29.05.09 02:29
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, -MyXa-, Вы писали:


MX>>Статистикой не владею. А в С#, разве, передача владения в метод — не единственно возможный способ?


Q>Ты это серьёзно? Ок, что по-твоему значит термин «владение»?


Серьёзно ли я? Да я в зеркале себе не улыбаюсь.

Под владением я понимаю — "кто последний, тот и убирает". А если функция владеет объектом, это значит, что она это право может и передать. Или вот, например, если составные части объекта передают, якобы, на "посмотреть" в функцию, то, возможно, они ещё и переживут своего хозяина:
class почка
{
    public int value = 42;
}

class человек1
{
    public почка value = new почка();
}

class человек2
{
    public почка value = null;
}

static void foo(почка o, человек2 oo)
{
    oo.value = o; // заграбастали чужую часть, осталось только первоначального владельца замочить
}

static void Main(string[] args)
{
    человек1 o1 = new человек1();
    человек2 o2 = new человек2();
    foo(o1.value, o2);


В С# есть другие варианты?

MX>>Скорее всего. никаких указателей, все жили долго и счастливо.


Q>Зачем передавать владение в функцию, которая, скажем, просто читает из твоего битмапа? Чтобы просто вернуть владение по выходу из функции? Эта функция вообще, может быть, разработана без знания о всяких boost::shared_ptr.


Незачем. Даже звучит странно. Может.

Q>>>
void foo(shared_ptr<bitmap> b);

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

Q>Инкремент/декремент на каждый вызов происходит.


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

Q>>>
void foo(shared_ptr<bitmap> const& b);

MX>>Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае...

Q>Кому здесь передаётся владение?


Мало ли кому. Нам же отсюда не видно реализацию. Может foo их складирует куда-то.

MX>>а букв больше.


Q>Букв больше, да изменений счётчика меньше.


MX>>>>using (RefCounter<HugeBitmap> hugeBitmap = new RefCounter<HugeBitmap>(new HugeBitmap()))

MX>>>>{
MX>>>> foo(hugeBitmap.Clone()); // правильно
MX>>>> //foo(hugeBitmap); // ошибка
MX>>>>}
MX>>>>[/c#]

Q>>>Похоже, всё-таки наоборот.

MX>>Почему-же? Создаём hugeBitmap, счётчик = 1.
MX>>в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using,

Q>С какой целью в foo свой using? Ты предлагаешь захватывать ресурс во внешней функции (посредством Clone), а освободить его во внутренней (через Dispose посредством using)? Странные представления о дизайне.


Ровно такими же словами я удивлялся, году в 1999, глядя на одну небезызвестную библиотеку, имя которой превратилось в ругательство. Зачем, думал я, вот это всё делается, о чём Вы говорите. Там увеличили только для того, чтобы при выходе уменьшить. Идиотизм!
Ну, может и странные. А представьте, что у нас плюс ко всему есть ещё и контейнер. Тогда, может получиться, что "Функция foo, не владеющая объектом, прилетевшим к ней в виде параметра, передаёт право владения контейнеру". Технически — возможно, звучит — не красиво.

MX>>Правильно?


Q>Нет. Либо в Foo есть и using, и hugeBitmap.Clone(), либо ни того, ни другого, что вероятнее. Для использования ресурса не обязательно разделять владение им.


Извините, не понимаю — к чему Ваше "Нет", если дальше Вы пишете "Либо в Foo есть и using, и hugeBitmap.Clone()". Я Вам столько букв, а Вы мне — всего три (ну, спасибо, что хоть такие). Где я ошибся — ткните пальцем. Что значит "вероятнее"?

А так что вероятнее? —
foo(new RefCounter<HugeBitmap>(new HugeBitmap()));
Если не поможет, будем действовать током... 600 Вольт (C)
Re[32]: Подсчёт ссылок
От: Константин Б. Россия  
Дата: 29.05.09 03:16
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>Почему-же? Создаём hugeBitmap, счётчик = 1.


MX>в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using, который уменьшает счётчик; при выходе из foo счётчик = 1; using (внутри которого битмап создавался) вызывает Dispose, счётчик уменьшается до 0, убивается объект.


MX>во втором случае: счётчик = 1; передаём в foo; в foo свой using, который уменьшает счётчик до 0, убивается объект; при выходе из foo счётчик = 0; пытаемся дальше работать с битмапом, а он не живой — пора палочкой его тыкать.


MX>Правильно?


Ну уже если навешивать оберток так навешивать Х)

void foo(RefCounter<HugeBitmap> hugeBitmap)
{
    ...
    using (RefCounterScope scope = new RefCounterScope(hugeBitmap)) // Здесь счетчик увеличивается
    {
       ...
    } // Здесь уменьшается
    ...
}
Re[33]: Подсчёт ссылок не получится!!!
От: Erop Россия  
Дата: 29.05.09 03:38
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>COW — это Copy-on-Write. GC — это Garbage Collector. Ты так построил фразу, будто считаешь COW и GC антонимами.


А, понятно! Я просто привык к такой терминологии, что COW подразумевает совместное владение со счётчиком...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[36]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.05.09 05:04
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>И т.д. Короче говоря, могу обращаться со свойством, как с полноценным типом. На C#, насколько я знаю, так поступить нельзя (за исключением использования PropertyInfo, но это несколько иной механизм).
Тебе шашечки или ехать?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 29.05.09 06:59
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>Под владением я понимаю — "кто последний, тот и убирает". А если функция владеет объектом, это значит, что она это право может и передать. Или вот, например, если составные части объекта передают, якобы, на "посмотреть" в функцию, то, возможно, они ещё и переживут своего хозяина:

MX>[Code skipped.]
MX>В С# есть другие варианты?

Здесь нет ни передачи владения, ни его разделения. Здесь на одну почку ссылаются два человека. Если любой из них умрёт и вызовет Dispose() для себя и подобъектов, то у другого будет невалидная почка.

Q>>Инкремент/декремент на каждый вызов происходит.

MX>Да, но за то мы получаем возможность не знать когда именно объект уничтожится.

Если ты передаёшь boost::shared_ptr по ссылке, то ты тоже этого не знаешь, и при этом у тебя лишний инкремент/декремент не произойдёт. В который раз я это уже повторяю?

Q>>>>
void foo(shared_ptr<bitmap> const& b);

MX>>>Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае...
Q>>Кому здесь передаётся владение?
MX>Мало ли кому. Нам же отсюда не видно реализацию. Может foo их складирует куда-то.

При передаче shared_ptr'а по значению создаётся ещё один совладелец — локальный параметр функции. Вызывается копиктор и инкремент для shared_ptr'а, о чём недвусмысленно свидетельствует use_count(). Здесь же — передача shared_ptr'а по ссылке, дополнительных совладельцев не создаётся, владение не шарится. Так-то.

MX>>>Правильно?

Q>>Нет. Либо в Foo есть и using, и hugeBitmap.Clone(), либо ни того, ни другого, что вероятнее. Для использования ресурса не обязательно разделять владение им.
MX>Извините, не понимаю — к чему Ваше "Нет", если дальше Вы пишете "Либо в Foo есть и using, и hugeBitmap.Clone()". Я Вам столько букв, а Вы мне — всего три (ну, спасибо, что хоть такие). Где я ошибся — ткните пальцем.

void foo(RefCounter<HugeBitmap h)
{
  using (h)
  {
    // Использование h.
  }
}
...
foo(hugeBitmap.Clone());

Такого в природе не бывает. Это всё равно что в плюсовую функцию передать «new int(42)» и внутри сделать «delete p».

MX>Что значит "вероятнее"?


void foo(RefCounter<HugeBitmap h)
{
  // Использование h, быть может даже клонирование при необходимости.
}
Глаза у меня добрые, но рубашка — смирительная!
Re[31]: Подсчёт ссылок
От: COFF  
Дата: 29.05.09 07:12
Оценка:
Здравствуйте, MxKazan, Вы писали:

COF>>Может конечно, это надо специально разруливать — например использовать пару shared_ptr/weak_ptr

MK>Вот знаешь, почему хорошо, что в C# нет перегрузки присваивания? Как раз чтобы голова не занималась подсчетом этих операцией или выбором вида указателей. А еще ведь надо будет глядеть не перекрыт ли оператор присваивания, а то мало ли чего на самом деле делается. В C# я всегда знаю, что a = b — есть только копирование указателя в случае ссылочного типа и копирование значения в случае value-типа. Всё четко и ясно. По-моему, это плюс.

По моему, если бы был язык, который поддерживает и сборку мусора и детерминированное освобождение ресурсов, то я бы первый сказал, что этот язык может быть лучше чем C++, а сейчас я могу только повторить, что они разные
Re[24]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 29.05.09 08:51
Оценка:
M> M>Лучше, если эти пять строк уже встроены в язык

M> осторожно! Можно ведь и захотеть декодер mpc поиметь встроенный в язык


Пусть будет

M> Ограничивать себя в сладостях надо


Зачем?
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[28]: Подсчёт ссылок
От: Eugeny__ Украина  
Дата: 29.05.09 09:16
Оценка:
Здравствуйте, Sinclair, Вы писали:


S>
S>public static void EpicFail(HugeBitmap bmp)
S>{
S>  RefCounter<HugeBitmap> c;
S>  using(var a = new RefCounter<HugeBitmap>(bmp)); // bmp.refCount++;
S>    {
S>      var b = new RefCounter(a); // bmp.refCount++
S>      c = a; // oops... вот в этот момент С++ инкрементирует указатель. С# - нет.
S>    b.Dispose(); //bmp.refCount-- 
S>    } // bmp.refCount-- => bmp.Release()
S>    c.Reference.Draw(); // InvalidOperationException!
S>}
S>




Я чего-то не понимаю, на кой вообще битмапу(который, по сути, тупо массив байт, вполне себе менеджед, а значит, подвластен GC(или в шарпе это не так? Я только про джаву знаю достоверно)) Release? Не нужен — просто обнуляешь все ссылки на него, пусть сборщик сам разбирается, он прекрасно увидит, что есть крупный массив байт, и на него нету ссылок ни у одного из потоков, и соберет его, когда память начнет кончаться. Зачем вообще эти пляски с бубном?
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[25]: За что я не люблю С++
От: Константин Б. Россия  
Дата: 29.05.09 09:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Ответь мне на один наводящий вопрос: а что дальше делать с этой сгенерированной и полностью новой структурой?
S>Ну хорошо. Пусть это будет не совсем новая структура.
S>Пусть это будет, скажем, наследник некоего известного интерфейса. Впрочем, нет — этого нам недостаточно. Потребуется еще какая-то функция со стандартной сигнатурой.
S>Скажем,
S>
S>IStandardObject factory()
S>

S>Насколько практично порождать новый код такого рода на С++? К примеру, если у меня есть регулярное выражение — сколько вызовов Match() на нескомпилированном выражении скомпенсируют стоимость компиляции выражения? Тысяча? Миллион?

А насколько практичен в этом отношении Reflection.Emit?
Re[2]: За что я не люблю С++
От: Qbit86 Кипр
Дата: 29.05.09 10:09
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Статью не читал


И правильно сделал. Бог с ними, с притянутыми за уши кривостями и ламеризмами типа «шаблоны — это те же макросы». Но такое обилие дурацких смайликов, инфантильных серийных восклицательных знаков и полное пренебрежения правилами типографики — это не «статья», а так, пост в жэжэшечке. Ну или на narod.ru, ага. Серьёзно относиться к такого рода писулькам — много им чести.

PD>Вот представьте себе — исчез он. Чем замените ?


Если бы это сборище костылей с 1K-страничным стандартом исчезло, это послужило бы толчком к появлению и развитию более удачных низкоуровневых языков. Современные компиляторы с C++ выдают эффективный код не благодаря языку C++, а вопреки. Создать компилятор C++ чрезвычайно трудно, причём это не столько объективная трудность, сколько борьба с тёмными углами языка.
Глаза у меня добрые, но рубашка — смирительная!
Re[26]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.05.09 10:10
Оценка:
Здравствуйте, Константин Б., Вы писали:
КБ>А насколько практичен в этом отношении Reflection.Emit?
Ну... На моей тачке регексы компиляются со скоростью около 1E-5 секунды на символ.
То есть для типичных регекспов длиной в сотню символов речь идет об 1й миллисекунде задержки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Подсчёт ссылок
От: Erop Россия  
Дата: 29.05.09 10:45
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Ключевое выделено. Парням из банды С++ хочется, чтобы объект собрался не когда память начнет кончаться, а именно когда не будет ссылок. И еще такой момент: текущая реализации битмапа в Windows Forms — это таки нативный хэндл ОС, в котором GC не властен.


Да и вообще, а вдруг он в видеопамяти живёт? Или прога не битмапами управляет а кудовыми заданиями на рассчёт, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[32]: cli? ;) (-)
От: Erop Россия  
Дата: 29.05.09 10:46
Оценка:
Здравствуйте, COFF, Вы писали:

COF>По моему, если бы был язык, который поддерживает и сборку мусора и детерминированное освобождение ресурсов, то я бы первый сказал, что этот язык может быть лучше чем C++, а сейчас я могу только повторить, что они разные
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[3]: За что я не люблю С++
От: COFF  
Дата: 29.05.09 10:46
Оценка:
Здравствуйте, Qbit86, Вы писали:

PD>>Вот представьте себе — исчез он. Чем замените ?


Q>Если бы это сборище костылей с 1K-страничным стандартом исчезло, это послужило бы толчком к появлению и развитию более удачных низкоуровневых языков. Современные компиляторы с C++ выдают эффективный код не благодаря языку C++, а вопреки. Создать компилятор C++ чрезвычайно трудно, причём это не столько объективная трудность, сколько борьба с тёмными углами языка.


Я согласен, что C++ не самый легкий и прямой язык. Но с другой стороны, все это вызвано вполне естественными причинами. Начни разрабатывать подобный язык с нуля, то в итоге либо C++ и получится (так как скажем копирование объекта из одного места в памяти так и останется копированием, соответственно срезка никуда не денется, ну и так далее по всем проблемным местам), либо он будет красивый и стройный, но абсолютно неприменимый в реальных проектах. Сила (и слабость) C++ в том, что он результат более чем тридцатилетней эволюции (если и C тоже считать). Посмотрим во что через двадцать лет превратится C#
Re[39]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.05.09 10:51
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Когда у тебя в руках молоток — всё кажется гвоздями. Когда С++ — всё кажется классами. Оказывается, не обязательно быть классом для того, чтобы успешно работать.


Добавим тривиальное усложнение в функцию управления Enabled:

// Где-то в недрах:
if (bOK) { ... }


Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: Подсчёт ссылок
От: MxKazan Португалия  
Дата: 29.05.09 11:05
Оценка:
Здравствуйте, Erop, Вы писали:

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


MK>>Ключевое выделено. Парням из банды С++ хочется, чтобы объект собрался не когда память начнет кончаться, а именно когда не будет ссылок. И еще такой момент: текущая реализации битмапа в Windows Forms — это таки нативный хэндл ОС, в котором GC не властен.

E>Да и вообще, а вдруг он в видеопамяти живёт? Или прога не битмапами управляет а кудовыми заданиями на рассчёт, например?
Это к чему?
Re[5]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 11:35
Оценка:
Здравствуйте, Qbit86, Вы писали:

COF>>Посмотрим во что через двадцать лет превратится C#

Q>Через двадцать лет он скорее всего благополучно преставится, и никто не станет по нему особо сокрушаться. Потому что на смену придут более удачные и удобные инструменты.

А плюсы, в каком-то виде, продолжат таки небо коптить
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 29.05.09 12:13
Оценка:
Здравствуйте, COFF, Вы писали:

COF>Я согласен, что C++ не самый легкий и прямой язык. Но с другой стороны, все это вызвано вполне естественными причинами. Начни разрабатывать подобный язык с нуля, то в итоге либо C++ и получится (так как скажем копирование объекта из одного места в памяти так и останется копированием, соответственно срезка никуда не денется, ну и так далее по всем проблемным местам), либо он будет красивый и стройный, но абсолютно неприменимый в реальных проектах. Сила (и слабость) C++ в том, что он результат более чем тридцатилетней эволюции (если и C тоже считать). Посмотрим во что через двадцать лет превратится C#


А вот с этим не соглашусь.

Если из C# оставить ту часть, что более или менее совпадает по возможностям с С++ (то есть минус Linq и т.п.), убрать всю эту самую управляемость, легализовать unsafe (точнее, сделать все unsafe) — будет лучше. C# вообще по синтаксису бесспорно лучше, да иначе и быть не могло — как можно было спустя два десятилетия сделать хуже!

В общем, был бы unmanaged — unsafe C# — я бы его предпочел.
Или Java, но там указатели вернуть сложно.
With best regards
Pavel Dvorkin
Re[41]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.05.09 12:21
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Добавим тривиальное усложнение в функцию управления Enabled:

S>Ничего военного.

Ну, я не сомневался, что похожее решение можно получить и на C#. ИМХО, только одно существенное отличие: на C++ не нужно вводить промежуточной абстракции для того, чтобы унифицировать работу со значениями и с объектами, перекрывающими операторы присвоения/получения ссылки. Понятно, что и там и там есть свои плюсы и минусы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[8]: За что я не люблю С++
От: Qbit86 Кипр
Дата: 29.05.09 12:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я, конечно, дико извиняюсь, но можно поподробнее про теплый ламповый звук ? :-). У меня лампы звук иногда издают, когда перегорают, но теплым и ласковым я бы этот звук не назвал. :-)


Подробнее:
«Аудиофилы с высоким уровнем ФГМ скажут вам, что они не признают транзисторные приборы из-за того, что они искажают сигнал, несмотря на то, что фиксируемые приборами искажения у транзисторных приборов меньше во много раз.»
«Вы всерьез думаете, что в эпоху цифрового звука восприятие человека изменилось и его организм не в состоянии отличить комфортный теплый ламповый звук от холодного-технического цифрового?.. Сравнивать ламповый и цифровой звук — это все равно как сравнивать Солнце, дающее нам жизнь, и солярий, поджаривающий клетки нашей кожи до коричневатового цвета, чем-то напоминающего настоящий загар! ;) Поэтому мы выбираем настоящий звук — а не суррогат!»
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: А я вот, например жену люблю, а к языкам равнодушен ;
От: Erop Россия  
Дата: 29.05.09 12:31
Оценка:
Здравствуйте, Qbit86, Вы писали:

E>>А написать что-то такое сложно-умное, много насилующее память и процессор, то тут уже ХиндиС не тянет.


Q>«Насилование памяти и процессора» к «сложно-умному» не имеет никакого отношения. «У нас в студии это называется „пидарасить пиксели“ или „тихановщина“. Вообще, я дизайнерам запрещаю это делать.» (© Некий Артемий Л.) В нашем случае это надо назвать «пидарасить байты или такты процессора». Работа иногда нужная, и порой весьма полезная. Как, например, работа ассинезатора. Но гордиться тут нечем. «Сложно-умное» как раз-таки делается на адекватных высокоуровневых языках. А «грязно-рутинную оптимизацию» можно и на C†† каком-нибудь. (Но не нужно.)


1) мат тут запрещён.
2) Я вообще-то не понимаю, от чего ты считаешь, что ресурсоёмкие приложения обязательно простые...
Вот два самых ресурсоёмких из тех что пользуюсь я -- это Photoshop и FineReader...
Во-первых оба писаны на неуправляемых языках вроде. Во вторых я не скажу что то или другое неумное...

Но я ещё призываю таки в таком русле продолжать тут
Автор: Erop
Дата: 29.05.09
...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: Слова, золотые, как загар!!! ;)
От: Erop Россия  
Дата: 29.05.09 12:33
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>«Вы всерьез думаете, что в эпоху цифрового звука восприятие человека изменилось и его организм не в состоянии отличить комфортный теплый ламповый звук от холодного-технического цифрового?.. Сравнивать ламповый и цифровой звук — это все равно как сравнивать Солнце, дающее нам жизнь, и солярий, поджаривающий клетки нашей кожи до коричневатового цвета, чем-то напоминающего настоящий загар! Поэтому мы выбираем настоящий звук — а не суррогат!»


Вот!!! Золотые слова!!! ХиндиС -- это СУРОГАТ!!!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[5]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 12:34
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>В общем, был бы unmanaged — unsafe C# — я бы его предпочел.

PD>Или Java, но там указатели вернуть сложно.

Можно, кстати, фронтэнды к плюсам пробовать приписывать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 29.05.09 12:42
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>«Аудиофилы с высоким уровнем ФГМ скажут вам, что они не признают транзисторные приборы из-за того, что они искажают сигнал, несмотря на то, что фиксируемые приборами искажения у транзисторных приборов меньше во много раз.»

Q>«Вы всерьез думаете, что в эпоху цифрового звука восприятие человека изменилось и его организм не в состоянии отличить комфортный теплый ламповый звук от холодного-технического цифрового?.. Сравнивать ламповый и цифровой звук — это все равно как сравнивать Солнце, дающее нам жизнь, и солярий, поджаривающий клетки нашей кожи до коричневатового цвета, чем-то напоминающего настоящий загар! Поэтому мы выбираем настоящий звук — а не суррогат!»

Все ясно. Не относясь с аудиофилам и не имея понятия, что такое ФГМ, все же иду искать свой старый ламповый приемник и граммофон с пластинками.
With best regards
Pavel Dvorkin
Re[11]: Слова, золотые, как загар!!! ;)
От: Erop Россия  
Дата: 29.05.09 12:44
Оценка:
Здравствуйте, Qbit86, Вы писали:

E>>Вот!!! Золотые слова!!! ХиндиС -- это СУРОГАТ!!!

Q>«Вы говорите об этом так, как будто это что-то плохое.»

Разве?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 29.05.09 12:48
Оценка:
Здравствуйте, NikeByNike, Вы писали:

NBN>Я абстрагировался до определённого уровня, на котором сериализация стала протоколом обмена данными одной структуры данных с другой

NBN>Т.е. превращение какой-то сложной структуры данных в другое представление (хмл, бинарный формат, трансформированная структура данных, та же самая структура данных с шарингом нужных данных, опять же сетевой протокол реализовался силами той же реализации сериализации).
NBN>Вопрос в том — кто до какого уровня абстрагировался

Я примерно так и понял, ждал только твоей реакции. Пожалуй, что я малость перегнул палку, говоря именно о протоколах обмена данными. Поясню в чём дело. Я, когда употребил этот термин, имел в виду такое явление, которое сопровождается артефактом "версия протокола", вокруг которой, в свою очередь, обычно накручено много дополнительной работы — анализа, обсуждений, бюрократии и т.п. Понятно, что если мы говорим о простой передаче данных с машины на машину в рамках внутреннего проекта, то всё это тоже есть, но не в "острой форме". Здесь, действительно, может оказаться более заметным сугубое "удобство сериализации произвольных объектов".

Хотя, как ни крути, а всё равно сериализация лучше всего подходит для передачи данных за пределы адресного пространства процесса, на то она и сериализация. Хотя можно, конечно, и внутри процесса таким образом данные перегонять, иной раз — удобно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[6]: А я вот, например жену люблю, а к языкам равнодушен ;
От: Erop Россия  
Дата: 29.05.09 13:14
Оценка:
Здравствуйте, Qbit86, Вы писали:


Q>За мат (хоть он исходил не от меня, а из цитаты) готов извиниться.

E>>2) Я вообще-то не понимаю, от чего ты считаешь, что ресурсоёмкие приложения обязательно простые...

Это ты модерам в бане расскажешь

Q>Аналогично, я не понимаю, почему ты считаешь, что программисты на C# — это недоученный быдлоиндусы.

Разве? Я так не считаю. Я считаю совсем другое. Что C# -- настолько классный язык, что на нём могут прогать и индусы

Q>У меня противоположный опыт общения с шарпистами и плюсистами. Первые, как правило, неплохо разбираются и в плюсах, потому что имеют соответствующий background, посему более критичны в суждениях. Вторые, как правило, воинствующие снобы, считающие владение плюсовыми аббревиатурами типа SFINAE или CRTP мерилом умения программировать.


Ну не повезло тебе, или, наоборот, повезло... Не знаю...
В любом случае -- зачем обобщать-то?

Q>Там вроде какой-то опрос предлагается, я не в курсе. Дело в том, что я не читаю текст, чрезмерно изобилующий значками «☺» и «!!!» Так что «в таком русле продолжать» — это без меня.

Не волнуйся, ты там со своими "цитатами" и "ассенизаторами" вполне органичен будешь
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[30]: Подсчёт ссылок
От: Eugeny__ Украина  
Дата: 29.05.09 13:32
Оценка:
Здравствуйте, MxKazan, Вы писали:

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


E__>>Я чего-то не понимаю, на кой вообще битмапу(который, по сути, тупо массив байт, вполне себе менеджед, а значит, подвластен GC(или в шарпе это не так? Я только про джаву знаю достоверно)) Release? Не нужен — просто обнуляешь все ссылки на него, пусть сборщик сам разбирается, он прекрасно увидит, что есть крупный массив байт, и на него нету ссылок ни у одного из потоков, и соберет его, когда память начнет кончаться. Зачем вообще эти пляски с бубном?

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

А смысл?

MK>И еще такой момент: текущая реализации битмапа в Windows Forms — это таки нативный хэндл ОС, в котором GC не властен.


А вот это меняет дело. Я никогда в шарпе с картинками не работал, потому не в курсе. В жабе классы-контейнеры изображений полностью managed, там такой проблемы нет(имеется ввиду стандартный Swing, не SWT).
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[35]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 29.05.09 13:56
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, -MyXa-, Вы писали:


MX>>Под владением я понимаю — "кто последний, тот и убирает". А если функция владеет объектом, это значит, что она это право может и передать. Или вот, например, если составные части объекта передают, якобы, на "посмотреть" в функцию, то, возможно, они ещё и переживут своего хозяина:

MX>>[Code skipped.]
MX>>В С# есть другие варианты?

Q>Здесь нет ни передачи владения, ни его разделения. Здесь на одну почку ссылаются два человека. Если любой из них умрёт и вызовет Dispose() для себя и подобъектов, то у другого будет невалидная почка.


К чему Вы тут говорите про Dispose? Я код привёл полностью, где Вы его там видите?. _Просто_ "ссылаются два человека" и ни один не владеет? ЗдОрово! Ну-ка, покажите мне — как уничтожить, в таком случае, почку по полной программе (и я опять не имею в виду Dispose, потому, что он — не уничтожение)? Короче, нет никакого способа в C# передать поле (вообще объект) в метод, не передав владения. Так и запишем.

Q>>>Инкремент/декремент на каждый вызов происходит.

MX>>Да, но за то мы получаем возможность не знать когда именно объект уничтожится.

Q>Если ты передаёшь boost::shared_ptr по ссылке, то ты тоже этого не знаешь, и при этом у тебя лишний инкремент/декремент не произойдёт. В который раз я это уже повторяю?


Инкремент/декремент не может быть лишним.
Я не знаю, зачем вы это повторяете. Я никогда boost::shared_ptr по ссылке не передаю. А Вы?

Q>>>>>
void foo(shared_ptr<bitmap> const& b);

MX>>>>Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае...
Q>>>Кому здесь передаётся владение?
MX>>Мало ли кому. Нам же отсюда не видно реализацию. Может foo их складирует куда-то.

Q>При передаче shared_ptr'а по значению создаётся ещё один совладелец — локальный параметр функции. Вызывается копиктор и инкремент для shared_ptr'а, о чём недвусмысленно свидетельствует use_count(). Здесь же — передача shared_ptr'а по ссылке, дополнительных совладельцев не создаётся, владение не шарится. Так-то.


И где экономия?
void foo(shared_ptr<bitmap> const& b)
{
   shared_ptr<bitmap> b_ = b;
   ...
}


MX>>>>Правильно?

Q>>>Нет. Либо в Foo есть и using, и hugeBitmap.Clone(), либо ни того, ни другого, что вероятнее. Для использования ресурса не обязательно разделять владение им.
MX>>Извините, не понимаю — к чему Ваше "Нет", если дальше Вы пишете "Либо в Foo есть и using, и hugeBitmap.Clone()". Я Вам столько букв, а Вы мне — всего три (ну, спасибо, что хоть такие). Где я ошибся — ткните пальцем.

Q>
Q>void foo(RefCounter<HugeBitmap h)
Q>{
Q>  using (h)
Q>  {
Q>    // Использование h.
Q>  }
Q>}
Q>...
Q>foo(hugeBitmap.Clone());
Q>

Q>Такого в природе не бывает. Это всё равно что в плюсовую функцию передать «new int(42)» и внутри сделать «delete p».

А какие проблемы с этим?

MX>>Что значит "вероятнее"?


Q>
Q>void foo(RefCounter<HugeBitmap h)
Q>{
Q>  // Использование h, быть может даже клонирование при необходимости.
Q>}
Q>


"Может быть даже клонирование"! Потрясающе! И чему будет равен стётчик? В каком случае необходимость клонирования?

Имея:
string DecodeCAPTCHA(RefCounter<HugeBitmap> h) // От Вашего варианта отличается только отсутствием опечатки, именем метода и возвращаемым значением.
{
  // Использование h, быть может даже клонирование при необходимости.
}


Нельзя написать так:
string s = DecodeCAPTCHA(new RefCounter<HugeBitmap>(new HugeBitmap("...")));

Или Вы сможете убедить других специалистов в С#, что так писать — не правильно? Думаю, они будут рады таким замечательным граблям.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[33]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 29.05.09 14:00
Оценка:
Здравствуйте, Константин Б., Вы писали:

КБ>Здравствуйте, -MyXa-, Вы писали:


MX>>Почему-же? Создаём hugeBitmap, счётчик = 1.


MX>>в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using, который уменьшает счётчик; при выходе из foo счётчик = 1; using (внутри которого битмап создавался) вызывает Dispose, счётчик уменьшается до 0, убивается объект.


MX>>во втором случае: счётчик = 1; передаём в foo; в foo свой using, который уменьшает счётчик до 0, убивается объект; при выходе из foo счётчик = 0; пытаемся дальше работать с битмапом, а он не живой — пора палочкой его тыкать.


MX>>Правильно?


КБ>Ну уже если навешивать оберток так навешивать Х)


КБ>
КБ>void foo(RefCounter<HugeBitmap> hugeBitmap)
КБ>{
КБ>    ...
КБ>    using (RefCounterScope scope = new RefCounterScope(hugeBitmap)) // Здесь счетчик увеличивается
КБ>    {
КБ>       ...
КБ>    } // Здесь уменьшается
КБ>    ...
КБ>}
КБ>


Дык, об чём прямая речь! Другой способ есть?
Если не поможет, будем действовать током... 600 Вольт (C)
Re[31]: Подсчёт ссылок
От: MxKazan Португалия  
Дата: 29.05.09 14:04
Оценка:
Здравствуйте, Eugeny__, Вы писали:

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

MK>>Здравствуйте, Eugeny__, Вы писали:
E__>>>Я чего-то не понимаю, на кой вообще битмапу(который, по сути, тупо массив байт, вполне себе менеджед, а значит, подвластен GC(или в шарпе это не так? Я только про джаву знаю достоверно)) Release? Не нужен — просто обнуляешь все ссылки на него, пусть сборщик сам разбирается, он прекрасно увидит, что есть крупный массив байт, и на него нету ссылок ни у одного из потоков, и соберет его, когда память начнет кончаться. Зачем вообще эти пляски с бубном?
MK>>Ключевое выделено. Парням из банды С++ хочется, чтобы объект собрался не когда память начнет кончаться, а именно когда не будет ссылок.
E__>А смысл?
Привычка

MK>>И еще такой момент: текущая реализации битмапа в Windows Forms — это таки нативный хэндл ОС, в котором GC не властен.

E__>А вот это меняет дело. Я никогда в шарпе с картинками не работал, потому не в курсе. В жабе классы-контейнеры изображений полностью managed, там такой проблемы нет(имеется ввиду стандартный Swing, не SWT).
Сейчас в WPF тоже появился свой битмап, управляемый. А по поводу битмапов в WinForms вопрос интересный. Анализирует ли сборщик объем памяти в целом для процесса, неважно как выделенную, или же только свою управляемую кучу? В первом случае всё ништяк, во втором наверное, придется подождать... Но я точно не скажу, не силен в этом вопросе.
Re[34]: Подсчёт ссылок
От: MxKazan Португалия  
Дата: 29.05.09 14:17
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>Дык, об чём прямая речь! Другой способ есть?

А, об чём? Я вот читаю и всё никак понять не могу: какую задачу то решаем?
Re[35]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 29.05.09 14:24
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Здравствуйте, -MyXa-, Вы писали:


MX>>Дык, об чём прямая речь! Другой способ есть?

MK>А, об чём? Я вот читаю и всё никак понять не могу: какую задачу то решаем?

Хотим, чтобы сам вызвался какой-нибудь метод (к примеру, Dispose) сразу, как только ссылок на данный объект не останется.
Если не поможет, будем действовать током... 600 Вольт (C)
Re[34]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 29.05.09 14:29
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>Здравствуйте, Константин Б., Вы писали:


КБ>>Здравствуйте, -MyXa-, Вы писали:


MX>>>Почему-же? Создаём hugeBitmap, счётчик = 1.


MX>>>в первом случае: клонируем RefCounter, счётчик = 2; передаём в foo; в foo свой using, который уменьшает счётчик; при выходе из foo счётчик = 1; using (внутри которого битмап создавался) вызывает Dispose, счётчик уменьшается до 0, убивается объект.


MX>>>во втором случае: счётчик = 1; передаём в foo; в foo свой using, который уменьшает счётчик до 0, убивается объект; при выходе из foo счётчик = 0; пытаемся дальше работать с битмапом, а он не живой — пора палочкой его тыкать.


MX>>>Правильно?


КБ>>Ну уже если навешивать оберток так навешивать Х)


КБ>>
КБ>>void foo(RefCounter<HugeBitmap> hugeBitmap)
КБ>>{
КБ>>    ...
КБ>>    using (RefCounterScope scope = new RefCounterScope(hugeBitmap)) // Здесь счетчик увеличивается
КБ>>    {
КБ>>       ...
КБ>>    } // Здесь уменьшается
КБ>>    ...
КБ>>}
КБ>>


MX>Дык, об чём прямая речь! Другой способ есть?


Ой, нет, я ошибся. И с Вами не согласен. new — не нужен потому, что

foo(new RefCounter<HugeBitmap>(new HugeBitmap()));
Если не поможет, будем действовать током... 600 Вольт (C)
Re[27]: За что я не люблю С++
От: Константин Б. Россия  
Дата: 29.05.09 14:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Константин Б., Вы писали:

КБ>>А насколько практичен в этом отношении Reflection.Emit?
S>Ну... На моей тачке регексы компиляются со скоростью около 1E-5 секунды на символ.
S>То есть для типичных регекспов длиной в сотню символов речь идет об 1й миллисекунде задержки.

Ну чтож. Попробую сделать компилятор регекспов на LLVM. Посмотрим сколько оно выдаст.
Re[5]: За что я не люблю С++
От: COFF  
Дата: 29.05.09 16:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

PD>>ПО с серьезными расчетами.

G>Пока вы будете писать их на С++, вариант на F# уже давно все посчитает.

Ага, а потом захочется посчитать на каком-нибудь линуксовом мегакластере. Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно
Re[6]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 29.05.09 16:48
Оценка:
Здравствуйте, COFF, Вы писали:

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


PD>>>ПО с серьезными расчетами.

G>>Пока вы будете писать их на С++, вариант на F# уже давно все посчитает.

COF>Ага, а потом захочется посчитать на каком-нибудь линуксовом мегакластере.

Уууу, много ты таких видел?

COF>Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно

Мегакластер на плюсах? Плюсов там и не будет, голый C.
Re[36]: Подсчёт ссылок
От: Юрий Жмеренецкий ICQ 380412032
Дата: 29.05.09 19:56
Оценка:
Здравствуйте, -MyXa-, Вы писали:
...
MX>Я не знаю, зачем вы это повторяете. Я никогда boost::shared_ptr по ссылке не передаю.

Q>>>>>>
void foo(shared_ptr<bitmap> const& b);

MX>>>>>Сомнительно. Зачем такой огород? Владение всё равно передаётся, как и во втором случае...
...
MX>И где экономия?
MX>
MX>void foo(shared_ptr<bitmap> const& b)
MX>{
MX>   shared_ptr<bitmap> b_ = b;
MX>   ...
MX>}
MX>


При передаче по значению имеет место быть раздутие кода из-за инлайна. Конкретные цифры и степень важности этого — другой вопрос.
Re[5]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 21:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Ничему из этого нативность не нужна.

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

WH>Тут дело лишь в качестве оптимизатора и ни в чем больше.

Да не только. Дело вообще в контроле над компом...

Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 29.05.09 21:12
Оценка:
Здравствуйте, Erop, Вы писали:

E>Ну да понятно, что при желании можно и на ХиндиС всё написать, только будет либо тормозить, либо прийдётся сильно код оптимизировать и не каким-то там оптимизатором мифическим, а ручками...

Ты наверное искренне считаешь, что ХиндиС — это мега-супер-пупер прикол, из-за чего мы все испадстола пишем. Ахха
Re[7]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 21:21
Оценка:
Здравствуйте, MxKazan, Вы писали:

MK>Ты наверное искренне считаешь, что ХиндиС — это мега-супер-пупер прикол, из-за чего мы все испадстола пишем. Ахха


Да нет, набирать просто удобнее...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[7]: За что я не люблю С++
От: hattab  
Дата: 29.05.09 22:15
Оценка:
Здравствуйте, MxKazan, Вы писали:

PD>>>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).

G>>>Расскажи это создателям AutoCad.

H>>Не, ну надоело уже... Что, правда, кроме WPF-морды Автокада упомянуть больше нечего? Вот незадача то... (ах да, ты еще Paint.NET с Photoshop'ом не сравнил )

MK>Да, незадача. Приводили тут списочек прог, да только некоторым пофиг на него, делают вид, что его нет..

Э-э-э, не нужно путать софт с <см. болд>, и те поделки (Yahoo IM!, мега блин, софт), что значились в том списке (да и список-то был с софтом засветившимся на использовании WPF, что ни коим разом не указывает на его, софта, природу, а именно .Net (окромя WPF части разумеется))

MK>Кстати, о Paint.Net. Я тогда искренне поверил, что прога тормознутая. Так как сейчас обильно приходится заниматься дизайном приложения, потребовался редактор покруче Paint, но простой. Скачал Paint.Net Portable, 1.5 мега весом. И прямо вообще офигел. А обещанных тормозов то нет!


А можно цитату с "обещанными тормозами"? Я лишь припоминаю, что говорил о "муравьях" жрущих 100% моего 1.7 Pentum M. Впрочем можно добавить еще и некоторую неспешность в отрисовке линий, когда начинаешь быстро карандашиком дергать -- тормозами это не назовешь, но определенная вялость фидбека ощущается и это неприятно.

MK>На моем домашнем компе, который и 3 года назад то был средний и с тех пор не видел ничего нового, кроме винтов, Paint.Net просто летает. Так что, всё больше убеждаюсь, что приставка ".Net" действует на некоторых как красная тряпка для быка, хочется искать тормоза даже когда их нет.


Предлагаю объективный тест Выбери картинку побольше и наложи на нее фильтр Gaussian Blur с радиусом в 200 (побольше и 200 это для того, чтоб было что посмотреть). Теперь запусти GIMP и проделай то же самое (к слову, в GIMP'е настроек фильтра больше, можешь попробовать со всякими -- картины это не меняет). Уверяю тебя, приставка .Net будет порвана на твоих глазах раз десять точно (чем больше картинка тем ощутимее).
Re[9]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 22:40
Оценка:
Здравствуйте, criosray, Вы писали:

C>Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального. Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.


Речь шла вроде о тормознутости .net, а не о удобстве интерфейсов...
Кста, 5мп -- это довольно маленькая картинка...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: За что я не люблю С++
От: hattab  
Дата: 29.05.09 22:43
Оценка:
Здравствуйте, criosray, Вы писали:

H>>Предлагаю объективный тест Выбери картинку побольше и наложи на нее фильтр Gaussian Blur с радиусом в 200 (побольше и 200 это для того, чтоб было что посмотреть). Теперь запусти GIMP и проделай то же самое (к слову, в GIMP'е настроек фильтра больше, можешь попробовать со всякими -- картины это не меняет). Уверяю тебя, приставка .Net будет порвана на твоих глазах раз десять точно (чем больше картинка тем ощутимее).


C>Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального.


30%? Шутишь? У меня даже на глаз видно, что там отрыв в разы, в большие разы.

C>Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.


Как в Paint.NET вырезать часть картинки выделенную Magic Wand, чтоб у вырезаемой части растушевались границы? Я в удобном интерфейсе Paint.NET этого не нашел, а в неудобном GIMP'е нашел сразу.
Re[9]: Эх, выдыхай, однако...
От: Erop Россия  
Дата: 29.05.09 22:53
Оценка:
Здравствуйте, criosray, Вы писали:

E>>Да нет, набирать просто удобнее...

C>А мне удобнее набирать Иван, а не Егор. Вы не обидетесь, если впредь буду звать Вас Иван?

А я тебя по складам тогда буду: Кри-О-Срай?
Выдыхай, короче. Если слово "нетня" нравится тебе больше, то я могу и так твой любимый сишарп называть...
Называешь же ты тут кого-то плюсятниками и т. п...

Да и вообще -- много личного как-то. Язык -- это всего лишь инструмент разработки.. Вообще-то и в одних местах приплюсня хорошо подходит, а в других сишрапня...
Просто индусам лучше таки C# доверять, чем С++, потому и ХиндиС... В целом это положительная характеристика языка и отрицательная индусов
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[35]: А ты самокритичный...
От: Erop Россия  
Дата: 29.05.09 22:59
Оценка:
Здравствуйте, criosray, Вы писали:

C>Человеку, который так упорно доказывает, что 2+2=5, все-равно ничего не доказать.


А ты самокритичный... Уважуха!!!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 23:03
Оценка:
Здравствуйте, hattab, Вы писали:


H>>>Предлагаю объективный тест Выбери картинку побольше и наложи на нее фильтр Gaussian Blur с радиусом в 200 (побольше и 200 это для того, чтоб было что посмотреть). Теперь запусти GIMP и проделай то же самое (к слову, в GIMP'е настроек фильтра больше, можешь попробовать со всякими -- картины это не меняет). Уверяю тебя, приставка .Net будет порвана на твоих глазах раз десять точно (чем больше картинка тем ощутимее).


C>>Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального.


H>30%? Шутишь? У меня даже на глаз видно, что там отрыв в разы, в большие разы.


Не шучу. Замерял с секундомером. Если быть точным, то 27.5% выходит. Может у Вас более старая версия Paint.NET?

C>>Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.


H>Как в Paint.NET вырезать часть картинки выделенную Magic Wand, чтоб у вырезаемой части растушевались границы? Я в удобном интерфейсе Paint.NET этого не нашел, а в неудобном GIMP'е нашел сразу.


Не знаю. Я не занимаюсь профессиональным фотомонтажем. Вы уверены, что пользователям Paint.NET это нужно?
Re[5]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 29.05.09 23:03
Оценка:
c> PD>системы автоматизации проектироваия,системы распознавания образов разного рода).

c> AutoCAD.


В Автокаде только часть интерфейса на дотнете.
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[10]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 23:04
Оценка:
Здравствуйте, Erop, Вы писали:

C>>Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального. Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.


E>Речь шла вроде о тормознутости .net, а не о удобстве интерфейсов...

Так где тормознутость-то?
E>Кста, 5мп -- это довольно маленькая картинка...
5мп довольно большая картинка. Особенно для непрофессионального использования.
Re[11]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 29.05.09 23:04
Оценка:
c> H>Как в Paint.NET вырезать часть картинки выделенную Magic Wand, чтоб у вырезаемой части растушевались границы? Я в удобном интерфейсе Paint.NET этого не нашел, а в неудобном GIMP'е нашел сразу.

c> Не знаю. Я не занимаюсь профессиональным фотомонтажем. Вы уверены, что пользователям Paint.NET это нужно?


Это не профессиональный фотомонтаж. Это так — любительский уровень.

Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[11]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 23:26
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Проверил — Paint.NET примерно на 30% дольше обрабатывал картинку в 5 MP. Ничего принципиального. Зато интерфейс удобнее + бесконечное количество отмен делают его всяко удобнее для непрофессионального использования.


E>>Речь шла вроде о тормознутости .net, а не о удобстве интерфейсов...

C>Так где тормознутость-то?
Ну там, у тебя, выделено...
Правда данные вида: при такой-то операции время гимпа составило столько-то секунд, а время пэинта -- столько-то....

E>>Кста, 5мп -- это довольно маленькая картинка...

C>5мп довольно большая картинка. Особенно для непрофессионального использования.

После гонки мегапикселей даже средненькие мыльницы от 8 начинаются...
5 -- это ближе к камерофону...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 23:28
Оценка:
Здравствуйте, Mamut, Вы писали:

c>> H>Как в Paint.NET вырезать часть картинки выделенную Magic Wand, чтоб у вырезаемой части растушевались границы? Я в удобном интерфейсе Paint.NET этого не нашел, а в неудобном GIMP'е нашел сразу.


c>> Не знаю. Я не занимаюсь профессиональным фотомонтажем. Вы уверены, что пользователям Paint.NET это нужно?


M>Это не профессиональный фотомонтаж. Это так — любительский уровень.


Пусть будет любительский, но явно за пределами задач основной категории пользователей, на которую расчитана Paint.NET

M>Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо


Возможно. Опять же это уже скорее профессиональный уровень.

Вот, кстати, сравнение Paint.NET с Gimp:
http://www.connectedphotographer.com/issues/issue200710/00002067001

Процитирую заключение:

On a personal note, I enjoyed learning how to use Paint.NET much more than GIMP. The layout was much easier for me to navigate, and personally, the more time I can save not having to go through tutorials, the better. Speaking of tutorials, when I did need them, Paint.NET directed me to them faster than GIMP. I also appreciated the program knowing where I kept my picture files on my computer. I didn't have to dig through file folders because it just pulled them right up for me when I clicked upload photo. See Figure G to take a look at a beginner's project using Paint.NET.

Re[11]: Эх, выдыхай, однако...
От: Erop Россия  
Дата: 29.05.09 23:30
Оценка:
Здравствуйте, criosray, Вы писали:

E>>А я тебя по складам тогда буду: Кри-О-Срай?

C>По складам? Если Вы подразумеваете по слогам, то по слогам читается криос рэй.
Эх! В стихах, видать, ты не знаток, увы!..
Но в целом в русском слоге всегда не больше одного гласного звука...

C>PS: Вы случайно не альтер-эго г-на Шеридана, кстати?

Да мы сиамский блин близнец...

Про то, что язык -- это только инструмент ты тезис заметил, кстати?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: За что я не люблю С++
От: criosray  
Дата: 29.05.09 23:31
Оценка:
Здравствуйте, criosray, Вы писали:


C>http://www.connectedphotographer.com/issues/issue200710/00002067001


C>Процитирую заключение:


C>

C>On a personal note, I enjoyed learning how to use Paint.NET much more than GIMP. The layout was much easier for me to navigate, and personally, the more time I can save not having to go through tutorials, the better. Speaking of tutorials, when I did need them, Paint.NET directed me to them faster than GIMP. I also appreciated the program knowing where I kept my picture files on my computer. I didn't have to dig through file folders because it just pulled them right up for me when I clicked upload photo. See Figure G to take a look at a beginner's project using Paint.NET.



и еще следующей же ссылкой в гугле
http://www.mythosa.net/2008/03/paintnet-vs-gimp.html

I had briefly looked at Paint.NET but it didn't really seem to be that great. However, based on a recommendation from a blog I frequent, I gave it another try.

And I discovered I liked it! The UI is far more standard, at least where Windows is concerned (I'm thinking about shortcut keys in particular). The layout is simpler and overall it packs a far amount of power in a small package. Now, it lacks much of the GIMP's functionality, but for the majority of graphics work I do, Paint.NET is sufficient and the UI doesn't get into the way (I still keep GIMP around if I need to do something Paint.NET can't).

Re[13]: За что я не люблю С++
От: Erop Россия  
Дата: 29.05.09 23:33
Оценка:
Здравствуйте, criosray, Вы писали:

C>Пусть будет любительский, но явно за пределами задач основной категории пользователей, на которую расчитана Paint.NET


Ну типа им надо повернуть/откадрировать/напечатать?
А на кой им тогда вообще палочка-то?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Эх, выдыхай, однако...
От: criosray  
Дата: 29.05.09 23:34
Оценка:
Здравствуйте, Erop, Вы писали:

E>>>А я тебя по складам тогда буду: Кри-О-Срай?

C>>По складам? Если Вы подразумеваете по слогам, то по слогам читается криос рэй.
E>Эх! В стихах, видать, ты не знаток, увы!..
E>Но в целом в русском слоге всегда не больше одного гласного звука...

Где Вы узрели русский слог?
Re[32]: Подсчёт ссылок
От: criosray  
Дата: 29.05.09 23:52
Оценка:
Здравствуйте, COFF, Вы писали:

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


COF>>>Может конечно, это надо специально разруливать — например использовать пару shared_ptr/weak_ptr

MK>>Вот знаешь, почему хорошо, что в C# нет перегрузки присваивания? Как раз чтобы голова не занималась подсчетом этих операцией или выбором вида указателей. А еще ведь надо будет глядеть не перекрыт ли оператор присваивания, а то мало ли чего на самом деле делается. В C# я всегда знаю, что a = b — есть только копирование указателя в случае ссылочного типа и копирование значения в случае value-типа. Всё четко и ясно. По-моему, это плюс.

COF>По моему, если бы был язык, который поддерживает и сборку мусора и детерминированное освобождение ресурсов,

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

Хотя подозреваю, что Вы имели в виду выбор из GC и ручного управления памятью. Тогда ответ Objective-C.


Garbage collection

Objective-C 2.0 provides an optional conservative yet generational garbage collector. When run in backwards-compatible mode, the runtime turns reference counting operations such as "retain" and "release" into no-ops. All objects are subject to garbage collection when garbage collection is enabled. Regular C pointers may be qualified with "__strong" to also trigger the underlying write-barrier compiler intercepts and thus participate in garbage collection. A zero-ing weak subsystem is also provided such that pointers marked as "__weak" are set to zero when the object (or more simply GC memory) is collected. The garbage collector does not exist on the iPhone implementation of Objective-C 2.0. Garbage Collection in Objective-C runs on a low-priority background thread, and can halt on user events, with the intention of keeping the user experience responsive

Re[5]: За что я не люблю С++
От: Хвост  
Дата: 30.05.09 01:06
Оценка:
Здравствуйте, WolfHound, Вы писали:

PD>>Десктопное ПО с существенными требованиями по быстродействию (граф. редакторы, серьезные текстовые редакторы, системы автоматизации проектироваия,системы распознавания образов разного рода).

PD>>ПО с серьезными расчетами.
WH>Ничему из этого нативность не нужна.
WH>Вообще не нужна.
WH>Тут дело лишь в качестве оптимизатора и ни в чем больше.

можно вопрос? а как будет обеспечиваться ето самое быстродействие на managed пдатформе когда она подразумевает jit? а у jit очень-очень сильно связаны руки в плане оптимизации из-за того что действует в рантайм, связан не тем что ему доступно меньше информации (ему как раз потенциально доступно больше информации для оптимизации), а тем что у него просто нет времени на качественную оптимизацию.
People write code, programming languages don't.
Re[8]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 05:13
Оценка:
Здравствуйте, Erop, Вы писали:

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

не пондменяй понятия. не ресурсоемкий код, а линейные вычисления.
E>Как только это изменитися, так сразу все переметнутся, я думаю...
именно ресурсоемкий код выходит на managed быстрее.
Re[12]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 08:01
Оценка:
Здравствуйте, hattab, Вы писали:


H>Дана картинка, известная, Dawn Of Ubuntu 1920x1200x24. Pentium M 1.7. 512 RAM. Все лишнее выгрузил.

Core2duo 3ghz
H>1. Paint.NET 3.31. Фильтр Gaussian Blur (200px) — 2мин. 28 сек (148 сек)
10 сек
H>2.2. GIMP 2.2.11. Фильтр Гаусcово размывание (200x200px. RLE) — 20сек.
7 сек

H>Цифры говорят сами за себя. Списывать отставание на несвежесть версии Paint.NET просто смешно.
кстати, а зачем нужен этот blur в 200 (!) пикселей?


H>>>Как в Paint.NET вырезать часть картинки выделенную Magic Wand, чтоб у вырезаемой части растушевались границы? Я в удобном интерфейсе Paint.NET этого не нашел, а в неудобном GIMP'е нашел сразу.


C>>Не знаю. Я не занимаюсь профессиональным фотомонтажем. Вы уверены, что пользователям Paint.NET это нужно?


H>Это самый обычный юзкейс -- вырезать что-то с картинки и бесшовно (без зазубренных краев) вставить в другую. Что тут необычного?


Не припомню, чтоб у меня или у кого-то из знакомых появлялся такой юзкейс. А вообще надо читать справку — наверняка там это так же просто делается.
Re[13]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 08:09
Оценка:
Здравствуйте, criosray, Вы писали:

E>>>>Речь шла вроде о тормознутости .net, а не о удобстве интерфейсов...

C>>>Так где тормознутость-то?
E>>Ну там, у тебя, выделено...
C>И? Где тормознутость? Мне знаете ли как-то все-равно будет разовая операция выполняться n секунд или n+n*0.3 секунд. Гораздо важнее для меня как пользователя интуитивность и удобство интерфейса.

Ну тут-то про эффективность программ тёрки, а не про интерфейсы... Иди в форум по юзабилити и там три про удобство интерфейса... Я думаю, что там Paint.Net огребёт заслуженной критики...

E>>После гонки мегапикселей даже средненькие мыльницы от 8 начинаются...

E>>5 -- это ближе к камерофону...
C>Мегапиксели это маркетинговая фишка — замануха для глупых покупателей. Хорошие бюджетные зеркалки как раз те самые 5-6 МП.

Это тут тоже офтоп, но, что-то как-то вызывает сомнение сочетание выделенного и 5 МП...
Кста, я согласен, что мегапиксели не так уж однозначно хороши, но хорошие фотики уже с маленькими мегапикселями не делают...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[6]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 08:10
Оценка:
Здравствуйте, Хвост, Вы писали:

Х>можно вопрос? а как будет обеспечиваться ето самое быстродействие на managed пдатформе когда она подразумевает jit? а у jit очень-очень сильно связаны руки в плане оптимизации из-за того что действует в рантайм, связан не тем что ему доступно меньше информации (ему как раз потенциально доступно больше информации для оптимизации), а тем что у него просто нет времени на качественную оптимизацию.


Ну можно, например, чегой-то заранее повычислять и сохранить в сборку, так чтобы джиту полегче было...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 08:18
Оценка:
Здравствуйте, criosray, Вы писали:

C>кстати, а зачем нужен этот blur в 200 (!) пикселей?


Например размыть фон
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 08:38
Оценка:
Здравствуйте, criosray, Вы писали:

C>Ваш софт никто покупать не будет.

Спасибо за заботу, но пока покупают...

C>Что до юзабили — пэинт дот нет на голову выше Гимпа в этом плане. Я уже приводил цитаты и это взятые наугад ссылки из топа поиска в гугле по выражению gimp vs paint.net


Ой-ой-ой, какие мы умные. Как проектирование UI относится вообще к языку реализации? ЭТО НЕСВЯЗАННЫЕ ВОПРОСЫ!!!

E>>Это тут тоже офтоп, но, что-то как-то вызывает сомнение сочетание выделенного и 5 МП...

C>nikon d40
Ну это так себе фотик. Матрица слишком мелкая, а так ничего, можно пользоваться в принципе, только задний фон на портретах размывать в фотошопе прийдётся...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 08:40
Оценка:
Здравствуйте, criosray, Вы писали:

C>Чтоб размыть фон совсем не нужно 200 пикселей.


На 5 МП может и не нужно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 08:50
Оценка:
Здравствуйте, Erop, Вы писали:

C>>Чтоб размыть фон совсем не нужно 200 пикселей.


E>На 5 МП может и не нужно...


Вот-вот.
Re[16]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 08:53
Оценка:
Здравствуйте, Erop, Вы писали:


C>>Что до юзабили — пэинт дот нет на голову выше Гимпа в этом плане. Я уже приводил цитаты и это взятые наугад ссылки из топа поиска в гугле по выражению gimp vs paint.net


E>Ой-ой-ой, какие мы умные. Как проектирование UI относится вообще к языку реализации? ЭТО НЕСВЯЗАННЫЕ ВОПРОСЫ!!!


При чем тут язык? Мы как бы обсуждаем два конкретных продукта: gimp и paint.net Не заметили?

E>>>Это тут тоже офтоп, но, что-то как-то вызывает сомнение сочетание выделенного и 5 МП...

C>>nikon d40
E>Ну это так себе фотик.
Знаете лучше зеркалку за 300 уе? Подскажите.

E>Матрица слишком мелкая,

Матрица нормальная и даже большая для непрофессионального использования.
Re[13]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 09:00
Оценка:
Здравствуйте, criosray, Вы писали:

H>>Дана картинка, известная, Dawn Of Ubuntu 1920x1200x24. Pentium M 1.7. 512 RAM. Все лишнее выгрузил.

C>Core2duo 3ghz
H>>1. Paint.NET 3.31. Фильтр Gaussian Blur (200px) — 2мин. 28 сек (148 сек)
C>10 сек
H>>2.2. GIMP 2.2.11. Фильтр Гаусcово размывание (200x200px. RLE) — 20сек.
C>7 сек
C>

Нужен еще один замер от незаинтересованного лица , а то у меня сомнения есть...

H>>Цифры говорят сами за себя. Списывать отставание на несвежесть версии Paint.NET просто смешно.

C>кстати, а зачем нужен этот blur в 200 (!) пикселей?

Мне нужен был для создания, как тут уже упомянули, фона. Хотя обсуждаем-то тут не применимость того или иного инструмента, а скорострельность натива и не натива. Кстати, Paint.NET ngen'ится при инсталляции т.ч. на неоптимальность JIT-оптимизации тут тоже не попеняешь.

H>>Это самый обычный юзкейс -- вырезать что-то с картинки и бесшовно (без зазубренных краев) вставить в другую. Что тут необычного?


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


Создание банального коллажа вот и юзкейс. А вообще мне нравится тебя читать, ты по каждому обсуждаемому вопросу так обстоятельно своих знакомых опрашиваешь
Re[6]: За что я не люблю С++
От: WolfHound  
Дата: 30.05.09 09:06
Оценка:
Здравствуйте, Хвост, Вы писали:

Х>можно вопрос? а как будет обеспечиваться ето самое быстродействие на managed пдатформе когда она подразумевает jit?

Managed не подразумевает только JIT.
Вполне возможно сделать всю или большую часть работы во время установки программы.
В прочем такое уже даже есть.
ngen.exe называется.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 09:08
Оценка:
Здравствуйте, Erop, Вы писали:

G>>не пондменяй понятия. не ресурсоемкий код, а линейные вычисления.

G>>именно ресурсоемкий код выходит на managed быстрее.

E>Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...


Если много винта, то скорее в винт все и упрется. Другое дело память и проц
Re[10]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 09:31
Оценка:
Здравствуйте, Erop, Вы писали:

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


G>>не пондменяй понятия. не ресурсоемкий код, а линейные вычисления.

G>>именно ресурсоемкий код выходит на managed быстрее.

E>Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...

Я тоже именно это имею ввиду. managed в таком раскладе рулит как пилот формулы один.
При сильно ресурсоемком приложении линейный код становится жутко неэффективным, поялвется необходимость создавать "легкие" потоки, state machine и прочие радости. В таких условиях ручное управление ресурсами становится чрезвычайно тяжелым занятием.
Поэтому в unmanaged занимаются или созданием кучи потоков, или оптимизируют только на высоком уровне. Оба варианта заметно влияют на производительность.
Re[11]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 09:32
Оценка:
Здравствуйте, hattab, Вы писали:

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


G>>>не пондменяй понятия. не ресурсоемкий код, а линейные вычисления.

G>>>именно ресурсоемкий код выходит на managed быстрее.

E>>Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...


H>Если много винта, то скорее в винт все и упрется. Другое дело память и проц


Тут еще вопрос насколько рано быстродействие программы упрется в быстродествие винта.
Re[13]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 30.05.09 09:38
Оценка:
c> M>Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо

c> Возможно. Опять же это уже скорее профессиональный уровень.


Далеко не профессиональный
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[13]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 10:52
Оценка:
Здравствуйте, criosray, Вы писали:

H>>Дана картинка, известная, Dawn Of Ubuntu 1920x1200x24. Pentium M 1.7. 512 RAM. Все лишнее выгрузил.

C>Core2duo 3ghz
H>>1. Paint.NET 3.31. Фильтр Gaussian Blur (200px) — 2мин. 28 сек (148 сек)
C>10 сек
H>>2.2. GIMP 2.2.11. Фильтр Гаусcово размывание (200x200px. RLE) — 20сек.
C>7 сек
C>

Я, кажется, понял -- Paint.NET параллелит алгоритмы в отличие от GIMP'а. Я посмотрел в ProcessExplorer'е, на моем одноядернике он считает в двух тредах (их сразу видно на фоне остальных). Вероятно на двуядерном тредов будет больше, хотя это не суть важно. Однако, даже в этом случае, натив быстрее
Re[12]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 10:55
Оценка:
Здравствуйте, gandjustas, Вы писали:

E>>>Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...


H>>Если много винта, то скорее в винт все и упрется. Другое дело память и проц


G>Тут еще вопрос насколько рано быстродействие программы упрется в быстродествие винта.


Как встретит нечто вроде "update xxxx where yyyy" на многомиллионной табличке, да с обновлением ключевых/индексируемых полей, так и упрется
Re[14]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 10:58
Оценка:
Здравствуйте, hattab, Вы писали:

H>Я, кажется, понял -- Paint.NET параллелит алгоритмы в отличие от GIMP'а. Я посмотрел в ProcessExplorer'е, на моем одноядернике он считает в двух тредах (их сразу видно на фоне остальных). Вероятно на двуядерном тредов будет больше, хотя это не суть важно. Однако, даже в этом случае, натив быстрее


Непринципиально быстрее. Было бы принципиально, переписали бы алгоритм на С и собрали бы каким-нибудь Intel C++.
Re[14]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 11:00
Оценка:
Здравствуйте, Mamut, Вы писали:

c>> M>Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо


c>> Возможно. Опять же это уже скорее профессиональный уровень.


M>Далеко не профессиональный


Кстати, к GIMP'у есть расширение для работы с RAW.
Re[15]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 11:02
Оценка:
Здравствуйте, criosray, Вы писали:

H>>Я, кажется, понял -- Paint.NET параллелит алгоритмы в отличие от GIMP'а. Я посмотрел в ProcessExplorer'е, на моем одноядернике он считает в двух тредах (их сразу видно на фоне остальных). Вероятно на двуядерном тредов будет больше, хотя это не суть важно. Однако, даже в этом случае, натив быстрее


C>Непринципиально быстрее. Было бы принципиально, переписали бы алгоритм на С и собрали бы каким-нибудь Intel C++.


Так не о том же речь
Re[15]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 11:36
Оценка:
Здравствуйте, hattab, Вы писали:

c>>> M>Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо


c>>> Возможно. Опять же это уже скорее профессиональный уровень.


M>>Далеко не профессиональный


H>Кстати, к GIMP'у есть расширение для работы с RAW.


http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Plugins/RawLoader.shtml
Re[16]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 11:37
Оценка:
Здравствуйте, hattab, Вы писали:


H>>>Я, кажется, понял -- Paint.NET параллелит алгоритмы в отличие от GIMP'а. Я посмотрел в ProcessExplorer'е, на моем одноядернике он считает в двух тредах (их сразу видно на фоне остальных). Вероятно на двуядерном тредов будет больше, хотя это не суть важно. Однако, даже в этом случае, натив быстрее


C>>Непринципиально быстрее. Было бы принципиально, переписали бы алгоритм на С и собрали бы каким-нибудь Intel C++.


H>Так не о том же речь


А о чем речь? О ветренных мельницах?
Re[14]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 11:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

E>>>>>Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...


H>>>>Если много винта, то скорее в винт все и упрется. Другое дело память и проц


G>>>Тут еще вопрос насколько рано быстродействие программы упрется в быстродествие винта.


H>>Как встретит нечто вроде "update xxxx where yyyy" на многомиллионной табличке, да с обновлением ключевых/индексируемых полей, так и упрется


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


И откуда взялось это "если"? А если будет другое "если"? Когда речь идет о софте, которому нужно "много винта", наивно, как раз таки, думать, что он не упрется именно в него.
Re[17]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 11:59
Оценка:
Здравствуйте, criosray, Вы писали:

H>>>>Я, кажется, понял -- Paint.NET параллелит алгоритмы в отличие от GIMP'а. Я посмотрел в ProcessExplorer'е, на моем одноядернике он считает в двух тредах (их сразу видно на фоне остальных). Вероятно на двуядерном тредов будет больше, хотя это не суть важно. Однако, даже в этом случае, натив быстрее


C>>>Непринципиально быстрее. Было бы принципиально, переписали бы алгоритм на С и собрали бы каким-нибудь Intel C++.


H>>Так не о том же речь


C>А о чем речь? О ветренных мельницах?


Придется повториться:

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


И как мы увидели, даже параллельность не спасла приставку...
Re[15]: За что я не люблю С++
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 12:09
Оценка:
Здравствуйте, hattab, Вы писали:

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


E>>>>>>Я не знаю, что ты имеешь в виду под "ресурсоёмкий", то я имею в виду код которому надо много проца, памяти, винта и т. д...


H>>>>>Если много винта, то скорее в винт все и упрется. Другое дело память и проц


G>>>>Тут еще вопрос насколько рано быстродействие программы упрется в быстродествие винта.


H>>>Как встретит нечто вроде "update xxxx where yyyy" на многомиллионной табличке, да с обновлением ключевых/индексируемых полей, так и упрется


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


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

Ну тогда подумай головой что есть производительность.
Re[16]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 12:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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

G>Ну тогда подумай головой что есть производительность.

А вот тут хоть как думай, если антивирусному сканеру нужно "много винта" так в него он и упирается.
Re[37]: Подсчёт ссылок
От: Erop Россия  
Дата: 30.05.09 13:19
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Что-то я запутался, в этой ветке я за дотнет вразумляю, или за сиплюсплюс?


+100
Да какая разница? Все хороши
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 13:24
Оценка:
Здравствуйте, criosray, Вы писали:


[совсем офтоп ON]
E>>Ну это так себе фотик.
C>Знаете лучше зеркалку за 300 уе? Подскажите.
Хорошую не знаю, к сожалению.

E>>Матрица слишком мелкая,

C>Матрица нормальная и даже большая для непрофессионального использования.
Я вот не очень понимаю, что такое "непроф. использование", и для чего для этого самого использования нужна именно зеркалка, сменная оптика и т. п...
Вот портретная съёмка в непроф. использование входит? Если таки да, то сразу хочется иметь ПЗСку побольше (не в пикселях, а в миллиметрах)...
[совсем офтоп OFF]

E>>Ой-ой-ой, какие мы умные. Как проектирование UI относится вообще к языку реализации? ЭТО НЕСВЯЗАННЫЕ ВОПРОСЫ!!!

C>При чем тут язык? Мы как бы обсуждаем два конкретных продукта: gimp и paint.net Не заметили?

Правда? А почему она, тогда, называется "За что я не люблю С++"?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 13:29
Оценка:
Здравствуйте, hattab, Вы писали:

H>Paint.NET использовал преимущества двуядерного проца. Это три.


Кстати, то, что многие проги повадились незапрящаемым образом загружать все возможные нити не несколько напрягает.
У меня часто так бывает, что идёт какой-то долгий процесс и я в это время в чём-то ещё ковыряюсь. Так вот Я БЫ ХОТЕЛ, ЧТОБЫ ЭТО "ЧТО_ТО ЕЩЁ" НЕ ТОРМОЗИЛО МОЙ ДОЛГИЙ ПРОЦЕССС!!!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 13:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Поэтому в unmanaged занимаются или созданием кучи потоков, или оптимизируют только на высоком уровне. Оба варианта заметно влияют на производительность.


Ну и где управляемые базы данных, например, которые рвут неуправляемые по производительности?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[21]: За что я не люблю С++
От: hattab  
Дата: 30.05.09 14:27
Оценка:
Здравствуйте, Erop, Вы писали:

H>>Paint.NET использовал преимущества двуядерного проца. Это три.


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


Я с Paint.NET'ом это удовольствие огреб в полной мере, со своим-то одноядерником Запускаю генерирование фрактала Мандельброт. Paint.NET открывает диалог с настройками этой отрисовки, а сам в фоне начинает считать и рисовать с текущими настройками (правда у меня есть сомнения, что настройки дефолтные, а не оставшиеся от предыдущих экспериментов). Что я имею? Я имею 100% загрузку проца и неотвечающие контролы. В общем, Paint.NET моей бутявке противопоказан

E>У меня часто так бывает, что идёт какой-то долгий процесс и я в это время в чём-то ещё ковыряюсь. Так вот Я БЫ ХОТЕЛ, ЧТОБЫ ЭТО "ЧТО_ТО ЕЩЁ" НЕ ТОРМОЗИЛО МОЙ ДОЛГИЙ ПРОЦЕССС!!!


Решение есть Ставишь Prio (это экстендер к таск-менеджеру) (ссылки нет у меня ) и выставляешь тяжелому процессу самый низкий приоритет (Prio эти настройки сохраняет поэтому сделать это нужно только один раз). Я так видео иногда перекодирую, сразу в 4-5 VirtualDub'ах (про очередь знаю, если что ).
Re[15]: Дык сам предложи область... ;)
От: Erop Россия  
Дата: 30.05.09 14:41
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>CouchDB это отлично показал.

И какая у него доля рынка там, или тесты какие-то, которые показывают мегакрутизну?
Кста, переписывание кода часто вообще полезно, даже без смены языка. Просто нарабатываются новые подходы, идеи и т. п...

E>>Но может быть это специфика БД. Но давай какую-нибудь другую область возмём? 3Д движки к играм, например, или распознавалки чего-нибудь, или редакторы видео, или сам предлагай...

E>>Для всего этого производительность -- это ключевая фича. И где управляемые аналоги, которые рвут неуправляемые по производительности?
G>Подожди, ты сам только что говорил про ресурсоемкие программы, а теперь говоришь исключительно о том, что требует только процессора.
AFAIK, не только процессора... Редакторам видео и память нужна и проц, и диск... Распознавалкам часто тоже. Но главное тут то, что я выделил... Где та область, где управляемые языки показывают хай перфоманс и рвут неуправляемые среды?

Вроде как в основном это энтерпрайз в режиме "быстро-быстро-уже вчера". И то рвут не по производительности программы, а по произодительности программиста. И там это круто делают, след. признать
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: Дык сам предложи область... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 30.05.09 15:13
Оценка:
Здравствуйте, Erop, Вы писали:

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


G>>CouchDB это отлично показал.

E>И какая у него доля рынка там, или тесты какие-то, которые показывают мегакрутизну?
Понятия не имею.

E>Кста, переписывание кода часто вообще полезно, даже без смены языка. Просто нарабатываются новые подходы, идеи и т. п...

Ты не понимаешь наверное.
То переписываение, о котором ты говоришь может затронуть 30% кода, при этом такое переписывание можно проводить постепенно.
Если хочешь переписать на другой язык, то надо переписывать почти 100% кода, причем пока не перепишешь все толку маловато будет.
Продажи софта это не увеличит ни на копейку, хотя придется вложить много денег в обучение команды новому языку и новой платформе.
Кроме того использование другой платформы заставит перерабатывать архитектуру.
Короче куча рисков и неясные бенефиты.
Можно конечно это делать частями, как автодеск в автокаде или МС в студии, но все равно настанет момент когда понадобится выкинуть большую часть существущего кода и написать по новой.

E>>>Но может быть это специфика БД. Но давай какую-нибудь другую область возмём? 3Д движки к играм, например, или распознавалки чего-нибудь, или редакторы видео, или сам предлагай...

E>>>Для всего этого производительность -- это ключевая фича. И где управляемые аналоги, которые рвут неуправляемые по производительности?
G>>Подожди, ты сам только что говорил про ресурсоемкие программы, а теперь говоришь исключительно о том, что требует только процессора.
E>AFAIK, не только процессора... Редакторам видео и память нужна и проц, и диск... Распознавалкам часто тоже.
Может и нужна, но не оказывает большого влияния на производительность.

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

В основном веб, распределенные системы.
Re[17]: Дык сам предложи область... ;)
От: Erop Россия  
Дата: 30.05.09 15:18
Оценка:
Здравствуйте, gandjustas, Вы писали:

E>>AFAIK, не только процессора... Редакторам видео и память нужна и проц, и диск... Распознавалкам часто тоже.

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

Ну вот в известных мне распознавалках очень даже оказывает...
И про переписать -- можно же переписать только высоконагруженные части...

G>В основном веб, распределенные системы.

Зачем распределённой системе хай-перфоманс? Ей нужно задания между компами хорошо перекидыватиь, а не с диском и памятью хорошо работать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 16:16
Оценка:
Здравствуйте, Erop, Вы писали:

E>
[совсем офтоп ON]

E>>>Ну это так себе фотик.
C>>Знаете лучше зеркалку за 300 уе? Подскажите.
E>Хорошую не знаю, к сожалению.

E>>>Матрица слишком мелкая,

C>>Матрица нормальная и даже большая для непрофессионального использования.
E>Я вот не очень понимаю, что такое "непроф. использование", и для чего для этого самого использования нужна именно зеркалка, сменная оптика и т. п...
E>Вот портретная съёмка в непроф. использование входит? Если таки да, то сразу хочется иметь ПЗСку побольше (не в пикселях, а в миллиметрах)...
[совсем офтоп OFF]


E>>>Ой-ой-ой, какие мы умные. Как проектирование UI относится вообще к языку реализации? ЭТО НЕСВЯЗАННЫЕ ВОПРОСЫ!!!

C>>При чем тут язык? Мы как бы обсуждаем два конкретных продукта: gimp и paint.net Не заметили?

E>Правда? А почему она, тогда, называется "За что я не люблю С++"?


Память коротка? Тему на фотики перевели Вы.
Re[12]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 16:21
Оценка:
Здравствуйте, Erop, Вы писали:

G>>Поэтому в unmanaged занимаются или созданием кучи потоков, или оптимизируют только на высоком уровне. Оба варианта заметно влияют на производительность.


E>Ну и где управляемые базы данных, например, которые рвут неуправляемые по производительности?


СУБД это всего-лишь бэкенд, где важно иметь возможность выжать максимум эффективности, а потому ресурсы на их разработку кидаются нешуточные. Кстати, для MS SQL Server довольно порядочно кода написано на дотнет — тот же Management Studio и хранимки на дотнет (что, кстати, в определенных сценариях дает нешуточный выигрышь производительности).

Ну а почти весь middle- и front-end пишутся на управляемых языках: джава и дотнет в первую очередь.
Re[14]: За что я не люблю С++
От: criosray  
Дата: 30.05.09 16:25
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

E>>>Ну и где управляемые базы данных, например, которые рвут неуправляемые по производительности?

G>>Есть CouchDB например. Только сравнить её пока не с чем.

ГВ>CouchDB не на Эрланге разве? Это ж не совсем то, что мы понимаем под managed.


Это Ваши проблемы, что Вы не понимаете что такое managed. Ерланг — самый настоящий управляемый язык.
Re[15]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 30.05.09 16:29
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>CouchDB не на Эрланге разве? Это ж не совсем то, что мы понимаем под managed.

C>Это Ваши проблемы, что Вы не понимаете что такое managed. Ерланг — самый настоящий управляемый язык.

Ладно, пусть так, чтобы не вдаваться в смысловые оттенки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[19]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 16:46
Оценка:
Здравствуйте, criosray, Вы писали:


E>>>>Ой-ой-ой, какие мы умные. Как проектирование UI относится вообще к языку реализации? ЭТО НЕСВЯЗАННЫЕ ВОПРОСЫ!!!

C>>>При чем тут язык? Мы как бы обсуждаем два конкретных продукта: gimp и paint.net Не заметили?

E>>Правда? А почему она, тогда, называется "За что я не люблю С++"?


C>Память коротка? Тему на фотики перевели Вы.


А так что скажешь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: За что я не люблю С++
От: Erop Россия  
Дата: 30.05.09 16:49
Оценка:
Здравствуйте, criosray, Вы писали:

C>Ну а почти весь middle- и front-end пишутся на управляемых языках: джава и дотнет в первую очередь.


Ну так там и производительность обычно некритична...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[37]: Подсчёт ссылок
От: -MyXa- Россия  
Дата: 30.05.09 17:34
Оценка:
Здравствуйте, Qbit86, Вы писали:

Q>Что-то я запутался, в этой ветке я за дотнет вразумляю, или за сиплюсплюс?


Ну, раз я внесён-таки уже "в реестр недостойных внимания", то день знаний уже не наступит.

MX>>Инкремент/декремент не может быть лишним.

MX>>Я не знаю, зачем вы это повторяете. Я никогда boost::shared_ptr по ссылке не передаю. А Вы?

Q>Я же выше намекнул, что проверить можно через use_count(), почему ты этого не сделал? Я должен за тебя код набирать? Хорошо, в последний раз я это сделаю.


Q>
Q>void Foo(std::tr1::shared_ptr<int> p)
Q>{
Q>  std::cout << p.use_count() << std::endl;
Q>}

Q>void Bar(std::tr1::shared_ptr<int> const& p)
Q>{
Q>  std::cout << p.use_count() << std::endl;
Q>}

Q>int main () 
Q>{
Q>  std::tr1::shared_ptr<int> const p(new int(2));
Q>  std::tr1::shared_ptr<int> const q(new int(1));

Q>  Foo(p);
Q>  Bar(q);
Q>}
Q>


Другими словами, Вы часто передаёте shared_ptr по ссылке (а внутри не создаёте копию прежде, чем делать что-либо ещё) и нет, по Вашему мнению, с этим никаких проблем, одна только экономия? Тогда Вы ошибаетесь, вот смотрите:
boost::shared_ptr<int> g;

void Bar(boost::shared_ptr<int> const & o)
{
    g.reset(); // не обязательно прямо так, это м.б. и вызов какой-нибудь функции, которая из какого-нибудь list-а удаляет shared_ptr
    *o = 42;
}


Всё замечательно, пока мы не делаем Bar(g). По-этому НИКОГДА нельзя передавать shared_ptr по ссылке (м.б., разве что, в конструктор, чтобы тут же его скопировать в поле класса, но и это не всегда надёжно по той же причине).

MX>>Инкремент/декремент не может быть лишним. Я не знаю, зачем вы это повторяете.


Q>Я не знаю, зачем ты упорно отрицаешь вещи, очевидные любому C++-программисту. Алсо, почитай книжки, где рассказывается про 1) ссылки/уазатели, 2) влавдение/аггрегацию/композицию, etc.


Мне книжки уже не помогут, дурака учить — только портить.

MX>>И где экономия?


Q>Я уже отчаялся тебе хоть что-то объяснить. Впредь я не буду даже пытаться.


Спрашивая про экономию, я приводил ещё и код, который ОБЯЗАТЕЛЕН в данном случае.

MX>>_Просто_ "ссылаются два человека" и ни один не владеет? ЗдОрово!


А почему Вы цитируете мои слова, которые относятся к С#, не полностью, отрывая самое важное, а потом ещё и перепрыгиваете на С++? А я, между прочим, спрашивал "Ну-ка, покажите мне — как уничтожить, в таком случае, почку по полной программе (и я опять не имею в виду Dispose, потому, что он — не уничтожение)?"

Q>Ты ничего не понимаешь в понятиях «ссылается» и «владеет». Точка, абзац. Вот тебе пример на C++ (потому что C#, очевидно, для тебя слишком сложен тем, что значок «=» означает в нём копирование ссылки):

Q>
Q>  std::tr1::shared_ptr<int> p(new int(42));
Q>  std::tr1::shared_ptr<int>& ref1(p);
Q>  std::tr1::shared_ptr<int>& ref2(p);
Q>

Q>Здесь есть 3 идентификатора — p, ref1, ref2. Чем-то владеет только p. Остальные — это ссылки на него, объявление ссылки не приводит к разделению владения. Не веришь — проверь:
Q>
Q>  ref1.reset();
Q>  std::cout << *ref2 << std::endl;
Q>


Как на С# записать аналог "ref1.reset()", в моём примере про почку и 2-х человек, Вы так и не ответили. И, если такого кода нет, стало быть Вы не правы, утверждая, что

Здесь нет ни передачи владения, ни его разделения. Здесь на одну почку ссылаются два человека. Если любой из них умрёт и вызовет Dispose() для себя и подобъектов, то у другого будет невалидная почка.

Соответственно и тут:

значок «=» означает в нём (в C#, прим. моё) копирование ссылки

Вы не правы, т.е. невозможно уничтожить насовсем объект, пока на него есть хоть одна ссылка, а вызов какого-то там Dispose ничего не говорит о владении. Эдак можно сказать, что и файл не расшарен между p1 и p2 тут:
shared_ptr<std::fstream> p1(...);
shared_ptr<std::fstream> p2(p1);

Т.к. всегда можно сделать "p1->close()".

MX>>Короче, нет никакого способа в C# передать поле (вообще объект) в метод, не передав владения. Так и запишем.


Q>Ага, так и запиши. Повторяй, как мантру. Совершенно очевидно, что ты не заинтересован в «понять», а заинтересован в «переспорить». Вообще-то, встречая явно провокационные (читай «толстый троллинг») фразы типа «В общем, картина начинает проясняться»
Автор: COFF
Дата: 28.05.09
и «Так и запишем»
Автор: -MyXa-
Дата: 29.05.09
, полезно заблаговременно вносить собеседника в реестр недостойных внимания и не тратить на них более времени.


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

А где не было про "запишем", Вы меня повырезали вовсе.

Короче, я остался при своём:
* в C# есть только передача владения (предположу, что есть исключение — встроенные типы, чтоб было не без аномалий)
* shared_ptr — только по значению, без вариантов
* подсчёт ссылок в C# только так (2 места, где можно ошибиться — забыть Clone или Using):
void foo(RefCounter<HugeBitmap> h)
{
  using (h)
  {
  }
}
foo(hugeBitmap.Clone());

сравните с С++ (ошибаться негде — передачу по ссылке видно невооруженным глазом):
void foo(shared_ptr<HugeBitmap>)
{
}
foo(hugeBitmap);
Если не поможет, будем действовать током... 600 Вольт (C)
Re[38]: Подсчёт ссылок
От: Erop Россия  
Дата: 30.05.09 17:46
Оценка:
Здравствуйте, -MyXa-, Вы писали:


MX>Другими словами, Вы часто передаёте shared_ptr по ссылке (а внутри не создаёте копию прежде, чем делать что-либо ещё) и нет, по Вашему мнению, с этим никаких проблем, одна только экономия? Тогда Вы ошибаетесь, вот смотрите:

MX>
MX>boost::shared_ptr<int> g;

MX>void Bar(boost::shared_ptr<int> const & o)
MX>{
MX>    g.reset(); // не обязательно прямо так, это м.б. и вызов какой-нибудь функции, которая из какого-нибудь list-а удаляет shared_ptr
MX>    *o = 42;
MX>}
MX>


MX>Всё замечательно, пока мы не делаем Bar(g). По-этому НИКОГДА нельзя передавать shared_ptr по ссылке (м.б., разве что, в конструктор, чтобы тут же его скопировать в поле класса, но и это не всегда надёжно по той же причине).


Z в целом с тобой согласен, но вот тут конкретно не совсем. Всё-таки большинство функций стараются писать так, чтобы сторонних эффектов не было... Так что подобная предосторожность в типичной функции -- лишняя...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[38]: Подсчёт ссылок
От: criosray  
Дата: 30.05.09 18:33
Оценка:
Здравствуйте, -MyXa-, Вы писали:

MX>* в C# есть только передача владения (предположу, что есть исключение — встроенные типы, чтоб было не без аномалий)

Понятие "передача владения" Вы сами придумали. Есть value-типы, есть ref-типы. Пока на объект реф типа есть "живые" и не слабые (WeakReference) ссылки GC его уничтожать не станет. Для детерменированного освобождения ресурсов применяется патерн IDisposable, позволяющий явно вызвать метод "закрытия" хэндла (неуправляемого ресурса) в детерменированный момент времени.

MX>* shared_ptr — только по значению, без вариантов

MX>* подсчёт ссылок в C# только так (2 места, где можно ошибиться — забыть Clone или Using):
MX>[c#]
MX>void foo(RefCounter<HugeBitmap> h)
MX>{
MX> using (h)
MX> {
MX> }
MX>}

Это бессмыслица. Работать либо не будет совсем, либо будет идентично
using (var h = new HugeBitmap) {} но с лишним слоем абстракции.

Не пытайтесь применять приемы, работающие в неуправляемых средах, к управляемым. Особенно, если не понимаете принципов работы сборщика мусора и патерна Disposable.
Re[39]: Подсчёт ссылок
От: Qbit86 Кипр
Дата: 30.05.09 18:41
Оценка:
Здравствуйте, criosray, Вы писали:

C>Понятие "передача владения" Вы сами придумали. Есть value-типы, есть ref-типы. Пока на объект реф типа есть "живые" и не слабые (WeakReference) ссылки GC его уничтожать не станет. Для детерменированного освобождения ресурсов применяется патерн IDisposable, позволяющий явно вызвать метод "закрытия" хэндла (неуправляемого ресурса) в детерменированный момент времени.


Ты не прав, criosray. «Передача владения» и «разделение владения» известные термины. Позже, быть может, я подробнее прокомментирую.

MX>>[Skipped.]

C>Это бессмыслица.

Да, это бессмыслица.

C>Не пытайтесь применять приемы, работающие в неуправляемых средах, к управляемым.


Приём «подсчёт ссылок» ортогонален «управляемости» среды.
Глаза у меня добрые, но рубашка — смирительная!
Re[25]: За что я не люблю С++
От: hattab  
Дата: 31.05.09 10:13
Оценка:
Здравствуйте, yuriylsh, Вы писали:

Y>>>Ага, точно, и вообще, для графики и редактирования видео многопоточность категорически противопоказана (а особенно в 4-5 VirtualDub'ах)!!!

Y>>>

H>>VirtualDub таки распараллеливается, чего ты так возбудился? А 4-5 инстансов использую т.к. он (VirtualDub), не то из-за кодеков, не то из-за ошибок во входящем потоке, иногда таки падает, и если использовать его очередь, то очередь он унесет вместе с собой. А так, один из 4-5 упал ночью, так и не страшно -- другие-то проболжают работать.


Y>Не знаю где ты там углядел чье-либо возбуждение, не хочу даже думать об этом. А если ты о количестве смайликов и восклицательных знаков, то это если ты не понял, просто в тон к твоим с Еrоp сообщениям.


А где в моем сообщении куча смайлов и восклицательных знаков? Между строк читаешь?

Y>То что VirtualDub распараллеливается я то как раз прекрасно понимаю, я думаю, иронию в моих словах сложно было не уловить. Обрати внимание на категорию приложений указанных мной (хинт, чтобы избежать повторного недопонимания и грез о возбужденных от твоих слов собеседников — графика и видео как раз те области, которым многопоточность — то что доктор прописал). Просто ты похаял одно приложение за использование многопоточности, ибо твоей одноядерной "бутявке" сложно это переварить и тут же приводишь другое, использующее многопоточность во весь рост да еще и в 4-5 экземплярах одновременно. Так держать!


Я, как ты изволил выразиться, похаял приложение не за использование, а за способ приготовления. Разницу улавливаешь? А VirtualDub позволяет таки устанавливать у молотящих тредов любой приоритет, потому и не мешает, ни работе своего гуя, ни работе окружающих приложений.
Re[15]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 01.06.09 08:38
Оценка:
Здравствуйте, criosray, Вы писали:

c> c>> M>Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо


c> c>> Возможно. Опять же это уже скорее профессиональный уровень.


c> M>Далеко не профессиональный


c> А что тогда профессиональный уровень? А какой процент пользователей вообще знает, что такое "работа с RAW"?


c> Мамут, ей богу, Вы как ребенок...


Я лучше послушаю определение любительского уровня.

ЛЮБИ'ТЕЛЬ, я, м.

1. чего и с инф. Имеющий склонность или пристрастие к чему-н. Л. музыки. Л. шахматной игры. Л. покушать. Страстный л. лошадей. 2. без доп. Занимающийся чем-н., как дилетант; противоп. профессионал. Труппа любителей. Шахматный турнир любителей

ПРОФЕССИОНА'Л, а, м.

Человек, сделавший какое-н. занятие своей постоянной профессией.

avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[16]: За что я не люблю С++
От: Mamut Швеция http://dmitriid.com
Дата: 01.06.09 08:38
Оценка:
Здравствуйте, criosray, Вы писали:

c> c>>> M>Кстати, ни Гимп ни Paint.net не поддерживают нормально работу с RAW — а вот это уже плохо


c> c>>> Возможно. Опять же это уже скорее профессиональный уровень.


c> M>>Далеко не профессиональный


c> H>Кстати, к GIMP'у есть расширение для работы с RAW.


c> http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Plugins/RawLoader.shtml


Да знаю я. Это — не то. Там есть ограничения
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[4]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 11:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>Множественное наследование такой же моветон, как и goto.

CC>Какое смелое заявление.
Это факт.
http://c2.com/cgi/wiki?MisUsingMultipleInheritance
http://www.gotw.ca/publications/mill06.htm


Scott Meyers is one of the leading gurus in the C++ languages, in his book "Effective C++", the "is a" relationship for public inheritance is being mentioned in item 35: Make sure public inheritance models "is a".

Beside that, the current chairman of the ISO C++ Standard Committee, Herb Sutter, have also mentioned that in one of his articles.


We need "controlled polymorphism" LSP IS-A, but in certain code only. Public inheritance should always model IS-A as per the Liskov Substitution Principle (LSP).[3] Nonpublic inheritance can express a restricted form of IS-A, even though most people identify IS-A with public inheritance alone. Given class Derived : private Base, from the point of view of outside code, a Derived object IS-NOT-A Base, and so of course can't be used polymorphically as a Base because of the access restrictions imposed by private inheritance. However, inside Derived's own member functions and friends only, a Derived object can indeed be used polymorphically as a Base (you can supply a pointer or reference to a Derived object where a Base object is expected), because members and friends have the necessary access. If instead of private inheritance you use protected inheritance, then the IS-A relationship is additionally visible to further-derived classes, which means subclasses can also make use of the polymorphism.



C>>>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>>>logger::log(__filename__, __line__, "log text")

C>>
C>>catch(Exception e) {
C>>   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
C>>   throw;
C>>}
C>>


CC>А ничего что то, что ты написал к logger::log(__filename__, __line__, "log text") не имеет вообще никакого отношения даже близко.

Конечно имеет. Но если хотите один в один, то ради бога:
Log.Info("log text");
Re[6]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 12:59
Оценка:
Здравствуйте, 0xC0000005, Вы писали:

C>>

C>>Scott Meyers is one of the leading gurus in the C++ languages, in his book "Effective C++", the "is a" relationship for public inheritance is being mentioned in item 35: Make sure public inheritance models "is a".

C>>Beside that, the current chairman of the ISO C++ Standard Committee, Herb Sutter, have also mentioned that in one of his articles.


C>>We need "controlled polymorphism" LSP IS-A, but in certain code only. Public inheritance should always model IS-A as per the Liskov Substitution Principle (LSP).[3] Nonpublic inheritance can express a restricted form of IS-A, even though most people identify IS-A with public inheritance alone. Given class Derived : private Base, from the point of view of outside code, a Derived object IS-NOT-A Base, and so of course can't be used polymorphically as a Base because of the access restrictions imposed by private inheritance. However, inside Derived's own member functions and friends only, a Derived object can indeed be used polymorphically as a Base (you can supply a pointer or reference to a Derived object where a Base object is expected), because members and friends have the necessary access. If instead of private inheritance you use protected inheritance, then the IS-A relationship is additionally visible to further-derived classes, which means subclasses can also make use of the polymorphism.


C>Многа букаф и ничего по существу.


Конечно. Скот Майерс — С++ гуру будет писать не по существу. Куда уж ему до господина с кулхацкерским ником с кывта.

C>>>>>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>>>>>logger::log(__filename__, __line__, "log text")

C>>>>
C>>>>catch(Exception e) {
C>>>>   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
C>>>>   throw;
C>>>>}
C>>>>


CC>>>А ничего что то, что ты написал к logger::log(__filename__, __line__, "log text") не имеет вообще никакого отношения даже близко.

C>>Конечно имеет. Но если хотите один в один, то ради бога:
C>>Log.Info("log text");

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

Ну не выводите. Формат лога настраивается как душе угодно. И какое вообще это имеет отношение к теме?
Re[4]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 13:38
Оценка:
Здравствуйте, 0xC0000005, Вы писали:

C>>COM


C>КОМ это прадед распределённой модели — это отдельный разговор, если уж хотите посмотреть как это может работать без мета инфы красиво, посмотрите на внука КОМа — CORBA в имплементации Шмидта над ACE


Кстати, совсем забыл указать на еще один ляп в Вашем посте. CORBA ну никак не может быть "внуком COM", т.к. появилась за два года до COM — в 91ом.
Re[5]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 13:45
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Множественное наследование такой же моветон, как и goto.

CC>>Какое смелое заявление.
C>Это факт.
C>http://c2.com/cgi/wiki?MisUsingMultipleInheritance

Хм. Misusing = моветон? У тебя снова какое-то странное прочтение. Можно в микроволновку сунуть домашнюю собаку, это ещё не означает, что микроволновка или домашняя собака — моветон.

C>http://www.gotw.ca/publications/mill06.htm


C>

C>Scott Meyers is one of the leading gurus in the C++ languages, in his book "Effective C++", the "is a" relationship for public inheritance is being mentioned in item 35: Make sure public inheritance models "is a".

C>Beside that, the current chairman of the ISO C++ Standard Committee, Herb Sutter, have also mentioned that in one of his articles.


C>We need "controlled polymorphism" LSP IS-A, but in certain code only. Public inheritance should always model IS-A as per the Liskov Substitution Principle (LSP).[3] Nonpublic inheritance can express a restricted form of IS-A, even though most people identify IS-A with public inheritance alone. Given class Derived : private Base, from the point of view of outside code, a Derived object IS-NOT-A Base, and so of course can't be used polymorphically as a Base because of the access restrictions imposed by private inheritance. However, inside Derived's own member functions and friends only, a Derived object can indeed be used polymorphically as a Base (you can supply a pointer or reference to a Derived object where a Base object is expected), because members and friends have the necessary access. If instead of private inheritance you use protected inheritance, then the IS-A relationship is additionally visible to further-derived classes, which means subclasses can also make use of the polymorphism.


При чём тут множественное наследование? В процитированной тобой статье речь идёт о наследовании вообще.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[5]: За что я не люблю С++
От: CreatorCray  
Дата: 01.06.09 13:49
Оценка:
Здравствуйте, criosray, Вы писали:

C>>А ЕСЛИ это не исключение?

C>Что "это"? сatch(Exception e) ловит все исключения (т.к. он является базовым классом для классов исключений в дотнет). Не знали об этом?
Он о том, что запись в лог вызвана не в результате исключения или какой либо ошибки.

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

Пиписки оказались одинаковой длины.

C>>А как строки относятся к языку? Этож не паскаль

C>Строка такой же базовый тип данных, как и int, double, bool, и т.д.
Неа. Это решать автору языка: базовый или не базовый.

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

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

C>Одна из реализаций. Как-там у нее с юникодом, кстати?

y wstring USC2 100% поддерживается
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 13:53
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, 0xC0000005, Вы писали:


C>>>

C>>>Scott Meyers is one of the leading gurus in the C++ languages, in his book "Effective C++", the "is a" relationship for public inheritance is being mentioned in item 35: Make sure public inheritance models "is a".

C>>>Beside that, the current chairman of the ISO C++ Standard Committee, Herb Sutter, have also mentioned that in one of his articles.


C>>>We need "controlled polymorphism" LSP IS-A, but in certain code only. Public inheritance should always model IS-A as per the Liskov Substitution Principle (LSP).[3] Nonpublic inheritance can express a restricted form of IS-A, even though most people identify IS-A with public inheritance alone. Given class Derived : private Base, from the point of view of outside code, a Derived object IS-NOT-A Base, and so of course can't be used polymorphically as a Base because of the access restrictions imposed by private inheritance. However, inside Derived's own member functions and friends only, a Derived object can indeed be used polymorphically as a Base (you can supply a pointer or reference to a Derived object where a Base object is expected), because members and friends have the necessary access. If instead of private inheritance you use protected inheritance, then the IS-A relationship is additionally visible to further-derived classes, which means subclasses can also make use of the polymorphism.


C>>Многа букаф и ничего по существу.


C>Конечно. Скот Майерс — С++ гуру будет писать не по существу. Куда уж ему до господина с кулхацкерским ником с кывта.


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

C>>>>>>А как просто вам при вызове логгера указать текущее имя файла, исходника я имею ввиду,ай как вы ругали макросы, это так, это сяк, а как вы напишете:

C>>>>>>logger::log(__filename__, __line__, "log text")

C>>>>>
C>>>>>catch(Exception e) {
C>>>>>   Log.Error(e); // через рефлексию будет собрана информация об исключении, потоке, методе, сборке, стеке вызовов(!!!)
C>>>>>   throw;
C>>>>>}
C>>>>>


CC>>>>А ничего что то, что ты написал к logger::log(__filename__, __line__, "log text") не имеет вообще никакого отношения даже близко.

C>>>Конечно имеет. Но если хотите один в один, то ради бога:
C>>>Log.Info("log text");

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

C>Ну не выводите. Формат лога настраивается как душе угодно. И какое вообще это имеет отношение к теме?

Так вот пишите то, о чем вас попросили, а не полёт фантазии на тему "Как это будет красивее"
Re[5]: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 14:04
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, 0xC0000005, Вы писали:


C>>>COM


C>>КОМ это прадед распределённой модели — это отдельный разговор, если уж хотите посмотреть как это может работать без мета инфы красиво, посмотрите на внука КОМа — CORBA в имплементации Шмидта над ACE


C>Кстати, совсем забыл указать на еще один ляп в Вашем посте. CORBA ну никак не может быть "внуком COM", т.к. появилась за два года до COM — в 91ом.




Давайте пробежимся по иерархий названий, но ActiveX, DCOM, OLE, DDE — это всё КОМ, и то что мелкомягкие называют новую версию не заставит меня называть одно другим, COM DDE
CORBA внук DDE, так вас больше устроит?

И говорив Внук я вовсе не имел ввиду что КОРБу сделали на основе КОМа, боже упаси, а вот по эволюции — КОМ это предшественник КОРБы
Re[6]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 14:09
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>>А ЕСЛИ это не исключение?

C>>Что "это"? сatch(Exception e) ловит все исключения (т.к. он является базовым классом для классов исключений в дотнет). Не знали об этом?
CC>Он о том, что запись в лог вызвана не в результате исключения или какой либо ошибки.
Какая разница?

C>>>А как строки относятся к языку? Этож не паскаль

C>>Строка такой же базовый тип данных, как и int, double, bool, и т.д.
CC>Неа. Это решать автору языка: базовый или не базовый.
Во всех нормальных языках так. Даже в Objective-C тип один единственный NSString — и никаких проблем с зоопарком строк, как в С++.

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

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

C>>Одна из реализаций. Как-там у нее с юникодом, кстати?

CC>y wstring USC2 100% поддерживается
Разницу между std::string и std::wstring улавливаете?
Re[8]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 14:26
Оценка:
Здравствуйте, 0xC0000005, Вы писали:


C>>Конечно. Скот Майерс — С++ гуру будет писать не по существу. Куда уж ему до господина с кулхацкерским ником с кывта.


C>Во первых переход на личности не показывает вас с лучшей стороны,

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

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

Вы не путайте наследование (inheritance) с реализацией (implementation). Так вот интерфейсы не наследуются, а реализуются. А наследование и в С# и в Java есть только одинарное.

C>И какой-же геморой вас ждёт, когда интерфейс должен иметь один маленький метод.

Что должен делать интерфейс?
Сморозили очередную глупость. Интерфейс — это просто контракт.

C>Так вот пишите то, о чем вас попросили, а не полёт фантазии на тему "Как это будет красивее"


По существу сказать нечего?
Re[7]: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 14:31
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, 0xC0000005, Вы писали:




C>>>>>COM


C>>>>КОМ это прадед распределённой модели — это отдельный разговор, если уж хотите посмотреть как это может работать без мета инфы красиво, посмотрите на внука КОМа — CORBA в имплементации Шмидта над ACE


C>>>Кстати, совсем забыл указать на еще один ляп в Вашем посте. CORBA ну никак не может быть "внуком COM", т.к. появилась за два года до COM — в 91ом.


C>>Давайте пробежимся по иерархий названий, но ActiveX, DCOM, OLE, DDE — это всё КОМ, и то что мелкомягкие называют новую версию не заставит меня называть одно другим, COM DDE

C>>CORBA внук DDE, так вас больше устроит?
C>>И говорив Внук я вовсе не имел ввиду что КОРБу сделали на основе КОМа, боже упаси, а вот по эволюции — КОМ это предшественник КОРБы
C>Чушь полная.

C>Немного ликбеза: COM и DDE были созданы с целью коммуникации между процессами в пределах одного компьютера.

C>CORBA и (много позже) DCOM были созданы для коммуникации между приложениями в сети.

C>Разницу чувствуете?


C>А Ваши бурные фантазии на тему кто чей внук/правну/дедушка/папка/мамка лучше оставьте при себе.



И Ком и Корба имплементируют "КОМПОНЕНТНУЮ" модель, и даже idl у них на 99% одинаковый, и всё сводится к общению между компонентами, но КОРБА имеет дополнительные аспекты.

В общем начали с одного, закончили терминами, как обычно и делает crioSray.

Кстати, криоСрэй, какой стаж работы на С++? На примере когда ты сказал что в С++ шаблоне нельзя вызвать неделарированный метод из T, я могу сказать что С++ для тебя это Си с классами(если помнишь), и обсуждать темы такого порядка ты может только на уровне "Мне это не нравится и ВСЁ".

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

Всё больше и больше мне здаётся что криоСрэй и есть аффтар той доки, уж очень стиль похож.
Re[5]: За что я не люблю С++
От: 0xC0000005  
Дата: 01.06.09 14:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте, 0xC0000005, Вы писали:


ГВ>>>Тут ты ошибаешься. Ошибка простительная, ты мог этого просто не знать по юности. На самом деле, классы появились в 5.5, а в 6.0 уже появился Turbo Vision, в 7.0 — редактор с подсветкой синтаксиса. Это так, не полемики ради, а энциклопедистики для.

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

ГВ>Я точно помню, как было — это был мой первый ОО-язык. Addon-ом, вернее библиотекой, был Turbo Vision (уже — в 6.0). Собственно, я хотел тебе намекнуть на другое: то, что ты говоришь, оно по сути правильно, но небрежность в исторических отсылках даёт лишний повод проигнорировать твои доводы.


Ок, полагаю я ошибся насчёт того, что автор неправильно выбрал версию паскаля для изучения ОО.
Re[7]: За что я не люблю С++
От: CreatorCray  
Дата: 01.06.09 14:37
Оценка:
Здравствуйте, criosray, Вы писали:

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


C>>>>А ЕСЛИ это не исключение?

C>>>Что "это"? сatch(Exception e) ловит все исключения (т.к. он является базовым классом для классов исключений в дотнет). Не знали об этом?
CC>>Он о том, что запись в лог вызвана не в результате исключения или какой либо ошибки.
C>Какая разница?
Однако.

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

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

C>>>Одна из реализаций. Как-там у нее с юникодом, кстати?

CC>>y wstring USC2 100% поддерживается
C>Разницу между std::string и std::wstring улавливаете?

typedef basic_string<char, char_traits<char>, allocator<char> > string;
typedef basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > wstring;
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[12]: Уточнение
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 14:58
Оценка:
ГВ>"Контракт" подразумевает в частности соглашения о побочных эффектах [...]
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 16:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>"Контракт" подразумевает соглашения о побочных эффектах

C>>Занавес. Апплодисменты.

ГВ>А что не так?


ГВ>Интерфейс (в терминах C#) — это только перечисление методов,


Не только. Садитесь — два.
Re[15]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 16:47
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Интерфейс (в терминах C#) — это только перечисление методов,


C>Не только. Садитесь — два.


Ладно, пусть перечисление не только методов, но ещё и их параметров. Много поменялось в сути сказанного мной о контрактах?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[16]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 16:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Интерфейс (в терминах C#) — это только перечисление методов,


C>>Не только. Садитесь — два.


ГВ>Ладно, пусть перечисление не только методов, но ещё и их параметров. Много поменялось в сути сказанного мной о контрактах?


Четвертая двойка. Не только методов и параметров.
Re[15]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 17:04
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>"что должен делать интерфейс" — интерфейс может верифицировать часть более общего контракта класса.


C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


Зависит от того, как мы определяем сам термин "интерфейс". Если это только конструкция языка программирования вроде C# или Java — да, не может. Если это часть "контракта" — то не только может, но ещё и, не побоюсь этого слова, должен.

C>Цитирую:


C>

C>Интерфейс — набор всех сигнатур, определенных операциями объекта. Интерфейс описывает множество запросов, на которые может отвечать объект.


C>"Приемы объектно-ориентированного проектирования. Патерны проектирования" Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес


GoF, как и многие идеологи современного программирования обожают приписывать хорошо знакомым терминам необычные значения. Сейчас мне лень возиться, погугли по словам Liskov Substitution Principle, в статьях, обсжудающих LSP, в частности, встречается корректное определение "контракта". В том числе и строгое — через предикаты. Ещё, в качестве опорной точки поисков — языки CLU и Eiffel.

C>Если для Вас это облегчит понимание, то уточню, что книга эта была написана ДО дотнет и все примеры в книге приведены на С++.


Спасибо, я знаю. Больше того, это была первая книга по программированию, которую я сознательно отказался покупать в 2001 г. ибо абсолютно ничего нового для меня в ней не было.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 17:05
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Ладно, пусть перечисление не только методов, но ещё и их параметров. Много поменялось в сути сказанного мной о контрактах?

C>Четвертая двойка. Не только методов и параметров.

Ах, ещё пропертей и статических методов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 17:17
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Геннадий Васильев, Вы писали:



C>>>Целые числа и числа с плавающей запятой это разные понятия.


ГВ>>Почему? И то, и другое суть "число".

C>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.

C>А строки "они и в африке" строки.


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

ГВ>>"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.

C>Нет, не может их быть великое множество. Заканчивайте фантазировать.

Отнюдь. Строка может представляться как:

— непрерывная (в памяти) последовательность символов с символом-терминатором;
— непрерывная последовательность с дополнительным параметром — длиной (длина может располагаться в начале последовательности или они объединяются в некоторый агрегат);
— "списком" символов, т.е., занимать не непрерывный сегмент памяти;
— набором ссылок на фрагменты последовательностей.

Естественно, может быть всё разнообразие кодировок: с фиксированным или плавающим количеством байт на символ. Так же естественно, что строка (как "объект") может содержать или не содержать операции поиска, конкатенации, выделения подстроки и т.п. И само собой, строки могут быть изменяемыми и не изменяемыми.

Ну и какую комбинацию мы примем за единственно правильную?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[7]: За что я не люблю С++
От: blackhearted Украина  
Дата: 01.06.09 17:34
Оценка:
Здравствуйте, gandjustas, Вы писали:


COF>>Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно

G>Мегакластер на плюсах? Плюсов там и не будет, голый C.

Откуда дровишки?
Re[8]: За что я не люблю С++
От: Antikrot  
Дата: 01.06.09 17:56
Оценка:
Здравствуйте, blackhearted, Вы писали:

COF>>>Вариант с C++ уже все посчитал, а создатель F# сидит — затачивает моно

G>>Мегакластер на плюсах? Плюсов там и не будет, голый C.
B>Откуда дровишки?

ну, в общем-то, плюсы там будут. после С и Fortran'а
дровишки можно поискать среди открытых и не очень hpc приложений, доступных в инете... вообще сейчас туда всё тащат, даже boost но старого кода пока больше
Re[18]: За что я не люблю С++
От: criosray  
Дата: 01.06.09 18:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ладно, пусть перечисление не только методов, но ещё и их параметров. Много поменялось в сути сказанного мной о контрактах?

C>>Четвертая двойка. Не только методов и параметров.

ГВ>Ах, ещё пропертей и статических методов.


Ну это двойка с двумя плюсами или тройка с тремя минусами. Могли бы уже хоть в Гугл заглянуть, вместо того, чтоб гадать...
Re[2]: За что я не люблю С++
От: WolfHound  
Дата: 01.06.09 18:30
Оценка:
#Имя: От модератора
Здравствуйте, 0xC0000005, Вы писали:

C>Очень интересная статейка, сколько я таких быдланов повидал и пообламывал,

Полегче на поворотах.

C>Ха, вот имено столкнулся, лбами, и судя по всему скорлупа его мозга дала непоправимую трещину, сорри за лирику — не выдержал.

В следующий раз выдерживай.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 18:47
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Отнюдь. Строка может представляться как:

C>Опять же — представления типа. Тип строка — один единственный.

Определение типа, которым ты руководствуешься — в студию!

ГВ>>Ну и какую комбинацию мы примем за единственно правильную?

C>А она всего одна — строка как тип данных.

Я сказал — определение.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[17]: Неясно сформулировал
От: criosray  
Дата: 01.06.09 18:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>>>Собственно, самое главное — строки в "общечеловеческом" смысле в принципе не могут совпадать со строками в "компьютерном" смысле.
C>>Тип может совпадать (конечно же) и совпадает. Примером тому c#, java, python, ruby — и другие нормальные языки.

ГВ>Мда? Надо думать, что общечеловеческое начертание строк символов тоже предполагает их закавычивание? Остроумно.


Какое еще "заковычивание"? Вам самому еще не смешно от той билеберды, что Вы тут выдумываете?

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

C>>И снова Вы говорите не о типе, а о реализации. Тип строка — один единственный. Точка.

ГВ>Ну, попробуй тогда ответить на вопрос, что такое тип.


http://en.wikipedia.org/wiki/Data_type читайте до полного просвящения.
Re[15]: интефейс и контракт...
От: Erop Россия  
Дата: 01.06.09 18:58
Оценка:
Здравствуйте, criosray, Вы писали:

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


Эх, кажется мне, что вы о разных сущностях говоррите. Где-то об интерфейсе, как конструкции того или иного языка, а где-то об интерфейсе, как о контракте класса...

Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:
struct IOrder {
    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
};
При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...

Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 19:08
Оценка:
Здравствуйте, criosray, Вы писали:

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

C>Все понятно. Все вокруг Вас приписывают необычные значения хорошо знакомым (почему-то только Вам одному) терминам.

Да, разумеется. Правда, то самое, хорошо знакомое значение терминов хорошо знакомо не только мне, о чём я сужу по реакции собеседников. И кстати, не только значение, но и взаимосвязь этого термина с другими терминами, явлениями и т.п.

C>Вопросов больше не имею. Не утруждайте себя больше ответами по этой теме.


Да это не у тебя ко мне вопросы, а у меня к тебе, если ты не заметил.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[9]: За что я не люблю С++
От: Erop Россия  
Дата: 01.06.09 19:09
Оценка:
Здравствуйте, criosray, Вы писали:


C>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.

А как у System.String с Shift-JIT, например?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[9]: За что я не люблю С++
От: Erop Россия  
Дата: 01.06.09 19:13
Оценка:
Здравствуйте, criosray, Вы писали:

C>Тем, что ошибка будет указана прямо в редакторе во время набора на строке f<B>(), где B — класс, не реализующий интерфейс, а в С++ только во время компилляции будет выдана ошибка при чем совсем в другом месте — на вызове

C>t.f() — будет указано, что класс B НЕ имеет метода f().

А почему ты думаешь, что одно место лучше другого?
Кста, дефолтный компилятор ещё посоветует посмотреть определение класса B, так что скорее всего попадёт в нужное место...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: интефейс и контракт...
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 19:20
Оценка:
Здравствуйте, Erop, Вы писали:

C>>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

E>Эх, кажется мне, что вы о разных сущностях говоррите. Где-то об интерфейсе, как конструкции того или иного языка, а где-то об интерфейсе, как о контракте класса...

Я — о разных. А criosray, похоже, склеивает их в одну.

E>Но если вернуться именно к языковым конструкциям, так сказать, то вот есть у меня интерфейс, например такой:
struct IOrder {
E>    virtual bool IsInCorrectOrder( const TEltm* elem1, const TElem* elem2 ) = 0;
E>    virtual bool IsEquivalent( const TEltm* elem1, const TElem* elem2 ) = 0;
E>};
При этом подразумевается, что IsEquivalent( a, b ) влечёт либо и IsInCorrectOrder( a, b ) и IsInCorrectOrder( b, a ), либо, наоборот, влечёт и !IsInCorrectOrder( a, b ) и !IsInCorrectOrder( b, a )...


E>Кроме того мы требуем, чтобы передавали всегда указатели на валидный объект. Вот это уже контракт этого интерфейса...


Да, согласен. Скажем так — это составляющая контракта.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Неясно сформулировал
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 01.06.09 19:51
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Ну что, моя очередь ставить двойки?

C>Попробуйте — снова посажу Вас в лужу.

Ты не увиливай, громовержец. Я тебя спросил, что считать определением типа, которым ты руководствуешься. Ответ будет?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[13]: За что я не люблю С++
От: NikeByNike Россия  
Дата: 01.06.09 21:25
Оценка:
Здравствуйте, criosray, Вы писали:

C>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.

C>А строки "они и в африке" строки.
Да-да-да
А что творится айфоне? А с китайским языком знаешь какие приколы бывают?
Нужно разобрать угил.
Re[10]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 06:04
Оценка:
Здравствуйте, Erop, Вы писали:
C>>Вот-вот. Никак у нее с юникодом. Потому что для юникода создан совсем другой класс — wstring.
E>А как у System.String с Shift-JIT, например?
А что с ней не так?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.09 07:14
Оценка:
Здравствуйте, criosray, Вы писали:

C>>http://research.microsoft.com/en-us/projects/contracts/

C>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?

Прикольный постинг по этому поводу: API Design Myth: Interface as Contract
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 09:01
Оценка:
Здравствуйте, 0xC0000005, Вы писали:

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


C>>Здравствуйте, Геннадий Васильев, Вы писали:


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


C>>>>>http://research.microsoft.com/en-us/projects/contracts/

C>>>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?
C>[...]
C>>А никто и не утверждал, что интерфейс является полным контрактом класса.

C>Я о том же, интерфейс — это не контракт, а вы разве не писали обратного?

C>http://rsdn.ru/forum/flame.comp/3412734.1.aspx
Автор: criosray
Дата: 01.06.09


Вы читать умеете? Или дальше первого предложения не осилили?

А никто и не утверждал, что интерфейс является полным контрактом класса. [b]Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе точно так же как и code сontracts в конкретной реализации интерфейса — в классе, описывают пред- и пост- условия в методе или еще более специфичные соглашения, как тут вчера приводили о порядке вызовов методов, т.п. — это тоже контракты КЛАССА. У классов естественно может быть целое множество контрактов, которое в совокупности составляет полный контракт этого класса. Вы же пытаетесь смешивать теплое с мягким, грубейше нарушая принцип single responsibility, когда добавляете КОД в интерфейс. О чем Вам, кстати, и господин WolfHound твердил.[/b]

Специально для Вас выделил ключевое.
Re[16]: За что я не люблю С++
От: MxKazan Португалия  
Дата: 02.06.09 09:16
Оценка:
Здравствуйте, 0xC0000005, Вы писали:

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

C>...
C>>Специально для Вас выделил ключевое.
C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:
C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.

C>Потом вы пишете
C>

C>А никто и не утверждал, что интерфейс является полным контрактом класса


C>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:

C>Колесо — это чисто машина.
По такой логике criosray должен был написать, что интерфейс — это чисто класс. Вроде такого не было
Re[16]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 09:30
Оценка:
Здравствуйте, 0xC0000005, Вы писали:


C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:


C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


C>Потом вы пишете


C>

C>А никто и не утверждал, что интерфейс является полным контрактом класса


Почему Вы упорно не желаете читать дальше первого предложения?

Читайте и перечитывайте пока до Вас не дойдет смысл сказанного:


Как минимум класс может реализовать множество интерфейсов и каждый из них является контрактом сам по себе

Re[18]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 10:21
Оценка:
Здравствуйте, Игoрь, Вы писали:

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


E>>>Ну и так далее...

S>>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>>0. Они не immutable.
S>>1. Они слишком сильно сосредоточены на бинарном представлении.

И>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:

И>
И>const std::string &str = string(src);
И>

Это совсем не то. В данном случае запрещено вызывать методы над этой строкой.
В С# разрешено:

var str = "abc";
var str2 = str.Replace('a','b'); // тут создается новая строка


И>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder. Лично мне, как пользователю,


То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:
var str = "abc";
var str2 = "abc2";
ссылаются на один и тот же участок памяти str == str2 true.
Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

StringBuilder представляет строку в виде полноценного связного списка char`ов, позволяя тем самым модифицировать ее за линейное время (в отличии от std::string).
Re[19]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 10:22
Оценка:
Здравствуйте, criosray, Вы писали:


C>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:

C>var str = "abc";
C>var str2 = "abc2";
C>ссылаются на один и тот же участок памяти str == str2 true.

Опечатка. str2 = "abc" конечно же.
Re[20]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 10:36
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>Это совсем не то. В данном случае запрещено вызывать методы над этой строкой.

CC>Неа. Запрещено вызывать методы, меняющие эту строку.
Именно то, о чем я и говорил.

C>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

CC>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
CC>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
Конечно никакой — ведь std::string не могут использовать общий буффер, как это делается в дотнет.

C>>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:

C>>var str = "abc";
C>>var str2 = "abc2";
C>>ссылаются на один и тот же участок памяти str == str2 true.
CC>Эээээ....
Да, опечатка.

var str = "abc";
var str2 = "abc";

Вот так они будут ссылаться на один и тот же буфер. Тем самым будет использовано всего 6 байт под буфер вместо 12, как это было бы в С++ (впрочем, std::string даже не юникодный, так что там было бы 3+3).
Re[20]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 10:39
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

CC>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
Re[13]: За что я не люблю С++
От: March_rabbit  
Дата: 02.06.09 10:41
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Геннадий Васильев, Вы писали:



C>>>Целые числа и числа с плавающей запятой это разные понятия.


ГВ>>Почему? И то, и другое суть "число".

C>Число это слишком обобщенное понятие. Даже школьники знают, что числы бывают целыми, дробными, с плавающей запятой, комплексными.
C>А строки "они и в африке" строки.
гм... неужто это говорит программист???
неее, не верю. Он прикалывается.

ГВ>>"В общем" — одно. А вот с точки зрения компьютера (то есть — реализаций) этих самых "строк" может быть великое множество. А для человека все они будут выражать одну и ту же абстракцию — строку.

C>Нет, не может их быть великое множество. Заканчивайте фантазировать.
Re[17]: Ну ты вообще многого не видишь... ;)
От: March_rabbit  
Дата: 02.06.09 10:47
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>Ну и так далее...

S>Ну, то, что нет предела совершенству — это как бы понятно. Но наука на месте не стоит. Пока что наиболее развитым формализмом для представления "просто строк" является уникодовская цепочка. В строках С++ сделано сразу несколько принципиальных ошибок:
S>0. Они не immutable.
S>1. Они слишком сильно сосредоточены на бинарном представлении.

S>Строки дотнета тоже не лишены недостатков, но об этих недостатках дефолтным строкам стандартной библиотеки плюсов еще приходится только мечтать.

было бы странно, если в дотнете недостатки были бы хуже
учитывая, когда кто из них появился.
Re[10]: За что я не люблю С++
От: March_rabbit  
Дата: 02.06.09 10:50
Оценка:
Здравствуйте, 0xC0000005, Вы писали:

C>Это проблема языка или IDE? Я работал под расширениями емакса, которые производят все операции проверки шаблона в редакторе, так что это далеко не проблема языка, а среды разработки.

пожалуйста, ткни пальцем где на ЭТО можно посмотреть! Воткну себе в емакс!
Давно что-то подобное хочу.
Re[21]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 10:56
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

CC>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
CC>>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
C>Конечно никакой — ведь std::string не могут использовать общий буффер, как это делается в дотнет.
Какая в этом выгода?
Не, ну если у тебя в проге есть куча одинаковых строк, раскиданных по всему коду то да, на спичках сэкономить можно.
А так смысла особого не видно.
Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?

C>Вот так они будут ссылаться на один и тот же буфер. Тем самым будет использовано всего 6 байт под буфер вместо 12, как это было бы в С++

В С++ для кода:
const char* str = "abc";
const char* str2 = "abc";

в случае включения опции Enable string pooling тоже будет str == str2

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

Кроме того, сталкивался с реализацией STL в которых basic_string сделан через COW с подсчетом ссылок.

C> (впрочем, std::string даже не юникодный, так что там было бы 3+3).

Базовой реализации строк в STL на это вообще пофигу — хоть UTF32 на них реализуй.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[3]: За что я не люблю С++
От: jazzer Россия Skype: enerjazzer
Дата: 02.06.09 11:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>А примеры? Как такой крутой перец и гуру не наваял нам с десяток красивых примеров.

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

C>>И вот тут я хочу остановиться на книге "Exceptional C++" в двух томах, где описывается как молодой девелопер может сделать криво, а как после прочтения это можно сделать шедеврально.

WH> Молодой "девелопер" может сделать только криво. Тем более на С++. Тем более после того как начитается.
+1

WH>В прочем жаба сама по себе один сплошной обрубок.

+1

C>>Тогда решили сделать множественное наследование, и разрешить наследовать от одного класса, и одного и более недо-класса, который не мог бы вызвать испражнения из кучерявых пальцев говнокодеров, те никаких имплементаций, которые могут вызвать двоиственность сущностей, только описание метода, или словами микрософта — Pure Virtual Function.

WH>Интерфейс это чистый контракт.
WH>Тем он собственно и хорош.
WH>Ибо SRP никто не отменял. А нарушать такие вещи в дизайне языка это совсем не хорошо.
Имхо, это совершенно некритично, и никто не мешает к этому чистому контракту привернуть пару невиртуальных функций — это никак на чистоте контракта не скажется, так как то, что было чисто виртуальным, им и останется.

WH>Так вот билдер сдох по тому что во первых был жутко глючный. Просто не реальное количество багов везде.

+1. Мертворожденное дитя.

WH>Нормальным людям нужно решать задачу, а не контролы в каждом новом проекте выпиливать.

+1. Но это спор не о языках, а о библиотеках.

WH>Вот это макросы.

WH>А то что в С++ это полное угрЁбище.
+1. Макросы Немерле было бы очень здорово поиметь в плюсах. Много проблем бы сразу ушло. А древний примитивный сишный препроцессор (тут С++ ничего не добавил) — это, безусловно, полный привет.
Единственное его достоинство — простота реализации, но программерам от этого ни холодно, ни жарко, им нужен нормальный мощный и гибкий инструмент.

WH>Ява просто не правильный язык.

WH>C# объективно лучше. Но тоже не фонтан.
+1
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Re[22]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 11:35
Оценка:
Здравствуйте, alexey_ma, Вы писали:


C>>>>Но это НИ В КОЕМ случае не должно запрещать операций над строками, как это происходит в С++ с const std::string...

CC>>>Подходы разные. В std::string все заточено на изменение этой же строки.
CC>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
C>>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.
_>Посмотрите QString из QT, вроде неплохо работает, да еще и cross-platform . А "дикий оверхед", обычно появляется в результате неумелого и непродуманного использования библиотечных классов как в С++ так в С#.
Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?
Re[19]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 11:41
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Игoрь, Вы писали:


И>>Не стоит мерить С++ мерками С#. В С++ давным-давно есть встроенное в сам язык средство для shallow/deep immutability, а именно модификатор const. Соответственно, если тебе нужна immutable строка, то достаточно написать что-то такое:

И>>
И>>const std::string &str = string(src);
И>>


И>>А в С# для этого пришлось городить огород в виде двух классов: String и StringBuilder.

S>Не стоит мерить дотнет мерками C++.
S>String и StringBuilder имеют принципиально разное поведение, которое не сводится к запрету вызова неконстантных мемберов. В частности, у них разная трактовка идентичности.
S>Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
Например, и почему эти алгоритмы нельзя сделать эффективно на С++?
Re[21]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 11:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

CC>>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
S>Очень простая. Например, иммутабельные строки могут быть ключами в хештаблицах.
Опять приходим к вопросу: если две одинаковые (в итоге) строки получены из разных источников, будут ли они ссылаться на одну и ту же область памяти?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[19]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 11:50
Оценка:
Здравствуйте, criosray, Вы писали:

C>Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.

Не, ну это уже оголтелый фанатизм, иначе уже и не назовешь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 11:52
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.

CC>Не, ну это уже оголтелый фанатизм, иначе уже и не назовешь.

Ну покажите мне хоть один современный язык, где ситуация со строками хуже или такая же плохая, как в С++.
Re[24]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 12:04
Оценка:
Здравствуйте, alexey_ma, Вы писали:

C>>Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?

_>Я полагаю что вы хотели получить пример этого :
_>

CC>>>>>В С++ ничего не мешает заимплементить точно такую же функциональность как для строк C#: все методы, меняющие строку — возвращают новую строку а оригинал не трогают.
C>>>>Кстати, хотел бы я посмотреть как бы это работало без дикого оверхеда в виде shared_ptr.

_>В QT это есть( и не только для строк кстати).
Понятно. Спасибо.
Re[23]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:06
Оценка:
Здравствуйте, criosray, Вы писали:

CC>>Какая в этом выгода?

CC>>Не, ну если у тебя в проге есть куча одинаковых строк, раскиданных по всему коду то да, на спичках сэкономить можно.
CC>>А так смысла особого не видно.
C>Вот и пришли наконец от "В С++ нет оверхеда!!!11111" (с) уж и не помню кто из местных "гуру" к "зачем экономить на спичках".
Угу. Именно нет оверхеда, да.
Потому как у меня нет одной единственной реализации строки, объявленной самой кошерной.
Там где мне надо иметь кучку константных строк с которыми у меня идут частые сравнения на равенство — у меня отдельный класс строки, который ровно под это заточен.
Остальные же строки в программе у меня на 99% различны — нет никакого смысла для них городить огород.
И я "не плачу" за то, что мне не нужно.

CC>>Кстати, если у тебя в коде будут две одинаковые строки, но одна прочитана из файла а вторая собрана из кусочков то они тоже на один и тот же буфер ссылаться будут?

C>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).
И как оно это делает?

C>Будет время напишу синтетический тест с молотилками больших объемов текста средствами std::string и StringBuilder для сравнения.

И потом как тут было с ганжустасовым тестом аллокации его порвет наколенный шаблон MySimpleString?

CC>>Кроме того, сталкивался с реализацией STL в которых basic_string сделан через COW с подсчетом ссылок.


C>>> (впрочем, std::string даже не юникодный, так что там было бы 3+3).

CC>>Базовой реализации строк в STL на это вообще пофигу — хоть UTF32 на них реализуй.

C>И что у Вас std::string UTF32? Что за STL у Вас такой можно поинтересоваться?

Например typedef std::basic_string<DWORD, char_traits<DWORD>, allocator<DWORD>> UTF32string;
на *никс системах по-дефолту wchar_t вообще 32битный. Там даже wstring UTF32 потянет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[23]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:06
Оценка:
Здравствуйте, criosray, Вы писали:

C>Это конечно все замечательно, но как это соотносится с обсуждаемым вопросом об immutable природе строк?

Это у тебя они все immutable. А реальный мир прекрасно живет и с mutable и c immutable строками.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[21]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 02.06.09 12:10
Оценка:
Здравствуйте, criosray, Вы писали:

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


FORTRAN 99 -- это современный?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: За что я не люблю С++
От: Erop Россия  
Дата: 02.06.09 12:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>А как у System.String с Shift-JIT, например?

S>А что с ней не так?
А рзве она в Юникод укладывается?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 12:14
Оценка:
Здравствуйте, Erop, Вы писали:


C>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.

E>Ты не поймёшь.
Ну если Вы поняли, то любой поймет.
E>Но если ты всё-таки готов напрячься и понять, то почитай исходники CString из MFC, например...
Посмотрю когда СString станет immutable.
Re[21]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:15
Оценка:
Здравствуйте, criosray, Вы писали:

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


C>>>Да это просто очень сложно — почти не возможно сделать хуже, чем тот зоопарк, что есть в С++.

CC>>Не, ну это уже оголтелый фанатизм, иначе уже и не назовешь.

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

Ты до сих пор не доказал что она плохая.
В С++ можно заимплементить какие угодно строки.
То, что в STL есть какая то обобщенная реализация строки имеет отношение к библиотеке STL а не к языку С++.
Благо STL в компилер не встроен, тьфу тьфу тьфу.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[23]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.06.09 12:19
Оценка:
Здравствуйте, criosray, Вы писали:
C>Скорее всего да (100% утверждать не буду — точно уже не припоминаю, надо перечитать System.String internals).
Нет. Более того, в последних версиях даже принудительный вызов Intern() не приводит к желаемым результатам.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:23
Оценка:
Здравствуйте, Юрий Жмеренецкий, Вы писали:

ЮЖ>Если это так, то время появления нового объекта (строки) должно зависеть от количества существующих объектов (строк) в программе.

А если это не так (что скорее всего) то тогда получается что уже в качестве ключей их использовать упс... И память они уже не экономят...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:23
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.

E>>Ты не поймёшь.
C>Ну если Вы поняли, то любой поймет.
Ну ты ж вот никак не можешь понять

E>>Но если ты всё-таки готов напрячься и понять, то почитай исходники CString из MFC, например...

C>Посмотрю когда СString станет immutable.
Мне что, написать для тебя immutable СString чтоб ты наконец понял как это делаетcя?
Ты ж вроде как программист — сам соображать должен. Что такое COW тоже вроде знаешь. А раз про shared_ptr приплел то явно тебя только этот момент смущал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: За что я не люблю С++
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.09 12:25
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>>http://research.microsoft.com/en-us/projects/contracts/

C>>>Вы что же совсем не понимаете разницы между interface as contract и между code contracts?
ГВ>>Прикольный постинг по этому поводу: API Design Myth: Interface as Contract

C>А никто и не утверждал, что интерфейс является полным контрактом класса.


Цитату из твоего постинга тебе уже тут не раз привели, так что, повторяться не буду. Значит, ты настолько неудачно сформулировал свою мысль, что читатели тебя с лёгкостью поняли не правильно. Что, в общем, не удивительно, фразу: "интерфейс это чисто контракт" можно понять и так и эдак — и что интерфейс является частью контракта, и что интерфейс эквивалентен контракту, и даже так, что контракт является частью интерфейса. Этим же грешат и другие твои постинги.

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


В общем, согласен. Хотя и здесь у тебя не обошлось без путаницы: "множество интерфейсов и каждый из них является контрактом сам по себе". Интерфейс не является контрактом — такой оборот не больше, чем эвфемизм.

C>Вы же пытаетесь смешивать теплое с мягким, грубейше нарушая принцип single responsibility, когда добавляете КОД в интерфейс. О чем Вам, кстати, и господин WolfHound твердил.


Это снова зависит от определений терминов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[25]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:35
Оценка:
Здравствуйте, criosray, Вы писали:

C>var a = "str";

C>var b = "str";

C>Точно ref equal.

Принято.

Кстати еще интересно, это не на этапе компиляции случайно происходит?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[23]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

CC>>Опять приходим к вопросу: если две одинаковые (в итоге) строки получены из разных источников, будут ли они ссылаться на одну и ту же область памяти?

S>Нет, не будут. По очевидным причинам: заниматься ерундой типа проверки уникальности при каждой операции получения строки — тратить перформанс непонятно на что.
В общем то так и ожидалось.

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

Ну наконец то спокойный ответ с полезной ссылкой без фанатских причитаний.
Thx, полез читать.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[23]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 12:35
Оценка:
Здравствуйте, criosray, Вы писали:

C>Так и есть — в С++ зоопарк глючных, несовместимых реализаций строк. А в исходниках каша из std::wstring, CWSTRPTR (spelling), CString, QString, wchar и десятков аллиасов.

Это скорее проблемы человеческой неорганизованности нежели языка.
Почему то такие проблемы есть далеко не у всех.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[21]: Ну ты вообще многого не видишь... ;)
От: Юрий Жмеренецкий ICQ 380412032
Дата: 02.06.09 12:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Игoрь, Вы писали:

S>>>Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
И>>Например, и почему эти алгоритмы нельзя сделать эффективно на С++?
S>Например потому, что придется делать по две версии алгоритмов — на случай передачи в них константной строки, и неконстантной строки.

Есть очень большая вероятность того, что писать две версии не придется, т.к. алгоритмам (внешним) все равно с какими типами итераторов работать, а внутренние (находящихся в std::basic_string) просто представляют собой вызовы обобщенных.

А вот, например, эффективную конкатенацию строк можно сделать (и сделано в одной из реализаций) с помощью expression templates, но к иммутабельности это не особо относится. Если копнуть глубже — в стандарте нет явного (хотя есть пару дефектов по этому поводу) требования хранить строки одним непрерывным куском.
Re[21]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 12:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Игoрь, Вы писали:

S>>>Иммутабельность строк позволяет делать крайне эффективными различные алгоритмы.
И>>Например, и почему эти алгоритмы нельзя сделать эффективно на С++?
S>Например потому, что придется делать по две версии алгоритмов — на случай передачи в них константной строки, и неконстантной строки.
Опять начинается путаница. Если мы говорим в пониманиии константности С++, то это неверно. Алгоритм требующий константности объекта, априори будет работать и для неконстантного объекта, просто из-за того, что константность более жесткое ограничение.
С другой стороны, если мы в понятие константности строки включаем еще и фиксированное размещение ее в памяти или в каком-то сторадже. Ну да, там можно использовать какие-то оптимизации в виде хэш == адрес. Но таких алгоритмов раз два и обчелся, а кроме того ведь в таком подходе C# есть и недостатки. Например, если идет относительно активная работа с текстом, включая его изменения, то почему я должен на каждый чих создавать копию строки? Опять эффективность, но уже в другую сторону.
Re[3]: За что я не люблю С++
От: Erop Россия  
Дата: 02.06.09 12:43
Оценка:
Здравствуйте, criosray, Вы писали:

C>На МакОСи, например, не пишут почти на С++. У них есть Objective-C, которого как оказывается тоже на многое хватает.


Ага-ага. И что, офис или БД какая там на Objective-C? Или ядро OS может на Objective-C?
На Objective-C там морда вроде...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[4]: За что я не люблю С++
От: criosray  
Дата: 02.06.09 12:56
Оценка:
Здравствуйте, Erop, Вы писали:

C>>На МакОСи, например, не пишут почти на С++. У них есть Objective-C, которого как оказывается тоже на многое хватает.


E>Ага-ага. И что, офис или БД какая там на Objective-C?

iWork. Почти все родные cocoa-приложения на ObjC.

E>Или ядро OS может на Objective-C?

Как и в других ОС ядро на С.
Re[22]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 13:01
Оценка:
Здравствуйте, Игoрь, Вы писали:

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


Откройте для себя System.Text.StringBuilder.
Re[23]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 13:16
Оценка:
Здравствуйте, criosray, Вы писали:

C>Откройте для себя System.Text.StringBuilder.

Первое. Читай внимательно, я в курсе.
Второе. Если хочешь, чтобы тебе отвечали не в стиле — "сам дурак", научись нормально разговаривать.
Re[25]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 13:17
Оценка:
Здравствуйте, criosray, Вы писали:

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

CC>>Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.

C>Все дело именно в таких вот мелочах.

C>Кстати, а С++ уже научился nullable типам?

Твои посты поражают логикой и внятностью.
Каким боком это вдруг к обсуждаемой теме?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 02.06.09 13:43
Оценка:
Здравствуйте, criosray, Вы писали:

C>Кстати, а С++ уже научился nullable типам?

Нет, А нафига?
Но в принципе можно поизвращаться и научить
Class nullable
Re[26]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 13:59
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

CC>>>Честно говоря там ИМХО нет ничего такого, что было бы killer feature. Так, мелкие приятности.

C>>Все дело именно в таких вот мелочах.

C>>Кстати, а С++ уже научился nullable типам?

CC>Твои посты поражают логикой и внятностью.

Какие проблемы с моей логикой?
CC>Каким боком это вдруг к обсуждаемой теме?
Тема называется "За что я не люблю С++". Не заметили?

Так что можете ответить про nullable типы?
Re[26]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 14:06
Оценка:
Здравствуйте, Игoрь, Вы писали:

C>>Кстати, а С++ уже научился nullable типам?


И>
И>int* n = null;
И>


И>Нашел чем гордиться


Это не nullable тип.

Перепишите на С++ и сами поймете
int? a = 1;
int c = 10;
int b = (a ?? c) / 100;
Re[27]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 02.06.09 14:31
Оценка:
Здравствуйте, criosray, Вы писали:

CC>>Твои посты поражают логикой и внятностью.

C>Какие проблемы с моей логикой?
CC>>Каким боком это вдруг к обсуждаемой теме?
C>Тема называется "За что я не люблю С++". Не заметили?
Ну так писал бы коммент к начальному сообщению.
В этой подветке обсуждали строки.

C>Так что можете ответить про nullable типы?

Хочешь еще одну волну бесполезного флейма поднять чтоб замять тему со строками?
В этой ветке — только про строки.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[27]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 02.06.09 14:32
Оценка:
Здравствуйте, criosray, Вы писали:

C>Здравствуйте, Игoрь, Вы писали:


C>>>Кстати, а С++ уже научился nullable типам?


И>>
И>>int* n = null;
И>>


И>>Нашел чем гордиться


C>Это не nullable тип.


C>Перепишите на С++ и сами поймете

C>
C>int? a = 1;
C>int c = 10;
C>int b = (a ?? c) / 100;
C>


Вообщето похоже

    int* p = NULL;
    int a = 1;
    int c = 10;
    p = &a;
    int b = ( p == NULL ? c : *p) / 100;
Re[28]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 14:42
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>
_>    int* p = NULL;
_>    int a = 1;
_>    int c = 10;
_>    p = &a;
_>    int b = ( p == NULL ? c : *p) / 100;
_>


Можно чуть короче, явно не делать проверку на NULL:

int* p = NULL;
int a = 1, c = 10;

int b = (p? *p : c) / 100;
Re[19]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 15:03
Оценка:
Здравствуйте, WolfHound, Вы писали:


WH>const это фигня на постном масле.

WH>Ибо изменяемость/не изменяемость должны быть неотъемлемым свойством типа, а не модификатором.
WH>Тогда сразу открывается возможность для кучи доказательства кучи свойств кода и как следствие более агрессивных оптимизаций. Про такую "мелочь" как увеличение надежности и предсказуемости кода для разработчика я вообще молчу.
Мы сейчас говорим о конкретных языках или "вообще"? Если говорить "вообще", то я могу согласиться, что в С++ константность — это сбоку бантик, который легко снимается конст-кастом. И это все дело можно было бы сделать намного лучше, делая сейчас и не думая об обратной совместимости. С этим я как бы и не спорю. Но только при чем здесь C++ и C#?

WH>Этот огород исключительно из-за того что мелкософты не осилили эффективную реализацию строк.

И с этим я не спорю, и то, что они могли сделать нормально — согласен, но сейчас есть то, что есть. А то что есть не особо лучше того, что есть в С++.
Re[29]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 02.06.09 15:04
Оценка:
Здравствуйте, Игoрь, Вы писали:

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


_>>
_>>    int* p = NULL;
_>>    int a = 1;
_>>    int c = 10;
_>>    p = &a;
_>>    int b = ( p == NULL ? c : *p) / 100;
_>>


И>Можно чуть короче, явно не делать проверку на NULL:


И>
И>int* p = NULL;
И>int a = 1, c = 10;

И>int b = (p? *p : c) / 100;
И>


То есть ради такой єлементарщины надо вводить доп. переменную?
Ок.
Усложним задачу:

int? a = 1;
int c = 10;
int? b = (a == null ? a : c) / 100;
Re[29]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 02.06.09 15:11
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>
И>int* p = NULL;
И>int a = 1, c = 10;

И>int b = (p? *p : c) / 100;
И>

Ну так, <censored> нам кабанам, обобщим, и научим тупой С++ работать с nullable

template <typename T>
class nullable
{
public:
    nullable(T* p ,T val )
    { 
        res =  p ? *p : val  ;
    }
    T res;
};

int main(int argc, char* argv[])
{
    int* p = NULL;
    int a = 1;
    int c = 10;
    p = &a;
    
    b = nullable<int>(p,c).res / 100;

    return 0;
}
Re[20]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 02.06.09 15:26
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>Мы сейчас говорим о конкретных языках или "вообще"? Если говорить "вообще", то я могу согласиться, что в С++ константность — это сбоку бантик, который легко снимается конст-кастом. И это все дело можно было бы сделать намного лучше, делая сейчас и не думая об обратной совместимости. С этим я как бы и не спорю. Но только при чем здесь C++ и C#?

C# тут действительно не причем.
Тут С++ мочат

И>И с этим я не спорю, и то, что они могли сделать нормально — согласен, но сейчас есть то, что есть. А то что есть не особо лучше того, что есть в С++.

По своему опыту могу сказать что таки сильно лучше.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[21]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 15:57
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Тут С++ мочат

Пытаются, сравнивая его с C#

И>>И с этим я не спорю, и то, что они могли сделать нормально — согласен, но сейчас есть то, что есть. А то что есть не особо лучше того, что есть в С++.

WH>По своему опыту могу сказать что таки сильно лучше.
Ну так может ты приведешь конкретные примеры из твоего опыта, особенно интересны связанные с mutable/immutable? Потому что я серьезных преимуществ пока не вижу, кроме как иногда хочется в С++ использовать что-то более легковесное а-ля const_string, только не как замену string. С другой стороны и в C# иногда хочется использовать какой-то аналог string с возможностью записи.
Re[20]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 02.06.09 16:42
Оценка:
Здравствуйте, criosray, Вы писали:

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



C>>То, как сделано в С# — ГОРАЗДО лучше. Строки обязаны быть immutable по той причине, что:

C>>var str = "abc";
C>>var str2 = "abc2";
C>>ссылаются на один и тот же участок памяти str == str2 true.

C>Опечатка. str2 = "abc" конечно же.


Кстати, а что мешает и варианты "abc" и "abc2" хранить в одной области(имеется ввиду сами буфферы, объекты будут разными в любом варианте)?
Длина заключена в объекте(а не определяется положением терминирующего символа), при этом строки никогда не будут изменены.
Так ли это в реале, не знаю, но ничего не мешает так устроить.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[22]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 02.06.09 17:09
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>Пытаются, сравнивая его с C#

Ты меня с кем-то путаешь.

И>Ну так может ты приведешь конкретные примеры из твоего опыта, особенно интересны связанные с mutable/immutable?

С immutable всегда проще.
Причем это не только строк касается.
Особенно если язык заточен на работу в этом стиле.
Тут
Автор: WolfHound
Дата: 01.06.09
я уже приводил пример кода работающего исключительно с неизменяемыми данными.
Даже если этот код оставить на немерле но переписать так чтобы AST изменялся по месту получится серьезное усложнение.
Со строками все не так печально но там тоже хватает головной боли особенно в многопоточной среде.

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

И создать еще одну строку...

И>С другой стороны и в C# иногда хочется использовать какой-то аналог string с возможностью записи.

Зачем?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: За что я не люблю С++
От: yuriylsh  
Дата: 02.06.09 17:34
Оценка:
Здравствуйте, 0xC0000005, Вы писали:

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


C>...

C>>Специально для Вас выделил ключевое.

C>Вы так умело затёрли вашу цитату, выделю главное, и больше не мозольте эту тему, вы ПИСАЛИ:


C>

C>Интерфейс по определению ничего не может делать. Интерфейс это чисто контракт. Не выдумывайте своих определений общеизвестных терминов.


C>Потом вы пишете


C>

C>А никто и не утверждал, что интерфейс является полным контрактом класса


C>Не будем углубляться в аспекты русского языка, но если к примеру колесо это неотьемлемая часть машины (давайте не разводить демагогию о том какие бывают машины), то нельзя написать:

C>Колесо — это чисто машина.
C>Надеюсь в этот раз я вас не запутал и привёл нормальные доводы.

Мне кажется, ты не прав. Например, я утверждаю что Подработка это чисто доход. При этом я не утверждаю, что подработка это полный мой доход. Это часть полного дохода.
Luck in life always exists in the form of an abstract class that cannot be instantiated directly and needs to be inherited by hard work and dedication.
Re[30]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.09 18:10
Оценка:
Здравствуйте, criosray, Вы писали:

C>Ок.

C>Усложним задачу:

C>
C>int? a = 1;
C>int c = 10;
C>int? b = (a == null ? a : c) / 100;
C>


Простейшее решение:

template<typename T>
struct Nullable {
  T val;
  Nullable() : null_(true){}
  Nullable(const T &rhs) : val(rhs), null_(false){}
  bool isNull() const { return true; }
  operator const T &() { if (null_) throw /* что надо, то и выкидываем */; return val; }
  const Nullable & operator = (const T &rhs) { val = rhs; null_ = false; return *this; }
private:
  bool null_;
};

// ...
Nullable<int> a(1);
int c = 10;
Nullable<int> b = a.isNull() ? a : (c / 100);


Арифметику и логические операции можно добавить по вкусу.

P.S.: Про строки
Автор: Геннадий Васильев
Дата: 02.06.09
, я так понимаю, ответа не будет?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 02.06.09 18:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>И создать еще одну строку...

А в чём проблема? Реализаций строк можно иметь хоть мильён. Работа с таким зоопарком просто и складно унифицируется набором свободных функций типа такого:

template<typename Str1_, typename Str2_> void assign(Str1_ *, const Str2_ &);
template<typename Str_> int getLength(const Str_ &);
template<typename Str1_, typename Str2_> int getSubstring(Str1_ *, const Str2_ &, int pos, int length);


Некоторое исключение составляют ASCIIZ-строки, с остальными особых заморочек нет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[23]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 02.06.09 21:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

И>>Ну так может ты приведешь конкретные примеры из твоего опыта, особенно интересны связанные с mutable/immutable?

WH>С immutable всегда проще.
WH>Причем это не только строк касается.
WH>Особенно если язык заточен на работу в этом стиле.
WH>Тут
Автор: WolfHound
Дата: 01.06.09
я уже приводил пример кода работающего исключительно с неизменяемыми данными.

WH>Даже если этот код оставить на немерле но переписать так чтобы AST изменялся по месту получится серьезное усложнение.
Не, ну хорошо, кто бы спорил. Раз подходит для каких-то задач, замечательно. Мне такое пока не нужно.


WH>Со строками все не так печально но там тоже хватает головной боли особенно в многопоточной среде.

Вот как раз с многопоточностью и строками я как-то никогда проблем не имел.

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

WH>И создать еще одну строку...
Иногда для оптимизации и не такое приходится делать, например выкидывать std::vector, из-за того, что тот свой буфер зануляет.

И>>С другой стороны и в C# иногда хочется использовать какой-то аналог string с возможностью записи.

WH>Зачем?
Например есть строки размером от 50КБ до 5МБ, надо найти и вырезать какие-то куски без лишних релокейшинов. Все что мне нужно — хоть простой набор алгоритмов над текстовым writable буфером.
Re[25]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 03:49
Оценка:
Здравствуйте, criosray, Вы писали:
C>Точно ref equal.
Если в одной сборке
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 04:06
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Арифметику и логические операции можно добавить по вкусу.
Кстати, там лифтинг заработает?
Лифтинг — это когда все операторы, определенные для типа T, автоматически определяются для типа Nullable<T> — соответствующим образом, то есть возвращают Nullable<T>, который null, когда хотя бы один из операндов Null.
Но если какого-то оператора у T нет, то ошибка будет только при попытке вызвать аналогичный оператор для Nullable<T>, а не при попытке сконструировать Nullable<T>.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 04:06
Оценка:
Здравствуйте, Erop, Вы писали:
E>А рзве она в Юникод укладывается?
А разве нет? http://wakaba-web.hp.infoseek.co.jp/table/sjis-0208-1997-std.txt
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 04:06
Оценка:
Здравствуйте, Eugeny__, Вы писали:
E__>Кстати, а что мешает и варианты "abc" и "abc2" хранить в одной области(имеется ввиду сами буфферы, объекты будут разными в любом варианте)?
E__>Длина заключена в объекте(а не определяется положением терминирующего символа), при этом строки никогда не будут изменены.
E__>Так ли это в реале, не знаю, но ничего не мешает так устроить.
В Java именно так работает выделение подстроки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 04:23
Оценка:
Здравствуйте, CreatorCray, Вы писали:
CC>А если это не так (что скорее всего) то тогда получается что уже в качестве ключей их использовать упс... И память они уже не экономят...
Экономия памяти — ерунда. Шансов на то, что две строки совпадут — практически нуль.
Зато гарантированная константность позволяет использовать хеш строки в качестве части ключа.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 03.06.09 07:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

Мы сейчас сравниваем вшитую в язык имплементацию, от которой в общем то никуда не деться и дефолтную библиотечную имплементацию, которой никто не заставляет пользоваться.
Какой в этом вообще смысл?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 03.06.09 07:15
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>Мы сейчас говорим о конкретных языках или "вообще"? Если говорить "вообще", то я могу согласиться, что в С++ константность — это сбоку бантик, который легко снимается конст-кастом. И это все дело можно было бы сделать намного лучше, делая сейчас и не думая об обратной совместимости.

Пока есть указатели в С++ никогда не сделать неснимаемый const.
Нельзя сделать напрямую — сделаем через память.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[26]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.06.09 07:46
Оценка:
Здравствуйте, CreatorCray, Вы писали:
S>>В С++ по давней традиции, смешивают две эти сущности в одну. Итоговый результат одинаково плохо выполняет обе задачи.
CC>Мы сейчас сравниваем вшитую в язык имплементацию, от которой в общем то никуда не деться и дефолтную библиотечную имплементацию, которой никто не заставляет пользоваться.
Хм. Мы сейчас сравниваем два фреймворка. В одном вшита реализация обоих примитивов — "строка как значение" и "конструктор текстов". Плюс, если рассматривать С#, есть еще и два синтаксиса строковых констант для разных случаев.
В другом фреймворке вшита одна реализация строковых констант и одна реализация класса строк. Обе вшитых вещи бесконечно убоги — я уже написал, почему.
Мало того, поскольку традиции разделения примитивов в С++ нет, то и "недефолтные" реализации в массе своей страдают от всех недостатков "дефолтных". Смотреть, например, в класс CString. К сожалению, этот подход обеспечивает бесполезность написания хороших "недефолтных" реализаций — они будут замкнуты в своём мирке. К примеру, нельзя опубликовать библиотеку строковых алгоритмов, оптимизированных под иммутабельные строки — они не будут нормально интероперировать с другими библиотеками.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 03.06.09 08:35
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Тут С++ мочат

Уже дофига лет... И всё никак
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[32]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.09 09:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

ГВ>>Арифметику и логические операции можно добавить по вкусу.

S>Кстати, там лифтинг заработает?
S>Лифтинг — это когда все операторы, определенные для типа T, автоматически определяются для типа Nullable<T> — соответствующим образом, то есть возвращают Nullable<T>, который null, когда хотя бы один из операндов Null.
S>Но если какого-то оператора у T нет, то ошибка будет только при попытке вызвать аналогичный оператор для Nullable<T>, а не при попытке сконструировать Nullable<T>.

Да, можно. Только нужно будет определить все операторы непосредственно в Nullable. Тогда ошибки (буде таковые возникнут) будут выбрасываться в месте вызова соответствующих операторов. Единственное, в чём я не уверен — в 100% переносимости.

Выглядит это приблизительно так:

// Оператор Nullable::operator ==
    template<typename U>
    Nullable<bool> operator == (const U &rhs) const
    {
      if (isNull() || ::isNull(rhs))
        return Nullable<bool>();
      return val_ == (const T &)rhs;
    }

// Пара свободных функций:
template<typename T> inline bool isNull(const Nullable<T> &v)
{
  return v.isNull();
}

template<typename T> inline bool isNull(const T &)
{
  return false;
}

// Пример использования:
struct X { int a; int b; };

void foo() {
  Nullable<X> v1, v2; // Ошибки нет

  if (v1 == v2) // Здесь ошибка
  { 
  }
}
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.09 09:04
Оценка:
Здравствуйте, CreatorCray, Вы писали:

WH>>Тут С++ мочат

CC>Уже дофига лет... И всё никак

Эпическая битва, можно сказать.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[33]: дополнение
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 03.06.09 09:14
Оценка:
ГВ>Только нужно будет определить все операторы непосредственно в Nullable.

Или как набор свободных операторов, функций и т.п.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 03.06.09 10:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


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

CC>>>Вот только какая может быть выгода от именно таких строк в С++ мне например неясно.
S>>Очень простая. Например, иммутабельные строки могут быть ключами в хештаблицах.
CC>Опять приходим к вопросу: если две одинаковые (в итоге) строки получены из разных источников, будут ли они ссылаться на одну и ту же область памяти?

[так в жабе, в шарпе — не помню]
Скажем так, они могут ссылаться на один и тот же буфер. Например, если одна из них ранее была получена методом substring другой. Так как этот метод не создает нового буфера. Он просто создает новый объект String на основе того же буфера чаров, но с другим индексом начала в этом буфере и другой длиной.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[27]: можно + нет =def= НЕ НУЖНО!!!
От: Erop Россия  
Дата: 03.06.09 22:26
Оценка:
Здравствуйте, criosray, Вы писали:

C>Я не сомневаюсь, что можно, но между можно и есть очень большая разница.


Эх, у старых, популярных, обременнённых годами истории велосипедостроительства языков "можно + нет =def= НЕ НУЖНО!!!"
Так как воспроизвести шарповую схему работы со строками на С++ проблемы никакой нет, но не пользуется оно популярностью, то это обозначает, что в данном случае преимущества не ясны, так скажем...

Может быть ты их понятно расскажешь? То, что на совпадение указателей, в случае идентичных строчек, рассчитывать нельзя мы уже выяснили... Что ещё "является" преимуществом иммутабельных строк?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[24]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 03.06.09 22:27
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>Счетчик в буфере? Это как? Объясните на пальцах, если не сложно.

CC> Ты точно на С или С++ писал? Или как работать с памятью и указателями уже забыл?
IMHO, он просто кушать хочет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[23]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 03.06.09 22:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Да-да, вы как раз вносите путаницу. Конечно же, алгоритм, заложившийся на константность объекта, никак не сможет работать с неконстантым. Например, из константности мы можем вывести возможность не делать блокировок при обращении; можем полагаться на то, что хеш будет неизменным; много на что еще можем полагаться. Неконстантность ничего этого не даёт, поэтому алгоритмы на С++ невозможно оптимизировать подобным образом.

Тем не менее в С++ именно так и делают...

Единственная проблема -- это разделяемая между нитями константная строка, которую иногда таки меняют...
Но такие же проблемы вызывают любые другие данные. Например, разделяемое между нитями число...
Для чисел же мы не нуждаемся в NumberBuildere? Чем строки так сильно отличаются?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: За что я не люблю С++
От: Erop Россия  
Дата: 03.06.09 22:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

E>>А рзве она в Юникод укладывается?
S>А разве нет? http://wakaba-web.hp.infoseek.co.jp/table/sjis-0208-1997-std.txt

Ну и как будет, например 0x8790?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[28]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 03:01
Оценка:
Здравствуйте, Erop, Вы писали:

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


S>>Мало того, поскольку традиции разделения примитивов в С++ нет, то и "недефолтные" реализации в массе своей страдают от всех недостатков "дефолтных". Смотреть, например, в класс CString. К сожалению, этот подход обеспечивает бесполезность написания хороших "недефолтных" реализаций — они будут замкнуты в своём мирке. К примеру, нельзя опубликовать библиотеку строковых алгоритмов, оптимизированных под иммутабельные строки — они не будут нормально интероперировать с другими библиотеками.


E>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п.

E>Тем более, что никаких принципиальных трудностей на этом пути нет...
Есть, причем офигеть какие.
1)Совместимость. Даже если сделать immutable-строки, все равно во многих местах понадобится передавать char*. Если этот char* отдавать из внутреннего буфера, то попа ибо от иммутабельности ничего не останется. Если копировать, то перфоманс просядет заничтельно.
2)Управление памятью. Если выполнить a = b + c для строк, то кто будет освобождать b и с? Повесить все это на shared_ptr — тормоза начнутся похлеще .net_овсих

E>2) Хотелось бы понять, чем строка отличается от числа. Почему числа могут представлять сами себя и иметь модифицирующие себя же операторы, а строки -- нет? Что этому препятствует? Эффективность? Какая-то особенность семантики строк? Что-то ещё?

Где такую траву берешь? Какие у чисел возожности по модификации себя? Ты разыве можешь написать 1.setBit(4)?
В том то и дело что в большинстве программ строкам нужна семантика значений, как у чисел. Только в малом проценте нужна семантика массива.

E>3)Должны ли, кроме строк, ещё и массивы букв иметь иммутабельную семантику? Если да, то почему это не так в большинстве языков, во всяком случае?

Не недо показвать свою безграмотность. В некоторых языках строки ассоциируются не с массивами, а с immutable списками. Ты же смотришь на строки только как на массивы байт.
E>Если нет, то в чём принципиальная разница между массивом букв и строкой?
Огромная разница.
Re[24]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 03:47
Оценка:
Здравствуйте, Erop, Вы писали:
E>Тем не менее в С++ именно так и делают...
Пример в студию.

E>Единственная проблема -- это разделяемая между нитями константная строка, которую иногда таки меняют...

Да, совершенно верно. Что такое "константная строка"???
Вот я отдал в другой тред указатель на строку. Ну, то есть понятно, что выполнять полное копирование — слишком дорого. Если у этого указателя семантика реф-типа, то необходимо обеспечить механизмы блокировки. Чтобы два треда не поменяли содержимое строки. В иммутабл строках никаких блокировок не нужно — если указатель указывал на Hello World, то он всегда будет указывать на Hello World.

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

Нет, не такие же. Обычный способ передачи чисел "по значению" — это копирование. Для строк его точная эмуляция приведет к просаду производительности.
Передача "по ссылке" бывает значительно реже. И с ней, естественно, будут ассоциированы аналогичные проблемы.
E>Для чисел же мы не нуждаемся в NumberBuildere? Чем строки так сильно отличаются?..
Тем, что числа не нужно модифицировать. Они настолько дёшевы, что можно просто выбросить предыдущее значение и заменить его новым.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 03:47
Оценка:
Здравствуйте, Erop, Вы писали:
E>Ну и как будет, например 0x8790?
U+2252?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 04.06.09 04:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

E>>Тем не менее в С++ именно так и делают...

S>Пример в студию.
Пример чего? Какого-нибудь алгоритма принимающего на вход константную строку? Ну поиск подстроки в строке, например...

S>Да, совершенно верно. Что такое "константная строка"???

Ну строка константная, константная строка... В С++ данные можно объявлять константными. Я думаю, что ты в курсе этого факта...

S>Вот я отдал в другой тред указатель на строку. Ну, то есть понятно, что выполнять полное копирование — слишком дорого. Если у этого указателя семантика реф-типа, то необходимо обеспечить механизмы блокировки. Чтобы два треда не поменяли содержимое строки. В иммутабл строках никаких блокировок не нужно — если указатель указывал на Hello World, то он всегда будет указывать на Hello World.


Что мешает публиковать уже константный указатель?..

E>>Для чисел же мы не нуждаемся в NumberBuildere? Чем строки так сильно отличаются?..

S>Тем, что числа не нужно модифицировать. Они настолько дёшевы, что можно просто выбросить предыдущее значение и заменить его новым.

Ну то есть выражения вида a |= 16 не нужны, и даже вредны?

Кста, ты тут много раз заметил, что авторы шарпа не смогли родить мутабельную строку, которая могла бы быть эффективным значением... IMHO, разделение на два класса происходит именно оттуда...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: За что я не люблю С++
От: Erop Россия  
Дата: 04.06.09 04:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>U+2252?

а разве такой есть? Это вроде как самодеятельность MS?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[26]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 05:50
Оценка:
Здравствуйте, Erop, Вы писали:

E>Пример чего? Какого-нибудь алгоритма принимающего на вход константную строку? Ну поиск подстроки в строке, например...

Ну, покажи мне этот алгоритм, его декларацию, и способ, которым он сделан потокобезопасным.

E>Ну строка константная, константная строка... В С++ данные можно объявлять константными. Я думаю, что ты в курсе этого факта...

Я понимаю. Я не понимаю, каким образом кто-то собрался менять константную строку.

E>Что мешает публиковать уже константный указатель?..

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

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

Значение иммутабельно по определению.

E>IMHO, разделение на два класса происходит именно оттуда...

Разделение на два класса происходит из глубокого понимания окружающей действительности. Равно как и, к примеру, отделение кодировки от строки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: За что я не люблю С++
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 05:50
Оценка:
Здравствуйте, Erop, Вы писали:

E>а разве такой есть? Это вроде как самодеятельность MS?

http://www.fileformat.info/info/unicode/char/2252/index.htm
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.06.09 05:57
Оценка:
Здравствуйте, Erop, Вы писали:

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


E>Чтобы не дробить обсуждение, я сразу на оба отвечу...


E>>>1) IMHO, если бы от такого разделения на константные строки и фабрики строк была какая-то реальная польза, в C++ уже бы давно были бы популярны такие библиотеки. В книжках бы были кучи примеров, как это реализовать и т. п.

E>>>Тем более, что никаких принципиальных трудностей на этом пути нет...
G>>Есть, причем офигеть какие.
G>>1)Совместимость. Даже если сделать immutable-строки, все равно во многих местах понадобится передавать char*. Если этот char* отдавать из внутреннего буфера, то попа ибо от иммутабельности ничего не останется. Если копировать, то перфоманс просядет заничтельно.
E>Зачем куда-то передавать сhar*, и как C# этого удаётся избежать? Если речь идёт об API, то там обычно входные строки именно const char*... Просто иногда С-шные хедеры декларируют функции без const, но это не является содержательной проблемой.
.NET это обходит на уровне рантайма и передачай StringBiilder в том случае когда переданная строка меняется.

E>Можно, например, написать к нужному API обёртки...

Ну можно и .NET написать, только дорого это выйдет.

G>>2)Управление памятью. Если выполнить a = b + c для строк, то кто будет освобождать b и с? Повесить все это на shared_ptr — тормоза начнутся похлеще .net_овсих

E>Почему? Можно же не в shared_ptr всё засунуть, а в аналог imtrusive_ptr...
А разница небольшая. В любом случае надо как-то обеспечивать автоматическое освобождение, которое в C++ стоит дороже, чем в .NET. А если учесть что и выделение памяти под строки будет дороже, чем в .NET, то смысла в создании такого нету.

G>>Где такую траву берешь? Какие у чисел возожности по модификации себя? Ты разыве можешь написать 1.setBit(4)?

E>1 -- это литерал. Литералы иммутабельны по своей семантике. Строковые литералы тоже иммутабельны. Скажем "мама".clear() ты тоже написать не можешь. А если число не литерал, а неконстантная переменная, то ты можешь написать так:
int i = 1;
E>i |= ( 1 << 4 );

Ты сам понял что присваивание написал?
Ни одной операции, меняющей переменную i на месте написать ты не сможешь.

G>>В том то и дело что в большинстве программ строкам нужна семантика значений, как у чисел. Только в малом проценте нужна семантика массива.

E>В STL std:vector требует семантику значения (это как у чисел) от своих элементов, и сам, в свою очередь, имеет такую семантику. Так, например, возможен вектор векторов.
То что он требует это его личное дело.
Ведь мало кто передает векторы по значению, обычно передают по ссылке.

E>>>...Если да, то почему это не так в большинстве языков, во всяком случае?

G>>Не недо показвать свою безграмотность. В некоторых языках...
E>Ну если под безграмотностью ты понимаешь неумение читать, то да, не надо.
E>Кста, в С++ нет проблем задавать строку в виде списка. Мало того, stl::basic_string не обязана хранить строку в массиве... Просто таких реализаций stl нет, я думаю потому, что они не нужны...

Потому что в C++ они неэффективны\небезопасны

G>>...строки ассоциируются не с массивами, а с immutable списками. Ты же смотришь на строки только как на массивы байт.

E>Да нет, я вообще не вижу разницы между списком и массивом. Если тебе список букв милее, пусть будет список. Любой контейнер для хранения ПОСЛЕДОВАТЕЛЬНОСТИ элементов годится. Мы же о семантике говорим вроде, а не о чём-то ещё? Какая тогда разница, как именно это реализовано?
Ну правильно. Семантика такова что с массивом символов приходится очень редко иметь дело.

E>Итак, нужно ли требовать иммутабельности от любой последовательности букв? Если да, то почему не требуют? Если нет, то чем строка так отличается от последовательности букв?

Семантикой. См выше.

S>>Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.

E>Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ... А что, смогли что ли?
Еще раз повторяю.
От строк редко требуется семантика массива символов. При другой семантике реализация через изменяемый массив неэффективна.


E>Кста, по поводу того, что про сценарии со строками мы знаем намного больше чем про сценариями с последовательностями букв -- хотелось бы поконкретнее этот тезис чтобы был развёрнут! А то как-то не понятно что мы такое знаем про строки, чего про последовательности букв не знаем... ПОЧЕМУ нужны иммутабельные и нет строки, но НЕ НУЖНЫ иммутабельные последовательности букв?

Сам понял что сказал?

E>>>Если нет, то в чём принципиальная разница между массивом букв и строкой?

G>>Огромная разница.
S>>от этого есть реальная польза. И во фреймворках, разработанных после С++, такое разделение уже существует пятнадцать лет.

E>Как-то вы ребята исключительно неконкретны...

E>Если gandjustas хотя бы попробовал привести пару доводов от чего иммутабельную строку якобы нельзя создать на С++, то второй собеседник ограничивается исключительно декларациями и отсылками к весьма бессмысленным, IMHO, документам.
E>Например я могу назвать фреймворк, который был разработан после появления С++ и строки там мутабельные, так же как и числа: MFC, STL, ATL, QT... хватит?
Да, особенно пример с числами приведи, когда выражение с числом меняет само число, а не создает новое.
Чтобы было прмерно так: int i; i someOp param; и число i после этого изменилось.


E>Вы можете таки ответить конкретно:

E>Преимущества такие: раз, два, три.
E>Отличие по семантике от последовательности букв (списка, массива, верёвки, очереди и т. д.) состоит в том-то и том-то, из чего следует нужда в иммутабельности.
E>Отличие по сеантике значения от чисел такие: раз, два, три...
Неизменяемая семантика строк позволяет передавать строку куда угодно (в том числе и в другие потоки) и не беспокоиться о том что её может кто-то поменять.
Причем это не "дохленький" const в C++, а реальные гарантии, которые позволяют более оптимально строки использовать.
Например при выделении подстроки не копировать, а создавать строку с со сдвинутыми указателями на внутренний буфер.
Также immutable семантика позволяет быстро сравнивать сроки, так как хеш строки можно закеширвать, а используя что-то вроде Intern Pool можно вообще ограничиться ссылочным сравнением.
Re[29]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 07:51
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

_>>Только вот к сожалению, окружающая среда про это ничего не знает Иногда в программе бывает очень полезно удобно и самое главное — эффективно использовать разные типы строк (wstring, string, bstr — разные и т.п, в том числе и самописные строки) именноо из-за разнообразия окружающей среды.
S>Все эти типы строк, которые кажутся вам разными, отличаются в незначительных аспектах представления. Поведение строк сводится всего к двум контрактам, для которых в дотнете и предусмотрены разные типы.
Вон оказывается оно как Только причем здесь окружающая среда? Замечательно если вы сами можете определять контракты и аспекты представления, ну а если Вам нужно взаимодествовать с какой-то legacy аппликацией написанной 20 лет назад и использующей свой собственный извращенный стринг, что делать то? Впрочем спорить не буду, возможно в 95% процентах случаев дотнетовский стринг вполне удобен, используйте и радуйтесь. Меня же радует в С++ многообразие стрингов из разных библиотек и возможность выбора наиболее подходящего и эффективного для каждого конкретного случая.
Re[31]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 08:04
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

E>>Зачем куда-то передавать сhar*, и как C# этого удаётся избежать?
S>В C# char* запрещён.

Хм. А в MSDN я вот такое увидел

fixed (char* p = str) ... // equivalent to p = &str[0]

Мне вообще-то как-то больно узнать, что он запрещен. Дело в том, что в моей программе на C# используется правда не char*, а sbyte* сплошь и рядом. Как мне иначе-то делать, если программа — интерфейс к неуправляемой DLL, написанной на презренном C++, которая только и знает экспортировать всякие char*, и char** ( в смысле C/C++, то есть однобайтовые).

With best regards
Pavel Dvorkin
Re[30]: Ну ты вообще многого не видишь... ;)
От: Mamut Швеция http://dmitriid.com
Дата: 04.06.09 08:14
Оценка:
a> Вон оказывается оно как Только причем здесь окружающая среда? Замечательно если вы сами можете определять контракты и аспекты представления, ну а если Вам нужно взаимодествовать с какой-то legacy аппликацией написанной 20 лет назад и использующей свой собственный извращенный стринг, что делать то? Впрочем спорить не буду, возможно в 95% процентах случаев дотнетовский стринг вполне удобен, используйте и радуйтесь. Меня же радует в С++ многообразие стрингов из разных библиотек и возможность выбора наиболее подходящего и эффективного для каждого конкретного случая.

Угу, потом пытаешься скрестить QString с bt_str и материшься трехэтажным матом
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[31]: i++; ++i; ;) (-)
От: Erop Россия  
Дата: 04.06.09 08:22
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Чтобы было прмерно так: int i; i someOp param; и число i после этого изменилось.

i++;
Но это всё не о том спор. Есть некие "значения" строк, они неизменны, так как являются абстракцией существующей исключительно в нашей голове. Ну там скажем строка "мама" или число "0,5"...
А есть переменные, которые могут принимать то или иное значение. Значения, конечно, менять нельзя, но содержащие их переменные иногда можно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[31]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 08:32
Оценка:
Здравствуйте, Mamut, Вы писали:

a>> Вон оказывается оно как Только причем здесь окружающая среда? Замечательно если вы сами можете определять контракты и аспекты представления, ну а если Вам нужно взаимодествовать с какой-то legacy аппликацией написанной 20 лет назад и использующей свой собственный извращенный стринг, что делать то? Впрочем спорить не буду, возможно в 95% процентах случаев дотнетовский стринг вполне удобен, используйте и радуйтесь. Меня же радует в С++ многообразие стрингов из разных библиотек и возможность выбора наиболее подходящего и эффективного для каждого конкретного случая.


M>Угу, потом пытаешься скрестить QString с bt_str и материшься трехэтажным матом

Угу. Бывает конечно и такое. Если самому можно определять какую библиотеку использовать то вопросы межвидового взаимодействия как правило не стоят, или решаются административным порядком. Но дело в том что я довольно много занимаюсь вопросами интеграции и взаимодействия с сторонними аппликациями ( иногда весьма старыми и экзотическими) и здесь "окружающая среда" имеет решающее значение. Я далеко не всегда могу выбирать то что мне нравиться ( в том числе иногда и сам язык),часто приходиться мириться с тем что есть. . В этом плане С++ с его многообразием библиотек более универсален чем С#.
Re[31]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 08:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>Не путайте возможность и необходимость. Именно такое похабное отношение к строкам с самого начала и привело к тому, что в С++ появилось "многообразие стрингов из разных библиотек" и необходимость трахаться с их интероперабельностью.

Еще раз, в ваших собственных проектах можете не трахаться, административно, на основании тех или иных требований заказчика определяте какую библиотеку использовать и все вопросы по интероперабельность отпадают. Но как вы справедливо заметили есть еще и окружающая среда, которая часто не знакома с майкрософтом и дотнетом.
У меня же нет выбора и я по роду своей работы вынужден с ней трахаться. Поверьте, дотнет в таких случая не помошник, попробуйте написать на шарпе програмку получающую текст с экрана терминального эмулятора написанного неизвестными испанскими коллегами лет десять назад и не имеющим не только внешнего АРI и но и вообше какойлибо документациию. Я конечно могу порекомендовать клиенту поменять этот терминал на другой имеющий hllapi или комовский интерфейс который я смогу задействовать из C#. Но вы наверное догадиваетесь куда я буды послан вместе с своими требованиями, клиенту нет никакого резона менять то что учтойчиво и надежно работало за много лет до появления дотнета.
Re[32]: i++; ++i; ;) (-)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 09:02
Оценка:
Здравствуйте, Erop, Вы писали:

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


G>>Чтобы было прмерно так: int i; i someOp param; и число i после этого изменилось.

E>
i++;
Но это всё не о том спор. Есть некие "значения" строк, они неизменны, так как являются абстракцией существующей исключительно в нашей голове. Ну там скажем строка "мама" или число "0,5"...

E>А есть переменные, которые могут принимать то или иное значение. Значения, конечно, менять нельзя, но содержащие их переменные иногда можно...
В данном случае ты говоришь об эксклюзивном ключе. Здесь есть езменяемая и неизменяемая часть.
разделение строк на 2 типа необходимо по нескольким причинам.
1. Хэш неизменен, а значит хранение в хэштаблице в том числе для интернирования для скорости сравнения по указателям и экономии памяти.

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

3. Отсутствие синхронизации при чтении строк.
и солнце б утром не вставало, когда бы не было меня
Re[24]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 09:04
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Что такое иммутабельность, в конце концов ? Грубо говоря, это порождение констант в рантайме. С++ этого не умеет. Java и C# умеют, но только для типа string. Как только мы попробуем развить идею иммутабельности для любых классов, так мы сразу придем к задаче, примерно эквивалентной работе GC — проверке на каждой операции, не достижим ли данный объект из какого-нибудь иммутабельного объекта. string слишком прост, поэтому для него такое возможно, в нем нет вложенных объектов.

Не всё так сложно, о мой давний противник
1. Если объект не имеет исходящих ссылок, то недостижимость крайне легко доказывается. См. например DateTime — он тоже полностью Immutable (что гораздо лучше, чем в Java).
2. Если объект имеет исходящие ссылки, то при проектировании его достаточно убедиться, что сами они показывают только на иммутабельные объекты.
Поэтому сделать вот такой класс immutable — проще простого:
public class Name
{
  public Name(string firstName, string lastName)
    {
      _firstName = firstName;
        _lastName = lastName;
    }
    
  public string FirstName { get { return _firstName;}}
  public string LastName { get { return _lastName;}}
    
    public Name ChangeFirstName(string newFirstName)
    {
      return new Name(newFirstName, this.LastName);
    }

    public Name ChangeLastName(string newLastName)
    {
      return new Name(this.FirstName, newLastName);
    }
}


PD>С другой стороны, необходимо ответить на вопрос — насколько часто придется все же менять эти иммутабельные объекты. Я не оговорился, слово "менять" я понимаю здесь в широком смысле, то есть создавать их измененные версии, независимо от того, как именно. Если объекты не являются иммутабельными, то во многих случаях эти изменения можно делать inplace (примеры — преобразование к иному регистру, замена символа на другой, реверс). Если объект является иммутабельным, то эти действия приходится выполнять с помощью создания нового объекта, нового string в конечном счете, опять же иммутабельного.

Совершенно верно.
PD>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.
Совершенно верно. К счастью, обычно автор программы достаточно хорошо себе представляет, какие операции он хочет делать с текстом и насколько часто. И если ему нужно часто вносить изменения в строку, он применяет StringBuilder.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 04.06.09 09:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Не обязательно 1:1. Достаточно иметь просто иммутабельные строки, которые не требуют O(N) при интеропе с окружающим кодом.

S>Увы, сие в плюсах решительно невозможно.
Доказательства решительной невозможности будут?
В С++ такие строки могут быть нужны "под задачу". А в этом случае весь интероп с окружающим кодом легко свести к присвоению начального значения.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[27]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 04.06.09 09:06
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


CC>>Так отдавай туда const char * — и ежу понятно что менять сие без хака низя.

S>Опять упорствующее непонимание. Отдать-то я могу. А как мне при приёме обеспечить константность?
А! Теперь понятно о чем ты.

S>Этот код пишу я. Вызывают его другие. Вот этот const означает, что я не имею права его менять. Но вызывающая сторона имеет полную свободу — я не могу, оставаясь в рамках С++, обеспечить неизменность этой строки.

Дык этож C# подход, для С++ надо делать иначе.

S>Не надо вот этих вот "ля-ля". В руках индуса... Ничто не спасёт... Этими мантрами люди, покусанные плюсами, убеждают себя уже двадцать лет. А тем временем другие люди, с более взвешенным отношением к индустрии, демонстрируют, что можно значительно увеличивать надёжность программ безо всяких мантр и подготовок личного состава.



S> А в вашей убогой спарте запросто можно отчудить вот такое:

S>
S>std:string hello("hello");
S>ProcessInAnotherThread(hello.c_str());
S>hello.clear(); // oops!
S>

S>И никаких средств защититься от этого не предусмотрено.
Это средство называется головной мозг.
Если в твоих терминах, то это код "покусанного C#".
Мне почему-то в голову такую дурость на С++ утворить не приходит.

CC>>Поэтому не надо тащить методы работы с C# в С++ где всё совсем по другому.

S>Я в курсе, как там что в С++. Я, вообще-то, не с С# работать начал.
Я понимаю. Но у тебя моск уже заражён шарпом, раз ты пытаешься писать на С++ как на шарпе.
Естественно получается фигня: подходы то не те.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[25]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 04.06.09 09:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Игoрь, Вы писали:


И>>Не, ну хорошо, кто бы спорил. Раз подходит для каких-то задач, замечательно. Мне такое пока не нужно.

WH>Нужно просто ты сам пока этого не понимаешь.
WH>Дело в том что тут работает парадокс блаба
Автор(ы): Чистяков Влад (VladD2)
Дата: 03.03.2007
Язык программирования Nemerle заинтересовал многих в первую очередь своей мощнейшей подсистемой мак-росов. Однако и без них Nemerle предоставляет ряд су-щественных улучшений по сравнению с традиционными, императивными языками программирования (такими как Java, C# и C++).
Nemerle, кроме традиционного императивного програм-мирования, поддерживает функциональное программи-рование. Это выражается в наличии конструкций, упро-щающих манипуляцию функциями, построение и анализ сложных структур данных и т.п.
К сожалению, если вы не использовали возможности, присущие функциональным языкам ранее, то вам будет трудно оценить, насколько Nemerle может оказаться вам полезным в реальной повседневной работе. Данная статья призвана в неформальной форме продемонс-трировать это.
.

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

И>>Иногда для оптимизации и не такое приходится делать, например выкидывать std::vector, из-за того, что тот свой буфер зануляет.

WH>А что reserve + push_back не помогает?
Нет, не помогало. Сначала убрали вектора, а позже вообще перешли на пул выделенных буферов.

И>>Например есть строки размером от 50КБ до 5МБ, надо найти и вырезать какие-то куски без лишних релокейшинов. Все что мне нужно — хоть простой набор алгоритмов над текстовым writable буфером.

WH>Это решается умным представлением строк. Одна из возможных структур данных называется rope.
Да, оказывается я этот rope несколько лет назад реализовывал, только не знал как оно называется. Но вопрос был по С#, String + StringBuilder не покрывают даже вполне распространенных сценариев, в частности элементарного редактирования текста средних и более размеров. Вон в той же Java (откуда, я так понимаю, и были слизаны String+StringBuilder), таки появился Rope. Вот тебе и зоопарк реализаций. То, что иммутабельные строки могут быть полезны — согласен, но и должна быть возможность для нормального редактирования строк хотя бы средних размеров (нормального редактирования, а не с помощью обрубка вроде StringBuilder). И здесь иммутабельность не особо и нужна.
Re[32]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 09:21
Оценка:
Здравствуйте, alexey_ma, Вы писали:
S>>Не путайте возможность и необходимость. Именно такое похабное отношение к строкам с самого начала и привело к тому, что в С++ появилось "многообразие стрингов из разных библиотек" и необходимость трахаться с их интероперабельностью.
_>Еще раз, в ваших собственных проектах можете не трахаться, административно, на основании тех или иных требований заказчика определяте какую библиотеку использовать и все вопросы по интероперабельность отпадают.
Это подростковые фантазии. В жизни не бывает "одной библиотеки", которая решает все нужные задачи. В плюсах шансы на то, что все библиотеки в проекте будут использовать одни и те же строки, приближаются к нулю очень быстро с ростом размера проекта.
_>Но как вы справедливо заметили есть еще и окружающая среда, которая часто не знакома с майкрософтом и дотнетом.
_>У меня же нет выбора и я по роду своей работы вынужден с ней трахаться. Поверьте, дотнет в таких случая не помошник, попробуйте написать на шарпе програмку получающую текст с экрана терминального эмулятора написанного неизвестными испанскими коллегами лет десять назад и не имеющим не только внешнего АРI и но и вообше какойлибо документациию.
И какое отношение отсутствие документации на терминал имеет к языку программирования? Неужели при программировании на плюсах документация волшебным образом появится из ниоткуда?
_>Я конечно могу порекомендовать клиенту поменять этот терминал на другой имеющий hllapi или комовский интерфейс который я смогу задействовать из C#. Но вы наверное догадиваетесь куда я буды послан вместе с своими требованиями, клиенту нет никакого резона менять то что учтойчиво и надежно работало за много лет до появления дотнета.
Вы, наверное не догадываетесь, но COM — далеко не всё, с чем может интероперировать шарп.
Покажите мне пример того, с чем вы интероперируете на С++, и что, по вашему, никак-никак не заработает в шарпе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 09:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Не всё так сложно, о мой давний противник




S>1. Если объект не имеет исходящих ссылок, то недостижимость крайне легко доказывается. См. например DateTime — он тоже полностью Immutable (что гораздо лучше, чем в Java).


Естественно.

S>2. Если объект имеет исходящие ссылки, то при проектировании его достаточно убедиться, что сами они показывают только на иммутабельные объекты.


Хм. Ссылки на объекты своего собственного типа ?

public class Name
{
  Name anotherName;
  //...
}


А во-вторых, это довольно серьезное ограничение.

PD>>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.

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

Вот тут я бы высказался по поводу реализации. Мне в свое время она доставила массу не слишком приятных впечатлений. Например, надо мне эту самую строчку в верхний регистр перебросить. Но у StringBuilder нет ToUpper. Выходит, надо его ToString, а потом новый StringBuilder на основе этой строки. Или можно как-то обойтись и сделать все же inplace ?

char szString[N];
gets(szString);
strupr(szString);

и ни одного лишнего байта. Можно такое сделать ?
With best regards
Pavel Dvorkin
Re[32]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 09:39
Оценка:
Здравствуйте, CreatorCray, Вы писали:
CC>Доказательства решительной невозможности будут?
Давайте лучше вы опровержение приведете. А то я уже запарился объяснять что-то людям, которые не хотят ничего понять.
CC>В С++ такие строки могут быть нужны "под задачу". А в этом случае весь интероп с окружающим кодом легко свести к присвоению начального значения.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 09:58
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

S>И какое отношение отсутствие документации на терминал имеет к языку программирования? Неужели при программировании на плюсах документация волшебным образом появится из ниоткуда?

Не появиться. Не в этом дело. Отсутствие вменяемого Api у аппликации серьзно затрудняет возможность ее интеграции c дотнет. На плюсах у меня просто возможностей больше. А эта задача с терминалом не без некоторого гиммороя решилась перехватом нескольких WinApi функций. Согласитесь что проще это сделать на С++/C ?
S>Вы, наверное не догадываетесь, но COM — далеко не всё, с чем может интероперировать шарп.
Еще как догадиваюсь, мало того, даже знаю какой ценой, тот же СОМ доставляет иногда не мало веселья. На собственном опыте вижу что ВНО написанный на плюсах работает бодрее, жрет меньше cpu, на порядок потребляет меньше памяти чем BHO написанный на шарпе с аналогичной функциональностью.
S>Покажите мне пример того, с чем вы интероперируете на С++, и что, по вашему, никак-никак не заработает в шарпе.
Ну для начала возьмем PowerBulder (это то с чем приходиться часто работать ). Для примера лучше взять версию постарше 6 или 7. Там есть такой обьект называемый DataWindow, попытайтесь получить из него значение какого нибудь поля, именно из gui, поскольку доступа к базе нет и не будет.
Re[26]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 09:58
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Хм. Ссылки на объекты своего собственного типа ?


PD>
PD>public class Name
PD>{
PD>  Name anotherName;
PD>  //...
PD>}
PD>

А какие проблемы? Иммутабельность же транзитивна.

PD>А во-вторых, это довольно серьезное ограничение.

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

PD>Вот тут я бы высказался по поводу реализации. Мне в свое время она доставила массу не слишком приятных впечатлений. Например, надо мне эту самую строчку в верхний регистр перебросить. Но у StringBuilder нет ToUpper. Выходит, надо его ToString, а потом новый StringBuilder на основе этой строки. Или можно как-то обойтись и сделать все же inplace ?


PD>char szString[N];

PD>gets(szString);
PD>strupr(szString);

PD>и ни одного лишнего байта. Можно такое сделать ?

Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace. Но если очень-очень хочется, то банально
static class StringBuilderHelper
{
        public static void Transform(this StringBuilder sb, Func<char, char> transform)
        {
                for (int i = 0; i < sb.Length; i++)
                        sb[i] = transform(sb[i]);
        }

        public static void ToUpper(this StringBuilder sb)
        {
                sb.Transform(Char.ToUpper);
        }
}

При этом мы сэкономим память ценой просада в производительности — внутри сеттера StringBuilder.this[int] происходит та самая злая магия межпоточной синхронизации, которая убивает производительность мутабл-строк.
Вообще, если профайлер тебе не показал проблемы с быстрым ростом количества строк, то искусственно продлять их время жизни в управляемой среде (в частности, внося изменения вместо создания копии) крайне не рекомендуется. Получишь обратный эффект.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: i++; ++i; ;) (-)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 10:10
Оценка:
Здравствуйте, Erop, Вы писали:

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


S>>В данном случае ты говоришь об эксклюзивном ключе. Здесь есть езменяемая и неизменяемая часть.

S>> разделение строк на 2 типа необходимо по нескольким причинам.
E>Как связанна эксклюзивность ключа с тем, что ключ -- строка, а не double, например?
Эксклюзивность связана с неизменяемостью не зависимо от типа.
Если ты хочешь найти в хэштаблице сначало по Хэшу, то и Хэш должен соответствовать значению,
если в сортированном списке ты меняешь строку, то должен изменить ее местоположение в списке.

S>>1. Хэш неизменен, а значит хранение в хэштаблице в том числе для интернирования для скорости сравнения по указателям и экономии памяти.

E>Про экономию памяти не понял, так как в любых хэшах бывают коллизии. А вот про хранение кэша рядом со строкой -- не ивжу что мешает так делать в С++ подходе? Я регулярно так делаю, и ничего вроде...
Экономия при интернировании, т.к. не хронятся дубли. Если хэш лежит рядом, то и строка должна быть неизменяема, смоьри выше.

S>>2. Для мутабельной строки как в стрингбуилдере для скорости нужно иметь выделенную память больше чем размер строки на данный момент

S>>для быстрого изменния длины строки.
E>Это всего лишь подробности реализации той самой мутабелной строки. Мне, например, нравится реализация, которая содержит коллекцию пулов буферов. Размеры буферов в каждом из пулов подобраны так, чтобы каждый следующий пул хранил строки во сколько-то раз (например в полтора) большие, чем предыдущий. Аллокация -- быстрая, освобождение -- ещё более быстрое, работа с COW...
У меня было аналогично такому
http://www.rsdn.ru/forum/philosophy/2449781.1.aspx
Автор: Serginio1
Дата: 16.04.07


Но удвоение размеров при полном заполнение очень эффективное решение.
S>>3. Отсутствие синхронизации при чтении строк.
E>При чтении любых константных данных синхронизация вроде как не нужна...
Ну в нативе мы если захотим можем изменить любой участок памяти
и солнце б утром не вставало, когда бы не было меня
Re[34]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 10:18
Оценка:
Здравствуйте, alexey_ma, Вы писали:
_>Ну ну. Это не фантазии, идеала не бывает, но это не отменяет факта что к этому надо стремиться.
Вы говорите про обратное стремление. Вы довольны тем, что у вас есть зоопарк строк для работы с зоопарком библиотек.
А я говорю, что стремиться нужно к наличию одной-двух вменяемых реализаций строк и отсутствию проблем с интеропом, по крайней мере на таком уровне.

_>Не появиться. Не в этом дело. Отсутствие вменяемого Api у аппликации серьзно затрудняет возможность ее интеграции c дотнет. На плюсах у меня просто возможностей больше. А эта задача с терминалом не без некоторого гиммороя решилась перехватом нескольких WinApi функций. Согласитесь что проще это сделать на С++/C ?

Какое отношение это имеет к зоопарку строк? Постарайтесь сосредоточиться и отделить мух от котлет — проблемы отсутствия документации и задачи перехвата WinAPI никак не решаются ни при помощи std::string, ни CString, ни их отсутствия.

S>>Покажите мне пример того, с чем вы интероперируете на С++, и что, по вашему, никак-никак не заработает в шарпе.

_>Ну для начала возьмем PowerBulder (это то с чем приходиться часто работать ). Для примера лучше взять версию постарше 6 или 7. Там есть такой обьект называемый DataWindow, попытайтесь получить из него значение какого нибудь поля, именно из gui, поскольку доступа к базе нет и не будет.
Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 10:24
Оценка:
Здравствуйте, Sinclair, Вы писали:


PD>>Хм. Ссылки на объекты своего собственного типа ?


PD>>
PD>>public class Name
PD>>{
PD>>  Name anotherName;
PD>>  //...
PD>>}
PD>>

S>А какие проблемы? Иммутабельность же транзитивна.

Я не совсем пойму, как ты этой ссылке значение будешь присваивать, например, если Name A ссылается на Name B, а в том — обратно. В конструкторе такое не сделаешь, а после — это уже не будет иммутабельность.

PD>>А во-вторых, это довольно серьезное ограничение.

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

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


PD>>Вот тут я бы высказался по поводу реализации. Мне в свое время она доставила массу не слишком приятных впечатлений. Например, надо мне эту самую строчку в верхний регистр перебросить. Но у StringBuilder нет ToUpper. Выходит, надо его ToString, а потом новый StringBuilder на основе этой строки. Или можно как-то обойтись и сделать все же inplace ?


PD>>char szString[N];

PD>>gets(szString);
PD>>strupr(szString);

PD>>и ни одного лишнего байта. Можно такое сделать ?

S>Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace.

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


Но если очень-очень хочется, то банально

<skipped>

Ну вручную все , что угодно можно сделать. Я же писал — вопрос о реализации. Дальше будем вручную дописывать прочие методы от string (CompareTo, Contains, IndexOf...)

S>При этом мы сэкономим память ценой просада в производительности — внутри сеттера StringBuilder.this[int] происходит та самая злая магия межпоточной синхронизации, которая убивает производительность мутабл-строк.

S>Вообще, если профайлер тебе не показал проблемы с быстрым ростом количества строк, то искусственно продлять их время жизни в управляемой среде (в частности, внося изменения вместо создания копии

Это как ? Не понял. В string ??? Или в StringBuilder все же ?
With best regards
Pavel Dvorkin
Re[26]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 10:28
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>Проблема в том, что StringBuilder не имеет полноценного интерфейса для редактирования строк. Например, там нет даже поиска подстроки. О каком редактировании может идти речь? StringBuilder вообще предназначен исключительно для конструирования строк, но не для их редактирования. И я думаю, что из-за этого в Java, которая применяет тот же принцип — String + StringBuffer, появилась альтернатива String — Rope, которая с одной стороны имеет интерфейс String, но оптимизирована под редактирование. В общем в MS хотели как лучше, а получилось как всегда.


Приходится делать свои аналоги
Например http://www.rsdn.ru/forum/dotnet/3303143.flat.aspx#3303143
Автор: Serginio1
Дата: 24.02.09

там есть реализация RStdingBuilder.
Так или иначе ни один класс не может реализовать все, что от него нужно, но у StringBuildera внутренности закрыты, поэтому
и пользователскую реализация сделать нельзя или сложно.
и солнце б утром не вставало, когда бы не было меня
Re[36]: i++; ++i; ;) (-)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 10:48
Оценка:
Здравствуйте, Erop, Вы писали:

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

E>Собственно в этом состоит принципиальное отличие. А дальше уже частности идут...
E>Собственно говоря что тебе важнее: контроль или возможность нанимать кого попало...
Ну никто же не запрещает тебе создавать пользователькие классы и делать с ними, что хошь, так или иначе под определенные задачи все равно не хватит существующего функционала.
Просто в 90 с лишним процентов за глаза хватает существующего функционала, и глаза не разбегаются.
Много информации тоже плохо, поэтому лучше сосредоточится на глобальных проблемах.
и солнце б утром не вставало, когда бы не было меня
Re[28]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 10:53
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я не совсем пойму, как ты этой ссылке значение будешь присваивать, например, если Name A ссылается на Name B, а в том — обратно. В конструкторе такое не сделаешь, а после — это уже не будет иммутабельность.

Я не совсем пойму, для чего тебе это потребовалось. В чём смысл этого? Можно иметь иммутабл дерево, можно иметь иммутабл стек. Иметь произвольный иммутабл граф иммутабл объектов — трудно, почти что невозможно. И, на первый взгляд, ненужно.

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

PD>Не понял. Как я могу такое сделать в принципе, это же бессмыслица.

Ну вот раз бессмыслица — значит никаких проблем.

S>>Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace.

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

PD>Ну вручную все , что угодно можно сделать. Я же писал — вопрос о реализации. Дальше будем вручную дописывать прочие методы от string (CompareTo, Contains, IndexOf...)

Да, тут ты прав. Всё это нужно было сархитектурить по-другому.

PD>Это как ? Не понял. В string ??? Или в StringBuilder все же ?

А внутри стрингбилдера по-твоему что?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 11:06
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

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

ГВ>Вот-вот. Возвращаемся к тому, с чего начали: к внутренней структуре строки.

И как грамотная реализация строки относится к тому что строк должно быть много?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 11:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

_>>Ну ну. Это не фантазии, идеала не бывает, но это не отменяет факта что к этому надо стремиться.
S>Вы говорите про обратное стремление. Вы довольны тем, что у вас есть зоопарк строк для работы с зоопарком библиотек.
S>А я говорю, что стремиться нужно к наличию одной-двух вменяемых реализаций строк и отсутствию проблем с интеропом, по крайней мере на таком уровне.
У
_>>Не появиться. Не в этом дело. Отсутствие вменяемого Api у аппликации серьзно затрудняет возможность ее интеграции c дотнет. На плюсах у меня просто возможностей больше. А эта задача с терминалом не без некоторого гиммороя решилась перехватом нескольких WinApi функций. Согласитесь что проще это сделать на С++/C ?
S>Какое отношение это имеет к зоопарку строк? Постарайтесь сосредоточиться и отделить мух от котлет — проблемы отсутствия документации и задачи перехвата WinAPI никак не решаются ни при помощи std::string, ни CString, ни их отсутствия.
Ясень пень что не решают, но иногда помогают. Разговор вроде был о возможности выбора оптимальной реализации строк в зависимости от задачи и о проблемах интеграции. Так вот, когда я из хука лезу в Сlarify11 (он почему-то написан на MFC 7.0) чтобы прочитать там пару строчек из ObjectivGrid я использую СString ( мало того я вынужден компилировать хук с той же версией MFC что и Сlarify — иначе не работает), если работаю с CОМ — использую BSTR и т.п — так понятно?
S>>>Покажите мне пример того, с чем вы интероперируете на С++, и что, по вашему, никак-никак не заработает в шарпе.
Про замечательный интероп шарпа c CОМ на примере ВНО, я полагаю замнем
_>>Ну для начала возьмем PowerBulder (это то с чем приходиться часто работать ). Для примера лучше взять версию постарше 6 или 7. Там есть такой обьект называемый DataWindow, попытайтесь получить из него значение какого нибудь поля, именно из gui, поскольку доступа к базе нет и не будет.
S>Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.
Не могу я код показать, но он есть и работает Возможно что подобный код какой нибудь гений может написать и на шарпе , но вряд-ли он будет короче и понятней. Да чего там PowerBuilder, набросайте VB6 апликацию с MSFlexGlig и попробуйте получить из этого грида пару строчек или хотя-бы текст какого нибудь Label тоже из VB6. К сожалению ( или к счастью) мир пока не весь еще дотнет, с дотнетом кстати интегрировться легко.
Re[27]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 04.06.09 11:12
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Приходится делать свои аналоги

S>Например http://www.rsdn.ru/forum/dotnet/3303143.flat.aspx#3303143
Автор: Serginio1
Дата: 24.02.09

S>там есть реализация RStdingBuilder.
S> Так или иначе ни один класс не может реализовать все, что от него нужно, но у StringBuildera внутренности закрыты, поэтому
S>и пользователскую реализация сделать нельзя или сложно.
Так об этом и речь, что приходится городить огород. А обычные С++ строки как правило с этим справляются. Мне только один раз приходилось писать свои оптимизированные строки а-ля rope для одного сетевого фильтра.
Re[24]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 04.06.09 11:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным. Если генерировать набор строк, не меняя длины исходной строки, а только заменяя в ней символы, то без иммутабельности эта задача решается на одной строке, одном буфере. С иммутабельностью мы рискуем захватить мегабайты, прежде чем проснется GC и уничтожит всю эту иммутабельную кунсткамеру. Более того, на нелюбиом тобой массиве из char (ASCIIZ то есть) эти операции можно выполнять на одном буфере даже при изменении длины строки, лишь бы только за пределы буфера не выходить.


Если бы в java/.NET не было StringBuffer/StringBuilder, это было бы проблемой. А так это станет проблемой только если у программера, писавшего этот алгоритм, кривые руки.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[33]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 11:37
Оценка:
Здравствуйте, Mamut, Вы писали:

a>> M>Угу, потом пытаешься скрестить QString с bt_str и материшься трехэтажным матом


a>> Угу. Бывает конечно и такое. Если самому можно определять какую библиотеку использовать то вопросы межвидового взаимодействия как правило не стоят, или решаются административным порядком. Но дело в том что я довольно много занимаюсь вопросами интеграции и взаимодействия с сторонними аппликациями ( иногда весьма старыми и экзотическими) и здесь "окружающая среда" имеет решающее значение. Я далеко не всегда могу выбирать то что мне нравиться ( в том числе иногда и сам язык),часто приходиться мириться с тем что есть. . В этом плане С++ с его многообразием библиотек более универсален чем С#.



M>Да ничего он не универсален. Весь этот «внешний» мир и появился из-за такой вот «универсальности». В идеальном мире, где строка была бы встроена в язык С++, броблемы QString <-> bt_str просто не появилось бы. А так, создали кучу проблем, миллион несовместимых классов строк, активно с тим все боремся, но при этом гордо: «а посмотрите, какой С++ универсальный»

Что поделать, тяжёлая наследственность . Но это и есть та самая "окружающая среда" и она существует не зависимо от нашего желания и броться с ней пока удобней из плюсов. Когда абсолютно всё перепишут на дотнете то будет нам всем счастье.
Re[29]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 12:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>Я не совсем пойму, для чего тебе это потребовалось. В чём смысл этого? Можно иметь иммутабл дерево, можно иметь иммутабл стек. Иметь произвольный иммутабл граф иммутабл объектов — трудно, почти что невозможно. И, на первый взгляд, ненужно.


Ну признаться , я не очень пойму, почему граф нельзя, а дерево можно. Но не в этом дело. Я просто хочу сказать, что это не так просто, и именно поэтому ИМХО их нет в языке, и я не могу создать иммутабл объект сам.

S>Опять же, пойми, что мы не пытаемся перехватывать все изменения и бросать исключение. Задача — описать иммутабл при помощи системы типов, так, чтобы изменить значение было просто невозможно.


Да понял я тебя, не волнуйся

S>>>Можно, но обычно незачем. Массовый ToUpper обычно применяется к коротким строкам, там дешевле сделать копию, чем делать inplace.

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

А если не секрет, почему все же. Я упорно не могу понять, чем такое на легальном C#

string s= ...
string s1 = s.ToUpper();

дороже, чем на некоем C#-подобном языке, где string mutable

string s= ...;
StringHelper.ToUpper(s);// заменяет в s на верхний регистр

Я даже в этом языке твой любимый хелпер употребил

На С

char szString[N];
strcpy(szString,...);
strupr(szString);

никак не может быть дороже, чем

char szString[N], szStringCopy[N];
strcpy(szString,...);
strcpy(szStringCopy,szString);
strupr(szStringCopy);

Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
PD>>Ну вручную все , что угодно можно сделать. Я же писал — вопрос о реализации. Дальше будем вручную дописывать прочие методы от string (CompareTo, Contains, IndexOf...)
S>Да, тут ты прав. Всё это нужно было сархитектурить по-другому.

Ява, Антон, Ява . Это не к MS, это к Sun. MS просто не решилась все это серьезно изменить — боялись оттолкнуть программистов на Яве.

PD>>Это как ? Не понял. В string ??? Или в StringBuilder все же ?

S>А внутри стрингбилдера по-твоему что?

Я так полагаю, кусок из short . Можно и посмотреть, но лень. Но какое отношение это имеет к росту числа строк (строк!) о котором ты пишешь ?
With best regards
Pavel Dvorkin
Re[28]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 12:32
Оценка:
Здравствуйте, Игoрь, Вы писали:

S>> Так или иначе ни один класс не может реализовать все, что от него нужно, но у StringBuildera внутренности закрыты, поэтому

S>>и пользователскую реализация сделать нельзя или сложно.
И>Так об этом и речь, что приходится городить огород. А обычные С++ строки как правило с этим справляются. Мне только один раз приходилось писать свои оптимизированные строки а-ля rope для одного сетевого фильтра.

Ну про функциональность стрингбуилдера давно плюются.
Не вижу веских причин для его качественной переделки. Или ввести новый более функциональный мутабельный строковый тип.
С другой стороны на кодепрожект наверняка полно таких классов на любой вкус.
Просто к сторонним библиотекам относишься настороженно.
и солнце б утром не вставало, когда бы не было меня
Re[37]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 12:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Нет, непонятно. Я не понимаю, что там делается внутри Clarify и каким боком тут вид строки, но вот про BSTR более-менее понятно. Вот в шарпе нет никакого BSTR, но при этом каким-то волшебным образом он интероперирует с COM. Вы не задумывались, почему?

Сlarify сам написан на MFC использует стороний компонет ObjectivGrid (тоже MFC) многие методы которого возвращают СString. Чтобы поиметь какую-то информацию от этого грида я внедряю свою MFC дллку в Сlarifу, получаю указатель на грид и начинаю работать с его методами используя родной для этого грида СString. В данном случае никакой дотнетовский интероп не будет работать более эффективно( Проверяно на практике, коллеги пытались это сделать на C#).
Я очень рад что шарп интероперирует с COM, только вот я в многих случаях могу работая из плюсов с СОМ могу избежать ненужного мне маршаллинга, в дотнете это у вас не получиться.

_>>Про замечательный интероп шарпа c CОМ на примере ВНО, я полагаю замнем

S>Можно и замять — мне всё равно. В принципе, на текущем фреймворке реализация in-proc COM серверов для unmanaged хостов — не лучший способ скрасить себе жизнь. А вот в обратную сторону интероп работает просто прекрасно.
Как я говорил так уж и прекрасно

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


S>>>Покажите код на С++, который делает это злое волшебство. Тот самый, который никак-никак не заработает в шарпе. Я даже за деньги не буду выкачивать PowerBuilder 6 и искать в нём объект называемый DataWindow.

_>>Не могу я код показать, но он есть и работает
S>А что, стеснительность не позволяет?
Да
_>>Возможно что подобный код какой нибудь гений может написать и на шарпе , но вряд-ли он будет короче и понятней.
S>При чём тут гений — это вопросы примитивной технической реализации. В принципе, ничего страшнее platform invoke нам всё равно не светит.
Конечно, все в конце-концов сводится к вопросам примитивной технической реализации, но согласитесь что писать инжектируемую в
чюжой unmanaged процесс дллк на дотнете удовольствие сомнительное, а выгода не очевидна.

_>>Да чего там PowerBuilder, набросайте VB6 апликацию с MSFlexGlig и попробуйте получить из этого грида пару строчек или хотя-бы текст какого нибудь Label тоже из VB6. К сожалению ( или к счастью) мир пока не весь еще дотнет, с дотнетом кстати интегрировться легко.

S>Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.
Нет не покажу . Если интересно пробуйте сами. Дело даже не в том что код невоспроизводим на шарпе, дело в целесообразности этого воспроизведения. Зачем?
Re[30]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 12:40
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну признаться , я не очень пойму, почему граф нельзя, а дерево можно. Но не в этом дело. Я просто хочу сказать, что это не так просто, и именно поэтому ИМХО их нет в языке, и я не могу создать иммутабл объект сам.
Можешь. В дотнете много иммутабл объектов помимо строк.

PD>А если не секрет, почему все же. Я упорно не могу понять, чем такое на легальном C#

PD>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
Потому, что твой код небезопасен. Как только ты начнешь делать его потокобезопасным, стоимость сразу станет совсем другой.

Выделение памяти в хипе — очень дешево. Стоимость чтения и записи в один и тот же short не слишком отличается от чтения из одного short и записи в другой short. А именно этим отличаются inplace ToUpper от копирующего ToUpper. На длинных строках начнут сказываться эффекты cache locality — но для коротких строк стоимость блокировки запросто сожрёт цену от дублирования лишнего килобайта. Посмотри на внутреннее устройство StringBuilder — там явно видна разница между "иммутабл" строкой, и "безопасной мутабл" строкой.


PD>Ява, Антон, Ява . Это не к MS, это к Sun. MS просто не решилась все это серьезно изменить — боялись оттолкнуть программистов на Яве.

Такие вещи, как System.String, подвергаются очень тщательному дизайну на предмет очень-очень многих противоречивых требований. Так что не думаю, что боязнь оттолкнуть жавистов была основным мотивом.
Ну и, конечно же, невозможно сделать всё-всё правильно с первого раза. Вон, в яве только в 1.2 допёрли, что Thread.Pause нужно запретить.

PD>Я так полагаю, кусок из short . Можно и посмотреть, но лень. Но какое отношение это имеет к росту числа строк (строк!) о котором ты пишешь ?

[Serializable, ComVisible(true)]
public sealed class StringBuilder : ISerializable
{
    // Fields
    private const string CapacityField = "Capacity";
    internal const int DefaultCapacity = 16;
    internal IntPtr m_currentThread;
    internal int m_MaxCapacity;
    internal volatile string m_StringValue;
...

Не угадал
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 12:50
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А до них Sun в Java тоже не освоила, так ? Не осваивается оно...

А тебя в гугле забанили?
Я же даже название одной из структур данных упоминал...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[24]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 13:06
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Что такое иммутабельность, в конце концов ? Грубо говоря, это порождение констант в рантайме. С++ этого не умеет. Java и C# умеют, но только для типа string. Как только мы попробуем развить идею иммутабельности для любых классов, так мы сразу придем к задаче, примерно эквивалентной работе GC — проверке на каждой операции, не достижим ли данный объект из какого-нибудь иммутабельного объекта. string слишком прост, поэтому для него такое возможно, в нем нет вложенных объектов.

Это же просто феерия.
Я просто балдею.
И как вся функциональщина то живет?

PD>С другой стороны, необходимо ответить на вопрос — насколько часто придется все же менять эти иммутабельные объекты. Я не оговорился, слово "менять" я понимаю здесь в широком смысле, то есть создавать их измененные версии, независимо от того, как именно. Если объекты не являются иммутабельными, то во многих случаях эти изменения можно делать inplace (примеры — преобразование к иному регистру, замена символа на другой, реверс). Если объект является иммутабельным, то эти действия приходится выполнять с помощью создания нового объекта, нового string в конечном счете, опять же иммутабельного.

И как часто такие действия нужны?
Плюс опять же не забывай про то что внутреннее представление строк может быть очень разным.
http://www.ibm.com/developerworks/java/library/j-ropes/index.html
Посмотри картинки. Они весьма позновательны...

PD>Отсюда ясно, что эффект от иммутабельности может быть как существенным и положительным, так и существенным и отрицательным.

Особенно если не знать матчасть.

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

А если разработчик ВМ осилил реализацию region inference то бедет тоже самое...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 04.06.09 13:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?

Потому что они не могут узнать использует ли этот буфер кто-то ещё...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[31]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 13:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

PD>>Ну признаться , я не очень пойму, почему граф нельзя, а дерево можно. Но не в этом дело. Я просто хочу сказать, что это не так просто, и именно поэтому ИМХО их нет в языке, и я не могу создать иммутабл объект сам.
S>Можешь. В дотнете много иммутабл объектов помимо строк.

Я са могу создать иммутабл тип ? Есть такие средства в языке ?

PD>>А если не секрет, почему все же. Я упорно не могу понять, чем такое на легальном C#

PD>>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?
S>Потому, что твой код небезопасен. Как только ты начнешь делать его потокобезопасным, стоимость сразу станет совсем другой.

Ладно, оставим твои аппеляции к потокобезопасности в стороне. Не всегда она нужна, и уж тебе ли не знать, что большинство классов .Net не являются потокобезопасными, а значит, эту безопасность придется делать вне. Также и здесь можно было бы поступить. Но я даже и это обсуждать не хочу. Допустим, у меня вообще один всего поток — почему я должен платить за эту самую потокобезопасность, если она мне не нужна.


S>Выделение памяти в хипе — очень дешево. Стоимость чтения и записи в один и тот же short не слишком отличается от чтения из одного short и записи в другой short. А именно этим отличаются inplace ToUpper от копирующего ToUpper. На длинных строках начнут сказываться эффекты cache locality — но для коротких строк стоимость блокировки запросто сожрёт цену от дублирования лишнего килобайта. Посмотри на внутреннее устройство StringBuilder — там явно видна разница между "иммутабл" строкой, и "безопасной мутабл" строкой.


Слушай, не наводи тень на плетень. Хоть какие вргументы приводи — не докажешь, что не выполнять лишних действий лучше, чем их выполнять И потом — а скорость уборки GC всей этой кунсткамеры тоже пренебрежимо мала ?


PD>>Я так полагаю, кусок из short . Можно и посмотреть, но лень. Но какое отношение это имеет к росту числа строк (строк!) о котором ты пишешь ?

S>
S>[Serializable, ComVisible(true)]
S>public sealed class StringBuilder : ISerializable
S>{
S>    // Fields
S>    private const string CapacityField = "Capacity";
S>    internal const int DefaultCapacity = 16;
S>    internal IntPtr m_currentThread;
S>    internal int m_MaxCapacity;
S>    internal volatile string m_StringValue;
S>...
S>

S>Не угадал

Да нет, в общем-то, угадал. В сущности этот самый m_StringValue и есть кусок из short, точнее, ссылка на него . Я же специально употребил нечеткий термин, я же тебя знаю, скажи я "массив из short" — что тут началось бы...
With best regards
Pavel Dvorkin
Re[31]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 04.06.09 13:27
Оценка:
Здравствуйте, Erop, Вы писали:

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



PD>>Операции будут те же и в этом моем псевдо-C#. Почему дороже ?

E>Потому что они не могут узнать использует ли этот буфер кто-то ещё...

А оно таки всегда надо ? Строки, конечно, могут быть в кэше, кэш доступен из разных потоков, тут нужна потокобезопасность и другие случаи есть. Но если я в своей C/C++ функции завел локальную auto переменную (хоть std::string, хоть char[N]), то к ней все равно никто добраться не может, и почему я должен платить за эту потокобезопасность ? Ну а если уж она нужна, кто мешает обертку в виде thread_safe_string соорудить ?
With best regards
Pavel Dvorkin
Re[39]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 04.06.09 13:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


S>Это не столько интероп, сколько хак. Опять же, вы путаете причину и следствие. То, что вам приходится компилировать DLL с той версие CString, которая у хоста — это не возможность, это необходимость. Вызванная ровно тем, что в С++ нет двух одинаковых классов строк. Если бы в стандарте с самого начала была приличная строка, вы бы и не знали о том, что могут потребоваться какие-то QString.


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

_>>Я очень рад что шарп интероперирует с COM, только вот я в многих случаях могу работая из плюсов с СОМ могу избежать ненужного мне маршаллинга, в дотнете это у вас не получиться.

S> А, ну это уж конечно недостаток из недостатков.
Для меня — да.
S>Вы невнимательно читаете. Для девелопера это очень плохо.
Для девлопера хаков сгодится . Вот начну всерьез на шарпе писать — исправлюсь.
S>BHO — это та самая реализация inproc COM server, о которой я говорил абзацем выше.
Да, конечно. Ну так здесь плюс победил (пока) или нет?
S>Я согласен. Но согласитесь, что разработка DLL для инжектирования в чужой процесс никак не назовешь мейнстримом. Так я могу сходу еще назвать тонну областей, куда управляемая среда подойдет плохо.
Респект. Я как раз в тех самых областях. Вот бы мне еще удалось убедить в этом неразумных колег — энтузиастов дотнета. Им даже бенчмарки не указ
S>>>Я не буду качать себе VB6 и MSFlexGrid — зачем? Приведите код на С++, который это делает, и по-вашему, невоспроизводим на шарпе.
_>>Нет не покажу . Если интересно пробуйте сами. Дело даже не в том что код невоспроизводим на шарпе, дело в целесообразности этого воспроизведения. Зачем?
S>Ну, например чтобы показать наглядную разницу.
Да ладно оставим это, в этом коде те самые хаки о которых Вы говорили.
Re[31]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 04.06.09 13:42
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>
S>[Serializable, ComVisible(true)]
S>public sealed class StringBuilder : ISerializable
S>{
S>    ...
S>    internal volatile string m_StringValue;
S>...
S>


Забавно. А с какой целью String/StringBuilder сделаны именно так, а не на базе char[] (который мог бы так же передаваться в String без копирования в StringBuilder.ToString())? Для того, чтобы убрать косвенность String->char[]->данные и сделать так, чтобы данные сразу в объекте «строка» хранились?
Re[27]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 04.06.09 14:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Пойми в чем прикол. Нужны только ропы.

WH>Их редактирование вполне дешево.
WH>Если бы в жабе строки изначально были бы ропами то никакого зоопарка бы не было. И StringBuilder'а тоже.

И что, даже на коротких строках (очень частый случай) «верёвки» будут эффективнее String/StringBuilder?
Re[32]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 14:05
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я са могу создать иммутабл тип ? Есть такие средства в языке ?

Конечно. Будет ничуть не хуже, чем строка. См. DateTime.

PD>Ладно, оставим твои аппеляции к потокобезопасности в стороне. Не всегда она нужна, и уж тебе ли не знать, что большинство классов .Net не являются потокобезопасными, а значит, эту безопасность придется делать вне. Также и здесь можно было бы поступить. Но я даже и это обсуждать не хочу. Допустим, у меня вообще один всего поток — почему я должен платить за эту самую потокобезопасность, если она мне не нужна.

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

PD>Слушай, не наводи тень на плетень. Хоть какие вргументы приводи — не докажешь, что не выполнять лишних действий лучше, чем их выполнять

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

PD>И потом — а скорость уборки GC всей этой кунсткамеры тоже пренебрежимо мала ?

Стоимость уборки строк равна нулю — у них нет финализатора.

PD>Да нет, в общем-то, угадал. В сущности этот самый m_StringValue и есть кусок из short, точнее, ссылка на него .

Не наводи тень на плетень. Ты спрашивал "где строки" — я показал тебе строки. Еще раз тебе объясняю: в управляемой среде в 99% случаев не надо ни "мешать" сборщику мусора, ни "помогать" ему. Понять, что ты попал в 1%, можно исключительно с помощью профайлера. Рассуждения типа "ой, тут что-то копируется, наверное без этого будет дешевле" не работают. Работает только профайлер.

Отдельные личности, к примеру, "для скорости" открывают коннекшн к базе данных в Application_Start и кладут в сессию веб-приложения. А потом удивляются, почему открытие/закрытие на каждый реквест работает так зверски лучше.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 04.06.09 14:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Thread_safe_string крайне труден в написании.

Да ну??? Неужто написать COW строку на refcounterах так сложно?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[34]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 14:41
Оценка:
Здравствуйте, CreatorCray, Вы писали:
S>>Thread_safe_string крайне труден в написании.
CC>Да ну??? Неужто написать COW строку на refcounterах так сложно?
И она будет прямо таки вся thread safe?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 14:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Если ты намекаешь на то что я не знаю С++ то ты мягко говоря не на того напал.

Нет. Всё, на что я "намекаю" написано открытым текстом.

WH>Можешь заглянуть в топ форума по С++... и это при том что я там уже не первый год почти не появляюсь.


Я знаю, что ты знаешь C++. Перечитай внимательно написанное.

ГВ>>Вот-вот. Возвращаемся к тому, с чего начали: к внутренней структуре строки.

WH>И как грамотная реализация строки относится к тому что строк должно быть много?

Так грамотная — это rope или линейный буфер?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[28]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 14:52
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Так грамотная — это rope или линейный буфер?

Все же для разных задач разные алгоритмы. В С# досих пор стандартных Б+ деревьев нет.
Все что требует частого удаления всавок по аналогии с б деревьями должны иметь такую структуру.
Либо буилдер стрингбуилдеров с ограничением на длину стрингбуилдера.
Но нелинейность оправдывает себя на больших размеров, и соответсвенно частые вставки и удаления.
Все под задачу. Поэтому 3 вида строк вполне оправдано.
и солнце б утром не вставало, когда бы не было меня
Re[28]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 14:54
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>И что, даже на коротких строках (очень частый случай) «верёвки» будут эффективнее String/StringBuilder?

Они им не уступят.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.06.09 14:56
Оценка:
Здравствуйте, WFrag, Вы писали:
WF>И что, даже на коротких строках (очень частый случай) «верёвки» будут эффективнее String/StringBuilder?
Нет, будут также эффективны.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[32]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 04.06.09 14:58
Оценка:
Здравствуйте, WFrag, Вы писали:



WF>Забавно. А с какой целью String/StringBuilder сделаны именно так, а не на базе char[] (который мог бы так же передаваться в String без копирования в StringBuilder.ToString())?


Не мог бы. Так как при внесении изменений в билдере(например, замене некоторых символов) эти изменения отразились бы и на строке, которая ранее была получена из этого билдера. А это
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[34]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 14:58
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Да ну??? Неужто написать COW строку на refcounterах так сложно?

Чтобы она еще и работала быстро на многопроцессорной тачке очень сложно.
Ибо даже InterlockedIncrement/InterlockedDecrement весьма не бесплатны на многопроцессорных машинах.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 04.06.09 15:00
Оценка:
Здравствуйте, Eugeny__, Вы писали:

E__>Не мог бы. Так как при внесении изменений в билдере(например, замене некоторых символов) эти изменения отразились бы и на строке, которая ранее была получена из этого билдера. А это


С изменяемым string ситуация ровно такая же. Ничто не мешает применить тот же финт ушами, что сделан в StringBuilder.ToString.
Re[29]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 04.06.09 15:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WF>>И что, даже на коротких строках (очень частый случай) «верёвки» будут эффективнее String/StringBuilder?

WH>Они им не уступят.

Да, действительно, не сообразил.

А как быть с заменой символа (например, 1000-ый, в строке, созданной конкатенацией пачки других строк)? В этом случае хочется по возможности не создавать лишние объекты, а значит изменяемый кусок не должен разделяться другими строками.
Re[29]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 15:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Так грамотная — это rope или линейный буфер?

WH>rope. Другие не нужны.

Даже с учётом immutability? Обход узлов — это уже бесплатно?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 15:10
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>А как быть с заменой символа (например, 1000-ый, в строке, созданной конкатенацией пачки других строк)? В этом случае хочется по возможности не создавать лишние объекты, а значит изменяемый кусок не должен разделяться другими строками.

А давай ты реалистичную задачу придумаешь где это может понадобиться.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 15:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Даже с учётом immutability?

Это к чему?
Ропы сами неизменяемые.

ГВ>Обход узлов — это уже бесплатно?

А зачем нам их обходить?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 04.06.09 15:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

WF>>И что, даже на коротких строках (очень частый случай) «верёвки» будут эффективнее String/StringBuilder?

S>Нет, будут также эффективны.

В терминах O-большого или с учётом константы?
Re[31]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 04.06.09 15:27
Оценка:
Здравствуйте, WolfHound, Вы писали:

WF>>А как быть с заменой символа (например, 1000-ый, в строке, созданной конкатенацией пачки других строк)? В этом случае хочется по возможности не создавать лишние объекты, а значит изменяемый кусок не должен разделяться другими строками.

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

Была как-то задача в тексте case поправить.
Re[31]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 15:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Даже с учётом immutability?

WH>Это к чему?
WH>Ропы сами неизменяемые.

Добавляем новый узел с конкатенацией — нужно продублировать часть узлов исходного дерева, начиная с корня. Не будь требования immutability — можно было бы просто добавить узел. Это оптимистичный случай. Если узлы хранят индексы элементов, и мы вставляем новый узел в начало, то дублировать придётся всё.

ГВ>>Обход узлов — это уже бесплатно?

WH>А зачем нам их обходить?

Например, поиск символа по индексу. Что там у нас со сложностью поиска узла в B+ — дереве?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[32]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 16:33
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>>>А как быть с заменой символа (например, 1000-ый, в строке, созданной конкатенацией пачки других строк)? В этом случае хочется по возможности не создавать лишние объекты, а значит изменяемый кусок не должен разделяться другими строками.

WH>>А давай ты реалистичную задачу придумаешь где это может понадобиться.
WF>Была как-то задача в тексте case поправить.
Те задача звучала исправить регистр 1000ого символа в тексте?
Интересная задачка.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 16:39
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Добавляем новый узел с конкатенацией — нужно продублировать часть узлов исходного дерева, начиная с корня. Не будь требования immutability — можно было бы просто добавить узел. Это оптимистичный случай.

Кто на ком стоял? Выражайся яснее.

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

Какие индексы? Зачем все?

ГВ>Например, поиск символа по индексу. Что там у нас со сложностью поиска узла в B+ — дереве?

Log(N) но зачем искать символ по индексу?
У меня почему то таких задач не возникает.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[29]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 16:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


WF>>И что, даже на коротких строках (очень частый случай) «верёвки» будут эффективнее String/StringBuilder?

WH>Они им не уступят.
В случае если веревки это дерево, то мы теряем да чтении DDR памяти непоследовательного участка памяти.
Правда зависит от размера непрерывной памяти
и солнце б утром не вставало, когда бы не было меня
Re[33]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 04.06.09 16:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

WF>>Была как-то задача в тексте case поправить.

WH>Те задача звучала исправить регистр 1000ого символа в тексте?
WH>Интересная задачка.

Нет, во всём тексте. Включая и 1000-ый символ. Грубо «абвг, деёжз. ийклмн!» => «Абвг, деёжз. Ийклмн!». Со StringBuilder-ом пробежался — и готово.
Re[33]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 16:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Добавляем новый узел с конкатенацией — нужно продублировать часть узлов исходного дерева, начиная с корня. Не будь требования immutability — можно было бы просто добавить узел. Это оптимистичный случай.

WH>Кто на ком стоял? Выражайся яснее.

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

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

WH>Какие индексы? Зачем все?

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

ГВ>>Например, поиск символа по индексу. Что там у нас со сложностью поиска узла в B+ — дереве?

WH>Log(N) но зачем искать символ по индексу?
WH>У меня почему то таких задач не возникает.

Подстроки тоже никогда не выделяешь?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[34]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 17:04
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Нет, во всём тексте. Включая и 1000-ый символ. Грубо «абвг, деёжз. ийклмн!» => «Абвг, деёжз. Ийклмн!». Со StringBuilder-ом пробежался — и готово.

Если по русски: сделать заглавной каждую первую букву предложения.
Ну тогда механика типа http://www.inf.puc-rio.br/~roberto/lpeg/re.html с этим прекрасно справится.
Причем оно будет изначально заточено на работу с конкретной реализацией строки.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 17:06
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> В случае если веревки это дерево, то мы теряем да чтении DDR памяти непоследовательного участка памяти.

S>Правда зависит от размера непрерывной памяти
Это все шито по вроде белыми вилами.
Реально я приводил ссылку где ропы рвали на кровавые ошметки и String и StringBuilder.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[34]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 17:14
Оценка:
ГВ>Как минимум, узлы должны хранить индекс начального элемента собственной подстроки. Могут, конечно, не хранить, но тогда поиск фрагментов очень не кисло усложнится.

В прочем, тут есть более оптимальная структура — хранить в узле только длину фрагмента "слева". Так что, на счёт модификации всех элементов дерева при вставке в начало я погорячился (не внимательно прочёл Боэмовскую бумагу).
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[34]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 17:20
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

Ну и? Создаем Log(N) новых узлов и все.
При конкатенации особенно если глубина деревьев сравнима и того меньше.
А есть еще finger tree. Там все еще интересней.

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

Нет. Им достаточно хранить количество символов в собственной подстроке.

ГВ>Подстроки тоже никогда не выделяешь?

А вот на этой задачке ропы порвут всех на мелкие кровавые ошметки.
Более жестокий разрыв на куски будет только при конкатенации.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 17:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Ну и? Создаем Log(N) новых узлов и все.
WH>При конкатенации особенно если глубина деревьев сравнима и того меньше.
WH>А есть еще finger tree. Там все еще интересней.

Так собственно, речь-то о чём была? О том, что дублирование узлов при соблюдении требования immutability неизбежно.

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

WH>Нет. Им достаточно хранить количество символов в собственной подстроке.

Нет, этого мало.

ГВ>>Подстроки тоже никогда не выделяешь?

WH>А вот на этой задачке ропы порвут всех на мелкие кровавые ошметки.
WH>Более жестокий разрыв на куски будет только при конкатенации.

Ты говорил, что где-то давал ссылку? Можно повторить?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[31]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 04.06.09 18:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


S>> В случае если веревки это дерево, то мы теряем да чтении DDR памяти непоследовательного участка памяти.

S>>Правда зависит от размера непрерывной памяти
WH>Это все шито по вроде белыми вилами.
WH>Реально я приводил ссылку где ропы рвали на кровавые ошметки и String и StringBuilder.
За счет чего можно рвать непрерывную неизменяемую память?
Что касается изменяемой то очень сильно зависит как от размера так и действий.
и солнце б утром не вставало, когда бы не было меня
Re[37]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 18:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Так собственно, речь-то о чём была? О том, что дублирование узлов при соблюдении требования immutability неизбежно.

WH>И в чем проблема?
WH>Ибо даже с учетом этого все работает быстрее.

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

WH>>>Нет. Им достаточно хранить количество символов в собственной подстроке.

ГВ>>Нет, этого мало.
WH>Для чего конкретно этого не хватает?

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

P.S.: Ссылку посмотрел, спасибо. Причины заморочек, ИМХО, понятны — похоже, как раз из-за индексного доступа или требования преобразования к линейному буферу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[38]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 19:14
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Просто такой подход сработает только на длинных строках и только для модификаций. На коротких дешевле будет обычный буфер (в который, в общем-то и должен бы превратиться rope). Ну и иммутабельность должна ещё повлиять: модификации иммутабельного rope будут, конечно, быстрее, чем модификации длинных иммутабельных буферов, но прилично медленнее, чем мутабельных rope-ов.

С какой стати?
Создание узлов операция очень дешевая.

WH>>>>Нет. Им достаточно хранить количество символов в собственной подстроке.

ГВ>>>Нет, этого мало.
WH>>Для чего конкретно этого не хватает?
ГВ>Для доступа по индексу, очевидно.
Те по твоему нельзя реализовать доступ по индексу если каждый узел знает только размер своей подстроки?
Я правильно тебя понял?

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

Опять таки зачем конкретно нужен доступ по индексу к одиночному элементу?

ГВ>P.S.: Ссылку посмотрел, спасибо. Причины заморочек, ИМХО, понятны — похоже, как раз из-за индексного доступа или требования преобразования к линейному буферу.

Нет.
Там заморочки из серии:

Astute readers might wonder why charAt is more than seven times faster than the iterator, given that both provide O(1) access time. This difference is due to the fact that in the Java language, Iterators must return Objects. Although the charAt implementation directly returns char primitives, the iterator implementation must box each char into a Character object. Auto-boxing might sooth the syntactic pain of primitive boxing, but it can't eliminate the performance penalties.

.NET 2.0 и старше конкретно этой заморочкой не страдает.
Хотя и он весьма ущербен.
Короче тут нужно делать нормальную ВМ с нормальным оптимизатором.
Тогда ропы или пальчиковые деревья (надо смотреть что лучше) будут рулить со страшной силой.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 19:15
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> За счет чего можно рвать непрерывную неизменяемую память?

S>Что касается изменяемой то очень сильно зависит как от размера так и действий.
RTFM
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[28]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 19:17
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нуу... Для редактора текстов представление строк (буфферов) будет отличаться от обычных коротких строк.

И чем конкретно ропы не подходят для редактора текста?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[30]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 04.06.09 19:37
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Для редактора текстов заметно лучше подходят строки с gap-буффером.

1)Советую ознакомиться с паттерном zipper.
2)А если рассматривать задачу в комплексе те вспомнить про undo/redo то кто кого порвет мы еще посмотрим...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[39]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 21:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Просто такой подход сработает только на длинных строках и только для модификаций. На коротких дешевле будет обычный буфер (в который, в общем-то и должен бы превратиться rope). Ну и иммутабельность должна ещё повлиять: модификации иммутабельного rope будут, конечно, быстрее, чем модификации длинных иммутабельных буферов, но прилично медленнее, чем мутабельных rope-ов.

WH>С какой стати?
WH>Создание узлов операция очень дешевая.

Это ты из принципа? Очень дешёвая — но всё равно же не нуль.

WH>>>>>Нет. Им достаточно хранить количество символов в собственной подстроке.

ГВ>>>>Нет, этого мало.
WH>>>Для чего конкретно этого не хватает?
ГВ>>Для доступа по индексу, очевидно.
WH>Те по твоему нельзя реализовать доступ по индексу если каждый узел знает только размер своей подстроки?
WH>Я правильно тебя понял?

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

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

WH>Опять таки зачем конкретно нужен доступ по индексу к одиночному элементу?

Есть, например, EDI-протоколы, формат сообщений которых предполагает фиксированные позиции элементов.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[39]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 04.06.09 21:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>P.S.: Ссылку посмотрел, спасибо. Причины заморочек, ИМХО, понятны — похоже, как раз из-за индексного доступа или требования преобразования к линейному буферу.

WH>Нет.
WH>Там заморочки из серии:
WH>

WH>Astute readers might wonder why charAt is more than seven times faster than the iterator, given that both provide O(1) access time. This difference is due to the fact that in the Java language, Iterators must return Objects. Although the charAt implementation directly returns char primitives, the iterator implementation must box each char into a Character object. Auto-boxing might sooth the syntactic pain of primitive boxing, but it can't eliminate the performance penalties.


Ну боксинг, так боксинг.

WH>.NET 2.0 и старше конкретно этой заморочкой не страдает.

WH>Хотя и он весьма ущербен.

И .Net ущербен, и Java — не язык, и C++ — убожество. Инверсный Блаб-парадокс в действии.

WH>Короче тут нужно делать нормальную ВМ с нормальным оптимизатором.


Понеслась коза по рельсам...

WH>Тогда ропы или пальчиковые деревья (надо смотреть что лучше) будут рулить со страшной силой.


Ну "нормальная ВМ" с "нормальным оптимизатором" вообще будет рулить не по-детски и анализировать граф исполнения сможет с учётом всех возможных данных за время, стремящееся к нулю, кто ж спорит?!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[30]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.06.09 03:35
Оценка:
Здравствуйте, WFrag, Вы писали:
WF>В терминах O-большого или с учётом константы?
По идее — без. Короткие rope выродятся в полный аналог String.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 05.06.09 03:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

WF>>В терминах O-большого или с учётом константы?

S>По идее — без. Короткие rope выродятся в полный аналог String.

Да, но Wolfhound предлагает устранить и StringBuilder.

Мне непонятно, как тогда rope получится эффективно удовлетворить оба пункта:

1) Иммутабельные строки, конкатенация длинных строк <-- вот тут rope замечательно подходят (опуская проблемы отдельно взятых VM)
2) Эффективная конкатенация мелочёвки (скажем, по нескольку символов). <-- А тут как быть? Создавать новые листья или узлы деревьев? Как-то неэффективно.
Re[32]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.06.09 04:10
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>1) Иммутабельные строки, конкатенация длинных строк <-- вот тут rope замечательно подходят (опуская проблемы отдельно взятых VM)

WF>2) Эффективная конкатенация мелочёвки (скажем, по нескольку символов). <-- А тут как быть? Создавать новые листья или узлы деревьев? Как-то неэффективно.
Не вижу, почему бы это было неэффективно.
В случае
while()
  rope = rope.Append((Char)random.Next(Char.Maxvalue));

всё будет работать как минимум не хуже, чем со StringBuilder:
1. Буфер под узел выделен с запасом; поэтому можно дописывать ему в конец символы, не разрушая предыдущие значения rope.
2. Когда кончится буфер, создадим новый узел. Это недорого.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 05.06.09 04:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Не вижу, почему бы это было неэффективно.

S>В случае
S>
S>while()
S>  rope = rope.Append((Char)random.Next(Char.Maxvalue));
S>

S>всё будет работать как минимум не хуже, чем со StringBuilder:
S>1. Буфер под узел выделен с запасом; поэтому можно дописывать ему в конец символы, не разрушая предыдущие значения rope.
S>2. Когда кончится буфер, создадим новый узел. Это недорого.

А как же иммутабельность? Получается, либо мы создаём новый объект кадый раз (например, rope, который указывает на то же дерево данных, НО имеет длину + 1), либо мы меняем существующий объект. Но у нас нет разделения неизменямый/изменяемый (String/StringBuilder), состояние какого объекта мы будем менять?
Re[34]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.06.09 05:02
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>А как же иммутабельность? Получается, либо мы создаём новый объект кадый раз (например, rope, который указывает на то же дерево данных, НО имеет длину + 1), либо мы меняем существующий объект. Но у нас нет разделения неизменямый/изменяемый (String/StringBuilder), состояние какого объекта мы будем менять?

А в чём проблема? Ну создали мы новый rope; он показывает на дерево данных, построенное на тех же буферах, что и предыдущий rope.
Представь, что ты решаешь обратную задачу:
rope1 = rope0.Left(rope0.Length-1);

Ведь понятно же, почему при этой операции не нужно никаких копирований буферов? Ну вот конкатенация делает то же самое, только наоборот.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 05.06.09 05:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А в чём проблема? Ну создали мы новый rope; он показывает на дерево данных, построенное на тех же буферах, что и предыдущий rope.

S>Представь, что ты решаешь обратную задачу:
S>
S>rope1 = rope0.Left(rope0.Length-1);
S>

S>Ведь понятно же, почему при этой операции не нужно никаких копирований буферов? Ну вот конкатенация делает то же самое, только наоборот.

Да, но тут нужно создавать новый экземпляр rope (а это память). Добавляя 10 раз по одному символу создадутся 10 экземпляров rope (пусть даже и разделяющих общий буффер с данными). А в случае «классического» StringBuilder-а ничего создавать не нужно (пока хватает capacity буффера) — увеличиваем длину и меняем элементы массива.

Если бы речь шла просто о замене внутренней структуры String и StringBuilder-а с массива на rope (с тем отличием, что StringBuilder может менять своё состояние), то я бы согласился — никаких проблем, можно сделать не хуже обычных String/StringBuilder на массивах. Но, насколько я понял, речь-то идёт о том, что оставить один контракт, иммутабельный String.
У них в описании должно быть
От: Mamut Швеция http://dmitriid.com
Дата: 05.06.09 06:31
Оценка:
WF> Если бы речь шла просто о замене внутренней структуры String и StringBuilder-а с массива на rope (с тем отличием, что StringBuilder может менять своё состояние), то я бы согласился — никаких проблем, можно сделать не хуже обычных String/StringBuilder на массивах. Но, насколько я понял, речь-то идёт о том, что оставить один контракт, иммутабельный String.

В тексте про ropes должно быть это описано: http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[37]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.06.09 06:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


WF>>Да, но тут нужно создавать новый экземпляр rope (а это память).

S>Э-э, как только память станет проблемой, её уберёт GC.
S>С System.String корень неэффективности именно в копировании буферов, т.е. стоимость любой операции в O(N). В rope это будет O(Log(N)), стремящийся к O(1) в простых случаях.

При этом пробег по непрерывной памяти значительно эффективней. Затраты одного создания может быть значительно меньше, затрат на прыжки по узлам.
Плюс GC так или иначе будет дефрагментировать память вместе со строками вкучу, и эффект не копирования буферов сведется если не на нет, то значительно.
Сильно зависит от отношения поиска по строке, и изменением размера строки.
и солнце б утром не вставало, когда бы не было меня
Re[35]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 05.06.09 07:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>>>Thread_safe_string крайне труден в написании.
CC>>Да ну??? Неужто написать COW строку на refcounterах так сложно?
S>И она будет прямо таки вся thread safe?
Будет.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[35]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 05.06.09 07:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

CC>>Да ну??? Неужто написать COW строку на refcounterах так сложно?

WH>Чтобы она еще и работала быстро на многопроцессорной тачке очень сложно.
Не очень. Никто в здравом уме не станет делать полную копию интерфейса мутабельной строки.
По сути по использованию (интерфейсу) thread_safe_string получится почти такая же immutable string как и в шарпе. Некоторые фичи mutable строк (напр. неконстантный operator[] и т.п.) будут разумеется отрезаны.
Ну и GC будет заменен refcounter-ами на буфер строки.

WH>Ибо даже InterlockedIncrement/InterlockedDecrement весьма не бесплатны на многопроцессорных машинах.

Не бесплатны, но и не экстра-дороги.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[27]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 05.06.09 08:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>char szString[N];

PD>>gets(szString);
PD>>strupr(szString);

PD>>и ни одного лишнего байта. Можно такое сделать ?

WH>Что сделать?
WH>Проезд по памяти?

Угу. С преобразованием к верхнему регистру для каждого проезжаемого символа.

WH>Конечно нет.


Именно.
With best regards
Pavel Dvorkin
Re[31]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 05.06.09 09:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Для редактора текстов заметно лучше подходят строки с gap-буффером.

WH>1)Советую ознакомиться с паттерном zipper.
Ознакомился.

WH>2)А если рассматривать задачу в комплексе те вспомнить про undo/redo то кто кого порвет мы еще посмотрим...

А что с ними не так у gap buffers?
Sapienti sat!
Re[40]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 05.06.09 10:12
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Это ты из принципа? Очень дешёвая — но всё равно же не нуль.

А модификация типа нуль?

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

С какой стати?
Решение в каждом узле принимается за O(1) с весьма маленьким О.

ГВ>Есть, например, EDI-протоколы, формат сообщений которых предполагает фиксированные позиции элементов.

Дай ссылку на толковое описание. А то я что-то один маркетинговый булщит нахожу.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[36]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 05.06.09 10:15
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Не очень. Никто в здравом уме не станет делать полную копию интерфейса мутабельной строки.

И не надо. Счетчика ссылок достаточно.

CC>Ну и GC будет заменен refcounter-ами на буфер строки.

Во-во...

WH>>Ибо даже InterlockedIncrement/InterlockedDecrement весьма не бесплатны на многопроцессорных машинах.

CC>Не бесплатны, но и не экстра-дороги.
Достаточно дороги чтобы в большинстве случаев было выгоднее копирование, а не счетчик ссылок.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[32]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 05.06.09 10:22
Оценка:
Здравствуйте, Cyberax, Вы писали:

WH>>1)Советую ознакомиться с паттерном zipper.

C>Ознакомился.
Значит теперь ты сможешь осознать что гапнуть ропу зиппером ни разу не проблема.

WH>>2)А если рассматривать задачу в комплексе те вспомнить про undo/redo то кто кого порвет мы еще посмотрим...

C>А что с ними не так у gap buffers?
А то что их нужно делать.
Нужно придумать структуры данных.
Реализовать без ошибок.
Поддерживать их в актуальном состоянии.
...

А в случае с rope у нас все получается бесплатно.
Все что нужно это добавить 2 односвязных списка.
Один для undo второй для redo.
А односвязные списки как ты понимаешь в любом функциональном языке буквально везде.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[33]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 05.06.09 10:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Ознакомился.

WH>Значит теперь ты сможешь осознать что гапнуть ропу зиппером ни разу не проблема.
А зачем?

WH>>>2)А если рассматривать задачу в комплексе те вспомнить про undo/redo то кто кого порвет мы еще посмотрим...

C>>А что с ними не так у gap buffers?
WH>А то что их нужно делать.
Как и верёвки...

WH>Нужно придумать структуры данных.

Как и верёвки...

WH>Реализовать без ошибок.

Как и верёвки...

WH>Поддерживать их в актуальном состоянии.

Как и верёвки...

WH>А в случае с rope у нас все получается бесплатно.

WH>Все что нужно это добавить 2 односвязных списка.
WH>Один для undo второй для redo.
WH>А односвязные списки как ты понимаешь в любом функциональном языке буквально везде.
Такая структура называется "finger tree" — http://en.wikipedia.org/wiki/Finger_tree

У неё проблема в том, что иногда возникают вырожденные случаи, когда она сильно неэффективна.
Sapienti sat!
Re[33]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 05.06.09 11:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>Я са могу создать иммутабл тип ? Есть такие средства в языке ?

S>Конечно. Будет ничуть не хуже, чем строка. См. DateTime.

Ну ин пусть так.

PD>>Ладно, оставим твои аппеляции к потокобезопасности в стороне. Не всегда она нужна, и уж тебе ли не знать, что большинство классов .Net не являются потокобезопасными, а значит, эту безопасность придется делать вне. Также и здесь можно было бы поступить. Но я даже и это обсуждать не хочу. Допустим, у меня вообще один всего поток — почему я должен платить за эту самую потокобезопасность, если она мне не нужна.

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

Ну это что-то не очень ясное. Готовая отличается от моей тем, что писал ее не я, вот и все. Если это не так, это лишь значит, что МС использует нечто, что не дает мне использовать. Это, кстати, за ней не раз замечалось еще с ДОС времен.

PD>>Слушай, не наводи тень на плетень. Хоть какие вргументы приводи — не докажешь, что не выполнять лишних действий лучше, чем их выполнять

S>Не хочешь — не буду. Это твое дело, насколько неэффективные программы ты будешь писать на управляемых языках.

Не, не буду. Я вообще , когда речь идет об эффективнсти, их использовать не буду

PD>>И потом — а скорость уборки GC всей этой кунсткамеры тоже пренебрежимо мала ?

S>Стоимость уборки строк равна нулю — у них нет финализатора.

А блоки памяти в большом количестве порожденные все же надо убирать ? пусть по алгоритму GC, но все же надо...


PD>>Да нет, в общем-то, угадал. В сущности этот самый m_StringValue и есть кусок из short, точнее, ссылка на него .

S>Не наводи тень на плетень. Ты спрашивал "где строки" — я показал тебе строки. Еще раз тебе объясняю: в управляемой среде в 99% случаев не надо ни "мешать" сборщику мусора, ни "помогать" ему. Понять, что ты попал в 1%, можно исключительно с помощью профайлера. Рассуждения типа "ой, тут что-то копируется, наверное без этого будет дешевле" не работают. Работает только профайлер.

Это твое утверждение можно преобразовать в эквивалентное "сделаем что-то, а потом посмотрим, что из этого получилось". Профалер же не дух святой, а просто средство посмотреть, что в итоге вышло. И не очень хорошо, что нельзя a priory сделать какие-то соображения, а можно только a posteriory смотреть, что вышло. Да, ты мне сейчас прочтешь лекцию в очередной раз о том, где использовать string, а где StringBuilder , но это частный случай, а применять такой подход в общем случае не очень хорошо.

А теперь по существу этой самой иммутабельности. Все же это должно быть свойство не типа , а экземпляра. Экземпляр может быть константой, порождаемой в рантайме, а тип вообще-то не должен. Если нам надо число PI вычислить , то результат должен впоследствии не изменяться, но не потому, что он float или double, а потому что он по смыслу не должен изменяться. А сам тип — не должен быть иммутабельным. Это и к строкам относится.

Что же касается решения Java/.Net о константности типов, то это полурешение, со своими недостатками, о которых тут говорили. И со своими плюсами, о которых тоже говорили.
With best regards
Pavel Dvorkin
Re[34]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.06.09 11:48
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>А блоки памяти в большом количестве порожденные все же надо убирать ? пусть по алгоритму GC, но все же надо...

Убирать, то есть дефрагментировать нужно живые блоки. Если живых блоков нет, то просто сдвинется учазатель конца кучи.
и солнце б утром не вставало, когда бы не было меня
Re[34]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.06.09 11:54
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>А теперь по существу этой самой иммутабельности. Все же это должно быть свойство не типа , а экземпляра. Экземпляр может быть константой, порождаемой в рантайме, а тип вообще-то не должен. Если нам надо число PI вычислить , то результат должен впоследствии не изменяться, но не потому, что он float или double, а потому что он по смыслу не должен изменяться. А сам тип — не должен быть иммутабельным. Это и к строкам относится.


Как раз имея иммутабельность по типу и хороша тем, что не нужно делать проверки в рантайме на иммутабельность, которые могут вылезать неизвестно когда.
и солнце б утром не вставало, когда бы не было меня
Re[34]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 05.06.09 12:18
Оценка:
Здравствуйте, Cyberax, Вы писали:

WH>>Значит теперь ты сможешь осознать что гапнуть ропу зиппером ни разу не проблема.

C>А зачем?
За тем чтобы ее можно было эффективно использовать в редакторе?

WH>>А то что их нужно делать.

C>Как и верёвки...
Это сделал разработчик стандартной библиотеки.

WH>>Нужно придумать структуры данных.

C>Как и верёвки...
Это сделал разработчик стандартной библиотеки.

WH>>Реализовать без ошибок.

C>Как и верёвки...
Это сделал разработчик стандартной библиотеки.

WH>>Поддерживать их в актуальном состоянии.

C>Как и верёвки...
Тут тебя вообще куда то понесло.
Я говорил про то что эти самые структуры для undo/redo нужно во время редактирования текста постоянно обновлять.
В случае с ропами это тривиально и сводится к добавлению текущего состояния в список undo состояний.

C>Такая структура называется "finger tree" — http://en.wikipedia.org/wiki/Finger_tree

Это вообще не про то.
Пальчиковые деревья альтернатива ропам, а не undo/redo стеку.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[35]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 05.06.09 12:24
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Значит теперь ты сможешь осознать что гапнуть ропу зиппером ни разу не проблема.

C>>А зачем?
WH>За тем чтобы ее можно было эффективно использовать в редакторе?
Некоторые вещи в делаются проще с gap-буффером.

WH>>>Реализовать без ошибок.

C>>Как и верёвки...
WH>Это сделал разработчик стандартной библиотеки.
И что?

Это не отменяет тот факт, что обе структуры

WH>Тут тебя вообще куда то понесло.

WH>Я говорил про то что эти самые структуры для undo/redo нужно во время редактирования текста постоянно обновлять.
WH>В случае с ропами это тривиально и сводится к добавлению текущего состояния в список undo состояний.
Примерно аналогично это делается для gap-буффера — просто достаточно запоминать его позицию и состояние. Причём у нас будет гарантия O(1) сложности по времени и памяти для стека undo/redo.

C>>Такая структура называется "finger tree" — http://en.wikipedia.org/wiki/Finger_tree

WH>Это вообще не про то.
WH>Пальчиковые деревья альтернатива ропам, а не undo/redo стеку.
Rope с undo/redo стеком в них вырождается.
Sapienti sat!
Re[33]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 05.06.09 13:18
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


S>> За счет чего можно рвать непрерывную неизменяемую память?

S>>Что касается изменяемой то очень сильно зависит как от размера так и действий.
WH>RTFM
Хороший ответ. Попрбую по друному задать вопрос.
Если мы выделили строку из 10 строк один раз, и пользуем как ключ или поиска в достаточно большом объеме, то затраты по поиску будут одинаковы для непрерывной памяти или списка из 10 строк.
При сборке мусора не будут ли дефрагментироваться эти 10 строк, и по сути получать те же затраты по копирования при слиянию строк?
и солнце б утром не вставало, когда бы не было меня
Re[41]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 05.06.09 21:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Это ты из принципа? Очень дешёвая — но всё равно же не нуль.

WH>А модификация типа нуль?

Ну я не знаю... Вставить один узел или Log(N). ИМХО, разница есть.

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

WH>С какой стати?
WH>Решение в каждом узле принимается за O(1) с весьма маленьким О.

Даже очень маленькая O это всё равно не нуль. И потом, поиск символа ближе к концу строки будет уже O(N) — нужно будет перебрать все узлы.

ГВ>>Есть, например, EDI-протоколы, формат сообщений которых предполагает фиксированные позиции элементов.

WH>Дай ссылку на толковое описание. А то я что-то один маркетинговый булщит нахожу.

Вот, например. Правда, протокол, скорее всего, малораспространённый. Поищу на выходных ещё ссылки, точно помню, что были и другие. Потом, в тех же форматах EDI нередко встречаются такие описания сегментов, как, скажем YYYYMMDD — тоже, в общем, формат представления с фиксированными позициями элементов. Хотя такой пример, наверное, уже крайность.

Ну и ещё в копилку рассуждений о строках — формат символов в том же ворохе протоколов EDI нередко бывает 8-битным, без всякого юникода.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[36]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 06.06.09 14:39
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Некоторые вещи в делаются проще с gap-буффером.

Какие?

WH>>Это сделал разработчик стандартной библиотеки.

C>И что?
И то что автору редактора ее писать не придется.

C>Это не отменяет тот факт, что обе структуры

Только автору редактора с гап буфером придется придумывать и реализовывать структуру для undo/redo, а автору редактора на ропах нет.

C>Примерно аналогично это делается для gap-буффера — просто достаточно запоминать его позицию и состояние. Причём у нас будет гарантия O(1) сложности по времени и памяти для стека undo/redo.


Что ты будешь делать с удалением?
Или когда дырка закончилась?
Короче сложность реализации просто не сравнима.

C>Rope с undo/redo стеком в них вырождается.

Я думаю ты что-то где-то очень сильно путаешь.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[37]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 06.06.09 14:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Некоторые вещи в делаются проще с gap-буффером.

WH>Какие?
Массовые операции замены, разбиение на строки, text wrapping и т.д.

C>>Это не отменяет тот факт, что обе структуры

WH>Только автору редактора с гап буфером придется придумывать и реализовывать структуру для undo/redo, а автору редактора на ропах нет.
Если она есть в стандартной библиотеке.

C>>Примерно аналогично это делается для gap-буффера — просто достаточно запоминать его позицию и состояние. Причём у нас будет гарантия O(1) сложности по времени и памяти для стека undo/redo.

WH>
WH>Что ты будешь делать с удалением?
А с ним надо что-то особое делать? Точно так же запоминаем позицию и содержание дырки.

WH>Или когда дырка закончилась?

Единственный сложный случай.

WH>Короче сложность реализации просто не сравнима.

Очень даже. Весь код gap string помещается в сотню строк (я знаю, сам их реализовывал). Вместе с undo/redo.

C>>Rope с undo/redo стеком в них вырождается.

WH>Я думаю ты что-то где-то очень сильно путаешь.
Я написал очень длинный пост на эту тему, но RSDN вчера его съел. Сейчас вот снова буду писать.
Sapienti sat!
Re[42]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 06.06.09 14:49
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

WH>>А модификация типа нуль?

ГВ>Ну я не знаю... Вставить один узел или Log(N). ИМХО, разница есть.
Это если говорить про оптимистический случай.
А в среднем разницы не будет.

ГВ>Даже очень маленькая O это всё равно не нуль. И потом, поиск символа ближе к концу строки будет уже O(N) — нужно будет перебрать все узлы.

Чё? С какой это стати O(N)?
Log(N) гарантировано.
Попробуй объяснить откуда ты взял O(N). Я не понимаю.

ГВ>Вот, например. Правда, протокол, скорее всего, малораспространённый. Поищу на выходных ещё ссылки, точно помню, что были и другие. Потом, в тех же форматах EDI нередко встречаются такие описания сегментов, как, скажем YYYYMMDD — тоже, в общем, формат представления с фиксированными позициями элементов. Хотя такой пример, наверное, уже крайность.

Понятно.
Только эта задача к строкам не относится.
Тут у нас сериализация/десериализация в/из бинарного потока.
Решается декларативно на любом языке с нормальными макросами или хотя бы рефлексией.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[38]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 06.06.09 15:07
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Массовые операции замены,

Что-то не верится.

C>разбиение на строки,

Куда проще то?

C>text wrapping и т.д.

Чего?

C>Если она есть в стандартной библиотеке.

Библиотеках функциональных языков должна быть.

WH>>Или когда дырка закончилась?

C>Единственный сложный случай.
Не верю что единственный.

C>Очень даже. Весь код gap string помещается в сотню строк (я знаю, сам их реализовывал). Вместе с undo/redo.

Ну тогда код в студию.
Только обязательно вместе с undo/redo.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[43]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.06.09 15:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>А модификация типа нуль?

ГВ>>Ну я не знаю... Вставить один узел или Log(N). ИМХО, разница есть.
WH>Это если говорить про оптимистический случай.
WH>А в среднем разницы не будет.

Здравствуйте?! И в среднем разница будет. Хотя бы потому что мутабельный rope не требует дублировать корневой узел и весь путь от корня до модифицируемого узла.

ГВ>>Даже очень маленькая O это всё равно не нуль. И потом, поиск символа ближе к концу строки будет уже O(N) — нужно будет перебрать все узлы.

WH>Чё? С какой это стати O(N)?
WH>Log(N) гарантировано.
WH>Попробуй объяснить откуда ты взял O(N). Я не понимаю.

Извини, я не уточнил, что в данном случае N — количество узлов дерева сегментов.

ГВ>>Вот, например. Правда, протокол, скорее всего, малораспространённый. Поищу на выходных ещё ссылки, точно помню, что были и другие. Потом, в тех же форматах EDI нередко встречаются такие описания сегментов, как, скажем YYYYMMDD — тоже, в общем, формат представления с фиксированными позициями элементов. Хотя такой пример, наверное, уже крайность.

WH>Понятно.
WH>Только эта задача к строкам не относится.

Ты спросил, где может потребоваться индексный доступ, я ответил.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[44]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 06.06.09 16:59
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здравствуйте?! И в среднем разница будет. Хотя бы потому что мутабельный rope не требует дублировать корневой узел и весь путь от корня до модифицируемого узла.

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

ГВ>Извини, я не уточнил, что в данном случае N — количество узлов дерева сегментов.

Да как ни крути, а пройтись придется только по узлам от корня до нужного листа.
Короче давай объясняй откуда взял O(N).

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

А я пояснил что:
1)К строкам это отношения не имеет.
2)Учитывая опциональные поля по индексу ходить не получится.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[45]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 06.06.09 22:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

ГВ>>Здравствуйте?! И в среднем разница будет. Хотя бы потому что мутабельный rope не требует дублировать корневой узел и весь путь от корня до модифицируемого узла.

WH>А у изменяемой ропы типа новые узлы создавать не надо?

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

WH>А для массовых вставок есть зипперы. Или можно сразу взять пальчиковое дерево которое по сути хитрая помесь ропы с зиппером.


Это сейчас к делу не относится.

ГВ>>Извини, я не уточнил, что в данном случае N — количество узлов дерева сегментов.

WH>Да как ни крути, а пройтись придется только по узлам от корня до нужного листа.

Кстати, как ты этот узел искать будешь? Либо с узлом должно быть сопоставлено его смещение в строке, либо нужно перебирать все узлы с начала (с самого левого).

WH>Короче давай объясняй откуда взял O(N).


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

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

WH>А я пояснил что:
WH>1)К строкам это отношения не имеет.

Имеет самое прямое.

WH>2)Учитывая опциональные поля по индексу ходить не получится.


Отнюдь. Посмотри спецификацию внимательней — сегменты фиксированной длины расположены в начале каждой строки.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[46]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 07.06.09 09:19
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

WH>>А для массовых вставок есть зипперы. Или можно сразу взять пальчиковое дерево которое по сути хитрая помесь ропы с зиппером.

ГВ>Это сейчас к делу не относится.
Еще как относится.

ГВ>Кстати, как ты этот узел искать будешь? Либо с узлом должно быть сопоставлено его смещение в строке, либо нужно перебирать все узлы с начала (с самого левого).

А как в бинарных деревьях поиска ищут?

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

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

WH>>1)К строкам это отношения не имеет.

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

WH>>2)Учитывая опциональные поля по индексу ходить не получится.

ГВ>Отнюдь. Посмотри спецификацию внимательней — сегменты фиксированной длины расположены в начале каждой строки.

1)Там все сегменты фиксированной длинны.
2)А с опциональными что делать будешь? С ними доступ по индексу уже не работает.
3)Плюс еще не мешало бы разобраться сегмент какого типа ты пытаешься читать.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[47]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 07.06.09 22:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>А для массовых вставок есть зипперы. Или можно сразу взять пальчиковое дерево которое по сути хитрая помесь ропы с зиппером.

ГВ>>Это сейчас к делу не относится.
WH>Еще как относится.

Как это? Мы же, вроде, ропы обсуждали. Да ещё и весьма узкие моменты оных.

ГВ>>Кстати, как ты этот узел искать будешь? Либо с узлом должно быть сопоставлено его смещение в строке, либо нужно перебирать все узлы с начала (с самого левого).

WH>А как в бинарных деревьях поиска ищут?

Я первый спросил. И вообще — ты сам сказал, что в узле достаточно хранить только длину его собственной подстроки. Вот теперь и рассказывай, как ты будешь в таком дереве что-то искать.

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

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

Ясное дело. И что такое деревья, первый раз узнал на RSDN третьего дня.

WH>>>1)К строкам это отношения не имеет.

ГВ>>Имеет самое прямое.
WH>Ну если на все смотреть чисто с точки зрения С/С++ программиста то может и имеет.

Это если смотреть с позиций первого приближения, с каковых я тебе и приводил это пример. Понадобится ли строка в реальности — трудно судить наперёд.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[35]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 04:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Нет, не надо. Читать RTFM про то, как работает GC. Он не занимается уборкой.


Уборкой или не уборкой, но исследованием кучи он занимаетеся или нет ? И время на это исследование от числа объектов там зависит или тоже нет ?

S>Можно. Можно априори. Но для того, чтобы научиться это делать, нужно сначала съесть 16кг соли с профайлером. И только после этого у тебя будет достаточно статистики для того, чтобы интуиция давала правильные подсказки.


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

>Интуиция, натренированная на С++, будет постоянно подводить в управляемой среде.


Вот-вот.

PD>>А теперь по существу этой самой иммутабельности. Все же это должно быть свойство не типа , а экземпляра. Экземпляр может быть константой, порождаемой в рантайме, а тип вообще-то не должен. Если нам надо число PI вычислить , то результат должен впоследствии не изменяться, но не потому, что он float или double, а потому что он по смыслу не должен изменяться. А сам тип — не должен быть иммутабельным. Это и к строкам относится.

S>Нет. Это трагическое заблуждение. Свойство экземпляра даёт слишком мало информации среде исполнения для эффективной оптимизации.

Попробуй обоснуй. Экземпляр привязан к типу, так что информация о типе всегда налицо. Чего ей не хватает ? Она может даже поместить этот объект в R/O секцию, так что все попытки его модифицировать вызовут exception
With best regards
Pavel Dvorkin
Re[36]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.06.09 05:09
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


S>>Нет, не надо. Читать RTFM про то, как работает GC. Он не занимается уборкой.


PD>Уборкой или не уборкой, но исследованием кучи он занимаетеся или нет ? И время на это исследование от числа объектов там зависит или тоже нет ?

Ты удивишься
http://www.rsdn.ru/article/dotnet/GC.xml#E6KAC
Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.


PD>>>А теперь по существу этой самой иммутабельности. Все же это должно быть свойство не типа , а экземпляра. Экземпляр может быть константой, порождаемой в рантайме, а тип вообще-то не должен. Если нам надо число PI вычислить , то результат должен впоследствии не изменяться, но не потому, что он float или double, а потому что он по смыслу не должен изменяться. А сам тип — не должен быть иммутабельным. Это и к строкам относится.

S>>Нет. Это трагическое заблуждение. Свойство экземпляра даёт слишком мало информации среде исполнения для эффективной оптимизации.

PD>Попробуй обоснуй. Экземпляр привязан к типу, так что информация о типе всегда налицо. Чего ей не хватает ? Она может даже поместить этот объект в R/O секцию, так что все попытки его модифицировать вызовут exception

R/O секцию чего? Стека? Кучи?
Re[36]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 06:42
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Уборкой или не уборкой, но исследованием кучи он занимаетеся или нет ? И время на это исследование от числа объектов там зависит или тоже нет ?


Исследуюется не вся куча. Так как считается, что объекты в ненулевом поколении не изменяются, то на них ссылки учитываются только при изменении, этим кстати обусловлены тормоза при изменеии ссылок в высших поколениях.
Влад хорошо про GC написал http://rsdn.ru/article/dotnet/GC.xml#EFNAC
Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.

Ознакомься со статьей полезно.
Поэтому лучше иметь массив структур, нежели массив объектов.
И лучше иметь классы строк имеющих структуру опитимальную для характера её использования. В этом плане зоопарк приветствуется.
и солнце б утром не вставало, когда бы не было меня
Re[47]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 06:50
Оценка:
Здравствуйте, Хвост, Вы писали:


C>>Небольшой тест производительности std::wstring в сравнении со StringBuilder.


Х>чем больше я вижу твоего С++ кода, тем больше понимаю почему тебе было мучительно больно на нём писать и ты перелез на C#


Говорю же, писалось на коленке за пять минут. Вам больше нечего сказать кроме перехода на личности? Или Вас так обидело, что "тормозной" дотнет порвал С++ STL, как тузик грелку?
Re[37]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 07:03
Оценка:
Здравствуйте, gandjustas, Вы писали:

PD>>Попробуй обоснуй. Экземпляр привязан к типу, так что информация о типе всегда налицо. Чего ей не хватает ? Она может даже поместить этот объект в R/O секцию, так что все попытки его модифицировать вызовут exception

G>R/O секцию чего? Стека? Кучи?

Просто R/O секцию. Создается в C++ #pragma dataseg(имя). Ей можно поставить атрибуты без W. Некая функция (конструктор констант , получив ее базовый адрес, ставит разрешение по записи, записывает, снимает опять. А что и как там хранить — предмет отдельного разговора. Например, куча константных объектов, которые можно туда добавлять и оттуда удалять (эти методы могут снимать защиту), но функции их изменения получат exception просто по защите на уровне процессора, так как снимать защиту не умеют.
With best regards
Pavel Dvorkin
Re[47]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.06.09 07:25
Оценка:
Здравствуйте, Хвост, Вы писали:

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


C>>Небольшой тест производительности std::wstring в сравнении со StringBuilder.


Х>чем больше я вижу твоего С++ кода, тем больше понимаю почему тебе было мучительно больно на нём писать и ты перелез на C#


Чего словами кидаться. Давай соптимизируй плюсовый код criosray, чтобы он был быстрее, так чтобы там stl остался.
Re[29]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 07:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

PD>>Угу. С преобразованием к верхнему регистру для каждого проезжаемого символа.
S>Включая те, которые вылезли за пределы N. У тебя нелимитированный gets в программе — а это классика buffer overrun. И не говори мне, что реальные программы так не пишут — вот только что ажно преподаватель попросил нас написать аналог именно этой программы на С#. Чего уж тогда от студентов ожидать.

Ну да, конечно, если не чего сказать по существу, то надо перевести вопрос на что-то иное. Я этот пример привел для демонстрации совсем другого вопроса, а из твоих слов получается, что я должен был еще и этим специально заняться, только чтобы тебе не к чему было придраться. Не буду — у меня на это времени нет. Никакого отношения к сути вопроса это не имеет.
With best regards
Pavel Dvorkin
Re[36]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.06.09 08:42
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Уборкой или не уборкой, но исследованием кучи он занимаетеся или нет ? И время на это исследование от числа объектов там зависит или тоже нет ?

От числа объектов, в которых нет ссылки наружу, это время никак не зависит. GC знает, что где искать.

PD>Это совсем не плюс. Фактически ты утверждаешь следующее — априорная оценка может базироваться не на свойствах алгоритма или информации о времени выполнения команд/доступа к памяти/и т.д, а только на основе прошлых экспериментов с этой системой по механизму черного ящика.

Нет. Чёрный ящик — это когда ты просто меришь общее время работы машины и вносишь хаотические изменения. Профайлер позволяет тебе посмотреть внутрь машины и получить информацию о времени выполнения команд, доступа к памяти и так далее.
PD>Все это весьма напоминает попытку вставить палец в отверстие машины, созданной Странниками в надежде на то, что движение машины после этого будет ровным и непреодолимым, ну а автора ждет награда от великого и могучего Утеса с ногой на солнце . Я все же предпочитаю ситуацию, когда я о машине что-то знаю, а не просто сую палец в отверстие и жду, что из этого выйдет.
Нет, не предпочитаешь. Уже несколько лет ты, вместо того, чтобы что-то узнать о машине, занимаешься попытками перенести эмпирический опыт использования другой машины, на эту.

S>>Нет. Это трагическое заблуждение. Свойство экземпляра даёт слишком мало информации среде исполнения для эффективной оптимизации.


PD>Попробуй обоснуй. Экземпляр привязан к типу, так что информация о типе всегда налицо. Чего ей не хватает ? Она может даже поместить этот объект в R/O секцию, так что все попытки его модифицировать вызовут exception

Это лучший способ просадить производительность. Система типов позволяет заенфорсить иммутабельность без рантайм-проверок — только путём статического анализа кода.
Соответственно другой код точно так же статически может быть оптимизирован — к примеру, потому, что ему не надо проверять неизменность экземпляра при каждом обращении.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[39]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 08:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

PD>>Просто R/O секцию. Создается в C++ #pragma dataseg(имя). Ей можно поставить атрибуты без W. Некая функция (конструктор констант , получив ее базовый адрес, ставит разрешение по записи, записывает, снимает опять. А что и как там хранить — предмет отдельного разговора. Например, куча константных объектов, которые можно туда добавлять и оттуда удалять (эти методы могут снимать защиту), но функции их изменения получат exception просто по защите на уровне процессора, так как снимать защиту не умеют.


G>Выделенное — дикий оверхед, оптимизацей в таком случае и не пахнет.


Не особенно такой уж дикий. Все зависит от того, где и как это применять.

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


Да, но оно позволяет иметь неизменяемость независимо от типа .
With best regards
Pavel Dvorkin
Re[48]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 08:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Мы же, вроде, ропы обсуждали. Да ещё и весьма узкие моменты оных.


Ну так зиппер имеет точно такое же отношение к деревьям (и, следовательно ропам), какое gap имеет к массивам.
Или о нем говорить нельзя потому, что это реальное решение проблемы?

ГВ>Я первый спросил. И вообще — ты сам сказал, что в узле достаточно хранить только длину его собственной подстроки. Вот теперь и рассказывай, как ты будешь в таком дереве что-то искать.


Детский сад — штаны на лямках.

дерево:
root(N1_6)
N1 = 6
N2 = 2
l(N1) -> N2
r(N1) -> L3_4
l(N2) -> L1_2
r(N2) -> L2_4

доступ к элементу номер 4:
Стоим на N1.
4 < 6 -> переходим на N2
4 > 2 -> 4-2 = 2 -> переходим на L2
Возвращаем второй элемент L2
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[37]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 09:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>Уборкой или не уборкой, но исследованием кучи он занимаетеся или нет ? И время на это исследование от числа объектов там зависит или тоже нет ?

S>От числа объектов, в которых нет ссылки наружу, это время никак не зависит. GC знает, что где искать.

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

S>Нет. Чёрный ящик — это когда ты просто меришь общее время работы машины и вносишь хаотические изменения.


Ничего подобного. Отуда ты взял про хаотические изменения ? Наоборот, у меня может быть очень даже серьезный план работы с этим черным ящиком. Например, не зная, как именно протекает некая реакция (механизм), я все же могу , работая с ней в этом плане как с черным ящиком, составить вполне осмысленный план действий по изучению влияния на нее температуры, давления, света и т.д. И вообще читать про планирование эксперимента.
И вносить эти изменения я буду отнюдь не хаотически. Если, конечно, это Черный Ящик, а не эвристическая машина Машкина

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


Ну и что ?

Вот допустим я, отнюдь не гуру в .Net, написал что-то, а быстродействие этого чего-то меня не устраивает. Пустил профайлер — что-то узнал. Как мне это применить для следующей задачи ? Пуд соли я не съел, и не скоро съем. Для C++ все ясно — используешь медленную функцию, поставил не лучший алгоритм N^2 вместо Nlog(N), память выделяешь не оптимально. Все так или иначе документировано и от наличия или отсутствия опыта у меня не очень зависит. Нашел bottleneck — определи суть — больше так не делай. Не потому, что профайлер показал его, а по определенной сути. В принципе я мог бы и без профалера эту суть найти, просто анализом, медленнее, конечно, будет. А ты сам говоришь — попробуешь улучшить — чего доброго ухудшишь, пока пуд соли не съешь и эмпирические правила не освоишь. Вот так не делай, не потому что суть этого плохая, а потому что прошлый раз плохо получилось

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

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

Да нужна она мне как корове седло, эта машина . Я бы давно все о ней узнал, если бы она могла быть всерьез полезна для моих задач. А пока что пользы
от нее — GUI слепить, без которого бы и обйтись вполне можно, да заказчик хочет "сделайте мне красиво". А для того, чем я в основном занимаюсь, эта машина так же пригодна, как эвристическая машина Машкина для предсказания погоды. Еще года 3-4 назад я замерял быстродействие по сравнению с С++ для тех примеров, которые меня интересуют. 3-5% потерю я бы еще стерпел (и то не уверен, я за каждую мсек бьюсь), а уж когда в 1.5-2 раза — всего хорошего.

S>>>Нет. Это трагическое заблуждение. Свойство экземпляра даёт слишком мало информации среде исполнения для эффективной оптимизации.


PD>>Попробуй обоснуй. Экземпляр привязан к типу, так что информация о типе всегда налицо. Чего ей не хватает ? Она может даже поместить этот объект в R/O секцию, так что все попытки его модифицировать вызовут exception

S>Это лучший способ просадить производительность. Система типов позволяет заенфорсить иммутабельность без рантайм-проверок — только путём статического анализа кода.

Что-то я опять не понял. Жара, что ли, действует, у нас тут +35
Вот есть экземпляр в R/O секции. Вызываем его const (в смысле C++) метод. Поскольку этот метод срабатывает без сучка и задоринки, то что тут есть R/O, что нет — оверхед нулевой. А поскольку нормальные программы модифицировать константные объекты все же не будут, как правило, пытаться, то в итоге опять же нулевой оверхед. Ну а если кто-то будет — схлопочет exception, вот и все. И никакой проверки тут вообще не надо — пущай процессор проверяет, он и так это всегда делает. Унутре . Так уж он сделан . Страничный механизм, атрибуты страниц и т.д.

Вот на размещение и удаление объектов оверхед будет, тут придется системный сервис дергать, VirtualProtect. Но опять-таки, все зависит от того, как часто и когда его дергать... Если константы создаются пакетом, то можно и один раз. Что-то вроде WriteFileGather vs N раз WriteFile.

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


Еще раз — для объекта в R/O секции вообще ничего проверять не надо.
With best regards
Pavel Dvorkin
Re[40]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 09:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>Выделенное — дикий оверхед, оптимизацей в таком случае и не пахнет.


PD>Не особенно такой уж дикий. Все зависит от того, где и как это применять.


Решил проверить


int _tmain(int argc, _TCHAR* argv[])
{
    MEMORY_BASIC_INFORMATION mbi;
    DWORD dwOld;
    VirtualQuery(_tmain,&mbi, sizeof(mbi));
    DWORD dwTimeStart = GetTickCount();
    for( int i = 0; i < 1000000; i++)
        VirtualProtect(_tmain,4096,mbi.AllocationProtect,&dwOld);
    DWORD dwTimeEnd = GetTickCount();
    printf("Time = %f sec\n", ((float)dwTimeEnd - dwTimeStart)/1000);
    return 0;


На моей машине (Athlon 4200+ Dual) этот код в Release работает 1.015 сек. То есть на один VirtualProtect уходит микросекунда. А если еще предусмотреть пакетное создание констант , то не на каждое добавление придется VirtualProtect дергать. А уж освободить все можно вообще одним вызовом VirtualFree
With best regards
Pavel Dvorkin
Re[49]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 09:43
Оценка:
Здравствуйте, Klapaucius, Вы писали:

ГВ>>Мы же, вроде, ропы обсуждали. Да ещё и весьма узкие моменты оных.

K>Ну так зиппер имеет точно такое же отношение к деревьям (и, следовательно ропам), какое gap имеет к массивам.
K>Или о нем говорить нельзя потому, что это реальное решение проблемы?

Да нет, это чтобы не распыляться.

ГВ>>Я первый спросил. И вообще — ты сам сказал, что в узле достаточно хранить только длину его собственной подстроки. Вот теперь и рассказывай, как ты будешь в таком дереве что-то искать.


K>Детский сад — штаны на лямках.


K>дерево:

K>root(N1_6)
K>N1 = 6
K>N2 = 2

Что означают 2 и 6? Длины собственных подстрок узлов? Индексы? Суммарные длины всех подстрок каждого узла?

K>l(N1) -> N2

K>r(N1) -> L3_4
K>l(N2) -> L1_2
K>r(N2) -> L2_4

K>доступ к элементу номер 4:

K>Стоим на N1.
K>4 < 6 -> переходим на N2
K>4 > 2 -> 4-2 = 2 -> переходим на L2
K>Возвращаем второй элемент L2
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[50]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 09:51
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

K>>Ну так зиппер имеет точно такое же отношение к деревьям (и, следовательно ропам), какое gap имеет к массивам.

K>>Или о нем говорить нельзя потому, что это реальное решение проблемы?
ГВ>Да нет, это чтобы не распыляться.

Озвучена проблема. В ответ представлено решение. Это теперь распылением называется? Кака раз редкий для этого форума случай ответа по теме обсуждения.

ГВ>Что означают 2 и 6? Длины собственных подстрок узлов? Индексы? Суммарные длины всех подстрок каждого узла?


Это суммарные длины всех подстрок слева.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[49]: Забыл уточнить
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 09:52
Оценка:
Это всё — для 32-битной конфигурации. Попозже проверю на 64-битной.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[51]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 09:58
Оценка:
Здравствуйте, Klapaucius, Вы писали:

ГВ>>Что означают 2 и 6? Длины собственных подстрок узлов? Индексы? Суммарные длины всех подстрок каждого узла?

K>Это суммарные длины всех подстрок слева.

А теперь перечитай внимательно мою с WolfHound дискуссию. WolfHound утверждал, что достаточно положить в узлы длины собственных подстрок.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[53]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 10:11
Оценка:
Здравствуйте, Klapaucius, Вы писали:

ГВ>>А теперь перечитай внимательно мою с WolfHound дискуссию. WolfHound утверждал, что достаточно положить в узлы длины собственных подстрок.

K>Это они и есть.

Кто????? Длины собственных подстрок узлов — это теперь то же самое, что длина слева? У тебя там улыбка Чеширского кота рядом не летает?

K>Смысл дискуссии был в том нужно ли обходить все узлы для доступа по индексу — правильный ответ — нет.


Спасибо, это мне известно почему-то. Я пытался уяснить магию с длинами собственных подстрок.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[49]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 10:18
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


C>>>>Небольшой тест производительности std::wstring в сравнении со StringBuilder.

Х>>>чем больше я вижу твоего С++ кода, тем больше понимаю почему тебе было мучительно больно на нём писать и ты перелез на C#
G>>Чего словами кидаться. Давай соптимизируй плюсовый код criosray, чтобы он был быстрее, так чтобы там stl остался.

ГВ>Лучше чуточку к реальности приблизить. Скопируем полученные строки в массив:


К какой реальности? Никто в здравом уме не станет 25 тыс. раз в цикле вызывать ToString для StringBuilder`а.
Re[55]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 10:27
Оценка:
Здравствуйте, Klapaucius, Вы писали:

ГВ>>Кто????? Длины собственных подстрок узлов — это теперь то же самое, что длина слева?

K>Да не длина слева, а суммарная длина собственных (те, что в левом поддереве узла) подстрок узла.

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

K>Дерево — рекурсивная структура.

K>Без картинки не понятно что-ли?

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

ГВ>>Я пытался уяснить магию с длинами собственных подстрок.

K>Эта магия называется аккумулятор. Проходят в первом классе, когда складывают (мысленно) яблоки из маленьких корзин в большую.

Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[56]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 10:38
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Ну так вы не могли понять, как можно одновременно не заменять все узлы при перестроении и не проходить по всем узлам при доступе по индексу. Я показал как. Какая разница теперь что скажет WolfHound — это имеет значение? Думаете, тут многие люди не понимают, как деревья поиска работают?
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[57]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 10:42
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


K>Ну так вы не могли понять, как можно одновременно не заменять все узлы при перестроении и не проходить по всем узлам при доступе по индексу. Я показал как. Какая разница теперь что скажет WolfHound — это имеет значение? Думаете, тут многие люди не понимают, как деревья поиска работают?


Вспомни, чем было спровоцировано моё непонимание. Здесь же все ходы записаны.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[58]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 11:03
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Вспомни, чем было спровоцировано моё непонимание. Здесь же все ходы записаны.

ГВ>>Если узлы хранят индексы элементов, и мы вставляем новый узел в начало, то дублировать придётся всё.
WH>Какие индексы? Зачем все?

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

Ну и чем может быть спровоцировано такое непонимание? Для добавления последовательности в начало нужно заменить 0 узлов. И создать 1 новый узел. Сложность O(1). При этом доступ по индексу будет с логарифмическим.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[59]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 11:11
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Ну и чем может быть спровоцировано такое непонимание? Для добавления последовательности в начало нужно заменить 0 узлов. И создать 1 новый узел. Сложность O(1). При этом доступ по индексу будет с логарифмическим.

Если речь идет об иммутабельной структуре, то придется создать новые узлы от вершины до модифицируемого узла, модифицируя в том числе и суммарные длины в подветках.
Сложность будет равна сложности поиска.
и солнце б утром не вставало, когда бы не было меня
Re[60]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 11:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

K>>Ну и чем может быть спровоцировано такое непонимание? Для добавления последовательности в начало нужно заменить 0 узлов. И создать 1 новый узел. Сложность O(1). При этом доступ по индексу будет с логарифмическим.

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

Это для вставки. А не для добавления к началу/концу т.е. конкатенации.
Преимущество у мутабольного дерева будет не очень существенным (да и то только при однопоточности) — алгоритмическая сложность та же, просто вместо создания нескольких небольших объектов-узлов будет модификация (не атомарная). Ну и с персистентностью придется распрощаться.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[51]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 11:23
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Лучше чуточку к реальности приблизить. Скопируем полученные строки в массив:


C>>К какой реальности?


ГВ>К повседневной, в которой строки, синтезированные StringBuilder-ом не хранятся в самом StringBuilder-е.


То есть у Вас среди повседневных задач формирование вектора из десятков тысяч вызовов ToString() StringBuilder`а? Что-то мне не верится в это.

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

C>>Никто в здравом уме не станет 25 тыс. раз в цикле вызывать ToString для StringBuilder`а.


ГВ>Ну никто в здравом уме не станет и 100000000 раз вызывать в цикле append для std::wstring.


Естественно. Это синтетика для чистого сравнения методов append. 10 млн только для того, чтоб более явно была видна разница.


Так что там с Replace? Мы увидим тест для replace внутри wstring`а, который бы отрабатывал по времени примерно столько же, сколько отрабатывал тест на append? Слабо?
Re[35]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 11:27
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>>>Зачем? Подобный код в плюсах не имеет смысла.

_>>>Получится что-то вроде :
Нет не получится. Объяснить почему?
_>>>
_>>>    int a = 0;
_>>>    int c = 10;
_>>>    int b = 0;
_>>>    (*(&b)) = ( &a == NULL ? *(&a) : c) / 100;
_>>>

S>>Это не эквивалентный код.
_>Хорошо. Измените сами по вкусу .
_>Зачем мне такой код ? Какой нибудь толковый пример есть?

Этот пример такой же толковый, как и любой другой. Что Вам показать? Работу с nullable типами, хранимыми в СУБД крупной enterprise системы? Так тут боюсь С++ вообще загнется (точнее не С++, а программист, которуму так (не)повезет).
Re[61]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 11:28
Оценка:
K>алгоритмическая сложность та же

Нужно, впрочем, заметить, что это в худшем случае.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[61]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 11:28
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


K>>>Ну и чем может быть спровоцировано такое непонимание? Для добавления последовательности в начало нужно заменить 0 узлов. И создать 1 новый узел. Сложность O(1). При этом доступ по индексу будет с логарифмическим.

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

K>Это для вставки. А не для добавления к началу/концу т.е. конкатенации.

Может я чего то не понимаю — В чем разница? Так структура мутабельна мы должны выделить новыю ссылку на корень,и от него добраться либо в конец либо в начало,
выделяя новую ветку, с модификациу длины?
и солнце б утром не вставало, когда бы не было меня
Re[36]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 11:38
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


S>>Нет, не надо. Читать RTFM про то, как работает GC. Он не занимается уборкой.


PD>Уборкой или не уборкой, но исследованием кучи он занимаетеся или нет ? И время на это исследование от числа объектов там зависит или тоже нет ?


Если речь идет об имутабельных деревьях, то будут такие проблемы.
Если удаляемые подветки будут хранится в старших поколениях, то они буду фрагментировать данную кучу, и соответсвенно заставляя ее более часто дефрагментировать, при ее заполнении. Плюс проблемы с врайт барьером.
Но все зависит от объема занимаемой памяти этими объектами и соответственно частоты срабатывания GC
и солнце б утром не вставало, когда бы не было меня
Re[61]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 11:43
Оценка:
Здравствуйте, Klapaucius, Вы писали:

Кстати мутабельная реализация. http://rsdn.ru/article/cpp/segmented_list.xml
Автор(ы): Алексей Семенюк
Дата: 31.10.2004
В статье приводится пример реализации нестандартного контейнера, позволяющего обеспечить приемлемую скорость доступа к произвольному элементу и вставки/удаления в произвольную позицию.


По уму нужно еще сложность балансировки добавлять, т.к. деревья могут вырождаться в двухнапрвленный список.
и солнце б утром не вставало, когда бы не было меня
Re[40]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.06.09 11:52
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>Просто R/O секцию. Создается в C++ #pragma dataseg(имя). Ей можно поставить атрибуты без W. Некая функция (конструктор констант , получив ее базовый адрес, ставит разрешение по записи, записывает, снимает опять. А что и как там хранить — предмет отдельного разговора. Например, куча константных объектов, которые можно туда добавлять и оттуда удалять (эти методы могут снимать защиту), но функции их изменения получат exception просто по защите на уровне процессора, так как снимать защиту не умеют.


G>>Выделенное — дикий оверхед, оптимизацей в таком случае и не пахнет.


PD>Не особенно такой уж дикий. Все зависит от того, где и как это применять.

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

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

PD>Да, но оно позволяет иметь неизменяемость независимо от типа .
А теперь докажи преимущества такого подхода перед формальным доказательством неизменяемости.
Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.
Re[36]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 11:52
Оценка:
Здравствуйте, criosray, Вы писали:

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


_>>>>Зачем? Подобный код в плюсах не имеет смысла.

_>>>>Получится что-то вроде :
C>Нет не получится. Объяснить почему?
_>>>>
_>>>>    int a = 0;
_>>>>    int c = 10;
_>>>>    int b = 0;
_>>>>    (*(&b)) = ( &a == NULL ? *(&a) : c) / 100;
_>>>>

S>>>Это не эквивалентный код.
_>>Хорошо. Измените сами по вкусу .
_>>Зачем мне такой код ? Какой нибудь толковый пример есть?

C>Этот пример такой же толковый, как и любой другой. Что Вам показать? Работу с nullable типами, хранимыми в СУБД крупной enterprise системы? Так тут боюсь С++ вообще загнется (точнее не С++, а программист, которуму так (не)повезет).

Не, из этого примера ничего не понятно. Пусть это в СУБД полезно, еще что нибудь? Почему я собственно не могу указатели на ноль проверять?
Ведь согласно MSDN

A nullable type can represent the correct range of values for its underlying value type, plus an additional null value.

А указатели тоже имеют тип и содержат либо значение либо ноль. Если Вас не затруднит, то приведите для примера пару строк реального кода.
И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?
Re[51]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 11:52
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>> _itoa_s(i,buffer,10);

C>> temp = buffer;
C>> ws.append(StringToWString(temp));

C>>Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.

CC> Ай хорошо!
CC>Прекрасный пример!

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

Принято.

CC>itow спасет отца русской демократии.

798 ms — ноздря в ноздрю. Кроме того, что С# вариант на много проще и не требует явного вызова функции конвертации.

CC>
CC>wchar_t * _itow(
CC>   int value,
CC>   wchar_t *string,
CC>   int radix 
CC>);
CC>


CC>На С++ говоришь несколько лет прогил, да?

CC>Ну ну...

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

Так что с replace? Будет вменяемый пример?
Re[37]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 11:55
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?

Загнулись. Потому 99% enterprise это Java и .NET
Re[51]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 11:56
Оценка:
Здравствуйте, CreatorCray, Вы писали:


C>> _itoa_s(i,buffer,10);

C>> temp = buffer;
C>> ws.append(StringToWString(temp));

C>>Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.

CC> Ай хорошо!
CC>Прекрасный пример!

Кстати, С++ вариант по прежнему падает, если count >= 10000

Прекрасный пример — тут Вы правы.
Re[38]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 12:02
Оценка:
Здравствуйте, criosray, Вы писали:

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


_>>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?

C>Загнулись. Потому 99% enterprise это Java и .NET
Насчет Jаva соглашусь. А пример широко известной дотнет enterprise системы ( ну там CRM — ЕRP какой-нибудь)?
Re[52]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 08.06.09 12:03
Оценка:
Здравствуйте, criosray, Вы писали:

C>Кроме того, что С# вариант на много проще и не требует явного вызова функции конвертации.

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

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

Ну хоть как MSDNом пользоваться не забывай.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[42]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.06.09 12:06
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>Учти также что формальное доказательство дает огромный простор для оптимизации, в отличе от runtime проверок.

PD>Пойми наконец, что никакой проверки не будет вообще.
Ага, процессор магическим образом будет узнавать куда писать не надо.
Re[53]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 12:07
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>Кроме того, что С# вариант на много проще и не требует явного вызова функции конвертации.

CC>Да не особо там разницы. Просто в шарпе натыкано хелперов-конверторов.
CC>Есть у меня на одном проекте либа, на которой все основано. С ее использованием тоже получится чисто по коду "на много проще и не требует явного вызова функции конвертации".
CC>Так что это в принципе мелочи.

Когда таких мелочей — миллион — это становится сущей головной болью. Хорошо, что у Вас есть либа, а что делать тому, кто читает Ваш код? Лазать в либу и еще ее читать?

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

CC>Ну хоть как MSDNом пользоваться не забывай.
Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".
Re[39]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 08.06.09 12:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

PD>>Хм... Что такое ссылки наружу — я не знаю, а вот про блоки памяти вроде Рихтер говорит, что он их просматривает, ну и дальше — что именно делает.
S>Объект может содержать в себе ссылки, а может не содержать. В отличие от С++/native, про все объекты заранее известно, есть ли в них ссылки. В строках — нет. Поэтому "просматривать" их не нужно.

Так Рихтер все же прав или нет — насчет просмотра блоков ?

S>Это тебе ясно исключительно потому, что ты провёл сотни экспериментов с С++.


Нет . Я вообще довольно долго писал на Паскале (не Дельфи) под ДОС. И все, что я там знал, я перенес сюда. Свойства алгоритмов и работы с памятью не зависят от языка, если это native код.

>Теперь тебе сразу видно — где стоит поменять алгоритм, где заменить аллокатор, а где сразу нужно переходить на MMX и прочую низкоуровневую химию. Для новичка С++ — точно такая же непредсказуемая штука. Типа поставил где-то в неочевидном месте слово const — бах, сразу скорость подпрыгнула на 20%. Почему, отчего — хрен поймешь. Потому что не все могут выполнять в уме частичную специализацию и определять на глаз, где компилятор сможет выкинуть конструктор копирования временного экземпляра.


Поменять алгоритм — да, но это от языка не зависит.
Аллокатор — частично согласен.
Хрен поймешь — не согласен, есть Disassembly
Копировать без надобноси не надо , и такие конструкции лучше вообще употреблять с осторожностью. Но для этого надо видеть, во что твой код примерно превратится. Без просмотра ассемблерного кода. Просто в уме понимать

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

S>Это неправда.

Это твое ИМХО, не более.

PD>>Нашел bottleneck — определи суть — больше так не делай.

S>Это неправда.

Тжс.

PD>>Не потому, что профайлер показал его, а по определенной сути.

S>Это неправда.

Туда же.
PD>>В принципе я мог бы и без профалера эту суть найти, просто анализом, медленнее, конечно, будет.
S>Анализом? Это каким? Ну-ка, ну-ка, покажи мне способ при помощи "анализа" за конечное время выяснить, где порылась собака в быстродействии программы на основе того же boost::lambda?

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



PD>>А ты сам говоришь — попробуешь улучшить — чего доброго ухудшишь, пока пуд соли не съешь и эмпирические правила не освоишь. Вот так не делай, не потому что суть этого плохая, а потому что прошлый раз плохо получилось

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

Это тебе и кое-кому еще кажется, что это так. Профайлер лишь говорит о том, что есть, но ни слова не скажет о том, что могло бы быть. Вот тебе пример. Подсчет числа счастливых билетов. Тупо — 6-кратный цикл. Немного подумать — пятикратный. Еще подумать — тройной. А, оказывается, есть просто формула, без всяких циклов. Ну вот написал некий программист 6-цикл , видит, что все время уходит на... и что дальше ?
И я если бы использовал плохую структуру данных, был бы обречен на то, чтобы улучшать работу с ней ( и возможно улучшил бы на 10-20%), вместо того, чтобы выбрать адекватную и получить ускорение в разы.


>Тот же SQL Server — есть масса факторов, влияющих на производительность запросов.


SQL — это тоже "управляемый" язык, так что здесь верно то же, что и для .Net. Но к программированию на уровне "я точно знаю, какие команды процессора у меня выполняются (даже если писалось не на асме)" это не относится.
With best regards
Pavel Dvorkin
Re[52]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 12:27
Оценка:
Здравствуйте, criosray, Вы писали:

C>Так что там с Replace? Мы увидим тест для replace внутри wstring`а, который бы отрабатывал по времени примерно столько же, сколько отрабатывал тест на append? Слабо?

А что не так с алгоритмом replace ?
       DWORD t1 = ::GetTickCount();
    wchar_t* buf = new wchar_t [200000000]; 
    std::wstring str1 ;
    wchar_t s[] = L"c1";
    for(size_t i = 0; i < 200000000; )
    {        
        _tcscpy(&(buf[i]),s);
        i+= _tcslen(s);
    }
    str1 = buf;

    DWORD dif_tim = ::GetTickCount() - t1;

    std::cout << "append: elapsed: " << dif_tim <<" millisecond"<< std::endl;
    std::cout << str1.length() << std::endl;

    t1 = ::GetTickCount();
    std::replace(buf, buf + _tcslen(buf)  , L'1', L'2');

    dif_tim = ::GetTickCount() - t1;
    std::cout << "replace (wchar array) : elapsed  : " << dif_tim <<" millisecond"<< std::endl;

    t1 = ::GetTickCount();
    std::replace(str1.begin(), str1.end(), L'1', L'2');
    dif_tim = ::GetTickCount() - t1;
    std::cout << "replace (wstring) : elapsed  : " << dif_tim <<" millisecond"<< std::endl;


у меня результат такой :

append: elapsed: 1203 millisecond
200000000
replace (wchar array) : elapsed : 328 millisecond
replace (wstring) : elapsed : 500 millisecond
Press any key to continue .

Re[52]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 08.06.09 12:32
Оценка:
Здравствуйте, criosray, Вы писали:

C>Кстати, С++ вариант по прежнему падает, если count >= 10000

C>Прекрасный пример — тут Вы правы.
Ну, этож твой код падает
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[40]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 12:35
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


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


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


_>>>>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?

C>>>Загнулись. Потому 99% enterprise это Java и .NET
_>>Насчет Jаva соглашусь. А пример широко известной дотнет enterprise системы ( ну там CRM — ЕRP какой-нибудь)?

G>Sharepoint, Dynamics

+1, А каков процент на рынке? А то я что-то все больше разные SAP-ы, Siebel-ы вижу.
Re[39]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 12:38
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>>>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?

C>>Загнулись. Потому 99% enterprise это Java и .NET
_>Насчет Jаva соглашусь. А пример широко известной дотнет enterprise системы ( ну там CRM — ЕRP какой-нибудь)?

Microsoft Dynamics. Но энтерпрайз системы проектируются исключительно на заказ и их сотни тысяч, если не миллионы.
Re[53]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 12:39
Оценка:
Здравствуйте, CreatorCray, Вы писали:

C>>Кстати, С++ вариант по прежнему падает, если count >= 10000

C>>Прекрасный пример — тут Вы правы.
CC>Ну, этож твой код падает
Ну напишите такой, чтоб не падал. Или здесь все такие умные, что им это не по силам?
Re[53]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 12:42
Оценка:
Здравствуйте, alexey_ma, Вы писали:


C>>Так что там с Replace? Мы увидим тест для replace внутри wstring`а, который бы отрабатывал по времени примерно столько же, сколько отрабатывал тест на append? Слабо?

_>А что не так с алгоритмом replace ?

Это не правильно. Заменить надо ВСЕ вхождения подстроки в строку.

Что-то вроде boost::replace_all, но т.к. буста у меня нет и желания возиться с ним у меня тоже нет, то проверить не могу.
Re[37]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 08.06.09 12:46
Оценка:
Здравствуйте, Serginio1, Вы писали:

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

А зачем барьер записи на неизменяемой куче?
Эта хрень нужна когда ссылку на молодой объект помещают в старый объект.
Но в данном случае это невозможно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[54]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 08.06.09 12:46
Оценка:
Здравствуйте, criosray, Вы писали:

CC>>Так что это в принципе мелочи.

C>Когда таких мелочей — миллион — это становится сущей головной болью. Хорошо, что у Вас есть либа, а что делать тому, кто читает Ваш код? Лазать в либу и еще ее читать?
А как шарпники, читают сурсы фреймворка?
Или у них есть какой то другой способ понять что делает вызываемая функция, а?

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

CC>>Ну хоть как MSDNом пользоваться не забывай.
C>Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".
Мне тоже не приходится.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[40]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 12:53
Оценка:
Здравствуйте, criosray, Вы писали:

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


_>>>>И как же программисты С++ до сих пор не загнулись при работе с enterprise системами?

C>>>Загнулись. Потому 99% enterprise это Java и .NET
_>>Насчет Jаva соглашусь. А пример широко известной дотнет enterprise системы ( ну там CRM — ЕRP какой-нибудь)?

C>Microsoft Dynamics. Но энтерпрайз системы проектируются исключительно на заказ и их сотни тысяч, если не миллионы.

Да ну? Я цифры не знаю, но примерно год — два назад ситуация была примерно следующая :
CRM-ERP — лидер SAP — 60%, потом Siebel — прoцентов 10%.
Builling системы крупых telecom компаний — примерно 80% — Amdocs CSM
и т.п . Впрочем за точность цифр не ручаюсь
Какая же крупная компания сегодня энтерпрайз системы заказывать будет? Обычно используют уже готовые и обкатанные решения(с кастомизацией конечно).
Re[40]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.06.09 12:54
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Так Рихтер все же прав или нет — насчет просмотра блоков ?
Ты его неправильно понимаешь. Никакие "блоки" памяти GC, естественно, не просматривает. У него есть полная информация об устройстве этих "блоков памяти".

PD>Нет . Я вообще довольно долго писал на Паскале (не Дельфи) под ДОС. И все, что я там знал, я перенес сюда. Свойства алгоритмов и работы с памятью не зависят от языка, если это native код.

Да ладно. То-то в релизах микрософтовского компилятора внезапно появляются тормоза на ровном месте — потому что новая версия чуть по-другому трактует частичные специализации, чем предыдущая.

PD>Копировать без надобноси не надо , и такие конструкции лучше вообще употреблять с осторожностью.

Какие конструкции? Вызов методов? Ну так я тебе напомню, что код в основном из них и состоит.
PD>Но для этого надо видеть, во что твой код примерно превратится. Без просмотра ассемблерного кода. Просто в уме понимать
Вот для понимания того, во что превратится твой код, нужно сначала съесть пуд соли с дизассемблером.


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

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

PD>Это тебе и кое-кому еще кажется, что это так. Профайлер лишь говорит о том, что есть, но ни слова не скажет о том, что могло бы быть. Вот тебе пример. Подсчет числа счастливых билетов. Тупо — 6-кратный цикл. Немного подумать — пятикратный. Еще подумать — тройной. А, оказывается, есть просто формула, без всяких циклов. Ну вот написал некий программист 6-цикл , видит, что все время уходит на... и что дальше ?

Будет повод исправить программу. А то, может быть, там всё время уходит не на цикл, а на ожидание пользовательского ввода этого номера. В итоге замена "шестикратного цикла" улучшит ситуацию на 1%.

PD>SQL — это тоже "управляемый" язык, так что здесь верно то же, что и для .Net. Но к программированию на уровне "я точно знаю, какие команды процессора у меня выполняются (даже если писалось не на асме)" это не относится.

Это очень узкая точка зрения. Грубо говоря, для SQL сервера команды процессора не имеют никакого значения. Не потому, что он "управляемый", а потому, что основное время уходит на ожидание подъема данных в память. Для него low-level — это "я точно знаю, какие страницы у меня читаются". И эта ситуация ничем принципиально не отличается от C++ и ассемблера. Точно так же опыт нарабатывается исключительно с помощью инструментов. И точно также опыт пользования MS SQL можно перенести на MySQL — как и Паскалевский опыт на С++. Потому что устройство "матчасти" примерно одинаковое. Переносить опыт с Паскаля на SQL, к примеру, будет неэффективно. И с SQL на STL тоже.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[55]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 13:07
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


CC>>>Так что это в принципе мелочи.

C>>Когда таких мелочей — миллион — это становится сущей головной болью. Хорошо, что у Вас есть либа, а что делать тому, кто читает Ваш код? Лазать в либу и еще ее читать?
CC>А как шарпники, читают сурсы фреймворка?
CC>Или у них есть какой то другой способ понять что делает вызываемая функция, а?
Есть.
http://www.rsdn.ru/forum/flame.comp/3419282.1.aspx
Автор: criosray
Дата: 07.06.09


При чем такую же документацию для своего кода делать элементарно:


        /// <summary>
        /// Описание метода
        /// </summary>
        /// <param name="args">описание аргумента</param>
        static void Main(string[] args)


Ввожу /// и студия автоматически генерирует такую вот форму документирования и тут же ее подхватывает.

Ну и кроме того, я могу сполна доверять стандартным классам фреймворка, а вот левой библиотеке некоего Васи Пупкина (ничего личного, я так для примера) — без соответствующего code review доверять ну никак не смогу.

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

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

CC>>>Ну хоть как MSDNом пользоваться не забывай.
C>>Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".
CC>Мне тоже не приходится.
Про _itow_s Вы знали на генетическом уровне? Да?
Re[41]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 13:10
Оценка:
Здравствуйте, alexey_ma, Вы писали:

C>>Microsoft Dynamics. Но энтерпрайз системы проектируются исключительно на заказ и их сотни тысяч, если не миллионы.

_>Да ну? Я цифры не знаю, но примерно год — два назад ситуация была примерно следующая :
_>CRM-ERP — лидер SAP — 60%, потом Siebel — прoцентов 10%.
_>Builling системы крупых telecom компаний — примерно 80% — Amdocs CSM
Ну что я могу сказать. Вы просто не понимаете значение термина enterprise система.
Re[54]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 13:29
Оценка:
Здравствуйте, criosray, Вы писали:

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



C>>>Так что там с Replace? Мы увидим тест для replace внутри wstring`а, который бы отрабатывал по времени примерно столько же, сколько отрабатывал тест на append? Слабо?

_>>А что не так с алгоритмом replace ?

C>Это не правильно. Заменить надо ВСЕ вхождения подстроки в строку.


C>Что-то вроде boost::replace_all, но т.к. буста у меня нет и желания возиться с ним у меня тоже нет, то проверить не могу.

Нет, там все правильно.
replace он такой :

Examines each element in a range and replaces it if it matches a specified value.

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

    DWORD t1 = ::GetTickCount();
    wchar_t* buf = new wchar_t [200000000]; 
    std::wstring str1 ;
    wchar_t s[] = L"c1";
    for(size_t i = 0; i < 200000000; )
    {        
        _tcscpy(&(buf[i]),s);
        i+= _tcslen(s);
    }
    str1 = buf;

    DWORD dif_tim = ::GetTickCount() - t1;

    std::wcout << L"append: elapsed: " << dif_tim <<L" millisecond"<< std::endl;
    std::wcout << str1.length() << std::endl;
    
    t1 = ::GetTickCount();
    std::replace(buf, buf + _tcslen(buf)  , L'1', L'2');
    dif_tim = ::GetTickCount() - t1;
    std::wcout << L"replace (wchar array) : elapsed  : " << dif_tim <<L" millisecond"<< std::endl;


    std::wstring test1 = str1.substr(0,100);
    std::wcout << "before replace " << test1.c_str() << std::endl;

    t1 = ::GetTickCount();
    std::replace(str1.begin(), str1.end(), L'1', L'2');
    dif_tim = ::GetTickCount() - t1;
    std::wcout << L"replace (wstring) : elapsed  : " << dif_tim <<L" millisecond"<< std::endl;

    test1 = str1.substr(0,100);
    std::wcout << L"after replace " << test1.c_str() << std::endl;

    delete [] buf;


результат такой :

append: elapsed: 1219 millisecond
200000000
replace (wchar array) : elapsed : 594 millisecond
before replace c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c
1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1c1
replace (wstring) : elapsed : 485 millisecond
after replace c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2
c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2c2
Press any key to continue . . .


У вас в коде вроде тоже замена одиночного символа
Справедливости ради, следует заметит что для подстрок все гораздо хуже. STL string не лучшее решение для для частых добавлений и вставок.
Re[55]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 13:33
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>У вас в коде вроде тоже замена одиночного символа

Речь шла о замене именно подстроки. Я могу поменять замену символа на замену подстроки из десятков символов и принципиального падения производительности не будет.
_>Справедливости ради, следует заметит что для подстрок все гораздо хуже. STL string не лучшее решение для для частых добавлений и вставок.
Вооооооот. О чем и речь.
Re[42]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 13:47
Оценка:
Здравствуйте, criosray, Вы писали:

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


C>>>Microsoft Dynamics. Но энтерпрайз системы проектируются исключительно на заказ и их сотни тысяч, если не миллионы.

_>>Да ну? Я цифры не знаю, но примерно год — два назад ситуация была примерно следующая :
_>>CRM-ERP — лидер SAP — 60%, потом Siebel — прoцентов 10%.
_>>Builling системы крупых telecom компаний — примерно 80% — Amdocs CSM
C>Ну что я могу сказать. Вы просто не понимаете значение термина enterprise система.
Ну так просвятите
На самом деле я их видел
А чем SAP, Siebel или Amdocs CSM не enterprise система ?
В Израиле SAP используется в правительственных учереждения, больницах и т.п
Amdocs CSM используют следущие опреторы связи ( своими глазами видел)
Израиль : Plephone, Сеllcom, (Partner использует Siebel и Ventiv)
Россия : Beeline.
США : АТ&T, Sprint
Канада : Bell Canada
И т.д.
Почти все крупные компании используют готовые решения.
Re[43]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 13:50
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>Почти все крупные компании используют готовые решения.


Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?
Re[38]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 13:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>А зачем барьер записи на неизменяемой куче?
WH>Эта хрень нужна когда ссылку на молодой объект помещают в старый объект.
WH>Но в данном случае это невозможно.
Это когда ссылку меняешь старшем поколении неважно на молодой или старший.
Согласен, что врайт барьера не будет,так как создаются новые узлы, но будет фрагментация кучи старших поколений, если освободившиеся узлы в них лежат.
Кстати а как там с балансировкой дерева?
и солнце б утром не вставало, когда бы не было меня
Re[56]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 13:57
Оценка:
Здравствуйте, criosray, Вы писали:

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


_>>У вас в коде вроде тоже замена одиночного символа

C>Речь шла о замене именно подстроки. Я могу поменять замену символа на замену подстроки из десятков символов и принципиального падения производительности не будет.
Уверены ?
У меня ваш код при замене

stringBuilder.Replace('1', '2');

на

stringBuilder.Replace("c1", "12");

Выбрасывает System.OutOfMemoryException.
Re[39]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 08.06.09 14:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

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

Какая еще фрагментация в случае с уплотняющим мусорщиком?

S>Кстати а как там с балансировкой дерева?

2-3 дерево. Частный случай B дерева. Еще вопросы?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[44]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 14:03
Оценка:
Здравствуйте, criosray, Вы писали:

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


_>>Почти все крупные компании используют готовые решения.


C>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?

Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?
Re[55]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Ты посчитай сколько памяти займут эти строки?


CC>На 10к строк С# падает с out of memory

??? Не падает. Выполняется за 3.9 сек.

CC>В С++ у тебя вылетает bad_alloc на ~1.4 Гб занятой памяти.

1.4 гб это далеко не лимит — еще как минимум 600 мб должно быть доступно процессу.
Re[45]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:06
Оценка:
Здравствуйте, alexey_ma, Вы писали:


_>>>Почти все крупные компании используют готовые решения.


C>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?

_>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.
Re[46]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 14:13
Оценка:
Здравствуйте, criosray, Вы писали:

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



_>>>>Почти все крупные компании используют готовые решения.


C>>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?

_>>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

C>У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.

Три это вовсе не "их сотни тысяч, если не миллионы" не "исключительно на заказ".
Re[40]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 14:14
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


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

WH>Какая еще фрагментация в случае с уплотняющим мусорщиком?

На дефрагментацию кучи время уходит? И это может происходить достаточно часто. Все зависит от емкости, и скорости изменения дерева.
S>>Кстати а как там с балансировкой дерева?
WH>2-3 дерево. Частный случай B дерева. Еще вопросы?

Прибавляй затраты на балансировку.
Я к тому, что много дополнительных затрат, которые по уму нужно учитывать, при выборе типа инструмента.
Но ни вкоем случае не против веревок. Для каждой задачи свой алгоритм. Чем больше тем лучше.
Поэтому и убежден, что 3 на бора строк это лучше чем 1 универсальный, но с реализацией одинаковых интерфейсов.
Нет серебрянной пули.
Спасибо, вопросов пока нет.
и солнце б утром не вставало, когда бы не было меня
Re[40]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

И все-таки, есть где-то готовая реализация immutable rope? Очень хотелось бы посмотреть, а то мучают сомнения на счет эфективности.
Re[47]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:22
Оценка:
Здравствуйте, alexey_ma, Вы писали:

_>>>>>Почти все крупные компании используют готовые решения.


C>>>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?

_>>>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>>>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

C>>У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.

_>Три это вовсе не "их сотни тысяч, если не миллионы" не "исключительно на заказ".

Конечно на заказ — иначе и не выйдет, т.к. требования у всех разные и хотя подсистемы типа call-центров, crm, erp и т.д. могут быть адаптированны под условиях конкретно взятой компании, то в ЦЕЛОМ enterprise система для каждой компании своя уникальная.

Иными словами, Вы явно не понимаете о чем говорите.
Re[48]: Ну ты вообще многого не видишь... ;)
От: alexey_ma Израиль  
Дата: 08.06.09 14:27
Оценка:
Здравствуйте, criosray, Вы писали:

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


_>>>>>>Почти все крупные компании используют готовые решения.


C>>>>>Это совсем не так. Нет готовых решений для enterprise систем. Или Вы серьезно думаете, что СSM или ERP — это есть ПОЛНОЕ enterprise решение?

_>>>>Ну так смотря для кого. Хотя конечно обычно есть и CRM и ЕRP и еще чего нибудь. Но например SAP и Siebel(Oracle) предлагают и то и другое.
_>>>>У Вас есть пример написанной с нуля на заказ крупной enterprise системы? В какой компании?

C>>>У меня таких примеров на моей практике аж три (из тех, что разработаны нами с "нуля") за последние 7 лет. Название компаний Вам ни о чем не скажет.

_>>Три это вовсе не "их сотни тысяч, если не миллионы" не "исключительно на заказ".

C>Конечно на заказ — иначе и не выйдет, т.к. требования у всех разные и хотя подсистемы типа call-центров, crm, erp и т.д. могут быть адаптированны под условиях конкретно взятой компании, то в ЦЕЛОМ enterprise система для каждой компании своя уникальная.

Не, не верю. Самописных систем я видел очень мало, а вот кастомизированных коробочных много.
Re[49]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:29
Оценка:
Здравствуйте, alexey_ma, Вы писали:


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


Ну значит мы говорим о разных вещах. Если уж Вы мне не верите, то постарайтесь подумать логически и ответить себе на вопрос — чем заняты миллионы джавистов и дотнетчиков в корпоративном секторе (а именно этот сектор основной для этой категории программистов).
Re[56]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 08.06.09 14:34
Оценка:
Здравствуйте, criosray, Вы писали:

C>Ну и кроме того, я могу сполна доверять стандартным классам фреймворка, а вот левой библиотеке некоего Васи Пупкина (ничего личного, я так для примера) — без соответствующего code review доверять ну никак не смогу.

C>Да и вообще зачем изобретать велосипед? Сколько уже было потрачено человеко часов для такой банальщины, как преобразование базовых типов для вывода в строку?..
Ну .NET FW же изобрели.
Опять куда то не туда ушла дискуссия.

C>>>Вот-вот. Почему-то с С# на такой банальщине не приходится "пользоваться MSDN".

CC>>Мне тоже не приходится.
C>Про _itow_s Вы знали на генетическом уровне? Да?
Ага. Зная про itoa "гены" начали мне подсказывать что есть и itow.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[51]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 14:46
Оценка:
Здравствуйте, Mamut, Вы писали:

c>> _>Не, не верю. Самописных систем я видел очень мало, а вот кастомизированных коробочных много.


c>> Ну значит мы говорим о разных вещах. Если уж Вы мне не верите, то постарайтесь подумать логически и ответить себе на вопрос — чем заняты миллионы джавистов и дотнетчиков в корпоративном секторе (а именно этот сектор основной для этой категории программистов).


M>Создают видиость работы Как и большинство программистов, вне зависимости от языка программирования


Мы таких не держим.
Re[41]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 08.06.09 15:48
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>На дефрагментацию кучи время уходит? И это может происходить достаточно часто. Все зависит от емкости, и скорости изменения дерева.

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

WH>>2-3 дерево. Частный случай B дерева. Еще вопросы?

S> Прибавляй затраты на балансировку.
Какую балансировку?
B дерево строится сбалансированным сразу.
Ты вообще представляешь как работают B деревья?
Или мне тут нужно всем лекции по структурам данных прочитать?

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

Каких?

S>Поэтому и убежден, что 3 на бора строк это лучше чем 1 универсальный,

Хуже. Причем сильно хуже.

S>но с реализацией одинаковых интерфейсов.

Одинаковые интерфейсы у изменяемых и неизменяемых структур данных просто сюр.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[41]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 08.06.09 15:55
Оценка:
Здравствуйте, criosray, Вы писали:

C>И все-таки, есть где-то готовая реализация immutable rope? Очень хотелось бы посмотреть, а то мучают сомнения на счет эфективности.

Я уже третий раз эту ссылку привожу http://www.ibm.com/developerworks/java/library/j-ropes/index.html

For example, the ICFP 2007 Programming Contest involved implementing a virtual machine that modified its state with every cycle and ran for millions of cycles for some inputs (see Resources). In one Java implementation, the virtual machine's speed was improved by three orders of magnitude, from ~50 cycles/sec to more than 50,000/sec, by changing the state representation to use a Rope instead of a specialized StringBuffer.

Я конечно понимаю что пример весьма клинический но разгон алгоритма на 3 порядка....
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[42]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 16:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>И все-таки, есть где-то готовая реализация immutable rope? Очень хотелось бы посмотреть, а то мучают сомнения на счет эфективности.

WH>Я уже третий раз эту ссылку привожу http://www.ibm.com/developerworks/java/library/j-ropes/index.html
Ссылку эту я видел, но исходника я там не нашел. Плохо искал? И хотелось бы все-таки .NET реализацию увидеть...
Re[62]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 16:34
Оценка:
Здравствуйте, Serginio1, Вы писали:

K>>Это для вставки. А не для добавления к началу/концу т.е. конкатенации.

S>Может я чего то не понимаю — В чем разница? Так структура мутабельна мы должны выделить новыю ссылку на корень,и от него добраться либо в конец либо в начало,
S>выделяя новую ветку, с модификациу длины?

1) Для конкатенации не нужно добираться в конец или в начало.
2) Быстрый доступ к концу и началу можно организовать с помощью двух "пальцев" указывающих на самый левый и самый правый узлы (удерживать их всегда в первом уровне дерева). Но для конкатенации это не нужно, это нужно если мы хотим чтобы строки у нас были деком с константным доступом.

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


Это все учтено. Сложность вставки О(1) — амортизированная.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[44]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 16:42
Оценка:
2 criosray: Толку-то в СВ баллы ставить? Если вам этот код по какой-то причине понравится — можете поставить где-нибудь в профильном баллы пользователю Alexey Romanov. Это его проект.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[45]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 16:46
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>2 criosray: Толку-то в СВ баллы ставить? Если вам этот код по какой-то причине понравится — можете поставить где-нибудь в профильном баллы пользователю Alexey Romanov. Это его проект.


Баллы за ссылку, т.к. упорно гуглил, но так и не нашел.
Re[42]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 16:54
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


S>>На дефрагментацию кучи время уходит? И это может происходить достаточно часто. Все зависит от емкости, и скорости изменения дерева.

WH>Чё? Дефрагментация кучи происходит во время сборки мусора.
WH>Причем я тут можно очень серьезно срезать углы по сравнения с изменяемой кучей.
По сравнению с изменяемой кучей, одноразмерных объектов, может даже и сливать.
WH>>>2-3 дерево. Частный случай B дерева. Еще вопросы?
S>> Прибавляй затраты на балансировку.
WH>Какую балансировку?
WH>B дерево строится сбалансированным сразу.
WH>Ты вообще представляешь как работают B деревья?
Знаю. http://rsdn.ru/article/alg/tlsd.xml
Автор(ы): Сергей Смирнов (Serginio1)
Дата: 14.08.2004
Пример реализации двухуровневого массива с помощью нового средства С# — generics. Сравнение производительности различных реализаций сортированных списков.
. Я имел ввиду затраты на новые узлы.
Если ссылки на строки лежат в листьях тому, что объект занимает 12 бай + лево + право + сумма итого 28 байт на объект
Плюс листья по 3 ссылки на строки итого 12 байт. При частой сборке мусора они будут вносить свою лепту в фрагмнтацию кучи старших поколений.
Мало того, что ты получаешь дефрагментацию в 0 поколении, так еще получишь и в старших поколениях.

При слиянии строк данные как правило сидят в кэше, так то на копирование другие трудозатраты.
S>> Я к тому, что много дополнительных затрат, которые по уму нужно учитывать, при выборе типа инструмента.
WH>Каких?
На дефрагментацию старших поколений. Плюс при сканировании строки скачки по уровням, и тормоза к памяти вне кэша, по сравненю с прогоном по непрерывной памяти.
Мало того, в большинсве случаем строки выделяются сразу, не подвергаются изменениям в течении всей своей жизни.
Во всяком случае на 64 элементах Б+ деревьях это заметно.
S>>Поэтому и убежден, что 3 на бора строк это лучше чем 1 универсальный,
WH>Хуже. Причем сильно хуже.
Ну Б+ деревьев до сих пор в стандартной библиотеке нет, а SortedList сливает также как и стрингБуилдеру веревкам.
Посмотрим когда их в библиотеку. Затраты по сравнению с обычными строками я приводил.

S>>но с реализацией одинаковых интерфейсов.

WH>Одинаковые интерфейсы у изменяемых и неизменяемых структур данных просто сюр.
Ну не совсем. Я имел ввиду имутабельные строки один интерфейс для мутабельных другой, но если для первых это функции то для вторых это процедуры.
и солнце б утром не вставало, когда бы не было меня
Re[50]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 16:56
Оценка:
Здравствуйте, criosray, Вы писали:

C>C++ 858 ms

C>C# 823 ms

Это называется "равны с точностью до погрешности измерения".

C>Про сложность кода и явную костыльность С++ (обратите внимание как пришлось извратиться, чтоб сконвертировать число в wstring там, где StringBuilder делает конвертацию сам и не парит нам мозги) и говорить не стоит — вся красота перед глазами.


Мне из моего колодца трудно судить о недостаточной эстетике, я, так сказать, привык по-простому, "от сохи":
ws += L"Карл у Клары украл кораллы в количестве ";
ws += _itow(i,buffer,10);
ws += L" штук\n";


И не надо никаких append и преобразований из MBCS.

C>Но самое замечательное, что С++ вариант банально крашился, если Count = 10000 (и возможно меньше... не проверял между 5к и 10к).


У меня было всё ровно наоборот: C++ вариант попыхтел на пару с виндой, но таки 10K строк отработал, тогда как C# пыхтел столько же, а потом сказал OutOfMemoryException.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[63]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 17:01
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


K>>>Это для вставки. А не для добавления к началу/концу т.е. конкатенации.

S>>Может я чего то не понимаю — В чем разница? Так структура мутабельна мы должны выделить новыю ссылку на корень,и от него добраться либо в конец либо в начало,
S>>выделяя новую ветку, с модификациу длины?

K>1) Для конкатенации не нужно добираться в конец или в начало.

K>2) Быстрый доступ к концу и началу можно организовать с помощью двух "пальцев" указывающих на самый левый и самый правый узлы (удерживать их всегда в первом уровне дерева). Но для конкатенации это не нужно, это нужно если мы хотим чтобы строки у нас были деком с константным доступом.
эээ WolfHound утверждает что веревки это 2-3 дерево. Так что вставка не зависит от того в какое место вставляется, это не очередь.


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


K>Это все учтено. Сложность вставки О(1) — амортизированная.

Наверное я чего то не пониаю. Ну да ладно
и солнце б утром не вставало, когда бы не было меня
Re[64]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 08.06.09 17:11
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> эээ WolfHound утверждает что веревки это 2-3 дерево.


Ну, не обязательно 2-3.

K>>Сложность вставки О(1) — амортизированная.

S> Наверное я чего то не пониаю. Ну да ладно

Я оговорился, конечно. Конкатенация — константная (амортизированная). Вставка — логарифмическая. Как я выше по ветке и говорил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[52]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 17:18
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>C++ 858 ms

C>>>C# 823 ms

ГВ>>Это называется "равны с точностью до погрешности измерения".


C>Конечно. Но вот чисто append сливает в три раза, а чисто replace так вообще в десятки раз (по крайней мере наколенковая реализация на базе wstring.find/wstring.replace.


Тут на самом деле не надо путать StringBuilder, специально заточенный на модификации, и std::wstring, которая, по сути, своего рода компромисс между хранилищем строки (добавь требование преобразования к zero-terminated) и StringBuilder. Забавляет другое — что некоторый выигрыш Append/Replace нивелируется медленным ToString.

C>>>Но самое замечательное, что С++ вариант банально крашился, если Count = 10000 (и возможно меньше... не проверял между 5к и 10к).

ГВ>>У меня было всё ровно наоборот: C++ вариант попыхтел на пару с виндой, но таки 10K строк отработал, тогда как C# пыхтел столько же, а потом сказал OutOfMemoryException.
C>У меня дотнет вариант отработал за примерно 4 секунды, С++ тут же крашнулся без вменяемого сообщения о роде проблемы.

На 10000 строк 4 секунды? Интересно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[53]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 17:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

почувсвуйте разницу на коротких строках. Поэтому и пишут свои стрингбуилдеры
public override string ToString()
{
    string stringValue = this.m_StringValue;
    IntPtr currentThread = this.m_currentThread;
    if ((currentThread != IntPtr.Zero) && (currentThread != InternalGetCurrentThread()))
    {
        return string.InternalCopy(stringValue);
    }
    if ((2 * stringValue.Length) < stringValue.ArrayLength)
    {
        return string.InternalCopy(stringValue);
    }
    stringValue.ClearPostNullChar();
    this.m_currentThread = IntPtr.Zero;
    return stringValue;
}




public string ToString(int startIndex, int length)
{
    return this.m_StringValue.Substring(startIndex, length);
}
и солнце б утром не вставало, когда бы не было меня
Re[53]: Ну ты вообще многого не видишь... ;)
От: hattab  
Дата: 08.06.09 17:43
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Это называется "равны с точностью до погрешности измерения".


C>>Конечно. Но вот чисто append сливает в три раза, а чисто replace так вообще в десятки раз (по крайней мере наколенковая реализация на базе wstring.find/wstring.replace.


ГВ>Тут на самом деле не надо путать StringBuilder, специально заточенный на модификации, и std::wstring, которая, по сути, своего рода компромисс между хранилищем строки (добавь требование преобразования к zero-terminated) и StringBuilder. Забавляет другое — что некоторый выигрыш Append/Replace нивелируется медленным ToString.


Не флейма ради В Delphi самые православные (и даже zero-terminated совместимые) строки По первому тесту результаты такие (только я количество итераций уменьшил на один нолик, а то у меня памяти не хватает ):

C#:
append: elapsed 00:00:00.6044270
20000000
replace: elapsed 00:00:00.8633580
20000000
insert: elapsed 00:00:06.7491980
20000090

Delphi 2009 (миллисекунды):
----------- RTL строки
string.append: elapsed 697 (20000000)
string.replace: elapsed 0 (20000000) // нет замены в строке, только с созданием копии -- мерять не стал
string.insert: elapsed 5880 (20000090)
----------- с использование класса TStringBuilder
sb.append: elapsed 1063 (20000000)
sb.replace: elapsed 65 (20000000)
sb.insert: elapsed 5862 (20000090)

Код:
Var

 sw    : TStopwatch; // QueryPerformanceCounter
 s     : String; // это юникод
 sb    : TStringBuilder;
 Index : Integer;

Begin

 sw.Start;

 For Index := 1 To 10000000 Do
  s := s + 'c1';

 sw.Stop;

 WriteLn('string.append: elapsed ', sw.ElapsedTime, ' (', Length(s), ')');

 sw.Start;
// s := StringReplace(s, '1', '2', [rfReplaceAll]);
 sw.Stop;

 WriteLn('string.replace: elapsed ', sw.ElapsedTime, ' (', Length(s), ')');

 sw.Start;

 Index := 10000;
 While Index < 100000 Do
  Begin

   Insert('7', s, Index);
   Inc(Index, 1000);

  End;

 sw.Stop;

 WriteLn('string.insert: elapsed ', sw.ElapsedTime, ' (', Length(s), ')');

 WriteLn('-----------');

 sb := TStringBuilder.Create;
 Try

  sw.Start;

  For Index := 1 To 10000000 Do
   sb.Append('c1');

  sw.Stop;

  WriteLn('sb.append: elapsed ', sw.ElapsedTime, ' (', sb.Length, ')');

  sw.Start;
  sb.Replace('1', '2');
  sw.Stop;

  WriteLn('sb.replace: elapsed ', sw.ElapsedTime, ' (', sb.Length, ')');

  sw.Start;

  Index := 10000;
  While Index < 100000 Do
   Begin

    sb.Insert(Index, '7');
    Inc(Index, 1000);

   End;

  sw.Stop;

  WriteLn('sb.insert: elapsed ', sw.ElapsedTime, ' (', sb.Length, ')');

 Finally

  sb.Free;

 End;

End.
Re[54]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 17:45
Оценка:
Здравствуйте, Serginio1, Вы писали:


S>почувсвуйте разницу на коротких строках. Поэтому и пишут свои стрингбуилдеры


Кстати, спасибо, что напомнили. Публичные методы StringBuilder еще и thread safe в отличии от std::wstring.
Re[54]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 17:50
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:


S>почувсвуйте разницу на коротких строках. Поэтому и пишут свои стрингбуилдеры

S>
S>public override string ToString()
S>{
S>    string stringValue = this.m_StringValue;
S>    IntPtr currentThread = this.m_currentThread;
S>    if ((currentThread != IntPtr.Zero) && (currentThread != InternalGetCurrentThread()))
S>    {
S>        return string.InternalCopy(stringValue);
S>    }
S>    if ((2 * stringValue.Length) < stringValue.ArrayLength)
S>    {
S>        return string.InternalCopy(stringValue);
S>    }
S>    stringValue.ClearPostNullChar();
S>    this.m_currentThread = IntPtr.Zero;
S>    return stringValue;
S>}
S>


При коротких строках лишние сравнения,
на длиных строках если не выполняется второе условие то
вступает всилу обнуление строки

internal unsafe void ClearPostNullChar()
{
    int index = this.Length + 1;
    if (index < this.m_arrayLength)
    {
        fixed (char* chRef = &this.m_firstChar)
        {
            chRef[index] = '\0';
        }
    }
}





S>
S>public string ToString(int startIndex, int length)
S>{
S>    return this.m_StringValue.Substring(startIndex, length);
S>}
S>
и солнце б утром не вставало, когда бы не было меня
Re[54]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 17:55
Оценка:
Здравствуйте, hattab, Вы писали:


H>Delphi 2009 (миллисекунды):

H>----------- RTL строки
H>string.append: elapsed 697 (20000000)
H>string.replace: elapsed 0 (20000000) // нет замены в строке, только с созданием копии -- мерять не стал
H>string.insert: elapsed 5880 (20000090)
H>----------- с использование класса TStringBuilder
H>sb.append: elapsed 1063 (20000000)
H>sb.replace: elapsed 65 (20000000)

Попробуйте Replace('1','2') заменить на Replace('c1', 'abc4') Будет куда интереснее, чем замена одного символа.
Re[55]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 18:08
Оценка:
Здравствуйте, Serginio1, Вы писали:

Извини, я не совсем понял — к чему ты это? Сам код понятен, не могу понять твою мысль.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[54]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 18:19
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>>>Это называется "равны с точностью до погрешности измерения".

C>>>Конечно. Но вот чисто append сливает в три раза, а чисто replace так вообще в десятки раз (по крайней мере наколенковая реализация на базе wstring.find/wstring.replace.
ГВ>>Тут на самом деле не надо путать StringBuilder, специально заточенный на модификации, и std::wstring, которая, по сути, своего рода компромисс между хранилищем строки (добавь требование преобразования к zero-terminated) и StringBuilder.
C>О том и речь. Потому я и утверждал, что разделение на immutable класс строк и mutable класс аккумулятор строк позволяют достич значительно большей эфективности.

Нет, с иммутабельностью это не связано. Здесь главное то, что StringBuilder специально затачивался на модификацию строк, а std::wstring — это так, гора компромиссов между ужами и ежами.

ГВ>>Забавляет другое — что некоторый выигрыш Append/Replace нивелируется медленным ToString.

C>Обычно ToString вызывается гораздо реже Append`ов и крайне редко, чтоб он вызывался в цикле, как было предложено.

Цикл нужен только для того, чтобы время операции точней померить.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[55]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 18:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>>>Это называется "равны с точностью до погрешности измерения".

C>>>>Конечно. Но вот чисто append сливает в три раза, а чисто replace так вообще в десятки раз (по крайней мере наколенковая реализация на базе wstring.find/wstring.replace.
ГВ>>>Тут на самом деле не надо путать StringBuilder, специально заточенный на модификации, и std::wstring, которая, по сути, своего рода компромисс между хранилищем строки (добавь требование преобразования к zero-terminated) и StringBuilder.
C>>О том и речь. Потому я и утверждал, что разделение на immutable класс строк и mutable класс аккумулятор строк позволяют достич значительно большей эфективности.

ГВ>Нет, с иммутабельностью это не связано. Здесь главное то, что StringBuilder специально затачивался на модификацию строк, а std::wstring — это так, гора компромиссов между ужами и ежами.

Вот именно. Именно такое разделение позволило сделать класс string immutable, а StringBuilder — более эфективным (по производительности, менее эфективным по памяти, очевидно) для операций над строками.

ГВ>>>Забавляет другое — что некоторый выигрыш Append/Replace нивелируется медленным ToString.

C>>Обычно ToString вызывается гораздо реже Append`ов и крайне редко, чтоб он вызывался в цикле, как было предложено.
ГВ>Цикл нужен только для того, чтобы время операции точней померить.

Так что Вы меряете? Append или ToString? Ведь ToString`ов ровно столько же, сколько и Append`ов, что почти что нонсенс.
Re[55]: Ну ты вообще многого не видишь... ;)
От: hattab  
Дата: 08.06.09 18:33
Оценка:
Здравствуйте, criosray, Вы писали:

H>>Delphi 2009 (миллисекунды):

H>>----------- RTL строки
H>>string.append: elapsed 697 (20000000)
H>>string.replace: elapsed 0 (20000000) // нет замены в строке, только с созданием копии -- мерять не стал
H>>string.insert: elapsed 5880 (20000090)
H>>----------- с использование класса TStringBuilder
H>>sb.append: elapsed 1063 (20000000)
H>>sb.replace: elapsed 65 (20000000)

C>Попробуйте Replace('1','2') заменить на Replace('c1', 'abc4') Будет куда интереснее, чем замена одного символа.


Померял -- не дождался
Re[56]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 18:54
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>Извини, я не совсем понял — к чему ты это? Сам код понятен, не могу понять твою мысль.

В тормознутости StringBuilder a
и солнце б утром не вставало, когда бы не было меня
Re[42]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 19:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

Я все к чему клоню то. Что если сделать мутабельную структуру,
наподобие Б+ на листовом уровне, и ветки ссумой символов в пддереве как 2-3 дерево, то можно получить
очень быструю структуру. Так в моих Б+ дереве на листовом уровне 64 элемента кей валуе, что для int*int дает отличную скорость,
то для чаров это будет 256. Если вставки и удаления будут такого же порядка, то вполне быстря структура.
Надо будет попробовать на досуге.
и солнце б утром не вставало, когда бы не было меня
Re[65]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 08.06.09 19:12
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


S>> эээ WolfHound утверждает что веревки это 2-3 дерево.


K>Ну, не обязательно 2-3.

Если мы хотим иметь поиск по индексу, то нужно иметь дерево, а значит при вставке его модифицировать, при имутабельно структуре
копировать ветку, с модифицированным количество символов.
и солнце б утром не вставало, когда бы не было меня
Re[56]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 19:20
Оценка:
Здравствуйте, hattab, Вы писали:


C>>Попробуйте Replace('1','2') заменить на Replace('c1', 'abc4') Будет куда интереснее, чем замена одного символа.


H>Померял -- не дождался


Уменьшите количество итераций при формировании еще на порядок (больше, если потребуется). У меня Делфи нет, так что проверить у себя не могу, а узнать интересно.
Re[59]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 20:01
Оценка:
Здравствуйте, Erop, Вы писали:

C>>А куда ей еще уйти? Все еще раз и еще раз сводится к примитивизму С++, как платформы, где даже такая элементращина, как преобразование типов, требует штудирования MSDN, а для банального replace всех вхождений подстроки в строку надо подкючать стороннюю библиотеку типа boost.


E>Так С++ это не фреймворк для разработки приложений.. Фреймворк это QT, например...

Ну здраствуйте, капитан Очевидность...
E>А С++ это стредство разработки фреймворков...
Ух ты, не может быть.
E>Если тебе хочется именно мощь фреймворков сравнивать, то имеет смысл сравнивать какие-то фреймворки, а не "голый С++", при этом стоит учесть, что С++ на самом деле предлагает широкий выбор фреймворков. Иногда это хорошо, а иногда плохо...
STL это что? Я же не предлагаю сравнивать std::wstring с Rope из сторонней библиотеки. Да и вообще Вас не поймешь... то "зачем добавлять в язык то, что можно сделать в стандартной библиотеке", то "следует учесть, что С++ предлагает широкий выбор".
Ну учли. И что дальше? Ну давайте сравнивать не std::wstring, а СString, QString или что там еще есть в зоопарке строк С++...
Re[56]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 21:26
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Цикл нужен только для того, чтобы время операции точней померить.

C>Так что Вы меряете? Append или ToString? Ведь ToString`ов ровно столько же, сколько и Append`ов, что почти что нонсенс.

Я понял, согласен, мешанина получилась. Надо бы попробовать переструктурировать. Одна причина слива .Net понятна — ToString. Интересно, сколько она весит...
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[60]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 21:34
Оценка:
Здравствуйте, criosray, Вы писали:

E>>Если тебе хочется именно мощь фреймворков сравнивать, то имеет смысл сравнивать какие-то фреймворки, а не "голый С++", при этом стоит учесть, что С++ на самом деле предлагает широкий выбор фреймворков. Иногда это хорошо, а иногда плохо...

C>STL это что?

Библиотека, которой повезло быть включенной в стандарт C++. Библиотека. Хочешь — пользуйся, не хочешь — нет.

C>Я же не предлагаю сравнивать std::wstring с Rope из сторонней библиотеки.


А зря, это как раз было бы интересно.

C>Да и вообще Вас не поймешь... то "зачем добавлять в язык то, что можно сделать в стандартной библиотеке", то "следует учесть, что С++ предлагает широкий выбор".

C>Ну учли. И что дальше? Ну давайте сравнивать не std::wstring, а СString, QString или что там еще есть в зоопарке строк С++...

Такое сравнение сможет ответить только на один вопрос — насколько хороша или плоха та или иная реализация строк.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[57]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 21:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Цикл нужен только для того, чтобы время операции точней померить.

C>>Так что Вы меряете? Append или ToString? Ведь ToString`ов ровно столько же, сколько и Append`ов, что почти что нонсенс.

ГВ>Я понял, согласен, мешанина получилась. Надо бы попробовать переструктурировать. Одна причина слива .Net понятна — ToString. Интересно, сколько она весит...


Слива? Вы ничего не путаете?
Re[58]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 21:52
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Я понял, согласен, мешанина получилась. Надо бы попробовать переструктурировать. Одна причина слива .Net понятна — ToString. Интересно, сколько она весит...


C>Слива? Вы ничего не путаете?


По цифрам получился слив.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[59]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 21:59
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Я понял, согласен, мешанина получилась. Надо бы попробовать переструктурировать. Одна причина слива .Net понятна — ToString. Интересно, сколько она весит...


C>>Слива? Вы ничего не путаете?


ГВ>По цифрам получился слив.


Хм? append — идентично по скорости. replace — StringBuilder на много быстрее. Это при том, что дотнет не занимается оптимизацией на этапе компилляции в IL, а в runtime, как мы выяснили, у компиллятора IL нет времени для особых оптимизаций. Не говоря уж о том, что StringBuilder в отличии от std::wstring — гарантированно потоко безопасный.

А-а, стоп! Я понял... Вы имели в виду слив С++ Тогда +1
Re[62]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 22:02
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Библиотека, которой повезло быть включенной в стандарт C++. Библиотека. Хочешь — пользуйся, не хочешь — нет.

C>.NET Framework это тоже библиотека "которой повезло", а String это тоже просто класс.

Ты можешь выкинуть String из .Net? А я вот, std::wstring смогу запросто.

C>Только в дотнет к счастью не наплодили зоопарка лишних сущностей. С++ по-сути уникальный язык в плане того, что каждый норовит создать свою реализацию типа строк только потому, что стандартная — ущербна/неудобна... Или Вы знаете другие причины для появления СString, QString и иже с ними?


CString точно старше std::wstring. На счёт QString точно не знаю.

ГВ>>Такое сравнение сможет ответить только на один вопрос — насколько хороша или плоха та или иная реализация строк.

C>Само собою. С реализацией std::wstring разобрались. Какая будет следущей?

Можно продолжить играться с std::wstring. Например, подсунуть ей другой аллокатор.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[61]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 22:18
Оценка:
Здравствуйте, skeptik_, Вы писали:


C>>Хм? append — идентично по скорости. replace — StringBuilder на много быстрее. Это при том, что дотнет не занимается оптимизацией на этапе компилляции в IL, а в runtime, как мы выяснили, у компиллятора IL нет времени для особых оптимизаций. Не говоря уж о том, что StringBuilder в отличии от std::wstring — гарантированно потоко безопасный.


_>;####! в код заглядывал? Там unsafe code.

И? В .NET FW порядочно блоков с unsafe блоками кода. Для Вас это новость? Или Вы просто не знаете зачем это делается?

_>К тому StringBuilder — класс заточенный на данную задачу.

Так и есть.

_>В итоге мы имеем фактически специальный нейтивный код, против all purpose.

Хм? Не понял. Где Вы увидели нейтив код?

_>Ну и чему тут удивляться?

А я ничему не удивляюсь. Результат тестов для меня был ожидаемым.
Re[64]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 08.06.09 22:26
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Ты можешь выкинуть String из .Net? А я вот, std::wstring смогу запросто.

C>+1 — зоопарку строк С++ самое место там — на помойке. Выкидывайте.

Ну к чему такой пафос?! Взять строки/управление памятью/процессами/ещё что-нибудь и заменить другим, более подходящим к текущей задаче — самое обыкновенное дело. Никаких тотемных плясок по этому поводу обычно не устраивают.

C>>>Только в дотнет к счастью не наплодили зоопарка лишних сущностей. С++ по-сути уникальный язык в плане того, что каждый норовит создать свою реализацию типа строк только потому, что стандартная — ущербна/неудобна... Или Вы знаете другие причины для появления СString, QString и иже с ними?

ГВ>>CString точно старше std::wstring. На счёт QString точно не знаю.

C>Так узнайте.


Узнал. QT тоже старше стандарта C++, как минимум на три года. Вот тебе и причина появления QString.

C>Например, проскочила информация, что QString immutable...


Для immutable у неё слишком много методов append/insert/replace. Так что, пускай информация скачет дальше.

ГВ>>>>Такое сравнение сможет ответить только на один вопрос — насколько хороша или плоха та или иная реализация строк.

C>>>Само собою. С реализацией std::wstring разобрались. Какая будет следущей?
ГВ>>Можно продолжить играться с std::wstring. Например, подсунуть ей другой аллокатор.
C>Ну да. А еще можно переписать ее так, чтоб внутри было concatenation tree — сугубо, чтоб заточить под задачу аккумулирования строк.

Как вариант. Потом, можно взять другую реализацию STL (не от Microsoft), например, широко известную STLPort.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[65]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 08.06.09 22:30
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Ты можешь выкинуть String из .Net? А я вот, std::wstring смогу запросто.

C>>+1 — зоопарку строк С++ самое место там — на помойке. Выкидывайте.

ГВ>Ну к чему такой пафос?! Взять строки/управление памятью/процессами/ещё что-нибудь и заменить другим, более подходящим к текущей задаче — самое обыкновенное дело. Никаких тотемных плясок по этому поводу обычно не устраивают.


Да-да.

C>>Например, проскочила информация, что QString immutable...


ГВ>Для immutable у неё слишком много методов append/insert/replace. Так что, пускай информация скачет дальше.


А чем эти методы мешают immutable природе QString? Дотнетовский String тоже имеет эти методы. Не знали?

ГВ>>>>>Такое сравнение сможет ответить только на один вопрос — насколько хороша или плоха та или иная реализация строк.

C>>>>Само собою. С реализацией std::wstring разобрались. Какая будет следущей?
ГВ>>>Можно продолжить играться с std::wstring. Например, подсунуть ей другой аллокатор.
C>>Ну да. А еще можно переписать ее так, чтоб внутри было concatenation tree — сугубо, чтоб заточить под задачу аккумулирования строк.

ГВ>Как вариант. Потом, можно взять другую реализацию STL (не от Microsoft), например, широко известную STLPort.


Да уж, скучать не приходится.
Re[65]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 07:02
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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


S>> эээ WolfHound утверждает что веревки это 2-3 дерево.


K>Ну, не обязательно 2-3.


Для мутабельного типа строки вполне подойдут двухнапрвленные списки строк, или буферов определенного объема как б+ деревьях.
Вместо индекса использовать закладку содержащий узел и смещение.
Буфера нужны для разбития строк если она большая и подвергается модификации, а так же для аккумуляциималеньких строк.
Тогда дерева никакого ненадо, и пробег по строкам будет быстрым и модификация дешевой.
Для имутабельного обязательно нужно балансированное дерево, т.к. при модификации строки, мы должны скопировать ветку от корня до узла с модифицированной строкой. Балансированное что бы доступ к узлу от корня был Log(N), в том числе и для закладок, содержащий путь до строкию
и солнце б утром не вставало, когда бы не было меня
Re[19]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 09.06.09 07:04
Оценка:
Здравствуйте, criosray, Вы писали:

C>StringBuilder представляет строку в виде полноценного связного списка char`ов, позволяя тем самым модифицировать ее за линейное время (в отличии от std::string).


Гон. Там массив char'ов
Re[57]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 07:11
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Я понял, согласен, мешанина получилась. Надо бы попробовать переструктурировать. Одна причина слива .Net понятна — ToString. Интересно, сколько она весит...
В большинстве случаев, ToString будет выигрывть, т.к. не будет копирования строки.
Для чего он кстати и предназначен. Понятно, что можно подобрать условия когда и быструю сортировку можно загнать в угол.
Все же нужно подбирать рабочие тесты, а для индентичного использования как правильно заметили Substring.
и солнце б утром не вставало, когда бы не было меня
Re[60]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 09.06.09 07:36
Оценка:
Здравствуйте, criosray, Вы писали:

E>>Так С++ это не фреймворк для разработки приложений.. Фреймворк это QT, например...

C>Ну здраствуйте, капитан Очевидность...
E>>А С++ это стредство разработки фреймворков...
C>Ух ты, не может быть.
Ну так строишь свою критику плюсов, что возникает ощущение, что ты этих очевидных вещей не понимаешь

C>STL это что?

STL -- это часть средства для изготовления фрейсворков. Сам по себе STL фреймворком не является, так как без кучи великов на нём не поедешь...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[68]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 09.06.09 07:39
Оценка:
Здравствуйте, criosray, Вы писали:

C>Я не знаю immutable ли QString или нет — за что купил, за то и продаю. Если можете доказать обратное — милости просим, но пока Ваши доводы ничего не доказали, равно как ничего и не опровергли.


Ну ты это на сайт зайди и доки погляди и всё узнаешь... Если готов поверить на слово, то мутабельная...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 09.06.09 07:44
Оценка:
Здравствуйте, _d_m_, Вы писали:

C>>StringBuilder представляет строку в виде полноценного связного списка char`ов, позволяя тем самым модифицировать ее за линейное время (в отличии от std::string).


___>Гон. Там массив char'ов


Даже хуже. Там (если речь о .NET) внутри просто string (который на самом деле не совсем неизменяемый) А вот уже сам string — просто последовательность char-ов.
Re[21]: Ну ты вообще многого не видишь... ;)
От: Mamut Швеция http://dmitriid.com
Дата: 09.06.09 08:48
Оценка:
WF> ___>Гон. Там массив char'ов

WF> Даже хуже. Там (если речь о .NET) внутри просто string (который на самом деле не совсем неизменяемый) А вот уже сам string — просто последовательность char-ов.


Там массив char'ов, как их понимают в С/C++, или все же массив символов?
avalon 1.0rc1 rev 239, zlib 1.2.3


dmitriid.comGitHubLinkedIn
Re[62]: Ну ты вообще многого не видишь... ;)
От: neFormal Россия  
Дата: 09.06.09 08:52
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>STL это что?

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

ну, прочитай что ли значение слов "фреймворк" и "библиотека".. вики в помощь:
Фреймворк
Библиотека
и не пишите больше таких глупостей.. а то сишники полопаются от смеха..
...coding for chaos...
Re[22]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 09.06.09 09:01
Оценка:
Здравствуйте, Mamut, Вы писали:

WF>> Даже хуже. Там (если речь о .NET) внутри просто string (который на самом деле не совсем неизменяемый) А вот уже сам string — просто последовательность char-ов.


M>Там массив char'ов, как их понимают в С/C++, или все же массив символов?


Последовательность (не совсем массив) char'ов, как их понимают в .NET То есть символов (в некотором приближении).
Re[22]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 09:03
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Там массив char'ов, как их понимают в С/C++, или все же массив символов?



[Serializable, ComVisible(true)]
public sealed class StringBuilder : ISerializable
{
    // Fields
      internal volatile string m_StringValue;

Причем у строки куча унсейвных методов.
и солнце б утром не вставало, когда бы не было меня
Re[68]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 09:31
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Дотнетовский, например, String.insert возвращает string. А QT-шный QString::insert возвращает QString&. Разница понятна?

C>Разница понятна — и то и другое есть ссылка.

C>Я не знаю immutable ли QString или нет — за что купил, за то и продаю. Если можете доказать обратное — милости просим, но пока Ваши доводы ничего не доказали, равно как ничего и не опровергли.


Сразу видно, что давно ты на C++ писал. Метод класса широко распространённой C++-библиотеки, возвращающий ссылку на экземпляр этого же класса очень-очень вряд ли вернёт ссылку на что-то отличное от себя самого.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[69]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 09:34
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>Дотнетовский, например, String.insert возвращает string. А QT-шный QString::insert возвращает QString&. Разница понятна?

C>>Разница понятна — и то и другое есть ссылка.

C>>Я не знаю immutable ли QString или нет — за что купил, за то и продаю. Если можете доказать обратное — милости просим, но пока Ваши доводы ничего не доказали, равно как ничего и не опровергли.


ГВ>Сразу видно, что давно ты на C++ писал. Метод класса широко распространённой C++-библиотеки, возвращающий ссылку на экземпляр этого же класса очень-очень вряд ли вернёт ссылку на что-то отличное от себя самого.

И?
Re[58]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 09:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Я понял, согласен, мешанина получилась. Надо бы попробовать переструктурировать. Одна причина слива .Net понятна — ToString. Интересно, сколько она весит...
S> В большинстве случаев, ToString будет выигрывть, т.к. не будет копирования строки.

Как это, не будет копирования строки?

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

S>Все же нужно подбирать рабочие тесты, а для индентичного использования как правильно заметили Substring.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[59]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 09.06.09 09:43
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

S>> В большинстве случаев, ToString будет выигрывть, т.к. не будет копирования строки.


ГВ>Как это, не будет копирования строки?


В типичных случаях он отдаёт наружу ровно ту строку, которую внутри себя редактирует. Естественно, с необходимой осторожностью, для гарантии неизменяемости этой отданной строки.
Re[70]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 09:46
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Сразу видно, что давно ты на C++ писал. Метод класса широко распространённой C++-библиотеки, возвращающий ссылку на экземпляр этого же класса очень-очень вряд ли вернёт ссылку на что-то отличное от себя самого.

C>И?

Значит QString никакой не immutable.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[60]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 09:50
Оценка:
Здравствуйте, WFrag, Вы писали:

ГВ>>Как это, не будет копирования строки?


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


То есть он отдаёт строку, держит на неё ссылку и при последующем, например, Append — дублирует её обратно во внутренний буфер?

String s = strBuilder.ToString(); // Отдал строку
strBuilder.Append("ABC"); // Вернул себе копию того, что было отдано через ToString и продолжил модификацию


Так?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[64]: Ну ты вообще многого не видишь... ;)
От: neFormal Россия  
Дата: 09.06.09 09:53
Оценка:
Здравствуйте, criosray, Вы писали:

F>>Фреймворк

F>>Библиотека
C>И? STL подходит 100% под определение фреймворка из приведенных Вами ссылок.

rofl

C>>>Не стоит выставлять на показ свои проблемы с логикой.

...coding for chaos...
Re[61]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 09.06.09 09:54
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


ГВ>То есть он отдаёт строку, держит на неё ссылку и при последующем, например, Append — дублирует её обратно во внутренний буфер?


Типа того. С учётом того, что внутренний буфер — это и есть эта строка (string на самом деле изменяема, внутри mscorlib).

ГВ>
ГВ>String s = strBuilder.ToString(); // Отдал строку
ГВ>strBuilder.Append("ABC"); // Вернул себе копию того, что было отдано через ToString и продолжил модификацию
ГВ>


ГВ>Так?


Что-то вроде того.
Re[62]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 09:58
Оценка:
Здравствуйте, WFrag, Вы писали:

ГВ>>То есть он отдаёт строку, держит на неё ссылку и при последующем, например, Append — дублирует её обратно во внутренний буфер?

WF>Типа того. С учётом того, что внутренний буфер — это и есть эта строка (string на самом деле изменяема, внутри mscorlib).

ГВ>>
ГВ>>String s = strBuilder.ToString(); // Отдал строку
ГВ>>strBuilder.Append("ABC"); // Вернул себе копию того, что было отдано через ToString и продолжил модификацию
ГВ>>


ГВ>>Так?


WF>Что-то вроде того.


Тогда берём такой пример:

const int Count = 1000000;
String str = "Text";

StringBuilder sb = new StringBuilder();
for(int i = 0; i < 10; ++i)
sb.Append("0123456789");
String s;

Stopwatch stopwatch = new Stopwatch();
stopwatch.Start();
for (int i = 0; i < Count; i++)
{
    s = sb.ToString();
}
stopwatch.Stop();
Console.WriteLine("Elapsed 1 {0}", stopwatch.Elapsed);

stopwatch.Reset();
stopwatch.Start();
for (int i = 0; i < Count; i++)
{
    s = sb.ToString();
    s = sb.ToString();
    s = sb.ToString();
    s = sb.ToString();
    s = sb.ToString();
}
stopwatch.Stop();
Console.WriteLine("Elapsed 5 {0}", stopwatch.Elapsed);


Если твоё предположение верно, то соотношение времен Elapsed1:Elapsed5 должно быть близко к 1:1. Прокрути тест, посмотри на результаты.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[65]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 10:00
Оценка:
Здравствуйте, neFormal, Вы писали:

F>>>Фреймворк

F>>>Библиотека
C>>И? STL подходит 100% под определение фреймворка из приведенных Вами ссылок.

F>rofl

F>

C>>>>Не стоит выставлять на показ свои проблемы с логикой.


У Вас соска выпала.
Re[66]: Ну ты вообще многого не видишь... ;)
От: neFormal Россия  
Дата: 09.06.09 10:10
Оценка:
Здравствуйте, criosray, Вы писали:

C>У Вас соска выпала.


крадёшь шутки у Петросяна?.
...coding for chaos...
Re[60]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 10:13
Оценка:
Здравствуйте, Serginio1, Вы писали:

ГВ>>Как это, не будет копирования строки?

S>А говоришь код понятный.

И ты тоже прокрути тест из этого сообщения
Автор: Геннадий Васильев
Дата: 09.06.09
.

[skip code]

Это-то я всё понял, но за комментарии отдельное спасибо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[60]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 09.06.09 10:14
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>
S>    stringValue.ClearPostNullChar();// добиваем пространство за Length + 1 нулями
S>


Вот этот момент, кстати, непонятный. Судя по коду оно добивает 1 null, причём за null-терминатором строки (который, видимо, играет роль при взаимодействии с нейтивом), то есть это уже как бы второй unll. Но зачем?
Re[62]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 10:20
Оценка:
Здравствуйте, WFrag, Вы писали:

ГВ>>
ГВ>>String s = strBuilder.ToString(); // Отдал строку
ГВ>>strBuilder.Append("ABC"); // Вернул себе копию того, что было отдано через ToString и продолжил модификацию
ГВ>>


ГВ>>Так?


WF>Что-то вроде того.


Вовсе не типа того.

http://www.koders.com/csharp/fidB60F568A8CB6C4FE6DC7BC17ED5C0A52CA37E2F4.aspx?s=mdef%3Ainsert
Re[61]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 10:22
Оценка:
Здравствуйте, WFrag, Вы писали:


S>>
S>>    stringValue.ClearPostNullChar();// добиваем пространство за Length + 1 нулями
S>>


WF>Вот этот момент, кстати, непонятный. Судя по коду оно добивает 1 null, причём за null-терминатором строки (который, видимо, играет роль при взаимодействии с нейтивом), то есть это уже как бы второй unll. Но зачем?

И еще по теме:
http://blogs.gotdotnet.ru/personal/gaidar/PermaLink.aspx?guid=c2f3af10-950e-4d6e-9d14-d9a9cb0e71dc
Re[61]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 10:28
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Это-то я всё понял, но за комментарии отдельное спасибо.

А зачем же я коментарии то пишу?
Там есть такая запись после отдачи строки.

this.m_currentThread = IntPtr.Zero;



public override string ToString()
{
    string stringValue = this.m_StringValue;
    if (this.m_currentThread != Thread.InternalGetCurrentThread()) // Вот здесь если IntPtr.Zero идет копирование строки
    {                                                              
        return string.InternalCopy(stringValue);
    }
    if ((2 * stringValue.Length) < stringValue.ArrayLength)
    {
        return string.InternalCopy(stringValue);
    }
    stringValue.ClearPostNullChar();
    this.m_currentThread = IntPtr.Zero;
    return stringValue;
}
и солнце б утром не вставало, когда бы не было меня
Re[61]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 10:30
Оценка:
Здравствуйте, WFrag, Вы писали:

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


S>>
S>>    stringValue.ClearPostNullChar();// добиваем пространство за Length + 1 нулями
S>>


WF>Вот этот момент, кстати, непонятный. Судя по коду оно добивает 1 null, причём за null-терминатором строки (который, видимо, играет роль при взаимодействии с нейтивом), то есть это уже как бы второй unll. Но зачем?

Это ты у них спроси. Она и так нуль терминированная. Какие то у них свои тараканы.
и солнце б утром не вставало, когда бы не было меня
Re[63]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 09.06.09 10:31
Оценка:
Здравствуйте, criosray, Вы писали:

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


ГВ>>>
ГВ>>>String s = strBuilder.ToString(); // Отдал строку
ГВ>>>strBuilder.Append("ABC"); // Вернул себе копию того, что было отдано через ToString и продолжил модификацию
ГВ>>>


ГВ>>>Так?


WF>>Что-то вроде того.


C>Вовсе не типа того.


С чем не согласен? Я смотрю по коду 2-ого фреймворка. Там, конечно, всё гораздо сложнее, но принцип вроде такой.

C>http://www.koders.com/csharp/fidB60F568A8CB6C4FE6DC7BC17ED5C0A52CA37E2F4.aspx?s=mdef%3Ainsert


Вообще это код из Mono. Кстати, они кешируют отданную строку в ToString, а настоящий фреймворк — нет.
Re[67]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 10:37
Оценка:
Здравствуйте, neFormal, Вы писали:

C>>У Вас соска выпала.


F>крадёшь шутки у Петросяна?.


А где Вы шутку увидели?
Re[64]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 11:03
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>С чем не согласен? Я смотрю по коду 2-ого фреймворка. Там, конечно, всё гораздо сложнее, но принцип вроде такой.

C>>http://www.koders.com/csharp/fidB60F568A8CB6C4FE6DC7BC17ED5C0A52CA37E2F4.aspx?s=mdef%3Ainsert
WF>Вообще это код из Mono. Кстати, они кешируют отданную строку в ToString, а настоящий фреймворк — нет.

Принято. Согласен.
Re[64]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 11:21
Оценка:
Здравствуйте, WFrag, Вы писали:

WF>Я не делаю предположений, я смотрю рефлектором. Но там не всё так прозрачно. Судя по коду, есть подозрение, что только первый .ToString не вызовет копирования.


А я всё больше таймеры обсчитываю. Вот тебе ещё один тест:

// Viva паранойя: разогрев StringBuilder:
for (int k = 0; k < 5; ++k)
{
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < 2; ++i)
        sb.Append("0123456789");
    String s = sb.ToString();
}

// Тест
const int Count = 10000000;
const int ConcatCount = 1;
const String StrConcat = "0123456789";
Stopwatch stopwatch = new Stopwatch();


stopwatch.Start();
for (int k = 0; k < Count; ++k)
{
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < ConcatCount; ++i)
        sb.Append(StrConcat);
    String s = "A";
}
stopwatch.Stop();
TimeSpan tsCreate = stopwatch.Elapsed;
Console.WriteLine("Elapsed creation {0}", stopwatch.Elapsed);

stopwatch.Reset();
stopwatch.Start();
for (int k = 0; k < Count; ++k)
{
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < ConcatCount; ++i)
        sb.Append(StrConcat);
    String s = sb.ToString();
}
stopwatch.Stop();
TimeSpan tsCreateAssign = stopwatch.Elapsed;
Console.WriteLine("Elapsed create+assign {0}", stopwatch.Elapsed);

stopwatch.Reset();
stopwatch.Start();
for (int k = 0; k < Count; ++k)
{
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < ConcatCount; ++i)
        sb.Append(StrConcat);
    String s = sb.ToString();
    s = sb.ToString();
}
stopwatch.Stop();
TimeSpan tsCreateAssign2 = stopwatch.Elapsed;
Console.WriteLine("Elapsed create+assign2 {0}", stopwatch.Elapsed);

Console.WriteLine("EC:ECA ~=~ 1:{0}", tsCreateAssign.TotalMilliseconds / tsCreate.TotalMilliseconds);
Console.WriteLine("ECA:ECA2 ~=~ 1:{0}", tsCreateAssign2.TotalMilliseconds / tsCreate.TotalMilliseconds);

double dCAC = tsCreateAssign.TotalMilliseconds - tsCreate.TotalMilliseconds;
double dCA2CA = tsCreateAssign2.TotalMilliseconds - tsCreateAssign.TotalMilliseconds;

Console.WriteLine("ECA-EC = {0} ms (D1)", dCAC / Count);
Console.WriteLine("ECA2-ECA = {0} ms (D2)", dCA2CA / Count);
Console.WriteLine("D2:D1 = {0}:1", dCA2CA / dCAC);


Здесь сравнивается три длительности: создание строки (1), создание + одно присвоение ToString() (2), создание + два присвоения ToString() (3). Потом сравниваются две разницы: (2)-(1) = D1 и (3)-(2) = D2. Если StringBuilder оптимизирован под отдачу первой строки, то D2:D1 должно быть значительно больше, чем 2:1. В принципе, похоже, что так и есть — D2:D1 для десятисимвольной строки при ConcatCount=1 колеблется где-то в районе 3.5:1, то есть второй вызов sb.ToString() значительно медленнее первого. Но возможно, я чего-то не учитываю, например — активности GC.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[65]: Ошибка в примере:
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 11:25
Оценка:
Console.WriteLine("EC:ECA ~=~ 1:{0}", tsCreateAssign.TotalMilliseconds / tsCreate.TotalMilliseconds);
Console.WriteLine("ECA:ECA2 ~=~ 1:{0}", tsCreateAssign2.TotalMilliseconds / tsCreateAssign.TotalMilliseconds);


На итоговые выводы это не повлияло, но всё равно ошибка.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[63]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 11:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:
Еще по умолчанию Capacity он же ArrayLength = 16,
Если строка меньше 8 то будет постоянно копироваться.
и солнце б утром не вставало, когда бы не было меня
Re[63]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 12:02
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Судя по всему, это просто маркер текущего потока, который модифицирует строку. Кстати, я не сообразил, что ты привёл код FW-шного стрингбилдера.


Особенностью FW наверное является присутствие методов с Internal

Thread.InternalGetCurrentThread()
string.InternalCopy
и солнце б утром не вставало, когда бы не было меня
Re[64]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 12:05
Оценка:
Здравствуйте, Serginio1, Вы писали:

ГВ>>Судя по всему, это просто маркер текущего потока, который модифицирует строку. Кстати, я не сообразил, что ты привёл код FW-шного стрингбилдера.

S>Особенностью FW наверное является присутствие методов с Internal

S>
S>Thread.InternalGetCurrentThread()
S>string.InternalCopy
S>


Как я понимаю, как раз в InternalCopy зарыта синхронизация.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[65]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 12:07
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


S>>Еще по умолчанию Capacity он же ArrayLength = 16,

S>>Если строка меньше 8 то будет постоянно копироваться.

ГВ>Угу. Ну, тогда результаты тестов становятся объяснимыми. По сути StringBuilder заточен под определённый паттерн использования: создать строку, при необходимости зарезервировав не более, чем 2xLength символов, и отдать строку единственным ToString. Дальше StringBuilder уходит в GC.


Именно так. Потому я и говорил, что вызов ToString после каждого Append`а почти что нонсенс.
Re[66]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 12:10
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Угу. Ну, тогда результаты тестов становятся объяснимыми. По сути StringBuilder заточен под определённый паттерн использования: создать строку, при необходимости зарезервировав не более, чем 2xLength символов, и отдать строку единственным ToString. Дальше StringBuilder уходит в GC.

C>Именно так. Потому я и говорил, что вызов ToString после каждого Append`а почти что нонсенс.

Так это не нонсенс, а использование, противоречащее предполагаемому паттерну. ИМХО, лучше было бы сделать что-то вроде DetachString, который бы гарантированно отдавал накопленную строку. По крайней мере, путаницы бы возникало меньше.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[67]: Дополнение
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 12:13
Оценка:
ГВ>ИМХО, лучше было бы сделать что-то вроде DetachString, который бы гарантированно отдавал накопленную строку. По крайней мере, путаницы бы возникало меньше.

Или, например, можно было бы явно определять политику использования буфера параметрами конструктора StringBuilder-а. А так, знаешь, пытаться вжиться в образ индуса, не ведающего программирования, не у всех быстро удаётся.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[66]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 12:20
Оценка:
Здравствуйте, Serginio1, Вы писали:

ГВ>>Как я понимаю, как раз в InternalCopy зарыта синхронизация.

S> В основном это унсейвные или extern закрытые методы.
S> Кстати поставь себе reflector http://www.red-gate.com/products/reflector/
S>Очень поучительная штука.

Спасибо, кстати. Я сам на C# практически ничего не пишу, а так сцепишься с кем — и апеллировать не к чему.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[69]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 09.06.09 13:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>Спасибо, кстати. Я сам на C# практически ничего не пишу, а так сцепишься с кем — и апеллировать не к чему.

S>>C# не основной язык. Просто очень удобно посмотреть внутренности, иногда подсмотреть алгоритмы.
S>> Читается код очень легко. (есть конечно и навороты бошку сломаешь).
S>> Кстати заметь в этой ветке рефлектор многократно упоминается. А врага надо знать в лицо, а там и в друга превратится

ГВ>Да какой из .Net враг-то? Потешный, разве что.


Ну уж С++ дотнету точно не враг. Вот джава — да.
Re[70]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 13:24
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Да какой из .Net враг-то? Потешный, разве что.

C>Ну уж С++ дотнету точно не враг. Вот джава — да.

Да ясное дело — куда ж дотнет без C++?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[70]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 13:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>В свое время обплевавшись на стандартный стрингбуилдер народ начал делать свои.

S>Посмотри http://www.rsdn.ru/forum/dotnet/3303143.flat.aspx#3303143
Автор: Serginio1
Дата: 24.02.09

S>там есть RStringBuilder тоже сделанный для тестов, но чиста манагедный.

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

[блестит меч джедая — on]
Правда, как это соотносится с восхвалениями Единственного Стандартного Самого Правильного Решения, Представляемого В .NET — тайна сия велика есть. Знаешь, есть очень большое рациональное зерно в высказываниях о том, что в мозгах "простого человека" легко уживаются именно противоречивые мифы — старик Геббельс был прав, говоря о том, что пропаганда должна строиться на совершенно невероятной лжи.
[блестит меч джедая — off]
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[71]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 13:48
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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

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

Кстати многие проблемы как раз торчат из философии и привязаннонсти к С++ местных писателей.
Так, что сказывается тяжелая наследственность
А то, что все универсальное не есть серебрянная пуля, да и велосипед создавать то никто не запрещал.
Иногда собственные велосипеды могуть быть намного лучше заводских.
В конце то концов каждый выбирает инструмент для себя.
и солнце б утром не вставало, когда бы не было меня
Re[72]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 13:59
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Здравствуйте, Геннадий Васильев, Вы писали:


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

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

Ровно то же самое справедливо и в отношении C++.

S>Кстати многие проблемы как раз торчат из философии и привязаннонсти к С++ местных писателей.

S>Так, что сказывается тяжелая наследственность

Не надо дудеть в дудку мозговедения. Почему-то даже "не привязанные к C++" отмечают притормаживания .Net. Взять высказывания того же vdimas из соседнего топика.

S> А то, что все универсальное не есть серебрянная пуля, да и велосипед создавать то никто не запрещал.


Ну... Зоопарк, затычки, недоязык — классика жанра высказываний "дотнетчиков" в адрес C++.

S>Иногда собственные велосипеды могуть быть намного лучше заводских.

S> В конце то концов каждый выбирает инструмент для себя.

Это понятно.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[71]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:01
Оценка:
Здравствуйте, criosray, Вы писали:

C>Average copy speed 681193341743,801 MB/s


В общем, слив засчитан. Хотя съехать на "хи-хи" тоже неплохо.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[71]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:05
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Соотношение считайте сами.


ГВ>650 GB/sec? Слушай, а бесконечный цикл за сколько секунд прокрутит?


ГВ>P.S.: Ты хоть понял, что я мерил?


Я же говорю: то, что Вы меряете — маразм. Сравнивать StringBuffer.ToString и обычное копирование С++.
Re[73]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:12
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>В общем, слив засчитан. Хотя съехать на "хи-хи" тоже неплохо.

C>То есть ответить Вам нечего? Отлично.

Да куда уж мне отвечать, когда тут показывают 650 GBps на ~25-гигабайтной шине.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[70]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 14:17
Оценка:
Здравствуйте, criosray, Вы писали:

Не будет копирования
private unsafe string InternalSubString(int startIndex, int length, bool fAlwaysCopy)
{
    if (((startIndex == 0) && (length == this.Length)) && !fAlwaysCopy) //!!!!!!!!
    {
        return this;//
    }    string str = FastAllocateString(length);
    fixed (char* chRef = &str.m_firstChar)
    {
        fixed (char* chRef2 = &this.m_firstChar)
        {
            wstrcpy(chRef, chRef2 + startIndex, length);
        }
    }
    return str;
}
и солнце б утром не вставало, когда бы не было меня
Re[71]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Не будет копирования


Я в курсе

Это просто был пример другой крайности, чтоб показать комичность данного "теста".
Re[74]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:23
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>В общем, слив засчитан. Хотя съехать на "хи-хи" тоже неплохо.

C>>То есть ответить Вам нечего? Отлично.

ГВ>Да куда уж мне отвечать, когда тут показывают 650 GBps на ~25-гигабайтной шине.


Действительно. Вам не отвечать — Вам только сливы считать.
Re[68]: Ну ты вообще многого не видишь... ;)
От: neFormal Россия  
Дата: 09.06.09 14:23
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>У Вас соска выпала.

F>>крадёшь шутки у Петросяна?.
C>А где Вы шутку увидели?

вот и я говорю, что петросянщина..
...coding for chaos...
Re[73]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:26
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>>P.S.: Ты хоть понял, что я мерил?

C>>Я же говорю: то, что Вы меряете — маразм. Сравнивать StringBuffer.ToString и обычное копирование С++.

ГВ>Отнюдь. Я "сравнил" не только копирование, но ещё и несколько распространённых мифов. Например, то, что создание нового объекта в .Net — едва ли не бесплатная операция вкупе с выделением памяти, каковая, судя по высказываниям апологетов, никогда не вылезает из пределов L2-кэша. Ну и потом, где же очень умные JIT+GC, которые "в принципе" могли бы чуть ли не сразу удалять распределённую память, да и делать это в параллельном потоке по цене картофельной шелухи?


Всем отделом смеемся. Продолжайте в том же духе.
Re[71]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:27
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Не будет копирования


Да это как раз понятно было сразу.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[73]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 14:27
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Не надо дудеть в дудку мозговедения. Почему-то даже "не привязанные к C++" отмечают притормаживания .Net. Взять высказывания того же vdimas из соседнего топика.


Технология сравнительно молодая, но очень бурно развивающаяся. Как тут в одной ветке аж удивиль когда они нововведения вводить успевают. Все идет своим чередом. Правда для кого то медлено, а для кого то и очень быстро.
Главное вектор развития выбран верно. А С++ с C# будут ещё долго существовать вместе.
и солнце б утром не вставало, когда бы не было меня
Re[74]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:29
Оценка:
Здравствуйте, criosray, Вы писали:

C>Всем отделом смеемся. Продолжайте в том же духе.


Люблю доставлять людям радость. Ложка дёгтя: теперь я точно знаю, к какому постингу апеллировать, когда услышу звон про бесплатность GC и распределения памяти под .Net.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[75]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

C>>Всем отделом смеемся. Продолжайте в том же духе.


ГВ>Люблю доставлять людям радость. Ложка дёгтя: теперь я точно знаю, к какому постингу апеллировать, когда услышу звон про бесплатность GC и распределения памяти под .Net.


Аппелировать к этому маразму? Ну давайте, удачи. Только, боюсь, что любой вменяемый программист Вас просто высмеит, если Вы покажете тот пост. Так что на Вашем месте я бы скромно попалкивал, а не орал на всю деревню: я только что обгадился!111аааа
Re[74]: Но продолжим органометрию
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:33
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


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

S>Главное вектор развития выбран верно. А С++ с C# будут ещё долго существовать вместе.


"Верно" — это что означает?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[73]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 14:33
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Не правильно. Если в компьютерные мегабайты переводить, то надо делить на 1024*1024 с соответственным домножением числителя на 1000.

Да уж старею килобайты с мегабайтами путать стал
А меги с тысячами.
и солнце б утром не вставало, когда бы не было меня
Re[66]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 14:36
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Если мы хотим иметь поиск по индексу, то нужно иметь дерево


Дерево, естественно, нужно. Но не обязательно 2-3.

S> Для имутабельного обязательно нужно балансированное дерево, т.к. при модификации строки, мы должны скопировать ветку от корня до узла с модифицированной строкой. Балансированное что бы доступ к узлу от корня был Log(N), в том числе и для закладок, содержащий путь до строкию


Если структура нужна нам в первую очередь для конкатенации — балансировать можно редко.
А так да, если у нас 2-3 дерево, то сложность конкатенации будет логарифмом от длинны меньшей строки.
Но непонятно, откуда Геннадий Васильев вывел необходимость или пересоздавать все узлы (это понадобится только если мы не балансировали дерево и всегда добавляли по дному блоку с одной и той же стороны и дерево выродилось в однонаправленный список) или перебирать все узлы при доступе по индексу.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[77]: Но продолжим органометрию
От: criosray  
Дата: 09.06.09 14:37
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ладно, ладно, я тоже хорошо знаю, что 2x2=5 при очень больших значениях 2.


Тоже? А-а, Вы про Шеридана? Что ж, не удивляюсь. Вполне закономерный результат.
Re[58]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 14:40
Оценка:
Здравствуйте, Геннадий Васильев,

Вы это
Автор: Klapaucius
Дата: 08.06.09
комментировать собираетесь? Если нужно, могу написать слово "парадигма" в качестве приманки.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[75]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 14:46
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


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


ГВ>Трудно сказать. Больше похоже на то, что отставание в производительности у C# будет всегда, если не прибегнуть к мерам типа прямой работы с памятью, от чего пытаются шугаться. Ну не бывает чудес, кроме алгоритмической оптимизации.


На данный момент нет особой оптимзации JIT ом, хотя какую то часть кода можно за счет суперкомпиляции в мсил код оптимизировать.
Вторая это NGen оптимизировать уже под процессор, если JIT этим заниматься не хочет.
S>>Главное вектор развития выбран верно. А С++ с C# будут ещё долго существовать вместе.

ГВ>"Верно" — это что означает?

Это развитие как манагед сред так и нативных, во многих случаях сближаясь. В многих случаях не нужна супер пупер скорость, нужны удобные средства разработки с минимальным затратами, с приемлемой скоростью работы. Поверь мне 1С ку.
Вот тут насчет веревок диспут шел, да эффективны,можно и другие структуры более эффективные создать, а будут пользоваться стрингбуилдером. Потому, что для большинства задач его хватает за глаза. Процессор в основном то простаивает.
и солнце б утром не вставало, когда бы не было меня
Re[59]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:47
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>>Вспомни, чем было спровоцировано моё непонимание. Здесь же все ходы записаны.

K>

ГВ>>>Если узлы хранят индексы элементов, и мы вставляем новый узел в начало, то дублировать придётся всё.
WH>>Какие индексы? Зачем все?

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

K>Ну и чем может быть спровоцировано такое непонимание? Для добавления последовательности в начало нужно заменить 0 узлов. И создать 1 новый узел. Сложность O(1). При этом доступ по индексу будет с логарифмическим.

Обрати внимание на вот этот постинг
Автор: WolfHound
Дата: 04.06.09
:

ГВ>>Как минимум, узлы должны хранить индекс начального элемента собственной подстроки. Могут, конечно, не хранить, но тогда поиск фрагментов очень не кисло усложнится.
WH>Нет. Им достаточно хранить количество символов в собственной подстроке.


Про индексы элементов и длины я оговорился здесь
Автор: Геннадий Васильев
Дата: 04.06.09
:

ГВ>В прочем, тут есть более оптимальная структура — хранить в узле только длину фрагмента "слева". Так что, на счёт модификации всех элементов дерева при вставке в начало я погорячился (не внимательно прочёл Боэмовскую бумагу).


Я ж говорю, все ходы записаны. Только надо прочитать записанное.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[59]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 14:48
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Вы это
Автор: Klapaucius
Дата: 08.06.09
комментировать собираетесь? Если нужно, могу написать слово "парадигма" в качестве приманки.


Откомментировал. Думал, что ты всё же перечитал дискуссию.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[67]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 14:52
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

Это нужно для имутабельной структуры. Ввыделяя новые узлы до модифицированного узла, му оставляем ссылку на "старое" дерево в старом корне, и ссылаясь на новый корень, представляющий собой ссылку на новое дерево, но имеющегл одинаковые ветки со старым. Классика функционального программирования.
и солнце б утром не вставало, когда бы не было меня
Re[60]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 14:54
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Я ж говорю, все ходы записаны. Только надо прочитать записанное.


Ну так я читал все это — отсюда и ощущение сюрреальности. Ведь вы вроде как обнаружили свою ошибку, а потом спор продолжился.
Расскажите тогда, что вы понимаете под словами "длина собственной подстроки" — наверное все дело в этом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[68]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 14:56
Оценка:
Здравствуйте, Serginio1, Вы писали:

S> Это нужно для имутабельной структуры. Ввыделяя новые узлы до модифицированного узла, му оставляем ссылку на "старое" дерево в старом корне, и ссылаясь на новый корень, представляющий собой ссылку на новое дерево, но имеющегл одинаковые ветки со старым. Классика функционального программирования.


Ну а я о чем? Узлы до модифицированного узла, а не все узлы дерева.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[69]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 14:59
Оценка:
Здравствуйте, Klapaucius, Вы писали:


K>Ну а я о чем? Узлы до модифицированного узла, а не все узлы дерева.

Все узлы от корня только в вырожденом случае (двухнаправленный список), чего быть не может в сбалансированом дереве.
и солнце б утром не вставало, когда бы не было меня
Re[61]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 15:02
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Ну так я читал все это — отсюда и ощущение сюрреальности. Ведь вы вроде как обнаружили свою ошибку, а потом спор продолжился.

K>Расскажите тогда, что вы понимаете под словами "длина собственной подстроки" — наверное все дело в этом.

А что можно под этим понимать? Это длина только той строки, которая отнесена непосредственно к узлу. Не сумма длин строк, хранящихся в дочерних узлах, плюс собственная строка, а только та, которая сопоставлена с самим узлом.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[70]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 15:02
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


Именно это я и написал. Только список однонаправленный, а не двунаправленный.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[62]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 15:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>А что можно под этим понимать?


Ну я выше написал что я под этим понял.

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


А. Вы имеете в виду длину линейного буфера в листе. Но буфер не сопоставлен с узлом, да и строка в контексте обсуждения — это дерево. Ну а подстрока — поддерево. Строка это абстракция, а дерево реализация.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[63]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 15:19
Оценка:
Здравствуйте, Klapaucius, Вы писали:

ГВ>>А что можно под этим понимать?

K>Ну я выше написал что я под этим понял.

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

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


K>А. Вы имеете в виду длину линейного буфера в листе.


Нет-нет. Если считать, что с каждым узлом дерева сопоставлен некий фрагмент общей строки, то "собственная подстрока" — это только тот фрагмент, который сопоставлен с этим узлом. Буферы тут не при чём.

K>Но буфер не сопоставлен с узлом, да и строка в контексте обсуждения — это дерево. Ну а подстрока — поддерево. Строка это абстракция, а дерево реализация.


То есть каждому символу строки сопоставляется отдельный узел дерева?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[64]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 15:32
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Семантики заявили, что все зависит от того, как понимать слова
"картофель", "может" и "двигаться". Так как ключом является модальный
глагол "мочь", то его надлежит тщательно исследовать. Затем они
приступили к созданию Энциклопедии Космической Семасиологии, первые
четыре тома которой посвящались модальным значениям глагола "мочь".


K>>А. Вы имеете в виду длину линейного буфера в листе.

ГВ>Нет-нет. Если считать, что с каждым узлом дерева сопоставлен некий фрагмент общей строки, то "собственная подстрока" — это только тот фрагмент, который сопоставлен с этим узлом. Буферы тут не при чём.

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

ГВ>То есть каждому символу строки сопоставляется отдельный узел дерева?


Сиволы и группы символов — это не узлы, а листья.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[65]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 15:40
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>>>А. Вы имеете в виду длину линейного буфера в листе.

ГВ>>Нет-нет. Если считать, что с каждым узлом дерева сопоставлен некий фрагмент общей строки, то "собственная подстрока" — это только тот фрагмент, который сопоставлен с этим узлом. Буферы тут не при чём.
K>Узел, он на то и узел, что с ним сопоставлено N подстрок. Так вот, для бинарного дерева достаточно хранить длину левой подстроки. Если вы ее называете собственной подстрокой — тогда мы понимаем под этими словами одно и то же.

Ни в коем случае я этого так не понимаю. Собственная — это собственная. "Слева" — это "слева". Хорош уже передёргивать — если под белым понимать синее, а под синим оранжевое, то и радуги нет.

ГВ>>То есть каждому символу строки сопоставляется отдельный узел дерева?

K>Сиволы и группы символов — это не узлы, а листья.

Тоже вариант, не спорю.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[67]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 16:05
Оценка:
Здравствуйте, Klapaucius, Вы писали:

ГВ>>Ни в коем случае я этого так не понимаю. Собственная — это собственная. "Слева" — это "слева". Хорош уже передёргивать — если под белым понимать синее, а под синим оранжевое, то и радуги нет.

K>Ну в каком она еще смысле может быть собственной, при том, что собственные строки есть у всех узлов?

[skip the nice picture]

Собственной она может быть только в прямом смысле, то есть принадлежащей только одному узлу, а не как собирательный термин для обозначения всех подстрок его потомков.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[68]: Ну ты вообще многого не видишь... ;)
От: Klapaucius  
Дата: 09.06.09 16:10
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

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


Но строка — это дерево. И она ни в каком ином виде кроме поддерева, т.е. в виде всех подстрок потомков существовать не может.
Собственное поддерево узла — это собственная подстрока.
... << RSDN@Home 1.2.0 alpha 4 rev. 1228>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[67]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 16:29
Оценка:
Здравствуйте, Klapaucius, Вы писали:


Красиво
и солнце б утром не вставало, когда бы не было меня
Re[71]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 16:48
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Только список однонаправленный, а не двунаправленный.

Согласен. Что то я сегодня не в форме
и солнце б утром не вставало, когда бы не было меня
Re[77]: Но продолжим органометрию
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 09.06.09 16:49
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

Здравствуйте, Геннадий Васильев, Вы писали:

Хочу добавить, что развитие одного благосклонно сказывается на развитие другого. Как говорится борьба и единство противоположностей.
и солнце б утром не вставало, когда бы не было меня
Re[69]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 17:13
Оценка:
Здравствуйте, Klapaucius, Вы писали:

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

K>Но строка — это дерево. И она ни в каком ином виде кроме поддерева, т.е. в виде всех подстрок потомков существовать не может.
K>Собственное поддерево узла — это собственная подстрока.

Не-е-е, Дэвид Блейн, строка — это строка, дерево — это дерево, узлы — это узлы.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[71]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 17:54
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Не-е-е, Дэвид Блейн, строка — это строка, дерево — это дерево, узлы — это узлы.

C>Одно из двух: либо Вы откровенно глупы, либо просто пытаетесь троллить.

Охрененно, ты мне оставил целых две возможности для выбора.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[73]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 18:42
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>>>Не-е-е, Дэвид Блейн, строка — это строка, дерево — это дерево, узлы — это узлы.

C>>>Одно из двух: либо Вы откровенно глупы, либо просто пытаетесь троллить.
ГВ>>Охрененно, ты мне оставил целых две возможности для выбора.
C>Не я Вам, а Вы сами себе.

Я сам себе оставил только две возможности выбора тобой твоих оценок. Дзен... Коан...

Папаша ходил на голове и горланил песню "Весь мир вверх тормашками".

(c) Р. Шекли.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[75]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 18:59
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Я сам себе оставил только две возможности выбора тобой твоих оценок. Дзен... Коан...

C>Нет, Вы сами себе создали имидж, я лишь прокомментировал.

Ты бы своим имиджем лучше озаботился, светоч ты наш.

ГВ>>

Папаша ходил на голове и горланил песню "Весь мир вверх тормашками".

(c) Р. Шекли.

C>А Шекли в курсе, что Вы ему приписали выдуманное Вами же?

Каттнер, конечно, а не Шекли. Это я не прав. Какая-то из историй о Хогбенах.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[74]: Поправка
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.06.09 19:00
Оценка:

Папаша ходил на голове и горланил песню "Весь мир вверх тормашками".

(c) Г. Каттнер
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[58]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.06.09 04:58
Оценка:
Здравствуйте, criosray, Вы писали:
C>itoa Вы, поди, тоже знали на генетическом уровне?
itoa была описана в Big Blue C, которую я читал классе в пятом. Так что можно считать, что да, таки на генетическом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[56]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 10.06.09 06:55
Оценка:
Здравствуйте, criosray, Вы писали:

CC>>На 10к строк С# падает с out of memory

C>??? Не падает. Выполняется за 3.9 сек.
У тя или 64битная ОС или памяти > 2гиг

CC>>В С++ у тебя вылетает bad_alloc на ~1.4 Гб занятой памяти.

C>1.4 гб это далеко не лимит — еще как минимум 600 мб должно быть доступно процессу.
если посмотреть VMView то видно что куски то есть, но постоянно растущая строка некоторую часть хипа зафрагментировала.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[57]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 07:11
Оценка:
Здравствуйте, CreatorCray, Вы писали:
CC>>>В С++ у тебя вылетает bad_alloc на ~1.4 Гб занятой памяти.
C>>1.4 гб это далеко не лимит — еще как минимум 600 мб должно быть доступно процессу.
CC>если посмотреть VMView то видно что куски то есть, но постоянно растущая строка некоторую часть хипа зафрагментировала.
В свое время делал тесты http://www.rsdn.ru/forum/design/701354.1.aspx
Автор: Serginio1
Дата: 30.06.04

Для Лохов память выделяется со старших адресов и не подвергается сборе мусора. Хотя давно было дело.
и солнце б утром не вставало, когда бы не было меня
Re[64]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 10.06.09 07:27
Оценка:
Здравствуйте, criosray, Вы писали:

ГВ>>Можно продолжить играться с std::wstring. Например, подсунуть ей другой аллокатор.

C>Ну да. А еще можно переписать ее так, чтоб внутри было concatenation tree — сугубо, чтоб заточить под задачу аккумулирования строк.
Мне кажется или ты начинаешь понемногу понимать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[58]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 07:32
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>В свое время делал тесты http://www.rsdn.ru/forum/design/701354.1.aspx
Автор: Serginio1
Дата: 30.06.04

S>Для Лохов память выделяется со старших адресов и не подвергается сборе мусора. Хотя давно было дело.
Вернее сборке то подвергается, не подвергается дефрагментации.
и солнце б утром не вставало, когда бы не было меня
Re[62]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 10.06.09 09:30
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А вот по соседству бродит некий Егор, который ставит минусы на все мои посты, вот он уверен, что std::wstring — это епик вин С++, и что он не "гора компромиссов между ужами и ежами", а спроектирован побеждать во всех обстоятельствах.

Что то я такого в этой теме не припомню.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[55]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 10.06.09 09:30
Оценка:
Здравствуйте, criosray, Вы писали:

C>Кстати, спасибо, что напомнили. Публичные методы StringBuilder еще и thread safe в отличии от std::wstring.

Не совсем так

Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe.

http://msdn.microsoft.com/en-us/library/system.text.stringbuilder(VS.71).aspx
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[63]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.06.09 09:58
Оценка:
Здравствуйте, CreatorCray, Вы писали:
CC>Что то я такого в этой теме не припомню.
Чего ты не припомнишь? Егора?
Вот: http://rsdn.ru/Forum/Message.aspx?mid=3415798&amp;only=1
Автор: Erop
Дата: 04.06.09

Цитирую:

S>Изменяемые строки в моём любимом языке реализовали вполне эффективно — см StringBuilder.
Это, эта всякий случай, если не понятно: НЕ СМОГЛИ РЕАЛИЗОВАТЬ ЭФФЕКТИВНО СТРОКУ, НЕ РАЗДЕЛЯЯ ЕЁ НА МУТАБЕЛЬНУЮ И ИММУТАБЕЛЬНУЮ... А что, смогли что ли?

... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[58]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 10.06.09 12:01
Оценка:
Здравствуйте, Serginio1, Вы писали:

CC>>>>В С++ у тебя вылетает bad_alloc на ~1.4 Гб занятой памяти.

C>>>1.4 гб это далеко не лимит — еще как минимум 600 мб должно быть доступно процессу.
CC>>если посмотреть VMView то видно что куски то есть, но постоянно растущая строка некоторую часть хипа зафрагментировала.
S>В свое время делал тесты http://www.rsdn.ru/forum/design/701354.1.aspx
Автор: Serginio1
Дата: 30.06.04

S>Для Лохов память выделяется со старших адресов и не подвергается сборе мусора. Хотя давно было дело.
О чём ты?
Я писал про поведение С++ примера, откуда сборка мусора?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[67]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 12:01
Оценка:
Здравствуйте, Cyberax, Вы писали:


C>С++ как обычно даёт кучу возможностей сделать что-то красивое (как и выстрелить себе в ногу). Например, я писал свой пакет строк на основе Александресковских. С фичами, которых нет в С# (и не будет). Например, возможностью превратить immutable-строку в mutable при необходимости с почти нулевыми затратами.

Stringbuilder занимается таким превращением. http://rsdn.ru/forum/flame.comp/3421959.1.aspx
Автор: Геннадий Васильев
Дата: 09.06.09
и солнце б утром не вставало, когда бы не было меня
Re[68]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 10.06.09 12:35
Оценка:
Здравствуйте, Serginio1, Вы писали:

C>>С++ как обычно даёт кучу возможностей сделать что-то красивое (как и выстрелить себе в ногу). Например, я писал свой пакет строк на основе Александресковских. С фичами, которых нет в С# (и не будет). Например, возможностью превратить immutable-строку в mutable при необходимости с почти нулевыми затратами.

S>Stringbuilder занимается таким превращением. http://rsdn.ru/forum/flame.comp/3421959.1.aspx
Автор: Геннадий Васильев
Дата: 09.06.09

Не, у меня круче всё было
Sapienti sat!
Re[68]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 12:45
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Не, у меня круче всё было

Ну своё то оно всегда
Просто имутабельность строки, гарантируется фреймворком в сэйв режиме. В нативе это возможно только через пометку памяти R/O.
и солнце б утром не вставало, когда бы не было меня
Re[69]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 10.06.09 12:54
Оценка:
Здравствуйте, Serginio1, Вы писали:

C>>Не, у меня круче всё было

S>Ну своё то оно всегда
S> Просто имутабельность строки, гарантируется фреймворком в сэйв режиме. В нативе это возможно только через пометку памяти R/O.
В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.
Sapienti sat!
Re[69]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 12:58
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

Суть то в том, что занимается. И нефиг для этих целей стрингбуилдер трогать уже строка для этого есть.
Скорее проблема в том, что в мануалах я этого вроде не видел, хотя и могу ошибаться.
и солнце б утром не вставало, когда бы не было меня
Re[67]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 10.06.09 13:20
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>С фичами, которых нет в С# (и не будет). Например, возможностью превратить immutable-строку в mutable при необходимости с почти нулевыми затратами.

Лучше молчать, если не знает.
Re[57]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 10.06.09 13:22
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>>>На 10к строк С# падает с out of memory

C>>??? Не падает. Выполняется за 3.9 сек.
CC>У тя или 64битная ОС или памяти > 2гиг
Слабо прочитать топик?

CC>>>В С++ у тебя вылетает bad_alloc на ~1.4 Гб занятой памяти.

C>>1.4 гб это далеко не лимит — еще как минимум 600 мб должно быть доступно процессу.
CC>если посмотреть VMView то видно что куски то есть, но постоянно растущая строка некоторую часть хипа зафрагментировала
Еще один камень в огород С++.
Re[65]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 10.06.09 13:25
Оценка:
Здравствуйте, CreatorCray, Вы писали:

ГВ>>>Можно продолжить играться с std::wstring. Например, подсунуть ей другой аллокатор.

C>>Ну да. А еще можно переписать ее так, чтоб внутри было concatenation tree — сугубо, чтоб заточить под задачу аккумулирования строк.
CC>Мне кажется или ты начинаешь понемногу понимать?

Это Вы начинаете немного понимать. У меня-то проблем с пониманием не было и я изначально говорил, что разделение строк по методам работы с ними (а не по способу внутренней реализации, как это сделано в с++ ) на строку и аккумулятор в дотнет — гениальное решение, которое на много эфективнее (и удобнее) строк С++.
Re[69]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 10.06.09 13:26
Оценка:
Здравствуйте, CreatorCray, Вы писали:



ГВ>>>Дотнетовский, например, String.insert возвращает string. А QT-шный QString::insert возвращает QString&. Разница понятна?

C>>Разница понятна — и то и другое есть ссылка.
CC>О да!

CC>Как ты там говорить любишь: "не позорьтесь"


Смех без причины? Что Вас так насмешило?
Re[68]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 10.06.09 13:40
Оценка:
Здравствуйте, criosray, Вы писали:

C>>С фичами, которых нет в С# (и не будет). Например, возможностью превратить immutable-строку в mutable при необходимости с почти нулевыми затратами.

C>Лучше молчать, если не знает.
Таки нет в .NET тех фич, которые у меня были.
Sapienti sat!
Re[69]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 10.06.09 13:48
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>>>С фичами, которых нет в С# (и не будет). Например, возможностью превратить immutable-строку в mutable при необходимости с почти нулевыми затратами.

C>>Лучше молчать, если не знает.
C>Таки нет в .NET тех фич, которые у меня были.
Ну давайте рассказывайте что за фичи-то.
Re[70]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 14:14
Оценка:
Здравствуйте, Cyberax, Вы писали:

S>> Просто имутабельность строки, гарантируется фреймворком в сэйв режиме. В нативе это возможно только через пометку памяти R/O.

C>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.
Тем и хорош манагед, что в ССЗБ сильно ограничен. Тут уж выбирай свобода действий в нативе, но с буратинами, либо в отсутствии Папы Карло выискивать обходные пути.
и солнце б утром не вставало, когда бы не было меня
Re[70]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 10.06.09 14:15
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Лучше молчать, если не знает.

C>>Таки нет в .NET тех фич, которые у меня были.
C>Ну давайте рассказывайте что за фичи-то.
Я же сказал — трансформация mutable/immutable с O(1) затратами (если это возможно), разные виды хранилищ (стековое, со Small Buffer Optimization), возможность сделать непотокобезопасную мутируемую строку, возможность делать разное представление и т.п.
Sapienti sat!
Re[71]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 10.06.09 14:17
Оценка:
Здравствуйте, Serginio1, Вы писали:

C>>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.

S> Тем и хорош манагед, что в ССЗБ сильно ограничен. Тут уж выбирай свобода действий в нативе, но с буратинами, либо в отсутствии Папы Карло выискивать обходные пути.
unsafe {
//Буратина
};


В С# буратин тоже хватает, на самом деле.
Sapienti sat!
Re[72]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 10.06.09 14:26
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>
C>unsafe {
C>//Буратина
C>};
C>


C>В С# буратин тоже хватает, на самом деле.

Я на этот момент уже обращал внимания, говоря об сэйв режиме. Причем заметь они помечаются специальным кодом,
и CAS может запретить данный код. В манагед большинство прекрасно чувствует себя и без unsafe. ССЗБ и без этого еще найдется.
и солнце б утром не вставало, когда бы не было меня
Re[70]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.06.09 14:29
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


C>>>Не, у меня круче всё было

S>>Ну своё то оно всегда
S>> Просто имутабельность строки, гарантируется фреймворком в сэйв режиме. В нативе это возможно только через пометку памяти R/O.
C>В С++ для этого есть слово "const". Конечно, его можно снять const_cast'ом, но это уже ССЗБ.
const — это не то.
Вот ты написал метод, который получает const char*.
Можешь ли ты сохранить внутри класса эту строку? Правильный ответ — нет, так как кто-то другой вполне мог эту строку получит не как константную и спокойно её меняет.
Побороть это можно с помощью COW, но тогда надо внутри обертки строки поддерживать счетчик ссылок, но он небесплатный.
Re[71]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 10.06.09 16:12
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Таким глубоким, бесконечно глубоким, я бы сказал, возражениям я не могу ничего противопоставить. Такую рекурсию мой ограниченный умишко не вместит. Еще Энштейн говорил, что знает только две бесконечные вещи: вселенную и определение строки через строку. Да и то, насчет вселенной он был не совсем уверен.


Ну уж, куда вселенной до рекурсивной строки-то?!

Ладно, завязываем: по сути я тебя понял. Вопросы к WolfHound-у остались в воздухе, да и шут с ними. Это, по сути, даже не о терминах спор, а чуть ли не о коннотациях.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[62]: Ну ты вообще многого не видишь... ;)
От: Erop Россия  
Дата: 10.06.09 20:25
Оценка:
Здравствуйте, criosray, Вы писали:

E>>STL -- это часть средства для изготовления фрейсворков. Сам по себе STL фреймворком не является, так как без кучи великов на нём не поедешь...


C>STL это и есть фреймворк. Убогий — да. Но тем не менее фреймворк.

Нет, ну если ты сказал, то как же можно в этом сомневаться-то?

C>Давайте без домыслов и фантазий бабушки-гадалки, окей?

Ну расскажи нам как на "фреймворке STL" передать что-то по сети, или окошко написать, или, хотя бы, прочитать/записать UTF-16 текстовый файл...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Эх, выдыхай, однако...
От: _d_m_  
Дата: 11.06.09 02:25
Оценка:
Здравствуйте, Erop, Вы писали:

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


E>>>А я тебя по складам тогда буду: Кри-О-Срай?

C>>По складам? Если Вы подразумеваете по слогам, то по слогам читается криос рэй.
E>Эх! В стихах, видать, ты не знаток, увы!..
E>Но в целом в русском слоге всегда не больше одного гласного звука...

Видать ты тоже не знаток: кри-ос-рай
Re[41]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 04:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

PD>>Так Рихтер все же прав или нет — насчет просмотра блоков ?
S>Ты его неправильно понимаешь. Никакие "блоки" памяти GC, естественно, не просматривает. У него есть полная информация об устройстве этих "блоков памяти".

The garbage
collector now traverses the heap linearly looking for contiguous blocks of garbage objects
(now considered free space). If small blocks are found, the garbage collector leaves the
blocks alone.
If large free contiguous blocks are found, however, the garbage collector shifts the
nongarbage objects down in memory (using the standard memcpy function that you’ve
known for years) to compact the heap.

Выделено мной. Как еще можно понимать linearly looking, я не понимаю.


PD>>Копировать без надобноси не надо , и такие конструкции лучше вообще употреблять с осторожностью.

S>Какие конструкции? Вызов методов? Ну так я тебе напомню, что код в основном из них и состоит.

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


PD>>Но для этого надо видеть, во что твой код примерно превратится. Без просмотра ассемблерного кода. Просто в уме понимать

S>Вот для понимания того, во что превратится твой код, нужно сначала съесть пуд соли с дизассемблером.

И да и нет. Для того, чтобы "видеть" за С++ конструкциями ассемблерные команды — да. Но этого я обычно и не делаю, разве что если меня вдруг удивит скорость некоторого фрагмента. А вот чтобы понимать, во что такая конструкция выльется — даже не обязательно знать асм.

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

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

Какими библиотеками ?

Стандартная C RTL — да, используется, да, свою версию strcpy я не буду писать. Win32 — да, тоже, потому что я и не могу написать ее функции. Но про первую столько понаписано и столько сравнений проведено, и столько раз эта strcpy обсуждалась, что я знаю, чему тут можно верить. А поскольку основное время все же ест мой собственный код, то я над ним и полный хозяин.


PD>>Это тебе и кое-кому еще кажется, что это так. Профайлер лишь говорит о том, что есть, но ни слова не скажет о том, что могло бы быть. Вот тебе пример. Подсчет числа счастливых билетов. Тупо — 6-кратный цикл. Немного подумать — пятикратный. Еще подумать — тройной. А, оказывается, есть просто формула, без всяких циклов. Ну вот написал некий программист 6-цикл , видит, что все время уходит на... и что дальше ?

S>Будет повод исправить программу. А то, может быть, там всё время уходит не на цикл, а на ожидание пользовательского ввода этого номера. В итоге замена "шестикратного цикла" улучшит ситуацию на 1%.

Ушел от ответа. Никакого пользовательского ввода в этой задаче нет. А как все же исправить — неясно.

PD>>SQL — это тоже "управляемый" язык, так что здесь верно то же, что и для .Net. Но к программированию на уровне "я точно знаю, какие команды процессора у меня выполняются (даже если писалось не на асме)" это не относится.

S>Это очень узкая точка зрения. Грубо говоря, для SQL сервера команды процессора не имеют никакого значения. Не потому, что он "управляемый", а потому, что основное время уходит на ожидание подъема данных в память. Для него low-level — это "я точно знаю, какие страницы у меня читаются". И эта ситуация ничем принципиально не отличается от C++ и ассемблера. Точно так же опыт нарабатывается исключительно с помощью инструментов. И точно также опыт пользования MS SQL можно перенести на MySQL — как и Паскалевский опыт на С++. Потому что устройство "матчасти" примерно одинаковое. Переносить опыт с Паскаля на SQL, к примеру, будет неэффективно. И с SQL на STL тоже.

Я не случайно поставил слово "управляемый" в кавычки. Я вовсе не утверждаю, что он родня C#. Я просто одно утверждаю — он не компилируется в ассемблерные коды, а исполняется под управлением некоторой исполняющей системы. Больше я ничего не хотел сказать.
With best regards
Pavel Dvorkin
Re[42]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.06.09 06:52
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

Если я правильно понял, то там идет оценка фрагментации кучи,
"При больших свободных прилегающих блоков, сборщиком мусора сдвигает
nongarbage объекты в памяти ", если небольшие то и нефиг эту кучу дефрагментировать.
и солнце б утром не вставало, когда бы не было меня
Re[42]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.06.09 07:36
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Выделено мной. Как еще можно понимать linearly looking, я не понимаю.

Очень жаль, что не понимаешь. Linearly looking вовсе не означает, что там есть цикл
for(int i=HeapStart;i< HeapLength;i++)
  if (IsGarbage__heap[i]) 
    ...

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

PD>Мой код состоит в основном отнюдь не из вызова методов. Вот в этом-то и в значительной степени разница между нашими подходами. Методы — это так, для лучшей организации, не более. А код состоит из реализации алгоритма, достаточно сложного, вообще говоря. Я могу эту реализацию написать с методами, могу и без методов, это будет организационно хуже, но работать будет также, даже, может, быстрее, если там не все inline у методов.

Ну, твоему коду, значит, повезло. Ему фреймворк не нужен — достаточно базовой арифметики (спасибо, что хотя бы она встроена в C++. А то ведь могли и это вынести в stl). Тут, правда, не совсем ясно, зачем вообще нужны плюсы. С тем же успехом можно колбасить код и на С — ведь никаким полиморфизмом или, скажем, ексепшнами, ты пользоваться не собираешься. Но это вопрос другой.

S>>Вот для понимания того, во что превратится твой код, нужно сначала съесть пуд соли с дизассемблером.

PD>И да и нет. Для того, чтобы "видеть" за С++ конструкциями ассемблерные команды — да. Но этого я обычно и не делаю, разве что если меня вдруг удивит скорость некоторого фрагмента. А вот чтобы понимать, во что такая конструкция выльется — даже не обязательно знать асм.
Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"? Асм, конечно, знать не обязательно. Но обязательно знать то, во что "выливается" конструкция. К примеру, выливается ли она в доступ к файлу подкачки, и если выливается, то когда. Для понимания того, что выделение массива данных размером в 5GB для обработки неизбежно потребует работы с файлом подкачки ассемблер знать не обязательно. Зато обязательно знать про архитектуру виртуальной памяти на той платформе, для которой ты пишешь — ну, чтобы вообще понимать, что такое файл подкачки. А если под "выливается" понимать, скажем, количество сбросов конвеера, то нужно как бы знать не только ассемблер на уровне MOV AH, AL, а вообще говоря архитектуру процессора.

PD>Какими библиотеками ?

Любыми библиотеками.
PD>Стандартная C RTL — да, используется, да, свою версию strcpy я не буду писать. Win32 — да, тоже, потому что я и не могу написать ее функции. Но про первую столько понаписано и столько сравнений проведено, и столько раз эта strcpy обсуждалась, что я знаю, чему тут можно верить. А поскольку основное время все же ест мой собственный код, то я над ним и полный хозяин.
Вопрос ровно в том, что такое "твой собственный код". Повторюсь: если этот код — это всего лишь арифметика, то ему просто повезло. Остальным, тем, кто не хочет, к примеру, педалить руками циклы в умножении матриц, хочется пользоваться библиотекой. И тут выясняется, что компилятор на диво умён — и иногда невинно выглядящие вещи (типа a*b) скрывают за собой холостое копирование килобайтов, а иногда наоборот — страшные навороты сворачиваются в очень компактный целевой код.
И без профайлера выяснить это невозможно — я еще раз повторяю пример с ошибкой в MS STL, из-за которой у них там было огребание со строками. Всего лишь немного другой алгоритм разрешения неопределённостей в частичных специализациях в компиляторе, и тот же самый пользовательский код с той же самой библиотекой начинает перформить совсем по-другому.

PD>Ушел от ответа. Никакого пользовательского ввода в этой задаче нет. А как все же исправить — неясно.

Я уже неоднократно слышу подобные гм-м, претензии, от профайлероненавистников. Еще раз неустанно повторяю: профайлер и не обещал вам сказать, как исправить. Но что исправить — профайлер скажет. Ситуация типа "у меня вся программа состоит из одного шестикратного цикла" встречаются, увы, крайне редко. Опять же — пример из далёкого тебе мира СУБД. "Показ плана запроса" не скажет тебе, какие индексы нужно поставить, и какие агрегатные таблицы нужно создать. Но без просмотра плана запроса угадать способ ускорения практически невозможно. Точнее, опять же так: опытный DBA может "в уме" прикинуть план запроса, с учётом селективности тех или иных предикатов, и еще много чего. Но его опытность — не в чтении книжек Кайта и Дейта. А в том, что он гонял реальные запросы на реальных базах под профайлером, и многократно наблюдал как за тем, что делает оптимизатор, так и за тем, куда уходит производительность. Программерская интуиция — это всего лишь кэш для фактов; если ты не будешь получать факты, то никогда не научишься предсказывать производительность. Вот, к примеру, ты, со всем своим опытом разработки, совершенно бессилен представить себе тот факт, что "мёртвые" строки не влияют на производительность программы. И что большинство приходящих тебе в голову "оптимизаций" в C# или Java только ухудшат производительность. И это несмотря на то, что про это пишут во всех книжках. А вот если бы ты поработал над конкретной задачей с профайлером в руках, то накормил бы конвеер своего процессора фактами. И уже на их основе получил новую, улучшенную "интуицию", которая бы ошибалась гораздо реже.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[45]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 07:43
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А кто будет знать? Дева мария или еще кто-то?

G>Именно процессор и делает такие провеки.

О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?

G>Кстати, что ты пытаешь доказать то? Что играться с атрибутами доступа к страницам памяти лучше, чем использовать иммутабельность?


Я лишь хочу сказать, что константые объекты можно в принципе делать для любого класса, размещая их в R/O памяти.
With best regards
Pavel Dvorkin
Re[43]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 07:44
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


S>Если я правильно понял, то там идет оценка фрагментации кучи,

S>"При больших свободных прилегающих блоков, сборщиком мусора сдвигает
S>nongarbage объекты в памяти ", если небольшие то и нефиг эту кучу дефрагментировать.

Да, я так же понял, но проход по блокам есть... Я же не говорю, что он с ними делает, я лишь отмечаю, что он их просматривает.
With best regards
Pavel Dvorkin
Re[44]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.06.09 07:49
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да, я так же понял, но проход по блокам есть... Я же не говорю, что он с ними делает, я лишь отмечаю, что он их просматривает.

Сначала он проходит по живым объекта, собирая информацию о их размещении и размере занимаемой памяти, потом сортирует по адресам и смотрит разницу между ближайшими адресами минус размер объекта.
Наверное правильно будет так проход не по блокам а по живим объектам отсортированным по адресам, учитывая их размер.
и солнце б утром не вставало, когда бы не было меня
Re[44]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.06.09 07:57
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


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


S>>Если я правильно понял, то там идет оценка фрагментации кучи,

S>>"При больших свободных прилегающих блоков, сборщиком мусора сдвигает
S>>nongarbage объекты в памяти ", если небольшие то и нефиг эту кучу дефрагментировать.

PD>Да, я так же понял, но проход по блокам есть... Я же не говорю, что он с ними делает, я лишь отмечаю, что он их просматривает.


Ты изначально говорил о зависимости скорости работы GC от количества мусора. Так вот на самом деле от количества мусора работа GC как раз и не зависит, зависит от количества живых объектов.
Re[43]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 08:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>Выделено мной. Как еще можно понимать linearly looking, я не понимаю.

S>Очень жаль, что не понимаешь. Linearly looking вовсе не означает, что там есть цикл
S>
S>for(int i=HeapStart;i< HeapLength;i++)
S>  if (IsGarbage__heap[i]) 
S>    ...
S>

S>Объясняется идея одного из алгоритмов компактификации хипа. К моменту, когда начинается вот эта работа, уже известно, что мусор, а что — нет. И время работы этого алгоритма совершенно не зависит от количества строк, на которые больше нет ссылок.

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

S>Ну, твоему коду, значит, повезло. Ему фреймворк не нужен — достаточно базовой арифметики (спасибо, что хотя бы она встроена в C++.


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

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


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

Но вообще-то С — подмножество С++. Ну пусть не совсем точное, но в основном да. Так что все, что говорилось про С++, можно отнести и к его подмножеству.

Дело в том, что есть программисты разного рода. Ты относишься к тем, для кого программирование — это вызов методов (сам признался), а я к тем, для кого программирование — это написание (методов, функций, процедур). Вот и вся разница . Поэтому для меня все эти игры с геттерами, сеттерами, интерфейсами, паттернами и т.д. малоинтересны. Мне придумать надо, как сделать, а не как оформить. Придумаю — как-нибудь оформлю. А вот если не придумаю — нечего будет оформлять.

S>>>Вот для понимания того, во что превратится твой код, нужно сначала съесть пуд соли с дизассемблером.

PD>>И да и нет. Для того, чтобы "видеть" за С++ конструкциями ассемблерные команды — да. Но этого я обычно и не делаю, разве что если меня вдруг удивит скорость некоторого фрагмента. А вот чтобы понимать, во что такая конструкция выльется — даже не обязательно знать асм.
S>Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"?

Просто примерно представить себе, что за код при этом получится. Это интуитивно, объяснить трудно.

>Асм, конечно, знать не обязательно.


Знать — обязательно, писать на нем — нет.

>Но обязательно знать то, во что "выливается" конструкция. К примеру, выливается ли она в доступ к файлу подкачки, и если выливается, то когда. Для понимания того, что выделение массива данных размером в 5GB для обработки неизбежно потребует работы с файлом подкачки ассемблер знать не обязательно.


Ну для этого сначала не мешает знать, что в Win32 это попросту невозможно . В Win64 можно. А насчет того, что это обязательно выльется к обращениям к файлу подкачки — неверно. Зависит от объема ОП. И не забывай, что файл подкачки может быть вообще отключен

>Зато обязательно знать про архитектуру виртуальной памяти на той платформе, для которой ты пишешь — ну, чтобы вообще понимать, что такое файл подкачки.


Чтобы понимать, что такое файл подкачки, знать архитектуру виртуальной памяти совсем не надо. У меня достаточно знакомых непрограммистов, которые в общем, понимают, для чего он нужен, но про архитектуру ВП слыхать не слыхали, и не смогу я им ее объяснить А вообще ВП делается примерно на одних и тех же принципах в любой архитектуре, ну разве что есть 2 варианта — страничный и сегментный.


PD>>Какими библиотеками ?

S>Любыми библиотеками.

Вопрос был риторический, пояснения даны были ниже.

PD>>Стандартная C RTL — да, используется, да, свою версию strcpy я не буду писать. Win32 — да, тоже, потому что я и не могу написать ее функции. Но про первую столько понаписано и столько сравнений проведено, и столько раз эта strcpy обсуждалась, что я знаю, чему тут можно верить. А поскольку основное время все же ест мой собственный код, то я над ним и полный хозяин.

S>Вопрос ровно в том, что такое "твой собственный код". Повторюсь: если этот код — это всего лишь арифметика, то ему просто повезло.

См. выше.

>Остальным, тем, кто не хочет, к примеру, педалить руками циклы в умножении матриц, хочется пользоваться библиотекой. И тут выясняется, что компилятор на диво умён — и иногда невинно выглядящие вещи (типа a*b) скрывают за собой холостое копирование килобайтов, а иногда наоборот — страшные навороты сворачиваются в очень компактный целевой код.


Слова, слова. Если речь идет о моем коде — да, я и отвечаю, я и анализирую. Если речь идет о чужой библиотеке, то это должен был сделать ее автор, у него код-то свой ? Если мне приспичит, и исходники есть, я могу за автора эту работу выполнить. В конце концов, и там код на С/С++, и здесь. Просто я своему коду доверяю, а тому — как знать. Сперва проверю на тестах.

S>И без профайлера выяснить это невозможно — я еще раз повторяю пример с ошибкой в MS STL, из-за которой у них там было огребание со строками.


А у меня не было проблем с char* . И с string STL тоже не было — я ее не использовал.


PD>>Ушел от ответа. Никакого пользовательского ввода в этой задаче нет. А как все же исправить — неясно.

S>Я уже неоднократно слышу подобные гм-м, претензии, от профайлероненавистников.

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

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


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

1. Написать 6-цикл, обнаружить с помощью профайлера, что основное время уходит на внутренний if (кстати, неужели я бы без профайлера бы не догадался
?) и потом улучшать — как ?
2. Посидеть подумать, свести к 3-циклу и написать, после чего посмотреть с помощью профайлера, что там не совсем хорошо — может, к примеру, не лучшим образом внутренний оператор реализован.

Так как же лучше ? Ответишь или , как в случае, когда тебе сказать нечего, просто выкинешь этот вопрос ?

>Опять же — пример из далёкого тебе мира СУБД.


Ну-ну... Отнюдь не далекого, не говоря уж о том, что я свою псевдо-СУБД писал

>"Показ плана запроса" не скажет тебе, какие индексы нужно поставить, и какие агрегатные таблицы нужно создать. Но без просмотра плана запроса угадать способ ускорения практически невозможно. Точнее, опять же так: опытный DBA может "в уме" прикинуть план запроса, с учётом селективности тех или иных предикатов, и еще много чего. Но его опытность — не в чтении книжек Кайта и Дейта. А в том, что он гонял реальные запросы на реальных базах под профайлером, и многократно наблюдал как за тем, что делает оптимизатор, так и за тем, куда уходит производительность. Программерская интуиция — это всего лишь кэш для фактов; если ты не будешь получать факты, то никогда не научишься предсказывать производительность. Вот, к примеру, ты, со всем своим опытом разработки, совершенно бессилен представить себе тот факт, что "мёртвые" строки не влияют на производительность программы. И что большинство приходящих тебе в голову "оптимизаций" в C# или Java только ухудшат производительность. И это несмотря на то, что про это пишут во всех книжках. А вот если бы ты поработал над конкретной задачей с профайлером в руках, то накормил бы конвеер своего процессора фактами. И уже на их основе получил новую, улучшенную "интуицию", которая бы ошибалась гораздо реже.


Честно признаюсь, что в этих деталях я не специалист, а поэтому воздержусь от комментариев.
With best regards
Pavel Dvorkin
Re[47]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 08:20
Оценка:
Здравствуйте, gandjustas, Вы писали:

PD>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?

G>Да не нервничай, проверки-то все равно есть. А "всегда" или "не всегда" зависит уже от ОС и процессора.

Все, моих педагогических способностей больше не хватает . Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
вынести не в состоянии

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


Ну слава тебе господи. Можно все же, оказывается. А насчет затрат — см. мой тест немного выше.
With best regards
Pavel Dvorkin
Re[45]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 08:23
Оценка:
Здравствуйте, Serginio1, Вы писали:

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


PD>>Да, я так же понял, но проход по блокам есть... Я же не говорю, что он с ними делает, я лишь отмечаю, что он их просматривает.

S>Сначала он проходит по живым объекта, собирая информацию о их размещении и размере занимаемой памяти, потом сортирует по адресам и смотрит разницу между ближайшими адресами минус размер объекта.

Ну не знаю. Рихтер о сортировке не пишет. Но если даже это так, то это все равно некие затраты. Да еще соритровка.

Впрочем, дело не в этом. Посмотри, из-за чего весь разговор начался. Дескать, выделение памяти в упроавлеямой куче очень быстрое — так Антон мне заявил. Я с этим и не спорю, но удаление их будет намного менее быстрым — вот и все.
With best regards
Pavel Dvorkin
Re[48]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.06.09 08:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?

G>>Да не нервничай, проверки-то все равно есть. А "всегда" или "не всегда" зависит уже от ОС и процессора.

PD>Все, моих педагогических способностей больше не хватает . Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы

PD>вынести не в состоянии
Ты сильно привязываешь к конкретной архитектуре процессора и ОС (наверное потому что в других не ориентируешься).
Иммутабельность никак от процессора не зависит. Например разрабатывая интерпретатор байткода иммутабельность типов языка поможет тебе выкинуть ненужные проверки в своем интерпретаторе.

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

PD>Ну слава тебе господи. Можно все же, оказывается. А насчет затрат — см. мой тест немного выше.
Какой тест?
Re[44]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.06.09 08:41
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я до сих пор был уверен, что линейный просмотр есть линейный просмотр. Если есть другие алгоритмы линейного просмотра, давай их сюда. Пока что твое утверждение не опровергает Рихтера.

Ну вот раз не опровергает — значит не опровергает. Главное, что опровергает моё утверждение — это твоё необоснованное подозрение о том, что мёртвые строки создают какую-то нагрузку на GC. Нет, не создают.

PD>Но вообще-то С — подмножество С++. Ну пусть не совсем точное, но в основном да. Так что все, что говорилось про С++, можно отнести и к его подмножеству.

Ничего не понимаю. Каким образом ты собрался относить "всё, что говорилось" про std::string и про частичную специализацию шаблонов к С?

PD>Дело в том, что есть программисты разного рода. Ты относишься к тем, для кого программирование — это вызов методов (сам признался), а я к тем, для кого программирование — это написание (методов, функций, процедур).

Ты так говоришь, как будто это что-то плохое.

PD>Вот и вся разница .

Нет, никакой разницы нету. Ты точно так же вызываешь методы, и я точно так же методы пишу. Даже если ты пишешь на ассемблере, то это не "написание методов", а всего лишь набор вызовов определённых процедур на микрокоде. "Что наверху, то и внизу". Если я пишу "вызовы методов", то в рамках некоторого метода, который будут вызывать другие.

PD>Поэтому для меня все эти игры с геттерами, сеттерами, интерфейсами, паттернами и т.д. малоинтересны. Мне придумать надо, как сделать, а не как оформить. Придумаю — как-нибудь оформлю. А вот если не придумаю — нечего будет оформлять.

Это у тебя просто от недостатка кругозора. Всё программирование — как раз про оформление. Про перевод из одной нотации в другую.
Если тебя попросить написать высокопроизводительный HTTP-сервер для обработки сайта программистского комьюнити с посещаемостью в 40к пользователей в день — уверяю тебя, времени на раздумывания о "структурах и алгоритмах" в терминах C RTL у тебя не хватит. Это будет слишком низкий уровень абстракции. Грубо говоря, твой подход хорош там, где мы придумываем эффективный конвертер из UUEncode в Base64. Задача разработки сервера стоит на шесть уровней архитектуры выше; там думать о регистрах противопоказано.

S>>Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"?

PD>Просто примерно представить себе, что за код при этом получится.
Какой код? На каком языке?
PD>Это интуитивно, объяснить трудно.
А ты попробуй. Это называется "рефлексия" — попытка понять, каким образом ты понимаешь то, что понимаешь. Без неё достаточно сложно найти косяки в своём потоке рассуждений, и уж тем более их исправить. Ключевой момент — именно в том, о каком языке ты говоришь во фразе "примерно представить себе, что за код при этом получится". Этот язык полностью определяет твои способности как программиста. Это может быть последовательность вызовов WinAPI, или набор реляционных операторов, или цепочка трансформаций XML дерева, или последовательность HTTP-запросов. Ну, или там последовательность MOV AH, AL.

PD>Ну для этого сначала не мешает знать, что в Win32 это попросту невозможно .

Ок. Значит, Эрик писал именно про тебя:

Вследствие этого жизненного опыта, я иногда удивляюсь тому факту, что многие профессиональные программисты, похоже, имеют представления об управлении памятью, которые перестали соответствовать истине со времён «защищенного режима 80286».

http://blogs.msdn.com/ruericlippert/archive/2009/06/08/9723963.aspx

PD>Чтобы понимать, что такое файл подкачки, знать архитектуру виртуальной памяти совсем не надо. У меня достаточно знакомых непрограммистов, которые в общем, понимают, для чего он нужен, но про архитектуру ВП слыхать не слыхали, и не смогу я им ее объяснить

Но мы же не говорим про "вообще нужен", а про способность понять взаимоотношения некоторой конкретной программы с этим файлом.
PD>А вообще ВП делается примерно на одних и тех же принципах в любой архитектуре, ну разве что есть 2 варианта — страничный и сегментный.


PD>Слова, слова. Если речь идет о моем коде — да, я и отвечаю, я и анализирую. Если речь идет о чужой библиотеке, то это должен был сделать ее автор, у него код-то свой ? Если мне приспичит, и исходники есть, я могу за автора эту работу выполнить. В конце концов, и там код на С/С++, и здесь. Просто я своему коду доверяю, а тому — как знать. Сперва проверю на тестах.

И что именно ты проверишь?

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


PD>А все же, будь добр, разрули мне эту задачу с шестикратным циклом с помощью профайлера. Для тебя редко, а для меня это моя работа — не шестикратные циклы, конечно, а как сделать. Вот в данном случае — ответь прямо, какой из вариантов я должен был бы выбрать


PD>1. Написать 6-цикл, обнаружить с помощью профайлера, что основное время уходит на внутренний if (кстати, неужели я бы без профайлера бы не догадался

PD> ?) и потом улучшать — как ?
PD>2. Посидеть подумать, свести к 3-циклу и написать, после чего посмотреть с помощью профайлера, что там не совсем хорошо — может, к примеру, не лучшим образом внутренний оператор реализован.

PD>Так как же лучше ?

Лучше — вот так:
1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
3. Проверить её производительность
4. Если она уложилась в требования из п.1., идти делать следующую задачу.
5. Если нет, то тогда начать оптимизацию:
6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
7. Посидеть, подумать, и свести к 3-циклу
8. Перейти к п.3
Вот ссылка на более подробное описание методики: http://blogs.msdn.com/ericlippert/archive/2009/02/06/santalic-tailfans-part-two.aspx


PD>Ну-ну... Отнюдь не далекого, не говоря уж о том, что я свою псевдо-СУБД писал

Ну, тогда он должен быть тебе понятен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[49]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 09:59
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Дык гони его на пересдачу через деканатскую комиссию, делов то!


Так в комиссию меня же и включат!
With best regards
Pavel Dvorkin
Re[50]: Ну ты вообще многого не видишь... ;)
От: CreatorCray  
Дата: 11.06.09 10:02
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

CC>>Дык гони его на пересдачу через деканатскую комиссию, делов то!

PD>Так в комиссию меня же и включат!
Ну тогда соболезную.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[49]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 10:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

PD>>Все, моих педагогических способностей больше не хватает . Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы

PD>>вынести не в состоянии
G>Ты сильно привязываешь к конкретной архитектуре процессора и ОС (наверное потому что в других не ориентируешься).

После всех моих попыток тебе что-то объяснить я уже физически чувствую, что я ни в чем вообще не ориентируюсь .

G>Какой тест?


http://rsdn.ru/forum/flame.comp/3419879.1.aspx
Автор: Pavel Dvorkin
Дата: 08.06.09
With best regards
Pavel Dvorkin
Re[47]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 10:19
Оценка:
Здравствуйте, Serginio1, Вы писали:

S>Рихтер очень много пишет о достижимых объектах, поколениях информации о достижимых ссылках итд.

S>Влад в своей статье тоже неплохо все написал http://rsdn.ru/article/dotnet/GC.xml
Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.
. На самом деле основная работа это поиск достижимых объектов. Если мы не касаемся объектов в старших поколениях а в 0 поколении нет достижимых объектов, то указатель кучи просто сдвигается на ее начало. На самом деле очень много ньюансов где ГС очень хорош, а где и проседает по полной. Смотри в этой же статье насет врайт барьера, а так же не дефрагментируемые Лохи (старый опыт) итд. Все зависит от кокретных условий.


Да я и не спорю, оптимизировать здесь есть что, и что можно — уже, я полагаю, соптимизировано. Просто если выделить память можно действительно за o(1), то освободить за o(1) не удастся. Так или иначе, а от количества созданных объектов (или живых объектов, или свободных блоков или еще чего-то) это как-то зависеть будет просто в силу специфики задачи.
With best regards
Pavel Dvorkin
Re[48]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 11.06.09 10:33
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Да я и не спорю, оптимизировать здесь есть что, и что можно — уже, я полагаю, соптимизировано. Просто если выделить память можно действительно за o(1), то освободить за o(1) не удастся. Так или иначе, а от количества созданных объектов (или живых объектов, или свободных блоков или еще чего-то) это как-то зависеть будет просто в силу специфики задачи.

Я влез исключительно из за просмотра памяти. Проблемы фрагментации высших поколений я обсуждал в этой ветке, и ни заявляю, что все бесплатно в этом мире. Но ГС развивается, плюс на многопроцессорных машинах для него отдельный поток отвести можно. А уж копирование на современных процессорах и памяти как то неловко даже обсуждать.
Если стрингбуилдеры и SortedList существуют вместо сегментированных аналогов, и этих аналогов нет в библиотеках.
и солнце б утром не вставало, когда бы не было меня
Re[45]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 11.06.09 11:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>Я до сих пор был уверен, что линейный просмотр есть линейный просмотр. Если есть другие алгоритмы линейного просмотра, давай их сюда. Пока что твое утверждение не опровергает Рихтера.

S>Ну вот раз не опровергает — значит не опровергает. Главное, что опровергает моё утверждение — это твоё необоснованное подозрение о том, что мёртвые строки создают какую-то нагрузку на GC.

Хороши же твои утверждения, если их можно опровергнуть с помощью даже необоснованных подозрений!

>Нет, не создают.


Ладно, шут с ними.

PD>>Но вообще-то С — подмножество С++. Ну пусть не совсем точное, но в основном да. Так что все, что говорилось про С++, можно отнести и к его подмножеству.

S>Ничего не понимаю. Каким образом ты собрался относить "всё, что говорилось" про std::string и про частичную специализацию шаблонов к С?

А я что-то говорил про специализацию шаблонов ? Где ? И про string я говорил лишь, что ее не использую.

PD>>Дело в том, что есть программисты разного рода. Ты относишься к тем, для кого программирование — это вызов методов (сам признался), а я к тем, для кого программирование — это написание (методов, функций, процедур).

S>Ты так говоришь, как будто это что-то плохое.

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

PD>>Вот и вся разница .

S>Нет, никакой разницы нету. Ты точно так же вызываешь методы, и я точно так же методы пишу. Даже если ты пишешь на ассемблере, то это не "написание методов", а всего лишь набор вызовов определённых процедур на микрокоде. "Что наверху, то и внизу". Если я пишу "вызовы методов", то в рамках некоторого метода, который будут вызывать другие.

Какой-то набор малопонятных высказываний. Еще раз объясняю — вызов методов и вообще деление на методы для меня вопрос десятистепенной важности. Единственное исключение — рекурсия, там метод действительно выделять надо. В остальном я их выделяю только для некоторого структурирования и трачу на это 0.01% своего времени. Пришло в голову, что неплохо бы это отделить — вот тебе и метод. Пришло в голову, что здесь нужен цикл — на тебе for. Это все мимоходом.

PD>>Поэтому для меня все эти игры с геттерами, сеттерами, интерфейсами, паттернами и т.д. малоинтересны. Мне придумать надо, как сделать, а не как оформить. Придумаю — как-нибудь оформлю. А вот если не придумаю — нечего будет оформлять.

S>Это у тебя просто от недостатка кругозора. Всё программирование — как раз про оформление. Про перевод из одной нотации в другую.

Ну и на здоровье. Останусь со свои кругозором. После того, что я сделал, я могу спокойно считать, что моего кругозора было вполне достаточно, чтобы писать ПО.
А все же программирование — это не про оформление. Оформление — это не самое главное. Программирование — это решение задачи. Нахождение алгоритма и структуры данных.

Помнишь Вирта книгу "Алгоритмы + структуры данных == программы". И ни слова про оформление. Или тогда программирования не было ? Я думаю, что все же было. Вот к оформлению относились спокойнее.

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

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


S>Если тебя попросить написать высокопроизводительный HTTP-сервер для обработки сайта программистского комьюнити с посещаемостью в 40к пользователей в день — уверяю тебя, времени на раздумывания о "структурах и алгоритмах" в терминах C RTL у тебя не хватит. Это будет слишком низкий уровень абстракции. Грубо говоря, твой подход хорош там, где мы придумываем эффективный конвертер из UUEncode в Base64. Задача разработки сервера стоит на шесть уровней архитектуры выше; там думать о регистрах противопоказано.


Ничего ты не понял. Увы. При чем тут регистры ? Я тебе сто раз объяснял, что моей задачей было найти эффективное решение задачи, алгоритм. Возможно, для HTTP сервера я его не найду — не моя тематика все эти параллельные или псевдопараллельные запросы. Но в любом случае тот, кто его будет писать, должен сначала продумать механику таких запросов и т.д, иначе у него ничего не выйдет. Алгоритм то есть.

S>>>Вот это мне не вполне понятно. Что значит "во что такая конструкция выльется"?

PD>>Просто примерно представить себе, что за код при этом получится.
S>Какой код? На каком языке?

Да ни на каком. Я же говорю — интуитивно. Ну если очень хочешь — на ассемблере, но и это не совсем верно. Не о том речь. Вот пишу я и думаю — гм, вот тут вызов ядра, мне это не совсем нравится, нельзя ли без него или хоть пореже. Здесь побайтный проход — тоже не радость. Здесь... Вот и все. На языке C/C++ это хоть и видно, но нужно немного знать о том, во что это выливается. Вот и все, что я хотел сказать.

PD>>Это интуитивно, объяснить трудно.

S>А ты попробуй. Это называется "рефлексия" — попытка понять, каким образом ты понимаешь то, что понимаешь.

Чуть выше попробовал


PD>>Ну для этого сначала не мешает знать, что в Win32 это попросту невозможно .

S>Ок. Значит, Эрик писал именно про тебя:
S>

S>Вследствие этого жизненного опыта, я иногда удивляюсь тому факту, что многие профессиональные программисты, похоже, имеют представления об управлении памятью, которые перестали соответствовать истине со времён «защищенного режима 80286».

S>http://blogs.msdn.com/ruericlippert/archive/2009/06/08/9723963.aspx

Слушай, ты хоть разберись с основами. Кто писал

S>выделение массива данных размером в 5GB


Ты или нет ?

И в 4GB адресном пространстве, из которого 1 или 2 GB отнимает ОС, ты намерен создать массив в 5 GB ? Я за такие вещи студента с зачета выгоню!

Что же касается того примера, на который этот Эрик ссылается — с файл-мэппингом — поверь, мне это давным-давно известно, еще со времен книги Рихтера 199x года. Проецируемый файл может быть действительно 2^64 байт, только это файл, а не массив, поскольку на диске массивов все же нет, а есть файлы. А спроецировать кусок этого файла ты можешь размером максимум 2 GB (чуть меньше), это и будет массив. А потом, да, можно перепроецировать (освободить старый и аллоцировать новый) на другой кусок файла — будет иной массив, но тоже не более 2Gb. А больше одновременно -не выйдет!
С таким же успехом ты мог бы заявить, что коль скоро можно выделить 1Gb, то сделав это 100 раз, мы получим 100 Gb. Получим, верно, но в разные моменты времени, и каждый раз придется освобождать

Хоть Тб так выделяй

Кстати, плавающие окна я еще в PDP/11 видел.
И кстати, можно и без всяких мэппингов выделить память больше 4Gb одному процессу. Физической памяти, между прочим. Несвопируемой. И он будет ей владеть. И будет к ней иметь доступ. Но не одновременно ко всей .

PD>>Чтобы понимать, что такое файл подкачки, знать архитектуру виртуальной памяти совсем не надо. У меня достаточно знакомых непрограммистов, которые в общем, понимают, для чего он нужен, но про архитектуру ВП слыхать не слыхали, и не смогу я им ее объяснить

S>Но мы же не говорим про "вообще нужен", а про способность понять взаимоотношения некоторой конкретной программы с этим файлом.

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


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

S>

Ты знаешь, основные принципы ОС разработаны в 60-70 годы. Дейтела , например, почитай, если найдешь. И в части управления памятью ничего нового я до сих пор не заметил.

PD>>Слова, слова. Если речь идет о моем коде — да, я и отвечаю, я и анализирую. Если речь идет о чужой библиотеке, то это должен был сделать ее автор, у него код-то свой ? Если мне приспичит, и исходники есть, я могу за автора эту работу выполнить. В конце концов, и там код на С/С++, и здесь. Просто я своему коду доверяю, а тому — как знать. Сперва проверю на тестах.

S>И что именно ты проверишь?

А я разве собирался что-то проверять ? Я сказал, что ему доверяю, а проверять буду, правильно ли он работает

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


PD>>А все же, будь добр, разрули мне эту задачу с шестикратным циклом с помощью профайлера. Для тебя редко, а для меня это моя работа — не шестикратные циклы, конечно, а как сделать. Вот в данном случае — ответь прямо, какой из вариантов я должен был бы выбрать


PD>>1. Написать 6-цикл, обнаружить с помощью профайлера, что основное время уходит на внутренний if (кстати, неужели я бы без профайлера бы не догадался

PD>> ?) и потом улучшать — как ?
PD>>2. Посидеть подумать, свести к 3-циклу и написать, после чего посмотреть с помощью профайлера, что там не совсем хорошо — может, к примеру, не лучшим образом внутренний оператор реализован.

PD>>Так как же лучше ?

S>Лучше — вот так:
S>1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
S>2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
S>3. Проверить её производительность
S>4. Если она уложилась в требования из п.1., идти делать следующую задачу.
S>5. Если нет, то тогда начать оптимизацию:
S>6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
S>7. Посидеть, подумать, и свести к 3-циклу
S>8. Перейти к п.3

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


PD>>Ну-ну... Отнюдь не далекого, не говоря уж о том, что я свою псевдо-СУБД писал

S>Ну, тогда он должен быть тебе понятен.

Нет. Там хоть и псевдо-БД, но это лишь по характеру работы ее. Я никакие принципы создания БД там не использовал.
With best regards
Pavel Dvorkin
Re[50]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 11.06.09 11:51
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


PD>>>Все, моих педагогических способностей больше не хватает . Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы

PD>>>вынести не в состоянии
G>>Ты сильно привязываешь к конкретной архитектуре процессора и ОС (наверное потому что в других не ориентируешься).

PD>После всех моих попыток тебе что-то объяснить я уже физически чувствую, что я ни в чем вообще не ориентируюсь .

Это почти правда.

G>>Какой тест?

PD>http://rsdn.ru/forum/flame.comp/3419879.1.aspx
Автор: Pavel Dvorkin
Дата: 08.06.09

Прекрасно, а теперь напиши аллокатор для таких "констант" минимально дефрагментирующий память.
А потом подумай, что с иммутабельными типами эффект достигается без выкрутасов во время выполнения.
Re[46]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.06.09 13:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А я что-то говорил про специализацию шаблонов ? Где ? И про string я говорил лишь, что ее не использую.

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


PD>Какой-то набор малопонятных высказываний.

Не надо объяснять. Я всё прекрасно понимаю. Просто то, что ты называешь программированием — это очень-очень маленький кусочек большой картины. Но как только я пытаюсь тебе рассказать про остальные части картины и про их взаимосвязи, моя речь становится для тебя невразумительной. Ок, оставим.

PD>Помнишь Вирта книгу "Алгоритмы + структуры данных == программы". И ни слова про оформление. Или тогда программирования не было ? Я думаю, что все же было. Вот к оформлению относились спокойнее.

Ну, во времена Вирта придумывали, грубо говоря, кирпичи. Сейчас кирпичи уже более-менее придуманы. С точки зрения опытного производителя кирпичей, народ занимается непонятно чем.
PD>Конечно, если придумывать решение не надо, поскольку задача стандартная, то все иначе...
Ну почему же не надо. Я тебе еще раз намекаю на то, что если перед тобой поставить задачу спроектировать высокопроизводительное веб-приложение или даже веб-сервис, то ты встрянешь, несмотря на отсутствие каких-то сверхеъестествнных алгоритмических задач.
Там тоже думать надо — иначе бы мы не имели такого засилья откровенно неудачных веб-приложений.

PD>На мой взгляд многие необоснованно переносят принципы разработки web-приложений на программирование в целом.

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


PD>Ничего ты не понял. Увы. При чем тут регистры ? Я тебе сто раз объяснял, что моей задачей было найти эффективное решение задачи, алгоритм.

Прекрасно. Что ты называешь алгоритмом?

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

Есть, скажем так, определённый "язык" описания устройства веб-приложения. Адресное пространство там, структуры, всё такое. Это не конкретный язык программирования; это скорее неформальное описание того, на какие запросы и как должно отвечать приложение.
Основная задача проектировщика — придумать вот это "описание" так, чтобы оно реализовывало поставленную задачу. Потом нужно будет по этому описанию приложение создать — ну там, скажем, научиться эффективно вычислять last-modified-date для составного ресурса, и всё такое.
Это не алгоритм — в том понимании, как его приводят в словарях. Нет там никакой "finite sequence of instructions". Но от этого меньше программирования там не становится.

PD>Да ни на каком. Я же говорю — интуитивно. Ну если очень хочешь — на ассемблере, но и это не совсем верно. Не о том речь. Вот пишу я и думаю — гм, вот тут вызов ядра, мне это не совсем нравится, нельзя ли без него или хоть пореже. Здесь побайтный проход — тоже не радость. Здесь... Вот и все.

Воот. Есть язык-то! Не может человек думать без языка. Он не обязательно весь вербализирован — когда его вербализируешь, остаётся всего лишь один шаг до нотации. Но сам язык есть. Есть некие образы. И вот то, какие там образы, полностью определяет то, какие программы человек может написать. Не имеет смысла оперировать терминами "вызов ядра", "побайтный проход", при разработке БД. Зато имеет смысл оперировать терминами "loop join", "bookmark lookup". Понятно? Ты вот всё время пробуешь применять образы, выработанные для Pascal/C, к управляемой среде. А это не только бесполезно, но и вредно

PD>Чуть выше попробовал

Ну вот видишь. Главное, чтобы ты не встрял, как та сороконожка

S>>выделение массива данных размером в 5GB

PD>Ты или нет ?
Ты всё-таки прочитай Эрика. Это полезно. Научишься, к примеру, отличать понятие "выделить" от понятия "отобразить".

(*) Хорошо, я соврал. 32хбитная Windows ограничивает общее количество памяти процесса на диске 16ю терабайтами, а в 64хбитной лимит равен 256 Tб. Но нет никакой причины, по которой отдельный процесс не мог бы выделить несколько Гб, если хватает места на диске.


PD>А больше одновременно -не выйдет!

Аллоцировать одновременно можно значительно больше. Отмапить — нельзя. Учим матчасть.

PD>С таким же успехом ты мог бы заявить, что коль скоро можно выделить 1Gb, то сделав это 100 раз, мы получим 100 Gb. Получим, верно, но в разные моменты времени, и каждый раз придется освобождать

Нет. http://blogs.msdn.com/oldnewthing/archive/2004/08/10/211890.aspx

PD>И про взаимоотношения я тебе грамотному пользователю смогу объяснить. Напрмер, пользователю Фотошопа. Канва простая — картинки большие, места не хватает, а ты хочешь их много, да одновременно, да еще всякие манипуляции, а это промежуточные картинки, ну вот Windows кое-какие куски их на диск и отправляет иногда, а потом обратно. И он вполне поймет.

Тем удивительнее то, что ты, к примеру, не понимаешь разницы между Allocate и Map.

PD>>>Так как же лучше ?

S>>Лучше — вот так:
S>>1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
S>>2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
S>>3. Проверить её производительность
S>>4. Если она уложилась в требования из п.1., идти делать следующую задачу.
S>>5. Если нет, то тогда начать оптимизацию:
S>>6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
S>>7. Посидеть, подумать, и свести к 3-циклу
S>>8. Перейти к п.3

PD>Нет уж, Антон, давай без общих советов. На тебе эту задачу и напиши план для нее.

У меня нет никакой задачи. Есть какой-то "шестикратный цикл", который непонятно откуда взялся, и непонятно что делает. Ты мне дай сначала саму задачу, а потом мы посмотрим, как её решать.

PD>Нет. Там хоть и псевдо-БД, но это лишь по характеру работы ее. Я никакие принципы создания БД там не использовал.

Ну, тогда мир СУБД от тебя далёк. Очень жаль — там есть крайне интересные вещи про оптимизацию производительности. Шибко помогает отвлечься от трактовки программирования как == алгоритмы + структуры данных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[69]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.06.09 13:44
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Ну да, и что? Ты думаешь, кого-то это смущает?

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

ГВ>Повторюсь: если мне не понравятся строки, то хай ANSI вместе XJ21 подавятся своим стандартом — я сделаю новые хранилища/манипуляторы строк и вся идеология C++ тут мне помощником.

Смелая гипотеза. Юношеский задор
Нет. Вся идеология С++ тут же гирей повиснет у тебя на ногах. Потому что в современном мире только редкие люди могут себе позволить писать без использования сторонних библиотек.
ГВ>Единственное место, где неизбежно придётся учитывать наличие ASCIIZ — строковые литералы, так их вообще, чем меньше — тем лучше. А сторонние API — это всегда сторонние API со своими приколами (CRT — тоже один из API).
Все приколы сторонних АПИ связаны именно с тем, что нет нормальной архитектуры.

ГВ>Хорошо, пусть проблема будет в контракте. Но и это не повод переносить недостатки контракта basic_string на весь C++. Если хочешь, давай отдельно поругаем контракт basic_string, я не против. Мне он тоже не во всём нравится.

Ишь, какой ты хитрый! Нет уж, хрен там. Это не я придумал вносить STL в стандарт языка. Поэтому я имею полное право критиковать "строки в С++" именно в том виде, в каком их предложил комитет. Или ты рассчитывал, что я буду обсуждать исключительно компилятор С++? Спору нет, компилятор в С++ просто прекрасен. Но без STL он даже не заработает.

ГВ>Кто тебе сказал такую глупость? Они будут интероперировать через промежуточные абстракции. Никто не мешает выполнять преобразование из rope к ASCIIZ в последний момент перед вызовом функции, требующей именно ASCIIZ. В чём прикол твоего утверждения о невозможности интероперабельности?

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

ГВ>Надо посмотреть, обещать ничего не могу, но, вроде бы, какая-то из реализаций STL выполняла преобразование к ASCIIZ по запросу c_str().

А что, не все реализации возвращают ASCIIZ по запросу с_str()???
Я тебе на всякий случай напомню, что это — небезопасная строка. На ее константность полагаться нельзя, т.к. по контракту std::string рушит этот буфер после первого же неконстантного вызова.

ГВ>Тройной одеколон вам в перегонку... С++-ники сопротивляются переносу оценки "УГ" по маршруту: std::basic_string -> C++ -> C++-ники. Не трещите так много про унылость "самих C++-ников" и C++ — и прекрасно услышите, как сами C++-ники ругают и ASCIIZ, и std::basic_string. Понимаешь? Вот не надо неправомерных обобщений и всё будет намного проще.

Я делаю обобщения совершенно правомерно. Показываю еще раз: std::basic_string, как и std::wstring — отстой. Это мы уже выяснили путём непросредственного сравнения. И проблема — не в конкретной реализации, а в том, что хреново спроектированы контракты этих классов.
Именно контракты являются частью стандарта С++, что даёт мне право говорить о том, что "строки в стандарте С++ — говно".

Про с++ников я такого не говорил, хотя люди, готовые закидать меня минусами только за то, что я повторяю банальную истину, вместо того, чтобы хоть на минуту о ней задуматься, доброго слова не заслуживают. Мне, собственно, всё равно — можете засунуть голову в песок хоть по пояс. Хороших строк в С++ от этого не появится.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: За что я не люблю С++
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 11.06.09 14:13
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вот что не ладно — какие альтернативы С++ можете предложить в ЕГО НИШЕ ? Вот представьте себе — исчез он. Чем замените ?


Eiffel (есть сравнивать сами языки, а не объем доступных библиотек).
Ada 2005 (она таки родилась, и даже бесплатные версии средств разработки выходят -- http://libre.adacore.com/libre/).


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[71]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.06.09 14:19
Оценка:
Здравствуйте, Cyberax, Вы писали:
C>Фигня эти строки. НАСТОЯЩИЕ пацаны пишут XML-парсеры с использованием SSE-инструкций — работает быстрее раз в 10, чем обычные парсеры.
Ну что ж, давай ссылку на эти НАСТОЯЩИЕ парсеры в студию. Будем мерить (правда, только через недельку — я в отпуск уезжаю).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[72]: Ну ты вообще многого не видишь... ;)
От: Cyberax Марс  
Дата: 11.06.09 14:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

C>>Фигня эти строки. НАСТОЯЩИЕ пацаны пишут XML-парсеры с использованием SSE-инструкций — работает быстрее раз в 10, чем обычные парсеры.
S>Ну что ж, давай ссылку на эти НАСТОЯЩИЕ парсеры в студию. Будем мерить (правда, только через недельку — я в отпуск уезжаю).
http://parabix.costar.sfu.ca/ (http://www.international-characters.com/product)

PS: "А что я? Я сама офигела" (с) анекдот.
Sapienti sat!
Re[46]: Ну ты вообще многого не видишь... ;)
От: Antikrot  
Дата: 11.06.09 14:45
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

G>>А кто будет знать? Дева мария или еще кто-то?

G>>Именно процессор и делает такие провеки.
PD>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?
ладно-ладно, а кто сказал что вообще включена страничная адресация? и таки опять же CR0.WP...
Re[71]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.06.09 15:16
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Нормальная — это какая? Список требований в студию!

Нет, они таки продолжают вилять тылом.

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

Ну, к примеру с того, что подсовывание стрингбуфера в своё время на порядок подняло перформанс компилятора Явы.

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

Мне всё равно, по каким причинам разработчики стандарта сделали его таким. Ну, то есть не всё равно — я читал, к примеру, Дизайн и Эволюцию, и историю вопроса представляю себе достаточно хорошо. Но это никак не отменяет того факта, что результат недостаточно хорош.
ГВ>И кроме того, стандарт в части core language проработан на порядок лучше, чем в части STL. И что мне теперь, сделать из STL икону только потому, что она под одной обложкой с core language?
А куда тебе деваться? Или ты готов объявить "языком C++" только то, что тебе нравится? Отлично. Ну так поздравляю — в твоём С++ недостатков вовсе нет. Потому что твоя позиция позволяет "не делать из них икону".

ГВ>Прости, я говорю об идеологии C++ core language, а не коктейля C++ core language + STL.

Прости, что такое "идеология core language"?
ГВ>Во-вторых, я не сказал, что откажусь от всего STL.
Да? Ты сразу перечисли то, от чего откажешься. Чтобы я знал, что критиковать нельзя.
ГВ>В-третьих, даже MFC в своё время не повисала гирей у меня на ногах. ЧЯДНТ?
Ты? Не сравниваешь с другими возможностями. Я, когда программировал на MFC, тоже не представлял себе, в чём там может быть проблема. Вот только это было десять лет тому назад, и с тех пор я узнал много нового. В том числе и о том, как важно для эффективной реализации построить хороший контракт.

ГВ>Да??? То есть не с десятилетиями предыдущей истории в которой было всё: от ограничений по объёму памяти до неразберихи с кодировками, а с тем, что сейчас изменились представления о нормальной архитектуре?

Да, представления изменились. Увы. Давайте теперь говорить, что ВАЗ 2101 — классная машина, потому что десятилетия назад это был ФИАТ.
Извини, с тех пор представления о "классной машине" немножко изменились. ВАЗ 2101 в этом не виноват. А вот те, кто упорно за него цепляется, отказываясь понимать преимущества инжекторного двигателя, коробки-автомата, кондиционера — виноваты.

ГВ>Хорошо, понятно. Говоря о строках в C++ ты имеешь в виду "строки, описанные в стандарте C++". Тут есть некоторая разница со "строками в C++", не находишь?

Да-да, можно еще и так попытаться выкрутиться. Ок. Давай тогда так: о чём ты говоришь, говоря о "строках в С++"?
Вот варианты:
1. Только строковые константы. STL — не часть языка, а core language ничего, кроме ASCIIZ, не умеет
2. Все стандартизованные строки, то есть std::string и ASCIIZ
3. Все классы строк, реально написанные в реальных фреймворках на основе C++: MFC, ATL, QT, etc.
4. Те классы строк, которые могли бы быть потенциально написаны на C++, если бы кто-то взялся за этот непосильный труд, и это имело какой-то практический смысл, с учётом объема легаси-кода, построенного на строках из п.3.
Я предлагаю пункт 2, но он тебе не подходит. Пункт 3, по какому-то неудачному стечению обстоятельств, тоже предлагает какое-то ужасное г. (по сравнению с CString, STL-ный вариант еще ничо). Опровергни меня, если я неправ.
Против пункта 4 я решительно возражаю: я тогда ему противопоставлю еще более потенциальные строки, которые могли бы быть написаны на гипотетической VM. Я говорил об имеющихся фактах, а не о сослагательном наклонении.


ГВ>Почему это он без STL не заработает?

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

Ты про type_info и xxxxx_cast, которые поддерживаются компилятором? Это микроскопический кусок STL. Зато ни один из известных мне компиляторов не порождает std::string заметив в тексте программы строковый литерал. И это, ИМХО, хорошо.
Это, имхо, плохо. Ну, то есть порождение std::string его бы, конечно, не спасло. Но и то, что он сейчас порождает, плохо. Потому что ASCIIZ-литералы лишены даже длины, что для современных строковых литералов недопустимо. Даже холлеритовские строки в фортране и то были лучше спроектированы (хоть и ужасно выглядели).

ГВ>Гы-гы. Так затраты на чтение из файла и на выдачу на экран с лихвой покрывают почти любую неэффективность преобразований (кроме того, из файлов читают линейные последовательности байтов, а не строки). Эффективные строки мне понадобятся, когда возникнет необходимость, например, оптимизировать операции модификации строк. Или когда строк окажется тыща мильёнов и понадобится разобраться с фрагментированием памяти. А в "типичных" программах потери на хранение и операции даже с такими строками, как std::wstring так же комичны, как тестирование StringBuilder на неэффективность.

А-а, ну-ну. Третий способ вильнуть, значит. Ок, производительность строк вообще никого не интересует. И это у нас, значит, позиция поклонников "самого эффективного в мире языка". Отлично. Можно, я буду ссылаться на этот пост всякий раз, когда кто-то будет гнобить С# за, к примеру, проверки на выход за границы массива?

ГВ>Вроде бы, не все хранят ASCIIZ. А возвращать должны все. То есть c_str() может неявно вызывать дополнительное распределение буфера под ASCIIZ-представление.

Может. Это она запросто.

ГВ>Ещё раз. В сравнении участвовала одна из реализаций STL. Проблемы контракта std::basic_string очень далеки от мутабельности/иммутабельности, если тебе это интересно.

Ок. Приведи хорошую реализацию wstring с тем же контрактом.

ГВ>Например, на мой взгляд, недостатком является засовывание методов find в сам класс строки. Даже не недостатком, а странностью: на фига он там, если есть итераторы?

Недостаток-недостаток. Это правда. Вообще, очень-очень многие фреймворки на C++ грешат злоупотреблением методами экземпляров.

ГВ>Ты постулируешь таким образом, что в рамках текущего контракта basic_string нельзя "порвать" StringBuilder? С чего ты взял?

Из опыта, который сын ошибок трудных.
ГВ>Вопрос только в степени наивности индукций о реализации, сделанных разработчиками данной версии STL на основе прочтения контракта. ИМХО — так.
В таком случае тебя, наверное, не затруднит "починить" данную версию STL так, чтобы она опередила управляемые строки, не изменяя контракта. С потокобезопасностью, всё такое.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[47]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 15.06.09 06:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


PD>>А я что-то говорил про специализацию шаблонов ? Где ? И про string я говорил лишь, что ее не использую.

S>Зато я говорил про специализацию шаблонов. Впрочем, это неважно. Как я понимаю, с С++ ты просто достаточно плохо знаком — либо я неправильно понимаю твои высказывания.

Ну вот, теперь я уже и с С++ плохо знаком. Как мне при этом удается писать эффективные программы — одному богу ведомо

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


Если по-твоему это не может быть правдой — это еще не значит, что твое высказывание есть правда. Но хватит на эту тему.


PD>>Какой-то набор малопонятных высказываний.

S>Не надо объяснять. Я всё прекрасно понимаю. Просто то, что ты называешь программированием — это очень-очень маленький кусочек большой картины. Но как только я пытаюсь тебе рассказать про остальные части картины и про их взаимосвязи, моя речь становится для тебя невразумительной. Ок, оставим.

Возвращаю мяч на твою половину. То, что ты считаешь программированием (web-программирование) — это маленький кусочек большой картины. И перенесение его принципов на все остальное выглядит довольно-таки несерьезно. А вот это ты и не хочешь понять.

PD>>Помнишь Вирта книгу "Алгоритмы + структуры данных == программы". И ни слова про оформление. Или тогда программирования не было ? Я думаю, что все же было. Вот к оформлению относились спокойнее.

S>Ну, во времена Вирта придумывали, грубо говоря, кирпичи. Сейчас кирпичи уже более-менее придуманы. С точки зрения опытного производителя кирпичей, народ занимается непонятно чем.



А посерьезнее у тебя аргументов не найдется ? Кирпичи или не кирпичи — но все же, тогда программы писали или нет ? И если все же писали — как же без паттернов и геттеров обходились, а также без интерфейсов ?

PD>>Конечно, если придумывать решение не надо, поскольку задача стандартная, то все иначе...

S>Ну почему же не надо. Я тебе еще раз намекаю на то, что если перед тобой поставить задачу спроектировать высокопроизводительное веб-приложение или даже веб-сервис, то ты встрянешь, несмотря на отсутствие каких-то сверхеъестествнных алгоритмических задач.

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


S>Там тоже думать надо — иначе бы мы не имели такого засилья откровенно неудачных веб-приложений.


А кто говорил, что так-таки думать не надо. Вот дали бы тебе спроектировать msdn.microsoft.com — я бы посмтотрел, как бы ты, не думая, начал его писать. Ну а когда речь идет о сайте третьего заборостроительного завода имени четвертой пятилетке — чего там думать, делай, и вперед!

PD>>На мой взгляд многие необоснованно переносят принципы разработки web-приложений на программирование в целом.

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

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

PD>>Ничего ты не понял. Увы. При чем тут регистры ? Я тебе сто раз объяснял, что моей задачей было найти эффективное решение задачи, алгоритм.

S>Прекрасно. Что ты называешь алгоритмом?

Ну вот, не хватает еще флейма на тему, что такое алгоритм. Почитай где-нибудь сам.

S>Есть, скажем так, определённый "язык" описания устройства веб-приложения. Адресное пространство там, структуры, всё такое. Это не конкретный язык программирования; это скорее неформальное описание того, на какие запросы и как должно отвечать приложение.

S>Основная задача проектировщика — придумать вот это "описание" так, чтобы оно реализовывало поставленную задачу. Потом нужно будет по этому описанию приложение создать — ну там, скажем, научиться эффективно вычислять last-modified-date для составного ресурса, и всё такое.
S>Это не алгоритм — в том понимании, как его приводят в словарях. Нет там никакой "finite sequence of instructions". Но от этого меньше программирования там не становится.

Я и не спорю, есть там свои задачи.

S>Воот. Есть язык-то! Не может человек думать без языка


. Привет от т. Сталина.

> Он не обязательно весь вербализирован — когда его вербализируешь, остаётся всего лишь один шаг до нотации. Но сам язык есть. Есть некие образы. И вот то, какие там образы, полностью определяет то, какие программы человек может написать. Не имеет смысла оперировать терминами "вызов ядра", "побайтный проход", при разработке БД. Зато имеет смысл оперировать терминами "loop join", "bookmark lookup". Понятно? Ты вот всё время пробуешь применять образы, выработанные для Pascal/C, к управляемой среде. А это не только бесполезно, но и вредно


Я уже устал повторять — не собираюсь я применять их к управляемой среде. Не собираюсь, понятно ? Я не принимаю эту управляемую среду именно за то, что к ней нельзя эти образы (коль уж такой термин тебе нравится, пусть так) применить. Именно поэтому она мне и не нравится.


S>>>выделение массива данных размером в 5GB

PD>>Ты или нет ?
S>Ты всё-таки прочитай Эрика. Это полезно. Научишься, к примеру, отличать понятие "выделить" от понятия "отобразить".


S>

S>(*) Хорошо, я соврал. 32хбитная Windows ограничивает общее количество памяти процесса на диске 16ю терабайтами, а в 64хбитной лимит равен 256 Tб. Но нет никакой причины, по которой отдельный процесс не мог бы выделить несколько Гб, если хватает места на диске.


PD>>А больше одновременно -не выйдет!

S>Аллоцировать одновременно можно значительно больше. Отмапить — нельзя. Учим матчасть.

Эту часть дискуссии я прекращаю. Заниматься демагогией на чисто техническую тему незачем. Если ты по-прежнему уверен, что в Win32 можно создать массив (а ты именно это утверждал) размером в 5 GB, добро пожаловать в форум Win API. Задай там вопрос , как это сделать, или выскажи свои соображения. Я обещаю не участвовать в дискуссии. Там найдется достаточно людей, которые тебе все объяснят, коль скоро ты в трех соснах запутался.

PD>>И про взаимоотношения я тебе грамотному пользователю смогу объяснить. Напрмер, пользователю Фотошопа. Канва простая — картинки большие, места не хватает, а ты хочешь их много, да одновременно, да еще всякие манипуляции, а это промежуточные картинки, ну вот Windows кое-какие куски их на диск и отправляет иногда, а потом обратно. И он вполне поймет.

S>Тем удивительнее то, что ты, к примеру, не понимаешь разницы между Allocate и Map.



Я вообще ничего не понимаю, из твоих высказываний это давно ясно. Ну и бог с ним.

PD>>>>Так как же лучше ?

S>>>Лучше — вот так:
S>>>1. Задать требования к производительности. Например, время, через которое программа должна выдать ответ.
S>>>2. Написать ту реализацию программы, которая кажется очевидной и простой в реализации
S>>>3. Проверить её производительность
S>>>4. Если она уложилась в требования из п.1., идти делать следующую задачу.
S>>>5. Если нет, то тогда начать оптимизацию:
S>>>6. Запустить профайлер и обнаружить, что всё время уходит на внутренний if
S>>>7. Посидеть, подумать, и свести к 3-циклу
S>>>8. Перейти к п.3

PD>>Нет уж, Антон, давай без общих советов. На тебе эту задачу и напиши план для нее.

S>У меня нет никакой задачи. Есть какой-то "шестикратный цикл", который непонятно откуда взялся, и непонятно что делает. Ты мне дай сначала саму задачу, а потом мы посмотрим, как её решать.

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

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

Чем быстрее — тем лучше. Точный ответ никто дать не может, заказчик его не знает. И предлагаю на эту тему не спорить. Если у тебя такие задачи, где задать требования всегда можно, то это еще не значит, что не бывает иной ситуации. У меня именно так — as maximum as possible.

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

Сделали 6-кратный цикл.

3. Проверить её производительность

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

4. Если она уложилась в требования из п.1., идти делать следующую задачу.

Пошел делать другую задачу.

А теперь продолжение.

Прошло 3 месяца. Заказчик сообщает, что , используя сей алгоритм еще в одном месте, он обнаружил, что работает все неприемлемо медленно. Обсуждение показало, что эту подзадачу он вызывает в некотором двойном цикле по другим параметрам. Я занят другой задачей в соответствии с п.4 твоих рекомендаций. Мне приходится бросить эту другую задачу и начать исправлять этот алгоритм. Если тебя такой подход устраивает — бога ради. Меня — нет.



PD>>Нет. Там хоть и псевдо-БД, но это лишь по характеру работы ее. Я никакие принципы создания БД там не использовал.

S>Ну, тогда мир СУБД от тебя далёк. Очень жаль — там есть крайне интересные вещи про оптимизацию производительности. Шибко помогает отвлечься от трактовки программирования как == алгоритмы + структуры данных.

"Нелья объять необъятное" (К. Прутков). В мире программирования есть много чего интересного...
With best regards
Pavel Dvorkin
Re[47]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 15.06.09 06:33
Оценка:
Здравствуйте, Antikrot, Вы писали:

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


G>>>А кто будет знать? Дева мария или еще кто-то?

G>>>Именно процессор и делает такие провеки.
PD>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?
A>ладно-ладно, а кто сказал что вообще включена страничная адресация? и таки опять же CR0.WP...

Если она не включена, то, очевидно, мы имеем дело с некоторой иной ОС, а там все, конечно, может быть иначе. Я это не обсуждал и не буду.
With best regards
Pavel Dvorkin
Re[42]: Ну ты вообще многого не видишь... ;)
От: Serginio1 СССР https://habrahabr.ru/users/serginio1/topics/
Дата: 15.06.09 06:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

S>>но с реализацией одинаковых интерфейсов.

WH>Одинаковые интерфейсы у изменяемых и неизменяемых структур данных просто сюр.
Зачем прямо уж сюр. Хотя Дали очень нравится. Если для неизменяемых структур метод возвращает новый объект, то для изменяемых
возвращается ссылка на сам объект. Распространнённая практика.
и солнце б утром не вставало, когда бы не было меня
Re[48]: Ну ты вообще многого не видишь... ;)
От: Antikrot  
Дата: 15.06.09 07:42
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>О господи! Ну прочитай же наконец про атрибуты страниц в страничном механизме. Пойми, что процессору все равно, куда писать — он транслирует вирт. адрес в физический через этот механизм, и если при этом атрибут страницы R/O, то возникнет исключение. А проверку эту он делает всегда. Всегда, понимаешь ?

A>>ладно-ладно, а кто сказал что вообще включена страничная адресация? и таки опять же CR0.WP...

PD>Если она не включена, то, очевидно, мы имеем дело с некоторой иной ОС, а там все, конечно, может быть иначе. Я это не обсуждал и не буду.


а как же:

Процессор будет или не будет делать проверки в зависимости от ОС — это мои слабые нервы
вынести не в состоянии

Re[51]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 15.06.09 07:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

PD>>После всех моих попыток тебе что-то объяснить я уже физически чувствую, что я ни в чем вообще не ориентируюсь .

G>Это почти правда.

Это просто правда — но только после объяснений с тобой.

G>>>Какой тест?

PD>>http://rsdn.ru/forum/flame.comp/3419879.1.aspx
Автор: Pavel Dvorkin
Дата: 08.06.09

G>Прекрасно, а теперь напиши аллокатор для таких "констант" минимально дефрагментирующий память.

Тот же самый, что и в .Net или в C++. Аллокатор не зависит от того, будем ли мы потом изменять объекты или нет. А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.

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


А ты подумай насчет того, что это можно применть к объектам любого типа, а не только к тем, что объявлены иммутабельными по типу.
With best regards
Pavel Dvorkin
Re: За что я не люблю С++
От: max-maxtor Россия www.rsdn.ru
Дата: 15.06.09 08:12
Оценка:
Здравствуйте, dmitry_npi, Вы писали:

_>Да нет, я-то сам его люблю. Случайно наткнулся на статью здесь.

_>Он не просто его, не любит, он его ненавидит. И других заразить пытается.
_>Вот, думаю, тролль Отличная приманка для священной войны.
Да всё ерунда пока я сам не напишу язык программирования так и придётся чем попало пользоваться.
Re[54]: Ну ты вообще многого не видишь... ;)
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 15.06.09 09:50
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


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


G>>>>>>Какой тест?

PD>>>Тот же самый, что и в .Net или в C++.
G>>Это принципиально разные аллокаторы, ты определись.

PD>Незачем мне определяться. Если речь идет о добавлении этой функциональности к C++, то и куча типа C++. Если к .Net — то и куча от .Net. Если к некоей мной системе — то ее куча.

Ну и каким образом это для С++ поможет? Как компилятор будет определять что поместить в "неизменяекмую кучу"?

PD>>>А почему для констант нужен какой-то аллокатор, минимально дефрагментирующий память (минимально по сравнению с чем ?) — не знаю. Просто 2 кучи — для констант и для переменных. Впрочем, не исключаю, что из факта неизменности объектов можно что-то выжать в плане оптимизации, так что эта куча может оказаться более эффективной. Обдумывать детали не буду.

G>>Так детали тут — самое интересное. Пока нету практического подтверждения полезности твоей теории все что ты говоришь — фуфло.

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

Так ты не смог доказать послезность своего подхода.

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

PD>>>А ты подумай насчет того, что это можно применть к объектам любого типа, а не только к тем, что объявлены иммутабельными по типу.
G>>Я то подуал, и пришел к мысли что нафиг оно не надо. Если компилятор и так будет анализировать неизменность объекта, то зачем лишние действия в рантайме?

PD>М-да... Хоть кол на голове теши... Ему объясняешь, что это может применяться к любым объектам — а он все за свое.

Покажи полезность этого.

PD>Ладно, все, с меня хватит.

Ну не сливай так быстро, момент истины близок.
Re[48]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 17.06.09 05:29
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну вот, теперь я уже и с С++ плохо знаком. Как мне при этом удается писать эффективные программы — одному богу ведомо


Шаман.
Вот приходят люди к бабке в деревню — врачи умные помочь не могут, а она помогает. Вопрос: как? Ответить не может. Но знает что нужно сделать
Re[48]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 17.06.09 05:37
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А посерьезнее у тебя аргументов не найдется ? Кирпичи или не кирпичи — но все же, тогда программы писали или нет ? И если все же писали — как же без паттернов и геттеров обходились, а также без интерфейсов ?


Да и без интернета, теле/видео, автомобилей люди как-то жили и все в порядке было. На лошадях ездили и не тужили.
Re[49]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 17.06.09 05:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Я уже устал повторять — не собираюсь я применять их к управляемой среде. Не собираюсь, понятно ? Я не принимаю эту управляемую среду именно за то, что к ней нельзя эти образы (коль уж такой термин тебе нравится, пусть так) применить. Именно поэтому она мне и не нравится.

WH>Этим ты выдал всю свою сущность.
WH>Ты не хочешь учится.
WH>А это значит что как профессионал ты уже мертв.

Это беда многих преподавателей и не только их.
Re[74]: Ну ты вообще многого не видишь... ;)
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 17.06.09 11:19
Оценка:
Здравствуйте, _d_m_, Вы писали:

Где здесь смайлик: "папа, ты с кем сейчас разговаривал?"
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[51]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 17.06.09 13:54
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".

___>Очень показательно, что ты привел в качестве этакого эталона это УГ
Если это УГ использовать аккуратно то оно очень не плохо живет и под нагрузкой.
НО в этом случае получается фактически своя БД поверх дискового движка этого УГ.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[51]: Ну ты вообще многого не видишь... ;)
От: Anton Batenev Россия https://github.com/abbat
Дата: 17.06.09 20:23
Оценка:
Здравствуйте, _d_m_, Вы писали:

_> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


Типа YouTube?
avalon 1.0rc1 rev 247, zlib 1.2.3
Re[52]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 17.06.09 20:43
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>То-то за яндексом (за narod-ом, вернее) уж давно закрепилась слава тормоза...

Я к народу не имею никакого отношения.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[54]: Ну ты вообще многого не видишь... ;)
От: kuj  
Дата: 17.06.09 23:06
Оценка:
Здравствуйте, Anton Batenev, Вы писали:


kuj>> _>> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


kuj>> AB>Типа YouTube?


kuj>> Как будто ютюб хранит ролики в майсикле.


AB>А что, подобный кретинизм стал отличительным признаком "чиста пацанских сайтов"? Речь шла про "моя первая пага". И эта... выдыхай...


Угу, и кто из нас спорит с тем, что майсикел не годится для "моя первая пага"? ;]

Сам выдыхай. ;]
Re[55]: Ну ты вообще многого не видишь... ;)
От: Anton Batenev Россия https://github.com/abbat
Дата: 17.06.09 23:51
Оценка:
Здравствуйте, kuj, Вы писали:

kuj> kuj>> _>> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


kuj> kuj>> AB>Типа YouTube?


kuj> kuj>> Как будто ютюб хранит ролики в майсикле.


kuj> AB>А что, подобный кретинизм стал отличительным признаком "чиста пацанских сайтов"? Речь шла про "моя первая пага". И эта... выдыхай...


kuj> Угу, и кто из нас спорит с тем, что майсикел не годится для "моя первая пага"? ;]


Ютуб — это "моя первая пага"?! Для моей первой паги годится. Для ютуба (который первой пагой не является) годится. Ну а хранить ролики в MySQL это тебе твой друг обкуренный чебурашка на ухо нашептал. Ты сейчас какой из тезисов оспорить-то пытаешься?
avalon 1.0rc1 rev 247, zlib 1.2.3
Re[52]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 18.06.09 02:34
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


___>>Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".

___>>Очень показательно, что ты привел в качестве этакого эталона это УГ
WH>Если это УГ использовать аккуратно то оно очень не плохо живет и под нагрузкой.

Ну-да, ну-да. Если конечно Google или там You tube — затраты на покупку комерческих СУБД наверное значительны, поэтому лучше потаратить на собственную разработку среднего слоя так сказать.

WH>НО в этом случае получается фактически своя БД поверх дискового движка этого УГ.


В том то и дело.
Re[56]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 18.06.09 02:36
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

kuj>> kuj>> _>> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


kuj>> kuj>> AB>Типа YouTube?


kuj>> kuj>> Как будто ютюб хранит ролики в майсикле.


kuj>> AB>А что, подобный кретинизм стал отличительным признаком "чиста пацанских сайтов"? Речь шла про "моя первая пага". И эта... выдыхай...


kuj>> Угу, и кто из нас спорит с тем, что майсикел не годится для "моя первая пага"? ;]


AB>Ютуб — это "моя первая пага"?! Для моей первой паги годится. Для ютуба (который первой пагой не является) годится. Ну а хранить ролики в MySQL это тебе твой друг обкуренный чебурашка на ухо нашептал. Ты сейчас какой из тезисов оспорить-то пытаешься?


Антоха, прекрати истерику. WolfHound все уже сказал, да и ты мне Америку не открыл. В ютубе мыскль савсем по другой причине.
Re[50]: Ну ты вообще многого не видишь... ;)
От: WFrag США  
Дата: 18.06.09 02:59
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы


Ты, наверное, даже не подозреваешь, насколько ты попал в точку Даже когда всё реализовано совершенно отвратно, на таких практически статических сайтах тупо накручиваются кеши ещё и с каким-нибудь ESI, и сайт работает на N порядков быстрее.

P.S. Делали нынешний сайт Опры По нагрузке это не microsoft.com, но посетителей тоже хватает.
Re[53]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 18.06.09 06:27
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Ну-да, ну-да. Если конечно Google или там You tube — затраты на покупку комерческих СУБД наверное значительны, поэтому лучше потаратить на собственную разработку среднего слоя так сказать.

Они на таких нагрузках не столько значительны сколько бесполезны.
Те даже если взять большую СУБД придется делать тоже самое.
А если не видно разницы зачем платить больше?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[57]: Ну ты вообще многого не видишь... ;)
От: Anton Batenev Россия https://github.com/abbat
Дата: 18.06.09 09:31
Оценка:
Здравствуйте, _d_m_, Вы писали:

_> Антоха, прекрати истерику.


Так ему, если не обламывать "приход", он и до столбов начнет доколупываться

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


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

Я согласен с утверждением о том, что среднестатистическая "LAMP пага" — это обычно звиздец на крыльях ночи, но так то же не вина мускуля (или оставшихся букв).
avalon 1.0rc1 rev 247, zlib 1.2.3
Re[51]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 19.06.09 07:05
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


PD>>Я учитЬся хочу, но только тому, что мне для работы годится. Например, CUDA — годится, поэтому я недавно ее и осваивал. .Net, VB, Python и прочие Хаскели — не годится, а поэтому мне на них время тратить незачем.

WH>Ты очень сильно ошибаешься.

Голословные утверждения особой ценности не представляют. У меня основное требование — скорость, второе — объем памяти. И всякие лишние действия мне ни к чему. Поэтому я вряд ли сильно ошибаюсь, тем более, что я и сам тестировал (.Net) и читал, что тут писали (другие системы).


PD>>Вот на это вы все и рассчитываете. Сделаем как-нибудь, работать все же будет (а кто спорит — будет!), а оптимизировать и не придется.

WH>Не как-нибудь, а так чтобы уложится в требования.

Вот именно. Интересное кино, между прочим. Вы тут одним из основных принципов выставили хорошую сопровождаемость. Не буду спорить. Иными словами, вы утверждаете, что хороший продукт должен быть легко модифицируем, адаптируем к новым условиям и т.д. Однако при этом как-то стыдливо подразумевается, что мол, если нужно добавить новую страницу на сайте или же даже внести изменения в его структуру — это мол, важно, а вот сделать так, чтобы он работал быстрее в 5 раз — это не так уж важно, мы же уложились в требования...
А ведь вы правы. Реально ваши задачи таковы, что от вас ускорить быстродействие в 5 раз не потребуют. Ну выросла компания в 2 раза, ну увеличилась нагрузка в 2 раза, ну замедлился ответ в 2 раза (а может, и не замедлился, было 5 посетителей в день, стало 10 , ну и ладно. А когда компания сильно разрастется, то выкинут они этот сатй на помойку и сделают новый.

Но не у всех такие задачи. Вот поэтому ты и неправ в общем случае.

PD>>О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы

WH> Я в недавнем прошлом работал в Яндексе старшим разработчиком.

Ты Яндексовый движок писал ? Или что-то к движку ?

WH>И именно так все и было. После того как сервис был написан его за пару дней разгоняли в сотни раз.


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

WH>Так что давай ты больше при мне не будешь заикаться про что-то вроде www.microsoft.com ибо как работает это самое что-то вроде я знаю неизмеримо лучше тебя.


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

PD>>А общие принципы я , конечно, знаю.

WH>Сомнительно.

На здоровье. Можешь сомневаться сколько тебе угодно. Имеешь полное право. Равно как и я вовсе не обязан тебе что-то доказывать.

PD>>Кстати, написан MySQL на чистом С. Из чего с неизбежностью следует, что нет там ни геттеров, ни сеттеров, ни интерфейсов, ни темплейтов , ни итераторов и вообще ничего из той кунсткамеры, без которой вы теперь жить не можете. И ничего — вполне себе живет и неплохо себя чувствует.

WH>Ну если использовать его только как дисковую подсистему

???

и делать свою БД поверх него то может и не плохо.

???


WH>Но шаг в сторону и приплыли.


Смею тебя заверить, что это далеко не так. Но, впрочем, не в этом дело. Он таков какой он есть. Но написан на С. Кстати, и MS-SQL и Oracle тоже не на C# написаны вроде бы, а это значит, что и при написании их вся та кунсткамера тоже не использовалась!
With best regards
Pavel Dvorkin
Re[52]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 19.06.09 07:27
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>>Я учитЬся хочу, но только тому, что мне для работы годится. Например, CUDA — годится, поэтому я недавно ее и осваивал. .Net, VB, Python и прочие Хаскели — не годится, а поэтому мне на них время тратить незачем.

WH>>Ты очень сильно ошибаешься.

PD>Голословные утверждения особой ценности не представляют. У меня основное требование — скорость, второе — объем памяти. И всякие лишние действия мне ни к чему. Поэтому я вряд ли сильно ошибаюсь, тем более, что я и сам тестировал (.Net) и читал, что тут писали (другие системы).

Вы действительно сильно ошибаетесь.

PD>Смею тебя заверить, что это далеко не так. Но, впрочем, не в этом дело. Он таков какой он есть. Но написан на С. Кстати, и MS-SQL и Oracle тоже не на C# написаны вроде бы, а это значит, что и при написании их вся та кунсткамера тоже не использовалась!

И тут Вы тоже ошибаетесь. В MSSQL2005 (и более новых) довольно прилично managed кода. К тому же, начиная с 2005 есть возможность создавать .NET хранимые процедуры, которые, как Вы должны понимать, гораздо эффективнее на ряде сценариев T-SQL, PL/SQL и т.п.
Re[58]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 19.06.09 08:40
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

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


AB>Я согласен с утверждением о том, что среднестатистическая "LAMP пага" — это обычно звиздец на крыльях ночи, но так то же не вина мускуля (или оставшихся букв).


Добро пожаловать в специальную ветку гнобления МуСкуля http://rsdn.ru/forum/flame.comp/3431970.aspx
Автор: avpavlov
Дата: 17.06.09

Вот там и выскажешься по существу.
Re[53]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 19.06.09 09:56
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Здравствуйте, Anton Batenev, Вы писали:


_>>> Ну мыскль та еще поделка. Балалайка для select from where a = b. Годится для сайта "моя первая пага".


AB>>Типа YouTube?


kuj>Как будто ютюб хранит ролики в майсикле.


Самое забавное, что похоже, именно так и есть(гугл поможет найти еще подтверждения). Для меня, кстати, это новость(я как-то не задумывался раньше, в чем гугл хранит видео), я и сам удивился.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[55]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 19.06.09 13:02
Оценка:
Здравствуйте, criosray, Вы писали:

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



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


C>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.


Возможно. У меня недостаточно инфы, чтобы подтвердить это, или опровергнуть.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[52]: Ну ты вообще многого не видишь... ;)
От: Anton Batenev Россия https://github.com/abbat
Дата: 19.06.09 13:42
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD> WH>И именно так все и было. После того как сервис был написан его за пару дней разгоняли в сотни раз.

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

Может, конечно, и не в сотни (в некоторых случаях вообще нужно "выжимать" десятые доли процента), но хорошо написанный сервис обычно хорошо разгоняется и, что немаловажно, масштабируется.
avalon 1.0rc1 rev 247, zlib 1.2.3
Re[51]: Ну ты вообще многого не видишь... ;)
От: drol  
Дата: 20.06.09 07:34
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>И сайт www.microsoft.com, уверяю тебя, делался точно так же.


Подтверждаю. Я лично участвовал в "делании" кусочка www.microsoft.com Вобщем одно только грамотное кэширование уже рулит неимоверно.
Re[53]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 20.06.09 09:17
Оценка:
Здравствуйте, Anton Batenev, Вы писали:

AB>Может, конечно, и не в сотни (в некоторых случаях вообще нужно "выжимать" десятые доли процента),

Это на большом поиске где уже выжали все что можно.
Причем там выжимают не только свой код но ОСь хачат...

AB>но хорошо написанный сервис обычно хорошо разгоняется и, что немаловажно, масштабируется.

Это да. Особенно хорошо разгоняется в момент когда он только написан и по нему еще не поездил танк.
А после танка уже мало что можно разогнать без очень серьезных усилий. Для того танк и нужен.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[50]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 20.06.09 10:19
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Вот на это вы все и рассчитываете. Сделаем как-нибудь, работать все же будет (а кто спорит — будет!), а оптимизировать и не придется. И чаще всего, ты прав, так и получается. У вас.. А у меня — ровным счетом наоборот.


PD>О чем я мечтаю — дали бы кому-нибудь из вас задачу разработать не сайт заборостроительной компании с 3 посетителями в сутки, а что-то вроде www.microsoft.com. Вот тогда бы я и посмотрел, как вы сначала сделали бы что-нибудь, а потом, когда время отклика станет измеряться минутами, начали улучшать с помощью профайлера. Интересное зрелище было бы


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

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

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

PD>Кстати, написан MySQL на чистом С. Из чего с неизбежностью следует, что нет там ни геттеров, ни сеттеров, ни интерфейсов, ни темплейтов , ни итераторов и вообще ничего из той кунсткамеры, без которой вы теперь жить не можете. И ничего — вполне себе живет и неплохо себя чувствует.


И?..
Re[55]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 02:53
Оценка:
Здравствуйте, criosray, Вы писали:

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


C>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.


Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.
Re[56]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 21.06.09 07:03
Оценка:
Здравствуйте, _d_m_, Вы писали:


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


C>>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.


___>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.


Хранить большое количество бинарной информации в таблицах БД? Удачи.
Re[57]: Ну ты вообще многого не видишь... ;)
От: hattab  
Дата: 21.06.09 08:30
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.


___>>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.


C>Хранить большое количество бинарной информации в таблицах БД? Удачи.


Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.
Re[57]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 08:58
Оценка:
Здравствуйте, criosray, Вы писали:

C>>>Ни один здравомыслящий dba не позволит хранить такие массивы бинарной информации в реляционной базе. Вероятнее всего хранятся они на обычной файловой системе, а в базе лишь ссылки на файлы.


___>>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.


C>Хранить большое количество бинарной информации в таблицах БД? Удачи.


Стереотипы, догматы, верим, поклоняемся, забываем — что ничто не вечно, все течет, изменяется...
http://blogs.technet.com/josebda/archive/2007/10/25/the-legend-of-the-single-multi-terabyte-replicating-sharepoint-database.aspx
http://www.rsdn.ru/forum/db/3038587.flat.aspx
Автор: megapoliss
Дата: 28.07.08
Re[58]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 09:14
Оценка:
Здравствуйте, hattab, Вы писали:

C>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


H>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?

Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?
Re[59]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 21.06.09 09:20
Оценка:
Здравствуйте, _d_m_, Вы писали:


C>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


H>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


___>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?


___>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?


По той ссылке, кстати, написано то, о чем я говорю:


1. First of all consider the cost of serializing the document/image into the blob.
2. Second think about timeouts and broken streams when retreiving larger datas that aren't quite one shot.
3. Third, your larger files will go from d/b to web server as 4 kb chunks and each chunk will require handshaking — too much overhead — you decide.
4. Fourth, What really guarantees that you will never run across an image > 50KB or document > 1 MB
5. Fifth, Sql server is gonna break the image/document up so it fits inside it's small small pages, and obviously it'll have to peice it together in a select query.

If I had to, I'd say keep small binaries in the database, and large binaries outside.



Надеюсь не нужно напоминать про размеры видеофайлов на ютюбе?
Re[59]: Ну ты вообще многого не видишь... ;)
От: hattab  
Дата: 21.06.09 09:23
Оценка:
Здравствуйте, _d_m_, Вы писали:

C>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


H>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


___>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?


Я рад за большинство СУБД, и про многофайловые базы мне рассказывать не нужно. К чему эта лирика?

___>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?


Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции). А в Firebird таки нет журнала транзакий, потому как он версионник.
Re[60]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 21.06.09 09:28
Оценка:
Здравствуйте, _d_m_, Вы писали:

C>>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


___>>>Стереотипы, догматы, верим, поклоняемся, забываем — что ничто не вечно, все течет, изменяется...

___>>>http://blogs.technet.com/josebda/archive/2007/10/25/the-legend-of-the-single-multi-terabyte-replicating-sharepoint-database.aspx
___>>>http://www.rsdn.ru/forum/db/3038587.flat.aspx
Автор: megapoliss
Дата: 28.07.08


C>>Нет, хранение бинарной информации больших объемов в БД совершенно неприемлимо. Мы говорим о терабайтах информации. Информации, которую не возможно практически кешировать (точнее возможно, но в ограниченном объеме). Нагрузка на базу будет колоссальной и совершенно неприемлимой.


___>

___>Ну ты бы ссылочки почитал для начала, прежде чем постить — там речь о терабайтах.
Я почитал. Не нашел ничего, что противоречило бы утверждению о том, что большие объемы бинарной информации хранить в БД крайне неэффективно.

___>Оттуда:

___>

>>>Подумай над возможностью хранить сами документы на файловой системе (FTP/HTTP/.. сервере), а в базе только ссылки на них.
M>>Имею глубокое убеждение, что блобам вобще не место в БД.

___>опана а пацаны в майкрофте об этом не знали и сделали самую большую базу изображений в мире — террасервер.


___>По теме:

___>http://www.terraserver.com/
И где доказательства, что бинарные данные там хранятся именно в файле(ах) БД?
Re[60]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 09:48
Оценка:
Здравствуйте, criosray, Вы писали:

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


C>>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


H>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


___>>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?


___>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?


C>По той ссылке, кстати, написано то, о чем я говорю:



C>

C>1. First of all consider the cost of serializing the document/image into the blob.
C>2. Second think about timeouts and broken streams when retreiving larger datas that aren't quite one shot.
C>3. Third, your larger files will go from d/b to web server as 4 kb chunks and each chunk will require handshaking — too much overhead — you decide.
C>4. Fourth, What really guarantees that you will never run across an image > 50KB or document > 1 MB
C>5. Fifth, Sql server is gonna break the image/document up so it fits inside it's small small pages, and obviously it'll have to peice it together in a select query.

C>If I had to, I'd say keep small binaries in the database, and large binaries outside.



Это где ваще? Немогу найти.

C>Надеюсь не нужно напоминать про размеры видеофайлов на ютюбе?


Нет. Зачем. Я вот напомню про террасервер. Вот еще, кстати:
http://msdn.microsoft.com/ru-ru/library/bb933993.aspx
Re[60]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 09:54
Оценка:
Здравствуйте, hattab, Вы писали:

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


C>>>>Хранить большое количество бинарной информации в таблицах БД? Удачи.


H>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


___>>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?


H>Я рад за большинство СУБД, и про многофайловые базы мне рассказывать не нужно. К чему эта лирика?


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

___>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?


H>Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции).


Тыдыщь! http://msdn.microsoft.com/ru-ru/library/bb933993.aspx

Доступ к транзакционной файловой системе
Новая встроенная функция, GET_FILESTREAM_TRANSACTION_CONTEXT(), возвращает лексему, представляющую актуальную транзакцию, с которой связан сеанс. Эта транзакция должна быть запущена, не прервана и не зафиксирована. Получение лексемы позволяет приложению связать потоковые операции файловой системы FILESTREAM с запущенной транзакцией. Эта функция возвращает значение NULL в случае отсутствия явно запущенной транзакции.

Прежде чем транзакция будет зафиксирована или прервана, все дескрипторы файлов должны быть закрыты. Если дескриптор остается открытым за пределами области действия транзакции, дополнительные операции чтения, применяемые к этому дескриптору, завершатся ошибкой; дополнительные операции записи, применяемые к этому дескриптору, будут выполнены успешно, но фактические данные не будут записаны на диск. Аналогичным образом, если работа базы данных или экземпляра компонента Database Engine завершается, все открытые дескрипторы становятся недопустимыми.


H>А в Firebird таки нет журнала транзакий, потому как он версионник.


А что и в оракле тоже нет журнала транзакций?
Re[61]: Ну ты вообще многого не видишь... ;)
От: hattab  
Дата: 21.06.09 10:06
Оценка:
Здравствуйте, _d_m_, Вы писали:

H>>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


___>>>Во первых, блобы хранить отдельно от табличных данных умеют большинство СУБД и я надеюсь, что не надо рассказывать про несколько файлов БД разнесенных на разные диски и прочее?


H>>Я рад за большинство СУБД, и про многофайловые базы мне рассказывать не нужно. К чему эта лирика?


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


FB в качестве примера, как там и написано . А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах

___>>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?


H>>Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции).


___>Тыдыщь! http://msdn.microsoft.com/ru-ru/library/bb933993.aspx

[skiped]

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

H>>А в Firebird таки нет журнала транзакий, потому как он версионник.


___>А что и в оракле тоже нет журнала транзакций?


хз. Я с Ораклом не работал, но версионникам журнал транзакций не нужен бай дизайн.
Re[56]: Ну ты вообще многого не видишь... ;)
От: Anton Batenev Россия https://github.com/abbat
Дата: 21.06.09 10:19
Оценка:
Здравствуйте, _d_m_, Вы писали:

_> Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.


"Никодим! Да тыж леший!"
Хотя, если не ограничиваться реляционными БД и файловую систему и аналоги тоже считать за БД...
avalon 1.0rc1 rev 247, zlib 1.2.3
Re[56]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 21.06.09 10:22
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.

Один простой вопрос: Раздавать ты это как будешь?
Если раздавать из файловой системы то ядро ОС может отправлять все прямо в сеть.
Из какой базы данных можно ядром ОС отправлять данные прямо в сеть?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[62]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 10:23
Оценка:
Здравствуйте, hattab, Вы писали:

H>>>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


H>FB в качестве примера, как там и написано . А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах


Косяк выделен жирным выше.

___>>>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?


Я стороник хранения в блобах! О чем и тут и распинаюсь. В ФС хранить — зло.

H>>>Выделенное говорит о том, что СУБД уже имеют транзакционность, а при работе с ФС ее придется прикручивать руками (не нужно мне рассказывать, что NTFS уже поддерживает транзакции).


___>>Тыдыщь! http://msdn.microsoft.com/ru-ru/library/bb933993.aspx

H>[skiped]

H>Я смотрю ты вообще мои слова не понимаешь... Я написал, что не нужно мне рассказывать о NTFS, которая уже поддерживает транзакции. Ключевое слово выделил.


А я тебе показал, что есть способ использующий достоинства обоих подходов — так сказать и на ель залезть, и жопу не поцарапать:
— целостность данных;
— в рамках транзакций;
— быстрота работы с ФС напрямую;
...

H>>>А в Firebird таки нет журнала транзакий, потому как он версионник.


___>>А что и в оракле тоже нет журнала транзакций?


H>хз. Я с Ораклом не работал, но версионникам журнал транзакций не нужен бай дизайн.


Есть в оракле журнал.
Re[57]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 10:29
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


___>>Не-не-не Дэвид Блэйн. Как раз лучше хранить все в БД. Если конечно, это не MySQL.

WH>Один простой вопрос: Раздавать ты это как будешь?
WH>Если раздавать из файловой системы то ядро ОС может отправлять все прямо в сеть.
WH>Из какой базы данных можно ядром ОС отправлять данные прямо в сеть?

MS SQL Server.
И в третий раз за сегодня:
http://msdn.microsoft.com/ru-ru/library/bb933993.aspx

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

Хранилище FILESTREAM объединяет компонент SQL Server Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе в виде файлов. С помощью инструкций Transact-SQL можно вставлять, обновлять, запрашивать, выполнять поиск и выполнять резервное копирование данных FILESTREAM. Интерфейсы файловой системы Win32 предоставляют потоковый доступ к этим данным.

Для кэширования данных файлов в хранилище FILESTREAM используется системный кэш NT. Это позволяет снизить возможное влияние данных FILESTREAM на производительность компонента Database Engine. Буферный пул SQL Server не используется, поэтому данная память доступна для обработки запросов.

Re[63]: Ну ты вообще многого не видишь... ;)
От: hattab  
Дата: 21.06.09 10:31
Оценка:
Здравствуйте, _d_m_, Вы писали:

H>>>>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


H>>FB в качестве примера, как там и написано . А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах


___>Косяк выделен жирным выше.


Мда... Расшифровываю для непонятливых: при хранении бинарников в БД мы получаем профит от того, что нам не нужно париться относительно транзакционности и обеспечения целостности. Так понятнее, или все еще считаешь, что я говорю о каком-то косяке FB?

___>>>>>Во вторых, как понимать выделенное — в чем отличие от храния файлов в ФС? Опять же про транзакции? Или в FB нет журнала транзакций, поэтому они не могут нормально сдалать блобы, и они этот косяк выдают за достоинство?


___>Я стороник хранения в блобах! О чем и тут и распинаюсь. В ФС хранить — зло.


Я тоже сторонник, об этом и написал...

H>>Я смотрю ты вообще мои слова не понимаешь... Я написал, что не нужно мне рассказывать о NTFS, которая уже поддерживает транзакции. Ключевое слово выделил.


___>А я тебе показал, что есть способ использующий достоинства обоих подходов — так сказать и на ель залезть, и жопу не поцарапать:

___>- целостность данных;
___>- в рамках транзакций;
___>- быстрота работы с ФС напрямую;
___>...

И нах ты мне это сказал? Я предупредил, что о транзакциях в NTFS мне рассказывать не нужно
Re[58]: Ну ты вообще многого не видишь... ;)
От: criosray  
Дата: 21.06.09 10:35
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Хранилище FILESTREAM объединяет компонент SQL Server Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе в виде файлов.


А я Вам о чем твержу?
Re[64]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 10:46
Оценка:
Здравствуйте, hattab, Вы писали:

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


H>>>>>>>Правильные БД (например Firebird), блобы хранят отдельно от табличных данных, посему никаких проблем это не вызывает, а профит в отсутствии необходимости обеспечивать целостность данных.


H>>>FB в качестве примера, как там и написано . А какой косяк, позволь осведомиться? Ты походу вообще не понял, что "отдельно от табличных данных" не означает в отдельных файлах


___>>Косяк выделен жирным выше.


H>Мда... Расшифровываю для непонятливых: при хранении бинарников в БД мы получаем профит от того, что нам не нужно париться относительно транзакционности и обеспечения целостности. Так понятнее, или все еще считаешь, что я говорю о каком-то косяке FB?


Ну так бы сразу и сказал. Я понял по другому: что FB не обеспечяивает целостность своих блобов

При раздельном хранении в БД и в ФС — гемор еще и с резервным копированием/восстановлении.
Re[59]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 21.06.09 10:50
Оценка:
Здравствуйте, criosray, Вы писали:

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


___>>Хранилище FILESTREAM объединяет компонент SQL Server Database Engine с файловой системой NTFS, размещая данные больших двоичных объектов (BLOB) типа varbinary(max) в файловой системе в виде файлов.


C>А я Вам о чем твержу?


Несколько о другом. О раздельном хранении в ФС и в БД. Кстати, ссылки приведенные мной — про MS SQL до версии 2008. Я за хранение блобов в БД, даже без FILESTREAM. Хотя файлстрим — самое оно.

С помощью инструкций Transact-SQL можно вставлять, обновлять, запрашивать, выполнять поиск и выполнять резервное копирование данных FILESTREAM.

Re[58]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 21.06.09 14:11
Оценка:
Здравствуйте, _d_m_, Вы писали:

WH>>Если раздавать из файловой системы то ядро ОС может отправлять все прямо в сеть.

WH>>Из какой базы данных можно ядром ОС отправлять данные прямо в сеть?
___>MS SQL Server.
___>И в третий раз за сегодня:
Те мелкософты таки признали проблему и начали хранить блобы в отдельных файлах...
Правда тут возникает еще один вопрос. Сколько будет стоить софт для объемов youtube?
Тем более что сделать это руками не так уж и сложно.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[61]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 22.06.09 01:48
Оценка:
Здравствуйте, criosray, Вы писали:

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


___>>Несколько о другом. О раздельном хранении в ФС и в БД.

C>Я говорил именно так: "ютюб скорее всего хранит ролики не в бд, а на файловой системе, а в бд только ссылки на файлы".

Я не знаю, что там и как в ютуб — здесь мы можем выдвигать только гипотезы. Делается ли резервное копирование роликов или нет — ХЗ
Может они взяли исходники MySQL и так их обработали, что там уже получился какой-нибудь ЮтубSQL с поправлеными косяками и специфичным функционалом типа МС-овского filestream.

___>>Кстати, ссылки приведенные мной — про MS SQL до версии 2008. Я за хранение блобов в БД, даже без FILESTREAM.

C>Это годится только для очень малых объемов бинарной информации.

Я тебе приводил ссылки про террабайтные базы шарепойнт, террасервер
Re[59]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 22.06.09 01:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Те мелкософты таки признали проблему и начали хранить блобы в отдельных файлах...

WH>Правда тут возникает еще один вопрос. Сколько будет стоить софт для объемов youtube?
WH>Тем более что сделать это руками не так уж и сложно.

Сделай запрос, узнай
Я думаю надо использовать лицензирование на процессор, а если учесть что при этом 1 многоядерник — это 1 лицензия, все может быть не так уж плохо.
Re[59]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 22.06.09 02:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Те мелкософты таки признали проблему и начали хранить блобы в отдельных файлах...


Так же было и с поддержкой версионности. Но за что мне нравится МС они могут предложить не просто такое же, а лучше. Например: read_committed_snapshot — смешанный режим. Версии строк создаются только тогда, когда транзакции пишут одни и те же строки.
Re[53]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 04:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

PD>>Голословные утверждения особой ценности не представляют. У меня основное требование — скорость, второе — объем памяти. И всякие лишние действия мне ни к чему. Поэтому я вряд ли сильно ошибаюсь, тем более, что я и сам тестировал (.Net) и читал, что тут писали (другие системы).

WH>Ты просто фантастически ошибаешься в том что тебе не надо это знать.

Что не надо знать ? Я же ясно сказал — я это тестировал (а стало быть знаю, пусть и не все) и определил, что это медленнее — для моих задач. Так что фантастически я не могу ошибаться. Даже если бы это было бы с той же скоростью — я бы ошибался, но не фантастически. Фантастически — если бы раза в 2-3-5 быстрее. Но это невозможно

WH>Все остальное оправдания собственной лени и невежества.


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

А впрочем, давай иначе. Пусть речь идет не о мне. Некий X делает те же заключения о управляемой среде. Ничего про этого X ты не знаешь, он здесь первый раз. Означает ли это, что он автоматически ленив и невежественен ? Означает ли это, что все, кто с твоим мнением в этой области не согласен, ленивы и невежественны ? Ad absurdum...


PD>>А ведь вы правы. Реально ваши задачи таковы, что от вас ускорить быстродействие в 5 раз не потребуют. Ну выросла компания в 2 раза, ну увеличилась нагрузка в 2 раза, ну замедлился ответ в 2 раза (а может, и не замедлился, было 5 посетителей в день, стало 10 , ну и ладно. А когда компания сильно разрастется, то выкинут они этот сатй на помойку и сделают новый.

WH>Ты даже не представляешь насколько ты не прав.

PD>>Но не у всех такие задачи. Вот поэтому ты и неправ в общем случае.

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

Супер! Поскольку о задаче ты не имеешь никакого представления, то это твое утверждение означает, что ты готов решить любую задачу, причем с блеском, да еще и неожиданным для меня способом! Ну и ну!

PD>>Ты Яндексовый движок писал ? Или что-то к движку ?

WH>Яндекс большой и движков там много.
WH>И таки да я писал движки которые живут в продакшене под нагрузкой.

Это не ответ. Являются ли эти движки (или их части) критическими по времени ? Та часть движка, которая обеспечивает CMS и используется один раз в день при внесениии каких-то изменений в систему, роли не играет.

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

WH>Обычные такие программисты.
WH>И пишут они правильно.

Супер! В общем , все ясно — "по этому вопросу есть два мнения, одно мое, другое неправильное"



WH>>>Ну если использовать его только как дисковую подсистему

PD>>???
WH>>>и делать свою БД поверх него то может и не плохо.
PD>>???
WH>Во-во как обычно полное не понимание того о чем вообще разговор... и еще говоришь что понимаешь как это все работает...

Точно, полное непонимание. До сих пор дисковой подсистемой называлось нечто иное.
With best regards
Pavel Dvorkin
Re[51]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 04:09
Оценка:
Здравствуйте, criosray, Вы писали:

C>Ваши проблемы в том, что Вы пишете приложения, которые либо слабо, либо и вовсе не поддаются рефакторингу


И еще как не поддаются! Незачем им и поддаваться, это же будет означать, что я их не лучшим образом написал
Но почему "проблемы" — не понял. Никаких проблем, просто задачи таковы.

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


Смею заверить, что участвовал я в разработке достаточно крупной системы и оптимизировал именно на этапе начального проектирования , правда, не всей системы, а своего куска — доступа к данным. И если бы я это не сделал, то меня бы, скорее всего, уволили, потому что именно для этого меня в этот проект и приняли.
With best regards
Pavel Dvorkin
Re[52]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 22.06.09 04:36
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Смею заверить, что участвовал я в разработке достаточно крупной системы и оптимизировал именно на этапе начального проектирования , правда, не всей системы, а своего куска — доступа к данным. И если бы я это не сделал, то меня бы, скорее всего, уволили, потому что именно для этого меня в этот проект и приняли.


Т.е. ты просто выполнял требования работодателя. Ну это несколько другое.
Re[53]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 04:41
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>не оправдывайся, ты как не знал ничего кроме С++, так и не знаешь. Хотя и насчет плюсов возникают сомнения.


Неужели ты думаешь, что я буду что-то тебе доказывать ?

G>Это ты неправ в общем случае, ибо если программа не выполняет требования, то она нафиг не нужна независимо от скорости её работы.

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

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

"Сила в словах у тебя есть, но ты их правильно расставить не можешь. Поэтому ты, Федя, в состоянии пропагандистом не быть"

(C) А. Райкин
With best regards
Pavel Dvorkin
Re[59]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.06.09 05:13
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Те мелкософты таки признали проблему и начали хранить блобы в отдельных файлах...
Нет. Микрософт признал проблему со скоростью линейного чтения из блобов. В связи с этим, они замутили Filestream, которые работают со скоростью файлухи, но через базу — т.е. обеспечивают ACID и прозрачность бэкапов.
То, какая там механика использована унутре — дело десятое. Совершенно неважно, создаётся ли отдельный файл для каждого блоба, или они выделяются блочно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[53]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 05:39
Оценка:
Здравствуйте, _d_m_, Вы писали:

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


PD>>Смею заверить, что участвовал я в разработке достаточно крупной системы и оптимизировал именно на этапе начального проектирования , правда, не всей системы, а своего куска — доступа к данным. И если бы я это не сделал, то меня бы, скорее всего, уволили, потому что именно для этого меня в этот проект и приняли.


___>Т.е. ты просто выполнял требования работодателя. Ну это несколько другое.


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

На самом деле я их не выполнил. Точнее, я их просто принял к сведению в качестве верхней планки. А делать решил на пределе своих возможностей, так, чтобы я мог сказать по крайней мере одно — "я сделал все, что мог, пусть другие сделают лучше". В итоге это оказалось в 95% случаев в несколько раз быстрее, чем он просил

Правда, такой подход имел один своеобразный эффект. Не то, чтобы неожиданный, я понимал, что таким дело может кончиться. Заказчик уверился, что я все могу , и на следующий раз, для другой задачи, прислал мне требования по времени, от которых у меня волосы дыбом стали — мне показалось, что такое невозможно, о чем я ему тут же и заявил. В ответ пришло — "постарайтесь все же сделать". Оказалось, что можно Правда, с помощью CUDA.
With best regards
Pavel Dvorkin
Re[60]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 22.06.09 06:24
Оценка:
Здравствуйте, _d_m_, Вы писали:

___>Сделай запрос, узнай

___>Я думаю надо использовать лицензирование на процессор, а если учесть что при этом 1 многоядерник — это 1 лицензия, все может быть не так уж плохо.
А зачем? Особенно если учесть что это решается бесплатным линуксом и несколькими сотнями строк кода?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[54]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 22.06.09 06:49
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Супер! Поскольку о задаче ты не имеешь никакого представления, то это твое утверждение означает, что ты готов решить любую задачу, причем с блеском, да еще и неожиданным для меня способом! Ну и ну!

Ты сам не раз говорил про числомолотилки.
Я это умею. Через одну из них прошло никак не меньше 50 миллионов изображений.
Причем умею применять в том числе волшебные методы...
Сейчас изучаю очередную магию на эту тему...

WH>>Яндекс большой и движков там много.

WH>>И таки да я писал движки которые живут в продакшене под нагрузкой.
PD>Это не ответ. Являются ли эти движки (или их части) критическими по времени ?
Прочитай выделенное.

PD>Супер! В общем , все ясно — "по этому вопросу есть два мнения, одно мое, другое неправильное"

Зеркало принести?

PD>Точно, полное непонимание. До сих пор дисковой подсистемой называлось нечто иное.

Дисковая подсистема это то что работает с дисками.
Можно конечно ручками но зачем?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[61]: Ну ты вообще многого не видишь... ;)
От: _d_m_  
Дата: 22.06.09 06:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


___>>Сделай запрос, узнай

___>>Я думаю надо использовать лицензирование на процессор, а если учесть что при этом 1 многоядерник — это 1 лицензия, все может быть не так уж плохо.
WH>А зачем? Особенно если учесть что это решается бесплатным линуксом и несколькими сотнями строк кода?

Если именно как filestream — вряд ли несколько сот строк.

С помощью инструкций Transact-SQL можно вставлять, обновлять, запрашивать, выполнять поиск и выполнять резервное копирование данных FILESTREAM.

Re[62]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 22.06.09 06:58
Оценка:
Здравствуйте, _d_m_, Вы писали:

WH>>А зачем? Особенно если учесть что это решается бесплатным линуксом и несколькими сотнями строк кода?

___>Если именно как filestream — вряд ли несколько сот строк.
___>

___>С помощью инструкций Transact-SQL можно вставлять, обновлять, запрашивать, выполнять поиск и выполнять резервное копирование данных FILESTREAM.

Ты не понял. Я такую систему писал.
Там правда язык описания транзакций был свой.
Но какое это имеет значение?

Если придется написать еще раз то я сделаю это еще более циничным методом.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[55]: Ну ты вообще многого не видишь... ;)
От: Pavel Dvorkin Россия  
Дата: 22.06.09 07:50
Оценка:
Здравствуйте, criosray, Вы писали:

PD>>На самом деле я их не выполнил.


C>Еще бы при таком неверном в корне способе разработки Вы их выполнили...


Еще бы при выдергивании половины фразы стоило с тобой дискутировать. Фразу до конца дочитай.
With best regards
Pavel Dvorkin
Re[60]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 22.06.09 08:12
Оценка:
Здравствуйте, Sinclair, Вы писали:

WH>>Те мелкософты таки признали проблему и начали хранить блобы в отдельных файлах...

S>Нет. Микрософт признал проблему со скоростью линейного чтения из блобов. В связи с этим, они замутили Filestream, которые работают со скоростью файлухи, но через базу — т.е. обеспечивают ACID и прозрачность бэкапов.
S>То, какая там механика использована унутре — дело десятое. Совершенно неважно, создаётся ли отдельный файл для каждого блоба, или они выделяются блочно.
Так я не понял можно на этот самый блоб натравить виндовый аналог sendfile?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[61]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 22.06.09 09:10
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Так я не понял можно на этот самый блоб натравить виндовый аналог sendfile?
Я так понял, что можно — прикручен режим доступа к ним из кернел моды.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[57]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 22.06.09 10:08
Оценка:
Здравствуйте, Anton Batenev, Вы писали:


AB>"Никодим! Да тыж леший!"


Жесткий оффтоп, но, блин, не знаешь, где можно найти этот мультик? Я в свое время все интернеты перекопал, не нашел .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[58]: Ну ты вообще многого не видишь... ;)
От: WolfHound  
Дата: 22.06.09 10:30
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Нет. Не расскажу. Есть на то причины

Боишься что перехвачу?
Или что нечем народ на форуме пугать будет?

PD>>>Ну что же, если это так, +1 тебе. Для задач этого рода, вполне допскаю, такой подход может и работать.

WH>>Оно для любых задач подходит.
PD>
Ты не лыбся. Про мелкософт.ком ты уже промазал. И со всем остальным при разборе полетов будет также.

PD>Лучше просто разберись, где файлы, где в/в, где драйверы, а где прикладные программы (в т.ч MySQL). А пока что ты, извини, ерунду говоришь.

Если говорить про классические ОС то единственная разница мжеду драйвером и MySQL это то что драйвер в нулевом кольце работает.
Или ты можешь назвать другое различие межу софтом и софтом?
А если посмотреть на ОС типа сингулярити то там разница будет еще более призрачной.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[59]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 22.06.09 13:14
Оценка:
Здравствуйте, Mamut, Вы писали:

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


E>> AB>"Никодим! Да тыж леший!"


E>> Жесткий оффтоп, но, блин, не знаешь, где можно найти этот мультик? Я в свое время все интернеты перекопал, не нашел .


M>Что за мультик, не знаю, но на http://multiki.arjlover.net/ нет?


По тому названию, что я помню("Ой-ё") — не находится. Подозреваю, что на самом деле, мультик называется как-то иначе. Основа сюжета в домике, где живут старик и старуха, причем домик стоит на пике горы, и спокойно переваливается то направо, то налево.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[59]: Ну ты вообще многого не видишь... ;)
От: Eugeny__ Украина  
Дата: 22.06.09 13:15
Оценка:
Здравствуйте, VoidEx, Вы писали:



E__>>Жесткий оффтоп, но, блин, не знаешь, где можно найти этот мультик? Я в свое время все интернеты перекопал, не нашел .


VE>Ссылку выше дали. Если вдруг забыли название, то вот


Так вот как он называется . Спасибо!
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Re[68]: Ну ты вообще многого не видишь... ;)
От: vdimas Россия  
Дата: 26.09.09 08:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Дети, STL и ASCIIZ — это единственные строки, стандартизованные в С++. И проблема у них — вовсе не в реализации. А в архитектуре, т.е. в том контракте, которым авторы наделили std::string. Сколько можно объяснять одно и то же? Вам показывают на пальцах: иммутабельные строки — эффективнее. Отдельный от них стрингбилдер — эффективнее. А вы опять за своё: "ой, так нечестно, ваши классы спроектированы под свои задачи". Конечно std::wstring неизбежно будет плодом компромиссов — потому что перед ней поставили противоречивые задачи.


Во-первых, я с трудом представляю себе пользу от иммутабельных строк в отсутствии GC. Не согласен?
Во-вторых, динамическое выделение памяти из стандартной кучи — не самое быстрое дело, GC в сравнении тратит на переаллоцирование гораздо меньше времени, так что не в реализации механики STL-строки дело, а в св-вах системного аллокатора, которым пользуюется алоокатор по-умолчанию.

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

S>Копец. Я уже семь раз написал на эту тему: самописанные строки не будут ни с кем интероперировать.


Да нет никакой жесткой завязки в библиотеках именно на std:string, через typedef все развязанно. И в большинстве сценариев достаточно реализовать в самописной минимальный интерфейс STL-строки ( метод c_str() ), чтобы получить полную интероперабельность.
Re[69]: Ну ты вообще многого не видишь... ;)
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.09.09 02:27
Оценка:
Здравствуйте, vdimas, Вы писали:

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

Сложно сказать. А разве модный C++ не позволяет сделать заведомо более эффективное управление памятью, чем тормозная сборка мусора?
V>Во-вторых, динамическое выделение памяти из стандартной кучи — не самое быстрое дело, GC в сравнении тратит на переаллоцирование гораздо меньше времени, так что не в реализации механики STL-строки дело, а в св-вах системного аллокатора, которым пользуюется алоокатор по-умолчанию.

V>Тут уже проскочило и не однажды, что можно в стандартную строку подставлять свои алокаторы. Народ писал аллокаторы, которые на порядки быстрее стандартных для определённых сценариев. Под каждый сценарий нужно применить наиболее подходящий аллокатор, и будет качественный результат.

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

V>Да нет никакой жесткой завязки в библиотеках именно на std:string, через typedef все развязанно. И в большинстве сценариев достаточно реализовать в самописной минимальный интерфейс STL-строки ( метод c_str() ), чтобы получить полную интероперабельность.

Пример в студию. Покажи, как сделать в самописанной иммутабельной строке полную интероперабельность с чем угодно. Ну вот хоть с парсером XML.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.10.09 19:58
Оценка:
Здравствуйте, doarn, Вы писали:

D>3. Нельзя объять необъятное, значительная часть запрошенных фичей эмулируется либо 1:1 (что чаще), либо с потерями в объеме кода ну максимум в два раза. Есть конечно вещи, которые толково не реализуются ну никак. Ну дык никто не будет спорить что язык придавлен грузом легаси и в общем-то на данный момент устарел. Но! Это еще не повод его демонизировать.


Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 22.10.09 20:05
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А вот что не ладно — какие альтернативы С++ можете предложить в ЕГО НИШЕ ? Вот представьте себе — исчез он. Чем замените ?


Определите его нишу, плиз.

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

PD>Тем, кому тут же хочется выдвинуть Java или C# — даю сразу полный отлуп. Я говорю только о той нише, где используется ИСКЛЮЧИТЕЛЬНО компилированный код, без всяких JIT и прочих огромных рантаймов.


А что, ниша языка определяется только типом его компиляции?

PD>Нет ему замены, господа.


Для тех кто только его знает — несомненно, нет.

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


Да, ничего не хочется. Потому и не используем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: За что я не люблю С++
От: dr.Chaos Россия Украшения HandMade
Дата: 23.10.09 16:09
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Если речь о компилируемых в иполнимый код, то пожалуй OCaml и D.

VD>Есть сомнения, что этим языкам плюсы сливают по полной?

Есть сомнения: у OCaml-а проблемы с concurrent GC, да и компиляторы под некоторые платформы не так уж хороши. У D с этим получше, но совместимости по исходным кодам с С++ нету . Да ИМХО D унаследовал кучу С++-шных проблем ещё и своих привнёс. Короче под не очень распространённые архитектуры (AIX) хрен найдёшь альтернативу на которую можно уговорить руководство.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[4]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 23.10.09 17:09
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Есть сомнения: у OCaml-а проблемы с concurrent GC, да и компиляторы под некоторые платформы не так уж хороши.

DC>У D с этим получше, но совместимости по исходным кодам с С++ нету .

А на что она нужна? Ну, как покажи мне хотя бы один востребованный АПИ который был бы только C++-ым?
Совместимости с С-апи выше крыши хватает.

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

DC>Да ИМХО D унаследовал кучу С++-шных проблем ещё и своих привнёс. Короче под не очень распространённые архитектуры (AIX) хрен найдёшь альтернативу на которую можно уговорить руководство.


Согласен, что Ди не идеал. Но по сравнению с С++ это манна небесная. И это при совершенно сопоставимых целевых нишах, способе компиляции и при близкой производительности.

Так что на надо про маргинальность или проблемы. Основная часть проблем в головах. Там засела одна ничем не обоснованная мысль которая вытесняет любые другие.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: За что я не люблю С++
От: metaprogrammer  
Дата: 24.10.09 11:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>А на что она нужна? Ну, как покажи мне хотя бы один востребованный АПИ который был бы только C++-ым?


LLVM
В особенности — CLang
Re[6]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.10.09 12:09
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ты волен считать, что сдуру или как-то еще. Это, кроме как для тебя, не так уж и важно.


Гы. Это все что ты говоришь не важно.

PD>Но язык, на котором столько написано, маргинальным быть не может по определению.


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

PD>>> Маргинальные в моем определении не значит плохие, а просто пока не употребляемые в реальном мире.


Для этого есть более подходящий термин — непопулярные.

PD>Ты прекрасно понял, что я имею в виду, а поэтому не стоит заниматься играми в дефиниции.


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

VD>>Ну, так загляни в угол экрана. На дворе идет конец первого десятилетия нового тысячалетия.

VD>>Здоровые люди плюсы используют все реже и реже. Его популярность неуклонно падает.

PD>Не похоже.


Гы-гы.

PD>Скорее так — появились новый области, где С++ никогда и не использовался всерьез. Например, в Интернете — не считать же серьезным использованием CGI или ISAPI.


Ага. Не стоит считать серьезным использование С++ там где всегда использовался только С.

PD> А больше ничего и не было. И в этой области его как не было, так и нет. А где он есть — я уже писал.


То что ты глаза от пола не хочешь оторвать еще не значит, что ничего вокруг не происходит.
Корпоративное ПО давно ушло от С++ и даже Дельфи. Сейчас там царствуют ява и дотнет.
Серверный софт разрабатываемый с нуля тоже пишется в основном на управляемом коде. Погляди хотя бы на бизтолк.
Рынок массового софта более консервативен. Но и он потихонечку прогибается. Скоро, если захочешь использовать VC++, то тебе придется писать С++-код в среде на 90 написанной на управляемых языках.
Верефицирующие компиляторы для С тоже пишут на управляемых языках. Так что скоро С-шные драйверы будут проверены F#-ом и Немерле.

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


PD>Ну кто кого тут рвет — из твоей фразы понять невозможно. То ли С рвет С++, то ли кто-то еще рвет кого-то еще...


Опять не хочешь слышать то что тебе говорят.

VD>>Сказки про десктоп и редакторы уже порядком надоели. Только совсем отсталый человек сегодня начнет разрабатывать новый десктопный софт на плюсах.


PD>Ну-ну...


Что "Ну-ну"? Ты VC используешь? Ну, так или завязывай, или приготовься, что IDE для него на шарпе будет написана.

VD>>Так что их удел — низкоуровневые оптимизации


PD>Именно. И там им конкурента нет.


Ну, как же? С отличный конкурент в этой области.
Ди тоже вряд ли уступит.

>>дрова для стремительно устаревающих ОС


PD>Wiindows и Linux , без которых твой любимый .Net существовать не может.


Он не то что любимый. Он шаг в почти правильном направлении.
Что дло Виней и Линей, то их сроки сочтены. Еще 10-15 лет и на помойку.

>>софт для бюджетных самрфонов и места где основной объем кода — это вызов C API.


PD>То есть все то, что использует средства ОС. Правильно.


Во как? Я грешным делом думал, что окромя чисто функциональных программ (т.е. сферофкоеней вакуумных) остальные все как одна используют сервисы ОС.
А оказывается — это прерогатива С++.

>>И во всех этих местах С за глаза хватило бы


PD>Особенно с твоей идеей насчет инкапсуляции. Чудный код получится.


А идея не моя. Твои любимые ОС с ее помощь написаны. Кстати, на том самом С в основном.
Си, кстати, я до сих пор уважаю, хотя язык конечно совершенно дырявый. Но в нем есть последовательность.

>>А с точки зрения удобства несомненно лучше применять Ди и ОКамл.


PD>Может и да, да ведь не используют же.


Дык посмотри в зеркало и скажи себе и своей лени спасибо.

PD>Вполне возможно. Ничего тут особенного нет, и плохого ничего нет. Придет время — настанет и пора, как один мой друг говорит. Поживем — увидим.


Пора уже настала. Просто многие до смерти ждут лучших времен.

PD>Ну может и "я работал в Windows" будет звучать так же. Не стоит пытаться предсказывать будущее, неблагодарное это дело.


Ничего. У меня это уже раз 5 получалось. С Нетварью и ВиньНТ было очень забавно. Меня так высмеивали, так высмеивали. А теперь нет ни Нетвари, ни тех кто смеялся. Все куда-то испарились.

PD>Да кто тебя заманивает ? Я — не буду ни за что. Судя по твоим постингам по С++, твое отсутствие в этом языке только желательно — меньше дилетантского кода будет.


Хамите, парниша. (с) Таким как ты про дилетантство помалкивать лучше.

PD>Не покупай Жигули и не программируй на С++. Лучше будет С++ и даже ВАЗу лучше будет.


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

PD>А как ты думаешь, зачем я это пишу ? Тебя переубедить ?


Да, кто же тебя знает? Ты иной раз такие вещи говоришь, что хот стой хоть падай.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 26.10.09 14:52
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Насчет нетвари угадать было несложно. Насчет NT — не понял. Чего нет, Windows NT ?


Это сейчас очевидно. А тогда (в 93-ем) я один супротив 10 весьма опытных и уважаемых программистов выступал. Мне потребовалось пару вечеров чтобы сделать вывод, что с выходом Windows NT судьба Netware решена, если конечно Новэл не поймет, что ориентироваться нужно не на одну поддержку локальных сетей, но и на рынок ОС для серверов приложений. В ответ были расплывающиеся по всему офису улыбки и рассказы о том, что они до времен когда NT вытеснит Netware не доживут.

PD>>>Да кто тебя заманивает ? Я — не буду ни за что. Судя по твоим постингам по С++, твое отсутствие в этом языке только желательно — меньше дилетантского кода будет.


VD>>Хамите, парниша. (с) Таким как ты про дилетантство помалкивать лучше.


PD>Лишь констатирую факт. Посмотри свои постинги по С++ — они чаще всего и не минусы, а смайлики вызывали.


Потрудись найти ссылки и пояснить свое мнение, раз так. Никто это твои слова — это нечто среднее между оскорблением и трепом базарной бабы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 27.10.09 04:49
Оценка:
Здравствуйте, VladD2, Вы писали:

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


PD>>Насчет нетвари угадать было несложно. Насчет NT — не понял. Чего нет, Windows NT ?


VD>Это сейчас очевидно. А тогда (в 93-ем) я один супротив 10 весьма опытных и уважаемых программистов выступал. Мне потребовалось пару вечеров чтобы сделать вывод, что с выходом Windows NT судьба Netware решена, если конечно Новэл не поймет, что ориентироваться нужно не на одну поддержку локальных сетей, но и на рынок ОС для серверов приложений. В ответ были расплывающиеся по всему офису улыбки и рассказы о том, что они до времен когда NT вытеснит Netware не доживут.



Пора эту дискуссию заканчивать. Еще раз для ясности

1. Я не считаю, что С++ — это на вечные времена. Я отчетливо вижу его недостатки. Я вполне согласен, что раньше или позже что-то придет на замену ему.
2. Я не знаю, что придет ему на замену, но это не будет управляемая среда. Это будет язык чисто компилируемый .
3. Я перейду на этот новый язык при двух условиях 1) на него перейдет мир и 2) я доживу.

PD>>>>Да кто тебя заманивает ? Я — не буду ни за что. Судя по твоим постингам по С++, твое отсутствие в этом языке только желательно — меньше дилетантского кода будет.



PD>>Лишь констатирую факт. Посмотри свои постинги по С++ — они чаще всего и не минусы, а смайлики вызывали.


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


Хм, а в чем же тут оскорбление ? В утверждении, что твои постинги по С++ вызывали смайлики ? Так это чистая правда, я прекрасно помню, о чем пишу, и рад бы найти ссылки, но увы

Поисковая система занята или временно недоступна.
DBG> errCode: 101

Так что как только вы поиск почините — приведу непременнно.
With best regards
Pavel Dvorkin
Re[10]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.10.09 13:45
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>1. Я не считаю, что С++ — это на вечные времена. Я отчетливо вижу его недостатки. Я вполне согласен, что раньше или позже что-то придет на замену ему.


Чтобы видеть все недостатки нужно хотя бы какую-то альтернативу попробовать.

PD>Хм, а в чем же тут оскорбление ? В утверждении, что твои постинги по С++ вызывали смайлики ? Так это чистая правда, я прекрасно помню, о чем пишу, и рад бы найти ссылки, но увы


Твой смех мало кого трогает. Многие недоразвитые вообще постоянно смеются. Не обращаться же внимание на всех смеющихся?
Вопрос в другом. Из твоих слов можно сделать вывод, что С++ я не знаю или знаю очень поверхностно. Вот это уже пункт 5 и вообще хамство. Так что папрашу (с).

PD>Поисковая система занята или временно недоступна.

DBG>> errCode: 101

PD>Так что как только вы поиск почините — приведу непременнно.


Попробуй так: site:rsdn.ru/forum/flame.comp Dvorkin
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 27.10.09 14:16
Оценка:
Здравствуйте, VladD2, Вы писали:


VD>Твой смех мало кого трогает. Многие недоразвитые вообще постоянно смеются. Не обращаться же внимание на всех смеющихся?


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

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


Итак, указание (кому бы то ни было) на то, что он не знает язык, есть хамство. Любому ? Или только тебе лично ?

>Так что папрашу (с).


И не проси.

VD>Попробуй так: site:rsdn.ru/forum/flame.comp Dvorkin


Нет уж, дождусь работы поиска здесь.
With best regards
Pavel Dvorkin
Re[12]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.10.09 17:43
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

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


А, ну-ну.

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


PD>Итак, указание (кому бы то ни было) на то, что он не знает язык, есть хамство. Любому ? Или только тебе лично ?


Это нарушение п. 5 правил данного форума. К тому же еще сочетающееся с клеветой.

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

Так что потрудись найти реальные доказательства своих слов или перестать нести чушь и нарушать правила форума.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: За что я не люблю С++
От: CreatorCray  
Дата: 28.10.09 09:40
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Ты лучше напомни нам сколько это было лет назад?
Потому как имею перед глазами реальные примеры людей, которые когда то писали на плюсах, но теперь пишут на шарпе несколько лет. Так вот из плюсов они не помнят уже почти ничего.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[14]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 28.10.09 16:10
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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

CC>Ты лучше напомни нам сколько это было лет назад?

А какая разница? Язык не менялся с 1998-го года. С творчество Александреску я успел познакомиться. Так что в области С++ я ничего не пропустил.
Естественно я не гуру в этом языке. Да и никогда не претендовал. Но если вдруг взбредет в голову, то и сейчас могу пойти в плюсовый форум и ответить на 90 вопросов там задаваемых.

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


Ну, мало ли какие там примеры у тебя есть?

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

Я думаю, что если бы мне сейчас пришлось бы вернуться к С++, то я был бы лучшим С++-программистом чем был тогда когда активно на нем программировал. Конечно на восстановление скилов пришлось бы потратить месяц-другой, но в итоге...

Дело в том, что качество программиста заключается отнюдь не в мастерском знании языка. Знание конечно важно. Без него никак. Но намного важнее умение проектировать ПО. Понимание технологий. Знание приемов решения тех или иных задач. Умение изучать чужой код. Умение отлаживать программы. А эти умения даются опытом. Причем не так важно что за язык ты используешь. Более того. "Другие языки" дают новое видение старых проблем. Человек освоивший ФП начинает по другому относиться к stl и boost-у. И по-другому их использовать (со знанием дела). Правда при этом он начинает понимать насколько примитивны и неудобны эти библиотеки и язык на котором они написаны. Но это уже обратная сторона медали.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.10.09 03:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Как что? С точки зрения Павла, человек, не сумевший увидеть неверно поставленную скобку — плохо знает язык.

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

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

ЗЫ

Да самое смешное, что я просто опечатался и нажал F5. А тему создал просто потому, что сам ржал минут пять увидав какая частота у процессор. Так что об узрел / не узрел даже говорить не приходилось.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.10.09 04:20
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

VD>>А на что она нужна? Ну, как покажи мне хотя бы один востребованный АПИ который был бы только C++-ым?


M> LLVM

M> В особенности — CLang

Серьезно? Вот психи. То-то я смотрю для ОКамла там обертку написали.

И как же его используют из других языков?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[26]: Ну ты вообще многого не видишь... ;)
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.10.09 04:34
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>Только троллишь тут в основном ты.


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

Тебе интересно почему я не привожу аргументов или не бросаюсь тебя убеждать как окружающие?
Это бесполезно. Пока ты сам не захочешь понять, то никто тебе не объяснит.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[24]: Ну ты вообще многого не видишь... ;)
От: VladD2 Российская Империя www.nemerle.org
Дата: 29.10.09 04:39
Оценка:
Здравствуйте, Erop, Вы писали:

E>Для чисел же мы не нуждаемся в NumberBuildere? Чем строки так сильно отличаются?..


Ты сам почти ответил на свой вопрос. Осталось только подумать в чем схожесть и в чем различие строк и чисел.
Потом можно помедитировать над тем в чем различие строк и массивов чисел.

Когда начнет появляться прозрение, то надо спросить себя зачем в С++ есть массивы фиксированной длинны и зачем классы вроде std::vector.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Ну ты вообще многого не видишь... ;)
От: Игoрь Украина  
Дата: 31.10.09 10:42
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Так и хочется спросить, а ты не живешь догмами? Со стороны не сильно заметно, правда последнее время я сюда редко захожу, может что-то и изменилось в этом королевстве. А я, конечно, живу догмами одного инструмента, только ничего, что на этом инструменте я уже года два ничего серьезного не писал? В основном вся разработка у нас сейчас идет под WPF/SL... Но мнение про StringBuilder у меня не изменилось — костыль, крайне неудобный костыль. Это все уже обсуждалось в этой ветке и повторяться не хочется, и введение в Java дополнительной имплементации строк через ропы — подтверждение тому, что реально есть проблемы со связкой String + StringBuilder.

VD>Тебе интересно почему я не привожу аргументов или не бросаюсь тебя убеждать как окружающие?

Нет, мне не интересно, мне просто скуШно, думаю, как и тебе.
Re[28]: Ну ты вообще многого не видишь... ;)
От: VladD2 Российская Империя www.nemerle.org
Дата: 02.11.09 16:22
Оценка:
Здравствуйте, Игoрь, Вы писали:

И>Так и хочется спросить, а ты не живешь догмами?


Стараюсь не жить, но конечно получается не всегда.

И>Это все уже обсуждалось в этой ветке и повторяться не хочется, и введение в Java дополнительной имплементации строк через ропы — подтверждение тому, что реально есть проблемы со связкой String + StringBuilder.


Что за роппы?
Что касается проблем, то ты их явно из пальца высосал.

VD>>Тебе интересно почему я не привожу аргументов или не бросаюсь тебя убеждать как окружающие?

И>Нет, мне не интересно, мне просто скуШно, думаю, как и тебе.

ОК
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: За что я не люблю С++
От: metaprogrammer  
Дата: 03.11.09 07:50
Оценка:
Здравствуйте, VladD2, Вы писали:

M>> LLVM

M>> В особенности — CLang

VD>Серьезно? Вот психи. То-то я смотрю для ОКамла там обертку написали.


Плохо смотришь. Там написали C wrappers для очень ограниченного подмножества функциональности LLVM. Эти врапперы постоянно отстают от развития С++-ной части кода, часто ломаются. OCaml и прочие биндинги строятся уже поверх Си, добавляя свои сложности.

Для CLang никаких Си-врапперов нет вообще.

VD>И как же его используют из других языков?


С трудом. И только очень небольшую часть возможностей.
Re[10]: За что я не люблю С++
От: metaprogrammer  
Дата: 03.11.09 08:11
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>2. Я не знаю, что придет ему на замену, но это не будет управляемая среда. Это будет язык чисто компилируемый .


Singularity видел?

PD>3. Я перейду на этот новый язык при двух условиях 1) на него перейдет мир и 2) я доживу.


Тю... Не понимаю такого подхода. Ещё более не понимаю тех, кто считает возможным использование одного единственного языка.
Re[11]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 03.11.09 08:43
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Singularity видел?


Видеть не видел, но мне WolfHound о ней уже столько раз говорил, что почти что и видел. Но это вроде ОС, а не язык ?

PD>>3. Я перейду на этот новый язык при двух условиях 1) на него перейдет мир и 2) я доживу.


M> Тю... Не понимаю такого подхода.


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

>Ещё более не понимаю тех, кто считает возможным использование одного единственного языка.


А разве я утверждал, что надо использовать именно один язык ? Вообще-то я знаю около десяти языков, одни лучше, другие хуже. Но для тех задач, которые я решаю , есть сейчас потенциально 2 языка — С++ и Паскаль. И не потому, что они хорошие, а другие хуже, а потому, что они компилируются в машинный код, а другие нет.
With best regards
Pavel Dvorkin
Re[13]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 03.11.09 09:42
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

Извини, но нет решительно никакого желания вести это флейм. Я уже десятки раз эти аргументы слышал и столько же раз отвечал. Если хочешь — поищи в моих постингах.
With best regards
Pavel Dvorkin
Re[16]: За что я не люблю С++
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.11.09 06:38
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ничего. Ада — хороший язык. У него масса преимуществ и только один недостаток — его нет, кроме как в МО США.


Так ADA language downloadпробовал делать?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: За что я не люблю С++
От: Юрий Жмеренецкий ICQ 380412032
Дата: 06.11.09 06:43
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD> Ада — хороший язык. У него масса преимуществ и только один недостаток — его нет, кроме как в МО США.


Таки есть: Who's Using Ada? Real-World Projects Powered by the Ada Programming
Re[16]: За что я не люблю С++
От: metaprogrammer  
Дата: 06.11.09 07:07
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

M>> Искать влом. Очень интересно, что же такое убойное можно вообще ответить на аргумент (странно, что только десятки раз услышанный, а не сотни), что Ада — компилируемый и низкоуровневый язык.


PD>Ничего. Ада — хороший язык. У него масса преимуществ и только один недостаток — его нет, кроме как в МО США.


Это как раз Паскаля нет, кроме как в некоторых особо диких регионах планеты. А Ада — есть, ещё как. Более того, она есть под все платформы, во всех разнообразных видах, есть и open source. Есть огромное количество специалистов на рынке труда. Есть десятилетия наработок. Есть литература. Как это "нет ады"?!?

Да и Фортран — есть он, очень даже есть. Нельзя говорить, что нет его, когда вот он, тут, с миллионами и миллионами строк постоянно поддерживаемого кода. Живее всех живых.
Re[13]: За что я не люблю С++
От: Игoрь Украина  
Дата: 06.11.09 07:30
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Всё, что я о ней знаю, весь мой опыт, просто кричит, что С++ — это всегда ОГРОМНЫЕ ПРОБЛЕМЫ. Никто другой столько не навредил, ни Fortran, ни PL/I, ни plain C, ни прочее, в реальной деятельности употреблявшееся.

Это из серии: трудное детство, скользкий подоконник? И почему мой опыт об этом не кричит? Кстати, можно расшифровать — какой такой вред нанес С++?

M> Примерчики можно? Кроме использования существующих C++ API. Я таких областей не знаю, при том, что знаю я очень много всякого разного.

C++ отлично подходит для околосистемных вещей, всевозможные системные сервисы, фильтры. Или, например, когда сам драйвер режима ядра пишется на С, а в пользовательском режиме обвязка с логикой пишется на С++. Управляемые языки здесь слишком громоздки и не достаточно предсказуемы. Эту нишу С++ занял с самого своего появления и никто его отсюда выбить пока не сумел.
Re[14]: За что я не люблю С++
От: metaprogrammer  
Дата: 06.11.09 07:39
Оценка:
Здравствуйте, Игoрь, Вы писали:

M>> Всё, что я о ней знаю, весь мой опыт, просто кричит, что С++ — это всегда ОГРОМНЫЕ ПРОБЛЕМЫ. Никто другой столько не навредил, ни Fortran, ни PL/I, ни plain C, ни прочее, в реальной деятельности употреблявшееся.

И>Это из серии: трудное детство, скользкий подоконник? И почему мой опыт об этом не кричит?

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

И> Кстати, можно расшифровать — какой такой вред нанес С++?


Самый разнообразный. Главная проблема C++-проектов в их неподдерживаемости. Главная проблема C++ как языка в практической невозможности его автоматизированного анализа. Он слишком мощный и разнообразный, это для промышленного языка недопустимо.

M>> Примерчики можно? Кроме использования существующих C++ API. Я таких областей не знаю, при том, что знаю я очень много всякого разного.

И>C++ отлично подходит для околосистемных вещей, всевозможные системные сервисы, фильтры.

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

И> Или, например, когда сам драйвер режима ядра пишется на С, а в пользовательском режиме обвязка с логикой пишется на С++.


Тем более — зачем тут C++ со всей его неуклюжей и бессистемной мощью?

И> Управляемые языки здесь слишком громоздки и не достаточно предсказуемы.


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

И> Эту нишу С++ занял с самого своего появления и никто его отсюда выбить пока не сумел.


Пытаться разбираться во вкусовых пристрастиях миллионов мух я не хочу. Мне достаточно того, что все они, в этой нише, имели превеликое множество проблем, вызванных неудачным выбором языка.
Re[17]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 06.11.09 07:50
Оценка:
Здравствуйте, Юрий Жмеренецкий, Вы писали:

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


PD>> Ада — хороший язык. У него масса преимуществ и только один недостаток — его нет, кроме как в МО США.


ЮЖ>Таки есть: Who's Using Ada? Real-World Projects Powered by the Ada Programming


Ну не надо же все понимать буквально . Я же не говорю, что ее вообще нет. Реально в мире ПО для рабочих станций ее крайне мало, если вообще есть. Зайди на любые сайты, где предлагают работу — сколько там С++, C#, Java, даже Питон или Перл — и сколько Ады ?
With best regards
Pavel Dvorkin
Re[18]: За что я не люблю С++
От: metaprogrammer  
Дата: 06.11.09 07:54
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

ЮЖ>>Таки есть: Who's Using Ada? Real-World Projects Powered by the Ada Programming


PD>Ну не надо же все понимать буквально . Я же не говорю, что ее вообще нет. Реально в мире ПО для рабочих станций ее крайне мало, если вообще есть.


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

PD> Зайди на любые сайты, где предлагают работу — сколько там С++, C#, Java, даже Питон или Перл — и сколько Ады ?


А это тем более не показатель. Вот если по CV поискать, то знающих Аду найдётся очень даже много. Так что проект на Аде никаких проблем с поддержкой иметь не будет.
Re[17]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 06.11.09 07:55
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Это как раз Паскаля нет, кроме как в некоторых особо диких регионах планеты.




>А Ада — есть, ещё как. Более того, она есть под все платформы, во всех разнообразных видах, есть и open source. Есть огромное количество специалистов на рынке труда. Есть десятилетия наработок. Есть литература. Как это "нет ады"?!?


http://rsdn.ru/forum/flame.comp/3592771.1.aspx
Автор: Pavel Dvorkin
Дата: 06.11.09


M> Да и Фортран — есть он, очень даже есть. Нельзя говорить, что нет его, когда вот он, тут, с миллионами и миллионами строк постоянно поддерживаемого кода. Живее всех живых.


А я разве говорил, что его нет ? Я, кстати, года три назад его стыковку с С делал. Не бесплатно . Но то, что я сказал в ссылке выше — и к нему относится.
With best regards
Pavel Dvorkin
Re[18]: За что я не люблю С++
От: metaprogrammer  
Дата: 06.11.09 08:01
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А я разве говорил, что его нет ? Я, кстати, года три назад его стыковку с С делал. Не бесплатно . Но то, что я сказал в ссылке выше — и к нему относится.


А я последние года три писал почти исключительно на Фортране и PL/I. Платно. Их тоже нет?
Re[19]: За что я не люблю С++
От: Pavel Dvorkin Россия  
Дата: 06.11.09 08:16
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> А я последние года три писал почти исключительно на Фортране и PL/I. Платно. Их тоже нет?


Как я понимаю, ты, устав от написания кода в последние три года исключительно на Фортране и PL/I, в последнюю неделю исключительно хочешь вызвать меня на интенсивный флейм на тему о языках. Еще раз — не хочу.
With best regards
Pavel Dvorkin
Re[20]: За что я не люблю С++
От: metaprogrammer  
Дата: 06.11.09 08:29
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

M>> А я последние года три писал почти исключительно на Фортране и PL/I. Платно. Их тоже нет?


PD>Как я понимаю, ты, устав от написания кода в последние три года исключительно на Фортране и PL/I, в последнюю неделю исключительно хочешь вызвать меня на интенсивный флейм на тему о языках. Еще раз — не хочу.


Флейм мне не интерестен. Мне просто неприятно, когда так цинично врут, что мол "нет ничего, кроме C++". Есть, до фига всякого разного. И бредовые аргументы про "а где же вакансии?" просто не котируются, именно в силу бредовости самого подхода к вопросу.

Вообще, занятная позиция — высказать бредовое утверждение, и отметать любые возражения как якобы "флейм". Трусливая позиция. Некрасивая.
Re[16]: За что я не люблю С++
От: metaprogrammer  
Дата: 06.11.09 08:35
Оценка:
Здравствуйте, Игoрь, Вы писали:

M>> Может, его просто маловато, или просто слишком в жизни везло? Я видел разные проекты, в диапазоне от плохих до кошмарных. Многие были весьма древними, и в таких обычно употреблялось сразу много языков. Самой проблемной частью было всегда то, что написано на C++.

И>Опыта более чем достаточно.

Не верю. Не может быть "более чем достаточно", и чтоб не было проблем с C++.

И>Во-первых, я не увидел ответа на свой вопрос. Ты утверждал о вреде, который нанес С++, я так и не понял в чем был вред?


Неподдерживаемость кода — это не вред?!? :-O

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


И всё равно на двадцать лет отстают от того, что есть, например, для Java.

И> Неподдерживаемость проекта — это скорее баг в организации процесса разработки, точнее в его отсутствии, и низкой квалификации программистов. Я и на С# видел такие проекты.


На C# эта проблема решаема. На C++ — нет. И если коду двадцать лет, то проблемы в нём будут обязательно. Кричать про "квалификацию" просто глупо. Невозможно сделать всё красиво в таких масштабах.

M>> А я так не считаю. Я думаю, что C++ абсолютно для таких вещей не подходит, есть гораздо лучшие и значительно более надежные и безопасные решения.

И>Ага, есть, но только не надежные и не безопасные.

Ну ну. Веруем?

M>>Тем более — зачем тут C++ со всей его неуклюжей и бессистемной мощью?

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

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

И>>> Управляемые языки здесь слишком громоздки и не достаточно предсказуемы.

M>> Ничем не обоснованное утверждение. Да и неуправляемых языков предостаточно, и многие для этих целей лучше подошли бы.
И>А твое типа обоснованное? ха-ха.

Естественно. Практикой обоснованное.

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

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

Проблемы начинаются не на машстабах hello world, естественно. Присылать миллион строк проблемного кода в студию, да?
Re[17]: За что я не люблю С++
От: Игoрь Украина  
Дата: 06.11.09 10:01
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Не верю. Не может быть "более чем достаточно", и чтоб не было проблем с C++.

С самим С++ проблемы были только в самом начале, когда я его сам не знал и другие вокруг меня его не знали. Потом я просто перерос этот уровень и сменил работу. Дальше были проблемы только с проектами, а не с языком. Да, были ужасные проекты на С++, но были ужасные и на php, и на С#/javascript.

И>>Во-первых, я не увидел ответа на свой вопрос. Ты утверждал о вреде, который нанес С++, я так и не понял в чем был вред?


M> Неподдерживаемость кода — это не вред?!? :-O

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


M> И всё равно на двадцать лет отстают от того, что есть, например, для Java.

То что отстают — да, но не стоит и преувеличивать.

M> На C# эта проблема решаема. На C++ — нет. И если коду двадцать лет, то проблемы в нём будут обязательно. Кричать про "квалификацию" просто глупо. Невозможно сделать всё красиво в таких масштабах.

Когда С# будет 20 лет, тогда и поговорим. Но уже сейчас поддерживать код, написанный на первой версии языка — удовольствие ниже среднего. Кстати, имел недавно опыт разработки под Silverlight 2.0, тоже в общем, удовольствие так се, правда дело не в языке и конечно явно лучше чем на javascript.
Я согласен, что С++ код даже 15 летней давности — еще та байда, но не стоит забывать, что тогда С++ еще только появился и не были выработаны best practices. С# код начала двухтысячных — говно еще то. Кстати! Есть у нас один проект, там есть два клиента — один на Java, другой на С++. Оба написаны в конце 90-ых. Разницы абсолютно никакой — что на Java код полное говно, что на С++.

M>>> А я так не считаю. Я думаю, что C++ абсолютно для таких вещей не подходит, есть гораздо лучшие и значительно более надежные и безопасные решения.

И>>Ага, есть, но только не надежные и не безопасные.
M> Ну ну. Веруем?
Нет, знаем. Пока не появятся ОС, где управляемость кода будет поддерживаться на всех базовых уровнях ОС, о замене неуправляемых языков управляемыми не может быть и речи.

M>>>Тем более — зачем тут C++ со всей его неуклюжей и бессистемной мощью?

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

M> Умелых рук в промышленных масштабах не бывает. И, да, сам C++ неуклюж независимо от квалификации программиста — язык нелеп, он заставляет простые вещи делать сложно.

А никто и не говорит, что С++ для простых вещей. Лепите формочки на С# Я тут, конечно, передернул, но каков аргумент — таков и ответ. "Умелые руки" — означает всего лишь знание инструмента. Ты считаешь, что такого не бывает? Представь себе бывает.

M> Естественно. Практикой обоснованное.

Если бы твое утверждение было обосновано практикой, то большинство системных процессов windows подгружало бы не msvcrt.dll, а какой-то fortran.dll. И я бы сейчас это сообщение набирал не из google chrome, написанного на С++, а из чего-то другого.
Re[17]: За что я не люблю С++
От: CreatorCray  
Дата: 09.11.09 12:24
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Не верю. Не может быть "более чем достаточно", и чтоб не было проблем с C++.

Своb верования ты уже озвучил. Вот только какое отношение это имеет к делу.

И>>Во-первых, я не увидел ответа на свой вопрос. Ты утверждал о вреде, который нанес С++, я так и не понял в чем был вред?

M> Неподдерживаемость кода — это не вред?!? :-O
В чем именно заключается такая тотальная неподдерживаемость любого С++ кода? Я так понимаю речь ты вёл о любом С++ проекте.

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

M> И всё равно на двадцать лет отстают от того, что есть, например, для Java.
Двадцать лет назад Java еще не было.

И>> Неподдерживаемость проекта — это скорее баг в организации процесса разработки, точнее в его отсутствии, и низкой квалификации программистов. Я и на С# видел такие проекты.

M>И если коду двадцать лет, то проблемы в нём будут обязательно.
Ну так и давай сравнивать С++ проект которому 20 лет и С# проект, которому тоже 20 лет.

И>>Ага, есть, но только не надежные и не безопасные.

M> Ну ну. Веруем?
Ты не вопросы веры решай а приведи пример обратного.

M>>>Тем более — зачем тут C++ со всей его неуклюжей и бессистемной мощью?

И>>Неуклюж не С++, а тот человек, который им пользуется. В умелых руках С++ вполне ничего.
M> Умелых рук в промышленных масштабах не бывает. И, да, сам C++ неуклюж независимо от квалификации программиста — язык нелеп, он заставляет простые вещи делать сложно.
Ну да, конечно

M> Проблемы начинаются не на машстабах hello world, естественно. Присылать миллион строк проблемного кода в студию, да?

Шли.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[19]: За что я не люблю С++
От: CreatorCray  
Дата: 09.11.09 12:24
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

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

M> Не верю. С C++ проблемы всегда. Он не может не создавать проблем, просто в силу низкоуровневости.
Ясно.
Если у тебя заведомо предвзятое отношение то о чем с тобой вообще можно вести разговор?

M> Хреновейше поддерживается. Достаточно посмотреть на любой крупный опенсорс-проект.

например на те, что написаны не на С++, ага.

M> На C++ легко поддерживаемых проектов нет.

-100

M> Недавно имел сомнительное удовольствие переводить код со старого синтаксиса managed C++ на новый — автоматом меньше половины получилось исправить, остальное только вручную.

Это ты претензии к МС предъявляй. МС++ это их творение.

M> Ну бред же! Зачем такой бред говорить?

И это говорит тот, кто порядком бреда написал в этой ветке.

M>Давно бы все выбросили C++ на помойку, где ему самое место, да легаси не позволяет.

Отучаемся говорить за всех.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[21]: За что я не люблю С++
От: CreatorCray  
Дата: 11.11.09 10:04
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M>>> Не верю. С C++ проблемы всегда. Он не может не создавать проблем, просто в силу низкоуровневости.

CC>>Ясно.
M> Тебе? Тебе ничего не ясно.
Мне с тобой всё ясно

CC>>Если у тебя заведомо предвзятое отношение то о чем с тобой вообще можно вести разговор?

M> У меня достаточно объективное отношение.
Да ты шо!!! Что то в глаза не бросается.

M>>> На C++ легко поддерживаемых проектов нет.

CC>>-100
M> Назови. Хоть один.
Называть не могу, но на нескольких таких работал лично.

M>>> Недавно имел сомнительное удовольствие переводить код со старого синтаксиса managed C++ на новый — автоматом меньше половины получилось исправить, остальное только вручную.

CC>>Это ты претензии к МС предъявляй. МС++ это их творение.
M> Претензии к C++ вообще. К его уродской грамматике.
А грамматика managed С++ к собственно С++ не имеет никакого отношения. Это microsoft extension.

M>Что, спорить будешь, что она уродская?!? Чтоб с этим спорить, надо быть уж совсем неадекватным.

Ты видимо еще на perl не писал. Так что у С++ еще нормальная грамматика.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: За что я не люблю С++
От: March_rabbit  
Дата: 12.11.09 08:54
Оценка:
Здравствуйте, metaprogrammer, Вы писали:

M> Не стоит предполагать, что я ничего не знаю о "реальной деятельности". Всё, что я о ней знаю, весь мой опыт, просто кричит, что С++ — это всегда ОГРОМНЫЕ ПРОБЛЕМЫ. Никто другой столько не навредил, ни Fortran, ни PL/I, ни plain C, ни прочее, в реальной деятельности употреблявшееся.

помнится, у НАСА спутник упал из-за синтаксической ошибки в программе на фортране
не помню подобного на других языках
Re[14]: За что я не люблю С++
От: Raz1k  
Дата: 20.11.09 07:36
Оценка:
Здравствуйте, March_rabbit, Вы писали:

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


M>> Не стоит предполагать, что я ничего не знаю о "реальной деятельности". Всё, что я о ней знаю, весь мой опыт, просто кричит, что С++ — это всегда ОГРОМНЫЕ ПРОБЛЕМЫ. Никто другой столько не навредил, ни Fortran, ни PL/I, ни plain C, ни прочее, в реальной деятельности употреблявшееся.

M_>помнится, у НАСА спутник упал из-за синтаксической ошибки в программе на фортране
M_>не помню подобного на других языках
Ну как же, в этом же виноват С++! =))
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.