Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char?
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 19.01.23 18:21
Оценка:
У меня есть функции, реализации которых нужны для разных комбинаций Unicode и ANSI (Unicode/Unicode, ANSI/ANSI, Unicode/ANSI). Строки ANSI используются только в качестве источников (байт дополняется нулевым старшим). Реализации отличаются только используемыми типами. Напрашивается идея оформить их одним шаблоном, но получается затык с "перекрестными" версиями — обычное присваивание из char в wchar_t расширяет знак, а мне нужно расширять нулем.

Если добавить в список параметров шаблона, кроме типов символов источника/результата, еще и третий промежуточный тип для беззнакового char, компилятор не в состоянии вывести его только по параметрам функции. Даже если делаю отдельную функцию ConvertChar, комбинация параметров шаблона все равно однозначно невыводима из комбинации параметров/результатов функций, хотя остальные комбинации, кроме трех основных, не используются. Но добавлять явные параметры шаблона в вызовы функций нельзя — они должны выглядеть, как обычные функции, вызывающий код ничего не знает про их шаблоны.

Как принято бороться с такими проявлениями противоестественного интеллекта?
Re: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char?
От: Videoman Россия https://hts.tv/
Дата: 19.01.23 18:25
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Как принято бороться с такими проявлениями противоестественного интеллекта?


Приведи пример кода где проблема?
Re[2]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 19.01.23 18:41
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Приведи пример кода где проблема?


А что непонятно из описания?

template <typename DstType, typename SrcType, typename IntType>
void s (DstType * Dst, SrcType const * Src) {

  *Dst = static_cast <IntType> (*Src);

}

template void s <wchar_t, wchar_t, wchar_t> (wchar_t *, wchar_t const *);
template void s <char, char, char> (char *, char const *);
template void s <wchar_t, char, unsigned char> (wchar_t *, char const *);

void f () {

  wchar_t * W;
  char * C;

  s (W, W);
  s (C, C);
  s (W, C);

}
Re[3]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: Videoman Россия https://hts.tv/
Дата: 19.01.23 19:18
Оценка: 18 (1)
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А что непонятно из описания?


Да потому-что фиг проссышь, что ты имеешь в виду. Научись задание формулировать четко и однозначно. Это ты хочешь ?:
template <typename dst_t, typename src_t>
struct s_trait_t;
template <>
struct s_trait_t<wchar_t, wchar_t>
{
    using type = wchar_t;
};
template <>
struct s_trait_t<char, char>
{
    using type = char;
};
template <>
struct s_trait_t<wchar_t, char>
{
    using type = unsigned char;
};


template <typename DstType, typename SrcType>
void s (DstType * Dst, SrcType const * Src) 
{
    using IntType = typename s_trait_t<DstType, SrcType>::type;

    *Dst = static_cast <IntType> (*Src);

}

template void s <wchar_t, wchar_t> (wchar_t *, wchar_t const *);
template void s <char, char> (char *, char const *);
template void s <wchar_t, char> (wchar_t *, char const *);

void f () {

  wchar_t * W;
  char * C;

  s (W, W);
  s (C, C);
  s (W, C);

}

int main()
{
  f();
}
Re[4]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 19.01.23 19:30
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Да потому-что фиг проссышь, что ты имеешь в виду. Научись задание формулировать четко и однозначно.


Так чего именно не хватает в описании из того, что видно по коду?

V>struct s_trait_t;


Без этого костыля никак?
Re[5]: Можно ли сделать универсальный шаблон для разных комб
От: Videoman Россия https://hts.tv/
Дата: 19.01.23 19:53
Оценка: 18 (1)
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Так чего именно не хватает в описании из того, что видно по коду?


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

V>>struct s_trait_t;


ЕМ>Без этого костыля никак?


Может так ?:
#include <type_traits>

template <typename DstType, typename SrcType>
void s (DstType * Dst, SrcType const * Src) 
{
    using IntType = typename std::make_unsigned<SrcType>::type;

    *Dst = static_cast<DstType>(static_cast<IntType>(*Src));

}

void f () {

  wchar_t * W;
  char * C;

  s (W, W);
  s (C, C);
  s (W, C);

}

int main()
{
  f();
}
Отредактировано 19.01.2023 20:35 Videoman . Предыдущая версия .
Re[6]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 19.01.23 21:20
Оценка:
Здравствуйте, Videoman, Вы писали:

V>Из описания замучаешься восстанавливать не работающий код.


В каком смысле "не работающий код"? Код здесь вообще ни при чем — проблема в том, что комбинация параметров шаблона (если в них явно добавлять промежуточный тип) не может быть однозначно выведена из комбинации параметров функции и ее возвращаемого типа. Получается, что решить можно только с костылями — хоть явными, хоть библиотечными. Придется их использовать.
Re[7]: Можно ли сделать универсальный шаблон для разных комб
От: Videoman Россия https://hts.tv/
Дата: 19.01.23 21:42
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

V>>Из описания замучаешься восстанавливать не работающий код.


ЕМ>В каком смысле "не работающий код"?

Ну тебе понятно что ты хочешь, а из твоей постановки мне, например, не понятно. С кодом быстрее, точнее и быстрее.

ЕМ>Код здесь вообще ни при чем — проблема в том, что комбинация параметров шаблона (если в них явно добавлять промежуточный тип) не может быть однозначно выведена из комбинации параметров функции и ее возвращаемого типа.

Естественно выводы типов делаются только для сигнатуры функции и только для типов которые в ней используются. Если уж тебе прям так хочется сделать промежуточный тип как параметр шаблона, сделай так:
template <typename DstType, typename SrcType, typename IntType = typename std::make_unsigned<SrcType>::type>
void s (DstType * Dst, SrcType const * Src) 
{
    *Dst = static_cast<DstType>(static_cast<IntType>(*Src));
}
Мне трудно судить о твоих вкусах.

ЕМ>Получается, что решить можно только с костылями — хоть явными, хоть библиотечными. Придется их использовать.

Получается, что компилятор несовершенен, и не обязан компилировать весь метод, который может быть ого-го, только для того, что бы вывести типы и понять какую функцию подставлять при вызове. Тело-то может быть и в другом месте, теоретически, определено. Всё тоже самое что и со стандартным Си.
Re: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char?
От: пффф  
Дата: 19.01.23 21:48
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У меня есть функции, реализации которых нужны для разных комбинаций Unicode и ANSI (Unicode/Unicode, ANSI/ANSI, Unicode/ANSI). Строки ANSI используются только в качестве источников (байт дополняется нулевым старшим). Реализации отличаются только используемыми типами. Напрашивается идея оформить их одним шаблоном, но получается затык с "перекрестными" версиями — обычное присваивание из char в wchar_t расширяет знак, а мне нужно расширять нулем.


Не понял, а в чем проблема расширять через промежуточный каст в unsigned char?
Re[2]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: Videoman Россия https://hts.tv/
Дата: 19.01.23 21:58
Оценка:
Здравствуйте, пффф, Вы писали:

П>Не понял, а в чем проблема расширять через промежуточный каст в unsigned char?


Он же обобщенный код хочет. А промежуточный каст wchar_t к unsigned char, это уже обрезание получается.
Re[3]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: пффф  
Дата: 19.01.23 22:14
Оценка:
Здравствуйте, Videoman, Вы писали:

П>>Не понял, а в чем проблема расширять через промежуточный каст в unsigned char?


V>Он же обобщенный код хочет. А промежуточный каст wchar_t к unsigned char, это уже обрезание получается.


У него проблема с расширением char в wchar_t, наоборот — никаких проблем не должно быть.

А обобщенный код можно написать с использованием библиотечных "костылей" типа std::make_unsigned
Re[7]: Можно ли сделать универсальный шаблон для разных комб
От: rg45 СССР  
Дата: 20.01.23 09:38
Оценка: 18 (1) +2
Здравствуйте, Евгений Музыченко, Вы писали:

V>>Из описания замучаешься восстанавливать не работающий код.


ЕМ>В каком смысле "не работающий код"? Код здесь вообще ни при чем — проблема в том, что комбинация параметров шаблона (если в них явно добавлять промежуточный тип) не может быть однозначно выведена из комбинации параметров функции и ее возвращаемого типа. Получается, что решить можно только с костылями — хоть явными, хоть библиотечными. Придется их использовать.


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

Например, можно было бы сформулировать правило таким образом: "когда тип назначения (Dst) больше по рамеру, чем исходный тип (Src), выполнить промежуточное преобразование Src к беззнаковому типу, во всех остальных случаях промежуточный тип совпадает с Src". При такой формулировке, утилиту преобразования типов, предложенную здесь
Автор: Videoman
Дата: 19.01.23
, можно было бы переписать более универсально:

template <typename dst_t, typename src_t, typename = void>
struct s_trait_t
{
    using type = src_t;
};

template <typename dst_t, typename src_t>
struct s_trait_t<dst_t, src_t, std::enable_if_t<(sizeof(dst_t) > sizeof(src_t))>>
{
    using type = std::make_unsigned_t<src_t>;
};


Вообще, самых разных реализаций здесь можно придумать вагон и маленькую тележку, но все только в зависимости от ТВОИХ требований.
--
Не можешь достичь желаемого — пожелай достигнутого.
Отредактировано 20.01.2023 10:12 rg45 . Предыдущая версия . Еще …
Отредактировано 20.01.2023 10:08 rg45 . Предыдущая версия .
Re[8]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 20.01.23 10:25
Оценка:
Здравствуйте, rg45, Вы писали:

R>костыльным предложенное решение тебе видится только лишь потому, что ты не смог, или просто не удосужился, эти правила сформулировать.


Я уже много раз писал, что считаю "костыльными" любые решения, основанные на побочных эффектах использования шаблонов, хотя они давно стали нормой и освящены с самых высоких позиций. У меня нет проблем с формулировкой правил, а вот возможности довести их непосредственно до компилятора у меня нет — только путем влияния на его работу косвенно, через задницу. Но что ж делать — за неимением гербовой придется писать на клозетной.
Re[9]: Можно ли сделать универсальный шаблон для разных комб
От: rg45 СССР  
Дата: 20.01.23 10:31
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Я уже много раз писал, что считаю "костыльными" любые решения, основанные на побочных эффектах использования шаблонов, хотя они давно стали нормой и освящены с самых высоких позиций.


И тебе не раз отвечали: считай что угодно, на здоровье.

ЕМ>У меня нет проблем с формулировкой правил,


Только, как минимум, уже двое человек не смогли понять, чего ты хочешь.

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


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

ЕМ>Но что ж делать — за неимением гербовой придется писать на клозетной.


Я не пойму, зачем тебе этот плохой язык. Тебя принуждают его использовать?
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[10]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 20.01.23 10:56
Оценка:
Здравствуйте, rg45, Вы писали:

R>как минимум, уже двое человек не смогли понять, чего ты хочешь.


Ну, кто-то мыслит в терминах задачи, как я, а кто-то — в терминах кода. Я тоже часто не понимаю, что хотят сказать те, кто вываливает кусок кода, добавляя к нему "не компилируется, в чем проблема?".

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


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

R>Я не пойму, зачем тебе этот плохой язык. Тебя принуждают его использовать?


Покажите мне другой язык, на котором можно делать драйверы ядра для Windows, в котором накладные расходы не превышают микросекунд — я рассмотрю.
Re[11]: Можно ли сделать универсальный шаблон для разных ком
От: Videoman Россия https://hts.tv/
Дата: 20.01.23 13:49
Оценка: +2
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Еще раз: "довести до компилятора" — это объяснить нужные правила непосредственно ему. Когда для типа указывается модификатор unsigned или const, для числа — суффикс "длинное", для строки — префикс "широкая", то это оно самое. Когда используются побочные эффекты механизма, придуманного совсем для другого, просто потому, что "это работает" — это костыль. И очень удручает, что парадигма языка, предостерегая от чрезмерного использования побочных эффектов в "базовом" наборе функций, столь же чрезмерно поощряет это в шаблонном механизме, лишая язык более адекватных способов управления компиляцией.


Я написал на "побочке", так как ты не соизволил сообщить какую версию компилятора С++ используешь. Из опыта общения предположил, что самую самую древнюю, которая еще как-то работает. В современном С++ для всего этого есть Concept-ы, где все уже пишется на адекватном, специально приспособленном для этого языке, всё как ты хочешь. В любом случае, так как ты работаешь с типами, это будет вызов мета-функции, хоть здесь, хоть там.
Отредактировано 20.01.2023 14:17 Videoman . Предыдущая версия .
Re: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char?
От: Sm0ke Россия ksi
Дата: 20.01.23 17:36
Оценка: +1
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У меня есть функции, реализации которых нужны для разных комбинаций Unicode и ANSI (Unicode/Unicode, ANSI/ANSI, Unicode/ANSI). Строки ANSI используются только в качестве источников (байт дополняется нулевым старшим). Реализации отличаются только используемыми типами. Напрашивается идея оформить их одним шаблоном, но получается затык с "перекрестными" версиями — обычное присваивание из char в wchar_t расширяет знак, а мне нужно расширять нулем.


ЕМ>Если добавить в список параметров шаблона, кроме типов символов источника/результата, еще и третий промежуточный тип для беззнакового char, компилятор не в состоянии вывести его только по параметрам функции. Даже если делаю отдельную функцию ConvertChar, комбинация параметров шаблона все равно однозначно невыводима из комбинации параметров/результатов функций, хотя остальные комбинации, кроме трех основных, не используются. Но добавлять явные параметры шаблона в вызовы функций нельзя — они должны выглядеть, как обычные функции, вызывающий код ничего не знает про их шаблоны.


ЕМ>Как принято бороться с такими проявлениями противоестественного интеллекта?


// function
{
if constexpr( std::is_signed_v<T> ) {}
else {}
}

Это поможет?
Re[9]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 20.01.23 18:10
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Я уже много раз писал, что считаю "костыльными" любые решения, основанные на побочных эффектах использования шаблонов, хотя они давно стали нормой и освящены с самых высоких позиций.


Причем тут SFINAE? Его, кстати, гораздо меньше в современных плюсах используют, потому что доработали язык. Но тебе не хочется изучать современный C++, гораздо проще скопом всё обозвать костылями
Маньяк Робокряк колесит по городу
Re[12]: Можно ли сделать универсальный шаблон для разных ком
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 12:49
Оценка:
Здравствуйте, Videoman, Вы писали:

V>В современном С++ для всего этого есть Concept-ы, где все уже пишется на адекватном, специально приспособленном для этого языке


Согласен, забыл обозначить, что "самый современный" пока не подходит из соображений совместимости с прежними версиями винды.
Re[10]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 12:52
Оценка:
Здравствуйте, Marty, Вы писали:

M>Причем тут SFINAE? Его, кстати, гораздо меньше в современных плюсах используют, потому что доработали язык.


Да, с опозданием лет на двадцать.

M>Но тебе не хочется изучать современный C++, гораздо проще скопом всё обозвать костылями


Изучать мне как раз хочется, но проблема в том, что в моей основной области (драйверы ядра под винду) в нагрузку к "современному C++" идет неадекватно тормозная студия вкупе с ограниченной совместимостью.
Re[11]: Можно ли сделать универсальный шаблон для разных комб
От: rg45 СССР  
Дата: 21.01.23 12:55
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Изучать мне как раз хочется, но проблема в том, что в моей основной области (драйверы ядра под винду) в нагрузку к "современному C++" идет неадекватно тормозная студия вкупе с ограниченной совместимостью.


Ты попробовал и убедился в том, что она тормозная, или говоришь предположительно? Ну и, если пробовал, то какие именно студии?
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[11]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 21.01.23 12:59
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>Причем тут SFINAE? Его, кстати, гораздо меньше в современных плюсах используют, потому что доработали язык.


ЕМ>Да, с опозданием лет на двадцать.


На 10, даже меньше. Уже 11ые хорошо продвинулись


M>>Но тебе не хочется изучать современный C++, гораздо проще скопом всё обозвать костылями


ЕМ>Изучать мне как раз хочется, но проблема в том, что в моей основной области (драйверы ядра под винду) в нагрузку к "современному C++" идет неадекватно тормозная студия вкупе с ограниченной совместимостью.


Тебе больше брюзжать и стенать нравится. Чего в ней неадекватно тормозного? Нормально с ней всё. И с совместимостью что не так? На худой конец, куда-нибудь в 2005ую присунь компилятор поновее, и радуйся жизни
Маньяк Робокряк колесит по городу
Re[12]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 13:43
Оценка:
Здравствуйте, rg45, Вы писали:

R>Ты попробовал и убедился в том, что она тормозная


Конечно, попробовал. В итоге выдрал оттуда build tools, использую их для финальных сборок того, что требует новых версий, а основную работу делаю в VS 2008.

R>какие именно студии?


Все от 2010 до 2019. Те, что до 2013 включительно, еще не так сильно тормозят, но там и нет значимых преимуществ по сравнению с 2008. Более-менее адекватная поддержка с++11 начинается с 2015, но там тормоза уже совсем некомфортные.
Re[12]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 14:06
Оценка: +1
Здравствуйте, Marty, Вы писали:

M>Тебе больше брюзжать и стенать нравится.


Мне это не нравится, но у меня нет возможности делать что-либо более продуктивное в этом плане.

M>Чего в ней неадекватно тормозного?


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

M>И с совместимостью что не так?


Где-то с 2015-й MS перенесла реализацию многих функций CRT из библиотек VC++ в библиотеки SDK. Это создало ряд дополнительных зависимостей, которые ломают давно налаженные взаимодействия моего кода со стандартными библиотеками. Да, это потому, что я предпочитаю контролировать код, который зависимости тащат в исполняемые модули. Если бы я, как большинство остальных, просто "записывал бы алгоритм конструкциями языка", было бы проще.

M>куда-нибудь в 2005ую присунь компилятор поновее, и радуйся жизни


Присунуть-то присунул, а вот радоваться не выходит — даже при использовании только конструкций, поддерживаемых родным компилятором, новые выдают много предупреждений, справки по которым в VS 2008 нет, за нею нужно лазить в сеть. А если использовать там новые конструкции, то IntelliSense студии их не понимает, и тупо не покажет константы какого-нибудь enum class или значение constexpr.
Re[13]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 21.01.23 14:23
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>Тебе больше брюзжать и стенать нравится.


ЕМ>Мне это не нравится, но у меня нет возможности делать что-либо более продуктивное в этом плане.


Поэтому ты продолжаешь брюзжать и стенать? Ну, окей


M>>Чего в ней неадекватно тормозного?


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


Хз, я не ощущаю. Впрочем, я код в фаре в основном пишу, в студии только отладка при нужде


M>>И с совместимостью что не так?


ЕМ>Где-то с 2015-й MS перенесла реализацию многих функций CRT из библиотек VC++ в библиотеки SDK. Это создало ряд дополнительных зависимостей, которые ломают давно налаженные взаимодействия моего кода со стандартными библиотеками. Да, это потому, что я предпочитаю контролировать код, который зависимости тащат в исполняемые модули. Если бы я, как большинство остальных, просто "записывал бы алгоритм конструкциями языка", было бы проще.


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


ЕМ>Присунуть-то присунул, а вот радоваться не выходит — даже при использовании только конструкций, поддерживаемых родным компилятором, новые выдают много предупреждений, справки по которым в VS 2008 нет, за нею нужно лазить в сеть. А если использовать там новые конструкции, то IntelliSense студии их не понимает, и тупо не покажет константы какого-нибудь enum class или значение constexpr.


Да, нет в жизни счастья
Маньяк Робокряк колесит по городу
Re[13]: Можно ли сделать универсальный шаблон для разных комб
От: rg45 СССР  
Дата: 21.01.23 15:03
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


Прямо альтернативная реальность какая-то. Почему я не ощущаю не то что ничего подобного, а мои ощущения прямо противоположны твоим? Можно было бы сказать, что у меня комп какой-то не такой, но у меня их три — один десктоп и два ноута. Все три используются чрезвычайно активно, зачастую одновременно. На двух машинах стоят все линейки студий с 2015 по 2022. Работаю исключительно на 2022-й и желания спрыгнуть на более раннюю не возникает почему-то. Почему так?
--
Не можешь достичь желаемого — пожелай достигнутого.
Re[14]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 16:12
Оценка:
Здравствуйте, Marty, Вы писали:

M>Поэтому ты продолжаешь брюзжать и стенать?


На мой взгляд, "стенать" сюда не совсем подходит. Ругаюсь — да.

M>Впрочем, я код в фаре в основном пишу, в студии только отладка при нужде


Ежли б я не получал удовольствия от IntelliSense, я б вообще не пользовался студией. В EWDK есть все нужные build tools и WinDbg.

ЕМ>>Где-то с 2015-й MS перенесла реализацию многих функций CRT из библиотек VC++ в библиотеки SDK.


M>Вероятно, для этого были предпосылки.


Какие, например? Больше двадцати лет в библиотеках VC++ шел код, специфичный для VC, а в библиотеках SDK/DDK/WDK — код, специфичный для системы. Это всех устраивало.

M>написание дров — это конечно всегда боль, по сравнению с разработкой обычных программ.


С адекватными средствами разработки в этом нет никакой боли — просто не так комфортно и халявно, только и всего. Боль возникает, когда средства разработки низкого уровня делают суровые мужики, воспитанные на парадигмах "только ассемблер", "только чистый C", "только статическая память" и т.п., а средства высокого уровня — воспитанные на парадигмах типа "мег туда, мег сюда — какая разница?". С разработкой для микроконтроллеров ведь такая же хрень.
Re[15]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 21.01.23 16:18
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>Вероятно, для этого были предпосылки.


ЕМ>Какие, например? Больше двадцати лет в библиотеках VC++ шел код, специфичный для VC, а в библиотеках SDK/DDK/WDK — код, специфичный для системы. Это всех устраивало.


Понятия не имею. Как самое простое — зачем тащить две одинаковых реализации в двух разных местах?


ЕМ>С адекватными средствами разработки в этом нет никакой боли — просто не так комфортно и халявно, только и всего. Боль возникает, когда средства разработки низкого уровня делают суровые мужики, воспитанные на парадигмах "только ассемблер", "только чистый C", "только статическая память" и т.п., а средства высокого уровня — воспитанные на парадигмах типа "мег туда, мег сюда — какая разница?". С разработкой для микроконтроллеров ведь такая же хрень.


Нет никаких проблем с разработкой под микроконтроллеры. Память — да, в основном статическая, но современный C++ вполне себе используется со всеми фишками
Маньяк Робокряк колесит по городу
Re[14]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 16:18
Оценка:
Здравствуйте, rg45, Вы писали:

R>Почему я не ощущаю не то что ничего подобного, а мои ощущения прямо противоположны твоим?


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

R>На двух машинах стоят все линейки студий с 2015 по 2022. Работаю исключительно на 2022-й


Тогда зачем стоят остальные? Чисто "лень сносить"?
Re[15]: Можно ли сделать универсальный шаблон для разных ком
От: rg45 СССР  
Дата: 21.01.23 16:31
Оценка: +1
Здравствуйте, Евгений Музыченко, Вы писали:

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


Во-первых, сотня-другая миллисекунд — это достаточно большая задержка, которую почувствует кто угодно, я думаю (это примерно равно интервалу времени между нажатиями клавиш при наборе текста — это еще как чувствительно). А во-вторых, что значит я "не слишком четко ощущаю", когда я пишу
Автор: rg45
Дата: 21.01.23
, что я достаточно четко ощущаю обратный эффект. Новые студии реально работают быстрее старых и это ясно ощутимо. А в 2022-й студии еще и навигацию по коду сделали весьма достойную, я все чаще пользусь встроенной, вместо visual assist. Работать становится все комфортнее и комфортнее. Почему у тебя все как-то по-другому происходит — вот, что интересно.


R>>На двух машинах стоят все линейки студий с 2015 по 2022. Работаю исключительно на 2022-й


ЕМ>Тогда зачем стоят остальные? Чисто "лень сносить"?


А зачем их сносить? Они ж есть не просят. При сносе может еще и поломаться что-нибудь (опасение у меня такое есть). А изредка бывает интересно откомпилировать и запустить что-нибудь на старых версиях. Выработанная практика такова, что старые студии отправляются в утиль вместе с компом.
--
Не можешь достичь желаемого — пожелай достигнутого.
Отредактировано 21.01.2023 17:31 rg45 . Предыдущая версия . Еще …
Отредактировано 21.01.2023 17:31 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 17:29 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 16:55 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 16:44 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 16:39 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 16:35 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 16:34 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 16:32 rg45 . Предыдущая версия .
Re[16]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 17:17
Оценка:
Здравствуйте, Marty, Вы писали:

M>зачем тащить две одинаковых реализации в двух разных местах?


Где они были одинаковыми?

M>Нет никаких проблем с разработкой под микроконтроллеры. Память — да, в основном статическая, но современный C++ вполне себе используется со всеми фишками


"Нет никаких проблем" началось примерно с сотни мегагерц тактовой, и сотни килобайт памяти под код.
Re[17]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 21.01.23 17:31
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>зачем тащить две одинаковых реализации в двух разных местах?


ЕМ>Где они были одинаковыми?


Ну, может код и был разный, а функционал — одинаковый. Не?


M>>Нет никаких проблем с разработкой под микроконтроллеры. Память — да, в основном статическая, но современный C++ вполне себе используется со всеми фишками


ЕМ>"Нет никаких проблем" началось примерно с сотни мегагерц тактовой, и сотни килобайт памяти под код.


Ну, под PIC'и и прочие MSC51 до сих пор на сишечке да на асме пишут, потому что для них просто нет плюсов, да и архитектура кривая шо пипец, там на любом языке всё через одно место. А так, я под STM с минималкой флешки и ОЗУ писал (может и не с самой минималкой, конечно, что-то вроде 4Кб/1Кб, может и побольше чутка, могу соврать). Современный C++ даже лучше для этого приспособлен, чем 0x03, и тем более, чем чистая сишечка.

Как-то писал жирный проект, долго писал, несколько месяцев, и он перестал влезать во флешку — то ли 192 Кб, то ли чуть больше 200. Поковырял MAP файл, много нового узнал, что делает кейловский компилятор, пофиксил, и всё стало влезать с большим запасом
Маньяк Робокряк колесит по городу
Re[15]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 21.01.23 17:36
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


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


Если печатать со скоростью хотя бы 300cpm, то это 200 мс между нажатиями, и это довольно средняя скорость печати, дофига бы народа замечала
Маньяк Робокряк колесит по городу
Re[16]: Можно ли сделать универсальный шаблон для разных ком
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 17:52
Оценка:
Здравствуйте, rg45, Вы писали:

R>Новые студии реально работают быстрее старых и это ясно ощутимо.


Хм, 2022 я пока не пробовал, не так давно спрашивал в "средствах разработки" о разнице между 2019 и 2022, и по поводу улучшения быстродействия высказались лишь "побыстрее отмерзает при загрузке больших солюшенов", а в остальном писали об ощущении большей тупости. С тех пор что-то поменялось?
Re[17]: Можно ли сделать универсальный шаблон для разных ком
От: rg45 СССР  
Дата: 21.01.23 18:04
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Хм, 2022 я пока не пробовал, не так давно спрашивал в "средствах разработки" о разнице между 2019 и 2022, и по поводу улучшения быстродействия высказались лишь "побыстрее отмерзает при загрузке больших солюшенов", а в остальном писали об ощущении большей тупости. С тех пор что-то поменялось?


Я затрудняюсь ответить на поставленный вопрос, это лучше спросить у авторов высказываний о "большей тупости". Лично у меня и от 2019-й студии впечатления неплохие были.
--
Не можешь достичь желаемого — пожелай достигнутого.
Отредактировано 21.01.2023 18:06 rg45 . Предыдущая версия . Еще …
Отредактировано 21.01.2023 18:05 rg45 . Предыдущая версия .
Отредактировано 21.01.2023 18:04 rg45 . Предыдущая версия .
Re[18]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 18:05
Оценка:
Здравствуйте, Marty, Вы писали:

M>Ну, может код и был разный, а функционал — одинаковый. Не?


Не. В библиотеках VC++ были реализации средств CRT, в библиотеках SDK/DDK/WDK — реализации интерфейсов с системными API. Вполне логично.

M>>>Нет никаких проблем с разработкой под микроконтроллеры. Память — да, в основном статическая, но современный C++ вполне себе используется со всеми фишками


ЕМ>>"Нет никаких проблем" началось примерно с сотни мегагерц тактовой, и сотни килобайт памяти под код.


M>под PIC'и и прочие MSC51 до сих пор на сишечке да на асме пишут, потому что для них просто нет плюсов


GCC для AVR есть давным-давно.

M>я под STM с минималкой флешки и ОЗУ писал (может и не с самой минималкой, конечно, что-то вроде 4Кб/1Кб, может и побольше чутка, могу соврать).


Так и я писал на C++ — с классами, наследованием, виртуальными функциями и шаблонами — для ATTiny13. И показывал фанатам Pure C, что код получается [почти] байт в байт с реализацией того же алгоритма на C.

M>Современный C++ даже лучше для этого приспособлен, чем 0x03, и тем более, чем чистая сишечка.


Безусловно.

M>Как-то писал жирный проект, долго писал, несколько месяцев, и он перестал влезать во флешку — то ли 192 Кб, то ли чуть больше 200. Поковырял MAP файл, много нового узнал, что делает кейловский компилятор, пофиксил, и всё стало влезать с большим запасом


Только вот у большинства писателей жирных проектов для писюков и телефонов вместо идеи поковырять MAP-файл возникает лишь идея добавить памяти.
Re[16]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 18:06
Оценка: :)
Здравствуйте, Marty, Вы писали:

M>Если печатать со скоростью хотя бы 300cpm, то это 200 мс между нажатиями, и это довольно средняя скорость печати, дофига бы народа замечала


На обычном "потоковом" наборе, слава богу, таких задержек нет, иначе бы действительно все вешались. Они есть на операциях редактирования, открывании менюшек, навигации и т.п.
Re[19]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 21.01.23 18:14
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


M>>под PIC'и и прочие MSC51 до сих пор на сишечке да на асме пишут, потому что для них просто нет плюсов


ЕМ>GCC для AVR есть давным-давно.


А причем тут AVR? AVR — это же ардуинка, не? Прекрасно под неё на плюсах пишут


M>>я под STM с минималкой флешки и ОЗУ писал (может и не с самой минималкой, конечно, что-то вроде 4Кб/1Кб, может и побольше чутка, могу соврать).


ЕМ>Так и я писал на C++ — с классами, наследованием, виртуальными функциями и шаблонами — для ATTiny13. И показывал фанатам Pure C, что код получается [почти] байт в байт с реализацией того же алгоритма на C.


И с чем ты тогда споришь?


M>>Как-то писал жирный проект, долго писал, несколько месяцев, и он перестал влезать во флешку — то ли 192 Кб, то ли чуть больше 200. Поковырял MAP файл, много нового узнал, что делает кейловский компилятор, пофиксил, и всё стало влезать с большим запасом


ЕМ>Только вот у большинства писателей жирных проектов для писюков и телефонов вместо идеи поковырять MAP-файл возникает лишь идея добавить памяти.


Ну, вот я на плюсах под писюк пишу. У меня проект на MSVC2019 собирается, C++17, ни в чем себе не отказываю, 2.1 Мб x64 экзешник в релизе (x86 — 1.9). Меня устраивает, нигде ковыряться нет желания. Может, не в языке дело?
Маньяк Робокряк колесит по городу
Re[20]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 22:35
Оценка:
Здравствуйте, Marty, Вы писали:

M>А причем тут AVR?


Наверное, при том, что это семейство микроконтроллеров.

M>AVR — это же ардуинка, не?


Э-э-э... Несколько наоборот: "ардуинка" — это набор из типовой платы на одной из моделей ATMega и разной периферии под нее. Примерно как первые писюки были типовыми платами на процессорах Intel с периферией для них.

M>Прекрасно под неё на плюсах пишут


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

M>И с чем ты тогда споришь?


С утверждениями о том, что плюсы якобы чуть ли не с рождения активно использовались для низкоуровневых задач. Я хорошо помню, какими уродливыми и тормозными они были еще на стыке 80-х и 90-х. Если какой-то софт был толстым и/или тормозным, и при этом не был написан на каком-нибудь FoxPro или Clipper, он чаще всего был написан на плюсах.

M>>>Как-то писал жирный проект, долго писал, несколько месяцев, и он перестал влезать во флешку — то ли 192 Кб, то ли чуть больше 200. Поковырял MAP файл, много нового узнал, что делает кейловский компилятор, пофиксил, и всё стало влезать с большим запасом


M>2.1 Мб x64 экзешник в релизе (x86 — 1.9). Меня устраивает, нигде ковыряться нет желания. Может, не в языке дело?


А если вдруг окажется, что процентов тридцать от этой пары мегабайт там лишь от несовершенства языка — тоже будет устраивать?
Re[21]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 21.01.23 23:11
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>А причем тут AVR?


ЕМ>Наверное, при том, что это семейство микроконтроллеров.


Смешно


M>>AVR — это же ардуинка, не?


ЕМ>Э-э-э... Несколько наоборот: "ардуинка" — это набор из типовой платы на одной из моделей ATMega и разной периферии под нее. Примерно как первые писюки были типовыми платами на процессорах Intel с периферией для них.


Для обывателя это примерно одно и то же


M>>Прекрасно под неё на плюсах пишут


ЕМ>Да — через много лет после того, как появился первый плюсовый компилятор, и народу долго и старательно объясняли, что плюсы, если умеючи, можно использовать для мелких контроллеров. До этого, как и с кодом ядра под любую промышленную ОС, "дураку было понятно", что либо голый C, либо ассемблер, другие варианты тупо не рассматривались.


Позволю уточнить — через много лет после того, как появились плюсики, писать на них под ардуинку научили даже домохозяек. А на сишечке или на питоне — писать под ардуинку как-то не особо домохохяек получилосьнаучить.


ЕМ>С утверждениями о том, что плюсы якобы чуть ли не с рождения активно использовались для низкоуровневых задач. Я хорошо помню, какими уродливыми и тормозными они были еще на стыке 80-х и 90-х. Если какой-то софт был толстым и/или тормозным, и при этом не был написан на каком-нибудь FoxPro или Clipper, он чаще всего был написан на плюсах.


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


M>>>>Как-то писал жирный проект, долго писал, несколько месяцев, и он перестал влезать во флешку — то ли 192 Кб, то ли чуть больше 200. Поковырял MAP файл, много нового узнал, что делает кейловский компилятор, пофиксил, и всё стало влезать с большим запасом


M>>2.1 Мб x64 экзешник в релизе (x86 — 1.9). Меня устраивает, нигде ковыряться нет желания. Может, не в языке дело?


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


Да ваще насрать. Особенно, если чтобы сэкономить эти 30%, мне надо будет жмыхаться на чистой сишечке в 10-20 раз дольше. Хейтил бы уж джаву какую-нибудь, или питона, или шарпеев. А то прикопался к плюсикам, которые просто нормально осиливать не хочешь
Маньяк Робокряк колесит по городу
Re[22]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 21.01.23 23:53
Оценка:
Здравствуйте, Marty, Вы писали:

M>Для обывателя это примерно одно и то же


Кто именно здесь обыватель — Вы, я, или типичный программист для AVR?

M>через много лет после того, как появились плюсики, писать на них под ардуинку научили даже домохозяек. А на сишечке или на питоне — писать под ардуинку как-то не особо домохохяек получилосьнаучить.


Насколько я знаю, домохозяйки пишут для Arduino исключительно простенькие скетчи, пользуясь крайне примитивным подмножеством C++ — примерно на уровне бейсика. Это как про забивающего микроскопом гвозди говорить, что он "занимается микроскопией".

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


Чтоб использовать плюсы для серьезных низкоуровневых задач в самом начале 90-х, их нужно было готовить столько, что быстрее и проще было писать на C. Тогда даже в "C с классами" были подводные камни вроде порядка вызова конструкторов/деструкторов, тонкостей преобразования типов при выборе перегруженных функций и т.п., а уж шаблоны только-только появились, и оптимизации для похожего кода практически не было.

M>и на плюсах можно написать кривой и тормозной софт. Как и на любом другом языке


Парадигма плюсов этому очень способствует. Я не раз слышал в свой адрес упреки в том, что якобы "пищу не на плюсах", ибо использую их "не в соответствии с парадигмой". Но я свободно могу послать любого автора такого упрека, и продолжать дальше писать, как считаю нужным, но большая-то часть софта делается корпоративно. И наверху обычно сидят идеологи, которые говорят всем: "все должно быть кошерно". Там, где типичный сишник обошелся бы небольшой функцией, а то и вовсе макросом, такие идеологи постановляют разработать отдельный класс, сделать для него спецификацию интерфейса, предусмотреть, чтобы класс можно было использовать в гипотетических ситуациях и т.п. Там, где напрашивается сугубо локальное решение, они требуют придумать самостоятельную сущность в парадигме ООП. В итоге получается код, который, грубо говоря, чтобы сложить два и два, создает объекты "два" и "два", ставит их в очередь к объекту "калькулятор", посылает тому сигнал, что нужно провести вычисление, и ждет результата. В какой-то момент исполнители перестают понимать грандиозный замысел идеологов, и начинают плодить отсебятину. В итоге получается очередной монстр, а в его проблемах обвиняют язык.

M>а что восьмидесятые?


То, что C долгое время удавалось развиваться в стиле "если это можно сделать просто, давайте так и сделаем", а C++ с почти самого начала тянули на себя минимум три группы: любители простых и внятных языков типа C, любители тяжеловесных языков типа PL/1 или Algol-68, и любители функциональных языков. Пока то, что все они натолкали в язык на первых порах, более-менее не устаканилось, использовать его для серьезных долгоживущих проектов, не имея собственного компилятора, было рискованным делом.

M>Да ваще насрать.


Ну вот — Вам насрать на 30%, кому-то — на 70%, а кому-то и на 300%, ведь пипл хавает. В Штатах производителям автомобилей когда-то тоже было насрать на расход в 25 литров на сотню, а потом времена изменились, и японцы, которых тогда никто не воспринимал всерьез, внезапно отжали изрядную долю рынка.

M>Особенно, если чтобы сэкономить эти 30%, мне надо будет жмыхаться на чистой сишечке в 10-20 раз дольше.


Вам кто-то предлагает жмыхаться на чистой сишечке?
Re[23]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 00:31
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Кто именно здесь обыватель — Вы, я, или типичный программист для AVR?


По тношению к AVR — я типичный обыватель, так как кроме как в ардуинской студии ничего под них не писал. Когда заинтересовался поплотнее — сразу на STMки пересел и реальные задачи


ЕМ>Насколько я знаю, домохозяйки пишут для Arduino исключительно простенькие скетчи, пользуясь крайне примитивным подмножеством C++ — примерно на уровне бейсика. Это как про забивающего микроскопом гвозди говорить, что он "занимается микроскопией".


Я, как домохозяйка, писал вполне не приметивные скетчи


ЕМ>Чтоб использовать плюсы для серьезных низкоуровневых задач в самом начале 90-х, их нужно было готовить столько, что быстрее и проще было писать на C.


Только не говори, что тебе 60+. Иначе — ты застал примерно тоже, что и я. А в 95ом я учился в техникуме на первом курсе, и старшекурсники бегали и кричали (по поводу выхода Turbo/Borland C++ 3 — не помню, вроде было и то и то, и разное, но могу с Turbo C/Borland C путать — на Турбо Си пописал уже в более зрелом возрасте) — так вот, кричали, что это огонь и пипец какой прорыв


ЕМ>Тогда даже в "C с классами" были подводные камни вроде порядка вызова конструкторов/деструкторов, тонкостей преобразования типов при выборе перегруженных функций и т.п., а уж шаблоны только-только появились, и оптимизации для похожего кода практически не было.


Да не было ничего такого особенно подводного, я на BC++3.1 немало кода наколбасил. Всё что было — оно и сейчас практически такое же. И с шаблонами было нормально, и STL уже была, но да, про SFINAE я тогда не слышал. И с качеством кода было норм (по скорости, баги кодогенератора тогда встречались чаще)


M>>и на плюсах можно написать кривой и тормозной софт. Как и на любом другом языке


ЕМ>Парадигма плюсов этому очень способствует. Я не раз слышал в свой адрес упреки в том, что якобы "пищу не на плюсах", ибо использую их "не в соответствии с парадигмой". Но я свободно могу послать любого автора такого упрека, и продолжать дальше писать, как считаю нужным, но большая-то часть софта делается корпоративно. И наверху обычно сидят идеологи, которые говорят всем: "все должно быть кошерно". Там, где типичный сишник обошелся бы небольшой функцией, а то и вовсе макросом, такие идеологи постановляют разработать отдельный класс, сделать для него спецификацию интерфейса, предусмотреть, чтобы класс можно было использовать в гипотетических ситуациях и т.п. Там, где напрашивается сугубо локальное решение, они требуют придумать самостоятельную сущность в парадигме ООП. В итоге получается код, который, грубо говоря, чтобы сложить два и два, создает объекты "два" и "два", ставит их в очередь к объекту "калькулятор", посылает тому сигнал, что нужно провести вычисление, и ждет результата. В какой-то момент исполнители перестают понимать грандиозный замысел идеологов, и начинают плодить отсебятину. В итоге получается очередной монстр, а в его проблемах обвиняют язык.


Так ты и обвиняешь. Почему на чистой сишечке нельзя такой фуеты наворотить? GObject'ы видел? А если покажу?


M>>а что восьмидесятые?


ЕМ>То, что C долгое время удавалось развиваться в стиле "если это можно сделать просто, давайте так и сделаем", а C++ с почти самого начала тянули на себя минимум три группы: любители простых и внятных языков типа C, любители тяжеловесных языков типа PL/1 или Algol-68, и любители функциональных языков. Пока то, что все они натолкали в язык на первых порах, более-менее не устаканилось, использовать его для серьезных долгоживущих проектов, не имея собственного компилятора, было рискованным делом.


И что? Мысль куда-то потерялась


M>>Да ваще насрать.


ЕМ>Ну вот — Вам насрать на 30%, кому-то — на 70%, а кому-то и на 300%, ведь пипл хавает. В Штатах производителям автомобилей когда-то тоже было насрать на расход в 25 литров на сотню, а потом времена изменились, и японцы, которых тогда никто не воспринимал всерьез, внезапно отжали изрядную долю рынка.


Прикинь, я вообще на плюсиках себе ни в чем не отказываю, размер аппы уже за два метра перевалил, и я таки думаю отжать некоторую долю того рынка, куда прицелился
На жиэс в электроне наверное за пару месяцев можно было бы сделать, я уже больше 4х пилю, но размер как дистра, так и по ОЗУ был бы в лучшем случае раз в 20 больше.

Писал бы на жиэс — уже бы начал отжимать рынок, но плохонько. На плюсах расчитываю отжать больше. И даже 300% сгенерированного кода меня не пугает. Всего-то шесть-семь метров вместо двух. Меня больше пугает проблема, что дистр размером в 5-10 метров будут считать "несолидным", что может отпугнуть некоторую часть пользователей.


M>>Особенно, если чтобы сэкономить эти 30%, мне надо будет жмыхаться на чистой сишечке в 10-20 раз дольше.


ЕМ>Вам кто-то предлагает жмыхаться на чистой сишечке?


Напрямую — нет. Но я не вижу проблемы в "бесовских" шаблонах, которые ты так не любишь. И если эти шаблоны мне экономят время — то я буду их использовать.

Более того. Не всегда обязательно даже понимать досконально, как оно работает внутри, особенно — если просто пользоваться. Я как-то перепилил и немало дополнил под себя одну большую шаблонную либу на C++0x03, так и не поняв до конца, как оно там всё работает Сейчас бы, наверное, разобрался бы, но лень. Работает — и ладно
Маньяк Робокряк колесит по городу
Re: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char?
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 00:37
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

Кстати, вот тут
Автор: пффф
Дата: 20.01.23
подсказали — это не решение твоей проблемы?

А если проблема в том, что у тебя плюсики старые — то и на них можно сделать свои traits для конвертации, делов на 10 минут, и без всяких залезаний в дибуны плюсиков, банальными специализациями (тут только надо, чтобы базовая реализация ломала компиляцию, и добавлять специализации по мере надобности)
Маньяк Робокряк колесит по городу
Re[21]: Можно ли сделать универсальный шаблон для разных комб
От: so5team https://stiffstream.com
Дата: 22.01.23 06:35
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Я хорошо помню, какими уродливыми и тормозными они были еще на стыке 80-х и 90-х. Если какой-то софт был толстым и/или тормозным, и при этом не был написан на каком-нибудь FoxPro или Clipper, он чаще всего был написан на плюсах.


Простите что вмешиваюсь в ваш спор, но это все происходило в СССР? И много вы софта на C++ видели в СССР на стыке 80-х и 90-х? На какой платформе?

В то, что в СССР в 1989-м или 1990-ом многие пробовали Prolog поверю, а вот в то, что пробовали использовать C++, да еще чтобы и софт на нем был массовым... Не припоминаю такого.
Re[24]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 11:08
Оценка:
Здравствуйте, Marty, Вы писали:

M>Только не говори, что тебе 60+.


55.

M>в 95ом я учился в техникуме на первом курсе


А я занимаюсь программированием с 1980-го. С 1982-го — на ассемблерах и в многопоточках, с 1985-го — под ядра ОС.

M>старшекурсники бегали и кричали (по поводу выхода Turbo/Borland C++ 3 — не помню, вроде было и то и то, и разное, но могу с Turbo C/Borland C путать — на Турбо Си пописал уже в более зрелом возрасте) — так вот, кричали, что это огонь и пипец какой прорыв


Так и у нас кричали — "виртуальное наследование, шаблоны, оптимизация, все дела!". А вместе с этим страдали, что совместимость плохая: у BC одни особенности, у MS — другие, у Watcom — третьи, и за пределами "C с классами" начиналось хождение по граблям. А навороченные кусты из шаблонов, которые тогда как раз входили в моду, при тогдашней скорости компилировались чертовски медленно, и выдержать это могли лишь сугубые энтузиасты, которым шашечки были важнее, чем ехать.

M>Да не было ничего такого особенно подводного, я на BC++3.1 немало кода наколбасил.


Переносить под другие компиляторы пробовали?

M>И с качеством кода было норм (по скорости, баги кодогенератора тогда встречались чаще)


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

Одним из хороших примеров такого подхода был Turbo Vision, из которой потом сделали Object Windows, а у MS — MFC. Со стороны исходников и документации все красиво и кошерно — "всё есть объект", везде динамическая память и полиморфизм, обработка событий вешается куда угодно и т.п. Простые приложения на них выглядели действительно просто и изящно, работали быстро, наводя на мысли, что так будет всегда. Но, по мере роста объема исходников, внутренних связей и усложнения взаимодействий, накладные расходы росли лавинообразно. Какой-нибудь чисто косметической правкой можно было легко получить кратный рост тормозов, и приходилось долго прослеживать цепочки своих и внутренних зависимостей, в которых и сами разработчики ориентировались с трудом.

M>Почему на чистой сишечке нельзя такой фуеты наворотить?


Можно, конечно, я тоже знаю примеры. Но и там это возможно в основном за счет подхода — "пишем на C в стиле <язык/технология, которые считаем крутыми>". То есть, сперва на C нужно создать "инфраструктуру", "экосистему" в нужном стиле, а затем уже начать комбинировать полученные "кубики".

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

M>я не вижу проблемы в "бесовских" шаблонах, которые ты так не любишь.


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

M>Работает — и ладно


Вполне себе годный девиз для наколенных поделок. Для промышленных — так себе.
Re[2]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 11:11
Оценка:
Здравствуйте, Marty, Вы писали:

M>это не решение твоей проблемы?


Я ее уже решил через костыльный struct, специализацией которого задается промежуточный тип. Но от того, что у меня получилось, этот метод не стал менее костыльным.
Re[22]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 11:12
Оценка:
Здравствуйте, so5team, Вы писали:

S>это все происходило в СССР?


Все это происходило в мире.
Re[23]: Можно ли сделать универсальный шаблон для разных комб
От: so5team https://stiffstream.com
Дата: 22.01.23 12:09
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

S>>это все происходило в СССР?


ЕМ>Все это происходило в мире.


Т.е. в конце 1980-х вы уже были не в СССР?

ЕМ>А я занимаюсь программированием с 1980-го.


С 12-ти лет?

EM>С 1982-го — на ассемблерах и в многопоточках


С ассемблером понятно. А на каких платформах можно было использовать многопоточность в 1982-1985гг?
Re[24]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 12:32
Оценка:
Здравствуйте, so5team, Вы писали:

S>в конце 1980-х вы уже были не в СССР?


Нет, я был в СССР. СССР был вовсе не так сильно изолирован от остального мира, как принято считать в некоторых кругах. У тех, кто работал в крупных НИИ и ВЦ, был доступ практически ко всей технической литературе, которая печаталась на Западе. Ленты и диски с новым софтом оттуда привозили регулярно, а дальше они уже расходились по стране. А в начале 80-х появились цифровые каналы между крупными научными центрами, софт стали качать по ним.

ЕМ>>А я занимаюсь программированием с 1980-го.


S>С 12-ти лет?


Да.

S>А на каких платформах можно было использовать многопоточность в 1982-1985гг?


На БЭСМ-6, на PDP-11 (под RSX-11M). С настоящей железной многопроцессорностью и истинным параллелизмом (у нас стояло три БЭСМ-6, объединенных в сеть) я тогда особо не связывался, но и там, и там была отличная многозадачность, межпроцессная синхронизация, асинхронные события и все остальное, что к этому прилагается.
Re[25]: Можно ли сделать универсальный шаблон для разных комб
От: so5team https://stiffstream.com
Дата: 22.01.23 12:50
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

S>>в конце 1980-х вы уже были не в СССР?


ЕМ>Нет, я был в СССР. СССР был вовсе не так сильно изолирован от остального мира, как принято считать в некоторых кругах. У тех, кто работал в крупных НИИ и ВЦ, был доступ практически ко всей технической литературе, которая печаталась на Западе. Ленты и диски с новым софтом оттуда привозили регулярно, а дальше они уже расходились по стране. А в начале 80-х появились цифровые каналы между крупными научными центрами, софт стали качать по ним.


Речь же не о литературе, а о программах. И, поскольку вы сравнивали с FoxPro и Clipper, то речь уже о x86 и MS-DOS (или клоны MS-DOS). На рубеже 80-х и 90-х просто под MS-DOS на C++ возможностей попрограммировать было совсем не много. Zortech C++ -- это 1988-ой, Borland C++ 1.0, емнип, 1990-й. А ведь нужно успеть на них еще и что-то запрограммировать.

Собственно, я к тому, что именно на рубеже 80-х и 90-х софта на C++, с которым вы могли бы столкнуться, было совсем совсем мало. Даже странно, что вы вообще с ним столкнулись.

ЕМ>>>А я занимаюсь программированием с 1980-го.


S>>С 12-ти лет?


Это была какая-то спецшкола, кружок/факультатив, возможность программировать у родителей на работе?

ЕМ>Да.


S>>А на каких платформах можно было использовать многопоточность в 1982-1985гг?


ЕМ>На БЭСМ-6, на PDP-11 (под RSX-11M). С настоящей железной многопроцессорностью и истинным параллелизмом (у нас стояло три БЭСМ-6, объединенных в сеть) я тогда особо не связывался, но и там, и там была отличная многозадачность, межпроцессная синхронизация, асинхронные события и все остальное, что к этому прилагается.


Эээ... Как бы многопроцессорность, многопроцессность и многопоточность -- это разные вещи. Именно многопоточность (а не многопроцессность) вроде бы в середине 1980-х только-только начиналась. Могу сильно ошибиться, но вроде как в SunOS. Затем уже она появилась в OS/2, WinNT и в виде POSIX Threads (но это уже 1990-е).
Re[25]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 13:02
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>Да не было ничего такого особенно подводного, я на BC++3.1 немало кода наколбасил.


ЕМ>Переносить под другие компиляторы пробовали?


Пробовал. Но, с учетом того, что на вткоме я прогал уже под dos4gw с его честными 32мя битами, из-под доса с его сегментами при переносе приходилось повозится. Но в целом — ничего страшного


M>>И с качеством кода было норм (по скорости, баги кодогенератора тогда встречались чаще)


ЕМ>Одним из хороших примеров такого подхода был Turbo Vision, из которой потом сделали Object Windows, а у MS — MFC. Со стороны исходников и документации все красиво и кошерно — "всё есть объект", везде динамическая память и полиморфизм, обработка событий вешается куда угодно и т.п. Простые приложения на них выглядели действительно просто и изящно, работали быстро, наводя на мысли, что так будет всегда. Но, по мере роста объема исходников, внутренних связей и усложнения взаимодействий, накладные расходы росли лавинообразно. Какой-нибудь чисто косметической правкой можно было легко получить кратный рост тормозов, и приходилось долго прослеживать цепочки своих и внутренних зависимостей, в которых и сами разработчики ориентировались с трудом.


Сказки какие-то


ЕМ>Я их люблю в той части, в которой они позволяют программировать обобщенно — за то, для чего они и создавались. А за то, что на их побочках успела вырасти целая отрасль технологии, я не люблю ни их, ни тех, кто это продвигает.


Это твоя проблема
Маньяк Робокряк колесит по городу
Re[3]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 13:04
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>это не решение твоей проблемы?


ЕМ>Я ее уже решил через костыльный struct, специализацией которого задается промежуточный тип. Но от того, что у меня получилось, этот метод не стал менее костыльным.


А, ну то есть вместо библиотечного ты свой traits наколбасил. Ну, если ты в 0x03их живешь — норм. Я только в упор не могу понять, с какого перепуга это является, по твоему мнению, костылём.
Маньяк Робокряк колесит по городу
Re[25]: Можно ли сделать универсальный шаблон для разных комб
От: Carc Россия https://vk.com/gosha_mazov
Дата: 22.01.23 13:07
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>На БЭСМ-6, на PDP-11 (под RSX-11M). С настоящей железной многопроцессорностью и истинным параллелизмом (у нас стояло три БЭСМ-6, объединенных в сеть)
А под чем оно (железо) работало?
Aml Pages Home
Re[26]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 13:20
Оценка:
Здравствуйте, Carc, Вы писали:

C>А под чем оно (железо) работало?


В каком смысле "под чем"?
Re[26]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 14:13
Оценка:
Здравствуйте, so5team, Вы писали:

S>Речь же не о литературе, а о программах. И, поскольку вы сравнивали с FoxPro и Clipper, то речь уже о x86 и MS-DOS (или клоны MS-DOS).


Так я и не говорил, что это хоть как-то относилось к СССР.

S>я к тому, что именно на рубеже 80-х и 90-х софта на C++, с которым вы могли бы столкнуться, было совсем совсем мало.


Верно, мало. Первым делом вспоминается Turbo Vision, который был прямо напоказ набит демонстрациями ООП. Еще вроде бы на C++ стали писать старшие версии Norton Utilities, в которых был навороченный интерфейс, но это не точно.

S>Именно многопоточность (а не многопроцессность) вроде бы в середине 1980-х только-только начиналась.


Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница? Параллелизм — он и в Африке параллелизм, что несколько потоков в одном контейнере-процессе, что несколько независимых процессов с общей памятью. Основные-то принципы те же. А многопоточность в рамках одного процесса тогда делали вручную — или полностью своими силами, или с помощью системных средств вроде виндовых fibers.
Re[27]: Можно ли сделать универсальный шаблон для разных комб
От: Carc Россия https://vk.com/gosha_mazov
Дата: 22.01.23 14:19
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, Carc, Вы писали:


C>>А под чем оно (железо) работало?


ЕМ>В каком смысле "под чем"?

ОС
Aml Pages Home
Re[28]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 14:28
Оценка:
Здравствуйте, Carc, Вы писали:

C>>>А под чем оно (железо) работало?


ЕМ>>В каком смысле "под чем"?

C>ОС

Если Вы про группу БЭСМ-6, то основной ОС был ДисПак, к которому было прикручено несложное сетевое расширение (которым, однако, мало кто пользовался). Поверх ДисПака стояла Дубна, но в качестве "мониторной системы", а не полноценной ОС — примерно так же, как первые версии винды поверх доса. Позже к ДисПаку, не имевшему собственной ФС, прикрутили архивно-файловую систему АрФа. Дальнейшей эволюции я уже не застал.
Re[27]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 14:32
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница? Параллелизм — он и в Африке параллелизм, что несколько потоков в одном контейнере-процессе, что несколько независимых процессов с общей памятью. Основные-то принципы те же. А многопоточность в рамках одного процесса тогда делали вручную — или полностью своими силами, или с помощью системных средств вроде виндовых fibers.


Если что, файберы в винду завезли довольно недавно, как бы не в W2K, если не в XP
Маньяк Робокряк колесит по городу
Re[28]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 14:39
Оценка:
Здравствуйте, Marty, Вы писали:

M>файберы в винду завезли довольно недавно


Это к чему?
Re[29]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 14:44
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>файберы в винду завезли довольно недавно


ЕМ>Это к чему?


Забей. Подглючило.

Но файберы — это не настоящая многопоточность, насколько я помню. И проблем многопоточных там не должно быть
Маньяк Робокряк колесит по городу
Re[30]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 14:54
Оценка:
Здравствуйте, Marty, Вы писали:

M>файберы — это не настоящая многопоточность, насколько я помню. И проблем многопоточных там не должно быть


Если переключать только так, как принято для них — по явному запросу, в строго определенные моменты, то не должно. Но в те времена таких механизмов или не было вообще, или были совсем примитивные, поэтому переключали как явно в ранних виндах (yield), так и неявно — по асинхронному событию. Я и под досом как-то делал эмуляцию многопоточки для программы на C, через переключение контекстов по таймерным прерываниям. Такие костыли тогда многие делали для себя.
Re: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char?
От: _NN_ www.nemerleweb.com
Дата: 22.01.23 15:00
Оценка: +1
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>У меня есть функции, реализации которых нужны для разных комбинаций Unicode и ANSI (Unicode/Unicode, ANSI/ANSI, Unicode/ANSI). Строки ANSI используются только в качестве источников (байт дополняется нулевым старшим). Реализации отличаются только используемыми типами. Напрашивается идея оформить их одним шаблоном, но получается затык с "перекрестными" версиями — обычное присваивание из char в wchar_t расширяет знак, а мне нужно расширять нулем.

Это при сборке где char = signed char.
Однако тип char не специфирован со знаком он или нет, посему он может быть и unsigned char.
Например: gcc -funsigned-char myprogram.c

В связи с этим правильным вариантом будет сначала приведением к unsigned char, а только потом к wchar_t для избежания расширения знака.
http://rsdn.nemerleweb.com
http://nemerleweb.com
Re[31]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 15:01
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>файберы — это не настоящая многопоточность, насколько я помню. И проблем многопоточных там не должно быть


ЕМ>Если переключать только так, как принято для них — по явному запросу, в строго определенные моменты, то не должно. Но в те времена таких механизмов или не было вообще, или были совсем примитивные, поэтому переключали как явно в ранних виндах (yield), так и неявно — по асинхронному событию.


Хм. Если в совсем ранних виндах — то там многозадачность только кооперативная была, никто там ничего не переключал, и никаких yield'ов не было. Ну, или я не помню. В более взрослых виндах была нормальная вытесняющая многопоточность, и никаких yield'ов там тоже не было.


ЕМ>Я и под досом как-то делал эмуляцию многопоточки для программы на C, через переключение контекстов по таймерным прерываниям. Такие костыли тогда многие делали для себя.


А это в принципе вполне себе вытесняющая многопоточность. Такой и на контроллерах балуются — FreeRTOS, например, на STMке использовали. Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать, а когда совсем невтерпеж было — использовали stackless корутины на шаблонах. Те же автоматы, но больше похожи на многопоточность
Маньяк Робокряк колесит по городу
Re[2]: Можно ли сделать универсальный шаблон для разных комбинаций whar_t и char
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 15:15
Оценка:
Здравствуйте, _NN_, Вы писали:

_NN>Это при сборке где char = signed char.


У меня char всегда signed.
Re[28]: Можно ли сделать универсальный шаблон для разных комб
От: rudzuk  
Дата: 22.01.23 15:23
Оценка:
Здравствуйте, Marty, Вы писали:

M> Если что, файберы в винду завезли довольно недавно, как бы не в W2K, если не в XP


В Windows 98 для линейки 9x или NT 3.5 SP3 для NT.
avalon/3.0.2
Re[32]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 15:25
Оценка:
Здравствуйте, Marty, Вы писали:

M>Если в совсем ранних виндах — то там многозадачность только кооперативная была


Она была в версиях 1.x, 2.x и 3.x.

M>никто там ничего не переключал, и никаких yield'ов не было.


И чем же там переключали, если не Yield'ом?

M>В более взрослых виндах была нормальная вытесняющая многопоточность


Она появилась в 4.0 (Win95).

M>никаких yield'ов там тоже не было.


Были, просто ничего не делали. В SDK и посейчас есть определение Yield.

M>Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать


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

M>использовали stackless корутины


Которые еще в 60-х назывались "сопрограммами".
Re[31]: Можно ли сделать универсальный шаблон для разных комб
От: rudzuk  
Дата: 22.01.23 15:26
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ> Я и под досом как-то делал эмуляцию многопоточки для программы на C, через переключение контекстов по таймерным прерываниям. Такие костыли тогда многие делали для себя.


Да! Я такое на турбо паскале делал
avalon/3.0.2
Re[29]: Можно ли сделать универсальный шаблон для разных комб
От: rudzuk  
Дата: 22.01.23 15:27
Оценка:
Здравствуйте, rudzuk, Вы писали:

r> M> Если что, файберы в винду завезли довольно недавно, как бы не в W2K, если не в XP


r> В Windows 98 для линейки 9x или NT 3.5 SP3 для NT.


В Windows 98 для линейки 9x или NT 3.51 SP3 для NT.
avalon/3.0.2
Re[33]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 15:37
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>Если в совсем ранних виндах — то там многозадачность только кооперативная была


ЕМ>Она была в версиях 1.x, 2.x и 3.x.


Не совсем понял что ты сказал сейчас. Уточни плс. Кто — она?


M>>никто там ничего не переключал, и никаких yield'ов не было.


ЕМ>И чем же там переключали, если не Yield'ом?


Да никак и не переключали. Просто возвращаешь управление из оконной процедуры, и всё.


ЕМ>Были, просто ничего не делали. В SDK и посейчас есть определение Yield.


Хм, хз, у Рихтера ничего про них не видел


M>>Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать


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


Да нормально. Отдельно делаются подавтоматы, и всё. Например, можно читать в одном потоке из UART'а сколько требуется, разбирать пришедшее, и что-то с этим делать, сообщать основному потоку, например. В основном потоке делать бизнес логику. А можно в одном потоке читать читать сколько прочитается, кидать в автомат разбора протокола, и, не блокируясь на этом, ковылять дальше и обрабатывать бизнес логику в том же потоке. Бизнес логику тоже на подавтоматы можно разбить обычно. И эти части готовыми фрагментами таскать из проекта в проект.


M>>использовали stackless корутины


ЕМ>Которые еще в 60-х назывались "сопрограммами".


Да на здоровье
Маньяк Робокряк колесит по городу
Re[27]: Можно ли сделать универсальный шаблон для разных комб
От: so5team https://stiffstream.com
Дата: 22.01.23 15:41
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

S>>Речь же не о литературе, а о программах. И, поскольку вы сравнивали с FoxPro и Clipper, то речь уже о x86 и MS-DOS (или клоны MS-DOS).


ЕМ>Так я и не говорил, что это хоть как-то относилось к СССР.


Вы говорили о том, что видели сами:

Я хорошо помню, какими уродливыми и тормозными они были еще на стыке 80-х и 90-х. Если какой-то софт был толстым и/или тормозным, и при этом не был написан на каком-нибудь FoxPro или Clipper, он чаще всего был написан на плюсах.


А поскольку вы в конце 80-х были в СССР, то видеть уродство и тормознутость С++ вы могли на том, что в это время было в СССР (не важно, написанное здесь или не здесь). Но на стыке 80-х и 90-х в СССР софта на C++ было микроскопически мало.

Подозреваю, что стыком 80-х и 90-х вы считаете период где-то с 1993-го. Но отнести 1993-й к "стыку 80-х и 90-х" сложновато.

S>>я к тому, что именно на рубеже 80-х и 90-х софта на C++, с которым вы могли бы столкнуться, было совсем совсем мало.


ЕМ>Верно, мало. Первым делом вспоминается Turbo Vision, который был прямо напоказ набит демонстрациями ООП.


У меня почему-то осталось воспоминание о том, что Turbo Vision был написан на Object Pascal, а к C++ там был сделан интерфейс за счет того, что формат объектников у Turbo Pascal и Turbo/Borland C++ от Borland-а был одинаковый. По крайней мере Turbo Vision конца 1980-х.

На C++ был написан OWL от Borland-а. Но это уже под Windows библиотека.

На C++, помнится, в начале 1990-х довелось видеть библиотеку Zinc Interface. Причем вроде как даже какую-то не первую версию, вроде бы Zinc 3.0, т.е. разрабатывать ее начали еще раньше.

S>>Именно многопоточность (а не многопроцессность) вроде бы в середине 1980-х только-только начиналась.


ЕМ>Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница?


Большая. Особенно в конце 1980-х. Многопоточность -- это же параллельность внутри одного адресного пространства. Соответственно, влезть в данные соседнего потока можно просто и незаметно для самого себя. Тогда как в многопроцессности тогдашенего времени обмен данными велся через IPC механизмы (типа пайпов). Вроде как даже shared memory в Unix-ы добавили толи в конце 1980-х, толи в начале 1990-х.
Re[28]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 15:49
Оценка:
Здравствуйте, so5team, Вы писали:

S>У меня почему-то осталось воспоминание о том, что Turbo Vision был написан на Object Pascal, а к C++ там был сделан интерфейс за счет того, что формат объектников у Turbo Pascal и Turbo/Borland C++ от Borland-а был одинаковый. По крайней мере Turbo Vision конца 1980-х.


Всё так. При этом борландовские среды Turbo Pascal и Turbo/Borland C++ были на нем написаны. И они вполне себе летали. Но, наверное, это слишком простые программы


ЕМ>>Я так написал потому, что нынче большинство знает только за многопоточность. А по сути, какая разница?


S>Большая. Особенно в конце 1980-х. Многопоточность -- это же параллельность внутри одного адресного пространства. Соответственно, влезть в данные соседнего потока можно просто и незаметно для самого себя. Тогда как в многопроцессности тогдашенего времени обмен данными велся через IPC механизмы (типа пайпов). Вроде как даже shared memory в Unix-ы добавили толи в конце 1980-х, толи в начале 1990-х.


+100500
Маньяк Робокряк колесит по городу
Re[34]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 16:00
Оценка:
Здравствуйте, Marty, Вы писали:

ЕМ>>Она была в версиях 1.x, 2.x и 3.x.


M>Не совсем понял что ты сказал сейчас. Уточни плс. Кто — она?


Кооперативная многозадачность.

M>Да никак и не переключали. Просто возвращаешь управление из оконной процедуры, и всё.


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

M>у Рихтера ничего про них не видел


Скорее всего, Вам просто не приходилось тогда писать под виндами код, работа которого занимала сколько-нибудь заметное время.

M>>>Только зело неудобно это, однопоточку на автоматах гораздо проще отлаживать


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


M>Отдельно делаются подавтоматы, и всё. Например, можно читать в одном потоке из UART'а сколько требуется, разбирать пришедшее, и что-то с этим делать, сообщать основному потоку, например


Хм, что Вы называете "потоками" в контексте автоматной реализации — ветку обработки состояния? Тогда такая техника работает ровно до тех пор, пока в одной ветке не накопится достаточно кода, чтобы нарушить привязку к реальному времени. Придется добавлять промежуточные состояния, добавлять переменные для хранения контекста. В какой-то момент это становится настолько развесистым, что проще сделать простенький переключатель контекста (хотя бы и кооперативный), и дальше уже писать обработку в естественной последовательности действий. Особенно если это пишется не на ассемблере, на регистрах и глобальных переменных, а хотя бы на C, с локальными переменными на стеке.
Re[35]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 16:20
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>Она была в версиях 1.x, 2.x и 3.x.


M>>Не совсем понял что ты сказал сейчас. Уточни плс. Кто — она?


ЕМ>Кооперативная многозадачность.


Ну да. А я что-то другое сказал?


M>>Да никак и не переключали. Просто возвращаешь управление из оконной процедуры, и всё.


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


Ну хз, может быть. Не доводилось использовать. Да и до сих пор почти всегда обхожусь однопоточностью


M>>у Рихтера ничего про них не видел


ЕМ>Скорее всего, Вам просто не приходилось тогда писать под виндами код, работа которого занимала сколько-нибудь заметное время.


Я про книжку Рихтера, когда он ещё про плюсы писал. Там про многопоток было, чуть ли не полкниги, а вот Yield'а я там не заметил


M>>Отдельно делаются подавтоматы, и всё. Например, можно читать в одном потоке из UART'а сколько требуется, разбирать пришедшее, и что-то с этим делать, сообщать основному потоку, например


ЕМ>Хм, что Вы называете "потоками" в контексте автоматной реализации — ветку обработки состояния? Тогда такая техника работает ровно до тех пор, пока в одной ветке не накопится достаточно кода, чтобы нарушить привязку к реальному времени. Придется добавлять промежуточные состояния, добавлять переменные для хранения контекста. В какой-то момент это становится настолько развесистым, что проще сделать простенький переключатель контекста (хотя бы и кооперативный), и дальше уже писать обработку в естественной последовательности действий. Особенно если это пишется не на ассемблере, на регистрах и глобальных переменных, а хотя бы на C, с локальными переменными на стеке.


Нет, я именно про threads. В FreeRTOS они есть, её и её многопоточность мы использовали, но отказались, стали все на автоматах делать. Ничего развесистым не становится. И риалтайм вполне жесткий. К слову, он редко нужен, этот жесткий риалтайм. Тех микросекунд, за которые прокручивается цикл в единственном потоке — хватало на все. Тут больше проблемы с внешними датчиками SPI/I2C. Во многих STMках есть аппаратные интерфейсы, и они вроде бы делают всю работу, но они подглючивают, и везде по разному. Для каждого камня надо эррату читать. И при переносе кода на другой камешек (почти такой же, только флеша, например, побольше) — легко могло оказаться, что что I2C отвалился. В итоге плюнули, и стали программно с датчиками общаться. В одном потоке. В блокирующем режиме. И 100/400 Кгц частоты I2C вполне хватало для всего. Один только случай могу вспомнить — когда чел делал управление асинхронным вроде мотором, и ему нужно было вот прямо сейчас получать значения тока, да так риалтаймово, что его не устраивали АЦП в обычном режиме, и приходилось делать инжектированный канал — что-то вроде запроса к АЦП отбросить всю текущую работу и побырому оцифрофровать значение определенного канала. И то — там в одном потоке умудрялись без проблем опрашивать CAN/UART'ы на предмет управляющих команд и отправлять ответы
Маньяк Робокряк колесит по городу
Re[28]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 18:21
Оценка:
Здравствуйте, so5team, Вы писали:

S>Но на стыке 80-х и 90-х в СССР софта на C++ было микроскопически мало.


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

S>Подозреваю, что стыком 80-х и 90-х вы считаете период где-то с 1993-го.


Баловаться программированием на C++ наши юниксоиды начали в конце 80-х, я в этом не участвовал. В 90-м, как только вышел TC++ 1.0, народ уже начал писать всерьез. К моменту появления BC++ 3 (91-й) это уже цвело пышным цветом. Но я тогда ограничивался ANSI C.

S>У меня почему-то осталось воспоминание о том, что Turbo Vision был написан на Object Pascal, а к C++ там был сделан интерфейс


Я уже не помню, чего из Pascal и C++ там было больше. Но эффективность обоих тогда была очень близка, особых преимуществ по объему и/или быстродействию не было ни у того, ни у другого. В "процедурном" применении оба были достаточно эффективны, а в варианте "ООП без границ" оба давали одинаково тормозной код, как и сейчас.

S>На C++, помнится, в начале 1990-х довелось видеть библиотеку Zinc Interface.


Наши вроде тоже что-то на ней делали.

S>Вроде как даже shared memory в Unix-ы добавили толи в конце 1980-х, толи в начале 1990-х.


В RSX-11M общая память была с начала 80-х, и там мы много писали под ядро, где почти любой код мог быть в любой момент прерван, и драйвер одновременно мог обслуживать множество запросов от разных процессов. На БЭСМ-6 нас к ядру не пускали, но там как раз мы делали многопоточность вручную в рамках одного процесса.
Re[29]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 18:32
Оценка:
Здравствуйте, Marty, Вы писали:

M>борландовские среды Turbo Pascal и Turbo/Borland C++ были на нем написаны. И они вполне себе летали.


Ну, у кого-то и VS 2019 "летает", хотя на мой взгляд она безбожно тормозит. А так-то даже в Norton Commander, написанном (по крайней мере, поначалу) на чистом C, на 286/16 ощущались задержки по сравнению с Volkov Commander, написанном на ассемблере, но это уже явно не от языка, а от неоптимальности реализации.
Re[36]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 18:48
Оценка:
Здравствуйте, Marty, Вы писали:

ЕМ>>Кооперативная многозадачность.


M>Ну да. А я что-то другое сказал?


Вы сказали, что она была "в совсем ранних виндах". "Совсем ранние" — это версии 1.x-2.x (1985-1988), а версии 3.x (1990-1993) уже применялись достаточно массово.

M>Я про книжку Рихтера, когда он ещё про плюсы писал. Там про многопоток было, чуть ли не полкниги, а вот Yield'а я там не заметил


Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.

M>К слову, он редко нужен, этот жесткий риалтайм. Тех микросекунд, за которые прокручивается цикл в единственном потоке — хватало на все.


Так это и есть жесткий реалтайм, когда железо/софт гарантируют обработку события за один или несколько циклов. На голом железе с этим как раз проще, чем под навороченной многозадачной ОС.
Re[37]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 22.01.23 19:09
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:


ЕМ>Вы сказали, что она была "в совсем ранних виндах". "Совсем ранние" — это версии 1.x-2.x (1985-1988), а версии 3.x (1990-1993) уже применялись достаточно массово.


3.X — тоже вполне ранние


M>>Я про книжку Рихтера, когда он ещё про плюсы писал. Там про многопоток было, чуть ли не полкниги, а вот Yield'а я там не заметил


ЕМ>Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.


Нужды может и не было, но вообще можно было бы упомянуть хотя бы, что ещё есть в винде


M>>К слову, он редко нужен, этот жесткий риалтайм. Тех микросекунд, за которые прокручивается цикл в единственном потоке — хватало на все.


ЕМ>Так это и есть жесткий реалтайм, когда железо/софт гарантируют обработку события за один или несколько циклов. На голом железе с этим как раз проще, чем под навороченной многозадачной ОС.


Автоматный стиль ни там ни там ничего не испортит
Маньяк Робокряк колесит по городу
Re[38]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 22.01.23 22:07
Оценка:
Здравствуйте, Marty, Вы писали:

M>3.X — тоже вполне ранние


Если отсчитывать от Win11, то и XP можно считать "ранней" — уже больше двадцати лет, как-никак.

ЕМ>>Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.


M>Нужды может и не было, но вообще можно было бы упомянуть хотя бы, что ещё есть в винде


Так в Win32 Yield оставлено исключительно ради совместимости по исходникам — в виде пустого макроса, даже в библиотеках его нет.
Re[39]: Можно ли сделать универсальный шаблон для разных комб
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 23.01.23 03:36
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

M>>3.X — тоже вполне ранние


ЕМ>Если отсчитывать от Win11, то и XP можно считать "ранней" — уже больше двадцати лет, как-никак.


ЕМ>>>Если книга была про Win 4.x (95/98/ME), то там и не было нужды в Yield.


M>>Нужды может и не было, но вообще можно было бы упомянуть хотя бы, что ещё есть в винде


ЕМ>Так в Win32 Yield оставлено исключительно ради совместимости по исходникам — в виде пустого макроса, даже в библиотеках его нет.


И охота тебе ещё всё это перетирать? Даже мне это уже надоело. А ты же во хранции, манифик, всё такое
Маньяк Робокряк колесит по городу
Re[29]: Можно ли сделать универсальный шаблон для разных комб
От: so5team https://stiffstream.com
Дата: 23.01.23 05:19
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Повторю: в тех организациях СССР, что предметно занимались вычислительной техникой и программированием, был любой зарубежный софт, который мог представлять интерес. Никаких ограничений по распространению обычного софта тогда не было, поэтому оттуда его раздавали всем желающим.


Т.е. вы лично видели и пробовали все, что попадало в СССР?

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

S>>Подозреваю, что стыком 80-х и 90-х вы считаете период где-то с 1993-го.


ЕМ>Баловаться программированием на C++ наши юниксоиды начали в конце 80-х.


Вот именно, баловаться. А на чем, кстати, баловались? На СМ ЭВМ?

ЕМ>В 90-м, как только вышел TC++ 1.0, народ уже начал писать всерьез. К моменту появления BC++ 3 (91-й) это уже цвело пышным цветом.


Вот как раз после 1991-го о C++ и начали узнавать. И в 1992-1993-ом уже в журналах (типа "Мир ПК" и тому подобных) можно было встретить и упоминания о C++, и сравнения C++ с другими языками. И года с 1993-го уже C++ применялся массово. По крайней мере никто не переспрашивал о том, что такое C++ когда разговор заходил.

ЕМ>На БЭСМ-6 нас к ядру не пускали, но там как раз мы делали многопоточность вручную в рамках одного процесса.


Теперь понятно о чем вы.
Re[40]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 23.01.23 09:21
Оценка:
Здравствуйте, Marty, Вы писали:

M>И охота тебе ещё всё это перетирать? Даже мне это уже надоело.


Если надоело — зачем продолжаете? Или, не имея сил остановиться, ждете этого от меня?
Re[30]: Можно ли сделать универсальный шаблон для разных комб
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 23.01.23 11:04
Оценка:
Здравствуйте, so5team, Вы писали:

S>Т.е. вы лично видели и пробовали все, что попадало в СССР?


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

ЕМ>>Баловаться программированием на C++ наши юниксоиды начали в конце 80-х.


S>А на чем, кстати, баловались? На СМ ЭВМ?


И на них, и на писюках, чуть позже — на SPARC'ах.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.