Они сделали дерьмо опять - C/C++

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

K>С вложенным классом Storage::Blob такой номер не пройдет т.к. в языке С++ нет механизма опережающих описаний. Это баг уровня языка который нужно исправлять. Как бы вы тут не распинались, что это и не нужно.

K>

K>struct Storage::Blob;
K>void foo(Storage::Blob *blob);
K>

Правда что ли? Суждениями похож на любителя раста, те тоже рассуждают о том чего не знают.

// main_iface.h
#ifndef MAIN_IFACE_H
#define MAIN_IFACE_H

class storage {
public:
    class blob;
};

storage::blob* make_blob();
int using_blob(storage::blob* b);

#endif /* MAIN_IFACE_H */

// main_impl.cpp
#include "main_iface.h"

class storage::blob {
public:
  int finish() {
    return 42;
  }
};

storage::blob* make_blob() {
  return new storage::blob();
}

int using_blob(storage::blob* b) {
  return b->finish();
}

// main.cpp
#include "main_iface.h"
#include <iostream>

int main() {
    std::cout << using_blob(make_blob()) << "\n";
    return 0;
}

Собирается gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), С++98,

g++ main.cpp main_impl.cpp -o main

Может это баг уровня твоего знания С++?

ЗЫ: Про сырой указатель и мемлик знаю, это к вопросу о возможностях языка.

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

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

YV>Правда что ли? Суждениями похож на любителя раста, те тоже рассуждают о том чего не знают.

YV>[ccode]

YV>class storage {
YV>public:
YV> class blob;
YV>};

Так идея в том чтобы storage тоже имел "forward declaration" наряду с blob.

https://stackoverflow.com/questions/951234/forward-declaration-of-nested-types-classes-in-c

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

Z>Так идея в том чтобы storage тоже имел "forward declaration" наряду с blob.

Z>https://stackoverflow.com/questions/951234/forward-declaration-of-nested-types-classes-in-c

Это не идея, а непонимание. Полный тип в C++ это его имя и описание его структуры. А "forward declaration" объявляет лишь имя типа (incomplete type) структура которого сейчас неизвестна и поэтому получить доступ к структуре (storage::blob) incomplete type через его имя невозможно. Тут всё логично и никакой "дыры" в языке нет. Можно ввести в язык расширяемые классы, ну как namespace может расширяться в разных единицах трансляции новыми declaration/definition. Этакая альтернатива наследованию, но к чему это может привести прогнозировать сложно.

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

MA>Ядро линукса компилируется в рабочее состояние ровно одним клмпилятором. Вам это ни о чем не говорит?

Это ложь.

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

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

K>>С вложенным классом Storage::Blob такой номер не пройдет т.к. в языке С++ нет механизма опережающих описаний. Это баг уровня языка который нужно исправлять. Как бы вы тут не распинались, что это и не нужно.

K>>

K>>struct Storage::Blob;
K>>void foo(Storage::Blob *blob);
K>>

YV>Правда что ли? Суждениями похож на любителя раста, те тоже рассуждают о том чего не знают.

YV>Собирается gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), С++98,

YV>g++ main.cpp main_impl.cpp -o main

YV>Может это баг уровня твоего знания С++?

Сначала разберись, что здесь обсуждают, а потом уже лезь в разговор без хамства и перехода на личностей.

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

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

Z>>Так идея в том чтобы storage тоже имел "forward declaration" наряду с blob.

Z>>https://stackoverflow.com/questions/951234/forward-declaration-of-nested-types-classes-in-c

YV>Это не идея, а непонимание. Полный тип в C++ это его имя и описание его структуры. А "forward declaration" объявляет лишь имя типа (incomplete type) структура которого сейчас неизвестна и поэтому получить доступ к структуре (storage::blob) incomplete type через его имя невозможно. Тут всё логично и никакой "дыры" в языке нет. Можно ввести в язык расширяемые классы, ну как namespace может расширяться в разных единицах трансляции новыми declaration/definition. Этакая альтернатива наследованию, но к чему это может привести прогнозировать сложно.

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

class storage;
class storage::blob;

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

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

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

Z>>>Так идея в том чтобы storage тоже имел "forward declaration" наряду с blob.

Z>>>https://stackoverflow.com/questions/951234/forward-declaration-of-nested-types-classes-in-c

YV>>Это не идея, а непонимание. Полный тип в C++ это его имя и описание его структуры. А "forward declaration" объявляет лишь имя типа (incomplete type) структура которого сейчас неизвестна и поэтому получить доступ к структуре (storage::blob) incomplete type через его имя невозможно. Тут всё логично и никакой "дыры" в языке нет. Можно ввести в язык расширяемые классы, ну как namespace может расширяться в разных единицах трансляции новыми declaration/definition. Этакая альтернатива наследованию, но к чему это может привести прогнозировать сложно.

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

K>

K>class storage;
K>class storage::blob;
K>

Верно. Объявление вложенного типа находиться внутри "member specification" или class body или пространства имён класса — как угодно, которое очевидно отсутствует в "forward declaration". Так что с точки зрения языка всё верно. Иначе чем nested typedefs лучше nested data members, тогда и их надо разрешить и методы и т.д. Такие вещи можно делать в темплейтных классах и то ограниченно. Например этот код не скомпилиться, потому что в точке использования тип C всё ещё неопределён.

template <typename T> struct A { 
  using type = typename T::C; // error
};

struct B : A<B> {
  using C = int;    
};

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

S>Но это не так. И авторы STL не единственные люди, которые считают, что размеры и индексы должны быть беззнаковыми.

Вообще-то они уже признали, что это была ошибка.

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

S>Если вы не в курсе, то STL допиливался до состояния, в котором его приняли в стандарт, несколько лет. И в 1996-1997-ом годах свободные реализации STL (вроде бы от RogueWare) уже активно использовались в продакшене.

RogueWave, если быть точным. В бормановском билдере 1, 3, и может и 5, например

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

K>Если вы не в курсе от раннего stl-мазохизма в продакшене активно отказывались и пересаживались на собственные разработки. Это уже веский повод не торопится с добавлением такой сомнительной библиотеки.

Если вы не в курсе, то к моменту даже раннего stl многие уже плотно сидели на своих велосипедах

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

S>>Но это не так. И авторы STL не единственные люди, которые считают, что размеры и индексы должны быть беззнаковыми.

TB>Вообще-то они уже признали, что это была ошибка.

Если под "они" подразумеваются авторы STL, то где об этом можно прочитать?

А вообще речь шла о том, что кроме авторов STL есть разработчики, которые находят логичным использование беззнаковых чисел для размеров и индексов. Т.е. авторы STL вовсе не были "белыми воронами".

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

S>>Если вы не в курсе, то STL допиливался до состояния, в котором его приняли в стандарт, несколько лет. И в 1996-1997-ом годах свободные реализации STL (вроде бы от RogueWare) уже активно использовались в продакшене.

M>RogueWave, если быть точным. В бормановском билдере 1, 3, и может и 5, например

Некоторые умельцы прикручивали STL от RogueWave к Watcom 10 и 11.

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

S>>>Если вы не в курсе, то STL допиливался до состояния, в котором его приняли в стандарт, несколько лет. И в 1996-1997-ом годах свободные реализации STL (вроде бы от RogueWare) уже активно использовались в продакшене.

M>>RogueWave, если быть точным. В бормановском билдере 1, 3, и может и 5, например

S>Некоторые умельцы прикручивали STL от RogueWave к Watcom 10 и 11.

Еще вот прямо сейчас смотрю в хидеры пятого кейла для арма, который ARMCC, а не ARMCLANG, и вижу

* Copyright (c) 1994-2001 Rogue Wave Software, Inc. All Rights Reserved.

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

K>>

K>>class storage;
K>>class storage::blob;
K>>

YV>Верно. Объявление вложенного типа находиться внутри "member specification" или class body или пространства имён класса — как угодно, которое очевидно отсутствует в "forward declaration". Так что с точки зрения языка всё верно.

Неверно. Пространство имен класса очевидно присутствует в опережающем описании. Вот оно:

class storage;

Поэтому нет никаких проблем с объявлением вложенного класса.

YV>Иначе чем nested typedefs лучше nested data members, тогда и их надо разрешить и методы и т.д.

У атрибутов смещение в объекте зависит от порядка декларации. Поэтому разрешить опережающее описание не статических атрибутов в рамках языка С++ невозможно.

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

S>А вообще речь шла о том, что кроме авторов STL есть разработчики, которые находят логичным использование беззнаковых чисел для размеров и индексов. Т.е. авторы STL вовсе не были "белыми воронами".

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

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

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

S>>>Но это не так. И авторы STL не единственные люди, которые считают, что размеры и индексы должны быть беззнаковыми.

TB>>Вообще-то они уже признали, что это была ошибка.

S>Если под "они" подразумеваются авторы STL, то где об этом можно прочитать?

S>А вообще речь шла о том, что кроме авторов STL есть разработчики, которые находят логичным использование беззнаковых чисел для размеров и индексов. Т.е. авторы STL вовсе не были "белыми воронами".

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

Вот один из примеров. Допустим нужно перебрать все элементы кроме первого и последнего:

    for (int i = 1; i < v.signed_size() - 1; i++)
    {
        v[i];
    }

    for (size_t i = 1; i < v.unsigned_size() - 1; i++)
    {
        v[i];
    }

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

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

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

Ты всё ниправильна делаиш2221111

std::kokoko::algoritmi::ubrat_posledniy<std::kokoko::algoritmi::dla_vectora<std::kokoko::algorimti::intov>>(
std::kokoko::algoritmi::ubrat_perviy<std::kokoko::algoritmi::dla_vectora<std::kokoko::algorimti::intov>>(

std::kokoko::algoritmi::rangi<std::kokoko::algoritmi::dla_vectora<std::kokoko::algorimti::intov>>::sdelat_rang::dla_vectora<std::kokoko::algorimti::intov>
)
).each(...)

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

Респект вам за грамотное и корректное общение.

И дизреспект so5team за тупые наезды, хамство и переходы на личности.

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

TB>Конечно есть. Даже если заставлять С++ников прямо жрать говно, то мне кажется чуть ли не половина начнёт доказывать, что так и надо и что там есть полезные витамины.

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

Ничего конструктивного и полезного вы не сказали, но зачем-то завели речь про "жрать говно".

И если опуститься на ваш уровень и продолжить разговор про "говно", то окажется, что наезжает и хамит so5team.

	От:	B0FEE664
	Дата:	19.06.20 19:03
	Оценка:

	От:	YuriV
	Дата:	22.06.20 10:23
	Оценка:	-2

	От:	Zhendos
	Дата:	22.06.20 11:10
	Оценка:	+1

	От:	YuriV
	Дата:	22.06.20 12:03
	Оценка:	+1

	От:	IID
	Дата:	23.06.20 09:40
	Оценка:

От:	Marty	https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата:	23.06.20 21:46
Оценка:

От:	so5team	https://stiffstream.com
Дата:	24.06.20 05:20
Оценка: