Forum Mjukvara Programmering och digitalt skapande Tråd Inlägg

MinGW för Visual Studio Community - C++ saknar variabeldefinierade arrayer

1 2 3
Skriv svar
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Qt Creator gillar jag faktiskt. Dock så passar inte ImGui med QtCreator.

Gå till inlägget

Hm, så länge du har en fungerande CMake-konfiguration borde det fungera bra att öppna i Qt Creator. Den är förstås extra anpassad för att integrera bra med Qt, men den fungerar lika bra med projekt utan Qt.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Nu har jag fått bort alla errors.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Nu har jag bara två error kvar 

C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src\Hardware\USB\USBHandler.o: in function `boost::asio::detail::winsock_init_base::startup(boost::asio::detail::winsock_init_base::data&, unsigned char, unsigned char)':
C:/vcpkg/installed/x64-mingw-dynamic/include/boost/asio/detail/impl/winsock_init.ipp:39: undefined reference to `__imp_WSAStartup'
C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: src\Hardware\USB\USBHandler.o: in function `boost::asio::detail::winsock_init_base::cleanup(boost::asio::detail::winsock_init_base::data&)':
C:/vcpkg/installed/x64-mingw-dynamic/include/boost/asio/detail/impl/winsock_init.ipp:56: undefined reference to `__imp_WSACleanup'

Vad ska man använda nu för flagga? Jag har installerat Boost Asio.

Gå till inlägget

Troligen är det ws2_32.lib som krävs. Det borde räcka med att lägga till
-lws2_32

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

Troligen är det ws2_32.lib som krävs. Det borde räcka med att lägga till
-lws2_32

Gå till inlägget

Japp. Jag lade till den som du ser ovan. Det fungerar, men nu har jag ett annat problem.
Det är att när jag startar min applikation så får jag detta nummer. Detta betyder att något med dynamisk minnesallokering inte riktigt fungerade korrekt.

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Japp. Jag lade till den som du ser ovan. Det fungerar, men nu har jag ett annat problem.
Det är att när jag startar min applikation så får jag detta nummer. Detta betyder att något med dynamisk minnesallokering inte riktigt fungerade korrekt.

https://www.bildtagg.se/file/32tz70enawthqbdhbhs2un

Gå till inlägget

Är det någon särskild rad den kraschar på?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

Är det någon särskild rad den kraschar på?

Gå till inlägget

Egentligen inte. Den bara säger detta när jag kör debug-mode.

Error in final launch sequence:

Failed to execute MI command:
-exec-run
Error message from debugger back end:
During startup program exited with code 0xc0000135.
Failed to execute MI command:
-exec-run
Error message from debugger back end:
During startup program exited with code 0xc0000135.
During startup program exited with code 0xc0000135.

Troligtvis så har jag glömt att importera .dll filerna för MariaDB.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Datavetare ★
●

Har aldrig använt vcpkg, men läser man deras "Get started with vcpkg" verkar verkar det som om man måste bestämma sig om man vill köra med Visual Studio integration (i det läget ska man normal INTE blanda in CMake) eller så kan man använda CMake.

Om man väljer att använda CMake måste man sätta upp sina projekt så att de är medvetna om vcpkg. Har man installerat vcpkg i katalogen "$HOME/vcpkg" måste man då göra detta vid setup av projektet

$ cd MITT_CMAKE_PROJ
$ cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=$HOME/vcpkg/scripts/buildsystems/vcpkg.cmake

Vidare får man ju tips från vcpkg kring vad man ska lägga till CMakeLists.txt om man vill använda en vcpkg hanterat bibliotek. T.ex. detta

./vcpkg install imgui  
Computing installation plan...
The following packages will be built and installed:
    imgui[core]:arm64-osx -> 1.88#1
Detecting compiler hash for triplet arm64-osx...
Restored 0 package(s) from /Users/kjn/.cache/vcpkg/archives in 12.5 us. Use --debug to see more details.
Installing 1/1 imgui:arm64-osx...
Building imgui[core]:arm64-osx...
warning: -- Using community triplet arm64-osx. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: /Users/kjn/cxx/vcpkg/triplets/community/arm64-osx.cmake
-- Downloading https://github.com/ocornut/imgui/archive/v1.88.tar.gz -> ocornut-imgui-v1.88.tar.gz...
-- Extracting source /Users/kjn/cxx/vcpkg/downloads/ocornut-imgui-v1.88.tar.gz
-- Using source at /Users/kjn/cxx/vcpkg/buildtrees/imgui/src/v1.88-34c93572a3.clean
-- Configuring arm64-osx
-- Building arm64-osx-dbg
-- Building arm64-osx-rel
-- Installing: /Users/kjn/cxx/vcpkg/packages/imgui_arm64-osx/share/imgui/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "/Users/kjn/.cache/vcpkg/archives/2e/2e130b2bb57b5bf97e3d7f70c79820d9dd8af76f8419d15a022a35e4a61bdc9d.zip"
Elapsed time to handle imgui:arm64-osx: 4.382 s
Total install time: 6.508 s
imgui provides CMake targets:

    # this is heuristically generated, and may not be correct
    find_package(imgui CONFIG REQUIRED)
    target_link_libraries(main PRIVATE imgui::imgui)

Kör du däremot Visual Studio ska du normalt inte blanda in CMake, utan då ska du köra den här delen från "Get started with vcpkg"

Using vcpkg with MSBuild / Visual Studio (may require elevation)
vcpkg integrate install

Står ju att Visual Studio i det läget blir uppsatt så den automatiskt hittar bibliotek installerad med vcpkg

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Har aldrig använt vcpkg, men läser man deras "Get started with vcpkg" verkar verkar det som om man måste bestämma sig om man vill köra med Visual Studio integration (i det läget ska man normal INTE blanda in CMake) eller så kan man använda CMake.

Om man väljer att använda CMake måste man sätta upp sina projekt så att de är medvetna om vcpkg. Har man installerat vcpkg i katalogen "$HOME/vcpkg" måste man då göra detta vid setup av projektet

$ cd MITT_CMAKE_PROJ
$ cmake -B build -S . -DCMAKE_TOOLCHAIN_FILE=$HOME/vcpkg/scripts/buildsystems/vcpkg.cmake

Vidare får man ju tips från vcpkg kring vad man ska lägga till CMakeLists.txt om man vill använda en vcpkg hanterat bibliotek. T.ex. detta

./vcpkg install imgui  
Computing installation plan...
The following packages will be built and installed:
    imgui[core]:arm64-osx -> 1.88#1
Detecting compiler hash for triplet arm64-osx...
Restored 0 package(s) from /Users/kjn/.cache/vcpkg/archives in 12.5 us. Use --debug to see more details.
Installing 1/1 imgui:arm64-osx...
Building imgui[core]:arm64-osx...
warning: -- Using community triplet arm64-osx. This triplet configuration is not guaranteed to succeed.
-- [COMMUNITY] Loading triplet configuration from: /Users/kjn/cxx/vcpkg/triplets/community/arm64-osx.cmake
-- Downloading https://github.com/ocornut/imgui/archive/v1.88.tar.gz -> ocornut-imgui-v1.88.tar.gz...
-- Extracting source /Users/kjn/cxx/vcpkg/downloads/ocornut-imgui-v1.88.tar.gz
-- Using source at /Users/kjn/cxx/vcpkg/buildtrees/imgui/src/v1.88-34c93572a3.clean
-- Configuring arm64-osx
-- Building arm64-osx-dbg
-- Building arm64-osx-rel
-- Installing: /Users/kjn/cxx/vcpkg/packages/imgui_arm64-osx/share/imgui/copyright
-- Performing post-build validation
-- Performing post-build validation done
Stored binary cache: "/Users/kjn/.cache/vcpkg/archives/2e/2e130b2bb57b5bf97e3d7f70c79820d9dd8af76f8419d15a022a35e4a61bdc9d.zip"
Elapsed time to handle imgui:arm64-osx: 4.382 s
Total install time: 6.508 s
imgui provides CMake targets:

    # this is heuristically generated, and may not be correct
    find_package(imgui CONFIG REQUIRED)
    target_link_libraries(main PRIVATE imgui::imgui)

Kör du däremot Visual Studio ska du normalt inte blanda in CMake, utan då ska du köra den här delen från "Get started with vcpkg"

Using vcpkg with MSBuild / Visual Studio (may require elevation)
vcpkg integrate install

Står ju att Visual Studio i det läget blir uppsatt så den automatiskt hittar bibliotek installerad med vcpkg

Gå till inlägget

Jo, jag vet att Vcpkg är konfigurerat med visual studio. Orsaken varför jag brottas med detta är för att jag vill använda VLA ( Variable Length Arrays) och det stöds inte i MSVC, utan bara i MinGW. Det är tydligen ett litet "hack" från GCC för att undvika dynamisk minnesallokering tror jag.

Så därför bytte jag kompilator, vilket betydde att jag fick byta IDE också. Sedan har det bara gått utför.
Just nu sitter jag och väger mellan att fortsätta med MinGW och CDT eller MSVC och MSBuild. Vcpkg hade nämligen problem att kompilera med MinGW då vissa paket var "använd på egen risk".

Vad tycker du att jag ska göra?

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●

@heretic16
Ett alternativ är väl att ge upp och använda något annat (vector, dynamisk allokering, stor fast storlek eller liknade)? Är det verkligen en kritisk finess?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

@heretic16
Ett alternativ är väl att ge upp och använda något annat (vector, dynamisk allokering, stor fast storlek eller liknade)? Är det verkligen en kritisk finess?

Gå till inlägget

Egentligen inte.
Jag kan använda malloc, men då dynamiskt minnesallokerar jag. Vilket jag vill undvika till högsta pris.

Eller om du kan hjälpa mig med ett Hello World med CMake för Eclipse så ska jag ge CMake en sista chans.
Det första jag får när jag skapar ett CMake-projekt är att den hittar inte min kompilator.

Min CMakeLists.txt ser ut så här

cmake_minimum_required (VERSION 2.6)

project (HelloWorld)

add_executable(HelloWorld HelloWorld.cpp)
Senast redigerat
Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Egentligen inte.
Jag kan använda malloc, men då dynamiskt minnesallokerar jag. Vilket jag vill undvika till högsta pris.

Gå till inlägget

Är det så farligt då? En vector gör ju allt åt dig, och i praktiken är det väl sällan man märker någon skillnad i prestanda?

Skrivet av heretic16:

Eller om du kan hjälpa mig med ett Hello World med CMake för Eclipse så ska jag ge CMake en sista chans.
Det första jag får när jag skapar ett CMake-projekt är att den hittar inte min kompilator.

https://www.bildtagg.se/file/7d3tpzau3yysb4cfu8334o0

Gå till inlägget

Fick du det inte att fungera för en stund sedan (bortsett från kraschen)?

Att få igång visual studio med clang borde inte heller vara så svårt.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

Är det så farligt då? En vector gör ju allt åt dig, och i praktiken är det väl sällan man märker någon skillnad i prestanda?

Gå till inlägget

Ja, speciellt när dynamisk minnesallokering är förbjudet
I C programmering använder jag aldrig malloc.

Citat:

Fick du det inte att fungera för en stund sedan (bortsett från kraschen)?

Att få igång visual studio med clang borde inte heller vara så svårt.

Nej. Jag fick bort felmeddelanden.
Som jag har uppfattat så är det mycket manuellt skrivande när det kommer till att bygga upp CMakeLists.txt.

Jag kan ju testa med Clang för Vcpkg.

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Ja, speciellt när dynamisk minnesallokering är förbjudet
I C programmering använder jag aldrig malloc.

Gå till inlägget

För inbyggda system och liknade kan det vara vettigt, men man begränsar sig ju rätt kraftigt (även i c) om man aldrig får använda mer minne än stacken? Blir det aldrig problem?

Skrivet av heretic16:

Nej. Jag fick bort felmeddelanden.
Som jag har uppfattat så är det mycket manuellt skrivande när det kommer till att bygga upp CMakeLists.txt.

Gå till inlägget

Visst skrivande blir det, men mycket är ungefär samma varje gång. Det gäller även att peka ut allt (som kompilatorn) rätt.

Om du har Qt Creator installerat med mingw-kompilator är det bara att skapa ett cmake-projekt för att få en fungerande Hello World.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

För inbyggda system och liknade kan det vara vettigt, men man begränsar sig ju rätt kraftigt (även i c) om man aldrig får använda mer minne än stacken? Blir det aldrig problem?
Visst skrivande blir det, men mycket är ungefär samma varje gång. Det gäller även att peka ut allt (som kompilatorn) rätt.

Om du har Qt Creator installerat med mingw-kompilator är det bara att skapa ett cmake-projekt för att få en fungerande Hello World.

Gå till inlägget

Jag har skrivit bibliotek i C för inbyggda system och där använder jag arrayer som sin storlek deklareras av variabler.
Problemet är att använda stacken är att den slits med tiden. Det tar dock år, men det går fortare än vad man tror.

Qt Creator är bra, men jag var inte helt nöjd med den. Framförallt strukturen på projektet var inte lika smidigt som i Eclipse/Visual Studio. Qt Creator dock skapade CMake projektet hur fint som helst. Man behövte inte ens tänka.

Men att använda Qt Creator för att skapa ett CMake-projekt känns lite brutalt enligt mig.
Du ser mitt exempel ovan, där jag har fel på min C++ kod. Jag vet inte hur jag åtgärdar detta problem och det verkar som att flera hundra har samma problem på StackOverflow.

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Men att använda Qt Creator för att skapa ett CMake-projekt känns lite brutalt enligt mig.
Du ser mitt exempel ovan, där jag har fel på min C++ kod. Jag vet inte hur jag åtgärdar detta problem och det verkar som att flera hundra har samma problem på StackOverflow.

Gå till inlägget

Det är väl inte brutalare än att använda eclipse eller visual studio?
Du har troligen inget direkt fel i koden, men cmake måste kanske till exempel instrueras var den ska hitta kompilatorn. Qt Creator (och säkert andra) sköter allt sådant åt dig.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av heretic16:

Jo, jag vet att Vcpkg är konfigurerat med visual studio. Orsaken varför jag brottas med detta är för att jag vill använda VLA ( Variable Length Arrays) och det stöds inte i MSVC, utan bara i MinGW. Det är tydligen ett litet "hack" från GCC för att undvika dynamisk minnesallokering tror jag.

Så därför bytte jag kompilator, vilket betydde att jag fick byta IDE också. Sedan har det bara gått utför.
Just nu sitter jag och väger mellan att fortsätta med MinGW och CDT eller MSVC och MSBuild. Vcpkg hade nämligen problem att kompilera med MinGW då vissa paket var "använd på egen risk".

Vad tycker du att jag ska göra?

Gå till inlägget

Det "hack" GCC och Clang utnyttjar är att de, till skillnad från MSVC++, stödjer C11 och de tillåter att man använder den funktionen i C++ (vilket egentligen är felaktigt då det inte är del av C++ standarden).

Finns väl två val om du absolut ska använda dynamiska C11 arrayer

1. Använd MinGW (GCC). Då det inte direkt stöds av Visual Studio blir vettigaste vägen att använda vcpkg+CMake. Är fullt möjligt att sedan använda ett CMake projekt både i VS, Eclipse (hur någon frivilligt vill använda Eclipse för C++ är över mitt förstånd, men inte mitt val här ) eller VS Code

2. Använd Clang och sätt det som kompilatorn i Visual Studio som beskrivs här. I det läget kör du med Visual Studios "normala" integration av vcpkg, d.v.s. inget CMake

Det skrivet: du nämnde mikrokontrollers tidigare. Mikrokontrollers, likt normalt kernel-kod, tenderar ha väldigt lite stack-utrymme så det är en exceptionellt dålig idé att använda dynamiska arrayer allokerade på stacken (vilket är fallet med C11 dynamiska arrayer). Vet du maxstorleken är det bättre att alltid allokera den storleken.

Handlar det verkligen om ett fall där du inte vet maxstorleken i förväg, använd std::vector<>!

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

Det är väl inte brutalare än att använda eclipse eller visual studio?
Du har troligen inget direkt fel i koden, men cmake måste kanske till exempel instrueras var den ska hitta kompilatorn. Qt Creator (och säkert andra) sköter allt sådant åt dig.

Gå till inlägget

Jag tycker det är svårt. Jag har alltid problem när det kommer till IDE och kompilatorer

Men nu fixade jag den där C-koden som hade VLA så den fungerar att kompilera med MSVC. Jag satt bara statiska värden typ #define på vissa arrayer och får acceptera en fast storlek.

Men nu när jag kompilerar så får jag "LNK2019". Orsaken har med att jag bakade in .c kod i mitt C++ projekt. Det var C-koden som var anpassad för C99 och nu anpassade jag den så att den ej använder VLA.

Severity	Code	Description	Project	File	Line	Suppression State
Error	LNK2019	unresolved external symbol "void __cdecl ImGui::SetColumnWidth(int,float)" (?SetColumnWidth@ImGui@@YAXHM@Z) referenced in function "void __cdecl showFileDialog(bool *,char *,unsigned int,enum FileDialogType)" (?showFileDialog@@YAXPEA_NPEADIW4FileDialogType@@@Z)	OpenSourceLogger	C:\Users\dmn\VS\OpenSourceLogger\OpenSourceLogger\FileDialog.obj	1
Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Det "hack" GCC och Clang utnyttjar är att de, till skillnad från MSVC++, stödjer C11 och de tillåter att man använder den funktionen i C++ (vilket egentligen är felaktigt då det inte är del av C++ standarden).

Finns väl två val om du absolut ska använda dynamiska C11 arrayer

1. Använd MinGW (GCC). Då det inte direkt stöds av Visual Studio blir vettigaste vägen att använda vcpkg+CMake. Är fullt möjligt att sedan använda ett CMake projekt både i VS, Eclipse (hur någon frivilligt vill använda Eclipse för C++ är över mitt förstånd, men inte mitt val här ) eller VS Code

2. Använd Clang och sätt det som kompilatorn i Visual Studio som beskrivs här. I det läget kör du med Visual Studios "normala" integration av vcpkg, d.v.s. inget CMake

Det skrivet: du nämnde mikrokontrollers tidigare. Mikrokontrollers, likt normalt kernel-kod, tenderar ha väldigt lite stack-utrymme så det är en exceptionellt dålig idé att använda dynamiska arrayer allokerade på stacken (vilket är fallet med C11 dynamiska arrayer). Vet du maxstorleken är det bättre att alltid allokera den storleken.

Handlar det verkligen om ett fall där du inte vet maxstorleken i förväg, använd std::vector<>!

Gå till inlägget

Exakt. Det är inte en del av C++ standarden, men är det dynamisk minnesallokering, dvs använder den stacken om man använder VLA-arrayer?

Jag vill ju köra så standardiserat som möjligt. Inte hitta på egna lösningar. Vilket jag har försökt i 2 dagar utan att lyckas.
Om vcpkg är konfigurerat bäst för Visual Studio med MSVC så tvingas jag nog köra med det, om jag nu ska använda vcpkg.

Eclipse är riktigt bra. Den har bra stöd för exakt allt.

Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av heretic16:

Egentligen inte.
Jag kan använda malloc, men då dynamiskt minnesallokerar jag. Vilket jag vill undvika till högsta pris.

Eller om du kan hjälpa mig med ett Hello World med CMake för Eclipse så ska jag ge CMake en sista chans.
Det första jag får när jag skapar ett CMake-projekt är att den hittar inte min kompilator.

https://www.bildtagg.se/file/7d3tpzau3yysb4cfu8334o0

Min CMakeLists.txt ser ut så här

cmake_minimum_required (VERSION 2.6)

project (HelloWorld)

add_executable(HelloWorld HelloWorld.cpp)
Gå till inlägget

För att ovan ska fungera måste du få din IDE att köra CMakes "configure" steg. Har ingen aning om hur det görs i Eclipse, i VS Code (vilket är den editor jag personligen använder för C och C++) gör man så här

Om vi har detta

så är nästa steg att köra configure

det skapar då en "build" katalog

och det är nu möjligt att bygga projektet

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag hade VS Code igår, men tog bort det. Den hittade inte MinGW och jag fick lägga till den helt själv i någon mystisk .json fil.

Jag ska bara lösa detta först.

error LNK2019: unresolved external symbol glfwCreateWindow referenced in function main
Redigera
Citera flera Citera
Permalänk
Datavetare ★
●
Skrivet av heretic16:

Exakt. Det är inte en del av C++ standarden, men är det dynamisk minnesallokering, dvs använder den stacken om man använder VLA-arrayer?

Jag vill ju köra så standardiserat som möjligt. Inte hitta på egna lösningar. Vilket jag har försökt i 2 dagar utan att lyckas.
Om vcpkg är konfigurerat bäst för Visual Studio med MSVC så tvingas jag nog köra med det, om jag nu ska använda vcpkg.

Eclipse är riktigt bra. Den har bra stöd för exakt allt.

Gå till inlägget

Där har du ju svaret på hur du löser detta: kör MSVC++ (om nu det fungerar) då C11 dynamiska arrayer i C++ kontext är inte en standard. Standarden i C++ är std::vector<> alt. std::array<>

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Redigera
Citera flera Citera
Permalänk
Hedersmedlem ★
●
Skrivet av heretic16:

Jag ska bara lösa detta först.

error LNK2019: unresolved external symbol glfwCreateWindow referenced in function main
Gå till inlägget

Nu verkar det som att du inte pekar ut lib-filerna igen (imgui och opengl).

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Elgot:

Nu verkar det som att du inte pekar ut lib-filerna igen (imgui och opengl).

Gå till inlägget

Tror jag har mixtrat nu när jag har hållit på med mingw. Ska installera om vcpkg. Går fort.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Yoshman:

Där har du ju svaret på hur du löser detta: kör MSVC++ (om nu det fungerar) då C11 dynamiska arrayer i C++ kontext är inte en standard. Standarden i C++ är std::vector<> alt. std::array<>

Gå till inlägget

MSVC fungerar. Jag ogillar bara att dom ej har stöd för VLA

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Problemet är att använda stacken är att den slits med tiden. Det tar dock år, men det går fortare än vad man tror.

Gå till inlägget

Kan du utveckla det där?

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av blackcoffee:

Kan du utveckla det där?

Gå till inlägget

Du vet att ett ramminne får man byta ibland efter några år.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Du vet att ett ramminne får man byta ibland efter några år.

Gå till inlägget

Nej.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av blackcoffee:

Nej.

Gå till inlägget

Samma sak gäller USB minnen.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av heretic16:

Samma sak gäller USB minnen.

Gå till inlägget

Nej, inte samma sak.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Du har inte lagt in någon path till biblioteken. Windows/programmet vet helt enkelt vart den ska kika efter körverk och biblioteken. Flaggade för det "problemet" i din tidigare tråd att det inte sker automatiskt.

Du kan givetvis göra precis som när du distribuerar programmet och lägga dessa filer i samma katalog som exekveringsfilen.

Redigera
Citera flera Citera
1 2 3
Skriv svar