» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

vez
В этой справке бесит, как найти заголовочные файлы.
Необходимо лазать по инету искать, что добавить в include

Цитата:

Необходимо лазать по инету искать, что добавить в include

Я поступаю проще, иду в include/... и поиском totalcmd (Alt-F7) ищу нужную функцию

Цитата:

Я поступаю проще, иду в include/...  и поиском totalcmd (Alt-F7) ищу нужную функцию

Ты не одинок, но хотелось бы сразу вместе.

А может кто-нить знает, есть ли on-line компилятор прод C++ Builder
искал не нашел

Народ! Думаем мигрировать с Delphi 2010 на XE7.
Парочка вопросов:
1 - Как быть с тем что имена юнитов изменились (у нас пара сотен pas файлов только в библиотеках, и куча проектов с dfm)
2 - Можно ли накатывать XE7 без FMX и других обвесов? Разработка только под Windows
3 - Сама IDE стабильней чем 2010?

tanaseduard
1. Надо будет в проекты добавить unit scope names для используемых vcl/rtl юнитов и всё.
2. Можно.
3. Намного стабильнее.

Eternal_Shield
Спасибо.
Есть предложения какую лучше накатывать из семейства XE?

Цитата:

Есть предложения какую лучше накатывать из семейства XE?

Сами только с 2010.
Пробовали XE3 - не прижилась, среда валилась.
Сейчас параллельно 2010 и XE7 - около месяца, которая с Update1.
пока вроде ничего.

Цитата:

Есть предложения какую лучше накатывать из семейства XE?

Не знаю какие у вас потребности, но, думаю, Pro хватит. В большинстве случаев хватает.

Eternal_Shield
Спасибо, но я имел ввиду версию XE (XE1.XE2-XE7). Кто то говорить что XE6 самая стабильная, другие XE7. Вот и пытаюсь узнать у тех кто юзал.

Mic777
Спасибо.
Обе делфи нормально уживаются на одном тазике?

Цитата:

Обе делфи нормально уживаются на одном тазике?

Да, нормально.
Последние девы прекрасно под них встали.

Mic777
Оооо. Это радует. Спасибо.

Кто-нибудь может объяснить, почему:

Код: var
Val: Extended;
begin
Val := 1.0950000000000000001;
SetRoundMode(TRoundingMode.rmDown);
Val := RoundTo(Val, -2);

Цитата:

Вроде 1,95 должно быть.

что за пурга?

максимум ответ должен быть 1.09, но никак не 1.95

Добавлено:
для объективности, на C# тоже ответ 1,1

Код:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Double a = 1.0950000000000000001;
Console.WriteLine("before = " + a);
Console.WriteLine("after = " + Math.Round(a, 2, MidpointRounding.ToEven));
Console.ReadLine();
}
}
}

Может быть кто-нибудь делал серилизацию записей, классов в буфер, используя RTTI информацию.
Есть
TRecord = record
i : integer;
s : string;
k : double;
end;
На выходе:
Начала буфера: i, offset на s, k, длина s, s (строка).
Может уже есть готовые классы?

ZloyBrawler
>> что за пурга?
Ошибся просто в посте. Конечно же 1,09 ожидал получить.
Ну вот почему он так считает, мне не понятно.
Ему же четко сказано, округлять вниз, какой 1,1...

Если применять это округление к деньгам, ерунда получается.
Приходится использовать свою функцию округления.
Очевидно что 1,0950000000000000001 рублей, это скорее 1 рубль и 9 копеек (при правиле округления вниз).

SolidSnakeRU

Цитата:

Кто-нибудь может объяснить, почему:

Попытаюсь на основании Help-а самой дельфы:
1. RoundTo НЕ использует флаг, устанавливаемый SetRoundMode(TRoundingMode.rmDown);
он используется для функции Round
В хелпе по Round есть упоминание о SetRoundMode, но ни слова о нем же в описании RoundTo

2. RoundTo использует метод "банковского" округления -
Банковское округление (англ. banker's rounding) — округление для этого случая происходит к ближайшему чётному, то есть 2,5 = 2, 3,5 = 4.

ну и опять же в самом хелпе они приводят пример:
RoundTo(1.235, -2) 1.24
RoundTo(1.245, -2) 1.25

как раз Ваш случай.

ну и позволю себе ссылочку в тему:
__http://www.delphikingdom.com/asp/viewitem.asp?catalogID=1217

SolidSnakeRU
Округляет он верно, т. к. тип double - это вещественное число с плавающей точкой. Для него есть специальный стандарт округления.
Этот тип не подходит к деньгам. Для этого нужно писать свой тип типа decimal, т. к. в Net - decimal - вещественное число с фиксированной точкой. Поэтому там другие правила округления.
В делфи отсутствует реализация типа decimal, поэтому либо самому писать или использовать сторонние классы, либо использовать реализацию microsoft (либо есть соответствующие функции).
В Delphi есть что-то подобное и называется этот класс TBcd. Но там основные операции сделаны через строки - в общем медленно.

SuPriTo
Не соглашусь с формулировкой, что для какого-то типа данных вот есть прям СТАНДАРТ округления. Скорее есть разные подходы к решению проблемы округления. А проблемы есть не только у Delphi.
Что касается TBCD - отношение к нему неоднозначное. Работали с ним, скорость не меряли, т.к. была не важна, но соглашусь, что т.к. все на строках не комильфо если считать надо много и быстро. К тому же и в реализации самого класса были ошибки, некоторые из которых решались только в следующих версиях Delphi или приходилось править ручками.

Да и в самом начале FMTBcd.pas есть определение константы
_DefaultDecimals = 10
может кому-то и не хватить.

Что касается самого округления для нашей задачи аналитики откопали такую формулу
(копипаст прям из ТЗ)
"Округление округляет значение первого операнда до числа знаков после запятой, указанного вторым операндом. Если второй операнд не целое число, то используется ближайшее целое. Результат операции округления определяется формулой:
[X*10[Y+0,5] +0,5]/10[Y+0,5], где
X – первый операнд;
Y – второй операнд;
[a] – целая часть числа a"

т.е. такой вот SimpleRoundTo

но работает неплохо наши задачи решает.

P.S. Да забыл сказать что именно с BCD-шными типами ее и реализовывали, как там с Extended будет не знаю, пробуйте.

Mic777
Вот IEEE 754-2008
Что нужно знать про арифметику с плавающей запятой
В Делфи нет проблем с округлением. Есть проблемы с восприятием результатов этого округления.
Если нужна реализация денежного типа - то это тип Decimal.
Я тоже решал свои задачи по округлению через TBCD.

SuPriTo
Ну стандарт скорее определяет способы работы с числами с плавающей запятой, в том числе способы округления, которых может быть несколько, какие-то являются обязательными, но это ведь не означает что для типа Extended только скажем RoundTo надо использовать.

Но соглашусь, что не корректно выразился, что это проблема Delphi (сейчас не владею вопросом, но раньше проблемы были:
"Итак, согласно документации, SimpleRoundTo реализует арифметическое округление, а RoundTo — банковское. Но на самом деле они вытворяют такие чудеса...")
- это скорее проблема использования тех или иных функций округления для каждой конкретной задачи.

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

Цитата:

2. RoundTo использует метод "банковского" округления -
Банковское округление (англ. banker's rounding) — округление для этого случая происходит к ближайшему чётному, то есть 2,5 = 2, 3,5 = 4.

ну и опять же в самом хелпе они приводят пример:
RoundTo(1.235, -2) 1.24
RoundTo(1.245, -2) 1.25

В делфи XE6, обе строки возвращают 1.24.
Зато:
SimpleRoundTo(1.235, -2) 1.24
SimpleRoundTo(1.245, -2) 1.25

Короче с округлениями вывод такой.
В мире напридумывали много вариаций округления.
Но в делфи реализовали 2:
SimpleRoundTo - не понял на что похоже.
RoundTo - похоже на банковское

SuPriTo

Цитата:

В делфи отсутствует реализация типа decimal, поэтому либо самому писать или использовать сторонние классы, либо использовать реализацию microsoft (либо есть соответствующие функции).

В дельфях есть тип Currency.

Имхо
для ХРАНЕНИЯ денежных типов вы можете использовать и Currency и Extended, но это вас не спасет от известных проблем при ВЫЧИСЛЕНИЯХ / ОКРУГЛЕНИЯХ.
Тем более, как выяснилось:

Цитата:

Только в делфи XE6, обе строки возвращают 1.24.

среда ведет себя по разному от версии к версии (ну не блюдут они стандарты )
оффтоп: март месяц, а смайл все в колпаке , наверное еще и елку не выбросил

Mic777
Читаем справку:

Цитата:

Currency is a fixed-point data type that minimizes rounding errors in monetary calculations. It is stored as a scaled 64-bit integer with the four least significant digits implicitly representing decimal places. When mixed with other real types in assignments and expressions, Currency values are automatically divided or multiplied by 10000

kaz_av
и что?
10 / 3 - вам хватит four least significant digits
???

а еще ведь надо не только 4 цифры после знака хранить - бухгалтеру что сотые доли копеек нужны, нет
и потому как правильно заметил
SuPriTo

Цитата:

Есть проблемы с восприятием результатов этого округления.

то бишь отображения в отчете к примеру, где волей не волей опять ентое округление.
и что, как помог вам тут Curreny ?

потому повторюсь
для ХРАНЕНИЯ денежных типов вы можете использовать и Currency и Extended, но это вас не спасет от известных проблем при ВЫЧИСЛЕНИЯХ / ОКРУГЛЕНИЯХ.
Этот вопрос ЗА рамками и способ решения уже зависит от задачи.

Mic777
Для денег вполне.

kaz_av

Цитата:

Для денег вполне.

Для денег этого мало - т. к. сейчас уже минимум необходимо 5 знаков после запятой, а иногда даже еще больше. Так что Currency - это такой отживший тип в Delphi, его пора уже давно менять.

kaz_av
ну как вполне, давайте выдайте трем сотрудникам 10 рублей поровну

Иванов 3,33
Петров 3,33
Сидоров 3,33
ИТОГО (ему как всегда больше всех) 9,99

а копеечку куда заныкали ???
где ваш Currency?


Цитата:

Этот вопрос ЗА рамками и способ решения уже зависит от задачи.

Mic777

Цитата:

Но вот не пойму как тип Decimal может помочь в решении задачи из приведенной мной ссылки

Тип Decimal - с фиксированной точкой, там нет чудес с округлением.

Цитата:

для ХРАНЕНИЯ денежных типов вы можете использовать и Currency и Extended, но это вас не спасет от известных проблем при ВЫЧИСЛЕНИЯХ / ОКРУГЛЕНИЯХ.

Extended - тип с плавающей запятой - есть чудеса (но они и должны быть)
Currency - тип с фиксированной запятой - чудес нет, но и у него маленькая дробная часть. Поэтому этот тип спасет от известных проблем при вычисления / округлениях. Но из-за маленькой дробной части его нельзя использовать в реальных проектах.

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

Из вашей же ссылки про арифметику
"Для многих широко распространенных математических формул математики разработали специальную форму, которая позволяет значительно уменьшить погрешность при округлении. Например, расчет формулы «x2-y2» лучше вычислять используя формулу «(x-y)(x+y)»."

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