LINUX.ORG.RU

Посоветуйте безщупальцевую STL С++

 


1

7

Существуют ли в природе библиотки-обёртки над STL, ограничивающиеся заголовочниками и предоставляющие в целом те же возможности что и стандартная библиотека С++, вероятно, с небольшими плюшками, и обладающие той же продуманностью?

Но! При этом, с интерфейсом, предназначенным для рук землян, а не щупалец инопланетных монстров?

Т.е. без подобного маразма, когда прочитать объект типа std::string из std::filestream (сэкономили 3 буквы, молодцы!) std::fstream можно только через статическую функцию, но не член класса std::fstream.

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

★★★★★

Есть POCO, но я ее не использовал и почти с нею не знаком

dave ★★★★★
()

Т.е. без подобного маразма, когда прочитать объект типа std::string из std::filestream можно только через статическую функцию, но не член класса std::fstream.

Реализация operator>> для классов должна быть именно в читаемом классе. Это работает примерно как тайпкласс Read в хаскеле. А как ты собрался засовывать эту реализацию в методы fstream?

Зато с сахарком, вроде того, чтобы можно было складывать вектора друг с другом

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

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

http://php.net/

Crocodoom ★★★★★
()

Может быть просто не стоит использовать уже этот цепепе? :-) Чего давиться этим кактусом всё время то? :-)

anonymous
()
Ответ на: комментарий от xaizek

(дек += вектор) == дек; (вектор += дек) == вектор

next_time ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

ей по возможностям до STL как до Луны пешком, они даже результат size() как тип size_t не осилили

next_time ★★★★★
() автор топика
Ответ на: комментарий от Crocodoom

Реализация operator>>

вообще делает не то, что нужно

зато есть std::getline, но она статическая

только +=, чтобы не выделять лишнюю память под результат суммы

ну и ладненько

это всё нифига не сахарок.

сахарок: std:: всё это умеет, но не через операторы, а итераторы

next_time ★★★★★
() автор топика
Последнее исправление: next_time (всего исправлений: 1)

Но! При этом, с интерфейсом, предназначенным для рук землян, а не щупалец инопланетных монстров?

Там почти вся кривизна вызвана отсутствием GC, вопросом производительности, натуральными ограничениями интерфейсов алгоритмов.

Так что лучше потратить время на изучение принципов костыльности STL.

dzidzitop ★★
()
Ответ на: комментарий от next_time

сахарок: std:: всё это умеет, но не через операторы, а итераторы

Повторю - изучи принципы «костыльности» STL. Ерунду пока что несёшь. Каким образом итераторы относятся к «сложению» контейнеров - совершенно непонятно.

dzidzitop ★★
()

Ты примерно хочешь получить сварочный аппарат на 250А, но чтобы непременно можно было использовать воспитанникам детского сада, и без ограничения функциональности и без маски сварщика.

dzidzitop ★★
()
Последнее исправление: dzidzitop (всего исправлений: 1)

бесщупальцевую - щ глухое )

anonymous
()

Напиши свои.

В Doom3 BFG есть самые необходимые контейнеры с неплохой производительностью. Никак не дойдут руки оторвать их движка.

a1batross ★★★★★
()
Ответ на: комментарий от dzidzitop
vec.insert(vec.end(), deq.begin(), deq.end())

Человек говорит о синтаксическом сахаре для подобной операции. Что тут непонятного?

anonymous
()

Напиши своё, можно в рамках boost например.

pon4ik ★★★★★
()
Ответ на: комментарий от dzidzitop

Как будто невозможно создать такой сварочный аппарат. Закрыл пламя в прозрачный (обыкновенное стекло, например, прозрачно для в. света, но непрозрачно для УФ) кожух и вперёд.

next_time ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Я не знаю что там в стандартной библиотеке.

В моем понимании std вообще должна быть минимальной, особенно для родственника Си. Вместо этого она уже начинает чрезмерно толстеть. Скоро догонит питон.

a1batross ★★★★★
()
Ответ на: комментарий от a1batross

std раста догонит питон? Вы обоих в глаза не видели? std раста содержит от силы 20% того, что есть в питоне из коробки.

Идея раста в том, что бы на оборот выпиливать всё из std. Благо cargo позволяет.

Ну и минимальность понятие растяжимое. Кому нужен очередной libc, содержащий десяток бесполезных функций?

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Ты читать умеешь? Я НЕ знаю что там в расте. Меня вообще не волнует его существование как языка, так как я не видел какого-то проекта на нем.

a1batross ★★★★★
()
Ответ на: комментарий от next_time

зато есть std::getline, но она статическая

Как что-то плохое.

anonymous
()
Ответ на: комментарий от kawaii_neko

Поведение std::max не норм.

Хэши не норм.

anonymous
()
Ответ на: комментарий от next_time

альтернатив-то нет

Лол :-) Даже PHP и то лучше :-) В цепепе такая продуманная типобезопасность, что (сюрприз) можно даже строке присваивать целое число :-) Вот, полюбуйся:

#include <cstdio>
#include <iostream>
#include <string>

int main()
{
  std::string s{"Cepepe is the most ugly language ever :-) Even uglier that PHP :-) Lol :-)"};
  std::cout << s << std::endl;

  s = int(67); // Even PHP is better :-) Lol :-)
  printf("%s is better anyway :-) Lol :-)", s.c_str());
}

$ ./stupid_cepepe
Cepepe is the most ugly language ever :-) Even uglier that PHP :-) Lol :-)
C is better anyway :-) Lol :-)

Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

Знакового недостаточно

было на 16-битных системах.

anonymous
()

С++
с интерфейсом, предназначенным для рук землян, а не щупалец инопланетных монстров

Только если такое не считать за щупальца. Хотя это про emacs вообще-то, но в тему.

peregrine ★★★★★
()
Ответ на: комментарий от anonymous

Ибо std::is_integral_v<char>() == true а у стринга есть оператор присваивания для value_type. Вот напиши ты там ересь типа s = 777; (чтоб в char не приводилось просто так)...

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

Вот напиши ты там ересь типа s = 777; (чтоб в char не приводилось просто так)..

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

anonymous
()

STL писал русский наркоман, нанюхавшись страусиной травы. бери .NET Framework и не парься...

anonymous
()
Ответ на: комментарий от KennyMinigun

Ибо std::is_integral_v<char>() == true а у стринга есть оператор присваивания для value_type.

Ну я же и говорю об этом :-) Это же такая продуманная типобезопаснтость в стиле цепепе :-) Лол :-)

Вот напиши ты там ересь типа s = 777;

Да пожалуйста, усатый, держи ересь:

#include <string>

int eres()
{
  return 777;
}

int main()
{
  std::string s{"Still ugly :-) Lol :-)"};
  s = eres(); // Lol :-)
}
Компилится без варнингов :-) Но цепепе по-прежнему нет альтернатив :-) Лол :-)

anonymous
()
Ответ на: комментарий от anonymous

Впрочем это очевидное поведение, видно смайлодаун уже не знает к чему придраться.

Наверное, это очевидно только для фанбоев, которые предпочитают не замечать любые недоразумения их любимого язычка, кроме которого они ничего другого толком не знают и знать не хотят :-) Поэтому им и очевидно :-) Лол :-)

anonymous
()
Ответ на: комментарий от next_time

ну да, можно инициализировать строку символом, как и должно быть

Это глупая семантика :-) Это всё равно, что разрешать присваивать массиву символов целое, чтобы превратить массив символов в символ :-) Строка - это строка (массив символов), а символ - это символ :-) И если уж разрешать (что неправильно) такие выкрутасы как operator=(T), куда более логичнее организовать конвертацию T в строковое представление :-) Т.е. после s = 777 в строке должно быть «777», а не какая-то глупость как строка из одного символа с кодом 777 :-) Но тебе вряд ли это будет понятно, у тебя же альтернатив цепепе нет :-) Лол :-)

anonymous
()
Ответ на: комментарий от RazrFalcon

строки, локали

по задумке они лучше, чем кутешные, но хромает именно интерфейс

варинт

сомнительной нужности штука

фс

вот её не хватает, да

next_time ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Т.е. после s = 777 в строке должно быть «777», а не какая-то глупость как строка из одного символа с кодом 777 :-)

Да, так оно было бы приятнее, поэтому я открыл сию тему. Кстати, пронаследоваться от string и переопределить = с поведением согласно вашему предложению - пара пустяков.

next_time ★★★★★
() автор топика
Ответ на: комментарий от next_time

Кстати, пронаследоваться от string и переопределить = с поведением согласно вашему предложению - пара пустяков.

Нельзя наследоваться открыто. Ни в коем случае нельзя. Потому что в таком случае меняется семантика operator= (который не виртуальный) в унаследованном классе. Т.е. вот такая вот фигня получится:

void foo(MyString& s)
{
  s = 777; // "777"
  std::string& sref = s;
  sref = 777; // oops
}
:-) basic_string расширяется только с помощью специализации char_traits и никак иначе :-)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.