Выбор языка

Расширяемый язык - это про что-нибудь типа Лиспа. В современном C++ ещё и короутины есть, чтобы ты распутался из callback'ов.

А линковщик прибит по большей части к объектным файлам, они в свою очередь прибиты к ОС и являются недоделанными исполняемыми файлами, т.е. выхлопом компилятора в некотором промежуточном варианте который ещё не готов работать на железе но уже является некоторым бинарным кодом. На практике при возможности все хотят чтоб было можно использовать библиотеки из чужих ЯП, кроме тех ЯП которые имеют свой формат исполняемого файла, выполняемый на виртуальной машине (Java, C#). Но даже эти ЯП хотят использовать нативные библиотеки, правда обратный процесс ипользования кода на этих ЯП в других ЯП уже очень и очень труден и требует огромных костылей, хотя и возможен через некоторые очень специфичные механизмы (вроде COM технологии в Windows или даже REST api и гонять данные от сервера к клиенту на локальном сервере).

а сами библиотеки получается на C, потому что файлы заголовков *.h, а не *.hpp

не факт, надо код читать, всякие извращенцы есть.

Не твоё это, раз на форуме спрашиваешь. Развивай автономность.

Предлагаю перекатиться в прошлый такой же тред, там всего-то страниц 20 было

Да вообще не понимаю этих тем про выбор языка. Если ты работаешь в существующем проекте, то уже всё выбрано обычно. Если для себя, то непонятно, зачем нужны чьи-то ещё мнения. Это же не какое-то решение на всю жизнь.

Эти вопросы задают в основном люди, которые рассматривают ковыряние языка как инвестицию, а не делают это просто потому что интересно стало, или руки зачесались

Как-то не очень похоже в большинстве случаев.

Мне бы хотелось поначалу прикладное программирование освоить на чём-нибудь попроще, но чтобы это был не «учебный язык», а вполне себе рабочий

Любой, который используется в индустрии. На СНГ не смотри, смотри на штаты.

Сейчас языки индустрии, кажется, берут какие могут фичи у своих конкурентов и разница между языками постепенно размывается.

Хочется сказать, что Python и Ruby кажутся проще, но я больше склоняюсь к тому, что во всех современных языках индустрии всё одно и то же, кроме синтаксиса и деталей реализации.

Особняком стоит Go: в нём преднамеренно нет очень многого, что есть в других языках индустрии. И не ожидается.

чтобы он тоже был расширяемый

В любом языке есть возможность использовать сторонние библиотеки.

Только там сложнее себе по ногам стрелять, он более четкий и не даёт творить дичь.

Я на МакОС лишним FreeRect на паскале ОС убил (да, я ещё дважды нажал «продолжить» на сообщение об ошибке).

С++ - самый расширяемый язык, потому как статические библиотеки стороних API (*.a и *.lib) пишутся в первую очередь для него

Для C они пишутся, у C++ нет стабильного ABI. Библиотеки на C можно использовать почти из любого языка (с разной степенью удобства).

Но C++ - слишком сложный, лично у меня ступор вызывают callback-функции и указательные типы.

Это база и она есть в любом языке, к сложности C++ ты даже близко не подобрался. Если у тебя такие сложности, выбором языка их не решить, любой язык сложный с той точки зрения что придётся включать голову.

https://github.com/tsoding/good_training_language

С такими вопросами тебе нужно обращаться к NeoX. Он за один тред стал просветлённым и всё разложил по красоте!

I knew he’s Russian. Пару раз видел на ютубе, но только сейчас увидел, что он знает русский.

Java может быть или в ней так же сложно?

Учитывая, что

лично у меня ступор вызывают callback-функции и указательные типы.

То будет сложно.

Кажется из полезного и адекватного остается пхп.

На СНГ не смотри, смотри на штаты.

Посмотрел в профиль, а там какой-то американец. Что вам неймется-то там?

Что касается темы. Автор, посмотри на котлин. Такая упрощенная scala, чтобы легко зашла для джава-программистов.

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

Колбеки писать там просто. Лямбды на уровне синтаксиса симпатичные.

+1.

Или C#, на крайняк. Вполне себе рабочий язык.

а Java - медленная

есть задачи на джаве которые работают со скоростью 0,5 от си-шной. это точно не «медленная».

Tcl\Tk . Потом Java.

Можно принять как шутку.

Выбирайте Python или JavaScript, и пишите на нём всё, что захотите. Потом этот язык вы, скорее всего, будете недолюбливать, но это будет потом.

Не слушайте тех, кто советует начинать с C++, теории вычислений, lambda calculus, SICP, O’Caml и т.д. Вам надо полюбить находить и решать проблемы, писать софт для себя. Теория нужна потом.

Basic, Pascal, Fortran

Первым ЯП для всех изучающих должен быть C (не С++)

С - достаточно простой ЯП, при этом дающий полное понимание того, что происходит «под капотом» у компиляторов и интерпретаторов. А когда понимаешь, что происходит «под капотом», то потом уж без разницы какой язык будет следующим - все будет зависеть от рынка или желания. С можно изучить с нуля до приемлемого уровня за 1-2 месяца (а то и быстрее).

С++ - сложный язык. Его можно учить, а можно и не учить после С.

Если после С будет интересно железо - то можно изучить какой-либо Assembler

Если после С будет интересно что-то быстро, модно, молодежно, на коленке и даже с ИИ - то Python

Если после С будет интересно что-то через браузер - то JavaSctipt вкупе с HTML/CSS

Если предпочитаешь работу в банках, то Java.

Если предпочитаешь работу в телекомах или где микросервисы - то Go

и т.д.

Какой JavaScript, если ТС колбэки не понимает? Да и объекты по ссылке передаются.

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

Я паскаль последний раз видел в 2000 году под DOS на уроке информатики, а что там в Delphi и других современных вариациях паскаля, я не знаю. Но по идее если мы программируем на языке ВЫСОКОГО уровня, то нас все эти ассемблерные подробности должны интересовать разве что для того чтобы эрудицией блеснуть. Мы пишем «передать переменную в процедуру», а компилятор сам должен додумывать как это в машинный код переводить.

Но паскаль из всех обзоров современных языков был выброшен, в том числе в этом треде.

Я паскаль последний раз видел в 2000 году под DOS на уроке информатики, а что там в Delphi и других современных вариациях паскаля, я не знаю

При чём тут дельфи? Повторю ещё раз - в Паскале есть указатели. Были и в 2000-м и в 1990-м. И передача переменной по ссылке есть и всегда была.

Но по идее если мы программируем на языке ВЫСОКОГО уровня, то нас все эти ассемблерные подробности должны интересовать разве что для того чтобы эрудицией блеснуть

Не путай язык высокого уровня и скриптоту. Это в скриптоте (пхп питон шеллы) указателей нет (но даже там местами есть ссылки). В нормальных языках высокого уровня указатели есть и используются для дела. Для «блеснуть эрудицией» никто языки не разрабатывает, всё для работы только.

Паскале есть указатели. Были и в 2000-м и в 1990-м.

И в книге Вирта 1970 какого-то года указатели были. Там даже не ASCII, а символы «стрелка вверх» и «стрелка вниз».

Но C++ - слишком сложный, лично у меня ступор вызывают callback-функции и указательные типы.

если указатели и стрелочки с квадратиками жгутики и проводочки метапроговые вызывают у тебя ступор в С++ – начинай с паскаля.

синтаксис проще некуда. если человек утверждает что не может осилить паскаль/яву/питон/бейсик/1с из-за синтаксиса – он тупо профнепригоден.

потому что синтаксис не самое сложное и не самое главное. семантика всему голова.

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

с языка паскаль. с наглядной и понятной книжки про алгоритмы и структуры данных.

вот этой, например olddos.ru:

• Доналд Алкок. Язык Паскаль в иллюстрациях.

в браузере: djvu.online

было бы здорово если бы, например, подобную книжку по Rust-у нарисовали. разноцветными фломастерами: чтобы показать лайфтаймы и семантику владения/одалживания, например, тот же borrow checker или мутабельность и иммутабельные алгоритмы. или например, семантику копирования/перемещения в С++ и lock-free алгоритмы – и как их типичные случаи Rust позволяет упростить и автоматизировать.

тогда можно было бы советовать тебе раст.

а пока – нет. его можно изучать если уже примерно понимаешь С++ и хаскель или лучше ML, Ocaml, например.

а вообще на тему

Мне бы хотелось поначалу прикладное программирование освоить на чём-нибудь попроще,

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

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

опять же, вопрос в том куда двигаться после изучения всего этого. и как найти на этом работу. это уже третьи книжки и про позиционирование и общение надо читать. например, Роб Мартин «чистый код» – книжка «Профессиональный программист».

Что выбрать для изучения, Java может быть или в ней так же сложно?

грубо говоря, Java = (C++)–. C# = ++(C++)– , D = (C++)++.

чем C# круче C++? чем четыре креста круче чем два!! лол.

в общем, да, там где – —- чуть проще. где ++ – чуть сложнее (но не намного).

а вполне себе рабочий, чтобы он тоже был расширяемый

тогда нужно уточнить, в каком смысле тебе нужен «расширяемый».

например, парадигмы программирования и мультипарадигменность. или ооп или компонентное ПО = объекты минус наследование. или готовые батарейки и инфраструктура как в какой-нибудь скриптухе. или синтаксическая расширяемость и макросы лиспа, например.

слишком сложный С++

проблема не столько в том, что он сложный. а в том, что эта сложность – структурирована по-дурацки.

например, на английском есть complexity сложность и sophisticated сложность. первая – это громоздкая сложность реализации (чем поливали, то и выросло, в духе: дизайн и эволюция С++ – никакого дизайна, зато все пошло в эволюцию словно сорняк какой-то). вторая – это продуманность архитектуры, которой пользоваться должно быть легко.

в этом смысле – в С++ дохрена ненужной избыточной сложности

There is only two things wrong with C++ – the initial concept and the implementation.

это не я сказал – а Бертран Мейер, автор языка Eiffel и книжек «Почувствуй класс с Эйфель», «Объектно-ориентированное конструирование программ».

вот он про нужную расширяемость в правильном смысле – динамической системной корректности и проектирования по контракту (Design By Contract, DbC).

и конструирования расширяемых систем из подобных компонентов.

вот там понятно, что такое «расширяемое ПО».

в BlackBox Component Pascal, A2/Active Oberon, Zonnon.NET – тоже понятно. что такое компонентное ПО и открытая, расширяемая система.

а что ты вкладываешь в смысл «расширяемости» – пока не понятно.

Начинай с Go. Потом докинешь либо JavaScript (и TypeScript), либо Python. А потом сам поймёшь, куда дальше.

Чтобы передать некий объект в качестве параметра функции, нужно при вызове функции передать ей указатель на этот объект.

вот это «нужно» уже навязано С/С++ пониманием. можно передавать объект по ссылке или по значению. в более других языках есть например ключевое слово IN которое показывает что это – входной параметр, значит, он передается по ссылке, и более того, изменять внутри функции его нельзя.

в с++ как и в С – всего этого нет. поэтому «указатель на объект»,«ссылка на объект», &foo – это костыль особенностей С или С++ (еще например в ANSI/K&R ссылок нет, только указатели – так что ты сам должен понять где передавать по ссылке – и взять &адрес , например, в sscanf – а где по значению, и понимать что работаешь с копией переданного значения, соответственно если его внутри функции пытаться менять – изменишь копию).

ничего страШного если из книжки Доналда Алкока жгутики и проводочки наглядно себе представляешь.

но довольно странно, да. потому что язык С недалеко ушел от ассемблера, а С++ – от обычного plain C, не объектного.

Вот например есть строки как и в любом языке

нет там строк, ни в С, ни в С++ – тебя обманули. даже массивов многомерных и нормальных векторов – их тоже нет.

есть просто адресная арифметика которая автомаГически делает из a[i][j][k] = &a[0][0][0]+i*sI+j*sJ+k*sK или например a[i] = &a[0]+i*sAi=i[a]. где sX – sizeof соответствующей длины элементов.

а настоящих массивов над ними нет – в plain C. типа настоящих матриц и векторов, как в том же фортране или паскале.

в С++ их – сюрприз, тоже нет. только есть всякие разные обёртки над C одномерными массивами.

по этой самой причине, строк в C и в С++ — тоже нет.

вот в D например, есть строки. в Go есть строки. потому что есть слайсы массивов и автоматическая функция длины. а в С/С++ строк нет – просто обёртки над DB(???) в ассемблере.

по этой же самой причине различные типы классов-обёрток в С++ изобретают неоднократно: в каком-нибудь std:: затем в Qt или еще где.

ах, да. потом еще кодировки строк. то есть – нормальная интеграция со встроенным типом строк должна поддерживать например, кодировки и/или уникодность.

int sqlite3_exec(sqlite3*, const char sql, int (callback)(void,int,char*,char**), void *, char **errmsg); где 3-й параметр - callback-функция, обрабатывающая результат SQL-запроса, допустим мне нужно, чтобы результат выводился в переменную, ну и всё - тупик.

просто в С++ как и в С нужно расшифровывать справа налево а не слева направо.

то есть, вот есть например паскаль. он в этом смысле логичный: сначала VAR потом имя переменной, потом тип. тип массив и тип скалярный это две большие разницы.

в С/С++ всего этого нет. поэтому нужно строить в голове жгутики и проводочки – где там ссылка, где значение, где что к чему применяется. и раскручивать изнутри это дерево – или справа налево.

например:

int sqlite3_exec(sqlite3*, const char *sql, int (*callback)(void*,int,char**,char**), void *, char **errmsg);

идем справа налево, изнутри наружу:

1. sqlite3_exec – имя функции с 5 параметрами
2. int – возвращаемое значение этой функции
   1-> 1.1. sqlite3 – указатель на значение типа sqlite3
   1.2. sql – указатель на константную строку (попробуй понять чем от константного указателя на строку отличается)
   1.3. третий параметр – коллбек
   1.4. четвертый параметр – указатель на значение любого типа
   1.5. указатель на указатель на байты char – то есть, двумерный массив байтов, то есть, одномерный массив строк (помним, что массивов по сути нет? и строк тоже?), как char **argv в main

1.3 ->

1.3.0.1 callback – указатель на функцию с 4 параметрами,
1.3.0.2 int – возвращаемое значение этой функции

1.3.1. void* – первый ее параметр – указатель на любое значение
1.3.2. int – второй: целое
1.3.3. char** — третий – одномерный массив строк
1.3.4. char** — четвертый – одномерный массив строк

в общем, теперь раскручиваем изнутри наружу и справа налево.

и в конце получаем тип возвращаемого значения.

все логично, простой синтаксис, же ну???

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

ах, да. этот const по сути примочка и припарка – типа IN только для чтения в параметрах передаваемых по значению. потому что в двух разных тредах например могут быть разные прототипы. то есть, не обладает «транзитивностью константности» – зачем в языке D придумали immutable который усиленный const.

в общем, приколы нашего городка. некоторые из которых тянутся еще из BCPL.

и всех все устаивает, логично же, ну!!!

There is only two thins wrong in C++ – the initial concept and the implementation

1. The initial concept – язык, синтаксически совместимый с С и его костылями и нелогичностями, bug-to-bug compatible еще с изначальным BCPL. это путь в никуда, изначально гнилая концепция.

2. The implementation — нуачо, мы вам template или объектных обёрток поверх накрутим всего этого.

тоже пустая и довольно бессодержательная концепция.

протекающие абстракции типа иммутабельности в многопоточности, отсутствия настоящей модульности, гарантий и инвариантов, пред/после-условий и т.п.

чтобы понять что можно и по другому – изучи сначала паскаль, модулу, оберон-2, аду.

ну или был вот такой язык: язык программирования Xerion Д. Гаев

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

потом изучи limbo, go. и опять же – здоровые элементы паскалевского синтаксиса которые на логичность повлияли.

или сразу учи Go – он в этом смысле логичный как и Limbo.

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

примерно как в книжке Доналда Алкока – только разноцветными фломастерами.

нарисуй например, какой-нибудь COM под Win32 на plain C и BSTR строки, кто там кому выделяет кому освобождает и как проконтролировать жизненный цикл объектов.

потом если все понятно – задание тебе со звёздочкой.

нарисуй move/copy семантику и какой-нибудь lock-free алгоритм в С++03,2012,2016,2020.

если все еще всё понятно – задание с двумя звёздочками.

тоже самое, только на Rust и жизненный цикл объектов, и семантику владения/одалживания, и иммутабельность и изменяемость, и функциональные структуры данных и lock-free алгоритмы, и borrow checker и лайфтаймы и вот это вот все.

читай про соглашения о вызовах и ABI и «Stable ABI is nonsense.cpp»

опять очень логично и справедливо устроено, же ну???

всё чтобы ты разные конпеляторы С++ друг с другом не смешивал. поэтому ABI в С++ нестабильный (хотя в plain C таки да – cdecl)

а теперь задумайся в этом контексте – а может она и нафиг не нужна – синтаксическая совместимость объектного С с необъектным, в этом контексте?

вот в языке Ada например. продумали #pragma(Import,C,....) – и даже сделали ключик который такие прототипы автоматически генерирует.

так зачем тогда высокоуровнему языку типа Ада или там С++ — быть совместимым с низкоуровневым plain C именно синтаксически ???

А вот с callback-функциями вообще не понятно как их писать и как вообще прийти к их пониманию

легко: через сопрограммы,корутины и продолжения.

коллбеки – совсем на них не похожи и самое простое из этих трех.

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

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

2. возвращаемся из функции не в адрес на вершине стека а еще куда, например, в последний передаваемый адрес, указатель – значит вся конструкция в целом это продолжение, или корутина.

две корутины делают друг другу одна пинг а другая понг – возвращаясь в точку не откуда вызывали исходную а в явно переданный последним параметром адрес.

пинг-понг корутины вместе реализуют кооперативную многозадачность, когда первая делает yield а вторая размораживает вычисления после этого yield.

3. это можно представить продолжением – как замороженные тентакли ктулху жгутики и проводочки потоки вычислений.

то есть: корутины можно реализовать через продолжения.

а продолжения – реализовать через замыкания.

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

тогда возможность заморозить и разморозить вычисления – это то, что делает замыкание. а возможность использовать это для передачи управления туда куда нужно (а не туда, откуда это вызывалось) – это продолжение.

а корутины – это кооперативная через добровольный yield многозадачность через продолжения.

замыкания в свою очередь просто записать через лямбда-функции, или анонимные функции – для которых имя не важно, только прототип.

ну вот – видишь, ты теперь и с замыканиями/продолжениями/корутинами разобрался.

все логично и просто устроено, же ну???

если нет – нарисуй cdecl и ABI стеки caller/callee и то как они друг другу по кругу пинг-понг делают и что они там через yield передают и кто кого замораживает и размораживает.

в тетрадке в клеточку с переменными ящичками – ручечкой и фломастерами. изображая жгутики и проводочки, ога.

Я не раз эту фразу от матёрых программистов слышал, что «язык это лишь инструмент».

всё верно. опытный мастер может топором и бриться, и избу срубить, и гвозди забивать, и пшеницу косить, и землю копать.

Ну то есть опытный программист может быть волен в выборе инструмента?

нет, все надо делать только топором на С/С++. другие инструменты просто не нужны – ведь у тебя есть отличный золотой топор молоток для всего, же ну.

у него там статическое выделение памяти в массивах и такой аллокатор за O(1) типа арены, ну да.

а вот потом что на си в TeXlive (или еще лучше: TinyTeX) что на расте в каком там новомодном тех на расте от этого избавляются.

вообще, лучше бы не на расте а например на той же аде переписали – ближе к истокам. да и изначальная реализация есть в виде патчей под fpc и gpc, без CWEB.

кстати. нарисовать жгутики и проводочки для его структур данных из TeX:The Book and the program водя пальцем по индексам и гиперссылкам блоков кода – тоже может быть интересным занятием.

с двумя, нет, лучше – с тремя звёздочками.

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

потому что строк у тебя нет в С и в С++.

присваивая одно другому – ты присваиваешь одному указателю содержимое другого указателя.

присваивая содержимое – например, в цикле перебирая одномерный массив – ты копируешь содержимое.

ах,да. массивов у тебя тоже нет. а содержимое массивов, можешь считать их «одномерный массив» = поток байт в памяти – есть. вот его и надо копировать.

вручную, разумеется. С такой высокоуровневый язык, лол.

ну или объектными обёртками на С++ к низкоуровневым же костылям.

через RAII или смартпоинтеры.

говорю же: нарисуй еще и жизненные циклы содержимого по указателю. кто кому когда чего выделяет и когда за кем чистит.

тогда все непонятки сами собой отпадут.

классической, 7.5 или девятке?

или в неХт-подобной?

MacOS Classic 7.6

А паскаль там был Think Pascal.

анон, я сейчас пойду водку пить с утра, если ещё что-нибудь напишешь.

Ну ты язык то выбрал? А то я почитываю тему, но не всю.

Java

Java

Kotlin

вот это «нужно» уже навязано С/С++ пониманием. можно передавать объект по ссылке или по значению. в более других языках есть например ключевое слово IN которое показывает что это – входной параметр, значит, он передается по ссылке, и более того, изменять внутри функции его нельзя.

в с++ как и в С – всего этого нет. поэтому «указатель на объект»,«ссылка на объект», &foo – это костыль особенностей С или С++ (еще например в ANSI/K&R ссылок нет, только указатели – так что ты сам должен понять где передавать по ссылке – и взять &адрес , например, в sscanf – а где по значению, и понимать что работаешь с копией переданного значения, соответственно если его внутри функции пытаться менять – изменишь копию).

ой ну и путаница у тебя в голове. в с++ IN параметр просто записывается явно - const T&. (то есть ссылка на констатное значение)

а & value - это тоже самое что addr(value), просто амперсандом обозначена функция взятия адреса, и такое многозначное использование лексем в с++ - это у них привычка. то есть это вовсе не тот амперсанд что в ссылке.

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

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

а еще есть двойной амперсанд

что, разумеется, многократно увеличивает читаемость программы. Чем больше применений у оператора, тем проще писать программу. Например, брейнфак славится своей простотой и выразительностью. А все потому, что там мало лексем.

Relocation сделали, а тройного амперсанда не будет?

struct FRT final replaceable_if_eligible trivially_relocatable_if_eligible {};

нет там строк, ни в С, ни в С++ – тебя обманули. даже массивов многомерных и нормальных векторов – их тоже нет.

а настоящих массивов над ними нет – в plain C. типа настоящих матриц и векторов, как в том же фортране или паскале.

в С++ их – сюрприз, тоже нет. только есть всякие разные обёртки над C одномерными массивами.

по этой самой причине, строк в C и в С++ — тоже нет.

вот в D например, есть строки. в Go есть строки. потому что есть слайсы массивов и автоматическая функция длины. а в С/С++ строк нет – просто обёртки над DB(???) в ассемблере.

по этой же самой причине различные типы классов-обёрток в С++ изобретают неоднократно: в каком-нибудь std:: затем в Qt или еще где.

ах, да. потом еще кодировки строк. то есть – нормальная интеграция со встроенным типом строк должна поддерживать например, кодировки и/или уникодность.

Строк нет, но строковые данные есть, потому как любые данные бывают либо строковые, либо бинарные.

Допустим читаем у Праты, что для описания строковых данных нужно использовать тип string из библиотеки string, потом, когда проходим указатели, узнаём, что строку также можно прописать через указатель на первый символ строки, то есть char* что да является полным аналогом db в ассемблере за той разницей, что тут символ конца строки не вписывается, потом узнаём, что string и wsting - это на самом деле классы, и только в конце книги в приложении Е раскрываются все фишки класса string. Из-за такой дурацкой компановки книги, я и предпочёл изучать C++ по четырём книгам одновременно.

А если считать, что string, iostream и всё что называется «стандартной библиотекой» частью языка С++ не являются, то да, можно сказать, что строк как таковых в C++ нет и вообще это язык низкого уровня. Я когда-то хотел освоить ассемблер, даже полностью освоил книжку Пильщикова, где описывается программирование под DOS, хотел освоить сложный язык в котором нет ООП, но когда добрался до «Уроков Iczelion’а», где описывается, что для вызова простейшей функции WinAPI нужно перед call передать через стек 10 параметров, а также адрес памяти, указывающий на структуру, которая содержит ещё 10 параметров, после чего понял, что эта структура и есть объект и язык с поддержкой ООП-парадигмы был бы удобнее.

1.4. четвертый параметр – указатель на значение любого типа

Но при этом мы знаем, что данные там тоже строковые. Вопрос, если тип void* то как выполнять строковые операции, например скопировать строку из одной области памяти в другую, если бы был string, то там простым присваиванием переменной можно было бы провернуть, а тут как? А конкатенацию строк как делать?

Ну ты язык то выбрал? А то я почитываю тему, но не всю.

Ну 3 варианта:

1. Продолжать штудировать C++ до просветления и не ныть.
2. Изучать C без плюсов
3. Попробовать Go

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

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

Си без плюсов поудобнее и порабочее, но инфраструктура та же угребищная, если нужны готовые модули.

Го это что то среднее между Си и Растом. Уже есть кое какая инфраструктура, можно полу-автоматически все подтягивать и получить рабочий проект буквально мгновенно, но чуть менее удобно, чем в Раст - вместо единой команды на все, несколько команд, бинарники побольше выходят, модули похуже (чисто мое субъективное), синтаксис не настолько однозначный.

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

Это все - субъективное мнение нуба, которому нужно делать рабочие проекты здесь и сейчас просто потому что нужно, иногда даже с нулевым знанием языка. У профессионалов определенно будет другое мнение.