C/C++

Üdv, Írtam egy PICO-8-szerű, retro virtuális konzolt (ezen az oldalon ez eléggé többértelmű, szóval konzol, mint NES, Famicom, PS, XBox stb.). A célja a kezdő programozók segítése, hogy gyorsan és könnyen sikerélményekkel szolgáljon nekik, mint anno a Commodore és társai az én időmben. https://bztsrc.gitlab.io/meg4/ Néhány fícsör a teljesség igénye nélkül: - Szabad és Nyílt forráskódú (GPL, gitlab repó) - támogatja a BASIC-et (akárcsak bármelyik 80-as évekbeli home computer), Lua-t (mint a többi virtuális konzol), de programozható C-ben (saját natív nyelve) illetve Assemblyben is - többnyelvű, UTF-8 támogatással, a beépített súgó természetesen magyar nyelven is elérhető (ehhez írtam egy MarkDown megjelenítőt) - akárcsak a többi virtuális konzol, beépített szerkesztőkkel rendelkezik (szövegszerkesztő, szprájtszerkesztő, zeneszerkesztő, stb., de még debugger is van benne) - de ha valaki ragaszkodik a kedvenc eszközéhez, a könnyű átjárhatóság érdekében rengeteg formátumot támogat (PNG, Amiga MOD, MIDI, Tiled TMX, BDF, PSF, de még PICO-8 és TIC-80 kertridcsek is importálhatók vele) - a rendelkezésre álló függvénykönyvtár terebélyes, átfogó és hatékony (szokásos grafikai primitíveken túl Bezier-ívek, teknőcgrafika, 3D-s labirintus és mátrix meg kvaterniófunkciók pl.) - a programozást nagyon leegyszerűsíti és szórakoztatóvá teszi a szövegszerkesztés közbeni segéd (gépelés közben mutatja, milyen paraméterei vannak az API-nak) - részletes, jól megírt dokumentációval rendelkezik: https://bztsrc.gitlab.io/meg4/manual_hu.html Jelenlegi formában még kezdetleges, itt-ott kissebb bugokra kell számítani, de már elég jól használható. Bináris futtathatók is letölthetők (statikusan linkelt Windows és Linux, valamint dinamikusan linkelt Ubuntu és Raspberry Pi .deb csomagok formájában). Telepítést nem igényel (portable executable). Natív futtathatókon túl böngészőre optimalizált WebAssembly port is elérhető. Ha valaki kipróbálná, akkor klikk a honlapra, és húzzátok rá valamelyik flopi képet az emulátorra! Egyelőre kevés példaprogram van hozzá, de azok remélem jól példázzák, mire képes. Kíváncsian várom a véleményeiteket! bzt ps: ha valaki kérdezné, miért nem TIC-80, akkor a válaszom az, hogy azért nem, mert az rettentő bugos és nem tud magyarul. Sőt mi több, a magyarítása nem is lehetséges (beégetett sztringek és ékezetes karakterek teljes hiánya miatt). FRISSÍTÉS: fun ötlet, igazi MEG-4 vas mekkora királyság lenne már, lehetne megint magyar számítógép a magyar gyerekeknek (még csak ötletelés szintjén áll a dolog). Szoftveresen már minden adott hozzá, csak a hardverrel vagyok bajban.

A napokban egy olyan érdekes C fordító forrása került fel a GitHub-ra, ami egy szokatlan sajátosságával emelkedik ki a szóban forgó nyelvhez készült kompilerek végtelen sorából. A SectorC különlegességét ugyanis nem az adja, hogy minden másik társánál gyorsabb kódot generál vagy hogy a legújabb nyelvi sajátosságokat is támogatja, hanem az, hogy simán elfér egy rendszerbetöltő szektorban is - ugyanis 512 bájtban is elfér.

https://xorvoid.com/sectorc.html

https://github.com/xorvoid/sectorc

Forrás:
https://prog.hu/hirek/6475/sectorc-boot-sector-c-fordito-compiler-512-bajt-kicsi

Sziasztok,

ESP32 mikrokontrollerre szeretnék egy (általános) fejlesztői környezetet írni, amiben már kész vannak az alap dolgok, utána csak az üzleti logikával kéne foglalkozni. Az alapok megvannak, már működik, de szeretném fejleszteni. Ehhez tartozik egy webes felület is. Korábban ez "kézzel írt" html és javascript volt, ami fájlonként volt 7-10 kb. Pl ez: https://github.com/redakker/blecker/tree/main/html
Ahhoz, hogy egységesebb legyen gondoltam választok egy javascrip framework-öt, így jutottam el a Svelte-ig, ami az egész mindenséget bele tudja fordítani egy darab html fájlba. Így a kiszolgálás is egyszerűsödik, de a fájl 100kb-osra nőtt.

Tehát a probléma: Az ESP-nek 100kb kiszolgálása már nehézséget okoz. EspAsyncWebserver library-t használnék.
Kérdés: Mit lehet ez ügyben tenni?

Sajnos a C++ ismereteim még nem elegek ennek a problémának a megoldásához, ezért kérek segítséget.
Kérdeztem a chatGPT-t is, de nem voltam vele sikeres.

Tehát van egy PROGMEM változóm, ami be a build során bekerül a HTML kód.
 

const char data_index_html[] PROGMEM = R"=====(
<!DOCTYPE HTML><html>
...
nagyon szép admin oldal, html, javascript, css
...
</html>
)=====";

Az egészet szeretném egy objektumba zárni:

#include <ESPAsyncWebServer.h>

class WebServer {
  public:
    WebServer(int port) : server(port) {}

    void begin() {
      server.on("/", HTTP_GET, [this](AsyncWebServerRequest *request){
        handleRoot(request);
      });
      
      server.begin();
    }

  private:
    AsyncWebServer server;

    void handleRoot(AsyncWebServerRequest *request) {
      String response = data_index_html;
      request->send(200, "text/html", response);
    }

   
};

És üres lapot kapok. Valószínűleg memória gondok lesznek. Próbáltam feldarabolni és streamként küldeni, de nem sikerült (nem az elv miatt).

Szóval tudna valaki támpontokat, esetleg kódrészletet írni, hogy merre induljak?

Köszönöm!

Üdv: redman

Sziasztok!

Tud erre valaki magyarázatot adni, miért csak 15 hosszú lehet az interface név?

   Linux define value in /usr/include/linux/if.h.
   #define IFNAMSIZ        16
   FreeBSD define value in /usr/include/net/if.h.
   #define IFNAMSIZ        16

C++-ban kellene kódot írnom (hobby), de még a C sem az erősségem.

Próbálom megérteni, hogy elméleti alapon miért rossz a C++ következő kód:

const char* fix_string = "FIX STRING";
char* szoveg = fix_string;

Nem értem, hibás ez? Amit mondani akarok vele, hogy van egy szöveges konstansom, ami sohasem változhat, és van egy másik szöveges változóm, ami felvehet tetszőleges értéket, például a fix értéket is.

Hol rontom el a gondolatmenetemet?

Az uno2iec projectet próbálom életre lehelni. Ebben egy Arduino Nano kommunikálna a PC-n egy QtCreator-ban készült cpp kóddal.

Sajnos a kód nem működik megfelelően, de még a hibát sem tudom megkeresni, mivel a cpp kód indítása után egy kis idő elteltével eltűnik a /dev/ttyUSB0 eszköz. Ilyenkor hiába húzom ki, és dugom be újra, a /dev/ttyUSB* nem lesz többé. Az újraindítás után minden rendben működik.

A cpp kód normál felhasználó nevében fut, de a felhasználónak joga van használni a soros portot. Így gondolom elrontani is joga van.

A kérdésem: hogyan lehet annyira elrontani a soros port kezelését, hogy tönkrevágja az új eszközök felismerését, és mit lehet ilyenkor kezdeni az újraindításon kívül az USB-vel, hogy újra működjön?

Sziasztok, Android source build-hez ért valaki?

 

Emulátor környezetben szeretnék tesztelni egy EVS_APP nevű programot, ami egy native app és az Android source code-jának a része a packages folderben:

https://cs.android.com/android/plat...r:packages/services/Car/cpp/evs/apps/default/

Sajnos rengeteg belső libet használ, ezért csak a teljes forrás részeként fordítható.

Ez egy automotive alkalmazás. Nagy nehezen találtam egy lunch target-et, amivel elindult egy Automotive emulátor: sdk_car_x86_64

 

Viszont fogalmam sincs, hogyan lehetne ezt (és dependenciáit) hozzáadni a buildhez. 

Ha valakinek van ötlete, szívesen fogadom. 

Üdv!

 

Miért van az, hogy az alábbi kódban a T template paramétert nem bírja kitalálni a compiler (g++):

#include<iostream>
#include<iomanip>

#include<boost/numeric/ublas/vector.hpp>
#include<boost/numeric/ublas/io.hpp>

template<typename T, size_t n> boost::numeric::ublas::vector<T> vecFromArray(const std::array<T, n> x){
  boost::numeric::ublas::vector<T> retVal(n);
  std::copy(x.begin(), x.end(), retVal.begin());
  return retVal;
}

int main(){
  boost::numeric::ublas::vector a = vecFromArray({0.0, 1.0, 2.0});
  std::cout << a << std::endl;
  return 0;
}

és szájba kell rágni neki úgy, hogy

  boost::numeric::ublas::vector a = vecFromArray<double, 3>({0.0, 1.0, 2.0});

ami persze nem jó, mert neked kell odafigyelned, hogy a szám és a lista hossza stimmeljen. (Nyilván meg lehet oldani, ha az ember ír egy ilyen függvényt külön, ami eleve egy std::initializer_list-et kap, de most nem ez a kérdés. Meg akkor, ha mind a kettő kell, akkor duplikálva van egy kis kód.)

 

 

Szerk.: kódismétlés nélkül megoldható, de azért érdekelne a válasz az előzőre:

#include<iostream>
#include<iomanip>
#include<initializer_list>

#include<boost/numeric/ublas/vector.hpp>
#include<boost/numeric/ublas/io.hpp>

template<class T1, class T2> T2 vectorConvert(const T1 &x){
  T2 convertedVector(x.size());
  std::copy(x.begin(), x.end(), convertedVector.begin());
  return convertedVector;
}


int main(){
  auto a = vectorConvert<std::initializer_list<double>, boost::numeric::ublas::vector<double> >({0.0, 1.0, 2.0});
  std::cout << a << std::endl;
  return 0;
}

Sziasztok!

Egy erdekes problema jott szembe most. Van egy ARMv6 Cortex-M0 mikrokontrollerre szant program, ami kb ezt csinalja tobbek kozott:

main()
{
// ...
 while ( 1 )
  {  // ... 
     if ( whatever )
      {    call_something_that_prints_the_stack_pointer();
      }
     // ...
     if ( something_totally_unrelated )
      {    uint8_t array[256];
           do_something_with_array(array);
      }
     // ...
  };
}

Namost, azt tapasztaltam hogy a call_something_that_prints_the_stack_pointer() altal kiirt ertek, meg ugy altalaban a stack fogyasztasa (itt ebben a peldaban) hatarozottan fugg az array[] meretetol. Ha azt kisebbre veszem, pl 128-ra, akkor a stack pointer kiirt erteke 128-cal nagyobb lesz. Most gondolnank hogy "igen, ez logikus". Dehat ugye nem az. Kis utanajarassal eljutottam ide, es ezalapjan... hat, igen, ezalapjan is nagyon ugy nez ki hogy nem kene fuggnie mert az array[] az elegge local, es ezt a fordito szereti romma optimalizani (es aki dangling pointereket csinal, az nyilvan igy jart es jarjon is igy). 

Kiprobaltam mas reszleteiben is a programot, valahol azert jol mukodik ez, szoval abszolut nem altalanos. Node mivel mikrokontroller, ezert minden RAM szamit, plane igy, hogy egy ilyen nagyon local scope local scopejaban levo valami miert is fogyasszon barmit... Es hat ugy is tunt fel hogy 1-2 plusz featura hozzaadasa utan osszeert a statikus terulet (data, bss) a stack-kel, es akkor jott a karorakutya, stb :) Raadasul libc-heap nincs is, csak egyedi allokatorok. 

Latott barki mar barmi hasonlo ilyesmit? Nyilvan ez inkabb beagyazott tema, nem klasszik C, de akkoris erdekes... van-e valami mod pl az arm-none-eabi-gcc hasznalataban ahol ezt le tudom debuggolni? Nyilvan automatikus valtozoknak nincsen memoriaterkepe, max frame pointer-hez viszonyitott, de ARM-nel meg kulon frame pointer se nagyon kell mert sp-relativ cimzesu az utasitaskeszlet (LDR*, STR*). Ami meg meginkabb erdekesse teszi ezt a kerdest szerintem...

Thx, A.

Sziasztok,

Adott 2 process (a,b) akik egy siman tcp socketen tartják a kapcsolatot. B processnek van egy openssl/boost::asio listen portja, ahol varja a bejovo kapcsolatokat majd megcsinalja a tls handshaket. Ha ez meg van, szeretnem atadni az A process-nek az ssl sessiont. Maga a tcp layeren levo socket file descriptor atadasa mar megoldott, az mukodik, de a session atadassal gondjaim vannak. Elvileg a i2d_ssl_session/d2i_ssl_session-al serializalhato a teljes session context, de  egyelore hibat dob ha az atadott ssl socketen megprobalom folytatni a kommunikaciot.

Foglalkozott mar valaki hasonloval?