Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.236.86.184] |
|
Страницы: (78) « Первая ... 75 76 [77] 78 ( Перейти к последнему сообщению ) |
Сообщ.
#1141
,
|
|
|
Цитата Славян @ Есть ли хоть какой-то шанс (хоть 1%-й), что введут в стандарт тип complex? Для комплексных чисел. std::complex уже давно в стандарте. |
Сообщ.
#1142
,
|
|
|
Имелось ввиду принятие его в язык Си, а не Си++.
|
Сообщ.
#1143
,
|
|
|
Цитата Славян @ Имелось ввиду принятие его в язык Си, а не Си++. Тогда Complex number arithmetic из C99 |
Сообщ.
#1144
,
|
|
|
Что-то почитываю, и что-то не нравятся эти намёки вида:
1. Файл corecrt_math.h struct _complex { double x, y; // real and imaginary parts }; #if _CRT_INTERNAL_NONSTDC_NAMES && !defined __cplusplus // Non-ANSI name for compatibility #define complex _complex #endif #ifndef _C_COMPLEX_T #define _C_COMPLEX_T typedef struct _C_double_complex { double _Val[2]; } _C_double_complex; typedef struct _C_float_complex { float _Val[2]; } _C_float_complex; typedef struct _C_ldouble_complex { long double _Val[2]; } _C_ldouble_complex; #endif typedef _C_double_complex _Dcomplex; typedef _C_float_complex _Fcomplex; typedef _C_ldouble_complex _Lcomplex; //-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // Macros // //-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ #define _DCOMPLEX_(re, im) _Cbuild(re, im) #define _FCOMPLEX_(re, im) _FCbuild(re, im) #define _LCOMPLEX_(re, im) _LCbuild(re, im) #define _Complex_I _FCbuild(0.0F, 1.0F) #define I _Complex_I Стандарт, - это когда можно будет написать такой код: complex kvadrat( complex z) { return z*z; } // далее - что угодно #include <math.h> #include <complex.h> int main() { complex z=5; return abs(kvadrat(z)); // ну или cabs, или ещё нечто такое } Добавлено Пардон, так: return (int)abs(kvadrat(z)); // ну или cabs, или ещё нечто такое |
Сообщ.
#1145
,
|
|
|
Ну, сочувствую. Это C, тут это нормально. В язык complex не введут, для встроек это крайне нерентабельно. А вот в библиотеки ввести можно, т.к. соответствующий заголовок для freestanding можно объявить необязательным. Собственно так и сделали.
Не подходит, тогда тебе в Плюсы или в Фортран. |
Сообщ.
#1146
,
|
|
|
Пардон, вопрос конечно не про то, что тема ведёт, но всё же:
Какой покрохотнее компилятор посоветуете? - дабы скомпилил под Винду нечто такое: #include <stdio.h> #include <math.h> int main() { for( int i=0; i<180; i+=10) printf("sin(%d)=%f", i, sin(i*M_PI/180); return 0; } |
Сообщ.
#1147
,
|
|
|
Цитата Славян @ Какой покрохотнее компилятор посоветуете? - дабы скомпилил под Винду нечто такое: Попробуй lcc-win |
Сообщ.
#1148
,
|
|
|
Попробовал. Печально. А именно:
1. Само распаковалось на 123 МБ. Мне думается, что это сильно много, ибо BorlandC где-то под 30 МБ раньше выходил и делал весьма много. 2. Просто открыть файл (с примером выше) и откомпилить не удалось - ей проект надо делать и всё такое. Минус. 3. При сохранении проекта, закрытии его и нажатии "открыть" прога упала. Резюме: сильно попытались заморочиться, им надо было бы как-то попроще быть... В идеале бы: TurboC x64 (кой у меня 1,3 МБ). |
Сообщ.
#1149
,
|
|
|
Цитата Славян @ 1. Само распаковалось на 123 МБ. Мне думается, что это сильно много, ибо BorlandC где-то под 30 МБ раньше выходил и делал весьма много. Ну сравнил хрен с пальцем Посмотри внимательно содержимое распакованного, там только каталог с заголовками весит 30 метров. Проект живой, под современные вёнды, потому и весит столько. Цитата Славян @ Просто открыть файл (с примером выше) и откомпилить не удалось - ей проект надо делать и всё такое. Минус. Минус тебе Можно было бы не делать поспешных выводов, а почитать документацию! Правда юзергайд надо искать на сайте. Единственное смущает, что его сделали с инсталлятором. Тем не менее, можно компилячить и линковать без использования IDE от этого проекта, чисто его утилитами командной строки. Цитата Славян @ При сохранении проекта, закрытии его и нажатии "открыть" прога упала. Без комментариев У меня такое не получалось. Хотя, скажу честно, я не часто эту софтину пользую. Цитата Славян @ Резюме: сильно попытались заморочиться, им надо было бы как-то попроще быть... Еще раз посоветую внимательнее разобраться. Но, как говорят, если нет ... на нет и суда нет. Это не моя софтина |
Сообщ.
#1150
,
|
|
|
В Си есть=допустима такая конструкция:
s = A ? p : q; Тут как-то захотелось, чтобы она была расширяема до такого: {s1,s2} = A ? {p1,p2} : {q1,q2}; Ну или даже до 3...n значений. Эх... |
Сообщ.
#1151
,
|
|
|
Ну попробуй так:
#include <iostream> #include <tuple> #include <utility> template <typename ...Args> class Multi { std::tuple<Args...> left; public: explicit Multi(Args&& ...list): left(std::tuple<Args...>(list...)){} template <typename ...Params> Multi& operator=(const Multi<Params...>& right) { auto generator = [counter = 0]()mutable { return counter++; }; auto assigner = [](int idx, auto& l, const auto& r) { std::get<idx>(l) = std::get<idx>(r); }; (assigner(generator(), left, right.left), ...); return *this; } }; template <typename ...Args> auto multi(Args&& ...args) { return Multi<Args...>(std::forward<Args>(args)...); } void check(bool b) { int p1 = 123, p2 = 321, q1 = 456, q2 = 654; int s1 = 789, s2 = 987; multi(s1, s2) = b ? multi(p1, p2) : multi(q1, q2); // аналог того, чего хотел std::cout << s1 << '\t' << s2 << std::endl; } int main() { check(true); check(false); } |
Сообщ.
#1152
,
|
|
|
Славян, в стандарте С++17 было введено "структурное связывание" (Structured binding declaration). Поэтому твой код можно записать вот так:
#include <iostream> #include <tuple> int main() { int p1 = 3, p2 = 4, q1 = 5, q2 = 5; bool b = true; auto [s1, s2] = b ? std::make_tuple(p1, p2) : std::make_tuple(q1, q2); // если s1 и s2 объявлены ранее, то вместо auto [s1, s2] используем std::tie(s1, s2) std::cout << "s1: " << s1 << std::endl; std::cout << "s2: " << s2 << std::endl; return 0; } Важно чтобы количество элементов в кортежах было одинаковое. |
Сообщ.
#1153
,
|
|
|
Я сперва тоже так хотел, но увы, структурное связывание может использоваться только при определении для инициализации. Тут же речь об обычном присваивании, т.е. однажды определив, те же сущности должно быть можно изменять присваиванием, а не определять новые. std::tie формально решает, однако он не допускает или делает крайне неудобными ситуации, когда типы данных слева и справа от = не совпадают и нуждаются в кастах. Тут легко можно запутаться, т.к. = в std::tie имеет несколько иную семантику, нежели в обычном =. У меня = сохраняет семантику, и новых сюрпризов не вносит. Но не буду спорить, что в целом этот более простой вариант имеет право быть.
Добавлено Впрочем, что у тебя, что у меня варианты грешат "лишними" буквами. Конечно с простыми {} было бы поприятнее. Подождём C++26, там на метаклассах, возможно, получится поэлегантнее. |
Сообщ.
#1154
,
|
|
|
Qraizer, зацени как элегантно это (ну почти это) обыграно в ЯП Dart:
myList = [1, 2, 3, 4]; final [b, _, c, _] = myList; print('b: $b, c: $c'); // b: 1, c: 3 var myList = [1, 2, 3, 4, 5, 6, 7]; final [a, ..., b] = myList; print('a: $a, b: $b'); // a: 1, b: 7 Это примеры только по деструктуризации списков. Для деструктуризации записей, хэшей и классов - там тоже очень красиво А если перевести именно мой кусок с С++ на Dart, то это будет выглядеть так: void main() { int p1 = 3, p2 = 4, q1 = 5, q2 = 5; bool b = true; var (s1, s2) = b ? (p1, p2) : (q1, q2); print("s1: $s1"); print("s2: $s2"); } |
Сообщ.
#1155
,
|
|
|
Вообще, желаемая Славяном конструкция сама по себе довольно сомнительна. Ведь ?:, как и любое выражение, имеет результат, у которого вполне определённый тип. Даже для стандартного ?: там довольно неочевидно, что да как, и эти ?: в C и C++ отличаются из-за наличия ссылок в последнем. Например, можно написать
(cond ? a : b) = expr; *(cond ? &a : &b) = expr; Я так думаю, предложение в Комитет о расширении синтаксиса ?: было, но из-за озвученных проблем, ведущих, как я в раннем в посту уже обращал внимание, к сюрпризам его отклонили, ибо вероятности программеру наглючить слишком велики. Я вот как-то даже теряюсь в том, чтобы просчитать всякоразные нюансы с выбором типа ?: и даже поведения. А что, если типы в кортеже разные? А что, если типы элементов кортежей посередине и справа не все совпадают? А вдруг там вперемежку значения и разного рода ссылки? Обычные, правосторонние, константные... Как при всём этом выполнять касты с учётом правил приоритетности от identical до ellipsis? |