Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
V>>>Поэтому, в спецификациях требований к окружению такой программы надо писать не <CLR 2.0.х>, а <.Net 3.5 SP1>. Разницу ощутил? S>>А как же multitargeting при разработке? S>>Скопиленное на платформе .Net3.5sp1 под 2.0 пойдет на 2.0 гарантированно? Или к 2.0 надо свои другие фиксы ставить?
V>Именно привел пример, когда гарантированно не пойдет. Конкретные классы и методы: V>Socket.AcceptSync(), Socket.ConnectSync(), и прочие xxxAsync() а так же сам класс SocketAsyncEventArgs.
Очевидно речь идет о методах Socket.AcceptAsync, Socket.ConnectAsync и т.п. Потому как об AcceptSync нет никаких упоминаний.
Эти новые методы были введены в Supported in: 3.5, 3.0 SP1, 2.0 SP1
Т.е. разрабатывая под 3.0 SP1 и используя эти методы мы получаем бинарник, которому нужен 2.0 SP1 для запуска. Если мы не хотим терять совместимость с 2.0 без sp1, то не используем. И все дела.
V>Была еще куча мелких примеров, но мы не записывали, а просто написали в требованиях <MS .Net FW 3.5 SP1>.
?
Если можно конкретнее...
C>Вы можете ответить какое отношения номера версий сборок имеют к CLR и JIT-оптимизациям???
CLR без FW не существует и обратное тоже верно, CLR слишком сильно завязан не только на спецификацию метаинформации и систему типов, но и на сами конкретные типы из FW. И обновляться это может только в сборе.
ОК, конкретно джит — составляющая часть "механики" CLR, платформы исполнения, так же как и GC и система ресолвинга и загрузки сборок и еще куча другой требухи. По доходившим до нас сведениям и по результатам анализа результата джиттинга, мы видели, что джит-таки развивается. Субъективно я так же обратил внимание, что и GC стал практически не заметен на глаз (он тоже не может быть не завязан на джит). Поэтому и утверждаю, что CLR изменялся. А в исходном посте заметил, что среди прочих изменений не было кое-каких, обсуждаемых ранее на форуме и интересных мне по работе. Где тут криминал-то?
C>Не можете. Потому что Вы банально "съхали с темы".
Да ничего не съехал. Не споря с тем, что версия спецификации не поменялась (потому как и не утверждал подобного, это был сугубо твой закидон), продолжаю утверждать, что реализация этой спецификации менялась постоянно и вполне честно остаюсь при своём.
Короче, снова предлагаю ставить точку. Своё мнение ты, слава богу, наконец озвучил здесь
P> P>>типов проверок !!!! ЧЕГО .. P> P>> мощная статическая проверка типов ..это 0 который делает из 1 десятку
P> G>
P> G>A a;
P> G>B* b = (B*)((void*)&a)
P> G>
P> G>Где тут сильные проверки?
P> G>Лучше сразу напиши что был неправ иначе заклюют.
P> тут их нет конечно же, это пример сознательного обхода проверок,
Мощная система проверки типов просто не позволила бы сделать такой финт ушами
P> есть полноценные указатели
Что такое полноценные указатели?
P> и void*
Который нужен зачем?
P> , совместимость с С и это здоровская вещь на самом деле ...
Любой современный язык имеет возможность вызывать функции из С-кода
P> понимаешь.. как тебе объяснить .. "нож хорош для того, у кого он есть, и плох для того, у кого он в нужный момент не оказывается под рукой" .
P> P>>весь пост не читал, только начало зацепил, вставлю свои 5 центов : тут чет про кросплатформенность много пишут там и прочий валюнтаризм .. мне кажется, дело в области применении задачи, наверное программу управления кардиодатчиком хирургического стола все же стоит писать на C++ ввиду сильного механизма проверок , а дрочилку отчетов овощной базы на рынке можно и на шарпах забомбить и она тож будет великолепна ..
P> G>Сильных проверок чего?
P> типов проверок !!!! ЧЕГО .. P> мощная статическая проверка типов ..это 0 который делает из 1 десятку
Нет в С++ мощной статической проверки типов. С++ — это слаботипизированый язык со статической типизацией
Здравствуйте, samius, Вы писали:
S>Очевидно речь идет о методах Socket.AcceptAsync, Socket.ConnectAsync и т.п. Потому как об AcceptSync нет никаких упоминаний.
Да (проклятый copy&paste и спешка).
S>Эти новые методы были введены в S>Supported in: 3.5, 3.0 SP1, 2.0 SP1 S>Т.е. разрабатывая под 3.0 SP1 и используя эти методы мы получаем бинарник, которому нужен 2.0 SP1 для запуска. Если мы не хотим терять совместимость с 2.0 без sp1, то не используем. И все дела.
Вот в том и прикол, что .Net 3.0 вышел раньше .Net 2.0 SP1, а если мы вели разработку на .Net 2.0 SP1, то получили бяку в Виста, которая идет с предустановленной .Net 3.0, и на которую .Net 2.0 SP1 не ставится никаким образом (если не ошибаюсь, туда и .Net 3.0 SP1 не ставится, не буду утверждать).
А что и как использовать — это сугубо технический вопрос, мы указали в требованиях .Net 3.5 и забыли.
S>Если можно конкретнее...
Не можно.
Было так: потрачено время на разработку классов, предоставляющих аналогичную ф-сть для сокетов для работы под .Net 3.0 и .Net 2.0 без SP, но потом выяснилась еще серия бяк (с сериализацией), и мы не стали заморачиваться и тупо проставили на висту 3.5 и забыли. Коль будет требование сделать нашу прогу под указанные предыдущие выпуски фреймворков, то будем копать глубже, разумеется, и обязательно поделюсь.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, samius, Вы писали:
S>>Очевидно речь идет о методах Socket.AcceptAsync, Socket.ConnectAsync и т.п. Потому как об AcceptSync нет никаких упоминаний.
V>Да (проклятый copy&paste и спешка).
S>>Эти новые методы были введены в S>>Supported in: 3.5, 3.0 SP1, 2.0 SP1 S>>Т.е. разрабатывая под 3.0 SP1 и используя эти методы мы получаем бинарник, которому нужен 2.0 SP1 для запуска. Если мы не хотим терять совместимость с 2.0 без sp1, то не используем. И все дела.
V>Вот в том и прикол, что .Net 3.0 вышел раньше .Net 2.0 SP1, а если мы вели разработку на .Net 2.0 SP1, то получили бяку в Виста, которая идет с предустановленной .Net 3.0, и на которую .Net 2.0 SP1 не ставится никаким образом (если не ошибаюсь, туда и .Net 3.0 SP1 не ставится, не буду утверждать).
Если так — действительно бяка. Пока не напарывались, но теперь будем внимательны при использовании фич из SP1. Делаем продукт под 2.0.
V>Коль будет требование сделать нашу прогу под указанные предыдущие выпуски фреймворков, то будем копать глубже, разумеется, и обязательно поделюсь.
Если будет уж что-то интересное...
А по субъективным впечатлениям — мне тоже показалось, что инлайнинг джита стал агрессивнее после выхода 2.0. Но подтвердить ощущения не могу. Специально заряжать машину под это дело не стану уж. Хотя если представится случай сравнить, будет интересно попробовать.
Здравствуйте, Mamut, Вы писали:
P>> P>>весь пост не читал, только начало зацепил, вставлю свои 5 центов : тут чет про кросплатформенность много пишут там и прочий валюнтаризм .. мне кажется, дело в области применении задачи, наверное программу управления кардиодатчиком хирургического стола все же стоит писать на C++ ввиду сильного механизма проверок , а дрочилку отчетов овощной базы на рынке можно и на шарпах забомбить и она тож будет великолепна ..
P>> G>Сильных проверок чего?
P>> типов проверок !!!! ЧЕГО .. P>> мощная статическая проверка типов ..это 0 который делает из 1 десятку
M>Нет в С++ мощной статической проверки типов. С++ — это слаботипизированый язык со статической типизацией
вы гдет надергали каких т стереотипных лозунгов, спорить какт бесполезно
приговариваетесь к пожизненному чтению <The C++ Programming Language by Bjarne Stroustrup> с .. заменой на 3-х годичную установкe мелкософтовых патчей к MS.NET Framework
а человеку данную ветку родившему, по итогу все таки скажу не важно с чего вы начнете, с delphi к слову начинайте, и еще смотря как вы дальше планируете хлеб добывать :
— будете на себя работать — С++ в руки
— на контору планируете идти — шарп
P> P>> мощная статическая проверка типов ..это 0 который делает из 1 десятку
P> M>Нет в С++ мощной статической проверки типов. С++ — это слаботипизированый язык со статической типизацией
P> вы гдет надергали каких т стереотипных лозунгов, спорить какт бесполезно
Не стереотипных. Суровая правда жизни
P> приговариваетесь к пожизненному чтению <The C++ Programming Language by Bjarne Stroustrup> с .. заменой на 3-х годичную установкe мелкософтовых патчей к MS.NET Framework
Ггг. Ты бы в руки ругой какой-нибудь, кроме С++ вообще бы взял
Здравствуйте, Mamut, Вы писали:
s>> V>Была еще куча мелких примеров, но мы не записывали, а просто написали в требованиях <MS .Net FW 3.5 SP1>.
s>> ? s>> Если можно конкретнее...
M>Досатточно посотреть what's new: http://msdn.microsoft.com/en-us/library/bb332048.aspx
Действительно, часть изменений позиционируется как изменения в CLR, хотя некоторые из них имеют отношение только к FCL (типа HashSet).
Не совсем то, меня интересовало на что можно напороться разрабатывая под .net 2.0 в vs2008 студии со всеми сервис паками на дотнет. Для этого, по всей видимости, надо смотреть список изменений в .net 2.0 sp1. Только что заюзал неглядя один из новых конструкторов DynamicMethod Надо быть внимательнее.
Здравствуйте, Pepel, Вы писали:
P>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Pepel, Вы писали:
P>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, Pepel, Вы писали:
P>>>>>весь пост не читал, только начало зацепил, вставлю свои 5 центов : тут чет про кросплатформенность много пишут там и прочий валюнтаризм .. мне кажется, дело в области применении задачи, наверное программу управления кардиодатчиком хирургического стола все же стоит писать на C++ ввиду сильного механизма проверок , а дрочилку отчетов овощной базы на рынке можно и на шарпах забомбить и она тож будет великолепна ..
G>>>>Сильных проверок чего?
P>>>типов проверок !!!! ЧЕГО .. P>>> мощная статическая проверка типов ..это 0 который делает из 1 десятку
G>>
G>>A a;
G>>B* b = (B*)((void*)&a)
G>>
G>>Где тут сильные проверки?
G>>Лучше сразу напиши что был неправ иначе заклюют.
P>тут их нет конечно же, это пример сознательного обхода проверок, да, есть такой инструмент в С++, есть полноценные указатели и void*, совместимость с С и это здоровская вещь на самом деле ...
P>понимаешь.. как тебе объяснить .. "нож хорош для того, у кого он есть, и плох для того, у кого он в нужный момент не оказывается под рукой" .
Не надо объяснять. Не такая уж сильная типизация как тебе кажется.
Пример с union_ами приводить?
Здравствуйте, Pepel, Вы писали:
P>- будете на себя работать — С++ в руки
Много ли ты проектов на С++ сделал?
P>- на контору планируете идти — шарп
И сколько на шарпе?
Здравствуйте, samius, Вы писали:
V>>Вот в том и прикол, что .Net 3.0 вышел раньше .Net 2.0 SP1, а если мы вели разработку на .Net 2.0 SP1, то получили бяку в Виста, которая идет с предустановленной .Net 3.0, и на которую .Net 2.0 SP1 не ставится никаким образом (если не ошибаюсь, туда и .Net 3.0 SP1 не ставится, не буду утверждать). S>Если так — действительно бяка. Пока не напарывались, но теперь будем внимательны при использовании фич из SP1. Делаем продукт под 2.0.
Вроде как через Windows Update ставится самая последняя версия фреймворка, если стоит 2.0 и выше.
G>>Кроме того уже не за горами запуск числомолотилок на GPU, там тоже высокоуровневые языки будут более уместны, так как позволят генерить код для GPU в рантайме. CC>Занимаюсь я щас как раз GPU числомолотильней для финансовых расчетов.
А можно твой опыт поэксплуатировать?
Как насчет параллельного расчета многих задач, т.е. код один и тот же, но нужны сотни одновременных потоков, обрабатывающих свои данные этим кодом (например, это будут аудио-кодеки).
Здравствуйте, criosray, Вы писали:
C>http://en.wikipedia.org/wiki/Objective-C — во многих смыслах замечательное решение, а с недавних пор еще и автоматическая сборка муссора появилась (опционально).
Ты писал на нем реально? И как тебе синтаксис объявлений обычных классов, абстрактных или интерфейсов? Как тебе запись вызова методов?
Сборка мусора там далеко не на всех реализациях, и в отсутствии аналогов смарт-поинтеров получаем тот же гемморой, что и с голым С.
Здравствуйте, Хвост, Вы писали:
Х>логично, но меня всё же более интересовал вопрос о том, будут ли ети структуры существовать на стеке если они замкнуты.
Нет, они сразу располягаются в полях замыкания, и доступ к ним коссвенный, естественно, а на "стеке" они располагаются лишь в синтаксисе программы.
Надо быть внимательнее.
