|
1. I run Ubuntu in a VM. A lot of people don't like it - heck I don't like it (but then I don't like any distro except ArchLinux which isn't usable as a primary desktop OS), but it has the largest userbase of any distro so when there are inevitably problems there's a lot more solutions to search for Ubuntu than say Debian. These days I prefer using MiniGW and using GCC that way without running it on Linux at all when I'm on a windows OS.
2. See 1
3. VS Code. It is simply better than anything else I've used, including for the most part, Visual Studio
4. See 1
5. Both. My code compiles with both or I change it until it does - and i always use the -std=C++XX options. Always.
6. I debug using GDB by way of VS Code's integrated debugger UI
7. VS Code
8. Hmmmm. Don't use VirtualBox - its USB device mapping has been dodgy for me. It can be hard to find a download link from the main site but google "VMWare Player" and download that.
Real programmers use butterflies
|
|
|
|
|
I've never done anything crazy in it but I use VirtualBox with Debian for some linux stuff. Aside from some of the convenience options sometimes bugging out (like cut/paste between VM and host) it's been pretty solid. You HAVE to install the Guest Additions though - lots of QoL improvements. Ubuntu didn't run the best on it for me but that also might be my setup because I know it has for others.
I'll have to check out VMWare Player though. Maybe I just don't know what I'm missing 
|
|
|
|
|
I just know I had issues with it capturing USB devices. The devices would capture but then they would come back with some kind of failure whenever I tried to access them - except once in a blue moon they would magically work.
Real programmers use butterflies
|
|
|
|
|
The only useful thing I found when I searched was this but I've really only ever used basic keyboard and mouse so never had to worry about those things. Does seem like a recurring issue though.
|
|
|
|
|
It's been five years, but I found VirtualBox better for running Linux and VMWare better for running Windows.
(And I found both problematic with USB so never bothered.)
|
|
|
|
|
1. Ubuntu
2. WSL
3. VSCode
4. g++ in Linux
5. see 4.
6. Current apps are not big enough to need debugging. But I have used with gdb quite extensively in the past.
7. Never used github.
8. Children and animals.
|
|
|
|
|
I can see the irony of this question.The desk would be a better place to bang your head when you start..
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
1. Ubuntu
2. WSL
3. Alternate between Notepad++/VSCode/VS2019.
4. Most of the time I build/debug in VS2019. Than makefiles/g++/gdb for platform specific issues.
5. g++
6. See 4 above. I find VS2019 a class above other environments and I go to gdb only for specific issues.
7. TortoiseGit is my friend. Occasionally using VS plugin.
8. Spending too much time in front of your screen. They say it's bad for your eyes. 
Mircea
|
|
|
|
|
I have Ubuntu as main OS of my notebook and use Windows inside a Virtualbox VM.
1) Ubuntu
2) Linux as main OS, Windows in a VM
3) QtCreator
4) build within QtCreator (cmake / qmake)
5) both gcc and clang (MinGW and occasionally VS on windows)
6) Inside QtCreator using gdb
7) within QtCreator or with git cli (remotes on gitlab)
8) my personal feeling.... Windows 
Main thing here is that in my personal opinion QtCreator is *much* better than VSCode for C++ development (unfortunately I have to use VSCode for other non C++ projects and I find it quite messy and chaotic).
modified 20-May-21 3:32am.
|
|
|
|
|
i vote for qtcreator, too. qt is super frickin great imho.
i'm just like you except my flavor is kubuntu. just ubuntu w kde instead o gnome.
|
|
|
|
|
 Greg Utas wrote:
Which Linux do you run? Debian? Ubuntu? RedHat?Ubuntu on 20.04 LTS on WSL2 using Windows 10 Pro insider ed. 21H2 Build 21382.1000 (Yes, I couldn't resist testing WSL with "native" graphics)
How do you run it on your Windows machine? In a VM? If so, which one? Or using WSL?Lastest WSL 2 based on MS' Mariner distro
How do you edit? VS2017? VS2019? VS Code? vi? VS Code, absolutely! Of course with all the extensions required for editing, building, and debugging C ++ applications.
How do you build? Within Linux? From within VS?[^]I personally use VS Code with the GUI running on Windows and connected remotely to WSL. With the extension for VS Code that supports CMAKE you can easily and conveniently use VS Code on Windows to develop and debug both graphical and console applications on Linux. Note: it does not cross-compile on Windows for Linux; it uses the Linux toolchains on Linux but from an IDE on Windows (i.e. VS Code). It is also very advisable to use Windows Terminal to open WSL console sessions or to connect to Linux with ssh as well.
Which compiler do you use? g++? clang?Both gcc (lastest, g++-11) and clang-12 (experimental).
How do you debug? Within Linux? If so, which debugger? Or remotely, from within VS?gdb, lldb, With VS Code.
How do you interface to GitHub? Within Linux? Using the VS plug-in?With git (command line, i.e. bash).
What should be avoided?I had a lot of difficulties using wxWidgets due to binary incompatibility between libraries of different versions. Furthermore, many applications installed with apt also suffer from the above problem. Anyway, I have tested qtcreator (qt5) and it works fine. I also used glade to design a small GUI for gtk and linked it to a C++ project (g ++) I also tested it with rustc.
Extensions I've installed in VS Code to write Linux programs are:
C/C++ IntelliSense, debugging, and code browsing. (ms-vscode.cpptools)C/C++ Extension Pack (ms-vscode.cpptools-extension-pack)C++ Intellisense (austin.code-gnu-global)CMake (twxs.cmake)CMake Tools (ms-vscode.cmake-tools)Regards.
modified 20-May-21 4:28am.
|
|
|
|
|
- Ubuntu 18.04, using a mix of the
apt and nix package managers (apt because it's the standard Ubuntu one, nix where I want newer versions of tools like CMake and ninja than are offered by apt in 18.04). - WSL1 (I don't use WSL2 because I want to work on a Windows filesystem, and WSL1 is better in that scenario).
- VSCode running under Windows (possibly using the Remote extension, but with WSL, VSCode doesn't necessarily need that).
- I do builds using a WSL bash prompt running in VSCode's integrated terminal. However - you can run a WSL command-line from a CMD or Powershell prompt too. I actually perform Linux and Windows builds from WSL bash. VSCode's 'tasks' can be used to do the builds as well.
I use CMake and ninja to perform builds - I find CMake the simplest way to have a single cross-platform build description. - On Windows, MSVC. On Linux, I build with g++ but use clang's static analysis tools (
clang-tidy primarily). oh - unless I'm doing a fuzzing build, when I use clang and libfuzzer. - I use VSCode for all debugging. It integrates with the native debugger that (I guess) Visual Studio uses, and for WSL, it fires up a gdb running under a WSL process and automates it using GDB's 'machine interface'.
- I use command-line Git (usually the Linux version, but if I use
git.exe at the command prompt rather than git, I'm using Windows native Git rather than Linux Git) and also GitKraken running under Windows. The only concessions I make to Windows are some git config settings: core.filemode is set to false and core.ignorecase to true. - Can't remember anything offhand...
I've been working like this very happily since 2018, doing Windows and Linux builds in tandem. The way I work is to develop under Windows primarily, then when I reach some significant point build under Linux (with static analysis) and run unit tests to ensure that I have parity between platforms.
I have some projects with Windows-only features - I find that's easy enough to do with CMake.
The only time I break out Visual Studio is if I need disassembly level debugging - one of the projects I work on has a JIT compiler, and debugging the JITted code needs that really. Aside from that, I often find myself developing small, self-contained features in Compiler Explorer, as that makes it easy to use libraries I often use (fmt, MS-GSL, Catch2) in a single source file without needing any build system.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
modified 20-May-21 9:18am.
|
|
|
|
|
For five year I used to develop in C++ on Windows for both Windows and Linux.
In the beginning I try to use Visual Studio solution for cross platform and failed miserably; on all VS versions 2015, 2017, 2019... Too many problems when projects grows. 
Another problem I had was to have to "program" the build on Linux using Make, CMake ...
I don't want to "program" the build, for me, basically, build a C/C++ project is just a matter to make a long command line.
From one year being fully on home office I completely abandoned Windows and now work fully on Linux (Debian 10), but need to build my projects on Windows too.
So I adopted VSCodium as my main editor and construc a mini build system (CPPMagic) that meet my needs, fully in Python. With this I can build on both Windows and Linux the same way (no need even an editor).
1. Debian 10;
2. I use 2 phisical machines;
3. VSCodium;
4. CPPMagic (CppMagic: A Python 3 script to help build C/C++ projects cross-platform.[^]);
5. GCC and MSVC;
6. GDB on Linux and MSVC on Windows;
7. Command line;
8. I personally don't like to use complex building systems and whenever I can use static libraries.
I don't clame that my build system is a final solution, it still raw, and I evolve just for my needs, but it works.
|
|
|
|
|
You are asking some great questions here!
1. Ubuntu distro, typically later than 16.
2. I do development using an Oracle VirtualBox VM running on Windows 10. I like the ability to manage separate VMs for separate development environments and always save both an "O/S only" VM as well as a "O/S + development tools" VM. I usually do full clones of the "O/S only" for build and deployment testing and use the "O/S + development tools" to create new development environments for separate projects. Full clones eat disk space like nobody's business, so you need a good hunk of disk storage.
3. I use...wait for it...Eclipse for editing and the GUI debugger (which is just a GUI riding on top of gdb). I often hear bad things said about Eclipse, and I have to agree, some of them are justified, but I like the things an IDE has to offer even though Eclipse ain't great like GUI debugging, the code indexer so you can right click on a variable or method and it will take you there, etc. It often takes a while to get Eclipse configured to do builds and debug (in both C++ as well as mixed C++/Python where Python is the typical entry point) and can be frustrating. I've had a lot of issues with the indexer picking up dependencies.
4. My build model typically consists of cmake with hierarchical CMakeLists.txt files. cmake has a generator that can produce eclipse project files via the -G"Eclipse CDT4 - Unix Makefiles" option, which is handy and seems to work pretty well, but honestly haven't tried it on the latest versions of Eclipse. One key thing you have to account for is that the generator (at least in the past) doesn't like a folder structure that stores build files in a subfolder lower in the directory hierarchy, e.g. doesn't like ~/username/MyProjects/SoftwareProjectA/build, so you have to get cmake to create the top-level Makefile directly in the top-level of the source tree, i.e. ~/username/MyProjects/SoftwareProjectA. This will allow you to debug your code using the Eclipse GUI front-end to gdb.
5. g++. Basically, go to source tree and run "cmake -G"Eclipse CDT4 - Unix Makefiles" -DENABLE_DOXYGEN=$BUILDDOCS -DCMAKE_BUILD_TYPE=<release debug="" relwithdebinfo="" etc.=""> -DCMAKE_INSTALL_PREFIX=<your prefix="" folder=""> .", then run "make -j4 install".
6. I typically use the Eclipse GUI-based gdb debugger, but this can be tricky to set up sometimes, but worth it.
7. Interface to github is usually done through Linux command-line "git".
8. Playing poker with anyone whose first name is preceded by a city, e.g. "Minnesota Jim", "Vegas Dave". Also, bears.
|
|
|
|
|
When I did Linux development, I preferred using Fedora in a VirtualBox VM. I vastly preferred using CLion as my IDE (though used Eclipse for one job. I shudder.)
When I first started Linux development, both GCC and Clang were stalled. GCC got it's act together. It took a while for Clang to do so. Yet, as they did, I found their response to well documented bugs severely lacking to the point where I still don't trust them.
|
|
|
|
|
1. Anything Debian-based can be considered a "typical" Linux
2. WSL when you don't need X11 or Wayland or specific device drivers, VM when you do
3. VS Code if you just want to get the job done, Visual Studio if you prefer IntelliSense
4. using the Clang support in VS Code or Clang support in Visual Studio
5. Clang
6. Waiting for debugger support in WSL, I just build for Windows and debug that instead. YYMV
7. VS plugin because it's easy to use, does everything, and prevents me from making typo's
|
|
|
|
|
Twitter = Sing
Revealed ? = let on
Pattern = Singleton
OG actually got it in another thread but didn't mention the actual word - he said lonesome heavyweight
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
modified 19-May-21 10:09am.
|
|
|
|
|
That's because I couldn't justify it - I had Singleton, but no reason why ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That would have been worth a shot in my book
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
Yeah, but I had just done three in a row and wanted to give others a chance.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
True
"I didn't mention the bats - he'd see them soon enough" - Hunter S Thompson - RIP
|
|
|
|
|
OriginalGriff wrote: wanted to give others a chance.
It seems we needed much more than just a chance
|
|
|
|
|
Does anyone here know of a very good article that can get someone started with writing automated unit tests for an ASP.NET web forms application (C#) using selenium?
Their documentation seems to be throwing me in different places.
|
|
|
|
|
For my sins, I am Secretary of a cricket club.
Having some spare time today, I decided I could no longer put off reading the latest Covid-safety info from the governing body, just to make sure we have every safety measure in place.
So, the main page lists 7 documents to read. I open the first one. It is 31 pages long. It contains links to 71 other documents and, from experience, I would guess that on average they all contain links to 10 more documents, and so on.
That was just one out of 7 "top level" documents. I haven't opened the rest.
So, officials are covering their a***es by claiming you've been given all the information whilst no sane human being could possibly read it all let alone take it all in. I'm guessing someone gets paid a lot more than I do to waste their time producing this rubbish.
If I was five years younger, I'd probably have decided to write a little program to follow all the links in all the documents and find how how many words you'd have to read to get the full info. Alas, that would probably mean having to read some Microsoft documentation which I suspect would be a circular process - leaving me fuming at that too...
|
|
|
|
|
Rich Leyshon wrote: which I suspect would be a circular process
Oh pretty much definitely: these people don't like to write their own stuff in case they make an mistake which can be traced back to them. Hence they quote and reference each others documents in the certain knowledge that you won't find an original thought in any of them ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
