Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
 Re: Ну вот и дождались Юкона  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
c127
А Почему на .НЕТ-е они "больше не будут такими опасными"? А какими опасными они были, до сих пор?

Я бы спросил, по сравнению с чем. Если я правильно понимаю смысл слов in-process, .NET-хранимки будут падать вместе с сервером.
13 ноя 05, 10:51    [2063638]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
softwarer
Если я правильно понимаю смысл слов in-process, .NET-хранимки будут падать вместе с сервером.

Я думаю, что уж все же не с сервером, а с потоком (thread), в котором исполняется хранимка, если исходить из аналогий с 2000 сервером.
13 ноя 05, 12:43    [2063712]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
c127

Что такое "extended процедуры"? Я подозреваю что Вы зачем-то так называете сохраненки. А почему они опасны? По крайней мере почему написанные на .НЕТ-е они будут безопанее чем на ТСКЛ-е?


"extended процедуры" -- специальным образом оформленные модули, использующие специальное API и написанные как правило на С или С++.
Работают они в MSSQL (если еще ничего не поманяли в MS) в адресном пространстве самого сервера базы данных, т.е. это - .dll , подключаемые к процессу сервера. Нужно ли говорить еще что-то об их потенциальной "опасности" ?
13 ноя 05, 13:43    [2063751]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
softwarer
c127
А Почему на .НЕТ-е они "больше не будут такими опасными"? А какими опасными они были, до сих пор?

Я бы спросил, по сравнению с чем.


А я так и спросил:А Почему на .НЕТ-е они "больше не будут такими опасными".

softwarer

Если я правильно понимаю смысл слов in-process, .NET-хранимки будут падать вместе с сервером.


Или сервер вместе с сохраненками.



MasterZiv

"extended процедуры" -- специальным образом оформленные модули, использующие специальное API и написанные как правило на С или С++.
Работают они в MSSQL (если еще ничего не поманяли в MS) в адресном пространстве самого сервера базы данных, т.е. это - .dll , подключаемые к процессу сервера. Нужно ли говорить еще что-то об их потенциальной "опасности" ?


Да, согласен. А что, .НЕТ extended процедуры будут работать как-то по-другому? Наверняка тоже в том же пространстве.

Сторонники пошарпанного С утверждают, что их код компилируется в машинные коды и потому быстрый. Но в таком случае при выполнении на сервере он так же опасен, как С код из extended процедуры, там такие же указатели и прямой доступ к памяти. А если он в этом случае не будет компилироваться в машинные коды, то врядли получится выигрыш в скорости в сравнении с обычными сохраненками, который так пропагандирует Dooma.
14 ноя 05, 00:19    [2064364]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
MoonLight
Guest
c127
Да, действительно, ошибся. Все время забываю что имею дело со сторонником мелкософта,...
Смотря со стороны, хочется сказать: Удивительно, мы все забываем, что имеем дело с яростными противниками MS. Причем, действительно, создается такое ощущение, что очередной выход хорошего продукта от MS вызывает у них такие вопли, как буд-то бы им прищемили "причинные места" в дверях
Я бы, со своей стороны, предложил бы совсем игнорировать их вопли.
Я уже взывал здесь на форуме и еще раз повторюсь: оставте их в покое, пусть свято веруют в свои Oracle. Не порождайте в них сомнений! Чем больше они так думают, тем вам же потом лучше будет - конкурентов меньше.
14 ноя 05, 02:46    [2064466]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
MoonLight
c127
Да, действительно, ошибся. Все время забываю что имею дело со сторонником мелкософта,...
Смотря со стороны, хочется сказать: Удивительно, мы все забываем, что имеем дело с яростными противниками MS. Причем, действительно, создается такое ощущение, что очередной выход хорошего продукта от MS вызывает у них такие вопли, как буд-то бы им прищемили "причинные места" в дверях
Я бы, со своей стороны, предложил бы совсем игнорировать их вопли.
Я уже взывал здесь на форуме и еще раз повторюсь: оставте их в покое, пусть свято веруют в свои Oracle. Не порождайте в них сомнений! Чем больше они так думают, тем вам же потом лучше будет - конкурентов меньше.


дайте две
14 ноя 05, 09:39    [2064696]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
c127

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


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

На самом деле вещь то хорошая(я про .НЕТ), спорить тут нечего, но не сильно необходимая для сервера. Хотя мы можем и ошибаться
14 ноя 05, 10:20    [2064876]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
locky

А зип такое и не возьмет, вроде... там ить до 2 гиг ограничение, вроде?


Во первых, никто не мешает побить на кусочки Во вторых, 2G это ограничение контных реализаций, а никак не алгоритма ;)
14 ноя 05, 11:41    [2065319]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67534
Блог
Локшин Марк
softwarer
Если я правильно понимаю смысл слов in-process, .NET-хранимки будут падать вместе с сервером.

Я думаю, что уж все же не с сервером, а с потоком (thread), в котором исполняется хранимка, если исходить из аналогий с 2000 сервером.

Видите ли в чем дело, насколько я могу судить, "единицей падения" довольно часто является именно процесс (process), а не поток (thread). Для того, чтобы ограничить падение потоком, это падение должно быть контролируемым; обработчик исключений должен вычистить все "грязные следы" падающего потока. Проблема здесь - в разделяемых данных; грубо говоря, если поток перед падением затрет нулями случайную область памяти, это имеет существенные шансы уронить и другие потоки, и в конце концов процесс в целом. Межпроцессное же общение куда лучше защищено; ОС неплохо подчищает следы за падающими процессами и главное, там нет непосредственной адресации в чужое адресное пространство.

Итого, если предположить, что внешняя хранимка падает, в случае out-of-process архитектуры просто упадет NET-машина, а поток сервера, общающийся с ней, вернет исключение типа "неожиданный сбой тра-ля-ля". В случае же in-process реализации NET-машина своим падением легко может уронить весь сервер. Насколько я в курсе, именно этим соображением обуславливается выбор архитектуры в случае Oracle, и именно поэтому я не совсем уверен, что in-process архитектуру следует записать в положительные отличия Yukon.
14 ноя 05, 22:51    [2067848]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
MoonLight
c127
Да, действительно, ошибся. Все время забываю что имею дело со сторонником мелкософта,...
Смотря со стороны, хочется сказать: Удивительно, мы все забываем, что имеем дело с яростными противниками MS. Причем, действительно, создается такое ощущение, что очередной выход хорошего продукта от MS вызывает у них такие вопли, как буд-то бы им прищемили "причинные места" в дверях


Пардон, Вы необъективны. Эти вопли раздаются из лагеря мелкософта. Причем уже дошло до того, что их вызывает даже не выход продукта, а только ожидание выхода, поскольку сам выход многократно откладывается.

Чтоб не быть голословным, самый первый пост топика под названием "Весомый плюс Юкон над ORACLE":
StalkerS> В Юкон будет реализована возможность программировать триггеры, ХП, UDF с помощью любого .NET ......
https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=143322&pg=1&hl=execute


SergSuper
c127

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


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


Почему после п-кода не может быть опасных операций? А если сишную процедуру сначала скомпилировать в п-код (например в асемблер, некоторые компиляторы так и работали), а потом в машинные коды, она тоже станет безопасной?

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

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

К тому же тут где-то утверждалось, что C# код транслируется именно в машинные коды и работает без виртуальной машины, не могу найти где. Но это в обычном приложении, на СКЛ сервере может быть по-другому.

SergSuper

На самом деле вещь то хорошая(я про .НЕТ), спорить тут нечего, но не сильно необходимая для сервера.


Именно это я и говорю, на сервере оно мало кому нужно. А энергии на интегрирование .НЕТ-а в СКЛ сервер потрачено немеряно и шума развели много. ИМХО не оправдывает затрат, лучше бы Т-СКЛ довели до ума.
15 ноя 05, 03:03    [2068188]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
c127
Почему после п-кода не может быть опасных операций? А если сишную процедуру сначала скомпилировать в п-код (например в асемблер, некоторые компиляторы так и работали), а потом в машинные коды, она тоже станет безопасной?

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

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

К тому же тут где-то утверждалось, что C# код транслируется именно в машинные коды и работает без виртуальной машины, не могу найти где. Но это в обычном приложении, на СКЛ сервере может быть по-другому.

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

но я не настолько знаю .Нет чтобы чего-то объяснять :)
15 ноя 05, 10:03    [2068631]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
SergSuper

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

но я не настолько знаю .Нет чтобы чего-то объяснять :)


Безопасные указатели замедлят выполнение, их же каждый раз нужно проверять. Либо же, выполнять код в виртуальной машине, тогда указатели будут указывать на виртуальную память и в случае чего испортят только ее.
17 ноя 05, 04:36    [2076857]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
да нет в безопасном коде вообще указателей
а виртуальной машины в .Нет-е вообще нет - исполняется машинный код

ну почитал бы чего прежде чем выводы делать
17 ноя 05, 09:59    [2077373]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034

Gluk (Kazan) wrote:
> locky
>
> А зип такое и не возьмет, вроде... там ить до 2 гиг ограничение, вроде?
>
>
>
> Во первых, никто не мешает побить на кусочки Во вторых, 2G это
> ограничение контных реализаций, а никак не алгоритма ;)
Ну, низнаю-низнаю... у меня ни один зип не хотел хавать файлы.
А то, что это ограничения реализации - я знаю. Но ить савсем впадлу
писать еще свой винзип, не правда-ли? коли уже есть винрар, который
такие файлы кушает не плямкая.

--
-------------------------
There's no silver bullet!

Posted via ActualForum NNTP Server 1.3

17 ноя 05, 10:49    [2077608]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
SergSuper
а виртуальной машины в .Нет-е вообще нет - исполняется машинный код


шо, опять?! во что, говорите, компилируется .Net проэкт? в машкод? аааа, таки в псевдокод IL? и фреймворк не нужен? тоесть совсем? у нас же бинарник! окей, выполните сборку .Net проекта на машине, где фреймворка нету. медаль от билли гейтса выбивать буим, если оно так сработает
для тех, кто в .Net`е - виртуальная машина, как ее не назови - интерпретатор, JIT компилятор, фреймворк - таки есть. и именно она выполняет сборку нетовскую.
17 ноя 05, 12:07    [2078134]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
aZm
SergSuper
а виртуальной машины в .Нет-е вообще нет - исполняется машинный код


шо, опять?! во что, говорите, компилируется .Net проэкт? в машкод? аааа, таки в псевдокод IL? и фреймворк не нужен? тоесть совсем? у нас же бинарник! окей, выполните сборку .Net проекта на машине, где фреймворка нету. медаль от билли гейтса выбивать буим, если оно так сработает
для тех, кто в .Net`е - виртуальная машина, как ее не назови - интерпретатор, JIT компилятор, фреймворк - таки есть. и именно она выполняет сборку нетовскую.

Выполняет ... но только один раз. Далее, пока файлы сборки не изменяются, выполняются сами уже откомпилированные сборкой dll-ы, лежащие в кэше. Отсюда я в первых версиях VS.NET и видел забавный глюк, когда изменишь формочку, скомпилишь и запустишь проект, а запускается старая, неизмененная версия формочки.
17 ноя 05, 12:16    [2078202]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
ASCRUS
Выполняет ... но только один раз.

quod erad demonstrandum. перенесите сборку на другую машину - и снова выполнится (первый раз) через эту самую виртуальную машину.
17 ноя 05, 12:54    [2078506]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 aZm
Ну не всё в .Net-е так примитивно, как Вы привыкли

Почитайте чего-нибудь прежде чем тонко острить
Я сам этим не занимаюсь, но основные принципы надо знать

MSIL - это независимый от процессора набор инструкций, в который компилируются программы в .NET Framework. Он содержит инструкции для загрузки, хранения, инициализации и вызова методов объектов.

Вместе с метаданными и общей системой типов, MSIL делает реальной межъязыковую интеграцию.

Перед выполнением, MSIL преобразуется в машинный код. Он не интерпретируется.




Из формата PE Windows определяет приложение .NET, и в дело вступает CLR. Важный момент, который необходимо понять, - приложения .NET не интерпретируются! Ошибкой было бы так думать, хотя в некоторых статьях и даже книгах вы можете такую ошибку найти.


Вот микрософтовские ссылки:

http://msdn.microsoft.com/library/rus/default.asp?url=/library/RUS/cpguide/html/cpconmanagedexecution.asp

http://msdn.microsoft.com/library/rus/default.asp?url=/library/RUS/cpguide/html/cpconjitcompilation.asp

Вопрос с интерпритацией надеюсь теперь закрыт?
17 ноя 05, 14:08    [2078952]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
aZm
Member

Откуда:
Сообщений: 2357
SergSuper


пожалуйста внимательно перечитайте мой пост. там я спорил с вами не в том плане, что оно интерпретатор, а в том, что дотнетовское приложение выполняется без всякой виртуальной машины в машинных кодах. аргументы перечислять повторно, уж извините, не буду.
17 ноя 05, 14:32    [2079144]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
gybson
Member

Откуда:
Сообщений: 1107
Насчет безопасности .net - тут стоит почитать про саму платформу, технологии, обратить внимание на домены.

Насчет того, зачем это надо. Ну можно просто посомтреть хотя бы в BOL пункт "Раскрытие иерархий" (не помню как по англиски правильно написать :D) и прикинуть, а как теперь подобные задачи можно решить.

Скорость .Net - на массе задач (много, действительно) не уступает С++. Кроме того, на x64 перейдете сами-собой :D - а это большой плюс.
17 ноя 05, 19:17    [2080860]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
SergSuper
да нет в безопасном коде вообще указателей
а виртуальной машины в .Нет-е вообще нет - исполняется машинный код

ну почитал бы чего прежде чем выводы делать


Может Вы все-таки обратите внимание на то, что я никаких выводов пока не делаю, я делаю утверждения. В какой же части мои утверждения не верны? В том что "Безопасные указатели замедлят выполнение, их же каждый раз нужно проверять"? Вроде все правильно, действительно, чтобы код был безопасным компилятор должен встраивать код, который проверяет указатели каждый раз при их использовании и это замедляет работу. Или может я ошибся во второй части: "Либо же, выполнять код в виртуальной машине, тогда указатели будут указывать на виртуальную память и в случае чего испортят только ее"? Но вроде и тут все правильно, виртуальная машина действительно безопаснее, но замедляет выполнение кода. Или по-Вашему она его ускояет?

Кстати обращение к элементу массива по индексу тоже требует проверки на выход за пределы массива. Если хотите строить безопасный код то это тоже нужно проверять каждый раз когда используются индексы. Работу программы не ускоряет.

Или массивов в безопасном коде тоже нет?



ASCRUS
Выполняет ... но только один раз. Далее, пока файлы сборки не изменяются, выполняются сами уже откомпилированные сборкой dll-ы, лежащие в кэше. Отсюда я в первых версиях VS.NET и видел забавный глюк, когда изменишь формочку, скомпилишь и запустишь проект, а запускается старая, неизмененная версия формочки.


Когда код в системе сам по себе это понятно. Вопрос в том, что происходит когда код компилируется в МССКЛ сервере, или для работы в МССКЛ сервере, не знаю как правильно.

Мы же вроде обсуждаем МССКЛ серверные сохраненки на .НЕТ-е, типа замена T-SQL, а оппоненты все норовят подсунуть ссылки на то, как работает независимое приложение. Подкиньте ссылку на .НЕТ в юконе.
18 ноя 05, 04:57    [2081624]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
2 aZm, c127
Возможно что у меня не совсем верное представление что такое "виртуальная машина". Мне это представлялось как нечто выполняющее промежуточный байт-код. А на самом деле это что?

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

"Либо же, выполнять код в виртуальной машине, тогда указатели будут указывать на виртуальную память и в случае чего испортят только ее"? Но вроде и тут все правильно
Интересно, а кто сейчас работает с реальной памятью? Я последний раз в ДОСе, Win 3.11 на 286 процессоре уже с виртуальной памятью работала.

Или массивов в безопасном коде тоже нет?

Вот нашел
Указатели и управление памятью. В языке C++ работа с указателями занимает одно из центральных мест. Нормальный стиль программирования на C# предполагает написание безопасного кода, а это значит - никаких указателей, никакой адресной арифметики, никакого управления распределением памяти. Возможность работы с указателями в духе C++ ограничена "небезопасными" блоками. Небезопасный код для C# программистов будет скорее исключением, чем правилом.
Массивы. В языке C# появилась возможность объявлять классические многомерные массивы. Работа с массивами в C# более безопасна, поскольку контролируется выход за границы массива.

Кстати обращение к элементу массива по индексу тоже требует проверки на выход за пределы массива. Если хотите строить безопасный код то это тоже нужно проверять каждый раз когда используются индексы. Работу программы не ускоряет.
Во всяком случае в Паскале и Делфи есть ставишь опцию Range Check (проверка выхода за пределы массивов) - на производительности это никак не сказывается.


Но даже если все эти проверки и замедляют оснований для этого вывода(или утверждения) нет:
с127
Сторонники пошарпанного С утверждают, что их код компилируется в машинные коды и потому быстрый. Но в таком случае при выполнении на сервере он так же опасен, как С код из extended процедуры, там такие же указатели и прямой доступ к памяти. А если он в этом случае не будет компилироваться в машинные коды, то врядли получится выигрыш в скорости в сравнении с обычными сохраненками, который так пропагандирует Dooma.
18 ноя 05, 11:21    [2082554]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
gybson
Member

Откуда:
Сообщений: 1107
c127, скажите, как можно рассуждать о .Net не имея ни малейшего, даже приблизительного, понятия о том, как это работает?
18 ноя 05, 12:36    [2083079]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
gybson
c127, скажите, как можно рассуждать о .Net не имея ни малейшего, даже приблизительного, понятия о том, как это работает?


Ваш вопрос поставлен неверно, все-таки кое-какое представление о работе .НЕТ-а я имею. Тем более что я пытаюсь разобраться в работе .НЕТ-а, а в работе .НЕТ-а в МССКЛ сервере и подчеркиваю это уже не в первый раз.

Отвечаю на вопрос. Есть много способов. Из общих соображений, например. Ничего нарушающего общие и даже не очень общие представления там вроде не наблюдается. Или Вы не согласны?


Я уже третий день прошу ссылки на то, как работает .НЕТ в МССКЛ сервере. Может Вы нарушите добрую традицию молчания и выложите ссылку на то, как он работает. Либо расскажите сами.
19 ноя 05, 01:10    [2086021]     Ответить | Цитировать Сообщить модератору
 Re: Ну вот и дождались Юкона  [new]
c127
Guest
SergSuper

Возможно что у меня не совсем верное представление что такое "виртуальная машина". Мне это представлялось как нечто выполняющее промежуточный байт-код. А на самом деле это что?


По-моему не обязательно. Это может быть настоящий исполняемый код, тот же x386, но выполняемый не на реальном процессоре/памяти, а на сэмулированных в другой программе. Например эмулятор палма и VMWare это виртуальные машины.

Т.е. виртуальная машина это программа или часть программы, изображающая из себя компьютер с процессором, памятью и периферией. ИМХО.

SergSuper

Не обязательно. Есть исключения процессора при обращении к запрещенной памяти, проверки делаются аппаратно и ничего не замедляют. Но как сделано в Нет-е - не знаю


Я тоже не знаю. Но в принципе согласен, такое может быть. Но в таком случае при работе внешней процедуры (extended procedure в терминологии Dooma), написанной на С тоже нет никакой опасности. Аппаратные ограничения памяти позаботятся о том, чтобы процедура не испортила память СКЛ сервера и системы. В этом случае непонятно почему процедуры на C# будут безопаснее чем на чем-то другом. (Dooma>Кроме того они больше не будут такими "опасными". https://www.sql.ru/forum/actualthread.aspx?bid=10&tid=231053&pg=3#2061467 )


SergSuper

Интересно, а кто сейчас работает с реальной памятью? Я последний раз в ДОСе, Win 3.11 на 286 процессоре уже с виртуальной памятью работала.


Но синий экран иногда выскакивает, хоть и редко. Значит кто-то все-таки работает.


SergSuper

Или массивов в безопасном коде тоже нет?

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


Всякое исключение можно сделать правилом, как это случилось в С++ по-моему. Там работа с указателями тоже должна была стать (как я понимаю) исключением, но программисты это сделали правилом. Единственный способ этого избежать - не давать возможность делать исключения. Поэтому если в C# есть возможность добраться до указателей, то эта возможность будет использоваться.

SergSuper

Массивы. В языке C# появилась возможность объявлять классические многомерные массивы. Работа с массивами в C# более безопасна, поскольку контролируется выход за границы массива.


Не верю что это можно сделать без потери производительности. Подумайте сами, при каждом обращении к элементу массива нужно проверить if(i>=first_index && i<=last_index). Паскаль не аргумент, борландовские компиляторы традиционно плохо оптимизируют код, на фоне плохого кода проверка на выход из паскалевского массива может быть незаметна.

Но в принципе согласен. Если (!) extended procedures МССКЛ сервера на .НЕТ-е действительно компилируются в машинные коды, то они скорее всего будут работать быстрее Т-СКЛ-евских процедур.

Осталось выяснить куда именно они компилятся НА МССКЛ СЕРВЕРЕ, а не в случае отдельного приложения.


с127
Сторонники пошарпанного С утверждают, что их код компилируется в машинные коды и потому быстрый. Но в таком случае при выполнении на сервере он так же опасен, как С код из extended процедуры, там такие же указатели и прямой доступ к памяти. А если он в этом случае не будет компилироваться в машинные коды, то врядли получится выигрыш в скорости в сравнении с обычными сохраненками, который так пропагандирует Dooma.


С указателями я ошибся, в пошарпанном C их вроде нет, по крайней мере они не болтаются на поверхности, как в С. Признаю. Остаются массивы, которые проверяются, и может еще что-то о чем я не подозреваю.
19 ноя 05, 02:23    [2086079]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить