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

C>>Нет, так как "void" можно возвращать:
PJ>Нет, нельзя. void не является типом. В твоем примере ничего не возвращается. Сделай вот так auto x = foo();
void в С++ является "неполным типом". Т.е. на него можно вернуть указатель, но нельзя вернуть сам тип.

Здравствуйте, Ночной Смотрящий, Вы писали:

S>>>Урок, на котором дети на питоне учатся классифицировать цветы или автомобили по фотографиям, даст им в 100 раз больше, чем целый семестр паскаля с массивами и переменными.
C>>Мне недавно порвало моск, когда я помогал школьнику делать проект для школьной ярмарки.
НС>Ключевой момент — для школьной ярмарки. А теперь представь, что такой проект задали делать каккой нибудь размалеванной девице из гетто.
А для неё будет чуть проще — написать на Питоне распознаватель из уже приготовленных кусочков. Ничего сложного.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Затем что статическая типизация по прежнему остается одной из главных концепций в программировании.
C>>Так мы учим информатику. Зачем практические знания?
НС>Это не практическое знание, это базовая концепция. У асма тоже статическая типизация, хотя практического в его знании в 2021 году совсем немного.
Лямбда-исчисление — тоже базовая концепция. Учить с него начнём?

НС>>>Отличие процедура и функция есть и в С сотоварищи, просто там оно неумело и неполно маскируется одинаковым синтаксисом декларации.
C>>Ну и что?
НС>Ну и все.
В С++ void — это обычный неполный тип, который подчиняется всем правилам для него. Т.е. на него можно вернуть указатель, например.

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

C>void в С++ является "неполным типом". Т.е. на него можно вернуть указатель, но нельзя вернуть сам тип.
В случае указателя ты возвращаешь тип указатель, а не void. На что указывает указатель вопрос уже не существенный, в контексте. void же процедура и есть.

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

C>Уродливость в том, что он невыразим через более примитивные типы.

Тогда в С++/Java/C#/etc все целые и вещественные типы уродливые, потому что они невыразимы через более примитивные типы. А в Аде — выразимы (через диапазоны).

C>Кстати, у него ещё и куча ограничений, в стандартном Паскале нельзя делать множество строк или записей.

Ограничения есть везде. Ты в Ц++ тоже не можешь передать параметром шаблона что угодно.

ARK>>И что? Это почти везде так. В жабе ты тоже не выразишь строку через примитивные типы.
C>В Java строка — это обычный класс: https://docs.oracle.com/javase/7/docs/api/java/lang/String.html Из магического в компиляторе только преобразование литералов в строки.

Можешь свою строку написать, полностью аналогичную стандартной? Пусть без литералов.
Ну, в golang или C# точно не сможешь. И много где еще.

C>>>Нет, так как "void" можно возвращать:
ARK>>Во-первых, если мне не изменяет склероз, возвращать его можно только в ц++. Верни-ка в го или в жабе.
C>В Go нет void, но функции могут возвращать пустой кортеж. Его нельзя вернуть напрямую из-за этого.

Да, про го я забыл. Ну поменяй на C#/Java — там ты его не вернешь.

ARK>>Во-вторых, это ничего не меняет, войд все равно не тип первого класса. У тебя все равно разделение на процедуры и функции и ты не напишешь генерик-обработчик для типа Т, в который сможешь передать void.
C>То есть?

int Function() { ... }

void Procedure() { ... }

T Process<T>(????) { ... }

// Хочу так
int myInt = Process<int>(Function);
void myVoid = Process<void>(Procedure);

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

C>void в С++ является "неполным типом". Т.е. на него можно вернуть указатель, но нельзя вернуть сам тип.

Так, и как же называется функция, возвращающая "неполный тип", и возвращаемое значение которой нельзя никуда не передать, ни сохранить? Дай угадаю — "процедура".

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

НС>>Это не практическое знание, это базовая концепция. У асма тоже статическая типизация, хотя практического в его знании в 2021 году совсем немного.
C>Лямбда-исчисление — тоже базовая концепция.

Да.

C> Учить с него начнём?

Нет.

НС>>Ну и все.
C>В С++ void — это обычный неполный тип

Нет.

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

void* это не void, это аналог указателя на object в других языках.

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

C>А для неё будет чуть проще — написать на Питоне распознаватель из уже приготовленных кусочков.

Или не будет.

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


У>Для какой-нибудь школы — поставить древний BC 3.1 под дос-боксом, и вперёд. Компилит — как ракета, C++ в нём очень на уровне, для учебных целей за глаза хватит.

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

У него, ЕМНИП, не было STL в комплекте. А делать версию для BC 3.1 будет нелегко снова-таки из-за сегментированной памяти.

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


P>При работе очень легко нарваться на сегментированнную память. А все эти near, far, huge давно уже забыты.

P>У него, ЕМНИП, не было STL в комплекте. А делать версию для BC 3.1 будет нелегко снова-таки из-за сегментированной памяти.

Для учебных программ small модели памяти будет достаточно. Ну, или заточится под huge, если нужно прям 640 кил. И ключевые слова near, far, huge будут не нужны, ЕМНИП, указатели по дефолту там вроде под модель памяти заточены. Ну, а даже если и понадобятся, то где-то унутре. В общем, в рамках либы для обучения не вижу проблем сделать что-то STL подобное.

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

А STL-подобные строки для BC3.1 я писал еще студнем, когда толком и язык-то не знал. Не вижу ничего неподъемного

Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Или не будет.
Ну, если настаивать на реализации на Паскале — то точно не будет.

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

P>При работе очень легко нарваться на сегментированнную память. А все эти near, far, huge давно уже забыты.
В BC 3.1 был т.н. "расширитель памяти" позволявший писать под ДОС 32-разрядные программы и не париться всеми этими near, far, huge.

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

У>>По-моему — идеальный вариант. Попробуйте раскритикуйте.
E>никаких cin cout. Для ввода вывода своя библиотека загрузки из файла,

Нах нах еще какие-то свои такие библиотеки


E>а то и из сети нужных данных прямо в коллекции на этапе инициализации. Плюс функции визуализации содержимого коллекций, чтобы было понятно что там происходит внутри.

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


E>Ну нужно нагружать никаким вводом выводом,

Задание. Напишите программу, которая запрашивает ваше имя и возраст, и после ввода имени выводит приветствие "Здравствуй, ИМЯ! До пенсии осталось N лет"

Обычное задание для первых занятий. А ты сюда хочешь подтянуть уже какие-то либы для сериализации. Это тогда еще надо отдельно файл с данными создавать, присовывать его либе, проверять, всё ли нормально прочиталось, и тд, и тп. Кучу гемора на ровном месте развести. Ученики от таких решений разбегутся, там неделю придётся объяснять, что и как происходит, и всё равно дай бох четверть самых умных поймёт. А всего-то нужно было простейшее действие выполнить: N=65-M и вывести результат на экран вместе с именем


E>Вопрос, зачем над детишками издеваться досбоксом? Чтоб не дай боже программирование не полюбили, а то вдруг понравится, соответственно дадим им по больше геморроя с запуском, с установкой, с нестандартными хоткеями.

А в чем издевательство? И в чем гемморой? Там всё элементарно. Это вот студию, а тем паче какой-нибудь эклипс или идею поставить да настроить — вот это квест, да. У меня вот эти ваши мавены/шмавены напрочь отбили охоту поиграться с котлином

И что не так с нестандартными хоткеями? Они и так везде по разному, что в студии, что в эклипсе, что в идее

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

P>В BC 3.1 был т.н. "расширитель памяти" позволявший писать под ДОС 32-разрядные программы и не париться всеми этими near, far, huge.

Ты имеешь в виду DOS Extender? Это я как-то пропустил. С BC 3.1 я мало работал, у нас MSC 6.0 и 7.0 (не Visual) использовался.
Я с расширителем столкнулся, когда переходил на 32-битовый Фортран с 16-битового.

Если сразу можно 32-битовые программы строить на BC 3.1, тогда вопросов нет.

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

P>>При работе очень легко нарваться на сегментированнную память. А все эти near, far, huge давно уже забыты.
P>В BC 3.1 был т.н. "расширитель памяти" позволявший писать под ДОС 32-разрядные программы и не париться всеми этими near, far, huge.

В BC?

Ты не про dos4gw, случайно? Так он не о BC, он про ватком и djgpp. Или что-то другое было?

BC в 32 разряда вроде никогда не умел

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

У>Ты не про dos4gw, случайно? Так он не о BC, он про ватком и djgpp. Или что-то другое было?

Что то другое, борландовский dpmi32

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

У>Ты не про dos4gw, случайно? Так он не о BC, он про ватком и djgpp. Или что-то другое было?
У Борланда свой был.

Здравствуйте, Ночной Смотрящий, Вы писали:

У>>Ты не про dos4gw, случайно? Так он не о BC, он про ватком и djgpp. Или что-то другое было?

НС>Что то другое, борландовский dpmi32

А, припоминаю. Но он вроде начиная с BC 4, не?

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

C>>void в С++ является "неполным типом". Т.е. на него можно вернуть указатель, но нельзя вернуть сам тип.
PJ>В случае указателя ты возвращаешь тип указатель, а не void. На что указывает указатель вопрос уже не существенный, в контексте. void же процедура и есть.

struct Vasja;

Vasja* foo() {
  return nullptr;
}

Это полностью легальный код — мы можем вернуть указатель на неполный тип. void ведёт себя абсолютно аналогично.

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

C>>Уродливость в том, что он невыразим через более примитивные типы.
ARK>Тогда в С++/Java/C#/etc все целые и вещественные типы уродливые, потому что они невыразимы через более примитивные типы. А в Аде — выразимы (через диапазоны).
Иметь фундаментальные типы — это нормально. Ненормально иметь их мешанину.

C>>Кстати, у него ещё и куча ограничений, в стандартном Паскале нельзя делать множество строк или записей.
ARK>Ограничения есть везде. Ты в Ц++ тоже не можешь передать параметром шаблона что угодно.
А что нельзя?

C>>В Java строка — это обычный класс: https://docs.oracle.com/javase/7/docs/api/java/lang/String.html Из магического в компиляторе только преобразование литералов в строки.
ARK>Можешь свою строку написать, полностью аналогичную стандартной? Пусть без литералов.
Да, без проблем. Более того, я это делал (для её представления через memory mapped файлы).

ARK>Ну, в golang или C# точно не сможешь. И много где еще.
В Go нельзя. Но там строка является просто частным случаем массива (с двумя исключениями), а массив мы таки считаем фундаментальным типом.

ARK>>>Во-первых, если мне не изменяет склероз, возвращать его можно только в ц++. Верни-ка в го или в жабе.
C>>В Go нет void, но функции могут возвращать пустой кортеж. Его нельзя вернуть напрямую из-за этого.
ARK>Да, про го я забыл. Ну поменяй на C#/Java — там ты его не вернешь.
Там да.

ARK>>>Во-вторых, это ничего не меняет, войд все равно не тип первого класса. У тебя все равно разделение на процедуры и функции и ты не напишешь генерик-обработчик для типа Т, в который сможешь передать void.
C>>То есть?
ARK>

ARK>// Хочу так
ARK>int myInt = Process<int>(Function);
ARK>void myVoid = Process<void>(Procedure);
ARK>

Ну так держи: https://onlinegdb.com/S1TBh50Md — всё работает.