Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Архив форумов ЦИТФорума
Море(!) вопросов - Море(!) ответов
 
 FAQFAQ   ПоискПоиск   ПользователиПользователи   ГруппыГруппы   РегистрацияРегистрация 
 ПрофильПрофиль   Войти и проверить личные сообщенияВойти и проверить личные сообщения   ВходВход 
Как правильно задавать вопросы

Модула 3

 
Перейти:  
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Программирование
Предыдущая тема :: Следующая тема  
Автор Сообщение
yw



Зарегистрирован: 21.10.2009
Сообщения: 15

СообщениеДобавлено: Пт Мар 05 2010 19:30    Заголовок сообщения: Модула 3 Ответить с цитатой

Здравствуйте .

Я заинтересовался этим языком . Русскоязычных ресурсов очень мало . С трудом читаю английскую документацию .

Вопрос : Есть ли RAII в М3 ?
Допустим я открыл файл , отдал хэндлер вызывающей функции или передал трэду . Кто-то должен закрыть файл , но ведь не финализатор блока , в котором файл открыт . Надо дождаться , чтобы хэндлер стал никому не нужен , и только тогда закрыть файл . Не представляю , как это можно сделать надёжно без автоматически вызываемого деструктора . Однако деструкторов в М3 нет , насколько я понял .

Так что вопросов даже 2 . Есть ли в М3 деструкторы ? Если нет , как обеспечить освобождение ресурса вне того блока , в котором ресурс захвачен ?

Ну и вообще , может кто скажет что-нибудь интересное о М3 Smile
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
yw



Зарегистрирован: 21.10.2009
Сообщения: 15

СообщениеДобавлено: Пт Мар 12 2010 15:33    Заголовок сообщения: Ответить с цитатой

Спасибо за интерес Smile

Про деструкторы и RAII кажется прояснилось

Ещё пара вопросов

Есть ли официальная документация по М3 после 1990-го года ? Подскажите пожалуйста , где искать

Есть ли в стандарте М3 условная компиляция ? Если да , то какая , где описана ? Если нет , тогда как в М3 можно учесть особенности платформы , компилятора и т.д. ? Как компилировать различные версии одной программы ?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
yw



Зарегистрирован: 21.10.2009
Сообщения: 15

СообщениеДобавлено: Вс Мар 28 2010 11:41    Заголовок сообщения: Ответить с цитатой

Раскапываю исходники , выложенные в иннет ...

Интересно увидеть работу с битами . Я бы стал делить и умножать целые числа на степени 2 (в надежде на оптимизацию) и объявил бы функции встраиваемыми . Нашлась куча исходников , оформленных в гипертекст ; вот что относится к битам :

http://web.archive.org/web/20000412001900/www.ifi.uni-klu.ac.at/Modula-3/html/m3sources/html/word/src/Word.i3.html

<<<<

INTERFACE Word;

TYPE
T = INTEGER;
(* encoding is implementation-dependent; e.g., 2's complement. *)

CONST
Size : INTEGER = BITSIZE (T); (* implementation-dependent *)

PROCEDURE Plus (x, y: T): T; (* (x + y) MOD 2^[Word.Size] *)

>>>>

И т.д. с другими функциями . Вроде всё понятно . Тип T -- традиционный синоним экспортируемого типа для некоторой унификации обращения с интерфейсами

Однако вот соответствующий модуль :

http://web.archive.org/web/19990501151017/www.ifi.uni-klu.ac.at/Modula-3/html/m3sources/html/word/src/Word.m3.html

<<<<

MODULE Word;
IMPORT Word; (* let the compiler implement each of these as inlines *)

PROCEDURE Plus (x, y: T): T = BEGIN RETURN Word.Plus (x, y) END Plus;

>>>>

И т.д. с другими функциями . Что это за ?

Экспорт не указан , значит модуль реализует одноимённый интерфейс . Экспортная процедура (Plus) определяется здесь как вызов её самой с теми же аргументами . Это бесконечная рекурсия ...
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
and3008



Зарегистрирован: 12.10.2001
Сообщения: 14893
Откуда: Н.Новгород

СообщениеДобавлено: Вс Мар 28 2010 17:00    Заголовок сообщения: Ответить с цитатой

А еще некоторые изучают языки древних шумеров...
У них там тоже интересные обороты и все называется по другому.
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
yw



Зарегистрирован: 21.10.2009
Сообщения: 15

СообщениеДобавлено: Вс Мар 28 2010 17:26    Заголовок сообщения: Ответить с цитатой

and3008 писал(а):
А еще некоторые изучают языки древних шумеров...
У них там тоже интересные обороты и все называется по другому.

Это чистый флуд или есть аргументы , чем хуже М3 и по сравнению с чем ?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
критикан



Зарегистрирован: 18.02.2005
Сообщения: 247

СообщениеДобавлено: Пн Мар 29 2010 11:53    Заголовок сообщения: долго ходил по на улицу, вчера узнал, что дома есть унитаз Ответить с цитатой

а можно узнать -- ЗАЧЕМ?
-------------------------------
я долго ходил по маленькой на улицу, но вчера узнал, что дома есть унитаз
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
yw



Зарегистрирован: 21.10.2009
Сообщения: 15

СообщениеДобавлено: Пн Мар 29 2010 19:32    Заголовок сообщения: Re: долго ходил по на улицу, вчера узнал, что дома есть унитаз Ответить с цитатой

критикан писал(а):
а можно узнать -- ЗАЧЕМ?

Я пока не разобрался толком , поэтому жду чужих мнений . Чисто субъективно -- М3 надёжнее , чем Си++ , по 3 главным причинам : имеет полноценный (но не навязчивый) сбор мусора ; позволяет явно запретить низкоуровневые (потенциально опасные) фичи , сохраняя практичность ; гораздо компактнее в описании . Зато по технологии отстаёт : нет конструкторов и деструкторов (хотя их полезность мала из-за мусорщика) ; нет никаких перегрузок , ни для процедур , ни для методов , ни для операций ; нет препроцессора ; кривая инкапсуляция
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
критикан



Зарегистрирован: 18.02.2005
Сообщения: 247

СообщениеДобавлено: Чт Апр 01 2010 17:13    Заголовок сообщения: а вчера я ещё узнал, что у унитаза есть ручка для смыва Ответить с цитатой

yw писал(а):
Чисто субъективно -- М3 надёжнее , чем Си++ , по 3 главным причинам : имеет полноценный (но не навязчивый) сбор мусора ; позволяет явно запретить низкоуровневые (потенциально опасные) фичи , сохраняя практичность ; гораздо компактнее в описании . Зато по технологии отстаёт : нет конструкторов и деструкторов (хотя их полезность мала из-за мусорщика) ; нет никаких перегрузок , ни для процедур , ни для методов , ни для операций ; нет препроцессора ; кривая инкапсуляция

1. полноценный сбор мусора: может, проще при программировании не мусорить? ведь чисто не там, где хорошо убирают, а там, где не мусорят.

2. позволяет явно запретить низкоуровневые фичи: я не понял -- кому он позволяет запретить? программисту? а зачем это запрещать? если программист не хочет низкого уровня, он и так не будет им пользоваться, а если захочет, а ему запретят, то он выбросит М3 и возьмёт Си или вообще Асм. пользователю? ну так ему и так программист запретил всё, что можно. а! прикладному программисту? ну так в этом случае он выступает в роли пользователя продукции системного программиста, и фактически он будет пользоваться не М3, а модифайд-М3, то есть собственно полноценного М3 просто не будет. так что непонятно, при чём здесь запрет низкого уровня.

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

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

5. нет препроцессора: вот это действительно ХЗЧ. нах такой компилятор.

6. кривая инкапсуляция: см. п. 4
--------------------------------------------------------
а вчера я ещё узнал, что у унитаза есть ручка для смыва
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
yw



Зарегистрирован: 21.10.2009
Сообщения: 15

СообщениеДобавлено: Чт Апр 01 2010 23:05    Заголовок сообщения: Ответить с цитатой

Отвечаю на основе текстов об М3 , своего опыта пока нет

> может, проще при программировании не мусорить?

Конечно проще . Ещё проще не программировать

Легко понять , когда понадобился объект , и создать его . Точно установить момент , когда объект разнадобится , где и кто в программе должен установить этот момент -- достаточно сложная и важная проблема , достойная автоматизации

> позволяет явно запретить низкоуровневые фичи: я не понял -- кому он позволяет запретить?

Программист может запретить самому себе . М3 позволяет запретить для надёжности (и тогда проверяет) и позволяет разрешить для предельной эффективности

> если программист не хочет низкого уровня, он и так не будет им пользоваться

М3 позволяет удобно и надёжно различать , где в программе возможны опасные трюки , а где нет . Это важно при чтении не только чужих , но и своих исходников ; а также вероятно для оптимизаций

> даже по сравнению с Си++ двух- и даже трёхкратная разница вряд ли может быть серьёзной причиной для выбора в пользу М3

Во-1-х может . Во-2-х наверно в 5 раз

> зависит не от базового языка, а от объёма готовых библиотек

От качества языка -- конечно зависит . Не от объёма , а от качества библиотек . Библиотеки М3 якобы хороши , но я не проверял и критику не искал

Насчёт конструкторов и деструкторов . В Си++ это фундамент всех технологий проектирования . К ним привязывается владение ресурсами и вообще внутренняя сигнализация в программе . В М3 -- тема очень сложная ; главная сложность -- нельзя создавать объекты на стэке

> нет препроцессора: вот это действительно ХЗЧ. нах такой компилятор.

Чем же так ценен препроцессор ? Я люблю и активно пользуюсь препроцессором Си++ ; конечно в Си он нужнее . Однако в М3 нет большой нужды во вставке файлов : интерфейсы передаются другим способом . Макроподстановок жаль , но в общем почти достаточно констант , инлайн функций и генериков (близких по предназначению шаблонным типам Си++) . Больше всего жаль условной компиляции : насколько я понял , вместо неё в М3 можно лишь выбирать , какие модули (вместо каких) включать в проект

Вообще в М3 многое реализовано скромнее , аскетичнее , чем в том же Си++ . Однако часто 10% усилий дают 90% результата , если правильно выбрать усилия . Кажется , в М3 выборы правильные Smile

Инкапсуляция в М3 гораздо лучше , чем казалось поначалу
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
критикан



Зарегистрирован: 18.02.2005
Сообщения: 247

СообщениеДобавлено: Пт Апр 02 2010 13:32    Заголовок сообщения: унитаз со сливом -- это вещь, жаль только вода из колодца Ответить с цитатой

yw писал(а):
> может, проще при программировании не мусорить?
Конечно проще . Ещё проще не программировать

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



yw писал(а):
> позволяет явно запретить низкоуровневые фичи: я не понял -- кому он позволяет запретить?

Программист может запретить самому себе
точно! привяжите меня к кровати, а то я сейчас такого натворю!




yw писал(а):
> если программист не хочет низкого уровня, он и так не будет им пользоваться

М3 позволяет удобно и надёжно различать , где в программе возможны опасные трюки , а где нет
ааа! вот оно что! ну это точно! для программистов, особенно выращенных в 90-2000-е годы на дельфях и аксессах, фокусы с адресами и типами -- это шаманские пляски с бубном. им нужно без разъяснений говорить: Мотя, a+a -- это тебе можно, 4+'T' -- это тоже можно, а *(p+2) -- это вообще-то можно, но тебе нельзя.



yw писал(а):
> даже по сравнению с Си++ двух- и даже трёхкратная разница вряд ли может быть серьёзной причиной для выбора в пользу М3

Во-1-х может . Во-2-х наверно в 5 раз
да даже 10-кратная. покажи мне программиста, который прочитал анси-йное описание си++. а я прочитал. примерно одну десятую. чуть не умер. ещё я прочитал борландовский хелп по паскалю. тоже чуть не умер. а про Паскаль брешут, что его описание на двух страницах умещается. Паскаль-то, может, и умещается, а вот известные реализации -- эээ... -- нужно читать как юзер документацию -- только когда не работает



yw писал(а):
> зависит не от базового языка, а от объёма готовых библиотек

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



yw писал(а):
Насчёт конструкторов и деструкторов . В Си++ это фундамент всех технологий проектирования. К ним привязывается владение ресурсами и вообще внутренняя сигнализация в программе . В М3 -- тема очень сложная ; главная сложность -- нельзя создавать объекты на стэке
конструкторы и деструкторы -- это не фундамент проектирования для Си++, а фундамент рекламы о великих преимуществах Си++. впрочем, признаю, они зело полезны в определённых случаях. а вот М3 с него недопустимостью создавать объекты на стеке озадачил: там даже объект размером в 1 байт нельзя в стек поставить? ХЗЧ.



yw писал(а):
Больше всего жаль условной компиляции : насколько я понял , вместо неё в М3 можно лишь выбирать , какие модули (вместо каких) включать в проект
"мне очень приятно, Штирлиц, что Вы так точно меня понимаете" (с). именно это я и имел ввиду, говоря про отсутствие препроцессора, что это ХЗЧ.



yw писал(а):
Вообще в М3 многое реализовано скромнее , аскетичнее , чем в том же Си++
ну это понятно: это же не язык, а идеал. зачем мне кушать, если я Верю в бога? (это шутка.)
--------------------------------------------------------------
унитаз со сливом -- отличная вещь, жаль только -- у нас вода из колодца
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
yw



Зарегистрирован: 21.10.2009
Сообщения: 15

СообщениеДобавлено: Пт Апр 02 2010 14:23    Заголовок сообщения: Re: унитаз со сливом -- это вещь, жаль только вода из колодца Ответить с цитатой

критикан писал(а):
а общее правило хорошего стиля, что объект инициализируется при входе в блок и освобождается при выходе из него не подходит? то есть, если обнаруживается, что объект нужен ещё где-то, то просто поднимать его в вышестоящий блок

Кому как ; мне не подходит . Вы никогда не создавали функцию , создающую связанную конструкцию ? Или никогда не используете указатели внутрь такой конструкции ?

> (кстати, именно это правило и автоматизировано в ООП путём введения деструкторов).

Деструктор всегда вызывается в Си++ при разрушении объекта , без обязательной дисциплины "разрушать в обратном порядке"

> а практика инициализации объектов где угодно в расчёте, что они понадобятся где угодно, мне не понятна.

Это важная практика . Процесс обрабатывает внешние запросы или читает их из файла . Запрос может подразумевать создание объектов ; или применение ранее созданных объектов ; или удаление некоторых объектов . Правило "разрушай в обратном порядке" ограничивает подобные алгоритмы .

> фокусы с адресами и типами -- это шаманские пляски с бубном. им нужно без разъяснений говорить: Мотя, a+a -- это тебе можно, 4+'T' -- это тоже можно, а *(p+2) -- это вообще-то можно, но тебе нельзя.

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

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

Совсем простой пример -- 'const' в Си и Си++ . Вы чувствуете себя "Мотей" , когда пишете константность ? Вы кричите сотрудникам "Бля буду , не трогаю эту переменную , не смейте оскорблять меня вашими констами , я сам себя проверяю" ?

> а я прочитал

И пришли к выводу , что компактность полного описания языка излишня ?

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

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

> линуксовые тоже не надо, там -- опен сорс, а не Си++.

Опс! По-Вашему опенсорс пишут без библиотек ? В опенсорсе нет Си++ ?

Теперь понятно . Извините за многословие в предыдущих абзацах . Я подожду другого собеседника

P.S: Объектами в М3 называют нечто подобное ссылкам на классы в Си++ . На стэке может быть ссылка (нечто похожее на указатель Си) но не само тело объекта . Скалярные типы , рекорды (аналог простых структур Си) и вообще переменные всех типов , кроме объектных , могут целиком размещаться на стэке
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
критикан



Зарегистрирован: 18.02.2005
Сообщения: 247

СообщениеДобавлено: Пт Апр 02 2010 17:03    Заголовок сообщения: что лучше, большой нож или маленький топор? Ответить с цитатой

yw писал(а):
Извините за многословие в предыдущих абзацах . Я подожду другого собеседника
да ладно тебе. это же просто критиканство. я не собираюсь непременно убедить тебя в моей правоте.




yw писал(а):
критикан писал(а):
а общее правило хорошего стиля, что объект инициализируется при входе в блок и освобождается при выходе из него не подходит? то есть, если обнаруживается, что объект нужен ещё где-то, то просто поднимать его в вышестоящий блок
Кому как ; мне не подходит . Вы никогда не создавали функцию , создающую связанную конструкцию ? Или никогда не используете указатели внутрь такой конструкции ?
мне не известны случаи, для которых было бы оправдано нарушение правил хорошего стиля.




yw писал(а):
> (кстати, именно это правило и автоматизировано в ООП путём введения деструкторов).

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




yw писал(а):
> а практика инициализации объектов где угодно в расчёте, что они понадобятся где угодно, мне не понятна.

Это важная практика . Процесс обрабатывает внешние запросы или читает их из файла
практика-то важная, только она давно известна и решена. называется эта практика "событийно-ориентированное программирование" (которое почему-то приписывается Стиву Джобсу, хотя он слямзил его у Ранк Ксерокса). и решение это не требует фокусов с влезанием внутрь неизвестно когда и неизвестно где созданных объектов.




yw писал(а):
> фокусы с адресами и типами -- это шаманские пляски с бубном. им нужно без разъяснений говорить: Мотя, a+a -- это тебе можно, 4+'T' -- это тоже можно, а *(p+2) -- это вообще-то можно, но тебе нельзя.

Вы часто пишете в тело функции , меняя её алгоритм на ходу ?
вообще-то тут речь шла о том, что запрет программисту выполнять какие-то операции сродни примерно такому ценному указанию: Мотя, ты полный и окончательный дурак, поэтому покорнейше тебя умоляю, не используй адресную арифметику.



yw писал(а):
А ведь реальный приём , может быть полезен . Однако , даже если так можно и нужно делать , очень важно отличать участки програмы , воздействующие таким образом на другие части программы , от гарантированно не воздействующих
такие участки надо не отличать, а знать. в помощь этому и придуманы правила хорошего стиля в программировании.



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

yw писал(а):
Совсем простой пример -- 'const' в Си и Си++ . Вы чувствуете себя "Мотей" , когда пишете константность ? Вы кричите сотрудникам "Бля буду , не трогаю эту переменную , не смейте оскорблять меня вашими констами , я сам себя проверяю" ?
а мне конст вообще не нужен. мне и с дефайнами хорошо живётся. а если мне и в правду нужно у какой-то переменной значение сохранить, так я её в интерфейс не предоставляю. хочешь, чтоб что-то было сделано правильно, сделай это сам или отдай тому, кому доверяешь как себе.




yw писал(а):
> а я прочитал

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




yw писал(а):
> покажи мне программу, чей код содержит только инструкции базового языка

Нет , не покажу . По-Вашему , из этого следует , что качество языка безразлично для качества программирования ?
из этого именно это и следует: качество (сегодняшнего) языка безразлично для качества программирования. потому что реальные программы -- это умелое использование библиотек, а не самого языка. сравните, скажем, фокспро и си++ в виде МФЦ. у первого -- дурацкая структура, доставшаяся от дибейза, у второго разрекламированные изыски типа одновременного разыменования, присваивания, инкремента и проверки условия. а посмотришь написанные на них реальные программы, выполняющие одно и то же действие, не отличишь, где фокспро, а где си++.




yw писал(а):
> линуксовые тоже не надо, там -- опен сорс, а не Си++.

Опс! По-Вашему опенсорс пишут без библиотек ? В опенсорсе нет Си++ ?
тут ты слегка маху дал: я как раз имел ввиду, что опен сорс это на 99,(9)% готовые библиотеки. за которыми уже давно не видно самого Си++. причём ладно бы это были библиотеки для самого Си++ -- в действительности современный линуксовый Си++ -- это огромная комбинация Си++, перла, аук'а, сед'а, шелла и ещё десятка средств, автоматизирующих разработку.




yw писал(а):
P.S: Объектами в М3 называют нечто подобное ссылкам на классы в Си++ . На стэке может быть ссылка (нечто похожее на указатель Си) но не само тело объекта . Скалярные типы , рекорды (аналог простых структур Си) и вообще переменные всех типов , кроме объектных , могут целиком размещаться на стэке
мда-с.... а Си-то плюс плюс объектом считает просто кусок памяти. отличие от Си-шного куска памяти только в том, что в Си следить, чтобы с этим куском памяти программист аккуратно обращался, должен он сам, а в Си++ в этом святом деле ему компилятор помогает. нах нужен М3-шный объект, если непонятно, что это за зверь и с чем его едят
-----------------------------------------------------------------
что лучше, большой нож или маленький топор?
Вернуться к началу
Посмотреть профиль Отправить личное сообщение
Показать сообщения:   
Этот форум закрыт, вы не можете писать новые сообщения и редактировать старые.   Эта тема закрыта, вы не можете писать ответы и редактировать сообщения.    Список форумов Архив форумов ЦИТФорума -> Программирование Часовой пояс: GMT + 3
Страница 1 из 1

 
Перейти:  
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах


Powered by phpBB © 2001, 2002 phpBB Group
Русская поддержка phpBB

 

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

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