погрешность в моем случае может быть связана с погрешностью получения данных times-ом
эти данные обновляются с частотой системного таймера
в Linux он установлен в 1мс
вычисляйте сами, если хотите, какая может быть погрешность 

И правда, какая погрешность. Система-то уравнений вообще не решаемая   archimed7592 сбил с толку 


И это B нам не известно.

Нам нужно найти T1/T2. Итак, каковы твои действия?

Добавлено @ 00:58

Так ты ещё и один опыт произвёл  Мегакруть ©

Это сообщение отредактировал(а) UnrealMan - 8.11.2007, 00:59

UnrealMan, 

B нам не нужно!!
T1 / T2 мы заменяем на A1 / A2
при B -> 00, если T1 < T2 ( => A1 < A2), результат неограниченно приближается к 1, но меньше ее
при T1 > T2 ( => A1 > A2) результат приближается к 1, но больше ее
при T1 = T2 ( => A1 = A2) результат 1
на основании одного опыта можно определить соотношение между A1 и A2
и на основании этого сделать вывод о соотношении между T1 и T2
конкретное соотношение не известно в силу неизвестности B, но относительный результат (который нам и нужен) мы получить можем
неужели не понятно?

Добавлено через 1 минуту и 45 секунд
archimed7592, 
вмешайся в спор
кто из нас (я и UnrealMan) тупит

Добавлено через 6 минут и 11 секунд

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

Наверное проще разобраться как реализован RTTI на каком либо конкретном компиляторе, как компилятор производит upcast-ы и тд, и сравнить с велосипедом в виде виртуальной ф-ии, сравнением и тд.

Ну что я могу сказать? Во-первых, конкретное соотношение было бы интересно узнать. Во-вторых, T1-T2 ты можешь найти, не так ли? И сколько там получается? Время в миллисекундах? Ты всерьёз считаешь, что вот эта несчастная строчка кода вычисляется несколько миллисекунд? Что у тебя там за комп такой?

сам считай, если хочешь
все данные я привел

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

Мне этот форум нравится всё больше и больше  Вопросов больше не имею.

т. е сказать больше нечего?   
ради бога

Вопрос в том, кто определил , что он мудрый .  Поэтому, "во-первых" в расчет не принимаем


А что в стандарте где есть фразы, дискриминирующие  dynamic_cast?
Вообщем то исходя из этого, можно например отказаться от ООП вообще. Нафига нам эта приблуда торомозная. Ограничимся только процедурным программированием. 
Мое мнение, что "во-вторых" тоже выглядит неубедительно. 


Дело в том, что если заранее известен класс, то dynamic_cast тут вообще не нужен. Вполне можно обойтись static_cast  .  Так что никакой реорганизации для того, чтобы избавиться от dynamic_cast не понадобится. 



То есть исключения для Вас обязательно что-то исключительное? Пусть так. 
Нут так н делайте преобразование без возможной генерации исключений: ограничтесь преобразованием указателей.


Смысл этой фразы я не понял :(.
 Но в общем могу сказать, но накладываемые Вами ограничения приводят к  печальному результату: при практическом( не демонстрационном  ) использовании полиморфизма придется 
1)либо перенасыщать интерфейс базового класса( применительно  к к данному  примеру вынести GetTime в базовый класс ), 
2)либо создавать свой механизм опознования ( хотябы с использованием typeid, что кстати не всегда удобно или применимо ) с последующим использованием static_cast, 
3) либо просто отказаться от полиморфизма, потому как обычно в реальных  программах  одной работой со  объектами производных классов  как с базовыми  дело не заканчитвается и рано или поздно от работы с базовым объектом приходится переходить к работе с конкретным объектом конкретного класса. 

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



typeid + static_cast == dynamic_cast.

В общем случае это совсем не одно и то же.

В общем то да, но я не часто пользовался typeid и поэтому вопрос: как решить задачу, когда надо преобразовать к не к реальному классу, а к некоемому базовому
A -> B 
   -> C
   -> D ->E
           ->J
          ->H->K
                ->...
 .            
 

Ну и  постановка:  имеется контейнер( дерево),   для  объектов A ( указателей, естественно).  Для всех объектов, которые могут представлены  как объекты класса D выполнить определенную операцию. То есть практически реализовать паттерн Visitor.

В чём разница? 0_о



Для преобразований к базовому касты не нужны вовсе...

Без dynamic_cast нельзя привести указатель от базового класса к потомку при виртуальном наследовании, так как адрес не может быть вычислен во время компиляции, в остальных случаях можно.

можно, тока работать будет неправильно