Здравствуйте, gandjustas, Вы писали:
G>У гугла столько ресурсов, что они могуть ОС в машинных кодах написать. G>И если им будет надо — напишут.
Не понимаю я вот этого аргумента! Если они такие лохи, что всё делают неверно и неэффективно, то почему у них всё так хорошо?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gandjustas, Вы писали:
G>>>Если вы изначально занимаетесь быстротой кода, то вряд ли он будет нажедным и красивым. Наоборот — вполне. E>>Это всего лишь твоё неумение писать быстрый и качественный код... G>С чего ты взял?
С того, что знаю примеры быстрого кода, который сразу так и разрабатывался, как быстрый...
E>>Мне известны МНОГОЧИСЛЕННЫЕ контрпримеры, так что позволь не поверить твоему голословному утверждению... G>Уууу, а сколько мне известно примеров когда наступала попа из-за преждевременной оптимизации и раннего проектирования структур данных...
Не понимаю. Возможно проектирование выполнялось некачественно?
G>Быстры и красивый быввает очень редко. Это он может казаться красивым пока не надо какую-то мелочь поменять.
Почему это? Почему быстрый код нельзя писать НОРМАЛЬНО? Читабельно, поддерживаемо, без ребусов?..
G>С чего ты взял что я не знаю С++?
Я не думаю, что ты совсем не знаешь. Но ты тут оговорился, что якобы объект на стеке не может иметь виртуальных функций, но может быть ты именно оговорился, или это вообще не ты был?
В любом случае это не важно. Я не утверждал, что ты не знаешь, я спрашивал, что тебя заставляет выбирать С вместо С++, кроме его сложности (IMHO, если ты говоришь, что С++ сложен, то это значит, что ты его знаешь недостаточно, чтобы писать на нём хороший код)
G>А "нагруженные части" — те которые обрабатывают большой объем информации в единицу времени — для них C# подходит гораздо лучше.
Пока не нужна память и скорость -- да. Например для GUI ХиндиС -- это просто находка! G>Насчет быстрее можешь не верить, но современные языки спокойно сокращают в несколько раз время разработи по сравнению с C++.
А! Это было не про время исполнения, а про время разработки? Про время разработки верю конечно. Но только в том случае, если задача органична для C#. А если нет, то не верю.
Почти любая оболочка, например, органична. Многое из вебства поверх DB органично, ну и т. д.
А там AI, например, нифига не органичен...
G>>>И только там где не хватает производительности может быть использован C. E>>Ну вот есть такая т. з., что в случае массового потребителя, производительности не хватает практически ВЕЗДЕ. Ну ценят люди скорость...
G>Да ну, а ты не слышал что процессор настолького компа в среднем загружен на 5%, а сервера — на 20% G>На C имеет смысл писать только математику, обработка больших объемов данных гораздо лучше пишется на .NET.
Я думаю, что в твоих задачах обработка больших объёмов совсем лучше всего выполнятся СУБД... В на C# хорошо пишется интерфейс к этой самой СУБД...
Ты видимо не встречал пока других сложных задач, где нужна таки выч. мощь, кроме того, что ты называешь словом "математика"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gandjustas, Вы писали:
G>Круто, а фабричный метод так изобразите? G>ЗЫ. Передача указателя на стек до добра не доводит, большенство уязвимостей в ПО так и получаются.
Я заню, что круто ))
Нет, фабричный метод так не изображу. Только не надо говорить "ну тогда и нет никакого ООП на стэке". Естественно одним стэком не обойдёшься. Но стэк позволяет убрать очень много выделений памяти.
P. S. Указатель не был заменён на ссылку по соображениям наглядности для участвующих в дискуссии, которые быть может не сильно разбираются в С++.
h> А если серьезно, то МакОС и Линукс версии сейчас готовятся.
Ну, про это я знаю
h> M>Гуглохром хороший пример нового приложения. Толкьо вот там С++ изначально — куча. Это и вебкит, и V8. h> Ну и что? Никого же не смущает использование в .Net софте нативно Трайдента
Здравствуйте, gandjustas, Вы писали:
M>>>С одной стороны виноват тот же С++. Потому что legacy и тот же ворд нет смысла переписывать с нуля M>>>С другой стороны — а что такое десктопный софт?
H>>Гуглохром например, и легаси нету и работает на десктопе
G>У гугла столько ресурсов, что они могуть ОС в машинных кодах написать. G>И если им будет надо — напишут.
У МС ресурсов не меньше, чего же легаси свое не перепишут на шарпе? Глядишь и сэкономят еще
Здравствуйте, gandjustas, Вы писали:
G>А что такое core ?
Это реализация функционала проги, отличного от GUI или какого-то ещё UI.
Скажем в твоих задачах core обычно на СУБД какой-то реализовано, а в одной из часть core была на C...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, alsemm, Вы писали:
A>>GUI — С#, core — С++ G>надо разработчикам blend это рассказать, а то они не знают.
G>А что такое core ?
В CAD системах — это modeling kernel.
Здравствуйте, esil, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
E>И вот таки да, предположим у нас получилость так, что из-за частых выделений/освобождений памяти наш продукт на С++ работает недопустимо медленно. Что можно с этим сделать? Для начала собрать профиль размеров выделяемых блоков, который нам покажет, что большинство выделяемых блоков имеют размер 256 байт. А дальше можно сделать например так:
E>
E>//поскипано
E>
Только делать так не нужно. В первую очередь стоит заняться алгоритмический оптимизацией или даже архитектурной, а не кидаться писать кастомный аллокатор.
Причем этот подход работает для любых языков.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Действительно, ООП там толком нет, только пародия на него. E>По существу замечание, однако... E>Вообще-то на ООП свет клином не сошёлся. И "настоящее ООП" где-то или "пародия на него" обычно не важно...
Так это не я начал про супер-мега ооп с объектами на стеке.
E>>>Но вообще-то возможно и изображу, правда тут надо бы уточнить, что ты понимаешь под "фабричный метод", так как может и изображу, а может и нет... G>>http://ru.wikipedia.org/wiki/Фабричный_метод_(шаблон_проектирования) E>Спасибо, я раньше не знал какого рода документацией пользуются в своей работе ХиндиСишники...
А вы какой пользуетесь?
Это первая ссылка в гугле по словосочетанию "фабричный метод".
E>Смотри, такой вот код:
E>struct IOder {
E> virtual bool IsInGoodOrder( T left, T right ) const = 0;
E> virtual bool IsEqu( T left, T right ) const = 0;
E>};
E>class SortBySimilarity : public IOder {
E>public:
E> bool IsInGoodOrder( T left, T right ) const { /*тут реализация*/ }
E> bool IsEqu( T left, T right ) const { /*тут реализация*/ }
E> // фабричные методы
E> static SortBySimilarity CreateBySimilarityCasesensitive( const T& pattern ) { /*тут реализация*/ }
E> static SortBySimilarity CreateBySimilarityCaseinsensitive( const T& pattern ) { /*тут реализация*/ }
E>}
E>// использование
E>void foo( T pattern )
E>{
E> const IOder& order = SortBySimilarity::CreateBySimilarityCasesensitive( pattern );
E> data.SortBy( &order );
E>}
E>
Здравствуйте, NikeByNike, Вы писали:
VD>>>А если серьезно, то уровень дискуссии действительно просто супер. Плинтус горами покажется. WH>>Угу. Люди не знающие .НЕТ против людей не знающих С++. WH>>Смешно читать и тех и других.
NBN>Не только, люди ещё специализируются на разных направлениях...
... незнающие ни того, ни другого но спорящие об обоих.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>У гугла столько ресурсов, что они могуть ОС в машинных кодах написать. G>>И если им будет надо — напишут.
E>Не понимаю я вот этого аргумента! Если они такие лохи, что всё делают неверно и неэффективно, то почему у них всё так хорошо?
Гуглу гораздо сложнее будет нанять шатат разработчиков на Java наример, чем написать что-то на C++.
Исторические причины в крупных организациях играют немалую роль.
Здравствуйте, Erop, Вы писали:
E>Да, так бывает. И не только в ПО. И не только сейчас, но и раньше было. E>То, что ты не умеешь искать такие позиции, всего лишь говорит что-то о тебе, а не об окружающем мире... E>Можешь подумать над значением слова "подмастерье"...
Ой, я же забыл. Мы же о сапожниках говорим. Вот только ученикам зарплату не платили. Им максимум еду давали.
Почему всем будет смешно, если им расскажут о подмастерьи физика, химика или врача. Так почему же подмастерья программистов обсуждаются серьезно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Действительно, ООП там толком нет, только пародия на него. E>По существу замечание, однако... E>Вообще-то на ООП свет клином не сошёлся. И "настоящее ООП" где-то или "пародия на него" обычно не важно...
E>>>Но вообще-то возможно и изображу, правда тут надо бы уточнить, что ты понимаешь под "фабричный метод", так как может и изображу, а может и нет... G>>http://ru.wikipedia.org/wiki/Фабричный_метод_(шаблон_проектирования) E>Спасибо, я раньше не знал какого рода документацией пользуются в своей работе ХиндиСишники... E>Смотри, такой вот код:
E>struct IOder {
E> virtual bool IsInGoodOrder( T left, T right ) const = 0;
E> virtual bool IsEqu( T left, T right ) const = 0;
E>};
E>class SortBySimilarity : public IOder {
E>public:
E> bool IsInGoodOrder( T left, T right ) const { /*тут реализация*/ }
E> bool IsEqu( T left, T right ) const { /*тут реализация*/ }
E> // фабричные методы
E> static SortBySimilarity CreateBySimilarityCasesensitive( const T& pattern ) { /*тут реализация*/ }
E> static SortBySimilarity CreateBySimilarityCaseinsensitive( const T& pattern ) { /*тут реализация*/ }
E>}
E>// использование
E>void foo( T pattern )
E>{
E> const IOder& order = SortBySimilarity::CreateBySimilarityCasesensitive( pattern );
E> data.SortBy( &order );
E>}
E>
это "фабричный метод" или нет?
G>>И в C++ есть способ безопасной передачи указателя на стек — ссылки называется. Только на ссылках вообще ООП не сделаешь. E>Выше глянь, повнимательнее..
А тут случаем баг не закрался?
CreateBySimilarityCasesensitive возвращает временный объект, на который потом берётся ссылка.
Здравствуйте, esil, Вы писали:
E>А тут случаем баг не закрался? E>CreateBySimilarityCasesensitive возвращает временный объект, на который потом берётся ссылка.
Нет, временный объект просуществует до конца видимости ссылки. С указателем такая фишка не сработает.
Здравствуйте, gandjustas, Вы писали:
G>Так это не я начал про супер-мега ооп с объектами на стеке.
Зачем "супер" и "мега"? Может быть, например, фильтр к какому-нибудь запросу к словарю...
Может быть техника, похожая на ET (шаблонные выражения, не знаю, как по-русски)
это "фабричный метод" или нет? G>Не-а.
Ну тогда, наверное, именно "фабричный метод" не изображу...
Но при нужде С++ позволяет использовать довольно мощный статический полиморфизм...
И это обычно можно сделать довольно быстрым кодом...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, esil, Вы писали:
E>>Здравствуйте, gandjustas, Вы писали:
G>>>Стоит учесть что каждый проход GC в программе на C# очищает вс первое поколение в таком случа и двигание объектов не происходит, то немного исправляет результат в пользу C#, но даже если бы код на C# работал в 2 раза медленее, то он оказался бы в 3 раза быстрее стандартного аллокатора для C++.
E>>И вот таки да, предположим у нас получилость так, что из-за частых выделений/освобождений памяти наш продукт на С++ работает недопустимо медленно. Что можно с этим сделать? Для начала собрать профиль размеров выделяемых блоков, который нам покажет, что большинство выделяемых блоков имеют размер 256 байт. А дальше можно сделать например так:
E>>
E>>//поскипано
E>>
G>Только делать так не нужно. В первую очередь стоит заняться алгоритмический оптимизацией или даже архитектурной, а не кидаться писать кастомный аллокатор. G>Причем этот подход работает для любых языков.
Может быть да, может быть нет. Может быть архитектура крива, а может быть она правильна, хотя в ней аллоцируется куча мелких объектов. Это вопрос чего угодно (религии, политики, философии), но только не сравнения аллокаторов.
Верным остаётся одно: на любой дурацкий синтетический тест найдёт столь же дурацкий аллокатор, который этот тест "уделает".
Лично мне комфортно от того, что можно пробовать строить различные архитекутры, не думая изначально о том, сколько каких мелких объектов где выделяется, потому что в случае чего можно расчехлить тяжёлую артиллерию. Кому-то такой подход кажется нормальным, кому-то нет. Но по крайней мере есть выбор. Хотя наличие выбора может кому-то тоже показаться плохой идеей. ))
Re[73]: Плохому танцору на С++ лучше не прогать...
Здравствуйте, gandjustas, Вы писали:
G>Исторические причины в крупных организациях играют немалую роль.
Странно у тебя выходит. Типа ХиндиС для десктопа подходит, но в каждом конкретном случае что-то ему мешает...
IMHO, есть огромный сегмент ПО -- это ПО, которое пишут по случаю и как можно быстрее.
Раньше это делали на VB, теперь делают на ХиндиС. В целом это огромный шаг вперёд!!!
И у C# есть своя ниша. А у С++ своя. Это разная работа обычно и разного рода цикл разработки даже. Так что я не вижу ничего странного в выборе человека между тем и этим, при построении дальнейшей карьеры.
Но в своей нише выбор уже часто предопределён. Если тебе надо пять COM-верверов заставить хитро взаимодействовать меду собой, то ясно что не на С++ это удобно. А если ты хочешь написать распознавалку голоса, чтобы оно могло писать под твою диктовку, то ясно, что не C#, твой выбор...
Ну и у десктопов своя специфика -- обычно программ много, а памяти и проца -- нет. При этом редко проги выпускаются по запросу и срочно. Так что экономичность программ -- это большой плюс для десктопа, а скорость разработки, на уровне "надо ещё вчера" -- нет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>>>Если вы изначально занимаетесь быстротой кода, то вряд ли он будет нажедным и красивым. Наоборот — вполне. E>>>Это всего лишь твоё неумение писать быстрый и качественный код... G>>С чего ты взял? E>С того, что знаю примеры быстрого кода, который сразу так и разрабатывался, как быстрый...
И я знаю, но обратных примеров больше.
E>>>Мне известны МНОГОЧИСЛЕННЫЕ контрпримеры, так что позволь не поверить твоему голословному утверждению... G>>Уууу, а сколько мне известно примеров когда наступала попа из-за преждевременной оптимизации и раннего проектирования структур данных... E>Не понимаю. Возможно проектирование выполнялось некачественно?
Ну это смотря что понимать под качеством проектирования.
Гуглите "premature optimization".
G>>Быстры и красивый быввает очень редко. Это он может казаться красивым пока не надо какую-то мелочь поменять. E>Почему это? Почему быстрый код нельзя писать НОРМАЛЬНО? Читабельно, поддерживаемо, без ребусов?..
Это я неверно выразился. Вместо быстрый надо читать "оптимизированный".
G>>С чего ты взял что я не знаю С++? E>Я не думаю, что ты совсем не знаешь. Но ты тут оговорился, что якобы объект на стеке не может иметь виртуальных функций, но может быть ты именно оговорился, или это вообще не ты был?
Я не говорил что не может иметь. Я вообще-то что их использовать там не получится.
Хотя надо было добавить что использовать безопасным образом. Я с тех пор как изучил C++ в полной мере старался не писать кода, который передает указатели на стек куда-то.
E>В любом случае это не важно. Я не утверждал, что ты не знаешь, я спрашивал, что тебя заставляет выбирать С вместо С++, кроме его сложности (IMHO, если ты говоришь, что С++ сложен, то это значит, что ты его знаешь недостаточно, чтобы писать на нём хороший код)
Я говорю что С++ сложен потому что знаю более простые и при этом более эффективные языки.
Например мне удалось жа полчаса объяснить человек программу на F# на два экрана, при том что он F# не знал.
Аналогичная программа на C++ занимала бы больше и была бы гораздо более сложна в понимании.
А вибирать С, когда нужен низкоуровневый код, заставляет его интероперабельность.
DLL экспортируют функции на С, линуксовые динамические модули (so) также работают на С.
Делать процедурную обвязку вокруг ОО-кода не хочется, тем более обычно задача низкоуровневого кода заключается в математике.
G>>А "нагруженные части" — те которые обрабатывают большой объем информации в единицу времени — для них C# подходит гораздо лучше. E>Пока не нужна память и скорость -- да. Например для GUI ХиндиС -- это просто находка!
Ну а доказательства тезиса будут?
Или опять по принципу — чем больше повторить, там больше правда.
E>А там AI, например, нифига не органичен...
Ну и как AI делать?
Мой знакомый AI занимается, вообще на лиспе пишет.
G>>>>И только там где не хватает производительности может быть использован C. E>>>Ну вот есть такая т. з., что в случае массового потребителя, производительности не хватает практически ВЕЗДЕ. Ну ценят люди скорость...
G>>Да ну, а ты не слышал что процессор настолького компа в среднем загружен на 5%, а сервера — на 20% G>>На C имеет смысл писать только математику, обработка больших объемов данных гораздо лучше пишется на .NET. E>Я думаю, что в твоих задачах обработка больших объёмов совсем лучше всего выполнятся СУБД... В на C# хорошо пишется интерфейс к этой самой СУБД...
Если данные лежат в субд и имеют реляционную природу, то конечно субд. И интерфейс отлично будет.
А если нет — то придется код писать и уж точно не на С++.
E>Ты видимо не встречал пока других сложных задач, где нужна таки выч. мощь, кроме того, что ты называешь словом "математика"
А где еще нужна таки вычмощь кроме математических алгоритмов (физика, графика, видео) ?
Все задачи которые требуют не только процессора, но и активно работы с другими ресурсами компьютера (память, диск, сеть), а также требующие высокую степень параллельности обработки лучше уже писать на .NET.
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, esil, Вы писали:
E>>А тут случаем баг не закрался? E>>CreateBySimilarityCasesensitive возвращает временный объект, на который потом берётся ссылка. NBN>Нет, временный объект просуществует до конца видимости ссылки. С указателем такая фишка не сработает.
Сенкс. Не думал, что в этом флейме удастся узнать что-то новое про С++ =)
С подобным кодом раньше не сталкивался, обычно в таких случаях вместо ссылки просто создают локальный объект )
Здравствуйте, esil, Вы писали:
E>Здравствуйте, gandjustas, Вы писали:
G>>Круто, а фабричный метод так изобразите? G>>ЗЫ. Передача указателя на стек до добра не доводит, большенство уязвимостей в ПО так и получаются.
E>Я заню, что круто )) E>Нет, фабричный метод так не изображу. Только не надо говорить "ну тогда и нет никакого ООП на стэке". Естественно одним стэком не обойдёшься. Но стэк позволяет убрать очень много выделений памяти.
Для С++ толк в этом есть, но мало. Это уже оптимизация после которой код хуже читается, сложнее модифицируется и еще и потенциально подвержен уязывимостям.
