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

Ш>>Нда? Это какой же язык программирования может определить, что ты вместо 12345 написал 2200 (или наоборот)?

VD>Как видишь, есть языки которые умадряются привести альтернативное решение.

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

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

PD>Что меня огорчает — фанатическая нетерпимость некоторых к другому мнению. В общем, увы, советское воспитание легко не исчезает.

Я бы попросил Вас воздерживаться от подобных высказываний. Ибо оскорбительно/некультурно...

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

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

SC>сабж

Премного благодарен Вам.

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

ПК>Pavel Dvorkin,

>> Просто я хочу отметить, что мы получим класс, который реально своим внутренним состоянием не управляет

ПК>Не согласен. "Внутренним состоянием" данного класса является гарантия, что на каждый вызов LoadLibrary, сделанный через этот класс, последует FreeLibrary. "Общих" гарантий относительно использования LoadLibrary/FreeLibrary во всей программе класс не дает.

"Внутренним состоянием" данного класса — согласен. Но вот то, что он общих гарантий не дает — и плохо. Иными словами, он своей задачи, которую я хотел бы решить (полностью управлять загрузкой/выгрузкой) — не решает. И этим меня не устраивает, почему я его писать и не буду. А то, что он внутренне непротиворечив — не спорю.

Как было написано в одном приказе по некоторому учреждении — "Гвозди в стенку забивать только через меня или зама". Вот это он и не позволит, увы.

Pavel Dvorkin,

> "Внутренним состоянием" данного класса — согласен. Но вот то, что он общих гарантий не дает — и плохо. Иными словами, он своей задачи, которую я хотел бы решить (полностью управлять загрузкой/выгрузкой) — не решает. И этим меня не устраивает, почему я его писать и не буду. А то, что он внутренне непротиворечив — не спорю.
>
> Как было написано в одном приказе по некоторому учреждении — "Гвозди в стенку забивать только через меня или зама". Вот это он и не позволит, увы.

Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.

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

Препроцессор C++ ругали все и всегда, если бы ты поизучал литературу, то знал бы от этом. А так, в любом языке есть куча возможностей как прострелить себе ногу.

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

ПК>Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.

Придерусь к техническ4им моментам — ИМХО запрещать коммит на основании каких то правил не есть верная мысль. Мы это в свое время уже проходили — создает массу проблем разработчикам. VCS должна решать только свою задачу, а именно контроль версий. Все остальное должно работать параллельно. Т.е. в данном случае правильным было бы запускать проверку после коммита, а по ее результатам присваивать статус проверенной ревизии.

AndrewVK,

> ПК>Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.

> Придерусь к техническ4им моментам — ИМХО запрещать коммит на основании каких то правил не есть верная мысль.

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

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

ОК. Давай называть SCM system, а не VCS. Так легче? Должна/не должна, правильно/неправильно -- это вопросы открытые, и в такой постановке мне мало интересные, а вот если в Perforce включены некоторые триггеры, хоть как-то проверяющие корректность файлов being submitted, жить становится заметно легче всем, кто потом эти файлы оттуда получает.

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

J>Препроцессор C++ ругали все и всегда, если бы ты поизучал литературу, то знал бы от этом.

Воспринимаю фразу "если бы ты поизучал литературу, то знал бы от этом" как хмаство и дешовые понты.

J>А так, в любом языке есть куча возможностей как прострелить себе ногу.

Ага. И качество языка оределеяется их количеством. Надо отсылать к литературе по вопросу количества граблей в С++?

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

ПК>Не запрещать, а напоминать о правилах (см. выделенное выше и ниже).Т.е. запрещать делать подобное неявно.

Все равно нельзя. Явно, не явно — процесс коммита и так штука непростая, чтобы перегружать ее дополнительными сложностями.

ПК> В случае, если разработчик настаивает (включил соответствующую опцию при submit), то разрешается,

Разработчик почти наверняка включит такую опцию.

ПК> но, как ты написал ниже, ревизии присваивается соответствующий статус. Точно такой же подход принят в Team System.

В TS именно что есть несколько разновидностей статуса ревизии.

ПК>ОК. Давай называть SCM system, а не VCS. Так легче?

Дело не в названии, дело в том чтобы одно не ешало другому.

ПК> Должна/не должна, правильно/неправильно -- это вопросы открытые, и в такой постановке мне мало интересные, а вот если в Perforce включены некоторые триггеры, хоть как-то проверяющие корректность файлов being submitted, жить становится заметно легче всем, кто потом эти файлы оттуда получает.

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

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

VD>BinaryReader же позоляет читать память как душе угодно, но при этом не заниматься реинтерпретацией типов и не допуская порчи памяти к которой может привести реинтерпетация. Погляди BinaryReader Рефлектором или в Роторе.

Откровенно говоря, выглядит грустно:

public virtual int ReadInt32()
{
      if (this.m_isMemoryStream)
      {
            MemoryStream stream1 = this.m_stream as MemoryStream;
            return stream1.InternalReadInt32();
      }
      this.FillBuffer(4);
      return (((this.m_buffer[0] | (this.m_buffer[1] << 8)) | (this.m_buffer[2] << 0x10)) | (this.m_buffer[3] << 0x18));
}

Для чтения больших объемов, пожалуй, непригодно.
Разве только JIT способен понять, о чем речь и превратить это все в ту же реинтерпретацию памяти, что вызывает сомнения.

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

S>Для чтения больших объемов, пожалуй, непригодно.

А ты попробуй.

S>Разве только JIT способен понять, о чем речь и превратить это все в ту же реинтерпретацию памяти, что вызывает сомнения.

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

Правда, я думаю, что на данном этапе развития упрвляемых рантаймов такие мощьные оптимизации еще не доступны. Однако они несомненно станут доступны в будущем. Да и на сегодня скорость очень и очень приличная.

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

ПК>Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.

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

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

P>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Что меня огорчает — фанатическая нетерпимость некоторых к другому мнению. В общем, увы, советское воспитание легко не исчезает.

P>Я бы попросил Вас воздерживаться от подобных высказываний. Ибо оскорбительно/некультурно...

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

Pavel Dvorkin,

> ПК> Отчего же? Можно поставить триггер на VCS, запрещающий "случайно" submit (прошу прощения, никак не могу вспомнить подходящее русское слово) код, содержащий LoadLibrary/FreeLibrary где-либо, кроме файла с определением соответствующего класса.

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

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

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

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

Да никакой проблемы и нет вовсе. Просто ИМХО класс-обертка должна управлять тем объектом, который она оборачивает. Например, класс string полностью управляет своим ASCIIZ буфером — изменить его состояние помимо интерфейса класса нельзя. здесь же объект может изменять свое состояние помимо этого класса. Вот и все, что я хотел сказать.

class CModule{
public:
BOOL Load(...) {...}
BOOL Unload(...) {...}
BOOL IsLoaded(...) {...}
};

IsLoaded может лишь ответить на вопрос — было ли количество Load для данного модуля больше, чем Unload. На вопрос : есть ли модуль в моем адресном простанстве или нет — IsLoaded корректно ответить не может.

Pavel Dvorkin,

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

> Да никакой проблемы и нет вовсе. Просто ИМХО класс-обертка должна управлять тем объектом, который она оборачивает.

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

> Например, класс string полностью управляет своим ASCIIZ буфером — изменить его состояние помимо интерфейса класса нельзя. здесь же объект может изменять свое состояние помимо этого класса. Вот и все, что я хотел сказать.

Почему состояние "управляемого" объекта отождествляется с состоянием объекта класса-обертки? А содержимое файла является состоянием объекта, представляющего файл с точки зрения программы? Имхо, ответ отрицательный в обоих случаях.

> class CModule{
> public:
> BOOL Load(...) {...}
> BOOL Unload(...) {...}
> BOOL IsLoaded(...) {...}
> };
>
> IsLoaded может лишь ответить на вопрос — было ли количество Load для данного модуля больше, чем Unload. На вопрос : есть ли модуль в моем адресном простанстве или нет — IsLoaded корректно ответить не может.

А почему он должен отвечать на этот вопрос? Может, это означает, что функция с подобной семантикой лишняя в интерфейсе данного класса?

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

ПК>Смотря, что понимать под "управлять". Если речь идет о гарантиях неизменности объекта мимо интерфейса класса-обертки, то я не вижу, откуда это следует, почему это должно быть так. Более того, обычно для объектов, "управляющих" внешними по отношению к программе сущностями, это не так: файлы, сокеты, соединения с базами данных и т.п.

ПК>А почему он должен отвечать на этот вопрос? Может, это означает, что функция с подобной семантикой лишняя в интерфейсе данного класса?

Я думаю, дискууссию стоит прекратить. Я вполне согласен с твоей точкой зрения — в рамках твоей парадигмы ты совершенно прав. В рамках иной парадигмы (полный контроль) — ИМХО прав я. Вопрос, таким образом, сводится к тому, какая парадигма правильная . А это от задачи зависит.