Re[30]: Они сделали дерьмо опять
От: B0FEE664  
Дата: 19.06.20 19:03
Оценка:
Здравствуйте, Kluev, Вы писали:

BFE>>И как же они использую рефлексию и для чего?

K>Как минимум для сериализации

Тогда у меня тот же вопрос: что с обратной совместимостью для десятилетних проектов? Она есть? Если да, то как реализована?
И каждый день — без права на ошибку...
Re[26]: Они сделали дерьмо опять
От: YuriV  
Дата: 22.06.20 10:23
Оценка: -2
Здравствуйте, 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

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

ЗЫ: Про сырой указатель и мемлик знаю, это к вопросу о возможностях языка.
Отредактировано 22.06.2020 10:28 YuriV . Предыдущая версия .
Re[27]: Они сделали дерьмо опять
От: Zhendos  
Дата: 22.06.20 11:10
Оценка: +1
Здравствуйте, 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
Re[28]: Они сделали дерьмо опять
От: YuriV  
Дата: 22.06.20 12:03
Оценка: +1
Здравствуйте, 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. Этакая альтернатива наследованию, но к чему это может привести прогнозировать сложно.
Re[13]: Они сделали дерьмо опять
От: IID Россия  
Дата: 23.06.20 09:40
Оценка:
Здравствуйте, Mystic Artifact, Вы писали:

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


Это ложь.
kalsarikännit
Re[27]: Они сделали дерьмо опять
От: Kluev  
Дата: 23.06.20 10:06
Оценка: +1
Здравствуйте, 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>Может это баг уровня твоего знания С++?


Сначала разберись, что здесь обсуждают, а потом уже лезь в разговор без хамства и перехода на личностей.
Re[29]: Они сделали дерьмо опять
От: Kluev  
Дата: 23.06.20 10:28
Оценка: :)
Здравствуйте, 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;
Re[30]: Они сделали дерьмо опять
От: YuriV  
Дата: 23.06.20 20:35
Оценка:
Здравствуйте, 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;    
};
Re[27]: Они сделали дерьмо опять
От: T4r4sB Россия  
Дата: 23.06.20 21:05
Оценка:
Здравствуйте, so5team, Вы писали:

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


Вообще-то они уже признали, что это была ошибка.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[23]: Они сделали дерьмо опять
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 23.06.20 21:46
Оценка:
Здравствуйте, so5team, Вы писали:


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


RogueWave, если быть точным. В бормановском билдере 1, 3, и может и 5, например
Маньяк Робокряк колесит по городу
Re[24]: Они сделали дерьмо опять
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 23.06.20 21:49
Оценка:
Здравствуйте, Kluev, Вы писали:


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


Если вы не в курсе, то к моменту даже раннего stl многие уже плотно сидели на своих велосипедах
Маньяк Робокряк колесит по городу
Re[28]: Они сделали дерьмо опять
От: so5team https://stiffstream.com
Дата: 24.06.20 05:20
Оценка:
Здравствуйте, T4r4sB, Вы писали:

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


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


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

А вообще речь шла о том, что кроме авторов STL есть разработчики, которые находят логичным использование беззнаковых чисел для размеров и индексов. Т.е. авторы STL вовсе не были "белыми воронами".
Re[24]: Они сделали дерьмо опять
От: so5team https://stiffstream.com
Дата: 24.06.20 05:21
Оценка:
Здравствуйте, Marty, Вы писали:

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


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


Некоторые умельцы прикручивали STL от RogueWave к Watcom 10 и 11.
Re[25]: Они сделали дерьмо опять
От: Marty Пират https://www.youtube.com/channel/UChp5PpQ6T4-93HbNF-8vSYg
Дата: 24.06.20 09:20
Оценка:
Здравствуйте, 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.


Маньяк Робокряк колесит по городу
Re[31]: Они сделали дерьмо опять
От: Kluev  
Дата: 24.06.20 10:49
Оценка:
Здравствуйте, 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, тогда и их надо разрешить и методы и т.д.


У атрибутов смещение в объекте зависит от порядка декларации. Поэтому разрешить опережающее описание не статических атрибутов в рамках языка С++ невозможно.
Re[29]: Они сделали дерьмо опять
От: T4r4sB Россия  
Дата: 24.06.20 11:14
Оценка: +1
Здравствуйте, so5team, Вы писали:

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


Конечно есть. Даже если заставлять С++ников прямо жрать говно, то мне кажется чуть ли не половина начнёт доказывать, что так и надо и что там есть полезные витамины.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[29]: Они сделали дерьмо опять
От: Kluev  
Дата: 24.06.20 11:15
Оценка: :)
Здравствуйте, 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];
    }


Со знаковым индексом пример всегда будет корректно работать, с беззнаковым на пустой коллекции ошибка времени выполнения.
Re[30]: Они сделали дерьмо опять
От: T4r4sB Россия  
Дата: 24.06.20 11:21
Оценка: +1 :))
Здравствуйте, 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(...)
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[30]: Они сделали дерьмо опять
От: AlexRK  
Дата: 24.06.20 11:25
Оценка:
Здравствуйте, Kluev, Вы писали:

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

И дизреспект so5team за тупые наезды, хамство и переходы на личности.
Re[30]: Они сделали дерьмо опять
От: so5team https://stiffstream.com
Дата: 24.06.20 12:26
Оценка: +1
Здравствуйте, T4r4sB, Вы писали:

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


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

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

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