Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, VladD2, Вы писали:
VD>>Понимаш ли, есть огромная разница между логическими ошибками и ошбками вроде описаной в теме. В Шарпе без ансэйва ты просто не сможешь повредить память, а в данном случае неверно поставленная скобка привела именно к повреждению памяти. И слава богу, что все было относительно безопасно. Как-то я видел намного более забавную ошибку. Человек в следствии сложных манипуляций возвратил их функции указатель на стековую переменную. Какое-то время код даже работал, а потом... потом были 2 недели поиска ошибки. GZ>Как-то пришлось подключать библиотеку, которая в своей функции удаляло строку, а потом создавала свою вместо нее. Долго разбирался. Сначала долго разбирался с ошибкой поскольку строку по незнанию я создавал в стеке. Потом долго выбивал из них, хотя бы скомпиленную библиотеку с msvcrt.dll, поскольку ихнюю строку должен был удалять уже я. Пробивать нормальный интерфейс от них по некоторым причинам было нельзя.
GZ>С уважением, Gleb.
Здравствуйте, srggal, Вы писали:
S>>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться AA>>Ну почему же? Если сильно постараться то получится: AA>>Singularity: A research OS written in C#
S>Спасибо за интересную ссылку, но все таки, оттуда:
Да я не спорю. Просто ты утверждал что написать драйвер на C# не получится (выделено). Я привел обратный пример. Пускай это и Research Project, но попытка предпринята была. Кто знает, какие выводи сделали из результатов этого проекта в MS.
Здравствуйте, Alexey Axyonov, Вы писали:
AA>Здравствуйте, srggal, Вы писали:
S>>>>А если серьезно, от опять же каждому своё — например написать драйвер на СШарп — не получиться AA>>>Ну почему же? Если сильно постараться то получится: AA>>>Singularity: A research OS written in C#
S>>Спасибо за интересную ссылку, но все таки, оттуда:
AA>Да я не спорю. Просто ты утверждал что написать драйвер на C# не получится (выделено). Я привел обратный пример. Пускай это и Research Project, но попытка предпринята была. Кто знает, какие выводи сделали из результатов этого проекта в MS.
Также я писал:
Точно также как и на Джаве, некоторые горячие головы ытались реалтизовать аппаратную поддержку Джава — спец- Джава процессоры и все такое, — ан не сильно получилось
И так я писал:
ИМХО: если язык появляется и активно используется в течении 4х лет — значит он нашел свою нишу среди других языков.
Причем первое процитированное — стало ясно не счерез 4е года спустя появления Лжава, позже.
Вывод: ИМХО пока говорить о C# OS — перждевременно.
И еще цитата с указанного Вами урла:
Beer28
beercosoftware.com custom linux solutions&software
galenh wrote:
This isn't the CLR. In our world, we compile entire MSIL for the kernel into x86 instructions
at installation time. There is no libc at the bottom.
However, we do have around some assembly code. Like a kernel written in C, our C# kernel needs
assembly code to handle the lowest part of the interrupt dispatch on the x86. But once the
assembly code has finished, it dispatches directly into compiled C# (no C). BTW, there is some C
code in the system, primarily for the debugger stub.
What are you using to compile the MSIL into x86?
how are you handling hardware interupts, and the interupt vector table and interupt service routines from C# code?
C# code has no way to interact with the bios. You can't drop into __asm { }; in C#.
I feel there is part of the story that is missing here.
Я разделю его мнение.
ЗЫ
Надеюсь, что мы не перейдем в спор о яйце и куритце, типа что на чем написано, это так, просто констатация факта
Здравствуйте, gear nuke, Вы писали:
GN>Здравствуйте, supersceev, Вы писали:
S>>кстати _T() это не конструкция языка — это макрос, который компилятор даже и не видит. S>>При чём здесь язык?
GN>Совершенно верно — ни при чём. GN>Каков смысл этого кода: GN>
в С++ ?
GN>Похоже, кто-то там на верху упорно даказывает разработчикам компилятора, что большенство людей используют его как С .
GN>Cделали бы cwindows в дополнение к windows.h, как поступили другие люди с остальными include. GN>В таком случае, подобной темы никогда бы не возникло.
Здравствуйте, VladD2, Вы писали:
Ш>>Влад, если ты не видишь, что пишешь, то никакой язык программирования тебе не поможет. НЕ спеши. Тише едешь -- дальше будешь.
VD>Я вижу что пишу. А от опечаток никто не застрахован. Что до языка, думаю, ты прекрасно понимашь, что никакой язык кроме С/С++ не пропустит такую лажу.
На самом деле, что-то в этом есть. В С++ полно "унаследованных" мест, которые ему вовсе не нужны. Ситуация с неверным числом аргументов макроса в т.ч.
Я бы перевел этот момент в разряд ошибок.
Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
— избавиться от const_cast, static_cast, reinterpret_cast, оставить лишь приведение в стиле С: (type_name)expression, но его семантику сделать эквивалентной нынешнему static_cast
— продолжая пред. пункт, запретить преобразование указателей и ссылок вниз по иерархии наследования новым оператором преобразования типа, т.е. от void* в т.ч. Разруливать подобные моменты впредь либо через dynamic_cast, либо через явные определения методов. Размеется, это создаст небольшие накладные расходы при работе с шаблонными базовыми классами, написанными в стиле ATL/WTL (пара лишних строк в исходниках), и тем не менее...
— в предыдущем пункте мы потеряли возможность произволдьной реинтерпретации памяти, однако иногда эта возможность все-таки нужна, например для тех же распределителей памяти... для сохранения возможности управления и явной реинтерпретации памяти достаточно оставить сигнатуры оператора void* operator new(size_t); и пр. с inplace new в т.ч., этого будет достаточно для реализаций STL и прочих boost.
------
Собственно, мне нравится в С++ сильная статическая типизация. По сравнению с тем же C# мне крайне редко приходлось отлаживать программы в пошаговом редакторе, используя С++. Еще немного более строгая типизация не повредила бы.
Понимаю, что тонны, просто тонны кода используют фичи, которые предлагается выкинуть или переписать... я думаю, всем от этого станет только лучше
------
проработать стандартную С-либу (не STL, а C RTL), всякие memmove, memcpy и прочие — убрать из С++. Ср-вами самого С++ их реализация станет невозможной. Останется только юзать STL. В результате избавимся сразу от нескольких классов UB, которые допускают программисты.
------
printf, va_list и пр. из этой оперы... жалко, согласен, однако "в топку". Переменное число аргументов сделать типизированным, наподобие реализации в С#.
IT>public abstract class Person : ObjectBase
IT>{
IT> [Required, MaxValue(50)] public abstract string FirstName { get; set; }
IT> [Required, MaxValue(50)] public abstract string LastName { get; set; }
IT> public abstract Gender Gender { get; set; }
IT> [MaxValue(100)] public abstract string Address { get; set; }
IT>}
IT>
В нашей системе мы выделенное в коде не описываем. В момент инициализации сопоставляем все подобные сущности с их описанием в БД, и эти ограничения выхватываем из схемы БД. Т.е. избавляемся от повторного описания ограничений.
Там же еще есть такие аттрибуты как:
— DefaultValue
— Format
и т.д.
Здравствуйте, Hydrogen, Вы писали:
H>>>AFAIK есть утверждение — "Более безопасная система менее удобна".
VD>>Можно ссылку на этот бред? H>Если Вы считаете это бредом, то ссылку не дам.
А чем еще можно считать постановку в один ряд несовместимых понятий?
Да и на примерах это бредовое утверждение рассыпается сразу. Возмем ДОС и Windows XP и сравним их с точки зрения удобства использования и безопасности. По обоим критериях ХРюша явно выигрывает. Другй пример, новая качественная иномарка и Жигули. Таких примеров можно привести бесчисленное множество.
H>В таком тоне говорите с вахтершами и кондукторами.
Ясно. Ну, ссылки на вахтерш меня действительно не интересуют.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, vdimas, Вы писали:
V>Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
Думаю, что выражу мысль большинства С++ программистов, которые в этом треде участвовали в обсуждении проблемы высосанной из пальца, но на всякий случай ИМХО:
Здравствуйте, srggal, Вы писали:
IT>>Сколько ты в своей жизни написал драйверов на C++?
S>ИМХО меряться размерами не мобильного телефона смысла не вижу, в дальнейшем подобные выпады оставляю без ответа.
А никто ничем и не меряется. Я тебе задал вопрос, ты на него ответил. Будем беседовать дальше
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>А никто ничем и не меряется. Я тебе задал вопрос, ты на него ответил. Будем беседовать дальше
Ок, просто это было как-то грубовато что-ли
Может Маня Величко о которой твердят большивики
Переставай дружить с Маней Величко. Это плохая подруга.
Вместо этого лучше представляй себе что разговаривашь с людми опыт которых как минимум не меньше твоего.
ЗЫ Приношу извинения за неправильную трактовку. И вот еще чот — писал отлько под Linux ядро 2.4
Здравствуйте, DJ KARIES, Вы писали:
DK>Интересно, зачем эти яйцеголовые изобретатели стандартов понаделали КУЧУ ЮНИКОДОВ? DK>Зачем MBCS/LowEndian/HiEndian/16bit/32bit разновидности юникода?
Ты не перечислил и 10-й части юникодных стандартов, их море.
DK>Идиотизм! DK>Нельзя было обойтись одним стандартным?
Эти стандарты разрабатывались и использовались независимо. Да, в те далекие времена на всем экономили, поэтому юникода не было. А потом он понадобился, но не сразу, и не всем, и не везде. И вот в разных странах/фирмах разрабатывались свои подпорки. Причем количество бит в этих подпорках поначалу было ну очень разное
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, vdimas, Вы писали:
V>>Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
S>Думаю, что выражу мысль большинства С++ программистов, которые в этом треде участвовали в обсуждении проблемы высосанной из пальца, но на всякий случай ИМХО:
S>
S>safe С++
S>Это и есть СШарп
Дудки. Добавьте в шарп зависимые типы, статические шаблоны, возможность иметь параметр шаблона базой, явное управление памятью (мне далеко не всегда нужен GC), указатели на члены (и на методы в т.ч.) и тогда это и будет "оно"
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, srggal, Вы писали:
IT>>>Сколько ты в своей жизни написал драйверов на C++?
S>>На С я написал 3 драйвера.
IT>Очень хорошо. А сколько ты написал не драйверов? Меня интересует соотношение, в строчках, в мегобайтах, в программах, в разах, всё равно.
Мысль понял, красивый ход.
Но строчки написанного системного ПО дорогого стоят
К ним предъявляются другие требование и, если верить клаччикам годои 70-80, то ППО 400 строк СПО 1 строка в день
В любом случае, понимая к чему Вы ведете, и имею Вам что сказать:
GZ>Есть задачи, для которых важно как я делаю. И в этом случае С++ неоценим. Но есть задачи где важнее что я делаю. И тут С# значительно продуктивнее чем С++. Потому как о многих вещах и не надо задумываться.
В ЯБЛОЧКО, т.е. одни решаем на одном языке вторые на втором, причем эти предпочтения субъективны. Ибо в силу того, что С++ я знаю лучше СШарп, то многие вещи мне проще сделать на С++, но могут быть люди у которых все наоборот.
От себя еще добалю, что при выборе предпочтительного языка реализации следует учитывать собственный уровень знания языка, а при самой реализации на выбраном языке писаьт надо острожно, если не чуствуешь себя НэтивСпикером
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, srggal, Вы писали:
S>>Здравствуйте, vdimas, Вы писали:
V>>>Далее, есть еще несколько уже давно устоявшихся мыслей по поводу введений в некий "safe С++":
S>>Думаю, что выражу мысль большинства С++ программистов, которые в этом треде участвовали в обсуждении проблемы высосанной из пальца, но на всякий случай ИМХО:
S>>
S>>safe С++
S>>Это и есть СШарп
V>Дудки. Добавьте в шарп зависимые типы, статические шаблоны, возможность иметь параметр шаблона базой, явное управление памятью (мне далеко не всегда нужен GC), указатели на члены (и на методы в т.ч.) и тогда это и будет "оно"
Ок, я понял Вашу точку зрения, теперб моё ИМХО
Аналогия:
Есть дикие собаки Динго, они независимы, довольно жестоки, и привыкли жить сами-по-себе.
И есть домашние пудели, они красивые, их надо стричь, кормить деликатесами и все такое.
Есть Люди которым импонируют собаки динго ( Я,например. ), есть люди, которым нравяться пудели ( к ним я равнодушен ).
Ещё есть зоопарки, в которых бывают собаки Динго в тесненьких вольерах. Это уже совсем не те собаки, которых показывают в программах про животных, они и внешне выглядят по-другому.
Кроме того, я подозреваю, что если бы ко мне попал в руки щенок динго, и я бы решил его вырастить, он бы не смог стать такой же собакой, как и прирученная взрослая особь.
Да к черту Динго, на даче у меня жил Пес Шарик ( точней он жил сам по себе, но рядом с моей дачей ), его кормило большинство дачников, когда я ночевал на даче, он ВСЕГДА спал исключительно под дверью моего дачного дома, я с ним игрался, он меня покусывал. Но когда я нечаянно наступил ему на лапу он меня сильно укусил, остались шрамы, после этого он скулил, просил прощения, было видно что ему непосебе, но я его и не наказывал ОН — дворовая собака, и должен был именно так поступить, — он такой как есть, и его не перделать.
Выводы:
Спросите к чему это, скажу — С/С++ это такая же дворовая собака которая такая уж есть, с ней можно играть, она может Вас покусывать, но если Вы ошибетесь, то могут остаться шрамы.
То что мы сейчас имеем — эот то, что было нужнно для выживания этой собаки в мире где уже до нее было много таких же собак. Чуть больше когтей чем у Бэйсик, чуть мягче шерсть чем у Ассемблер, за это я и люблю эту собаку.
Я люблю этот язык таким каким его делает комитет стандартизации И рад, что этот я зык есть.
Если он начнет идти в сторону Safe то это уже будет "дрессированный" язык, и совсем не тот, который мне нравится.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я не буду смеяться, но вроде бы в Unix был когда-то tool , который отлавливал несоответсвия всякие в С программах еще когда С++ не было. В частности, несоответствия между описанием функции и ее вызовом (если помнишь, в версии С Кернигана-Ритчи прототипов не было, а вызывать неописанную функцию в С даже сейчас компилятор позволит, предупреждение, правда, будет. Не исключаю, что и для C++ такие тулзы либо есть, либо их можно написать. Но мне они не нужны.
S>[q] S>Lint -- A C program verifier
Точно, мне и припоминалось это название. Но не был уверен, а K&R лежит дома где-то очень далеко.
Здравствуйте, IT, Вы писали:
IT>Судя по постам предыдущих товарищей каждая написанная на C++ строчка делает человека гениальней и увеличивает размер головного мозга в два раза. Представляешь до каких размеров разрослись мои полушария за 12 лет? Особенно левое. А если сюда добавить ещё 3 года до этого на чистом C? Там вообще был год за два. В общем, тяжело быть таким умным и гениальным.
Эхе-хе-хе. Что же мне тогда говорить с моим опытом программирования на Фортране ? Не иначе как мне просто должны за гениальность платить — даже если я вообще ничего делать не буду...
Не-а. Глубина падения и одновременно мощности С++ значительно больше.
Возьми к примеру наложение структуры на адрес в памяти. Чрезвычайно полезная фича в некоторых случаях, как и опасная. Или взять к примеру инициализацию структуры нулевыми значениями через memset. Ты уже ее уничтожил, а фича также очень полезная.
Можно запретить указатели, но это уже не будет С++.
Сначала долго разбирался с ошибкой поскольку строку по незнанию я создавал в стеке. Потом долго выбивал из них, хотя бы скомпиленную библиотеку с msvcrt.dll, поскольку ихнюю строку должен был удалять уже я. 
.
Если нам не помогут, то мы тоже никого не пощадим.
