Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>На java (C#) значит выпускаются только безглючные программы?
VD>Ну, объем глюков меньше в разы. И критичных просто мизер. В общем, при сравнимом скиле программистов разница на порядки.
Не свисти. Сказки будешь рассказывать в другом обществе.
Здравствуйте, VladD2, Вы писали:
ГВ>>Я не знаком с Shady, но ИМХО, Влад, ты несколько поспешно делаешь свои предположения. VD>В самый раз.
Ну да... на RSDN-философия свои нормы относительно своевременности преположений.
ГВ>>Или, это уже выводы? VD>Диагноз.
Не занимайся самолечением.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
ПК>> Generic programming куда?
VD>Нукуда заплатка проблем языка связанных со статической типизацией. У языков с динамической типизацией, как ты понимешь, подобных проблем вообще нет. В те времена когда эта статья писалась, может обобщенное программирование и было в новинку для языков со статической типизацией, но на сегодня это вообще не аргумент.
Пытаюсь разобраться что такое "статическая/динамическая типизация".
Слышал про "сильную/слабую типизацию" тут понятно, сильно типизированные языки строже следят за использованием типов в качестве других типов.
Например, C# и Java требуют явно указать тип при приведении "сверху вниз", C++ не требует. Он менее типизирован, но всё равно считается сильно типизированным.
Также слышал про "статическое/динамическое связывание" — время, когда происходит отождествление типа с методом. Статическое — во время компиляции, динамическое — во время выполнения. Благодаря динамическому связыванию существует полиморфизм. И опять же и в C# и в C++ есть динамическое связывание.
Что же такое "статическая/динамическая типизация". ?
Если я что-то напутал, поправь. Пытаюсь разобраться...
Здравствуйте, Шахтер, Вы писали:
Ш>Смех смехом, но всё вышеперечисленное -- действительно знаки разложения и деградации современного общества.
Ты будешь смеяться, но то же самое говорилось уже много раз за историю человечества — по совершенно разным поводам. Вероятно, сейчас мы находимся в крайней степени деградации и разложения, по сравнению с прошлым
VladD2,
> ПК> Пока что у меня к C# интерес исключительно академический, соответственно, особенно тратить время на упражнения с ним не хочется. > > Дык столько время тратится в баталях по его поводу... причем в основном идут обсуждения мифов. Глядишь 80% сналось бы само собой.
до C#... Честно говоря, после массированной рекламной компании я ожидал большего... Впрочем, пока не исключается вариант, что я чего-то не то в нем сделал. Любые предложения по исправлению кода с целью уменьшения тормозов — welcome.
Posted via RSDN NNTP Server 1.9
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Шахтер, Вы писали:
Ш>>Смех смехом, но всё вышеперечисленное -- действительно знаки разложения и деградации современного общества. Лучший способ защититься от изнасилований -- кастрировать всех мужчин при рождении. Что нам поборники .Net и предлагают.
Смех смехом, но если серьезно...
В развитии любой профессии всегда имеет место переход от искусства к ремеслу.
То, что было уделом мастеров-одиночек, постепенно становится массовым промыслом — как в результате общего прогресса технологий, так и в результате обычного увеличения численности так называемых sapiens'ов. В местах, доступных ранее лишь отчаянным альпинистам, вырастают башни фуникулеров; мастерство огранки бриллиантов ставится на конвейер, и безымянные тети пытаются заменить собой Фаберже.
Однако, как известно, при увеличении численности населения общее количество ума на планете не прибавляется (шутка со значительной долей истины). И некий "средний уровень интеллекта по профессии" неизбежно падает. Так что развитие "рабочих инструментов" в сторону упрощения их использования, увеличения мощности и соответствующего ограничения гибкости — закономерно и неизбежно. А уж считать плюсы/минусы от последствий этого явления — дело десятое, и я не понимаю, почему это становится предметом многочисленных holy wars. Подняться на гору на фуникулере легче, но не везде можно поставить фуникулер. Безопасность альпиниста находится на его собственном попечении — а безопасность поднимающегося на фуникулере зависит от производителя тросов, двигателей; и т.д., и т.п.
В любом случае, места на планете пока хватает всем. В крайнем случае, если уж альпинистов зажмут окончательно, могу предложить совершенно свежую горку — 22 км — на Марсе .
Единственное, что меня действительно раздражает — простота использования современных инструментов провоцирует неоправданное "чувство величия" и мастерства там, где им и не пахло. Накидавший десяток разноцветных кнопочек на форму шкет мнит себя создателем "крутой аппликухи". У меня это в первую очередь ассоциируется с надписями "Киса и Ося здесь были" и побитыми бутылками в местах, в которых еще недавно "не ступала нога идиота". Ощущения омерзительные.
Все, что здесь сказано, может и будет использоваться против меня...
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Влад, это уже просто абзац. Сначала ты просишь перечислить, что именно есть в boost, чего нет в .Net. После того, как я это делаю, ты просто отмахиваешься. Если тебе есть, что сказать по этому поводу — скажи. В противном случае лучше молчать.
Ну, нет у меня желания (а главное времени) разбираться с каждым мелким классом и искать ему соотвествие или объяснять почему в дотнете это делается по другому или вообще не нужно.
Если хочешь задавай вопросы по одному и объясняй почему ты считашь что это нужно. Тогда я потихоничку отвечу. А делать огромную работу на пустом месте... уволь.
Если хочешь напишу тебе программу которая сгенерирует списк классов фрэймворка и ты попыташся найти им соотвествие в бусти или СТЛ. Как тебе такая перспективка?
>> ПК> Я сравнительно недавно описывал как раз такую: http://rsdn.ru/Forum/Message.aspx?mid=650616&only=1
Так открывается, но я уже потерял контекст. О чем ты?
ПК>То же самое верно и для других ошибок: исключение точно так же может снести все приложение и данные пользователя.
Нет. Не врено. И объем ошибок, и их критичность, и друдность их обраружения в менеджед коде намного ниже. Особенно это хорошо ощущается кодгда после года программирования на Шарпе пыташся слабать нечто на С++. Возникает чувство что тебе отрезали крылья.
ПК>"Ох уж мне эти сказки, ох уж мне эти сказочники". Все эти ошибки были не моими, а в чужом коде. В проекте, который уже существует лет десять. К которому я присоединился всего пол-года назад. В самых старых частях его кода.
Ну, то-есть ошибка ловилась не 4 часа, а прожила в проекте много лет и никто не мог ее не то что поймать, но даже обраружить примерное место? И кому ты пыташся внушать, что проблем нет?
ПК>То есть к "найти свою ошибку в сто раз проще" это вообще не относится.
Возможно. Но ты возьмешся спорить с этим утверждением?
ПК>Я прекрасно представляю пределы возможностей автоматизированных средств анализа кода. Большинство вещей, на которые у меня идет время при разработке на C++, находится за этими пределами. Обычно это непонимание, что одна функция на самом деле представляет собой две или более семантически различных операции.
И эта проблема в Шарпе не так страшна. Есть рефакторинг, код чище, есть средства навигации (которые никогда не глючат), есть крутой рантайм который позволяет уростить отладку и понимание, и (возможно одно из главных) есть возможность поглядеть в чужой библиотечный код (библиотеки то декомпилируются).
ПК> По формальным признакам, какая из операций должна быть в каком из мест, где используется данная функция, определить невозможно.
Кому как. Я открываю Рефлектор и прошу показать мне список мест откуда функция вызывается.
ПК> Соответственно, чтобы перелопатить код, нужно пройтись по каждому из случаев, и "глазками" определить, какая из новых двух функций должна использоваться в каждом из случаев.
Не. Глазками — это не наш метод.
>> Это каких же? Никак отсуствие строгой типизации, обязательного объявления переменных, десятикрантый проигрыш в скорости?
ПК>В данном случае речь шла о приемах функционального программирования, по которым Питон, на мой взгляд, далеко "обходит" C#.
Примеры, в студию, чего можно сделать функционального на питоне, и нельзя на Шарпе 2.0.
ЗЫ
Вообще-то я думал познакомпвшись с обобщенными делегатами ты такие фразы бросать не будель.
В Питоне есть только одно приемущество (а может и недостаток) там поддержка коллекций встроена в язык и имеется более краткий синтаксис для работы с ними. Судя по твоим словам о том, что встраивать в язык то что можно сделать библиотеками не верно, я делаю выводы о двойных стандартах.
... << RSDN@Home 1.1.4 beta 3 rev. 273>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2,
> ПК> Сначала ты просишь перечислить, что именно есть в boost, чего нет в .Net. После того, как я это делаю, ты просто отмахиваешься.
> Ну, нет у меня желания (а главное времени) разбираться с каждым мелким классом и искать ему соотвествие или объяснять почему в дотнете это делается по другому или вообще не нужно.
В общем "Пастернака я не читал", но:
В бусте одни заплатки дыр языка.
и
Почи все перечисленное тобой есть или в языке или в библиотеках. Исключения составляют graph и фичи связанные с метапрограммированием.
Многое из перечисленного — далеко не "мелкие классы", а целые библиотеки.
> ПК> "Ох уж мне эти сказки, ох уж мне эти сказочники". Все эти ошибки были не моими, а в чужом коде. В проекте, который уже существует лет десять. К которому я присоединился всего пол-года назад. В самых старых частях его кода.
> Ну, то-есть ошибка ловилась не 4 часа, а прожила в проекте много лет и никто не мог ее не то что поймать, но даже обраружить примерное место?
Никто и не пытался, т.к. раньше эта ошибка не проявлялась. Нашли и устранили, как только она начала проявляться.
> ПК> То есть к "найти свою ошибку в сто раз проще" это вообще не относится.
> Возможно. Но ты возьмешся спорить с этим утверждением?
Нет, просто показываю, что оно никак не изменяет того, что я говорил. Разве что, если его принять за истинное, то, стало быть, если, вдруг, я допущу ошибку с проходом по памяти, то искать я ее буду в сто раз проще, чем описанные выше
> ПК> Большинство вещей, на которые у меня идет время при разработке на C++, находится за этими пределами. Обычно это непонимание, что одна функция на самом деле представляет собой две или более семантически различных операции.
> И эта проблема в Шарпе не так страшна. Есть рефакторинг, код чище <...>
Будет ли "код чище" не от языка зависит, а от автора. В смысле, конечно, неряшливому программисту в C++ есть где разойтись и накрутить чего попало, но и аккуратному C++ дает как минимум не меньше возможностей для "красивой" организации своего кода, чем C# или Java. Я предпочитаю по возможности работать с последними вне зависимости от используемого языка.
> ПК> По формальным признакам, какая из операций должна быть в каком из мест, где используется данная функция, определить невозможно. > > Кому как. Я открываю Рефлектор и прошу показать мне список мест откуда функция вызывается.
Это ровным счетом ничего не скажет, какая же из двух новых функций должна вызываться в том месте, пока код вокруг старого вызова не будет проанализирован программистом.
> ПК> В данном случае речь шла о приемах функционального программирования, по которым Питон, на мой взгляд, далеко "обходит" C#.
> Примеры, в студию, чего можно сделать функционального на питоне, и нельзя на Шарпе 2.0.
Вопрос не в может/не может, а в легкости реализации и использования. В противном случае можно вспомнить реализацию лямбда-выражений шаблонами C++ и утверждать, что C++ поддерживает функциональное программирование не хуже Питона Одно даже отсутствие в C# "свободных" функций здорово осложняет функциональщину, т.к. функции автоматически перестают быть first class citizens.
Или ленивые вычисления (ну-ка, насколько легко, если вообще возможно, организовать такую краткость записи и простоту работы с подобными вещами на C#?):
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>В общем "Пастернака я не читал", но:
ПК>
В бусте одни заплатки дыр языка.
ПК>и ПК>
Почи все перечисленное тобой есть или в языке или в библиотеках. Исключения составляют graph и фичи связанные с метапрограммированием.
Ну, не надо этой дешевой демагогии. А? Я же сказал. Проводить день за описанием мне не охота. А потом не охота объяснять почему разные спириты это маразм и почему нужно использовать полноценные генераторы парсеров или вообще другие решения.
ПК>Многое из перечисленного — далеко не "мелкие классы", а целые библиотеки.
Пашь, я не великий знакто Буста, но в основном понимаю предназначения описанных тобой классов и библиотек. Если отвечать в двух словах, то я уже все сказал. Приведенные тобой классы делятся на два класса а) средства метапрограммирования которых нет, но для которых есть замена, и б) то что есть во фрэймворке или решается неким другим способом. Все что во фрэймворке нехватает к нему дописывается сторонними авторами. И уверяю тебя объем библиотек на много больше чем у плюсов. Сюда же еще можно прибавить портирование решения с Явы где вообще наблюдается взрыв ислледовательских проектов.
Вот интересно, ты слышал когда нибудь о IOC-контейнерах?
В общем, сравнение библиотек явно не пойдет плюсам на пользу. А их качества и подавно. По удосбтсву плюсовые библиотеки просто чудовшьны. Попросуй найти хотя бы аналоги примитивным классам из пространства имен System.IO. Да все что нужно можно "нагрести", но черт возьми насколько же это все убого и неудобно!
ПК>Никто и не пытался, т.к. раньше эта ошибка не проявлялась. Нашли и устранили, как только она начала проявляться.
Ага. И случаев когда заказчики жалуются на время от времени появляющуюся непонятную бяку у тебя в жизни тоже не случались (с последующими, безуспешнцми, попытками воспроизвести эту бяку)?
Я бы тебе поверил если бы сам через это не проходил. Я видел как у людей даже нервы сдавали, и они говорили, что "лучше все переписать по нвой".
ПК>Будет ли "код чище" не от языка зависит, а от автора.
Боюсь тебя огорчить, но и от языка тоже. Хотя, безусловно, от авторов это зависит не меньше.
ПК> В смысле, конечно, неряшливому программисту в C++ есть где разойтись и накрутить чего попало,
И "ряшлевому" тоже. Возможно идеальному программисту все не почем. Но я вот таких еще не встречал. Кстати, и ты, и я к их числу тоже не принадлежим. Возможно ты более акуратен, а умудряюсь избегать гор проблем применением жустких паттернов, но все это только снижает риск. Причем за одно это резко снижает производительность. Ну, и опять же 100%-нл квалифицированные кадры это низбыточная мечта. В Москве уже хорошего дотнет-ного программиста за 1000 баксов хрен найдешь, а С++-ника и подавно.
ПК> но и аккуратному C++ дает как минимум не меньше возможностей для "красивой" организации своего кода, чем C# или Java. Я предпочитаю по возможности работать с последними вне зависимости от используемого языка.
Я Явой?
Что же до возможностей "крассивой"... то это в тебе говорят привычки. Я вот пописал на Шарпе и нажожу его значительно более выразительным и красивым. Да, в чем-то ограниченным, но именно что выразительным и красивым.
>> ПК> По формальным признакам, какая из операций должна быть в каком из мест, где используется данная функция, определить невозможно. >> >> Кому как. Я открываю Рефлектор и прошу показать мне список мест откуда функция вызывается.
ПК>Это ровным счетом ничего не скажет, какая же из двух новых функций должна вызываться в том месте, пока код вокруг старого вызова не будет проанализирован программистом.
Ну, писать надо так чтобы часами не думать над строчкой кода.
ПК>Вопрос не в может/не может, а в легкости реализации и использования.
Дык о проблемах в легкости ты даже боиш заикаться. Все какими-то намеками...
ПК> В противном случае можно вспомнить реализацию лямбда-выражений шаблонами C++ и утверждать, что C++ поддерживает функциональное программирование не хуже Питона
Да уж. То что это так не даже ты не возьмешся утверждать.
ПК> Одно даже отсутствие в C# "свободных" функций здорово осложняет функциональщину, т.к. функции автоматически перестают быть first class citizens.
Ну, то что это домыслы я уже не раз говорил. По жизни, нет никакой разницы между статическими методами и функциями.
ПК>Далее, пример: ПК>
Мля, Паш, может ты сам будешь изучать новый язык, а не строить домыслы? В общем, в этот раз я тебе привожу аналог, но дальще уж просба не включать демагогию если я тебя пошлю писать код самостоятельно. ОК?
Сори если чего не так понял, во всех этих трехбуквенных именах я не силен...
using System;
using System.Collections.Generic;
using System.Text;
class Program
{
static void Main(string[] args)
{
int[] intArray = { 1, 3, 5, 8 };
string[] atrArray = { "one", "two", "three", "eight" };
FuncLib.PrintList(FuncLib.Zip<int, string>(intArray, atrArray));
}
}
Консольный вывод:
[(1, one), (3, two), (5, three), (8, eight)]
Код реализации требуемой лабуды:
/// <summary>
/// Класс предназначенный для объеденения двух элементов в
/// один логический.
/// </summary>public class Tuple<T1, T2>
{
public Tuple() { }
public Tuple(T1 elem1, T2 elem2)
{
Elem1 = elem1;
Elem2 = elem2;
}
public T1 Elem1;
public T2 Elem2;
public override string ToString()
{
return"(" + Elem1 + ", " + Elem2 + ")";
}
}
public static class FuncLib
{
/// <summary>
/// Реализация Zip для двух аргументов.
/// </summary>public static IEnumerable<Tuple<T1, T2>> Zip<T1, T2>(
IEnumerable<T1> list1, IEnumerable<T2> list2)
{
IEnumerator<T1> en1 = list1.GetEnumerator();
IEnumerator<T2> en2 = list2.GetEnumerator();
while (en1.MoveNext() && en2.MoveNext())
yield return new Tuple<T1, T2>(en1.Current, en2.Current);
}
/// <summary>
/// Печать элементов списка в Питоновском стиле.
/// </summary>public static void PrintList<T>(IEnumerable<T> list)
{
StringBuilder sb = new StringBuilder();
sb.Append("[");
foreach (T value in list)
{
string str = value as string;
sb.Append(value);
sb.Append(", ");
}
if (sb[sb.Length - 1] == ' ')
sb.Length -= 2;
sb.Append("]");
Console.WriteLine(sb);
}
}
ПК>Или ленивые вычисления
А что они в Питоне есть? Ну, да итераторы и стэки всегда легко и эффективно решали проблему линивых вычислений.
К примеру, если массивы в предыдущем примере заменить на динамические энумераторы, то будут тебе более чем линивые вычисления.
ПК> (ну-ка, насколько легко, если вообще возможно, организовать такую краткость записи и простоту работы с подобными вещами на C#?): ПК>
В общем, у Шарпа более чем достаточно фунициональных возможностей чтобы писать в этом стиле когда это удобно. Уж точно больеш чем у плюсов. Ну, а Питому до того же Руби в некоторых областях просто как до Пикина раком.
Мне вот интересно, можно ли на Питоне "выглядывать" из функционалов как это можно в Руби и Шарпе:
static void Main(string[] args)
{
int[] intArray = { 1, 3, 5, 8 };
string[] atrArray = { "one", "two", "three", "eight" };
FuncLib.PrintList(FuncLib.Zip<int, string>(intArray, atrArray));
intinnerVar = 10;
Console.WriteLine(Test(intArray, delegate(int elem) { return elem * innerVar; }));
}
delegate int Operation(int arg);
static int Test(IEnumerable<int> list, Operation operation)
{
int sum = 0;
foreach (int var in list)
sum += operation(var);
return sum;
}
>> В Питоне есть только одно приемущество (а может и недостаток) там поддержка коллекций встроена в язык и имеется более краткий синтаксис для работы с ними. Судя по твоим словам о том, что встраивать в язык то что можно сделать библиотеками не верно, я делаю выводы о двойных стандартах.
ПК>В Питоне, как ты можешь видеть выше, и библиотеками можно сделать в плане функциональщины побольше, чем в C#.
Да не особо-то, как ты можешь видеть выше.
По крайней мере основные черты "функционельщины" Шарп уже почерпнул из того же Питона и Руби. А вот С++ в этом плане нервно курит в сторонке. Ну, и понятно что в отличии от Руби и Питона я не обязан платить тнтерпретацией и отсуствием статической типизации за предоставляемые ими возможностями (а значит кучей рантайм ошибок и более чем десятикратным замедлением кода).
Естественно Шарп не ФЯ. И было бы странно если универсальный язык был бы в этом плане круче чем ФЯ. Но то что есть выглядит очень неплохо.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>И уверяю тебя объем библиотек на много больше чем у плюсов.
Однако тот же Янус до сих пор использует меню, которое неправильно рисуется. Про жуткие проблемы с фокусом и вообще модальными окнами я и не говорю. Это от обилия библиотек или как?
Надеюсь утверждать, что GUI библиотек по сравнению с остальными пишеться мало ты не станешь.
Вообще утверждать, что у языка которому пара лет от роду объём библиотек больше, чем у плюсов нелепо.
VD>Вот интересно, ты слышал когда нибудь о IOC-контейнерах?
И я не слышал. А ещё неуловимого Джо никто не поймал, потому что он нафиг никому не нужен
IOC это для меня input-output completion. Ничего другого MSDN не выдаёт.
VD>В общем, сравнение библиотек явно не пойдет плюсам на пользу. А их качества и подавно. По удосбтсву плюсовые библиотеки просто чудовшьны. Попросуй найти хотя бы аналоги примитивным классам из пространства имен System.IO. Да все что нужно можно "нагрести", но черт возьми насколько же это все убого и неудобно!
В System.IO некоторая логическая группа (а меня спросить — свалка) классов. В Си++ этот набор не нужен, там всё делается по-другому.
Как минимум всегда есть два варианта Platform Specific и Portable.
VD>Ага. И случаев когда заказчики жалуются на время от времени появляющуюся непонятную бяку у тебя в жизни тоже не случались (с последующими, безуспешнцми, попытками воспроизвести эту бяку)?
Случается. Но у меня это в 99% случаев это проблемы совместимости со скачанными из Интернета удобными часами от Васи Пупкина, которые вешают глобальный хук на всё подряд невесть зачем.
VD>Я бы тебе поверил если бы сам через это не проходил. Я видел как у людей даже нервы сдавали, и они говорили, что "лучше все переписать по нвой".
Сам видел. Верю — знаю. Но как правило ошибка, если и была, была очень простой и логической (из разряда не отписался от сообщения).
И чтоб её найти надо пойти погулять и подумать, а не паниковать и перебирать весь код только увеличивая стресс.
ПК>>Будет ли "код чище" не от языка зависит, а от автора. VD>Боюсь тебя огорчить, но и от языка тоже. Хотя, безусловно, от авторов это зависит не меньше.
Например сейчас пишу на C# и мне трудно подбирать имена переменным. Naming Convention классов и переменных во многом пересекается, хотя писать что-то связанное с СОМ одно удовольствие.
ПК>> В смысле, конечно, неряшливому программисту в C++ есть где разойтись и накрутить чего попало, VD>И "ряшлевому" тоже. Возможно идеальному программисту все не почем. Но я вот таких еще не встречал. Кстати, и ты, и я к их числу тоже не принадлежим. Возможно ты более акуратен, а умудряюсь избегать гор проблем применением жустких паттернов, но все это только снижает риск. Причем за одно это резко снижает производительность. Ну, и опять же 100%-нл квалифицированные кадры это низбыточная мечта. В Москве уже хорошего дотнет-ного программиста за 1000 баксов хрен найдешь, а С++-ника и подавно.
Здравствуйте, adontz, Вы писали:
A>Однако тот же Янус до сих пор использует меню, которое неправильно рисуется.
Что значит не правильно? В Эксплорере тоже не правильно?
A> Про жуткие проблемы с фокусом и вообще модальными окнами я и не говорю.
Правильно. Не говори. Нет их.
A> Это от обилия библиотек или как?
Я не очень понял о чем ты.
A>Надеюсь утверждать, что GUI библиотек по сравнению с остальными пишеться мало ты не станешь.
Зачем? Правда для 3-ух летнего дотнета их уже намного больше чем для С++. Во втором фрэймворке есть вообще полноценные МС Офисные меню и тулбары. Как ты понимашь нахаляву.
A>Вообще утверждать, что у языка которому пара лет от роду объём библиотек больше, чем у плюсов нелепо.
И тем не менее это так. Нет, может объем кода который можно нарыть и сопоставим. Но вот охват явно шире длу дотнета.
VD>>Вот интересно, ты слышал когда нибудь о IOC-контейнерах?
A>И я не слышал. А ещё неуловимого Джо никто не поймал, потому что он нафиг никому не нужен A>IOC это для меня input-output completion. Ничего другого MSDN не выдаёт.
Нет. IOC — это Inversion of Control. Вот цитата из одной статьй опубликованной в нашем журнале "Технология Клиент-Сервер":
Концепция, лежащая в основе инверсии управления, часто выражается "голливудским принципом": "Не звоните мне, я вам сам позвоню". IoC переносит ответственность за выполнение действий с кода приложения на фреймворк. В отношении конфигурирования это означает, что если в традиционных контейнерных архитектурах наподобие EJB, компонент может вызвать контейнер и скзать:"где объект Х, нужный мне для работы?", то в IoC сам контейнер выясняет, что компоненту нужен объект Х, и предоставляет его компоненту во время исполнения. Контейнер делает это, основываясь на подписях методов (таких, как свойства JavaBean) и, возможно, конфигурационных данных в формате XML.
A>В System.IO некоторая логическая группа (а меня спросить — свалка) классов. В Си++ этот набор не нужен, там всё делается по-другому.
И я знаю как.
A>Как минимум всегда есть два варианта Platform Specific и Portable.
И оба требуют долгих часов лазенья по справке и Интернеру если ты не знаком с библиотекой. А тут все од рукой и очень удобно.
A>Например сейчас пишу на C#
Вау! Что-то меняется в этом ире.
A> и мне трудно подбирать имена переменным. Naming Convention классов и переменных во многом пересекается,
.
2. Научиться давать имена не переменным, а переменным в разрезе пространства имен, класса, переменной. Другими словами нужно отучиться впихивать в имя переменной весь смысл и выносить его в класс и простраство имен. Особенно это примечательно с энумами. Вместо myTypeSomeValue нужно давать имя MyType.SomeValue.
A> хотя писать что-то связанное с СОМ одно удовольствие.
Э... А какой кайф писать код без оглядуи на ком... Ух!!! Как сказал Дон Бокс дотнет — это КОМ на стеройдах. И я с ним согласен. Поддержка компонентного подхода в дотнете просто потрясающая. И никаких конфликтов с зяком или рантаймом.
A>1000 баксов говоришь?
Минимум. Народ из топа получает куда больше.
A>Еду к вам
Ну, если морду бить не будешь , то приезжай. Винца выпьем погутарим в живую.
... << RSDN@Home 1.1.4 beta 3 rev. 279>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
A>>Однако тот же Янус до сих пор использует меню, которое неправильно рисуется. VD>Что значит не правильно? В Эксплорере тоже не правильно?
Выделение в MenuBar У вас не стандартное
A>> Про жуткие проблемы с фокусом и вообще модальными окнами я и не говорю. VD>Правильно. Не говори. Нет их.
Однако они есть. Например так.
Выбрать Сервис\Синхронизация с сервером. Во время синхронизации нажать "отмена" (окно синхронизации остаёться почти навечно)
Если потом выбрать Сервис\Подписка на форумы, то оно будет модальным для обоих окон, хотя как показал Spy++ эти два окна никак не связаны.
VD>Зачем? Правда для 3-ух летнего дотнета их уже намного больше чем для С++. Во втором фрэймворке есть вообще полноценные МС Офисные меню и тулбары. Как ты понимашь нахаляву.
Они не особо-то managed и не ясно сколько займёт MsoCommandBar redistributable и кому он будет нужен такой большой учитывая, что такие монстры мало кому нужны.
A>>Как минимум всегда есть два варианта Platform Specific и Portable. VD>И оба требуют долгих часов лазенья по справке и Интернеру если ты не знаком с библиотекой. А тут все од рукой и очень удобно.
Как раз portable никаких часов не требует. Он стандартен для стандартных библиотек Си++.
A>>Например сейчас пишу на C# VD>Вау! Что-то меняется в этом мире.
Был выбор Си++/C# для конкретной задачи. Для конкретной же задачи С# оказался удобнее, хотя уже сейчас, на начальных этапах я вижу, что у Си++ возможностей было больше.
VD>1. Изучить Соглашения по оформлению кода команды RSDN
.
ОК.
VD>2. Научиться давать имена не переменным, а переменным в разрезе пространства имен, класса, переменной. Другими словами нужно отучиться впихивать в имя переменной весь смысл и выносить его в класс и простраство имен. Особенно это примечательно с энумами. Вместо myTypeSomeValue нужно давать имя MyType.SomeValue.
Ты будешь удивлён, но в Си++ тоже есть namespace'ы Так что с этим проблем нет
Здравствуйте, adontz, Вы писали:
A>Выделение в MenuBar У вас не стандартное
Рома, этой версии януса наверное уже года полтора. Меджиковское меню давным давно не используется.
A>Они не особо-то managed и не ясно сколько займёт MsoCommandBar redistributable A> и кому он будет нужен такой большой учитывая, что такие монстры мало кому нужны.
Не говори того, чего не знаешь. Тулбары в дотнете менеджед.
Здравствуйте, AndrewVK, Вы писали:
A>>Выделение в MenuBar У вас не стандартное AVK>Рома, этой версии януса наверное уже года полтора. Меджиковское меню давным давно не используется.
Позавчера скачал Янус с сайта в связи с рисованием иконок.
A>>Они не особо-то managed и не ясно сколько займёт MsoCommandBar redistributable A>> и кому он будет нужен такой большой учитывая, что такие монстры мало кому нужны. AVK>Не говори того, чего не знаешь. Тулбары в дотнете менеджед.
АВК, ты понял вообще, что я и Влад обсуждаем?
Влад сказал, что в Framework 1.0 будет поддержка тулбаров из MS Office, а онги совсем не managed. Я выразил сомнение, что такой траглодит кому-то нужен.
Здравствуйте, adontz, Вы писали:
A>Позавчера скачал Янус с сайта в связи с рисованием иконок.
Видать не тот.
A>>>Они не особо-то managed и не ясно сколько займёт MsoCommandBar redistributable A>>> и кому он будет нужен такой большой учитывая, что такие монстры мало кому нужны. AVK>>Не говори того, чего не знаешь. Тулбары в дотнете менеджед.
A>АВК, ты понял вообще, что я и Влад обсуждаем?
А ты?
A>Влад сказал, что в Framework 1.0 будет поддержка тулбаров из MS Office,
Во втором фрэймворке есть вообще полноценные МС Офисные меню и тулбары.
Один хрен. Пункт сервис должен быть вдавленным, а не подсвеченным.
AVK>А ты? A>>Влад сказал, что в Framework 1.0 будет поддержка тулбаров из MS Office, AVK>
Во втором фрэймворке есть вообще полноценные МС Офисные меню и тулбары.
Ну да, во втором. У меня опчатка. Но суть в том, что будут именно офисные, а они unmanaged.
