Вот почему:
например есть функция

function funcstr(string s):integer;
Есть две переменные:

ii:integer;
ff:float;


Их надо конвертировать в число затем передать функции funcstr.
на delphi
придется писать


funcstr(IntToStr(ii));
funcstr(FloatToStr(ff));
Если охота форматирования есть другие функции;


на С же:

char str[??] // ?? обычно 100 — привычное "наверное хватит" со времен С

itoa(ii,str,10);
funcstr(str);

int decimal, sign;
char *buffer;
buffer = _ecvt(ff, 10, &decimal, &sign );
strcpy(str,buffer);
funcstr(str);





Или обратное преобразование:

StrToInt
StrToFloat
В случае ошибки кинут исключение EConvertError


в С
atoi
strtod

в С++
еще хуже

в знакомых мне библиотеках: MFC,STL..
во ВСЕХ классах со строками нет таких преобразований!
в MFC CSting есть функция с неопрделенныч числом параметров format -зачем делать разбор строки формата и неявные преобразования т.к ф-я с неопределенным числом параметров?

Решение половинчатое и преобразование только в дну сторону.Допустим CString->double как???

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


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

Здравствуйте, Аноним, Вы писали:

А>Вот почему:
А>например есть функция

А>function funcstr(string s):integer;
А>Есть две переменные:

А>ii:integer;
А>ff:float;


А>Их надо конвертировать в число затем передать функции funcstr.
А>на delphi
А>придется писать


А>funcstr(IntToStr(ii));
А>funcstr(FloatToStr(ff));
А>Если охота форматирования есть другие функции;



Там можно написать funcstr(1) или funcstr(ii) — правда лапочка?
А есть еще такие экзотические удовольствия как — SmartTalk — но это для изысканный цинителей......

Здравствуйте, <Аноним>, Вы писали:

А>Вот почему:
А>например есть функция

А>function funcstr(string s):integer;
А>Есть две переменные:

А>ii:integer;
А>ff:float;


А>Их надо конвертировать в число затем передать функции funcstr.

А>funcstr(IntToStr(ii));
А>funcstr(FloatToStr(ff));

Ты попробуй VB, там с этим еще проще

А вот, например, Perl:

#Входная сторка
$_ = "1 22 333 4444 55555 666666";
#Разбираем
if (/^(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)\s+(\d+)$/) {
  #Собираем строчку с другими разделителями, и печатаем.
  print "$1, $2, $3, $4, $5, $6\n";
} else {
  print "Обломс однака. ;-в\n";
}

Здравствуйте, Аноним, Вы писали:

А>Вот почему:
А>например есть функция

А>function funcstr(string s):integer;
А>Есть две переменные:

А>ii:integer;
А>ff:float;


А>Их надо конвертировать в число затем передать функции funcstr.

sprintf (str, "%d", ii);
funcstr (str);

sprintf (str, "%f", ff);
funcstr (str);

А вообще, насколько корректно сравнивать Delphi и стандартный C? Может, надо с C++?

Здравствуйте, Аноним

Друг мой, если Вы не знакомы с Cи, то нечего показывать Ваше невежество, к тому же в такой мелкой форме!


А>Вот почему:
А>например есть функция

А>function funcstr(string s):integer;
А>Есть две переменные:

А>ii:integer;
А>ff:float;


А>Их надо конвертировать в число затем передать функции funcstr.
А>на delphi
А>придется писать


А>funcstr(IntToStr(ii));
А>funcstr(FloatToStr(ff));
А>Если охота форматирования есть другие функции;
Подумайте на досуге, откуда берется строка, возвращаемая XxxToStr(), и куда она потом девается.
Если поймете, то Вам сразу многое станет ясно...
(Подсказка: строка — это буфер в куче)


А>на С же:

А>char str[??] // ?? обычно 100 — привычное "наверное хватит" со времен С
пора бы знать, что максимальное значение типа int — 4294967295. Простой подсчет показывает, что
размер массива — 10 байт + 1 на знак + 1 на /0
максимальное float — 3.402823466e+38F. Посчитаете сами

А>itoa(ii,str,10);
А>funcstr(str);

А> int decimal, sign;
А> char *buffer;
А> buffer = _ecvt(ff, 10, &decimal, &sign );
А> strcpy(str,buffer);
А> funcstr(str);

Почти верно, уточню лишь, что _ecvt возвращает немного не то что вы хотели увидеть.
Вот результат работы вашего примера, взятый из MSDN:
source: 3.1415926535 buffer: '3141592654' decimal: 1 sign: 0
Если не боитесь разрушить состояние эйфории, в котором вы сейчас прибываете,
то взгляните на функцию _gcvt()




А>Или обратное преобразование:

А>StrToInt
А>StrToFloat
А>В случае ошибки кинут исключение EConvertError


А>в С
А>atoi
А>strtod

А>в С++
А>еще хуже

Вот уж не знал, что в C++ нельзя использовать atoi и strtod!

А>в знакомых мне библиотеках: MFC,STL..
А>во ВСЕХ классах со строками нет таких преобразований!
А>в MFC CSting есть функция с неопрделенныч числом параметров format -зачем делать разбор строки формата и неявные преобразования т.к ф-я с неопределенным числом параметров?
Даже обсуждать не буду.

А>Решение половинчатое и преобразование только в дну сторону.Допустим CString->double как???

А>Решения основанные на потоках хоть переносимые но медленные.
А>С какой стати надо использовать поток если я хочу всего навсего преобразовать строку в число?
Вот с этим я согласен.

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

Y>Здравствуйте, Аноним, Вы писали:

[...]
А>>funcstr(IntToStr(ii));
А>>funcstr(FloatToStr(ff));
А>>Если охота форматирования есть другие функции;



Y>Там можно написать funcstr(1) или funcstr(ii) — правда лапочка?
Y>А есть еще такие экзотические удовольствия как — SmartTalk — но это для изысканный цинителей......

Не знаю почему ты его упомянул в таком простом случае, но на нем действительно все тривиально:

10 printString
'10.0' asNumber

У меня относительно Delphi очень давно есть намного более веселый вопрос.
Как создать коллекцию double-ов/float-ов?
Есс-но требуются операции добавления, удаления, поиска и т.д. После такого вопроса на лица дельфистов очень весело смотреть.

Об удобстве использования языка можно судить по базовым конструкциям и стандартной библиотеке классов.
Например, как можно на Delphi (или любом другом языке), проделать следующее:

1) Посчитать сумму последовательности чисел от 1 до 100 с заданным шагом n.

2) Дана некоторая коллекция/массив чисел collection. Нужно в результате получить коллекцию/массив того же типа, но только с элементами исходной коллекции, большими нуля.

Время на каждое задание — три минуты.

--

Владимир.

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

_>У меня относительно Delphi очень давно есть намного более веселый вопрос.
_>Как создать коллекцию double-ов/float-ов?


Так же как на С++

_>Есс-но требуются операции добавления, удаления, поиска и т.д. После такого вопроса на лица дельфистов очень весело смотреть.

_>Об удобстве использования языка можно судить по базовым конструкциям и стандартной библиотеке классов.
_>Например, как можно на Delphi (или любом другом языке), проделать следующее:

_>1) Посчитать сумму последовательности чисел от 1 до 100 с заданным шагом n.

Так же как на С++

_>2) Дана некоторая коллекция/массив чисел collection. Нужно в результате получить коллекцию/массив того же типа, но только с элементами исходной коллекции, большими нуля.

Так же как на С++

_>Время на каждое задание — три минуты.


Код писать желания нет.

Но хоть убей не вижу как при правильном программировани на данных примерах можно увидет разницу между С++ и ObjectPascal (или его там опять в Delphi переименовали?). Чего такого нет в ObjectPascal что критично в этих примерах?



P.S. Полуофф. В последние время правильным программированием я все больше считаю код — который удобно и легко читать, а также просто портировать..... Жизнь знаете говорит о том что различные опитимизации, сокращение и прочее — просто экономические не выгодно.

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

_>>Об удобстве использования языка можно судить по базовым конструкциям и стандартной библиотеке классов.


Если считать STL как как часть С++, а не отделной библиотекой — то можно и не продолжать.....

Здравствуйте, Аноним, Вы писали:
Не надо развивать языковые войны. С# Delphi.Net все стало одного поля ягода.

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

S>Здравствуйте, Аноним, Вы писали:
S>Не надо развивать языковые войны. С# Delphi.Net все стало одного поля ягода.


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

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

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

_>>У меня относительно Delphi очень давно есть намного более веселый вопрос.
_>>Как создать коллекцию double-ов/float-ов?


Y>Так же как на С++

Ну конечно

std::vector<double> v;
v.push_back(10.0);

_>>Есс-но требуются операции добавления, удаления, поиска и т.д. После такого вопроса на лица дельфистов очень весело смотреть.

_>>Об удобстве использования языка можно судить по базовым конструкциям и стандартной библиотеке классов.
_>>Например, как можно на Delphi (или любом другом языке), проделать следующее:

_>>1) Посчитать сумму последовательности чисел от 1 до 100 с заданным шагом n.

Y>Так же как на С++

Не спорю. Значит длинно и плохо читается.

_>>2) Дана некоторая коллекция/массив чисел collection. Нужно в результате получить коллекцию/массив того же типа, но только с элементами исходной коллекции, большими нуля.

Y>Так же как на С++

Нет, значительно хуже.

_>>Время на каждое задание — три минуты.


Y>Код писать желания нет.

Я знаю, потому что нет желания перенапрягаться.

Y>Но хоть убей не вижу как при правильном программировани на данных примерах можно увидет разницу между С++ и ObjectPascal (или его там опять в Delphi переименовали?). Чего такого нет в ObjectPascal что критично в этих примерах?

Я не считаю C++ приемлемым языком. А тем более Object Pascal, который как язык ниже любых планок (VCL и Delphi IDE это другой вопрос).

Я предпочитаю язык, в котором указанные задачи решаются следующим образом:

(1 to: 100 by: n) inject: 0 into: [:sum :e | sum + e]

collection select: [:each | each > 0]

Y>P.S. Полуофф. В последние время правильным программированием я все больше считаю код — который удобно и легко читать, а также просто портировать..... Жизнь знаете говорит о том что различные опитимизации, сокращение и прочее — просто экономические не выгодно.

Вот-вот, именно.

--

Владимир.

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

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

_>>>Об удобстве использования языка можно судить по базовым конструкциям и стандартной библиотеке классов.

Y>Если считать STL как как часть С++, а не отделной библиотекой — то можно и не продолжать.....

Считать. Хоть STL слаб, но даже его хватает, чтобы оставить Object Pascal с его библиотеками позади.

--

Владимир.

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

_>_>

_>std::vector<double> v;
_>v.push_back(10.0);
_>

Во во этот типизированный вектор, делается за 2 минуты простым набором текста в любом языке. А огромное количество программистов даже незнают его сущности. И почти все алгоритмы используемые постоянно от 10 20 строках исходного текста.
Зачем развивать языковые войны. Не надоело?????

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

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

_>_>>

_>>std::vector<double> v;
_>>v.push_back(10.0);
_>>

S> Во во этот типизированный вектор, делается за 2 минуты простым набором текста в любом языке. А огромное количество программистов даже незнают его сущности. И почти все алгоритмы используемые постоянно от 10 20 строках исходного текста.

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

S> Зачем развивать языковые войны. Не надоело?????

Я в них научавствовался. Поэтому говорю, что C++ и OP оба ужасны. Выучите один хороший функциональный язык и один хороший объектный, тогда Delphi vs C++ vs C# закончатся сами собой.

--

Владимир.

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

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

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

_>>>>Об удобстве использования языка можно судить по базовым конструкциям и стандартной библиотеке классов.

Y>>Если считать STL как как часть С++, а не отделной библиотекой — то можно и не продолжать.....

_>Считать. Хоть STL слаб, но даже его хватает, чтобы оставить Object Pascal с его библиотеками позади.

Угу, а VCL по своей идеи заткнет за пояс MFC.... Ну и что?


STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки....

Я предпочту видеть собственный класс вектор и класс коллекцию, и не вижу чем это хуже (а критерий объективный мне известен один — экономический) чем шаблоны.....

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

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

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

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

_>>>>>Об удобстве использования языка можно судить по базовым конструкциям и стандартной библиотеке классов.

Y>>>Если считать STL как как часть С++, а не отделной библиотекой — то можно и не продолжать.....

_>>Считать. Хоть STL слаб, но даже его хватает, чтобы оставить Object Pascal с его библиотеками позади.

Y>Угу, а VCL по своей идеи заткнет за пояс MFC.... Ну и что?


Y>STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки....

Y>Я предпочту видеть собственный класс вектор и класс коллекцию, и не вижу чем это хуже (а критерий объективный мне известен один — экономический) чем шаблоны.....

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

--

Владимир.

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


Y>STL это зло! Вершее шаблоны это зло... Потому как во первых шаблоные есть даже не для всех платформ (читай компиляторов) C/C++, не говоря уже о проблеме портирования на другие языки....
Интересно, и почем же это зло? Шаблоны есть в последнем стандарте языка. MS и Borland их реализует, так, что же еще надо? С портировании на другие языки — проблема, но те приимущества, которые они дают в C++, все с лихвой перекрывают. Если кто-то скажет, что никаких преимуществ нет, тот никогда не использовал шаблоны! (если не считать каких-нибудь халявных курсовиков в институте). Насчет раздуывания кода при использовании шаблонов, то вы не задумывались, сколько кода генерируется в языках позволяющих реализовывать сложные алгоритмы одной строчкой?

Y>Я предпочту видеть собственный класс вектор и класс коллекцию, и не вижу чем это хуже (а критерий объективный мне известен один — экономический) чем шаблоны.....
Что значит собственный класс-вектор или класс-коллекция? Не заметил чтобы программеры утруждали себя созданием таких вещей, используют стандартные и не задумываются! А среди них шаблоны — сомое лучшее и безопасное решение.

Здравствуйте, _vovin, Вы писали:
_>Я в них научавствовался. Поэтому говорю, что C++ и OP оба ужасны. Выучите один хороший функциональный язык и один хороший объектный, тогда Delphi vs C++ vs C# закончатся сами собой.

И что же жто за сверх языки? Попытался поискать их среди предложений на рынке труда, что-то обычно C++ да прибомбасы к нему попадаются...

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

_>Я предпочитаю язык, в котором указанные задачи решаются следующим образом:
_>

_>(1 to: 100 by: n) inject: 0 into: [:sum :e | sum + e]
_>

_>

_>collection select: [:each | each > 0]
_>

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