Тип void в Delphi.

← →
oxffff © (2010-04-13 10:33) [120]

> oxffff © (13.04.10 10:29) [118]

Это к тому что тип void существует в том или ином виде.
Однако действительно объявлять переменные запрещено(поскольку лишено смысла) Но некое выражение может являться в итоге типом void, что не запрещено.

← →
monoid (2010-04-13 11:00) [121]

Дмитрий Белькевич (13.04.10 01:16) [108]

>И, что самое главное, от качества/гибкости языка это никак не зависит.

Ну если бы это было правдой, то писали бы мы сейчас всё на фортране. Однако, почему-то это не так. Не находите противоречий?

>Поддержи в своё время MS и другие Pascal, был бы он, как минимум, там, где сейчас плюсы.

Этого бы никогда не произошло, просто потому, что плюсы являются смелым экспериментом, целью которого было объединить в языке несколько парадигм программирования (структурное, объектно-ориентированное, обобщенное), чего Вирт с его консервативностью никогда бы не сделал (и таки не сделал, если посмотреть на Модулу и Оберон). Именно подобная гибкость обеспечила популярность C++, сделала его стандартом индустрии, с реализациями на множестве платформ (Microsoft конечно же не могла обойти это явление стороной, и ничего удивительного в том, что ее средства разработки для самой распространенной операционной системы так популярны, нет).
Говоря о том, что гибкость не имеет значения, вы просто пытаетесь оправдать негибкость вашего любимого средства разработки, на которое не смотрит никто кроме его производителя и горстки энтузиастов, пытающихся с горем пополам сотворить свободную реализацию.

← →
Anatoly Podgoretsky © (2010-04-13 11:45) [122]

> monoid (13.04.2010 11:00:01) [121]

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

← →
test © (2010-04-13 11:51) [123]

monoid (13.04.10 11:00) [121]
>Этого бы никогда не произошло, просто потому, что плюсы являются смелым
>экспериментом, целью которого было объединить в языке несколько парадигм
>программирования (структурное, объектно-ориентированное, обобщенное), чего Вирт
>с его консервативностью никогда бы не сделал (и таки не сделал, если посмотреть на
>Модулу и Оберон).

Вы таки не поверите Вирт приследовал примерно те же цели, на момент создания Паскаля конкурентами были Алгол, Кобол, Асемблер. Во всяком случае так писал Вирт, думаете врет?

← →
Дмитрий Белькевич (2010-04-13 13:00) [124]

> Ну если бы это было правдой, то писали бы мы сейчас всё
> на фортране. Однако, почему-то это не так. Не находите противоречий?
>

Смотри на Бэйсик. Уж какой убогий язык был...

>которые я решал на дельфи и которые наверное решают в большой части многие - а именно приложения для работы с БД мне и C# хватало за глаза

Ну и зачем перешел на шарп, если это всё и в делфи хорошо было? В чём профит? Кроме вот такого счастья:

http://delphimaster.net/view/15-1271140789/

Через какое-то время MS придумает очередную гениальную парадигму (операционки продавать-то нужно, а принципиально нового (xp vs 7) ничего уже нет), народ начнёт массово все наработки с дотнета переписывать еще на что-то.

Творческий онанизм и генерация энтропии.

>Впрочем в пылу борьбы за чистоту языка и некоторые мастера отказывают в праве на жизнь языку, который позволяет сделать конструкцию типа #deifine TRUE FALSE

По крайней мере, паскаль не даст такое, и то хлебушек:

#define true (Math.random()>0.5)

А сколько еще всего напридумать можно :) С умыслом или без...

>Конструкция : <тип> и есть дополнительное языковое средство, позволяющее различать в Обероне процедуры и функции.

Дополнительное по отношению к чему? К плюсам? Что, в плюсах не существует (не введено) средство, позволяющее различать процедуры от функций? Нет, оно введено. Это void.

>В Паскале несколько похожими свойствами обладает тип Pointer

Поинтер и есть полный аналог void. В смысле нетипизированного указателя. Аналога же "void" в смысле возвращаемого значения нет, за ненадобностью.

> вы просто пытаетесь оправдать негибкость вашего любимого
> средства разработки

Везде свои плюсы и свои минусы:

Defective C++

http://yosefk.com/c++fqa/defective.html

← →
Дмитрий Белькевич (2010-04-13 13:09) [125]

>Конструкция : <тип> и есть дополнительное языковое средство, позволяющее различать в Обероне процедуры и функции.

В обероне же, уже само отсутствие возвращаемого значения подразумевает процедуру. В отличие от плюсов, где нужно явно "void" указывать.
Возвращаемые же значения в функциях описываются и в плюсах и в обероне.

← →
euru © (2010-04-13 17:19) [126]

> Дмитрий Белькевич (13.04.10 13:00) [124]
> Дополнительное по отношению к чему? К плюсам? Что, в плюсах
> не существует (не введено) средство, позволяющее различать
> процедуры от функций? Нет, оно введено. Это void.

В C++ процедуры и функции синтаксически неразличимы. Раличие определяется семантикой типов. В Паскале и Обероне различие между процедурами и функциями вводится на уровне синтакиса языка.

> Поинтер и есть полный аналог void.

Вы неправы. Аналогом Pointer является void*.

> Аналога же "void" в смысле возвращаемого значения нет, за
> ненадобностью.

Естественно, нет. Зачем он нужен, если его можно выразить через синтаксис языка?

> В обероне же, уже само отсутствие возвращаемого значения
> подразумевает процедуру.

Такой вывод неоднозначен, а в историческом контексте, возможно, и неверен.
Сравним описание подпрограмм в двух языках Витра: Обероне и в его предшественнике Алгол-68.

Функции
Алгол-68: proc <имя процедуры> = (<список_параметров>) <тип> :
Оберон: PROCEDURE <имя процедуры>(<список параметров>): <тип>;

Процедуры
Алгол-68: proc <имя процедуры> = (<список_параметров>) void:
Оберон: PROCEDURE <имя процедуры>(<список параметров>);

Как видим, определение функций в обоих языках одинаково, а процедуры различаются только пропуском типа void в Обероне. Так что отсутствие в определении возвращаемого типа может подразумевать и возврат типа void.
Кстати, определение функции в Паскале с формальной точки зрения избыточно. Достаточно было принять соглашение в языке, что при определении подпрограммы как function, первый (или последний) параметр из списка параметров становится возвращающимся.

← →
Игорь Шевченко © (2010-04-13 17:41) [127]

euru © (13.04.10 17:19) [126]

Что еще спер Вирт из Алгола ? :)

← →
euru © (2010-04-13 17:53) [128]

> Игорь Шевченко © (13.04.10 17:41) [127]

Почему сразу "спёр"? Просто взял, что плохо лежит. :)

← →
Игорь Шевченко © (2010-04-13 18:19) [129]

euru © (13.04.10 17:53) [128]

Жена Цезаря вне подозрений ? :)

← →
test © (2010-04-13 18:19) [130]

Игорь Шевченко © (13.04.10 17:41) [127]
Операции +, -, алфавит!

← →
euru © (2010-04-13 18:29) [131]

> Игорь Шевченко © (13.04.10 18:19) [129]
> Жена Цезаря вне подозрений ? :)

А она плохо лежала? :)

← →
Вариант (2010-04-14 07:23) [132]

> Творческий онанизм и генерация энтропии.

Мне не нравится эта фраза.

Поэтому позволю себе некоторую эскападу

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

← →
Дмитрий Белькевич (2010-04-14 12:18) [133]

> В C++ процедуры и функции синтаксически неразличимы.

Интересно, что будет, если попытаться у void функции забрать возвращаемое выражение? Как я себе представляю, она его должна отдать, если ты говоришь, что процедуры/функции синтаксически неразличимы (как я понимаю, синтаксическая неразличимость подразумевает не только синтаксис описания но и синтаксис использования)? И потом с этим void"ом что-то можно сделать? И что отдастся на уровне асма?

> Вы неправы. Аналогом Pointer является void*.

Еще раз.

> Поинтер и есть полный аналог void. В смысле нетипизированного
> указателя.

Здесь что-то неверно?

> Так что отсутствие в определении возвращаемого типа может
> подразумевать и возврат типа void.

Что значит - подразумевает? Процедура наполовину беременна? Значения на выходе процедуры нет. Как на уровне компилятора, так и на уровне ассемблера.

> Ибо первое вызывает сомнение в твоей культуре, а второе
> всего лишь говорит о том, что ты трепло.

Спасибо за обратную связь. Вижу - за живое задевает.

← →
euru © (2010-04-14 17:02) [134]

> Дмитрий Белькевич (14.04.10 12:18) [133]

> Интересно, что будет, если попытаться у void функции забрать
> возвращаемое выражение?
Компилятор во время компиляции выдаст сообщение об ошибке.

> как я понимаю, синтаксическая неразличимость подразумевает
> не только синтаксис описания но и синтаксис использования
Нет. Использование будет зависеть от контекста лексемы (в данном случае от контекста возвращаемого типа).
Вас же не удивляет, что исполнение правила
<переменная> := <значение>;
будет зависеть от типа переменной и типа значения, хотя синтаксис от этих типов не зависит. Так и с функциями: если функция возвращает void, то компилятор будет выдавать сообщение об ошибке при любой попытке получить значение этой функции.

> Еще раз.
> > Поинтер и есть полный аналог void. В смысле нетипизированного
> > указателя.
> Здесь что-то неверно?
Pointer является аналогом void* (void со звёздочкой) - указатель неопределённого типа.
Аналога для void в Паскале нет.

> то значит - подразумевает? Процедура наполовину беременна?
> Значения на выходе процедуры нет. Как на уровне компилятора,
> так и на уровне ассемблера.
Можно по-разному интерпретировать отсутствие у подпрограммы возвращаемого значения:
1. подразумевается, что подпрограмма является процедурой (ваша интерпретация);
2. подразумевается, что подпрограмма возвращает значение типа void (моя интерпретация).
В любом случае компилятор не будет генерировать возврат значений из таких подпрограмм.

← →
oxffff © (2010-04-14 17:10) [135]

> Аналога для void в Паскале нет.

В некотором смысле untyped var и untyped const являются void,
но только неявно ссылкой.

> oxffff © (14.04.10 17:10) [135]
> В некотором смысле untyped var и untyped const являются void,
> но только неявно ссылкой.
В Паскале, насколько я помню, такого безобразия не было. :)

Нет. Это разные спецификаторы.
Теоретически untyped var должен соответствовать void&. Но я не помню, поддерживается ли в С++ такая возможность использования void, а проверить не на чем.

> euru © (15.04.10 12:28) [136]
>
> > oxffff © (14.04.10 17:10) [135]
> > В некотором смысле untyped var и untyped const являются
> void,
> > но только неявно ссылкой.
> В Паскале, насколько я помню, такого безобразия не было.
> :)
>
> Нет. Это разные спецификаторы.
> Теоретически untyped var должен соответствовать void&. Но
> я не помню, поддерживается ли в С++ такая возможность использования
> void, а проверить не на чем.

Это можно в некоторой степени подтвердить от обратного. Например так.

В теории типов, Ref A является подтипом Ref B и наоборот, если А=B.
Два типа совместимы по присваиванию, если Rvalue является подтипом Lvalue.
Поскольку untyped указатель(void*) (var параметр) совместим по присваиванию с typed указателем, т.е. Void* совместим по присваиванию с A*. => что Void=A.
Это в системе типов Delphi. Но это не безопасно.

> oxffff © (15.04.10 12:40) [137]

Из высказывания "если A = B, то ref A = ref B", ещё не следует, что "если ref A = ref B, то A = B" (импликация некоммутативна).

В Дельфи нетипизированный параметр - это всё-таки не само значение, а ссылка на значение, которую ещё нужно будет привести к конкретному типу. В С++ ссылка обозначется символом "&".

> euru © (15.04.10 15:27) [138]
>
> > oxffff © (15.04.10 12:40) [137]
>
> Из высказывания "если A = B, то ref A = ref B", ещё не следует,
> что "если ref A = ref B, то A = B" (импликация некоммутативна).
>

Не следует цепляться за импликацию, следует рассмотреть эквивалентность.

> oxffff © (15.04.10 15:55) [139]
Ладно, эквивалентны так эквивалентны. Не будем углубляться в мат. логику. :)

Зайдём с другой стороны. Возьмём вместо типа void тип char. Рассмотрим следующую процедуру:
procedure P(pc: PChar; c: Char; var rc: Char);
Напишем соответствующую ей функцию на Си:
void P(char* pc, char c, char& rc);
Как видим, var-параметру типа Char в Дельфи соответствует параметр типа char& в Си. Поэтому нетипизированному var-параметру в Дельфи будет соответствовать параметр типа void& в Си.

> euru © (16.04.10 00:55) [140]
>
> > oxffff © (15.04.10 15:55) [139]
> Ладно, эквивалентны так эквивалентны. Не будем углубляться
> в мат. логику. :)
>
> Зайдём с другой стороны. Возьмём вместо типа void тип char.
> Рассмотрим следующую процедуру:
> procedure P(pc: PChar; c: Char; var rc: Char);
> Напишем соответствующую ей функцию на Си:
> void P(char* pc, char c, char& rc);
> Как видим, var-параметру типа Char в Дельфи соответствует
> параметр типа char& в Си. Поэтому нетипизированному var-
> параметру в Дельфи будет соответствовать параметр типа void&
> в Си.

Я честно не понял какую мысль преследуете.
Повторю мое утверждение, что в некотором смысле тип переменой uptyped var соответствет void, с дополнительным требованием, чтобы это было lvalue.
Действительно в С++ - это по смыслу соответствует Void&.

Тип void в Delphi. Найти похожие ветки