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

M>А IBM не давали шансов? Или Oracle? И т.д. и т.п.
M>ChormeOS — это Убунту + Chrome. Нет там никаких шансов

Человек к Вам с проповедью обращается, а вы его фактами путаете

subj
И нечего сравнивать его C++

Microsoft из-за своей ревности к другим ОС резко ограничило распространение языка.
На это, уже сегодня, накладывается ограничение в распространении Windows как пользовательской ОС:
еще 5 лет назад, в руках у неумелой блондинки Linux мог оказаться только по недосмотру, а теперь пожалуйста -- Android.

Не за горами тот день, когда Гугл сделает свою ось для PC с блэкджеком и шлюхами.

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

M>Приче подразумевается, что эти утверждения справедливы для 100% программистов на С++ и, более того, эти способности встраиваются напрямую мозг простым заклинанием «я знаю C++».

Есть интересное наблюдение. В холиварах C# vs C++ на стороне C# выступают те кто знаю и C# и C++, а на стороне C++ выступают те, кто C# не знают.

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


G>Я не за свое время хочу денег, а за удовлетворение твоих потребностей.

У меня нет потребности в твоём труде. Просто нужно было вывести тебя на чистую воду, чтобы все увидели что ты пустышка в области программирования и твои слова о том, что на С# можно работать с аппаратно ускоренной графикой — это просто пустой трёп.

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

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

K>>Пришлёшь пример, я его сразу на CodeProject помещу и имя твоё прославлю, а если не пришлёшь, то ты болтун с большой буквы Б.

G>3 минуты в гугле и... http://www.codeproject.com/KB/openGL/sharpgl.aspx
G>Начинай прославлять. Мое имя не надо, прославляй автора статьи.

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

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

N>>>>Хорошо. Драйвера на C# в студию! асм-вставки в студию! Высокопроизводительные вещи (не исследовательские, такие и на Питоне пишут) в студию!
MM>>>Это всё-равно что я от тебя потребую примеры Linq-запросов на native С++ и, не получив ответ, заявлю, что у программистов С++ мало опыта и знаний. Ты смешиваешь области разработки и языки. Для каких-то задач нужно внимание к ассемблеру. Системные, например. Но на С++ пишут не только эти вещи. Следовательно из то, что часть С++ников обладает опытом разбора ассемблера, вовсе не следует, что тем же опытом обладают и все остальные разработчики, использующие данных язык.

N>>Я об этом и говорю: у С++ больше задач, требующих знаний ассемблера, поэтому они его знают лучше.

G>Интересно, какие это задачи С++ требуют знание ассемблера?

На самом деле все просто. В последнее время адепты С++ катятся в унылыий псевдоэлитизм. Который, грубо говоря, выглядит так:
— Только тот, кто освоил С++, способен разобраться в сложных системах
— Только тот, кто освоил С++, способен разобраться в работе компьютера
— Только тот, кто освоил С++, способен разобраться, если надо, в ассемблере
— Только тот, кто освоил С++, способен ... [подставить сюда любую сферу программерской деятельности]

Приче подразумевается, что эти утверждения справедливы для 100% программистов на С++ и, более того, эти способности встраиваются напрямую мозг простым заклинанием «я знаю C++».

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

С фундаментальной — ничего, потому что с фундаментальной точки зрения в С# есть почти все , что есть в C/C++ (конечно, если не пренебрегать unsafe).

С практической — иное дело.

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

M>>
K>Ты сейчас описал локальных Немерлистов :-D

Не, у немерлистов такое деление:
— элита
— блаб-программисты

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.
портабельную программу. моя программа на си работает на винде, маке и линухе (и еще кое-где). а как с этим у шарпа? только не надо про моно. оно не только ms не поддерживается, но даже и поставищиками линуха. т.е. юзать на свой страх и риск без гарантий.

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

_>Но подождите, и через 3 года 20% осей в мире будут ХрОСами.

Гарантированно не будет.
1)не будет игрушек по хромую ось.
2)не будет тонн корпоративного софта под хромую ось
3)не будет драйверов под хромую ось
4)и самое главное не будет разработчиков, которые смогут исправить ситуацию

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

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

Амазон пролежавший 36 часов весьма красноречивое основание.

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

1. Нельзя работать с OpenGL и DirectX
2. Нельзя написать защищённый от взламывания код
3. Нельзя написать код, требовательный к производительности
4. Нельзя писать программу, удобную для пользователя. Кругом одни костыли.

Резюмируя, можно сказать, что связка C# и .NET подходит исключительно для написания простеньких бизнес приложений, в основном для web.
Скажем более менее сложную учётную систему на C# не напишешь. Даже такой монстр инженерной мысли (в ковычках) как 1С, и та уделывает дот нет по полной.
А ведь это позор!

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.
Безгеморройный RAII

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

S>>Разумеется реализация такого рантайма должна быть максимально скоростной, что достижимо только на языке низкого уровня, такого как C++.
S>>Когда возможностей или производительности прикладной платформы недостаточно, необходимо писать расширение, которое так же должно быть максимально производительно. На чем его писать — разумеется на C++.
S>Сомнительные утверждения выделены.
Они не просто смнительны. Они откровенно ложны.
Ибо в случае с жабой и .НЕТ можно вовремя исполнения генерировать код который будет скомпилирован в весьма не плохой нативный код.
Делать это на С++ озвереешь.

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

M>>>На самом деле все просто. В последнее время адепты С++ катятся в унылыий псевдоэлитизм. Который, грубо говоря, выглядит так:

FR>>Кстати почему катятся, оно же всегда было.

M>Сейчас же:
M>- элита (любой программист на С++)
M>- быдлокодеры (все остальные)

M>
Ты сейчас описал локальных Немерлистов :-D

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


G>Кто тебе такую глупость сказал?

Глупости ты говоришь, а я говорю то, что знаю.


G>Не понятно, в чем ты позор увидел? Я же тебе говорю — смотри Dynamics CRM 2011, 1с8.2 и рядом не валялась.

Смотри выше.

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


G>За 10к рублей — нивопрос. Забесплатно ниче больше 20 строк писать не буду.

Я на Qt и OpenGL более сложную программу написал всего лишь за 15 минут когда знакомился с возможностями этой бибдиотеки в области трёхмерной графики.
Боюсь, ты на кывт гораздо больше времени в день проводишь. Это не коммерческая программа чтобы за неё денег просить, это Hello World трёхмерной графики.
Так что слив засчитан. Ты и твой дот нет в луже по этому вопросу.

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

.NET Common Language Runtime.

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

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

T>Мы же инженеры. Мы должны отличать теоретическую реализуемость (теоретически реализуема, например, операционная система на брейнфаке) от практической реализуемости. Указанная задача не реализуема на C# не в силу теоретических ограничений и не в силу законов природы. Она не реализуема потому что непрактична. Любой нормальный программист, даже если его заставить, помучается пару дней, плюнет и возьмёт нормальный инструмент. А если не заставлять -- сразу возьмёт.

Ну то есть вы признали, что фактических препятствий нет? Ну вот о том и речь.

T>P.S. Есть такая задача с куском платины. Какого размера должен быть кусок платины, чтобы его нельзя было поднять произвольному числу людей? Оказывается всего лишь метр на метр на метр -- уже хватает за глаза. Чтобы его поднять нужны усилия примерно 180 человек, а столько вы вокруг метрового куска не расставите.

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

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

R>>-скажем шаред кэш каких-то сложных структур данных, разделяемый между несколькими процессами
MM>Интересно, а как подобное делается в том же С++?

Делается DLL, в ней выделяется общий для всех процессов сегмент памяти с помощью #pragma data_seg

http://msdn.microsoft.com/en-us/library/h90dkhs0%28VS.80%29.aspx

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.
На обоих языках можно реализовать машину Тьюринга (одинаково отвлекаясь от конечности памяти). Для традиционных компьютеров нет ничего более фундаментального.

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

Здравствуйте, svcoder, Вы писали:
S>Также я думаю что количество предметно-ориентированных языков будет только увеличиваться. Пользователи становятся более продвинутыми и для многих специализированных приложений появляется сначала макросы для автоматизации часто выполняемых операций, затем какой-нибудь скрипт, а затем этому скрипту дают доступ ко всем библиотекам приложения. Разумеется реализация такого рантайма должна быть максимально скоростной, что достижимо только на языке низкого уровня, такого как C++.
S>Когда возможностей или производительности прикладной платформы недостаточно, необходимо писать расширение, которое так же должно быть максимально производительно. На чем его писать — разумеется на C++.
Сомнительные утверждения выделены.

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

S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

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

Возможно это недостаточно "фундаментально", но тем не менее это пример того, что если неизвестно как сделать что-либо на C++, то все равно можно быть уверенным, что сделать можно, а в случае C# уверенности такой нет.

On 11.05.2011 1:42, hardcase wrote:

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

Да, отсутствие понятия о адресной арифметике и устройстве памяти ниоткуда не
возникнет, если всю жизнь на managed и 4gl писать.

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

N>Я не смог нормально с Питоном работать из-за отсутствия этой возможности. Функции для доступа к элементам изображения есть, но тормозииит. При работе с одноцветными изображениями, например, удобно вручную развернуть цикл обхода по пикселям: за одну итерацию обрабатывать 4 пикселя, а инкремент указателя делать на 4 байта, а не на один. Получается гораздо быстрее.
N>Таких моментов встречается немного, но они существенны.
Безусловно такие задачи имеются. Я как-бы и не опровергаю их. Обсуждение пошло от этого

Автор: MasterZiv
Дата: 11.05.11

, где автор заявил, что люди, которые пишут на managed, не имеют понятия об адресной арифметике. С этим я собственно и не согласен. Твой пример только подтверждает, что это. Цепочка вполне простая: я программист Python -> пишу обработку картинки -> получается медленно -> ищем пути оптимизации -> выясняем, что удобнее по 4 пикселя -> пробуем на Python -> не выходит -> берем другой язык, если текущая производительность не укладывается в требования. И совершенно неважно, владел ты вначале этой цепочки адресной арифметикой или нет. Надо — выучишь. Не надо — значит не надо.

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

MM>Давай еще раз. Есть человек без опыта в программировании. Он начинает работать и осваивает определенный язык. В какой-то момент выясняется, что для выполнения задачи нужно углубиться в детали конечного кода, исполняемого процессором. Ни программист на C++, ни программист на Managed языке ни разу до этого не рассматривали итоговые ассемблерные команды. Они оба находятся в одном и том же положении по части умения дизассемблировать.

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

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

N>Хорошо. Драйвера на C# в студию! асм-вставки в студию! Высокопроизводительные вещи (не исследовательские, такие и на Питоне пишут) в студию!
Это всё-равно что я от тебя потребую примеры Linq-запросов на native С++ и, не получив ответ, заявлю, что у программистов С++ мало опыта и знаний. Ты смешиваешь области разработки и языки. Для каких-то задач нужно внимание к ассемблеру. Системные, например. Но на С++ пишут не только эти вещи. Следовательно из то, что часть С++ников обладает опытом разбора ассемблера, вовсе не следует, что тем же опытом обладают и все остальные разработчики, использующие данных язык.

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

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

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

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

S>>>>Просто il не даёт никаких особых преимуществ по скорости в сравнении с c#.
J>>>Он может дать скорость, когда компилятор делает не то. По крайней мере ,в С++ так — ты пишешь какой-то код, ожидая, что компилятор его определенным образом соптимизирует/раскидает по регистрам/упорядочит в памяти/во времени, а потом смотришь в дизассемблер — а там ужас какой-то.
J>>>В таких случаях приходится извращаться.

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

J>Плюс если ты вчитаешься в то, что я написал, то скилл не в том, чтобы писать на асме, а в том, чтобы его читать и понимать (т.е. понимать как то, что он делает, так и почему он такой получился), и чтобы изменять свой неасмовый код таким образом, чтоб получился правильный асм (например, переупорядочить поля структуры, повставлять руками дырки, так что структура хоть и распухнет, но будет быстрее работать, переупорядочить куски кода в функции, и т.п.).
Нууу pragma pack помоему в любом учебнике есть и совсем без необходиомсти знать ассемблер.

G>>Имхо единственный реальный сценарий применения ассемблера — задействование векторных вычислений (mmx, sse), автоматом это пока ни один компилятор делать не умеет.

J>Умеет. Автовекторизация называется. Но плохо. Только в примитивных случаях.
"Плохо и в примитивных случаях" — считай нету.

J>P.S. А как можно заниматься оптимизацией работы с памятью в управляемых языках, когда доступа к собственно памяти нету?
Легко. Смотришь профайлером где много памяти выделяется и\или много циклов GC происходит, потом ищешь более подходящий алгоритм, который меньше объектов создавать будет, по вкусу: переводишь объекты в структуры или организуешь пулинг долгоживущих объектов. А может просто настройка латентности gc поможет. В особо критичных местах может в 2-3 раза быстродействия добавить.

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

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

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


G>Нууу pragma pack помоему в любом учебнике есть и совсем без необходиомсти знать ассемблер.

pragma pack может не всё.


G>"Плохо и в примитивных случаях" — считай нету.

Нет есть! Лично мне включение опции "/arch:SSE2" в майкрософтовском компиляторе ускорило программу раза в два. Ну и код я слегка подтюнинговал под это дело.

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

J>Он может дать скорость, когда компилятор делает не то. По крайней мере ,в С++ так — ты пишешь какой-то код, ожидая, что компилятор его определенным образом соптимизирует/раскидает по регистрам/упорядочит в памяти/во времени, а потом смотришь в дизассемблер — а там ужас какой-то.

А можно увидеть реальный пример, в котором Вам удалось превзойти, допустим, Intel'овский оптимизатор ? Ну или даже стандартный VS2010, на худой конец ?

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

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

FR>Там как раз по теме, обсуждаете шаблоны и не смотрите на лучшую их реализацию.

Если в таком ключе, то милости просим. Мы только "за", если кто-то интересные идеи предлагает.
В рекламе D тоже нет ничего плохого. Это даже очень хорошо. Язык во многом интересеный. И если на него свалило бы несколько сотен С++-ников я бы был только рад.

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

VD>>Или это твое сообщение означает, что за пределами форума "Nemerle" об оном нельзя говорить, чтобы вас не раздражать?

FR>Я разрешаю.
FR>Если серъезно то здесь я про немерле как язык и не говорил, я говорил про местную элиту

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

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

D>Здравствуйте, мыщъх, Вы писали:

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

М>>моя программа на си работает на винде, маке и линухе (и еще кое-где). а как с этим у шарпа?
М>>только не надо про моно. оно не только ms не поддерживается, но даже и поставищиками линуха.
D>Это как на C можно написать такую программу, которая работает на винде, маке и линухе (и еще кое-где)?
ANSI C курить надо. и юзать стандартный ввод/вывод. поверьте, за пределами гуи есть жизнь!!! и на си _можно_ писать портабельно. на шарпе писать портабельно нельзя. поверьте, в мире есть не только винда и не только интеловские процы. в мире очень много разного железа и разных осей. и куча оборудования работает на жутко кастрированных никс-подобных системах, под которых нет даже моно. и под них пишут ПО (ну вот я пишу).

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

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


_>С железом у нас дружит эпл. Тут вообще мало кому что светит и Гугл не исключение.
_>А ОС писать с нуля и не будут. Возьмут за основу опыт Android (читай Линукс). И допилят.
_>Сделают какой-нибудь тонкий клиент, где сразу будет грузиться Хром. Достаточно взглянуть на gmail чтобы понять к чему все идет.


Ну, ChromeOS они уже пилят больше двух лет. И? Как была неюзабельным унылым гуаном, так и осталась

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

Осталось найти массовую ОСь, которую люди ВНЕЗАПНО начнут массово грузить

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

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


G>>Видимо синдром "гарфа монте-кристо".

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

За 10к рублей — нивопрос. Забесплатно ниче больше 20 строк писать не буду.

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

G>>Ну-ну, право, Вы несправедливы ко мне, уважаемый Lloyd. Я вам прекрасно ответил по теме Вашего письма, разъяснив ускользнувшие от Вас особенности устройства jython, помянутого Вами всуе.

L>Ты не ответил на вопрос Константин Б.:
L>

L>И в чем фундаментальная проблема забутстрапить CLR ?

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

L>Кроме того, проигнорировал замечание о pypy и лиспе.

PyPy consists of a standard interpreter and a translator.
The interpreter implements the full Python language in a restricted subset, called RPython (Restricted Python). Unlike standard Python, RPython is statically typed, to allow efficient compilation.

Забавно получается, когда начинаешь не копипастить из сети все подряд по ключевым словам, как поисковик, а пытаться читать инфу по собственным ссылкам, и вдаваться в детали, правда? Первое открытие — RPython это по большому счету не Python, а другой язык. Копнув глубже, поймешь, что PyPy это генератор рантаймов в разные бэкэнды, а не сам рантайм. С CLR у этой штуки достаточно мало общего. Для иллюстрации этого достаточно осознать, что CLR — это один из вариантов бэкэнда для PyPy.

LISP, так же как и FORTH, равнять с C# — не самая умная идея. Оба — концептуально простые по устройству рантайма метаязыки, и имеют с .NET довольно мало общего. Metacircular interpreter сделать на обеих — реально два пальца об асфальт. Что не скажешь о mamaged платформах.

L>>>Если вас настольно это задевает, пожалуй продолжать не стоит.

G>>Да нет, меня это ровным счетом никак не задевает. Развлекает немного — это да.

L>У меня есть по этому поводу определенные сомнения. Для незадетого человека вы слишком неадекватно реагируете.

Сомневайся, я не против.

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


_>А ОС писать с нуля и не будут. Возьмут за основу опыт Android (читай Линукс). И допилят.
_>Сделают какой-нибудь тонкий клиент, где сразу будет грузиться Хром. Достаточно взглянуть на gmail чтобы понять к чему все идет.


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

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

1. На C# не написать Венду
2. На C# не написать Линух
думаю, с фундаментальной точки зрения этого достаточно

А вообще C# — замечательный язык, в котором учтены многие ошибки дизайна и C++, и Java, и добавлено множество отличных возможностей, причем реализованных красиво (а не так как в C++0x). И библиотека классов .NET — замечательная и продуманная. Но вот понесло же их не в ту степь.. вместо того, чтобы захардкодить нормальный оптимизатор и кодогенератор, они породили всю эту немыслимую хрень с jit-компиляцией. В результате весь софт на дотнете тормозной.
Недавно столкнулся с одной софтиной на дотнете... Нажатие на красивую менюшку приводит к тому, что менюшка начинает отрисовываться, пару раз вздрагивая и останавливаясь на полпути, перерисовывая зачем-то время от времени другие компоненты, к ней не относящиеся (которые тоже заметно "вздрагивают" при этом). В результате, интерфейс обновляется около 500 миллисекунд, а то и секунду.
Нативные WinAPI-шные меню и диалоги открываются за время, нефиксируемое человеком (т.е. за сотые доли секунды или еще меньше).

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

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

M>>>Вопрос так и сотался неотвеченным: с какого перепугу люди буду массово грузить, а мне предлагать эту самую новую ОСь?
S>>С того же, с которого сейчас кто-то ставит что-то кроме Windows и Internet Explorer: оно бесплатно и оно лучше.
MM>Массовости в этом нет. Сам по себе Linux как был в заднице на десктопе, так там и остается.

Это исключительно лишь из-за сговора MS с производителями компьютеров и комплектующих.

Гугл дает тот самый шанс Линуксу, которого у него небыло. А мы посмотрим, годен он для десктопов или нет. И если да, то проприетарные языки MS вымрут.

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

M>>>>Вопрос так и сотался неотвеченным: с какого перепугу люди буду массово грузить, а мне предлагать эту самую новую ОСь?
S>>>С того же, с которого сейчас кто-то ставит что-то кроме Windows и Internet Explorer: оно бесплатно и оно лучше.
MM>>Массовости в этом нет. Сам по себе Linux как был в заднице на десктопе, так там и остается.
_>Это исключительно лишь из-за сговора MS с производителями компьютеров и комплектующих.
Ну с этим не поспоришь. MS еще сговорилась с моим ЖЭКом — весь лифт обклеен рекламкой на переустановку Windows.

_>Гугл дает тот самый шанс Линуксу, которого у него небыло. А мы посмотрим, годен он для десктопов или нет. И если да, то проприетарные языки MS вымрут.
А если нет?

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

N>Программисту на С++ углубляться требуется чаще. Поэтому у него знаний и опыта больше. Это так очевидно, что даже спорить незачем. Хотя бы потому, что ниши у языков разные: на С# не пишут системные или высокопроизводительные вещи, не используют asm вставки, не так часто занимаются профилированием программ.
Теперь понятно. С такими убеждениями спорить действительно незачем.

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

G>Есть интересное наблюдение. В холиварах C# vs C++ на стороне C# выступают те кто знаю и C# и C++, а на стороне C++ выступают те, кто C# не знают.

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

Ну и C++ он постоянной практики требует, пара лет и тонкости теряются.

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


M>Ну, когда вокруг был, по сути, только С++, а всего остального практически не было, то было разграничение типа:

Как это не было, очень даже было Delphi, VB и Java и даже FoxPro и подобные.
Кроме того были чистые сишники которые большей частью враждовали с плюсистами

M>- элита (чистый С++, шаблоны, потом boost как передний край науки и техники и т.п. Особняком — благородная аристократия вроде Кодта)
M>- быдлокодеры (те, кто писали под C++ Builder'ы)

Забыл еще плюсистов признающих только с Си с классами без всяких богомерзких шаблонов и STL

M>- странные люди которые писали на Qt не под Линукс
M>- просто быдлокодеры (Delphi, Java), на которых смотрели с презреннием
M>- программисты на VB и 1C, на которых смотрели с жалостью

M>Сейчас же:
M>- элита (любой программист на С++)

Элита сейчас только немерле признает

M>>>
K>>Ты сейчас описал локальных Немерлистов :-D

T>Не, у немерлистов такое деление:
T>- элита
T>- блаб-программисты

T>



У Немерлистов есть другая проблема.

Немерлист:
— Языки со статической типизацией заруливают динамику
— Языки с метапрограммированием решают то-то и то-то и не имеют проблем таких-то и таких-то
— Что-то там в PEG стандаризированно

Интересующийся/скептик:
— А как же вот такие-то проблемы в статически-типизированных языках?
— А вот тут и тут естьили могут быть проблемы с метапрограммированием
— Где это оно стандартизировано?

Немерлист:
— В правильных языках нет такой проблемы
— В правильных языках нет такой проблемы
— В правильных языках нет такой проблемы

Интересующийся/скептик:
— Список правильных языков в студию

Немерлист:
— Немерле.

Интересующийся/скептик:
— Ээээ. А где список?

Немерлист:
— Ты в блабе, ты блаб, ты туп и т.п.


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

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

Написать программу для нестандартной архитектуры (e.g. Symbian) или хотя б сделать модуль заточенный под 64-битную систему (пример — см. гугловский алгоритм сжатия Snappy aka Zippy). Сомневаюсь, что удастся достичь на шарпе скорости распаковки в 500 Мб/с.

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

Если доживем до времени, когда появятся 128-и битные компы, то для С или С++ ситуация мало изменится (STL например будет нормально функционировать), шарп же будет несколько не к месту.

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

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

M>>>А откуда он возьмется выделенное у С++ника?
N>>Из практической каждодневной деятельности.
MM>Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием. Более того, не верю, что 50% программеров на С++ вообще прибегают к этому приему. О, кстати, ДотНет-чики тоже умеют при необходимости: тынц1

Автор: Пельмешко
Дата: 19.08.10

, тынц2

Автор: romangr
Дата: 30.08.08

, тынц3

Автор: bitferens
Дата: 19.06.09

, тынц4

Автор: dimchick
Дата: 18.11.05

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

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

В c# нельзя напрямую работать с памятью.

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


A>а в чем тут проблема? код вызывающий функции opengl, что на асме, что на Си, что на С# — выглядит одинаково
A>или говоря "работа с openGL\DX" вы имели ввиду библиотеки типа ogre3d? так для C# тоже есть библиотеки %)

Не надо меня лечить всей этой теоретической м..............й!!!!!!!!!
Ты пробовал создать РЕАЛЬНОЕ приложение, использующее все эти интеропы? Судя по твоему идеалистическому представлению — нет.
А я на этом зубы сломал , плюнул и решил, что уж лучше я буду использовать самый простой , самый незамысловатый интерфейс
(ведь эти .... из MS сделали ВСЁ, чтобы мы не могли на плюсах писать под виндой), но не буду больше мучиться с этим нетом


A>ваш бинарник декомпилируется не хуже C#, а проты и для .NET есть

Я тебе пришлю экзешник, ты мне исходники пришлёшь?

K>>>>3. Нельзя написать код, требовательный к производительности
A>>>можно написать отдельный модуль на С\С++, а 90% проги будет на C#

K>>Об этом, собственно, и вопрос, что нельзя написать на C#? Ответ Вы сами дали — то, что предлагаете запихать в dll на с++. Только какой тогда прок оставшиеся 10% писать на дот нете, ради чего?!!!

A>у вас с математикой плохо?!!!11

Я над тобой поиздевался немного , потому как лень спорить, что ты 10 и 90 местами поменял

K>>>>4. Нельзя писать программу, удобную для пользователя. Кругом одни костыли.
A>>>жуть
K>>Да, это жуть. Я могу по части интерфейса Вас примерами из 1С уложить на обе лопатки в области программ для работы с базами данных. Желаете опозориться?
K>>Это к вопросу про позор.

A>вы различаете фразы "программа, удобная для пользователя" и "программа для работы с БД, удобная для пользователя" ?
A>у вас похоже и с теорией множеств что-то не в порядке

Ещё раз, не лечи меня своими множествами и их теориями. Позора хочешь или нет? Я тебе на youtube выложу ролик примера интерфейса и как его сделал, а ты мне ответ на нете выложишь, равнозначный по возможностям. Давай покуражимся?

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


G>Видимо синдром "гарфа монте-кристо".

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

Пришлёшь пример, я его сразу на CodeProject помещу и имя твоё прославлю, а если не пришлёшь, то ты болтун с большой буквы Б.

G>>Видимо синдром "гарфа монте-кристо".

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


1. Что это докажет?
2. Какое отношение это имеет к удобству пользователя?
3. Программы типа Paint.NET показывают, что, если руки не из жопы, то удобные для пользователи приложения спокойно пишутся на дотнете

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

M> 3. Программы типа Paint.NET показывают, что, если руки не из жопы, то удобные для пользователи приложения спокойно пишутся на дотнете

Посмотрел на новую 3.5.1. Боже ж мой, они переделали выделение, теперь оно статично! Видимо не смогли справиться с ситуацией, когда их "ползающие муравьи" (в 3.31) выжирали 100% проца/ядра Это к вопросу о произростании рук

Здравствуйте, Константин Б., Вы писали:

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

S>>>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>>>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

G>>.NET Common Language Runtime.

КБ>И в чем фундаментальная проблема забутстрапить CLR ?

Если не вдаваться в детали (и в смысл того, что означает "забустрапить" в данном случае) — то, разумеется, никаких. А если вдаваться, то на реализацию JIT-компилятора и сборщика мусора на C# было бы интересно посмотреть. Покажешь, никаких проблем ведь вроде, так?

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

КБ>>И в чем фундаментальная проблема забутстрапить CLR ?
G>Если не вдаваться в детали (и в смысл того, что означает "забустрапить" в данном случае) — то, разумеется, никаких. А если вдаваться, то на реализацию JIT-компилятора и сборщика мусора на C# было бы интересно посмотреть. Покажешь, никаких проблем ведь вроде, так?
Таки нет проблем.

Более того, для Java вполне есть JVM, написанная на самой Java: http://jikesrvm.org/

Для Python'а есть PyPy на самом Питоне.

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

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

КБ>>>И в чем фундаментальная проблема забутстрапить CLR ?

G>>Если не вдаваться в детали (и в смысл того, что означает "забустрапить" в данном случае) — то, разумеется, никаких. А если вдаваться, то на реализацию JIT-компилятора и сборщика мусора на C# было бы интересно посмотреть. Покажешь, никаких проблем ведь вроде, так?

L>На данный момент нет программы, которая бы выводила на консоль строку "11a75ef2-20c4-4592-84d4-205b68da1058".

Не составляет труда написать ни на С#, ни на С++.

L>Из этого разве следует, что есть какие-то фундаментальные проблемы с выводом этой cтроки?

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

Здравствуйте, Философ, Вы писали:

A>>>Делается DLL, в ней выделяется общий для всех процессов сегмент памяти с помощью #pragma data_seg
MM>>Угу, ясно. Я так понял, MS не особо рекомендует этот способ, а Memory Mapped Files теперь поддерживаются и в BCL.

Ф>что там мелкософт "не особо рекомендует" — не важно, т.к. иногда это наиболее удобный и простой способ что-нибудь "зашарить".
После этой фразы, уже можно прекращать разговор.

Ф>иногда нужно шарить всего одну единственную целочисленную переменную — в пень mmf!
Ну да, конечно. Вот ваять отдельную dll для одной несчастной переменной — вот это тру.

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

T>>Фактически это и есть препятствие. Автор поста спросил "что можно СДЕЛАТЬ на C++ что невозможно на C#" а не "что реализуемо на C++ и не реализуемо на C#".

L>"можно сделать" и "реализуемо" — это одно и то же, синонимы.

"В теории практика от теории ничем ни отличается"

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

VD>Ты главное название конторы не называй. А то ведь с того сайта много то на собеседования ходит. Будут вашу контору обходить за тридевять земель.

Не ну вот надо было тебе его спугнуть и всё испортить!!!

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

S>>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

BFE>Освобождение ресурса в деструкторе локального объекта?

См IDisposable + using

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

G>http://www.mono-project.com/Main_Page

After Novell acquisition by Attachmate on April 2011, Attachmate announced hundreds of layoffs for the Novell worksforce[26], putting in questions the future of Mono

здесь

_>Не за горами тот день, когда Гугл сделает свою ось для PC с блэкджеком и шлюхами.

Не сделает никогда. Потому что они не умеют это делать

Вон, свой ноутбук они пытались уже два раза сделать

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

A>>На C#/.Net не стоит писать обработку мультимедиа (крайне низкий уровень оптимизациив ычислений, разница на порядок).
VD>После появления кучи библиотек для переноса расчетов на видюху эта информация устарела.

Ну есть ещё Mono.Simd, но это жульничество

Здравствуйте, rm822, Вы писали:
R>из очень сложных — все что требует ручного управления памятью
R>-скажем шаред кэш каких-то сложных структур данных, разделяемый между несколькими процессами
R>-шаред-мемори провайдер к БД

В C# есть unsafe и можно работать с любыми WINAPI вызовами, я знаю человека кому удобнее это всё реализовывать на C#

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

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

G>>Ничего. А что страшного? Для С++ вообще ничего нет ECMA/ISO.

I>Для C++ есть ANSI/ISO стандарт, а для C# версий 3 и 4 стандарта нет.

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

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

S>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

У меня на этот счет сформировалось свое ИМХО.
Смысл в том, что c# не является таким уж высокоуровневым языком. Если например поставить задачу расчета себестоимости продукции — реализация ее на платформе 1C8 будет гораздо более понятна и расширяема, чем на c# или java. Потому что какой бы совершенный язык ни был он не сможет конкурировать с предметно-ориентированным языком. Можно вообще логику работы описать на BPMN и запускать ее в специальной среде.
Также я думаю что количество предметно-ориентированных языков будет только увеличиваться. Пользователи становятся более продвинутыми и для многих специализированных приложений появляется сначала макросы для автоматизации часто выполняемых операций, затем какой-нибудь скрипт, а затем этому скрипту дают доступ ко всем библиотекам приложения. Разумеется реализация такого рантайма должна быть максимально скоростной, что достижимо только на языке низкого уровня, такого как C++.
Когда возможностей или производительности прикладной платформы недостаточно, необходимо писать расширение, которое так же должно быть максимально производительно. На чем его писать — разумеется на C++.
Из всего вышеописанного следует, что c# и java не подходят ни для использования в качестве прикладного языка, ни для языка на котором следует реализовывать стандартные библиотеки, поэтому их предназначение — написание самостоятельных приложений без возможности быстрого и дешевого расширения под новые требования пользователя.

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

_>Да, кстати, Oracle ведь подал в суд на Google за Java в андроиде. Если захотеть, то ECMA можно и отозвать =)
Ты учитывай не только потенциальную возможность, но и профит, который получит компания от таких действий. Я вот совершенно не вижу причин по которым MS может пойти на такой шаг.

G>>>>Реально единственное где Microsoft может перекрыть кислород — не-Windows серверная разработка. Но и сейчас довольно мало выбирают *nix в качестве серверов для .NET приложений.

_>>>Они могут перекрыть кислород в любом месте когда захотят. Однажды, во всех Windows, начиная с версии 1X не будет фрэимворка.
G>>А зачем? Какой им с этого профит?

_>Будет новая технология. Нужно ведь как-то продавать новые версии Windows. А для этого нужно вводить что-то новое и убирать поддержку страрого.
Странно, .NET существует с 2003 года и пережил спокойно два мажнорных релиза новых ОС. По каким причинам не переживет еще несколько — непонятно.
Кроме того .NET всегда отдельно ставился.

_>А то дай юзерам волю -- будут сидеть под XP еще 10 лет.
Вот только те кто перешел на win7 как-то не рвутся обратно на xp.

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

_>Излише говорить, но .NET останется на пероне.

Вы хотели сказать, на серверах.

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

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

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

_>>>Да, кстати, Oracle ведь подал в суд на Google за Java в андроиде. Если захотеть, то ECMA можно и отозвать =)
G>>Ты учитывай не только потенциальную возможность, но и профит, который получит компания от таких действий. Я вот совершенно не вижу причин по которым MS может пойти на такой шаг.

_>Тут два момента.
_>1) Создатель языка не заинтересован в его распространении за пределы своей ОС
Кто сказал? Пруфлинк дашь?

_>2) Всем разработчикам ОС, отличных от Windows, нет дела до поддержки C#. Он им не интересен.
Интересно, а кто Mono сделал?

_>В силу просто теоретической возможности судебного преследования со стороны MS, и с учетом (1) и (2) никто не идет на встречу C#.
_>Нужно признать: технология .NET не сделала революции по причине идиотской политики MS.
Кстати Mono был в составе дистрибутивов Linux, пока такие нытики как ты не заставили его убрать оттуда. Так что путаешь мнение разработчиков ОС и свое собственное.

_>Были бы умнее, поступили бы как SUN с Java и кто знает, может на каждом утюге и в каждом холодильнике работали бы сейчас программы на C#.
Если что — политика лицензирования java vm гораздо более жесткая, чем политика лицензирования clr. Например в среде java что-то типа mono никогда бы не появилось.

_>>>Будет новая технология. Нужно ведь как-то продавать новые версии Windows. А для этого нужно вводить что-то новое и убирать поддержку страрого.
G>>Странно, .NET существует с 2003 года и пережил спокойно два мажнорных релиза новых ОС. По каким причинам не переживет еще несколько — непонятно.
G>>Кроме того .NET всегда отдельно ставился.

_>Еще несколько переживет Сколько вас устроит? 5, 10 лет. А куда идти потом, когда и возраст уже не тот и переучиваться на С++ поздно.
5 релизов это минимум лет 15, к тому времени я уже не буду код писать.

_>>>А то дай юзерам волю -- будут сидеть под XP еще 10 лет.
G>>Вот только те кто перешел на win7 как-то не рвутся обратно на xp.

_>Вы святой! По вашему, раз заключённые не спешат уходить из тюрьмы, значит им там просто нравится?
_>Мой ноут (ASUS, 3 года) имеет дрова только к Висте 32 и 64. Даже для 7-ки нет. А для XP пришлось искать по всему инету и еще хорошо, что я был не первый кто это делал.
_>Если вы сейчас купите новый компьютер, у вас просто не будет другой альтернативы кроме 7ки.
Понятно, фанатик. отдыхай.

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

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

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

_>>>Излише говорить, но .NET останется на пероне.

H>>Вы хотели сказать, на серверах.
K>HP-UX, AIX, *BSD уже могут в Mono или я что-то пропустил? :-D

А это ничего, что одного слова MS достаточно, чтобы Mono прекратил существование?

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

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

_>>>>>Ага, нашел.
_>>>>>Что тут скажешь, они стараются как могут.
_>>>>>Старания эти может и не сокрушат MS, но они откроют рынок для Linux систем: появятся дрова, качественные программы (фотошоп хотя бы) современные игры и т.д.

M>>>>С какого перепугу?

_>>>Ну это вроде очевидно, как 2*2:
_>>>Ядро у ХрОСа -- Linux, проект открытый. Производители железа и ПО неминуемо пойдут на встречу Гуглу, а значит и всему linux сообществу.

M>>Еще раз. С какого перепугу производители железа и ПО неминуемо пойдут ему навстречу?

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

Amazon уже давно снимает. Rackspace тоже. Даже Microsoft давно снимает.

_>Достаточно вспомнить как Apple, совсем недавно, создал рынок тачскринов.

И? Какое отношение это имеет к ОСям? Мало иметь облачную ОСь и полное отсутствие приложений, умеющих с ней работать. А у ХромоОСи количество приложений, умеющих работть в облаке стремится к нулю, потому что то всего лишь браузер поверх Убунту

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

M>>>>Свежо предание У Гугла лимит доверия ровно такой же, как у любой другой компании
_>>>Как у кого еще? Их услугами пользуются без малого 100% пользователей интернет.

M>>Только поиском и не 100%, а 66%. Во всем остальном у них далеко не так радужно. Второй самый популярный продкут у них — это GMail, но он от силы четвертый в мире

_>Поисковиком, согласно статистике — 90%

Согласно статистике — 66%. Но не суть важно. Главное, что самым популярным их продуктом пользуются далеко не 100% людей.

_>А еще, из не требующих регистрации, есть google.maps и переводчик. Я не представляю кто может полноценно пользоваться интернетом и вообще никогда не пользоваться услугами Гугла.

Да, можно разрознено пользоваться различными их продуктами. Что не позволяет делать следующие выводы:
— Их услугами пользуются без малого 100% пользователей интернет. Совокупно — быть может и то...
— У Гугла неограниченный лимит доверия.


_>>>И делают это с величайшим удовольствием.
_>>>Хрому всего 3 года, а он уже на 3 месте с, по разным оценкам, 17-25% рынка.

M>>И? Как из этого следуют 100% пользователей интернета или безграничный лимит доверия? Да никак

_>1. Некоторые сайты, которых становится все меньше, работают только с IE
_>2. Политика очень многих компаний запрещает использование чего-либо кроме IE.
_>3. К лисе, пока еще, больше плагинов. Люди не хотят ломать привычки.
_>4. Большинство -- неопытные пользователи, которые просто боятся нового

_>И тем не менее, доля хрома непрерывно растет.


И как из этого следует вывод про 100% пользователей интернета или безграничный лимит доверия? Да никак

_>>>Я, например, не в особом восторге от организации переписки в gmail, пользуюсь лисой, но к самой компании отношусь абсолютно положительно, как и все кого я знаю лично. Будут дрова, поставлю Хрось параллельно с Windows

M>>И как из этого следует безграничный лимит доверия?
_>Из этого — никак.

И я о том же

_>Но подождите, и через 3 года 20% осей в мире будут ХрОСами.

С какого перепугу?

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

M>Итак, от тебя последовали следующие утверждения:

M>1. И вот когда люди начнут массово грузить новую ОС, Майкрософт осуществит свой фирменный маневр...
M>2. Однажды вам предложат на выбор предустановленный Хромос или Виновс...

M>Вопрос так и сотался неотвеченным: с какого перепугу люди буду массово грузить, а мне предлагать эту самую новую ОСь?

1 Будут предлагать купить, потому что появится такой продукт.
2 Будут массово грузить, если будут драйвера и продукт будет гарантированно лучше чем windows 7/8.

Мое IMHO: ХрОС порвет Win, достаточно посмотреть на качество браузера Chrome в сравнении с IE (до 9й версии, ее я пока не пробовал), чтобы понять кто на что способен.

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

_>Мое IMHO: ХрОС порвет Win, достаточно посмотреть на качество браузера Chrome в сравнении с IE (до 9й версии, ее я пока не пробовал), чтобы понять кто на что способен.
Ты учти что под Win отнюдь не все пользуются IE.
Для меня например Chrome вчистую сливает FF по юзабилити.

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

N>Так откуда выяснится, что по 4 пикселя быстрей? Только после анализа дизассемблера профайлером. А для этого нужен опыт. А ему откуда взяться?
Всё когда-нибудь бывает в первый раз. Если человек чего-то не знает, это же не означает, что он не способен узнать об этом в будущем.

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

M>>А откуда он возьмется выделенное у С++ника?
N>Из практической каждодневной деятельности.
Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием. Более того, не верю, что 50% программеров на С++ вообще прибегают к этому приему. О, кстати, ДотНет-чики тоже умеют при необходимости: тынц1

Автор: Пельмешко
Дата: 19.08.10

, тынц2

Автор: romangr
Дата: 30.08.08

, тынц3

Автор: bitferens
Дата: 19.06.09

, тынц4

Автор: dimchick
Дата: 18.11.05

и далее поиск...

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

M>>>>А откуда он возьмется выделенное у С++ника?
N>>>Из практической каждодневной деятельности.
MM>>Не верю, что даже 75% программеров С++ каждый день занимаются дизассемблированием.
CC>Такое ощущение что дизассемблирование это какое то таинство.
CC>Любой нормальный отладчик или профайлер показывает asm код при необходимости.
CC>Если на уровне С++ сурсов не понятно в чём проблема — тыкается одна кнопка и переходим в asm, где смотрим что там компилер нагенерил и что про это думает профайлер.
Дык, я и не считаю дизассемблер таинством. Инструмент, как инструмент. Кому-то нужный, кому-то нет

N>>>Так откуда выяснится, что по 4 пикселя быстрей? Только после анализа дизассемблера профайлером. А для этого нужен опыт. А ему откуда взяться?

M>>А откуда он возьмется выделенное у С++ника?

N>Из практической каждодневной деятельности.

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

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

N>>Программисту на С++ углубляться требуется чаще. Поэтому у него знаний и опыта больше. Это так очевидно, что даже спорить незачем. Хотя бы потому, что ниши у языков разные: на С# не пишут системные или высокопроизводительные вещи, не используют asm вставки, не так часто занимаются профилированием программ.
MM>Теперь понятно. С такими убеждениями спорить действительно незачем.

Хорошо. Драйвера на C# в студию! асм-вставки в студию! Высокопроизводительные вещи (не исследовательские, такие и на Питоне пишут) в студию!

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

N>>Хорошо. Драйвера на C# в студию! асм-вставки в студию! Высокопроизводительные вещи (не исследовательские, такие и на Питоне пишут) в студию!
MM>Это всё-равно что я от тебя потребую примеры Linq-запросов на native С++ и, не получив ответ, заявлю, что у программистов С++ мало опыта и знаний. Ты смешиваешь области разработки и языки. Для каких-то задач нужно внимание к ассемблеру. Системные, например. Но на С++ пишут не только эти вещи. Следовательно из то, что часть С++ников обладает опытом разбора ассемблера, вовсе не следует, что тем же опытом обладают и все остальные разработчики, использующие данных язык.

Я об этом и говорю: у С++ больше задач, требующих знаний ассемблера, поэтому они его знают лучше.

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


FR>>С этой штукой http://code.google.com/p/nativeclient/ + http://news.cnet.com/8301-30685_3-20003527-264.html вполне реально выполнять их и в браузере.

M>Во-первых там для начала всего лишь OpenGL ES 2.0. То есть это — максимум уровень афйонов/айпадов. Все, что посложнее — welcome в мир драйверов и несовместимых конфигураций.

Ну подтянуть и полноценный OGL вполне можно.

M>Ну и учитывая не только браузерность но и убнтность ХромоОСи, то когда-когда, говорите, там надо будет ожидать Total War или GTA?

Я вообще не жду, думаю что это вообще не выстрелит.
Вот если бы они успели к началу бума с нетбуками все могло бы и получится.

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

G>Интересно, какие это задачи С++ требуют знание ассемблера?

Практически все, где требуется профилирование. Такое ощущение, что никто тот же VTune в глаза не видел.

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

CC>>Т.е. откуда?
CC>>Профайлеры для native кода очень давно есть в наличии.
CC>>И очень мощные, типа VTune, который юзает HW средства профайлинга процессора. Показывает как С++ сурс (при наличии PDB) так и ассемблер.

M>Я не совсем верно выделил. Откуда взяться опыту анализа дизассемблера профайлером у С++ника? Средний С++ник так же далек от анализа дизассемблера профайлером, как и средний дотнетчик
Ну в общем то оттуда же откуда и у дотнетчика: наколбашеный код не вписывается в requirements по времени выполнения.
Тут начинает всплывать специфика специализаций среднего С++ и C# разработчика. Грубо говоря у кого time critical задач попадается больше.
Плюс то, что слабые программеры при налиичии более ошибкопрощающих языков в С++ приживаются плоховато.

Здравствуйте, x-code, Вы писали:
XC>Недавно столкнулся с одной софтиной на дотнете... Нажатие на красивую менюшку приводит к тому, что менюшка начинает отрисовываться, пару раз вздрагивая и останавливаясь на полпути, перерисовывая зачем-то время от времени другие компоненты, к ней не относящиеся (которые тоже заметно "вздрагивают" при этом). В результате, интерфейс обновляется около 500 миллисекунд, а то и секунду.
XC>Нативные WinAPI-шные меню и диалоги открываются за время, нефиксируемое человеком (т.е. за сотые доли секунды или еще меньше).
Наблюдаемое поведение не имеет никакого отношения к C#. В до-дотнетные времена ровно то же самое писали про программы на дельфи, которые были все из себя насквозь нативные.
Просто писал программу некомпетентный разработчик, который понавешал обработчиков не туда, куда надо.
Чистое время исполнения прикладного кода в этой менюшке настолько мало, что разницу между нативным и управляемым кодом невозможно заметить. Перерисовка отдельных компонентов, скорее всего, тоже сделана на нативном коде (а то и через бит-блиттинг операции, реализованные в железе драйвером видеокарты). А вот то, что этих операций выполняется 5000 вместо 5, и вызывает наблюдаемый эффект.

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

M>Еще раз. С какого перепугу у среднего С++ника time-critical кода ВНЕЗАПНО больше?
Из опыта.
Спросим тебя твоим же языком: С какого перепугу у среднего С#ника time-critical кода ВНЕЗАПНО больше?

Здравствуйте, 5er, Вы писали:

5er>Здравствуйте, snaphold, Вы писали:

S>>Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
S>>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

5er>В c# нельзя напрямую работать с памятью.

unsafe отменили?

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

K>1. Нельзя работать с OpenGL и DirectX
у вас в C# p\invoke и COM не работают?
K>2. Нельзя написать защищённый от взламывания код
на С++ можно? покажите
K>3. Нельзя написать код, требовательный к производительности
можно написать отдельный модуль на С\С++, а 90% проги будет на C#
K>4. Нельзя писать программу, удобную для пользователя. Кругом одни костыли.
жуть

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

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


G>>Кто тебе такую глупость сказал?

K>Глупости ты говоришь, а я говорю то, что знаю.

Видимо синдром "гарфа монте-кристо".

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

J>Он может дать скорость, когда компилятор делает не то. По крайней мере ,в С++ так — ты пишешь какой-то код, ожидая, что компилятор его определенным образом соптимизирует/раскидает по регистрам/упорядочит в памяти/во времени, а потом смотришь в дизассемблер — а там ужас какой-то.
J>В таких случаях приходится извращаться.

Для c# такого практически не бывает. il очень прост и компилятор шарпа не содержит в себе никакой магии. Раскладыванием по регистрам занимается jit, его не подтюнишь

Здравствуйте, Константин Б., Вы писали:

КБ>Приношу извинения. Глупо было с моей стороны ожидать от тебя нормального ответа

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

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

КБ>>И в чем фундаментальная проблема забутстрапить CLR ?

G>Если не вдаваться в детали (и в смысл того, что означает "забустрапить" в данном случае) — то, разумеется, никаких. А если вдаваться, то на реализацию JIT-компилятора и сборщика мусора на C# было бы интересно посмотреть. Покажешь, никаких проблем ведь вроде, так?

На данный момент нет программы, которая бы выводила на консоль строку "11a75ef2-20c4-4592-84d4-205b68da1058".
Из этого разве следует, что есть какие-то фундаментальные проблемы с выводом этой cтроки?

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

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

Про mercurial вы наверное в курсе?

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

G>>"В общем, ушел от ответа". Понятно.

L>Да вопрос просто бредовый. Если ты хоть немножко интерсуешься этой темой, ты должен быть в курсе что даже на древнем lisp-е есть полноценные среды для исполнения lisp-кода со сборщиком мусора и всем таким. На той-же java есть jython тоже со сборщиком мусора.
L>По каким причинам нельзя написать подобное на шарпе мне лично не понятно.
L>Ты видимо более осведомлен в этом вопросе, раз с такой уверенностью заявляешь, что этого сделать нельзя.

Очевидно, да, более осведомлен. Например, мне известно, что jython — компилятор из Питона в JVM-ный байткод, и никакого своего сборщика мусора в нем нет.

This is one of those major differences between CPython and Jython. Unline CPython, Jython does not implement a reference counting technique for aging out or garbage collection unused objects. Instead, Jython makes use of the garbage collection mechanisms that the Java platform provides.

http://jythonpodcast.hostjava.net/jythonbook/chapter2.html

Хотя я не так сильно интересуюсь темой, как ты, конечно.

L>>>Тезис о том, что на java/.net этого сделать невозможно прозвучал из ваших уст, на вас и обязанность сей тезис доказывать.
G>>Тут есть тонкость. Она состоит в том, что лично перед тобой у меня нет никаких обязанностей.
L>А меня твоя личность абсолютно не волнует. Меня прежде всего интерсует почему нельзя написать цлр/сборщик мусора на шарпе. А будешь эту идею защищать ты или кто другой значения не имеет.
L>Но если у тебя нет аргументов в защиту своей точки зрения и/или желания их озвучить, то тогда непонятно, зачем ты вообще с ней вышел.

Все просто — я с тобой говорить всерьез не вижу никакой причины, так как отлично представляю себе, как будет развиваться разговор, если я вдруг начну тебе что-либо объяснять.

ЗЫ: Ой, как меня радуют эти детские попытки "взять на слабо". Попробуй еще.

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

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

G>Все просто — я с тобой говорить всерьез не вижу никакой причины, так как отлично представляю себе, как будет развиваться разговор, если я вдруг начну тебе что-либо объяснять.

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

Удачи.

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

G>>Все просто — я с тобой говорить всерьез не вижу никакой причины, так как отлично представляю себе, как будет развиваться разговор, если я вдруг начну тебе что-либо объяснять.

L>Твой ответ был предсказуем. Вместо того, чтобы написать по теме, в очередной раз скатываешься на личность собеседника.

Ну-ну, право, Вы несправедливы ко мне, уважаемый Lloyd. Я вам прекрасно ответил по теме Вашего письма, разъяснив ускользнувшие от Вас особенности устройства jython, помянутого Вами всуе.

L>Если вас настольно это задевает, пожалуй продолжать не стоит.

Да нет, меня это ровным счетом никак не задевает. Развлекает немного — это да.

L>Удачи.

И Вам того же, многоуважаемый Lloyd. Примите мои искренние уверения в совершеннейшем почтении, и все такое.

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

L>>Ты не ответил на вопрос Константин Б.:
L>>

L>>И в чем фундаментальная проблема забутстрапить CLR ?

G>Я ответил на его вопрос. Ответ с предложением подумать ему не понравился, как и тебе.

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

L>>Кроме того, проигнорировал замечание о pypy и лиспе.

G>

G>

G>PyPy consists of a standard interpreter and a translator.
G>The interpreter implements the full Python language in a restricted subset, called RPython (Restricted Python). Unlike standard Python, RPython is statically typed, to allow efficient compilation.

G>Забавно получается, когда начинаешь не копипастить из сети все подряд по ключевым словам, как поисковик, а пытаться читать инфу по собственным ссылкам, и вдаваться в детали, правда? Первое открытие — RPython это по большому счету не Python, а другой язык. Копнув глубже, поймешь, что PyPy это генератор рантаймов в разные бэкэнды, а не сам рантайм. С CLR у этой штуки достаточно мало общего. Для иллюстрации этого достаточно осознать, что CLR — это один из вариантов бэкэнда для PyPy.

И что это должно было доказать? Как это свзяано с вопросом о невозможности реализовать CLR-то?

G>LISP, так же как и FORTH, равнять с C# — не самая умная идея.

Я и не сравнивал LISP с C#. Целью было показать, сбощик мусора возможно реализовать даже в такой среде, как лисп.

G>Оба — концептуально простые по устройству рантайма метаязыки, и имеют с .NET довольно мало общего. Metacircular interpreter сделать на обеих — реально два пальца об асфальт. Что не скажешь о mamaged платформах.

Т.е. вопрос уже не в принцыпиальной невозможности, а в сложности реализации оного? Ну тогда вопросы отпадают.

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

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

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

T>Мы же инженеры. Мы должны отличать теоретическую реализуемость (теоретически реализуема, например, операционная система на брейнфаке) от практической реализуемости. Указанная задача не реализуема на C# не в силу теоретических ограничений и не в силу законов природы. Она не реализуема потому что непрактична. Любой нормальный программист, даже если его заставить, помучается пару дней, плюнет и возьмёт нормальный инструмент. А если не заставлять -- сразу возьмёт.

А чем для данной задачи C++ практичнее C#?

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

H>А что такого в этом коде, что его всенепременно следует писать на Си?

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

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

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

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

M>>ЗЗЫ. Ни против Немерле, ни против людей, его разрабатывающих, лично ничего не имею

VD>Врешь.

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

Коли тут зашла речь про сравнение этих языков. Стало мне интересно.
Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

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

На C#/.Net нельзя написать драйвер видеоадаптера или файловой системы (благодаря WDF остальные уже кое-как можно).
На C#/.Net не стоит писать обработку мультимедиа (крайне низкий уровень оптимизациив ычислений, разница на порядок).

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

A>На C#/.Net не стоит писать обработку мультимедиа (крайне низкий уровень оптимизациив ычислений, разница на порядок).

обработку мультимедиа нынче можно писать на GPU, но там и не C++ и не C#

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

G>обработку мультимедиа нынче можно писать на GPU, но там и не C++ и не C#

Там все же С, хоть и адаптированный под GPU (NVidia)

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

G>обработку мультимедиа нынче можно писать на GPU, но там и не C++ и не C#
Там немерле
kvap.ru/pavt2011_cd/full/117.pdf
Обратити внимание на то насколько оно быстре...

PD>Там все же С, хоть и адаптированный под GPU (NVidia)
Я бы сказал иначе, там что то среднее между С и С++, и все это движется в сторону С++.
Уже появилась поддержка классов (частично без виртуальности/наследования), ссылки, шаблоны и перегрузка операторов есть чуть ли ни с первых версий.

Здравствуйте, WolfHound, Вы писали:
WH>Обратити внимание на то насколько оно быстре...

Интересно, что конкретно быстрее в плане (нативная vs управляемая) ?

Kernel mode?

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

A>На C#/.Net не стоит писать обработку мультимедиа (крайне низкий уровень оптимизациив ычислений, разница на порядок).

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

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

A>>На C#/.Net не стоит писать обработку мультимедиа (крайне низкий уровень оптимизациив ычислений, разница на порядок).

G>обработку мультимедиа нынче можно писать на GPU, но там и не C++ и не C#

Ага. Там Nemerle! Аж в дух инкарнация. NUDA

Автор: Denom
Дата: 04.04.11

и nemerlecl

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

T>Интересно, что конкретно быстрее в плане (нативная vs управляемая) ?

Какая на фиг управляемая? Там расчеты на GPU переносятся.

Здравствуйте, VladD2, Вы писали:
VD>Какая на фиг управляемая? Там расчеты на GPU переносятся.

Да, но оболочка вокруг OpenCL управляемая ... или немерл уже ToNative поддерживает? (в чем я сомневаюсь).

Если глянуть на сабж вопрос в том есть ли что-нибудь что НЕ УДОБНО делать на C# (e.g. .NET), а удобнее делать на С++

Драйвера это понятно... есть ли что нибудь ещё...

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

WH>Там немерле
WH>kvap.ru/pavt2011_cd/full/117.pdf
WH>Обратити внимание на то насколько оно быстре...

Жаль, из статьи непонятно быстрее чего.

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

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

S>>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

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

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

S>Отрицается сама техническая возможность, или речь об отсутствии такой фичи в BCL?

Второе конечно. Java-то может.

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

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

S>>Отрицается сама техническая возможность, или речь об отсутствии такой фичи в BCL?

I>Второе конечно. Java-то может.
Тема называется "что не сделать на C#", а не "чего нет в BCL .net"

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

S>Тема называется "что не сделать на C#", а не "чего нет в BCL .net"

Да оно понятно.

S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.
из принципиально невозможных разве что
-системы реального времени
-кроссплатформенность
-жизнь в ядре
-выская производительность (впрочем это наверное не навсегда)
из очень сложных — все что требует ручного управления памятью
-скажем шаред кэш каких-то сложных структур данных, разделяемый между несколькими процессами
-шаред-мемори провайдер к БД
-оптимизация размещения в памяти (см http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf)

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

R>из очень сложных — все что требует ручного управления памятью
R>-скажем шаред кэш каких-то сложных структур данных, разделяемый между несколькими процессами
Интересно, а как подобное делается в том же С++?

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

A>Делается DLL, в ней выделяется общий для всех процессов сегмент памяти с помощью #pragma data_seg
Угу, ясно. Я так понял, MS не особо рекомендует этот способ, а Memory Mapped Files теперь поддерживаются и в BCL.

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

S>Что с фундаментальной точки зрения не сделать на C#, что сделаешь на C++.

Compile-time вычисления?

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

_>subj
_>И нечего сравнивать его C++

_>Microsoft из-за своей ревности к другим ОС резко ограничило распространение языка.
_>На это, уже сегодня, накладывается ограничение в распространении Windows как пользовательской ОС:
_>еще 5 лет назад, в руках у неумелой блондинки Linux мог оказаться только по недосмотру, а теперь пожалуйста -- Android.
http://www.mono-project.com/Main_Page
http://mono-android.net/
http://monotouch.net/

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

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

_>>subj
_>>И нечего сравнивать его C++

_>>Microsoft из-за своей ревности к другим ОС резко ограничило распространение языка.
_>>На это, уже сегодня, накладывается ограничение в распространении Windows как пользовательской ОС:
_>>еще 5 лет назад, в руках у неумелой блондинки Linux мог оказаться только по недосмотру, а теперь пожалуйста -- Android.
G>http://www.mono-project.com/Main_Page
G>http://mono-android.net/
G>http://monotouch.net/

А вот цитатка из википедии:

После заключения Microsoft договорённости с компанией Novell, платформа Mono была официально признана реализацией .NET на Unix-подобных операционных системах (Linux, Mac OS X и других). Однако договорённость касается только Novell и клиентов Novell; также технологии ASP.NET, ADO.NET и Windows.Forms не были стандартизированы ECMA/ISO, и использование их в Mono находится под угрозой юридических претензий со стороны Microsoft (претензии возможны только в странах, где существуют патенты на программное обеспечение). Mono предоставляет реализацию ASP.NET, ADO.NET и Windows.Forms, но в то же время рекомендует не использовать эти API.

Принятая в проекте лицензия на компилятор и другие программы — GNU GPL. Лицензия на среду исполнения и другие библиотеки — GNU LGPL. Лицензия на библиотеки классов — X11 License. Патенты на C#/CLI принадлежат Microsoft, и ведутся споры насчёт риска и допустимости роста зависимости от Mono или C#.

То есть с моно не все так гладко. Вы можете до умопомрачения прокачивать навыки в C#, но если однажды MS решит завязывать .net, то завяжут все и вы Mono. А если дела у Android пойдут в гору, то MS подаст в суд на Novell, чтобы закрыть разработчикам .net рынок любых других смартфонных ОС-ей кроме православной.

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

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

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

_>>>subj
_>>>И нечего сравнивать его C++

_>>>Microsoft из-за своей ревности к другим ОС резко ограничило распространение языка.
_>>>На это, уже сегодня, накладывается ограничение в распространении Windows как пользовательской ОС:
_>>>еще 5 лет назад, в руках у неумелой блондинки Linux мог оказаться только по недосмотру, а теперь пожалуйста -- Android.
G>>http://www.mono-project.com/Main_Page
G>>http://mono-android.net/
G>>http://monotouch.net/

_>А вот цитатка из википедии:

_>

_>После заключения Microsoft договорённости с компанией Novell, платформа Mono была официально признана реализацией .NET на Unix-подобных операционных системах (Linux, Mac OS X и других). Однако договорённость касается только Novell и клиентов Novell; также технологии ASP.NET, ADO.NET и Windows.Forms не были стандартизированы ECMA/ISO, и использование их в Mono находится под угрозой юридических претензий со стороны Microsoft (претензии возможны только в странах, где существуют патенты на программное обеспечение). Mono предоставляет реализацию ASP.NET, ADO.NET и Windows.Forms, но в то же время рекомендует не использовать эти API.

_>Принятая в проекте лицензия на компилятор и другие программы — GNU GPL. Лицензия на среду исполнения и другие библиотеки — GNU LGPL. Лицензия на библиотеки классов — X11 License. Патенты на C#/CLI принадлежат Microsoft, и ведутся споры насчёт риска и допустимости роста зависимости от Mono или C#.

_>То есть с моно не все так гладко. Вы можете до умопомрачения прокачивать навыки в C#, но если однажды MS решит завязывать .net, то завяжут все и вы Mono. А если дела у Android пойдут в гору, то MS подаст в суд на Novell, чтобы закрыть разработчикам .net рынок любых других смартфонных ОС-ей кроме православной.
Бред ты говоришь. Во-первых речь идет не про язык C# или виртуальную машину (они кстати стандартизированы в Ecma, так что какие патенты на C# — еще вопрос), а про конкретные библиотеки. Но на Android (и на iPhone, и на iPad) не было и никогда не будет ни ASP.NET, ADO.NET и Windows.Forms, так что нечего переживать.

Кстати в английской версией статьи нет второго параграфа, что ты процитировал, зато есть ссылка на Ecma-334 и Ecma-335.

Реально единственное где Microsoft может перекрыть кислород — не-Windows серверная разработка. Но и сейчас довольно мало выбирают *nix в качестве серверов для .NET приложений.

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

G>Бред ты говоришь. Во-первых речь идет не про язык C# или виртуальную машину (они кстати стандартизированы в Ecma, так что какие патенты на C# — еще вопрос), а про конкретные библиотеки. Но на Android (и на iPhone, и на iPad) не было и никогда не будет ни ASP.NET, ADO.NET и Windows.Forms, так что нечего переживать.
G>Кстати в английской версией статьи нет второго параграфа, что ты процитировал, зато есть ссылка на Ecma-334 и Ecma-335.

А это ничего, что для C# версий 3 и 4 ECMA/ISO нет?
Этому есть только одно объяснение — они планируют оформить GPL.

G>Реально единственное где Microsoft может перекрыть кислород — не-Windows серверная разработка. Но и сейчас довольно мало выбирают *nix в качестве серверов для .NET приложений.

Они могут перекрыть кислород в любом месте когда захотят. Однажды, во всех Windows, начиная с версии 1X не будет фрэимворка.

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

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

G>>Бред ты говоришь. Во-первых речь идет не про язык C# или виртуальную машину (они кстати стандартизированы в Ecma, так что какие патенты на C# — еще вопрос), а про конкретные библиотеки. Но на Android (и на iPhone, и на iPad) не было и никогда не будет ни ASP.NET, ADO.NET и Windows.Forms, так что нечего переживать.
G>>Кстати в английской версией статьи нет второго параграфа, что ты процитировал, зато есть ссылка на Ecma-334 и Ecma-335.

_>А это ничего, что для C# версий 3 и 4 ECMA/ISO нет?
Ничего. А что страшного? Для С++ вообще ничего нет ECMA/ISO.

_>Этому есть только одно объяснение — они планируют оформить GPL.



G>>Реально единственное где Microsoft может перекрыть кислород — не-Windows серверная разработка. Но и сейчас довольно мало выбирают *nix в качестве серверов для .NET приложений.

_>Они могут перекрыть кислород в любом месте когда захотят. Однажды, во всех Windows, начиная с версии 1X не будет фрэимворка.
А зачем? Какой им с этого профит?

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

G>Ничего. А что страшного? Для С++ вообще ничего нет ECMA/ISO.

Для C++ есть ANSI/ISO стандарт, а для C# версий 3 и 4 стандарта нет.

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

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

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

G>>>Бред ты говоришь. Во-первых речь идет не про язык C# или виртуальную машину (они кстати стандартизированы в Ecma, так что какие патенты на C# — еще вопрос), а про конкретные библиотеки. Но на Android (и на iPhone, и на iPad) не было и никогда не будет ни ASP.NET, ADO.NET и Windows.Forms, так что нечего переживать.
G>>>Кстати в английской версией статьи нет второго параграфа, что ты процитировал, зато есть ссылка на Ecma-334 и Ecma-335.

_>>А это ничего, что для C# версий 3 и 4 ECMA/ISO нет?
G>Ничего. А что страшного? Для С++ вообще ничего нет ECMA/ISO.

_>>Этому есть только одно объяснение — они планируют оформить GPL.
G>
Это сарказм

Да, кстати, Oracle ведь подал в суд на Google за Java в андроиде. Если захотеть, то ECMA можно и отозвать =)

G>>>Реально единственное где Microsoft может перекрыть кислород — не-Windows серверная разработка. Но и сейчас довольно мало выбирают *nix в качестве серверов для .NET приложений.

_>>Они могут перекрыть кислород в любом месте когда захотят. Однажды, во всех Windows, начиная с версии 1X не будет фрэимворка.
G>А зачем? Какой им с этого профит?

Будет новая технология. Нужно ведь как-то продавать новые версии Windows. А для этого нужно вводить что-то новое и убирать поддержку страрого.
А то дай юзерам волю -- будут сидеть под XP еще 10 лет.

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

_>Будет новая технология. Нужно ведь как-то продавать новые версии Windows. А для этого нужно вводить что-то новое и убирать поддержку страрого.
_>А то дай юзерам волю -- будут сидеть под XP еще 10 лет.

Кстати, согласно http://gs.statcounter.com/#os-na-monthly-201005-201105
В пршлом месяце свершилось: В Win7 таки стало больше чем XP, в NorthAm. .
А MacOSX за год вырос с 11.1% до 14.1%