1
|
Програмиране / Общ форум / Re: Къде се намира so?
|
-: May 22, 2016, 00:32
|
Всъщност, в днешно време не е 100% вярно че линкерът не се интересува от инклуди, защото теоретично, в зависимост от това което се инклудва е възможно това да повлияе на процеса на линкване. Става разбира се по доста индиректен начин, но е възможно. Причината е в LTO оптимизациите дето от известно време са доста модерни нещо. Там процесът малко се променя, линкерът вече не е толкова тъп просто да "събира" няколко object файла в някакъв ELF такъв - те на практика дори object файловете вече може да не са същите като преди. Вместо relocatable машинен код, може да има някаква междинна репрезентация между C кода и машинния код, което вече позволява да минават допълнителни link-time оптимизации преди да се "генерира" крайния ELF файл. Така на практика, нещата между компилатор и линкер леко се размиват.
Та пак на въпроса - възможно е include-натите хедъри да повлияят на линкването, особено ако съдържат разни препроцесорни директиви, които влачат функционални "промени". На практика не особено вероятно, но това не означава че е невъзможно.
|
|
|
2
|
Програмиране / Общ форум / Re: Къде се намира so?
|
-: May 18, 2016, 12:11
|
Между другото, вероятно индиректно могат да се викат и методи на обекти, през function pointer-и. Тя calling конвенцията е почти същата с това изключение че първият параметър към функцията трябва да е this, демек указател към обекта. Не че някога съм пробвал (почти никакво вземане-даване с изпълнение на C++ код от C нямам ако трябва да съм честен), но не мисля че би имало някакъв проблем. Обаче не мисля че C кода би могъл да създаде нов обект като хората, да му викне конструктора и т.н. А може и да може, знам ли. От друга страна, може да има и някакъв фундаментален проблем с викането на методи през function pointer-и, въпреки че поне в момента не се сещам.
П.П type safety-то е интересен въпрос разбира се, ако методите вземат някакви по-"C++ специфични" аргументи може да се случи неприятна авария.
|
|
|
3
|
Програмиране / Общ форум / Re: Къде се намира so?
|
-: May 18, 2016, 10:28
|
"при C++ нещата стават леееко различни, тези същите символи изглеждат съвсем различно (и много грозно и неразбираемо)" Една лека забележка. Могат да се "пооправят" нещата например с: #ifdef __cplusplus extern "C" { #endif
Може и така, обаче тогава ще трябва да си пишеш C функции, wrap-ващи C++ методите, не мисля че ще минеш без това.
|
|
|
4
|
Програмиране / Общ форум / Re: Къде се намира so?
|
-: May 15, 2016, 00:32
|
Ъммм много оптимистично е това, дори binary-то да е компилирано с debug символи и да не е strip-нато, не мисля че можеш да възтановиш source кода. Това че с gdb примерно можеш да видиш точно на кой ред гърми нещо и какъв е реда се дължи просто на факта че имаш и сорса, а иначе не мисля че можеш да "извадиш" сорса от debug символите...може би все пак може във вид на някаква междинна интерпретация, но оригиналния C сорс - абсурд. Освен което много рядко ще ти попадне нещо с debug символи, особено нещо със затворен код.
Също така тук говорим за чисто C....при C++ нещата стават леееко различни, тези същите символи изглеждат съвсем различно (и много грозно и неразбираемо) ако са методи на класове примерно. Та това дето го говориш че C било тъмна Индия и вуду магия, ха!
|
|
|
5
|
Програмиране / Общ форум / Re: Къде се намира so?
|
-: May 14, 2016, 22:15
|
То ти и -lc не указваш за да се линкнеш с libc, става автоматично (същото и за още няколко библиотеки част от libc - математическата, тази за posix нишките и т.н.)
Иначе няма значение какво include-ваш, има значение какво викаш из кода обаче - после при линкване което се намери из object файловете се включва, каквото не - влиза в една таблица, тази въпросната накрая е определяща при динамичното линкване. Предполагам readelf/objdump може да ти изкара въпросната.
|
|
|
6
|
Програмиране / Общ форум / Re: Къде се намира so?
|
-: May 14, 2016, 21:10
|
man ld-linux.so
P.S и другите въпроси са хубави - на първо време забрави за хедърите, защото те нямат много общо.
Под "линкер" се разбират две неща - на gcc линкера с който линкваш крайния изпълним файл и "динамичния" такъв (ld-linux.so) който знае в runtime къде и какво да търси на базата на разни неща в ELF хедъра.
Едното и другото от различни неща зависи къде ще си търсят библиотеките - опции на командния ред, променливи от обкръжението и т.н. Дори в link-time можеш да го направиш срещу една библиотека, а при изпълнението - срещу друга.
Що се отнася до -lfoo и libfoo.so, това е по-скоро именна конвенция....shared библиотеките трябва да се казват libнещото.so и да могат да се открият в директориите където се търсят.
|
|
|
8
|
Linux секция за начинаещи / Настройка на хардуер / Re: Info за tv тунери
|
-: May 14, 2016, 01:40
|
Не там, pulseaudio е тъпо животно, обаче ми се спи за да обяснявам защо е лоша идея - кратко и просто нищо няма да се случи ако го сложиш там. Или промени default.pa на pulseaudio-то (след това рестартирай pulseaudio или ако не знаеш точно как - логаутни се от X-а и се логни наново), или ако не искаш да става "глобално" - в този конкретен случай ще мине ако набиеш същата команда в ~/.bashrc - колкото и да е тъпо и склонно към проблеми, точно в този случай няма да ги имаш, най-много да гледаш някое глупаво съобщение за грешка като си отваряш нови терминали в X-а или се логваш през ssh. Но последното може да е досадно верно.
|
|
|
9
|
Хардуер за Линукс / Десктопи / Re: Лампов усилвател модул за Raspberry Pi
|
-: May 10, 2016, 16:03
|
самоцитирам се-"единствената помощ е увеличаване на битрейта."
при по-голям битрейт става по-плавно описание на сигнала-оттам изкривяванията са по-малки
мазалото е на нисъка честота на семплиране-колкото по-ниска-толкова по-голямо мазало
засега най-мощният вариант е този-по-голям битрейт, има и дуги
УФ! Това което наричаш "битрейт" е достатъчно да е по-голямо от 2 пъти честотата на семплирания аналогив сигнал, за да можеш ИДЕАЛНО да го реконструираш. Ако случайно можеш да докажеш че въпросната теорема на Котелников/Найкуист е невярна и трансформацията на Фурие в дискретно време не може да реконструира идеално аналоговия сигнал при изпълнени съответните условия за дискретните стойности, тогава го направи и целият свят (евентуално без шаманите) ще се съгласят с теб. Ако аргументите ти са "ама на мен това ми звучи по-добре, не знам защо, кривоч е иначе" - какво да ти кажа, със същият успех можеш да твърдиш че земята е плоска и подпряна на две гигантски костенурки.
|
|
|
10
|
Хардуер за Линукс / Десктопи / Re: Лампов усилвател модул за Raspberry Pi
|
-: May 10, 2016, 08:36
|
Проблемите са огромни-на високи нива на сигнала е добре, но на ниски нива на сигнала имаш много груби грешки и страшно мазало. В какво се състои мазалото? Зевсе, всъщност няма огромно значение, нека за момент предположим че си прав и да видим какво следва от това. Значи колкото повече oversampling, толкова по-страшно мазало, нали така? Тоест при даден sample rate, колкото по-ниска е аудио честотата която дискретизираме, толкова по-голямо "мазало" е, просто защото в рамките на една секунда дискретизирани данни, ще имаме толкова повече дискретизирани стойности, нали така? Зевсе, че ти тогава правиш огромна глупост като си слушаш ден победи на 88200 samples/s. Това е точно 2 пъти по-зле от CD качеството от 44.1 където така или иначе вече ниските честоти би следвало да с "много груби грешки и страшно мазало". В случая просто два пъти по-груби грешки и страшно мазало значи. А ти се оплакваш че не ти давали да възпроизвеждаш музика дискретизирана на 384 khz. Е там па какво мазало би било вече не знам. Да не излезе че всъщност обичаш да слушаш мазало и много груби грешки?
|
|
|
12
|
Хардуер за Линукс / Десктопи / Re: Лампов усилвател модул за Raspberry Pi
|
-: May 10, 2016, 02:22
|
Да, разбира се с шаманизъм можеш да убедиш всеки....който ти повярва. Така е откакто свят светува. За жалост обаче обществата, в които шаманите са авторитивният източник на знание просто не са имали късмета да оцелеят....повечето поне. Може би това е логичния резултат от естествения подбор, а може би е конспирация - не знам
|
|
|
13
|
Хардуер за Линукс / Десктопи / Re: Лампов усилвател модул за Raspberry Pi
|
-: May 10, 2016, 01:39
|
Уфффф аман бе. Абе защо няма видеофили да му се не види. А, знам защо, защото като направим съпоставката и глупостите става прекалено нагледни.
Първо sample rate-а на записа - много добре известен факт е че човешкият слух реагира на звукови честоти между 60-тина херца и 20 килохерца. Максималната звукова честота, която надеждно можеш да възпроизведеш е sample_rate/2, защо това е така е съвсем отделен въпрос. Следователно за 44.1-те килохерца на аудио CD-тата тя е малко над 20khz, за 384000 тя ще е 192000. 192000 е близо 10 пъти над горната граница на човешкия слух. Обаче да речем че сме тотални пуристи и искаме да запишем музиката точно както е, без значение че високите честоти няма да ги чуем.
Айде сега същото упражнение за нашия видеофил - под видимата светлина е инфрачервената част от спектъра, над нея - ултравиолетовата. Понеже искаме да записваме и възпроизвеждаме 10 пъти по-широк честотен спектър, то значи ще трябва да записваме и възпроизвеждаме надолу почти до микровълновия спектър и нагоре до йонизиращата ултравиолетова светлина. Да, там е по-зле, защото тази самоцел ще ни струва здравето, в добрият случай ще хванеш тен. Ама илюстрира добре безумието.
После същата работа с колко бита на дискретизирана стойност. Съпоставката не е 1:1, ама е сходна ситуация. Да хванем което и да е било grayscale (за по-лесно) изображение, обикновено то е 8-битово. Да, може да е записано като 24-битово (в който случай и трите канала имат една стойност), дори 32-битово (с допълнителна стойност за алфа), дори може повече от един байт да ти кодира нюансите на сивото, ама накрая на RGB монитора визуализираш максимум 256 сиви стойности или 8 бита - всичко различно от това ще бие я на синкаво, я на червеникаво, я на зеленикаво, т.е няма да е точно grayscale. Ама как не се сетили да го променят това - ми не са се сетили щото хората рядко различават повече от 30-40 нюанса на сивото и то при идеално осветление, т.е дори тези 256 възможни стойности са им overkill. Да, тези дето се занимават с обработка на изображения може и да си го записват във формати с повече битове за кодиране на сивото - ама там е поради съвсем различни причини. И като им гледаш крайния резултат на монитора, той пак си е с 8-битовите нюанси. А можеше и да не е така, можеше да го направят 32 бита да кодират нива на сивото, просто не са сектанти-ценители като аудио-хората, а са стъпили на земята. Но и нещо няма хора дето се кълнат как могат да различат 50 хиляди нюанса сиво. Е, същата история е и с 24-битовия и 32-битовия звук.
После същата работа с това дали PCM семплите да се пазят като числа с плаваща запетая (float) или като целочислени стойности - ИЗНЕНАДА, НЯМА НИКАКВО ЗНАЧЕНИЕ. Поне докато просто възпроизвеждаш. Ама никаква. Технически дори никой не знае дали са float или int - това е въпрос на интерпретация от софтуера или от DAC-а, иначе и двете са си точно едно и също. float семпли НЯМА да звучат различно от съответните int такива. Разликите идват единствено при манипулиране на семплираното аудио - и идва от разликите в precision-а и закръглянето на стойности. Но ако просто възпроизвеждаш - няма значение.
Само се чудя как още не сте се хванали за endianness-а на семплите, ама може би little-endian звучи по-качествено от big-endian или обратното? Ама въобще няма да се учудя...
|
|
|
14
|
Хардуер за Линукс / Десктопи / Re: Лампов усилвател модул за Raspberry Pi
|
-: May 09, 2016, 02:11
|
Абе между другото, има едно много забавно сериалче, за който има HBO Go, иначе сигурно го има из торънтите - Vinyl. Забавно е защото освен че из режисьорите са пичове като Мартин Скорсезе, в състава им има и рок динозаври като Мик Джагър. Та интригата се върти около една затъваща продуцентска/аудиоиздателска компания в Ню Йорк в края на 70-те и началото на 80-те. Пичовете искаха да я продадат на Полиграм, но шефчето което реши да се завърне към пороците си (кокаин и хазарт главно) опропасти всичко - компанията, включително и семейството си. И осенен от висши намеси, реши да спасява компанията си. Сериалчето е забавно иначе, най-малкото илюстрира процеса по начин по който не съм си мислил, а и има доста забавни и реалистични сцени със студията, включително аналоговата техника тогава. Та като изключим това, интрото на сериала е с една плоча която се просвирва, но всичкото това е през микроскоп...не знам дали е автентично или е някаква артистична гавра, но ми изглежда реалистично някак. Под такова увеличение, нещата изглеждат доста грозно....иглата цепи през винила и наоколо има един дебел слой "прахоляк", демек изпилена пластмаса от плочата и всичко това странно напомня на разходка на луноход по лунната повърхност. P.S всъщност, то го имало в youtube, разбира се: https://www.youtube.com/watch?v=mVI0JqC-fAQ
|
|
|
15
|
Хардуер за Линукс / Десктопи / Re: Лампов усилвател модул за Raspberry Pi
|
-: May 08, 2016, 13:46
|
Аз,като рационално мислещ човек (а не сноб),разсъждавам по следния начин: Една грамофонна плоча,колкото и да е качествена,се износва сравнително бързо (освен ако не се използва някакъв супер материал). Колкото и качествен и скъп да е грамофона, при всички положения има механични вибрации, които влияят на качеството на звука.При всички положения има пукане,пращене и т.н. които с течение на времето се засилват.Е как се търпи това от "аудиофилите"...
Ха, да, има го това. На мен основният аналогов аудионосител който съм "ползвал" бяха аудио/видеокасетите, вкъщи имахме и грамофон, при баба ми имаше магнетофон с онези ролки с ленти, но за последното не мога да говоря, защото бях много малък тогава. Но с плочите с детски приказки съм отраснал. Като цяло май са си доста "държеливи" в сравнение с аудиокасетите - последно съм слушал плочи някъде в средата на 90-те, преди въпросният грамофон да замине на един таван, където го откраднаха. Те си звучаха кажи-речи по същият начин както като бях прав под масата, това са повече от 10 години, единствено самият грамофон беше тръгнал да се сдухва, доколкото помня нещо с иглата. Аудиокасетите и видеокасетите обаче - мех. Имат потресаващото свойство да се скапват бързо с времето дори да не ги ползваш. Значи пак някъде края на 90-те бях набарал касетите дето съм си ги слушал като малко тийн-говедце от началото на 90-те и все още имахме касетофон с CD плеъра - та реших да ги прослушам - беше трагедия - чуваше се тихо и глухо, съскаше, противия. Видеокасетите са същата работа, старите видеокасети са все едно гледаш слаб аналогов ТВ сигнал някъде далеч извън града. Старите аудио CD-та ако не друго поне държат доста повече с времето - единствено надраскването и слънчевата светлина ги прецакват - звучат си точно по същия начин след 10 години.
|
|
|
Страници: [1] 2 3 ... 409
|
|