template
vector.cpp - у тебя компилируется отдельно...
а шаблоны... это такая штука, реализацию которой, к сожалению тоже приходится в header'ы засовывать.
а шаблоны... это такая штука, реализацию которой, к сожалению тоже приходится в header'ы засовывать.
У меня все отлично скомпилировалось и запустилось.
у меня тоже
после того как я засунул все функции шаблона класса в заголовочный файл.
спасибо -у
после того как я засунул все функции шаблона класса в заголовочный файл.
спасибо -у
хех, ну не знаю, не знаю, у меня VС 6.0 (SP5) и Builder5.0 умеют справляться с раздельной компиляцией 
AFAIK этот грязный хак называется implicit templates и как раз несколько подрывает идею раздельной компиляции
Что такое AFAIK
Ликбез: As Far As I Know.
Честно сказать я не думаю что это "грязный хак подрывающий идею раздельной компиляции". Когда говорят о раздельной компиляции вс-таки имееют ввиду, по моему, компиляцию раздельных "единиц трансляции", т.е. результат макроподстановок и как раз #include деректив. Или я путаю? Если нет, то в данном случае вообще не имеет смылс говорить о раздельной компиляции - здесь единица трансляции вообще одна.
А кому она нужна то, эта раздельная компиляция? Только геморой себе наживать.
> А кому она нужна то, эта раздельная компиляция? Только геморой себе наживать.
Вот это заявления!
А что такое тогда библиотеки функций и всё остальное? И динамически подгружаемые тоже в некотором смысле из этой области.
Вот это заявления!
А что такое тогда библиотеки функций и всё остальное? И динамически подгружаемые тоже в некотором смысле из этой области.
Раздельная компиляция - это очень плохо
Вот только когда проект полчаса каждый раз компилируется, это начинает бесить
Вот только когда проект полчаса каждый раз компилируется, это начинает бесить
Если я правильно понял, то по замыслу автора должно было быть как минимум две единицы трансляции --- реализация класса и main.cpp, использующая этот класс.
пока не меняются декларации функций/классов (которые обычно в include файле другие единицы компиляции, использующие оные функции/классы в перекомпиляции не нуждаются даже при изменении определений оных функций/классов. Вот собсвенно суть раздельной компиляции.
При инстанциировании темплатов все-таки учитывается их реализация (определения поэтому раздельная компиляция не особенно уместна.
При инстанциировании темплатов все-таки учитывается их реализация (определения поэтому раздельная компиляция не особенно уместна.
Ну в теории может быть. А на практике изменишь чуть-чуть h файл, который всем нужен - и все, иди пей кофе, пока все заново компилируется.
Какие вообще аргументы есть за разделение на h и cpp/c?
Какие вообще аргументы есть за разделение на h и cpp/c?
так можно ходить пить кофе при изменении .h файла, а если без них, то при каждой компиляции
А та же теория говорит, что нужно интерфейсы продумывать заранее
Хреново раскидали свою лабуду по .h файлам.
Хмм. А на C#, скажем, мне не нужно лабуду раскидывать. И на Яве тоже. Новые языки свободны от этого пережитка прошлого.
Я ж не спорю.
Ты вроде как сам жаловался на .h.
Ты вроде как сам жаловался на .h.
О да, это велтикие языки! Куда там плюсам до них. Настоящие отцы пишут на Яве, в крайнем случае - на ВижуалБэйсике, не на плюсах же в самом деле...
Если интерфейс и реализация разделены, то при изменении реализации не требуется перекомпиляция кода, использующего модуль. При разделении их по отдельным файлам определение модулей, нуждающихся в перекомпиляции, легко автоматизируется.
В С# эта проблема решена на другом уровне. Как в Java не знаю, но полагаю похоже сделано.
Ну извини Отец, что посмел тут упомянуть о презренных язычках - жалких копиях великого C++.
А можно вкратце описать решение?
На другом уровне? Смеёшься что ли? Расскажи тогда на каком, очень интересно...
плюсы действительно сдохли, машинка "корпоративного" софта начинает раскручиваться в сторону C#. Если Страуструп в ближайшее время язык не причешет, то на C++ останется доля низкоуровневого софта
Проблема в том, что C++ оприентирован на последовательную компиляцию исходников (обычно в C++ компиляторах используется два прохода, на первом проходе генерируется АСТ (семантическое дерево программы на втором проходе генерируется код).
В C# и Java нет понятия прохода, исходники компилируются целиком (поэтому в C#/Java можно использовать типы до их объявления, что облегчает циклическое использование грубо говоря компилятор Java/С# делает столько проход сколько ему захочется.
В C# и Java нет понятия прохода, исходники компилируются целиком (поэтому в C#/Java можно использовать типы до их объявления, что облегчает циклическое использование грубо говоря компилятор Java/С# делает столько проход сколько ему захочется.
Что-то я ничего не понял
> C++ оприентирован на последовательную компиляцию исходников
что значит "последовательная"? что за чем следует?
> обычно в C++ компиляторах используется два прохода
это личное дело компилятора, не так ли? как это отражается на его использование?
> В C# и Java нет понятия прохода, исходники компилируются целиком
Что в данном случае целое и что - часть?
Те компиляторы, которые я видел, компилировали целиком всё, что им давали, если не останавливались из-за ошибок.
> в C#/Java можно использовать типы до их объявления,
Про до-диез не в курсе, а можно пример на Java?
> C++ оприентирован на последовательную компиляцию исходников
что значит "последовательная"? что за чем следует?
> обычно в C++ компиляторах используется два прохода
это личное дело компилятора, не так ли? как это отражается на его использование?
> В C# и Java нет понятия прохода, исходники компилируются целиком
Что в данном случае целое и что - часть?
Те компиляторы, которые я видел, компилировали целиком всё, что им давали, если не останавливались из-за ошибок.
> в C#/Java можно использовать типы до их объявления,
Про до-диез не в курсе, а можно пример на Java?
> что значит "последовательная"? что за чем следует?
Это значит, что компилируя какую-либо строку, компилятор только знает (причем по стандарту) только то, что было до этого. Небольшое исключение делается для методов, поэтому и появилось два прохода, изначально был один.
> это личное дело компилятора, не так ли?
для плюсов - это личное дело не компилятора, а стандарта.
> как это отражается на его использование?
в C++ нельзя использовать конструкцию до ее использования
> Что в данном случае целое и что - часть?
целое - сборка, часть - один файл, одна строка
> Те компиляторы, которые я видел, компилировали целиком всё, что им давали, если не останавливались из-за ошибок
C++ компилятор компилирует каждый cpp-файл по отдельности, затем cpp-шники собираются линкером в сборку (dll/exe)
С#/Java - компилируют сборку целиком
> Про до-диез не в курсе, а можно пример на Java?
Вот тебе на шарпе (лень вспоминать Java-у)
class A
{
B B;
public A(B B)
{
this->B = B;
}
}
class B
{
A A;
public B
{
A = new A(this);
}
}
Это значит, что компилируя какую-либо строку, компилятор только знает (причем по стандарту) только то, что было до этого. Небольшое исключение делается для методов, поэтому и появилось два прохода, изначально был один.
> это личное дело компилятора, не так ли?
для плюсов - это личное дело не компилятора, а стандарта.
> как это отражается на его использование?
в C++ нельзя использовать конструкцию до ее использования
> Что в данном случае целое и что - часть?
целое - сборка, часть - один файл, одна строка
> Те компиляторы, которые я видел, компилировали целиком всё, что им давали, если не останавливались из-за ошибок
C++ компилятор компилирует каждый cpp-файл по отдельности, затем cpp-шники собираются линкером в сборку (dll/exe)
С#/Java - компилируют сборку целиком
> Про до-диез не в курсе, а можно пример на Java?
Вот тебе на шарпе (лень вспоминать Java-у)
class A
{
B B;
public A(B B)
{
this->B = B;
}
}
class B
{
A A;
public B
{
A = new A(this);
}
}
Что касается внешних библиотек, то с ними все ясно - документация генерируется из коментариев, а вся информация о типах хранится в самой dll (не обычной, а .NET'овской). Заголовочные файлы здесь, очевидно, не нужны.
Что касается конкретного проекта, то про него в документации я ничего не видел. Но судя по всему компилятор создает вспомогательный файл, где хранит информацию о ссылках. Эксперименты показали, что если меняется файл, от которого зависит другой файл, то тот тоже перекомпилируется, что, в принципе, и понятно.
Что касается конкретного проекта, то про него в документации я ничего не видел. Но судя по всему компилятор создает вспомогательный файл, где хранит информацию о ссылках. Эксперименты показали, что если меняется файл, от которого зависит другой файл, то тот тоже перекомпилируется, что, в принципе, и понятно.
> Но судя по всему компилятор создает вспомогательный файл, где хранит информацию о ссылках.
Зачем дополнительный файл?
Дополнительный файл не создается. Информация о ссылках между сборками хранится в файле проекта, решение о перекомпиляции компилятор принимает на основе отметок времени зависимого файла и зависящего файла
Зачем дополнительный файл?
Дополнительный файл не создается. Информация о ссылках между сборками хранится в файле проекта, решение о перекомпиляции компилятор принимает на основе отметок времени зависимого файла и зависящего файла
Если и интерфейс, и реализация находятся в одном файле, то информации о зависимости между файлами недостаточно, чтобы принять верное решение при сборке. Это проблема рассматриваемых языков, но никак не достоинство.
Еще раз повторяю, одна сборка компилируется целиком (сколько не было в ней файлов компилятор сам разрешает зависимости внутри одной сборки
Зависимости есть только между самими сборками
Зависимости есть только между самими сборками
Речь не о сборках. А о файлах в одном проекте.
В самом csproj такая информация нахрен не нужна и ее там нет. Там только ссылки на внешние dll. Зато есть некий файл ИмяПроекта.projdata.
В самом csproj такая информация нахрен не нужна и ее там нет. Там только ссылки на внешние dll. Зато есть некий файл ИмяПроекта.projdata.
Это какой-то левый файл. Например, в Web-нутых проектах этого файла нет, но сборки все равно нормально собираются.
( Я так понимаю, речь идёт только о C#, т.к. в Java всё несколько не так.)
То есть разделение на файлы не имеет смысла с точки зрения раздельной компиляции. Тогда сборка - это и есть единица трансляции. Возникает вопрос: а при изменении реализации сборки (библиотеки) обойтись без перекомпиляции кода, от неё зависящего, если интерфейс не изменён? Как это реализовано?
То есть разделение на файлы не имеет смысла с точки зрения раздельной компиляции. Тогда сборка - это и есть единица трансляции. Возникает вопрос: а при изменении реализации сборки (библиотеки) обойтись без перекомпиляции кода, от неё зависящего, если интерфейс не изменён? Как это реализовано?
Здесь то все понятно. Любая Assembly содержит как информацию о типах, так и номер версии и кое-какую другую информацию. Т.е. может быть одновременно две библиотеки разных версий. Если нужная версия отсутствует, файл просто не запустится. Если ты используешь библиотеку в проекте и ее интерфейс не меняется, то ничего перекомпилировать не придется.
Да, с Java-ой я сильно не разбирался.
> Как это реализовано?
Оставлено на внешние tool-ы.
В теории можно проверить, что не изменилось публичная часть сборки.
ps
Пока это не имеет значение, т.к. шарп компилируется очень быстро.
> Как это реализовано?
Оставлено на внешние tool-ы.
В теории можно проверить, что не изменилось публичная часть сборки.
ps
Пока это не имеет значение, т.к. шарп компилируется очень быстро.
> Оставлено на внешние tool-ы.
Они есть?
> шарп компилируется очень быстро.
Другие модули проекта могут использовать и более другие языки, компиляция которых обходится дороже. Нужна возможность не трогать их без необходимости.
Они есть?
> шарп компилируется очень быстро.
Другие модули проекта могут использовать и более другие языки, компиляция которых обходится дороже. Нужна возможность не трогать их без необходимости.
Номер версии указывается руками или автоматически?
> Они есть?
Пока не интересовался этим вопросом.
Тебя это проблема интересует серьезно?
Пока не интересовался этим вопросом.
Тебя это проблема интересует серьезно?
И так и так можно.
Build и Revision - можно автоматически подставлять.
Major Minor - только руками.
Build и Revision - можно автоматически подставлять.
Major Minor - только руками.
Подобного рода вопросы не могут интересовать меня серьёзно, я любитель.
Нужно для расширения кругозора.
Нужно для расширения кругозора.
Можно ли автоматически определить, что интерфейс не изменился, и перекомпиляция зависимых модулей не нужна?
Можешь объяснить разницу между с++ и с#( одну я уже понял и есть ли этот язык на других системах, есть ли приемственность с с++ . Мне это инетесно в свете активного изучения с++ и не окажусь ли я не удел со своими знаниями, в смысме ликвидности этих знаний...Тут бы узнать что вообще лучше учить ... Подскажите пожалуйста,буду очень признателен!
Зайди на Rsdn.ru и посмотри, там уже раз 20 спрашивали, чем C#(.Net) лучше C++
У меня инета нет 
RSDN Magazine купи
Там на диске зеркало rsdn-а есть
Как же ты без инета C++ изучаешь? Не серьезно - это как-то....
Я по книге Страуструпа. А что в инете можно узнать например?
Обсудить прочитанное с товарищами 
Да у меня друзья есть, а если честно то ты прав изучал бы серьезно мужно было бы общение... А ты сам не программером работаешь,если да то что можешь сказать о персективности изучения с++?
Выложил старое (от середины июля) зеркало сайта rsdn.ru
> то что можешь сказать о персективности изучения с++?
Если ты действительно выучишь c++, то остальные языки тебе дадутся без особых проблем.
Как язык C++ - умер, особенно на платформе Microsoft, еще будет держаться пару лет за счет legacy-софта, а дальше уйдет в нишу low level программирования.
Если ты действительно выучишь c++, то остальные языки тебе дадутся без особых проблем.
Как язык C++ - умер, особенно на платформе Microsoft, еще будет держаться пару лет за счет legacy-софта, а дальше уйдет в нишу low level программирования.
C++ умрёт в тот день, когда напишут хоть одну систему на С# или VisualBasic-е, не раньше. То, что он никогда не был языком для широких масс - факт, который фактом и остаётся. "Дальше уйдет в нишу low level программирования" - похожие вещи рассказывали сразу после появления Явы, однако...
У Java-ы была большая проблема - она была вещью в себе, к ней очень сложно было пристыковать не-java код.
В .net-е это делается без проблем.
ps.
Что такое система?
В .net-е это делается без проблем.
ps.
Что такое система?
ОС.
У С# проблем тоже хватает.
Назови хоть одного КРУПНОГО разработчика КРОМЕ мелкомягких перешедшего на С#
У С# проблем тоже хватает.
Назови хоть одного КРУПНОГО разработчика КРОМЕ мелкомягких перешедшего на С#
Спасибо за информацию. Я тут по ссылке зайти не могу ,может что не так 
Borland 
Зачем же они тогда Delphi.Net в спешном порядке клепают?
Зачем же они тогда Delphi.Net в спешном порядке клепают?
Хе. Про этих я просто молчу. Ни одного приличного продукта не сделали, зато очень любят играть на веяньях толпы. Достаточно вспомнить хотя бы как они на OWL свой поклали и сколько народу тем самым кинули....
А что говорит? Попробуй по ip-у.
ps. Вообще-то странно, два человека как раз сейчас открыли данный файл.
ps. Вообще-то странно, два человека как раз сейчас открыли данный файл.
Для корбы у них что-то есть и приличное.
У меня что-то на z80 вообще не заходит 
Киданием юзеров занимаются почти все крупные компании...
По ip-адресу тоже?
Я этот ip не знаю , но сайт про фильмы грузится и выдает что z80 о online странно...Но пока не зашаривай пж. может заработает!
Большая часть программ, установленных на моих тачках (и практически все хорошие из них написаны на C. На С++, не говоря уже о более новых языках, мало кто ещё умеет хорошо писать, по крайней мере результатов не видно. А вы уже хороните кого-то.
Ну ты загнул. С++ как раз самый популярный в массах язык. Другое дело, что слишком запутанный и мало кто его реально знает и может юзать с полной отдачей. Но это только в минус ему.
А много ли систем на С++ написано?
А много ли систем на С++ написано?
> А много ли систем на С++ написано?
Операционных? №бОС (BeOS) вроде.
MacOSX позволяет драйверы на C++ писать (но сама на C!). Есть продукты для винды для написания драйверов на C++ (самый известный - NuMega DriverStudio).
Операционных? №бОС (BeOS) вроде.
MacOSX позволяет драйверы на C++ писать (но сама на C!). Есть продукты для винды для написания драйверов на C++ (самый известный - NuMega DriverStudio).
Где я загнул? Я говорю, как есть. Результаты творчества тех масс, среди которых C++ популярен, до моей пещеры не доходят.
Sorry, по ошибке на свой счет воспринял
Тредед моде рулит (с) сам-знаешь-кто 
Вот поставишь FreeBSD 5.x и будет там у тебя аж системный демон (devd написанный на C++ .
Не поставлю.
У меня есть ksymoops написанный на С++ -- системная программа
Больше что-то ничего в голову не приходит.
У меня есть ksymoops написанный на С++ -- системная программа
Больше что-то ничего в голову не приходит.
MS сейчас рекомендует писать драйвера на C
да и вроде практически весь Windows тоже на C написан
на их сайте можно посмотреть структуру исходников ядра винды, каталоги, названия файлов и прочее
да и вроде практически весь Windows тоже на C написан
на их сайте можно посмотреть структуру исходников ядра винды, каталоги, названия файлов и прочее
Да знаю я это усё.
Скажем, в той же MacOSX драйверы писать вроде как на C++ можно и даже рекомендуется, но все продвинутые фичи этого языка использовать нельзя (шаблоны, исключения и т.п.).
Скажем, в той же MacOSX драйверы писать вроде как на C++ можно и даже рекомендуется, но все продвинутые фичи этого языка использовать нельзя (шаблоны, исключения и т.п.).
В ветке с количеством анонимусов > 1 не рулит.
(c) мой.
(c) мой.
В .net что делается без проблем ? По-моему, проблем хватает.
Один раз софтверный гигант изрыгнул из себя COM. Подавились, но смирились. Концепция красивая, до определённого момента. Теперь, поднатужившись, вслед за ХР с интерфейсом для педиков (который 90% пользователей сразу же изменяет выродили .NET Теперь во всех предложениях работодателей к огроменному списку всяческих навыков (никогда не понимал, как можно знать СТОЛЬКО технологий, если описание каждой из них занимает по нескольку метров) гордо добавляют .NET
C++ не умрёт под давлением Microsoft, т.к. это язык продуманный, стандартизированный более чем рамками одного софтверного монополиста, пригодный для решения любой задачи на сегодняшний день (конечно, конечно, о сроках речи не ведём).
Один раз софтверный гигант изрыгнул из себя COM. Подавились, но смирились. Концепция красивая, до определённого момента. Теперь, поднатужившись, вслед за ХР с интерфейсом для педиков (который 90% пользователей сразу же изменяет выродили .NET Теперь во всех предложениях работодателей к огроменному списку всяческих навыков (никогда не понимал, как можно знать СТОЛЬКО технологий, если описание каждой из них занимает по нескольку метров) гордо добавляют .NET
C++ не умрёт под давлением Microsoft, т.к. это язык продуманный, стандартизированный более чем рамками одного софтверного монополиста, пригодный для решения любой задачи на сегодняшний день (конечно, конечно, о сроках речи не ведём).
Ты C# юзал?
Очень здоровская вещь.
Так что на .NET бочку не кати, если не знаешь, что это такое.
Очень здоровская вещь.
Так что на .NET бочку не кати, если не знаешь, что это такое.
Вещь, конечно, хорошая. А жаловались, вроде бы, на проблемы состыковки и совместимости. (Да я и COM юзал, только ведь можно было удобнее сделать.)
Я не наезжаю на C# или на Microsoft. Сам долгое время писал проги под Linux, а теперь написание текста программ на vim считаю мазохизмом, хотя он умеет делать всё, что делает редактор кода Visual Studio.
Я не наезжаю на C# или на Microsoft. Сам долгое время писал проги под Linux, а теперь написание текста программ на vim считаю мазохизмом, хотя он умеет делать всё, что делает редактор кода Visual Studio.
Не знаю. Мне очень понравился. Особенно межъязыковое взаимодействие рулит.
Например мне нравиться возможность создания объектов на одном языке используя в роле предка объект, написанный на другом
Например мне нравиться возможность создания объектов на одном языке используя в роле предка объект, написанный на другом
>Ну ты загнул. С++ как раз самый популярный в массах язык.
Самый популярный в массах - VisualBasic. На плюсах реально пишут(а не думают, что пишут) - единицы.
>А много ли систем на С++ написано?
В тех же виндах ощутимая часть кода - плюсовая(С# там вовсе нет)
ОС, полностью написанная на плюсах - SoftKernel.
Самый популярный в массах - VisualBasic. На плюсах реально пишут(а не думают, что пишут) - единицы.
>А много ли систем на С++ написано?
В тех же виндах ощутимая часть кода - плюсовая(С# там вовсе нет)
ОС, полностью написанная на плюсах - SoftKernel.
> C++ не умрёт под давлением Microsoft, т.к. это язык продуманный, стандартизированный более чем рамками одного софтверного монополиста, пригодный для решения любой задачи на сегодняшний день (конечно, конечно, о сроках речи не ведём).
Что же это за стандарт такой, который до сих пор не один компилятор не поддерживает.
Что же это за стандарт такой, который до сих пор не один компилятор не поддерживает.
Возможно тебе не известно, но во всех серьёзных областях стандарты именно так и появляются - сначала различные производители решают определённую проблему, каждый по своему, а уже потом выбирается некое решение и объявляется СТАНДАРТОМ, которому рекомендуется следовать.
>Что же это за стандарт такой, который до сих пор не один компилятор не поддерживает.
А ты сколько компиляторов на соответствие проверил? Готов спорить, что только Мелкомягких.
>Что же это за стандарт такой, который до сих пор не один компилятор не поддерживает.
А ты сколько компиляторов на соответствие проверил? Готов спорить, что только Мелкомягких.
Этому стандарту уже 4 года, а воз и ныне там...
я смотрел VC, Borland, Intel, GCC, Comeau
ps
C++ очень запутанный стандарт, в нем много нестыковок и неодназначностей.
я смотрел VC, Borland, Intel, GCC, Comeau
ps
C++ очень запутанный стандарт, в нем много нестыковок и неодназначностей.
Какой язык, такой и стандарт
Интересный список - не приходило в голову взглянуть на Watcom?
P.S. Тот стандарт, которому ЧЕТЫРЕ года уже поддерживается почти всеми(.NET и Watcom-ом - заведомо не поддерживается(частично) тот которому ДВА года.
P.S. Тот стандарт, которому ЧЕТЫРЕ года уже поддерживается почти всеми(.NET и Watcom-ом - заведомо не поддерживается(частично) тот которому ДВА года.
> Да я и COM юзал, только ведь можно было удобнее сделать.
Так ведь остальные и этого не сделали. Единственная альтернатива Com/Dcom-у это Corba, причем только на межкомпьютерном взаимодействие, на локале Com-у вообще альтернативы нет.
Так ведь остальные и этого не сделали. Единственная альтернатива Com/Dcom-у это Corba, причем только на межкомпьютерном взаимодействие, на локале Com-у вообще альтернативы нет.
Разве Watcom еще живой? Последнее время о Watcom-е не слышно (по крайнем мере на Win-платформе).
> уже поддерживается почти всеми
Так и VC почти поддерживает стандарт, особенно седьмая версия, в ней только нет частичной специализации и внешних шаблонов.
ps
Назови хоть один компилятор, кроме comeau, который поддерживает стандарт C++97 (export шаблонов уже был)
> уже поддерживается почти всеми
Так и VC почти поддерживает стандарт, особенно седьмая версия, в ней только нет частичной специализации и внешних шаблонов.
ps
Назови хоть один компилятор, кроме comeau, который поддерживает стандарт C++97 (export шаблонов уже был)
> В тех же виндах ощутимая часть кода - плюсовая(С# там вовсе нет)
А как можно ядро промышленной ОС написать на C#?
Как _реально_ написать ядро _промышленной_ ОС на C#?
> ОС, полностью написанная на плюсах - SoftKernel.
Это что за чудо такое? И чего авторы сего добивались? Чего добились?
А как можно ядро промышленной ОС написать на C#?
Как _реально_ написать ядро _промышленной_ ОС на C#?
> ОС, полностью написанная на плюсах - SoftKernel.
Это что за чудо такое? И чего авторы сего добивались? Чего добились?
>А как можно ядро промышленной ОС написать на C#?
Никак. Что и было заявлено. И ещё очень многие вещи на нём не сделаешь.
>Это что за чудо такое?
Это действительно ПРОМЫШЛЕННАЯ ОС(одна из самых успешных на сегодня и самая перспективная в отличие от винды.
>И чего авторы сего добивались? Чего добились?
Многого. Мне лень писать - поищи в нете, если вдруг интересно.
Никак. Что и было заявлено. И ещё очень многие вещи на нём не сделаешь.
>Это что за чудо такое?
Это действительно ПРОМЫШЛЕННАЯ ОС(одна из самых успешных на сегодня и самая перспективная в отличие от винды.
>И чего авторы сего добивались? Чего добились?
Многого. Мне лень писать - поищи в нете, если вдруг интересно.
А WIn - платформа ещё живая?
P.S. Нет систем кроме Windows и Microsoft пророк его?
P.P.S. Ссылку на "стандарт C++97" в студию.
P.S. Нет систем кроме Windows и Microsoft пророк его?
P.P.S. Ссылку на "стандарт C++97" в студию.
> Это действительно ПРОМЫШЛЕННАЯ ОС(одна из самых успешных на сегодня и самая перспективная в отличие от винды.
Можно здесь поподробнее? Так как писать тебе лень, то с минимумом слов и максимумом инфы!
Это RTOS? Платформа(ы)? API (POSIX, Win32, сам-себе-API-захерачу)?
Можно здесь поподробнее? Так как писать тебе лень, то с минимумом слов и максимумом инфы!
Это RTOS? Платформа(ы)? API (POSIX, Win32, сам-себе-API-захерачу)?
>Можно здесь поподробнее?
Да.
>Это RTOS?
Да.
>Платформа(ы)?
Host - Unix/Windows
Target - Motorola 68xxx, Intel 80960, SPARC, PowerPC, ARM
>API (POSIX, Win32, сам-себе-API-захерачу)?
Отсутствует. В этом её главное отличие от всех остальных(и связано это с тем, что и система и приложения написаны на ОДНОМ И ТОМ ЖЕ языке - С++).
Да.
>Это RTOS?
Да.
>Платформа(ы)?
Host - Unix/Windows
Target - Motorola 68xxx, Intel 80960, SPARC, PowerPC, ARM
>API (POSIX, Win32, сам-себе-API-захерачу)?
Отсутствует. В этом её главное отличие от всех остальных(и связано это с тем, что и система и приложения написаны на ОДНОМ И ТОМ ЖЕ языке - С++).
Слышал я о такой системе на спецкурсе по RTOS. Но ты лучше скажи, где она применяется. Для персональных компьютеров что больших, что pocket все забивает винда. Может в станках каких-нибудь или интеллектуальной кофеварке?
Кстати, что ты имеешь ввиду под промышленной ОС. И с чего ты взял, что винда не успешная и не перспективная?
И еще,а многие вещи на C# не сделать, зато многие вещи на C++ хоть и можно сделать, но такой геморой огребешь, что сам не рад будешь. Дебилизм пытаться писать на одном языке все, если есть возможность реализовать все тоже самое на другом с куда меньшими трудозатратами.
Куда больший дебилизм кричать, что основной язык сегодняшнего дня умер, просто потому, что Мелкомягкие выпустили какой-то его диалект(который действительно протянет года 3 от силы).
А геморой в плюсах возникает, когда пытаются делать что-то "как бог на душу положит".
А геморой в плюсах возникает, когда пытаются делать что-то "как бог на душу положит".
Тогда на том же спецкурсе ты слышал, где она применяется...
>Кстати, что ты имеешь ввиду под промышленной ОС.
То же, что и весь мир. Вот что ты - не знаю
>И с чего ты взял, что винда не успешная и не перспективная?
И успешная, и перспективная, только:
а) НЕ промышленная,
б) в 98-й - 25% кода на плюсах, в XP - 45%. Тенденцию рюхаешь?
То же, что и весь мир. Вот что ты - не знаю
>И с чего ты взял, что винда не успешная и не перспективная?
И успешная, и перспективная, только:
а) НЕ промышленная,
б) в 98-й - 25% кода на плюсах, в XP - 45%. Тенденцию рюхаешь?
Рюхаю, XP больше всех глючит.
Я не кричал, что С++ умер, протри глаза.
ХР больше всех глючит?
Даже так?
Даже так?
Лично я под промышленной имею в виду ОС, которая широко применяется в IT индустрии.
Какая доля рынка у этого чуда (SoftKernel)? Кстати, задай в гугле запрос на поиск SoftKernel, выбери поиск в группах и отсортируй результаты по времени. Очень любопытная картинка получается.
> в 98-й - 25% кода на плюсах, в XP - 45%. Тенденцию рюхаешь?
Откуда эти цифры? И уж не учитывается ли здесь explorer и т.п?
Какая доля рынка у этого чуда (SoftKernel)? Кстати, задай в гугле запрос на поиск SoftKernel, выбери поиск в группах и отсортируй результаты по времени. Очень любопытная картинка получается.
> в 98-й - 25% кода на плюсах, в XP - 45%. Тенденцию рюхаешь?
Откуда эти цифры? И уж не учитывается ли здесь explorer и т.п?
Убедил. Иди пиши на С#. Хоть не испортишь ничего.
Ок.
А в чём я тебя убедил?
Не знаю, заметил ты или нет, но я не был за/против C/C++/C#.
Вижу, гугл ты пригнорировал. А зря. Ибо это хороший показатель популярности ОС, пусть и специализированной.
Не знаю, заметил ты или нет, но я не был за/против C/C++/C#.
Вижу, гугл ты пригнорировал. А зря. Ибо это хороший показатель популярности ОС, пусть и специализированной.
Нашёл я тут доку за 1997 год (если знаешь новее и на английском - ссылку в студию, пожалуйста).
Весёлый документ. Особенно прикольно упоминание слова secure и отсутствие поддержки MMU на одной странице (hint: смотри свой список архитектур).
Ещё они очень гордятся прямым вызовом сервисов ОС.
А как ещё можно дёргать ОС в отсутствие MMU? Это при том, что в начале усиленно критикуют использование TRAP для системных вызовов.
IMHO чуваки просто замутили себе диссер, а ты и поверил.
Весёлый документ. Особенно прикольно упоминание слова secure и отсутствие поддержки MMU на одной странице (hint: смотри свой список архитектур).
Ещё они очень гордятся прямым вызовом сервисов ОС.
А как ещё можно дёргать ОС в отсутствие MMU? Это при том, что в начале усиленно критикуют использование TRAP для системных вызовов.
IMHO чуваки просто замутили себе диссер, а ты и поверил.
Где можно посмотреть на этот документ, дабы тоже повеселиться?
Под словом secure они наверное что-то своё понимали.
На самом деле, разграничение доступа выполняемого кода к ресурсам системы возможно и без использования MMU, на более высоком уровне. Можно доказывать безопасность кода (понимаемую как правильное использование только разрешенных интерфейсов для доступа к ресурсам или переложить управление доступом на защищенную среду выполнения (интерпретатор).
Идеи совсем не новые, используются в том числе и в Java и в .NET. Только вот с C++ не очень совместимы.
Под словом secure они наверное что-то своё понимали.
На самом деле, разграничение доступа выполняемого кода к ресурсам системы возможно и без использования MMU, на более высоком уровне. Можно доказывать безопасность кода (понимаемую как правильное использование только разрешенных интерфейсов для доступа к ресурсам или переложить управление доступом на защищенную среду выполнения (интерпретатор).
Идеи совсем не новые, используются в том числе и в Java и в .NET. Только вот с C++ не очень совместимы.
> Под словом secure они наверное что-то своё понимали
Есть там такая фраза: software protection.
> На самом деле, разграничение доступа выполняемого кода к ресурсам системы возможно и без использования MMU, на более высоком уровне
Согласен. Ничего такого там нет.
А скажем на S/390 можно аппаратно сделать защиту и без MMU.
Есть там такая фраза: software protection.
> На самом деле, разграничение доступа выполняемого кода к ресурсам системы возможно и без использования MMU, на более высоком уровне
Согласен. Ничего такого там нет.
А скажем на S/390 можно аппаратно сделать защиту и без MMU.
Вот тебе стандарт от 98 года, покажи мне хоть один компилятор, который этому стандарту удовлетворяет (прошло уже 4 года)
Я счситаю, что в этом отношение Borland Builder С++ вроде ничего так, но с удовольствием полсушаю о его несоответствиях, самому интересно.
Я вот тоже так считал пока не стал на нем использовать сложные навороты...
На сложных шаблонах (вложенных, наследовании одного шаблона от другого) ведет себя хуже, чем vc6. Компилятор падает часто и на ровном месте. Хотя на простых шаблонах все хорошо.
На сложных шаблонах (вложенных, наследовании одного шаблона от другого) ведет себя хуже, чем vc6. Компилятор падает часто и на ровном месте. Хотя на простых шаблонах все хорошо.
хм.. интересно, надо будет поэксперементировать...
Кстати тут с одной порблемой стлокнулся в STL, долго не разбирался, поэтому не знаю - моя это проблема, языка ли, компидлятора ли:
Создал класс A, он достаточно большой поэтому создал bool operator< (A&, A&) через ссылки, чтобы избежать лишнего копирования. И поробовал использовать стандартный, скажем, sort: sort (a.begin a.end less<A> - компилятор ругается, говорит ему нужет оператор меньше не через сылки а через полноценный объекты. Неужели стандартные алгоритмы всегда так требуют, это же не эффективно? Или я где-то глючу...
Кстати тут с одной порблемой стлокнулся в STL, долго не разбирался, поэтому не знаю - моя это проблема, языка ли, компидлятора ли:
Создал класс A, он достаточно большой поэтому создал bool operator< (A&, A&) через ссылки, чтобы избежать лишнего копирования. И поробовал использовать стандартный, скажем, sort: sort (a.begin a.end less<A> - компилятор ругается, говорит ему нужет оператор меньше не через сылки а через полноценный объекты. Неужели стандартные алгоритмы всегда так требуют, это же не эффективно? Или я где-то глючу...
На самом деле тут не стоит вопрос, как избежать таких ограничений, а, наверное, о неполноценности стандартныъх предикатов.
> оператор меньше не через сылки а через полноценный объекты.
Может он хочет объекты-итераторы, а не сами объекты?
Может он хочет объекты-итераторы, а не сами объекты?
Не, хочет-то он объекты см. определение less:
template <class T>
struct less : public binary_function<T, T, bool>
{
bool operator (const T& x, const T& y) const { return x < y; }
};
Кстати разобрался, самому стало интересно и разобрался. Оказывается нужно было обязательно определить bool operator< (const A&, const A&) с константными ссылками. После этого все заработало. Я глючил...
template <class T>
struct less : public binary_function<T, T, bool>
{
bool operator (const T& x, const T& y) const { return x < y; }
};
Кстати разобрался, самому стало интересно и разобрался. Оказывается нужно было обязательно определить bool operator< (const A&, const A&) с константными ссылками. После этого все заработало. Я глючил...
Оставить комментарий
mitjt
Столкнулся с такой проблемой:делаю шаблон класса Vector:
// Vector.h
template <class T>
class Vector
{
int N;
T *v;
T& operator[](int i);
};
// Vector.cpp
template<class T>
T& Vector<T>::operator[](int i)
{
return v[ i ] ;
}
// main.cpp
#include "Vector.h"
Vector<double> x;
function
{
x[ i ] = 0;
}
Компилируется нормально, но....
На этапе линковки выдается сообщение
main.obj : error LNK2001: unresolved external symbol "public: double & __thiscall Vector<double>::operator[](int)" (?A?$@Z)
Кто работал с шаблонами, подскажите пожалуйста - где здесь ошибка, или может компилятор (MS VC6.0++) нада настроить.