Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

23.01.2017

Google
WWW CITForum.ru
С Новым годом!

Свойство неизменности: ООП под микроскопом

Алексей Лапшин, Открытые системы, #11/2002

Объектно-ориентированное программирование сегодня изучено достаточно глубоко и существует множество поддерживающих эту парадигму языков, однако так называемая проблема обеспечения неизменности (immutability) везде решается уникальным образом, причем большинству реализаций присущи те или иные недостатки. Статья представляет обзор имеющихся решений и предлагает вариант реализации, свободный от ряда недостатков.

Говорят, что метод объекта обладает свойством неизменности (константности), если после его выполнения состояние объекта не изменяется. Различают два вида неизменности, логическую и физическую. Физическая неизменность означает полную идентичность объекта, с точностью до каждого поля, а логическая - его наблюдаемую идентичность (невидимые внешнему миру поля private и protected могут быть изменены, но это не должно быть заметно для клиента, использующего объект).

Необходимость контроля неизменности

Если не контролировать свойство неизменности, то его обеспечение будет целиком зависеть от квалификации программиста. Если же "неизменный" метод в процессе выполнения будет производить посторонние эффекты, то результат может быть самым неожиданным; отлаживать и поддерживать такой код очень тяжело. В качестве примера можно рассмотреть часть кода из библиотеки STL, поставляемой с компилятором Borland C++ 5.01 (файл memory.h):

Метод operator=() вместо операции присвоения выполняет операцию переноса указателя на объект, что позволяет написать вот такой странный код:

После выполнения операции присвоения одного объекта другому, вполне естественно ожидать их равенства, но в данном случае равенства не будет. Объект first_string не будет содержать объект типа string, которым был проинициализирован: при выполнении операции присвоения он был удален из first_string. В результате, текст "some text" будет напечатан только один раз в последней строке. operator=() обладает определенной семантикой; в частности, предполагается, что копируемый объект остается неизменным. Однако в данном случае выполняются действия, которые не совпадают с этой семантикой. Если бы интерфейс был описан верно (параметр rhs метода operator=() был неизменным), то подобная ошибочная реализация была бы невозможна. Вариант такого решения предлагает библиотека STL, поставляемая с компилятором Visual C++ 6.0; он также является хорошим примером несовпадения логической и физической неизменности.

Допустим, метод get() объекта auto_ptr не объявлен как неизменный. В этом случае была бы возможна ошибочная реализация:

В таком случае две последние строки из примера содержали бы ошибку, так как во время вызова метода get() сохраняемый объект удалялся бы из объекта типа auto_ptr, и при его дальнейшем использовании возникало бы обращение к нулевому указателю.

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

С++

Язык С++ позволяет пометить метод как константный [1]; неконстантные методы этого объекта запрещается использовать в теле помеченного метода, и в контексте этого метода ссылки на сам объект и все его поля константны. Также существует возможность пометить ссылку (указатель) как константную. Применительно к ссылке свойство константности означает, что через эту ссылку можно вызывать только константные методы; присвоение константной ссылки неконстантной запрещено. Проверку этих условий обеспечивает компилятор. Для обозначения константности используется модификатор const. Пример интерфейса с константными методами:

В примере методы Name, Age, Picture объявлены константными. Кроме того, можно наблюдать и использование константных ссылок: параметр методов SetName и SetPicture, возвращаемое значение методов Name и Picture. Компилятор обеспечит проверку того, что реализация константных методов не имеет побочных эффектов в виде изменения состояния объекта, реализующего интерфейс Personal. Как только обнаружится попытка выполнить запрещенную операцию, компилятор сообщит об ошибке.

Предположим, мы намерены оптимизировать работу метода Picture. Вовсе не обязательно, что во всех вариантах использования класса Personal будет требоваться получить фотографию, занимающую много памяти. Можно так реализовать метод Picture, чтобы фотография загружалась только в случае использования именно этого метода. Но в Picture нельзя менять переменную picture_data, которая хранит ссылку на фотографию: компилятор запрещает менять поля объекта в константном методе. Это и есть проблема логической неизменности. Пожалуй, самым распространенным случаем возникновения несоответствия логической и физической неизменности является кэширование данных и создание прокси-объектов [9]. Таким образом, в С++ модификатор const означает лишь физическую неизменность. Чтобы обеспечить возможность реализации логически константных методов, в С++ имеется конструкция const_cast. С ее помощью приведенный пример можно переписать так:

Итак, проблема логической неизменности решена; метод Picture не меняет наблюдаемого состояния объекта. Однако одновременно потеряна защита со стороны компилятора, и теперь модификатор const не гарантирует, что состояние объекта остается неизменным.

Для ослабления контроля неизменности со стороны компилятора в С++ также используется модификатор mutable. Им можно пометить поля класса, значения которых разрешается менять в константных методах. Посмотрим, как будет выглядеть пример с использованием mutable (приведены только те элементы, которые изменены по сравнению с вариантом для const_cast).

Увы, этот вариант имеет тот же недостаток, что и вариант с const_cast. Проверка со стороны компилятора ослабляется, не предлагая взамен никаких гарантий. Если, в силу ошибочной реализации, при каждом вызове метода Picture поле picture_data модифицируется, то это не будет обнаружено, а клиент станет каждый раз получать разные изображения одной и той же персоны.

Плюсы такой реализации: контроль физической неизменности на стадии компиляции. Минусы: наличие const_cast и mutable, решив проблему реализации логической неизменности, свело на нет усилия по обеспечению контроля обоих видов неизменности.

C#, Java

Языки C# и Java унаследовали упрощенный вариант реализации неизменности из С++ [2, 3]. Можно пометить ссылку как константную (const в C#, final в Java), но метод пометить как константный нельзя. Поэтому компилятор контролирует использование только одной известной ему неконстантной операции - присвоения. Выгода от этого механизма минимальна и проявляется, в основном, при работе с примитивными типами в Java или value types в C#; как правило, объекты такого типа меняют состояние только с помощью операции присвоения.

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

Методы-аксессоры оказываются отделены от методов-модификаторов, что позволяет контролировать использование только константного интерфейса объекта, например:

Класс Printer получает ссылку на константный интерфейс и потому не может изменить состояние объекта, который находится по ссылке personal_info. Однако в данном случае нет гарантии, что методы-аксессоры не будут менять состояния объекта; все опять же будет зависеть от опыта и внимательности программиста. Для того чтобы избежать подобных ошибок, можно, конечно, объявить класс ConstPersonal как sealed (в Java - как final), запретив другие, возможно ошибочные, реализации, а класс Personal не наследовать от ConstPersonal. Примером такого решения служат классы String и StringBuilder в С# (соответственно String и StringBuffer в Java). Но это означает отказ от механизма наследования; как показывает практика, такой подход редко используется. Примером тому служат базовые библиотеки для С# и Java, где этот прием применяется в единичных случаях: даже базовый интерфейс Object не разделен на константную и неконстантную составляющие.

Плюсы данного подхода: не нужен дополнительный механизм, для реализации используются стандартные средства; есть слабый контроль физической неизменности. Минусы: в большинстве случаев контроль неизменности отсутствует; необходима дополнительная работа по разделению интерфейса на изменяемую и неизменную части; возможность использования механизма RTTI (runtime type identification - "идентификация типов во время выполнения") для преобразования неизменного интерфейса в изменяемый.

Eiffel

В языке Eiffel [4] используется вариант разбиения интерфейса на константный и неконстантный. Также поддерживается методология Design By Contract [7], которая позволяет задать семантику интерфейса. Такой подход дает возможность контролировать правильность реализации неизменного интерфейса:

В секции inherit перечисляются базовые классы. С помощью ключевого слова ensure записывается постусловие метода, которое проверяется во время выполнения. В случае, если условие не выполняется, то генерируется исключение. Current - это Eiffel-вариант ключевого слова this. Ключевое слово old обозначает ссылку на копию объекта, сделанную перед началом выполнения метода. Метод is_equal наследуется всеми объектами из базового класса ANY и проверяет объекты на равенство; при необходимости может быть переопределен.

У методов интерфейса CONST_PERSONAL имеется постусловие, которое гарантирует, что после выполнения метода объект не изменил свое состояние. Любая реализация интерфейса CONST_PERSONAL должна будет удовлетворять заданному свойству неизменности. Метод is_equal в данном случае выступает критерием неизменности состояния объекта.

Плюсы подхода Eiffel: есть контроль физической и логической неизменности; не нужен дополнительный механизм, все реализуется стандартными средствами. Минусы: необходимость в дополнительной работе по разделению интерфейса на две изменяемую и неизменную части; при интенсивном использовании неизменяемых интерфейсов возрастает число проверок, необходимых в отладочной версии; возможность использования RTTI для преобразования неизменного интерфейса в изменяемый.

Предлагаемый вариант решения

Интерфейс не делится на два; вместо этого все неизменяемые методы обозначаются ключевым словом const, это свойство наследуется. Все константные ссылки обозначаются ключевым словом const, что позволяет находить ошибки на стадии компиляции. Критерий тот же, что и в С++: запрещается вызывать неконстантные методы объекта в теле константного метода, ссылки на сам объект и все его поля в контексте этого метода константны. Вызывать неконстантные методы через константную ссылку, а также присваивать константную ссылку неконстантной запрещается.

В случае необходимости, используя ключевое слово mutable, разрешается вызывать неконстантные методы этого же объекта в константном методе, в константном методе присваивать неконстантной ссылке значение this или значения полей этого же объекта. Наличие ключевого слова mutable служит сигналом компилятору для вставки проверки того, что состояние объекта не изменилось; эта проверка аналогична постусловию в Eiffel-варианте и выполняется по завершении работы метода независимо от того, сколько точек возврата имеет метод (это может быть реализовано либо с помощью прокси-метода, либо вставкой проверки во все точки возврата). Для осуществления проверки перед выполнением метода копируется исходное состояние объекта. Также проверка выполняется при выходе из метода в случае исключительной ситуации. Проверка осуществляется во время выполнения только в отладочной версии независимо от того, выполнялась или нет часть метода, которая содержит инструкцию mutable. В случае если проверка не прошла генерируется исключение. На число использований ключевого слова mutable в теле метода ограничений не накладывается. Должен быть определен метод, который задает критерий оценки неизменности состояния, этот метод будет вызываться в проверке вставляемой компилятором. Использование ключевого слова mutable в таком методе запрещено.

Отличие от варианта С++ состоит в том, что const означает не физическую, а наблюдаемую неизменность объекта. Разница с Eiffel в том, что в случае, когда метод физически константен, проверка не вставляется, а также в том, что механизм обеспечения неизменности является дополнением к уже существующим элементам языка.

Описанный механизм может быть реализован либо в рамках существующих языков программирования с проведением необходимого анализа на возможность интеграции с существующим окружением, либо в новых языках. Вот как это может выглядеть в контексте С++ (в качестве примера выбран operator==(), который задает условие логической константности):

В классе Personal переопределен оператор сравнения, который задает условие логической неизменности. В операторе проверяется, что логическое содержание объектов эквивалентно (несмотря на то, что на момент проверки данные могут быть не загружены в память). Также отметим, что переопределение операторов копирования и сравнения не является специальной реализацией этих методов для поддержки предлагаемого механизма. Такая их реализация продиктована семантикой интерфейса Personal; мало проку при сравнении двух персон сравнивать значения указателей вместо содержимого изображений. Если необходим метод, осуществляющий сравнение физического содержания всех полей, его можно реализовать дополнительно. В данном случае объект имеет пять константных методов; четыре из них (ReadPictureFromFile, Name, Age, operator==) будут проверены на стадии компиляции, а пятый, метод Picture, - во время выполнения в соответствии с заданным в operator== условием неизменности (при его реализации была использована инструкция mutable).

Плюсы предложенного подхода: используется специальный механизм, что позволяет компилятору контролировать неизменность; в большинстве случаев это будут ошибки компиляции, в ряде случаев ошибки времени выполнения; не нужно делить интерфейс на два - меньше работы программисту; количество проверок времени выполнения по сравнению с вариантом Eiffel невелико и равно количеству случаев, когда физическая неизменность не совпадает с логической, вследствие чего нет потерь в скорости работы; механизм не конфликтует с рядом специфичных для объектно-ориентированного подхода принципов, например, с ковариантным переопределением параметров.

Минусы: в отладочной версии, когда физическая неизменность не совпадает с логической и для хранения информации о состоянии проверяемого объекта требуется большой объем памяти, возможно значительное потребление ресурсов, что может сказаться на скорости работы программы.

Проблеме неизменности посвящено множество публикаций [5-9]. Представленный вариант снимает имеющиеся трудности и может быть использован для решения проблемы обеспечения свойства неизменности для объектов.

Литература

  1. Б. Страуструп. Язык программирования C++, 3-е изд. М.: Бином, 1999
  2. Э. Гуннерсон. Введение в C#. Библиотека программиста, СПб.: Питер, 2001
  3. Б. Эккел, Философия Java. СПб.: Питер, 2001
  4. B. Meyer, Eiffel: The Language. Second edition. Prentice Hall, 1992
  5. K. Henney, From Mechanism to Method: Good Qualifications. C++ Experts Forum on the C/C++ Users Journal website, January 2001
  6. S. Porad, M. Biberstain, L. Koved, B. Mendelson, Automatic detection of Immutable fields in Java. www.research.ibm.com/ people/ k/ koved/ papers/ MutabilityCASCON2000.ps
  7. B. Meyer, Object-Oriented Software Construction. Second edition. Prentice Hall, 1997
  8. J. Bloch, Effective Java Programming Language Guide. Addison Wesley Professional
  9. Р. Джонсон, Дж. Влиссидес, Э. Гамма, Р. Хелм, Приемы объектно-ориентированного проектирования. СПб.: Питер, 2001

Алексей Лапшин (Alexey@star.spb.ru) - сотрудник компании "Стар-СПб" (Санкт-Петербург).

Опубликовано 04.02. 2003

 

Размещение рекламы — тел. +7 495 4119920, ICQ 232284597

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы — тел. +7 495 4119920, ICQ 232284597 Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2007 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...