|
Putting certifications on your resume is generally considered a negative signal.
|
# ? Jan 6, 2018 06:16 |
|
|
# ? Mar 29, 2024 03:10 |
|
Plorkyeran posted:Putting certifications on your resume is generally considered a negative signal. You mean you wouldn't want to hire a certified C++ GRANDMASTER? (to be fair that course is about writing a C++ compiler, you could literally just throw the code up on github after the certification but I don't know if I'd be impressed or somewhat scared)
|
# ? Jan 6, 2018 15:14 |
|
The Phlegmatist posted:You mean you wouldn't want to hire a certified C++ GRANDMASTER? A C compiler if that actually...
|
# ? Jan 6, 2018 15:23 |
http://sci.tuomastonteri.fi/programming/sse I may have missed it when reading this, but why does he use Mat4x3s in stead of vec4s in his algorithms? It kinda seems suboptimal to not just use the data type that already has the width SIMD wants, and it uses more memory for no reason. He doesn't seem to provide any justification.
|
|
# ? Jan 7, 2018 00:51 |
|
It's addressed in section 4. Essentially, it's four different (x, y, z) tuples, expressing four different points being acted on, in a way that's useful for sse. I would guess that the author doesn't just use a separate vector of xs, a vector of ys, and a vector of zs for pedagogical reasons - conceptually, x1, y1 and z1 are part of the same datum, while x1, x2 etc. are unrelated, and having entirely separate vectors could lead to confusion.
|
# ? Jan 7, 2018 01:05 |
|
Hi will c++ ever collapse std::array and “c” arrays into the same thing? I’ve been using c++ for a very long time so I understand what both options are but it feels like one of them is the correct option while the other is deprecated/incorrect. However, the most useful one is the most verbose. So, what’s the plan for c++ future regarding arrays? I’d love it if [] automatically created a std::array.
|
# ? Jan 7, 2018 23:26 |
I don't think that's their plan? std::array comes with some overhead from its STL interface, but is nice if you want that interface.
|
|
# ? Jan 7, 2018 23:46 |
|
std::array has zero overhead (other than an incredibly trivial hit to compile perf I guess), but no, C++ doesn't make that sort of backwards-incompatible change.
|
# ? Jan 8, 2018 02:03 |
|
I think it will hurt performance if you use it as a drop in replacement if you ever copy them by value and rely on c arrays degrading to pointers in those cases. If you are writing new code, you can explicitly pass references or pointers around when you want them.
|
# ? Jan 8, 2018 03:44 |
|
Jeffrey of YOSPOS posted:I think it will hurt performance if you use it as a drop in replacement if you ever copy them by value and rely on c arrays degrading to pointers in those cases. If you are writing new code, you can explicitly pass references or pointers around when you want them.
|
# ? Jan 8, 2018 04:16 |
|
Jeffrey of YOSPOS posted:I think it will hurt performance if you use it as a drop in replacement if you ever copy them by value and rely on c arrays degrading to pointers in those cases. If you are writing new code, you can explicitly pass references or pointers around when you want them. Modern (C++14 compliant) compilers are technically smart enough to avoid this. The question would be what's gained by making C-style array declarations into std::array containers and the answer is...nothing.
|
# ? Jan 8, 2018 04:26 |
|
The Phlegmatist posted:The question would be what's gained by making C-style array declarations into std::array containers and the answer is...nothing.
|
# ? Jan 8, 2018 05:17 |
|
The Phlegmatist posted:The question would be what's gained by making C-style array declarations into std::array containers and the answer is...nothing.
|
# ? Jan 8, 2018 06:10 |
|
roomforthetuna posted:The ability to do my_array.size(), my_array.begin() and my_array.end() would be gains. You can use std::begin(my_array), std::end(my_array) already, and size is just end-begin. Should work for both types.
|
# ? Jan 8, 2018 07:16 |
|
Zopotantor posted:You can use std::begin(my_array), std::end(my_array) already, and size is just end-begin. Should work for both types. Tangentially relevant side note: I don't know how relevant this is, but when I do those programming challenge sites I notice that doing std::begin(my_array) instead of my_array.begin() or even my_array[0] can shave off a millisecond or two.
|
# ? Jan 8, 2018 07:23 |
|
The Phlegmatist posted:Modern (C++14 compliant) compilers are technically smart enough to avoid this. The problem that I keep having with C++ is that very often there are often multiple different ways to accomplish the same thing, like with arrays. So I'm wondering if the future plans for C++ will ever involve becoming more simplified, or if the backwards compatibility thing is going to stick around forever, with the language growing new appendages forever. I guess I'm looking at how nice other languages seem, and questioning the massive amount of investment I've put into C++. e: I guess part of my frustration is that my own workflow hasn't caught up to modern c++. I know there are ways to do things to make basic problems like memory leaks or thread safety non-issues, but my "muscle-memory" for programming still wants to use the decades-old "unsafe" methods. I feel like I'm not getting my point across because its really late and I got out of bed to post this. baby puzzle fucked around with this message at 08:11 on Jan 8, 2018 |
# ? Jan 8, 2018 08:00 |
|
baby puzzle posted:The problem that I keep having with C++ is that very often there are often multiple different ways to accomplish the same thing, like with arrays. So I'm wondering if the future plans for C++ will ever involve becoming more simplified, or if the backwards compatibility thing is going to stick around forever, with the language growing new appendages forever. I guess I'm looking at how nice other languages seem, and questioning the massive amount of investment I've put into C++.
|
# ? Jan 8, 2018 08:08 |
|
baby puzzle posted:The problem that I keep having with C++ is that very often there are often multiple different ways to accomplish the same thing, like with arrays. So I'm wondering if the future plans for C++ will ever involve becoming more simplified, or if the backwards compatibility thing is going to stick around forever, with the language growing new appendages forever. I guess I'm looking at how nice other languages seem, and questioning the massive amount of investment I've put into C++. The language itself will probably never be simplified by design. However, you can expect tools like clang-tidy to become gradually more and more pedantic about what passes and what doesn't. Get in the habit of running it as part of your build process and you will get the stricter language you want.
|
# ? Jan 8, 2018 08:47 |
|
C++17 removes some stuff, most notably std::auto_ptr and the much-maligned dynamic exception specifications that everyone said "okay never use these" right after they were introduced. In general you should expect newer revisions to the standard to keep adding features and making C++ more conceptually complex, yeah. RAII, smart pointers and STL containers make C++ code easier to keep leak-free than C code, though. C++ should eventually have std::span<T> (C++20 maybe?) which is a non-owning view into a contiguous area of memory, making it easier and safer to work with C style arrays.
|
# ? Jan 8, 2018 18:42 |
|
The Phlegmatist posted:C++ should eventually have std::span<T> (C++20 maybe?) which is a non-owning view into a contiguous area of memory, making it easier and safer to work with C style arrays. std::span<> is incredibly overrated in my opinion, unless you are interacting with a C library or the OS, odds are pretty good that whatever function you are writing that would take a span<> should be operating on iterators instead.
|
# ? Jan 8, 2018 23:35 |
To me it makes good sense to pack the idea of a range of a collection into a single type, instead of requiring two separate values for each end. It could also make the ranged for syntax usable, and give some additional protection from the uncommon but possible error of mixing iterators from separate but same-typed containers.
|
|
# ? Jan 8, 2018 23:41 |
|
The clever things you can do in the STL with iterators are cute but the usability (and safety) of the entire library is just godawful because of it. Iterator ranges let you have both, but really iterators are just overrated as a collection design primitive. The STL obsession with iterators leads to horrors like "output iterators" that actually push_back to a vector, which is like... this is not how a reasonable library would have solved this problem. It does not help that the language committee itself is still strictly opposed to anything like an extension-method feature. rjmccall fucked around with this message at 05:29 on Jan 9, 2018 |
# ? Jan 9, 2018 05:25 |
|
Jose Valasquez posted:When you are declaring an array the numbers are not 0 based, so you would want [2][10] in your example. Jeffrey of YOSPOS posted:Arrays are prove to out of bounds errors, my concern would be that you'd be given a firm rigid way of doing something, and only learn to manipulate that without understanding it. I see C as somewhat portable assembly language and is hard for me to think of it as a language whose abstractions I can trust without knowing how they work all the way. It's been a while since I've been able to use something other than a phone. code:
|
# ? Jan 9, 2018 23:52 |
|
Azuth0667 posted:
|
# ? Jan 10, 2018 00:21 |
|
This might be a dumb question, but I need clarification. In C#, let's say I make a class called "Test", and give it an int variable. I then make a Test object, and store it in a Test object variable. I then create two more Test object variables, and assign the original Test object to both. If I change the value of the int variable in either of the two new objects, will those changes propagate backwards to the original object? My brief test says yes, but I'm not sure if that's a consistent behaviour I can take advantage of, or if I've walked into some weird edge case that I can't rely on. If it is consistent, how would I go about splitting a copied object into its own unique object? Would I need to create a new object, and copy the values over? Or is there a way to directly make an object variable unique, and untied to anything else?
|
# ? Jan 10, 2018 00:43 |
|
The line:code:
code:
The thing I was unclear on was what you meant by "combine two arrays". Being precise matters here because there are 11 ways I can imagine to combine arrays and most of them don't result in a 2d array that's nxn for two size n arrays. I don't really even see what you're combining here, you didn't have arrays to begin with either, you created them to store x coordinates and then y coordinates only to then use those to fill in a 2d array. There's a few things going on there - for one, you could potentially skip the middle man, and just use rand() % 10 with the 2d array, something like this: code:
code:
|
# ? Jan 10, 2018 01:50 |
|
Does visual studio have anything like clang-tidy mentioned above?
|
# ? Jan 10, 2018 09:03 |
Boron_the_Moron posted:This might be a dumb question, but I need clarification. You probably want the .NET thread, not the C and C++ thread, for C# questions, but anyway: In C# you have two kinds of object-like user-defined types: Class and Struct. The syntax for declaring either is basically the same, the only difference is whether you use the "class" or the "struct" keyword at the beginning. A variable of a C# class type is a reference type (pointer-like), it references an object that lives somewhere else in memory. Assigning the value of one class type variable to another class type variable only copies the reference, both variables now reference the same object. You have two variables, but a single object. Meanwhile in C#, a variable of a struct type is a value, it is the object. Assigning one struct type variable to another creates a full copy of the object, so you have two separate objects, one contained in each variable.
|
|
# ? Jan 10, 2018 09:18 |
|
nielsm posted:You probably want the .NET thread, not the C and C++ thread, for C# questions, but anyway: Ah, thank you. I know this is the wrong thread, but would I be right in thinking that in order to split an object variable into its own unique object, I would need to use the "new" keyword, and copy the values of the original object into the new one?
|
# ? Jan 10, 2018 10:55 |
|
Boron_the_Moron posted:Ah, thank you. If the object in question is a class instance (which you should prefer over struct instances in most cases), then yes.
|
# ? Jan 10, 2018 12:07 |
|
c0burn posted:Does visual studio have anything like clang-tidy mentioned above? Not natively. Various different linters have extensions or can just be bound to a command somewhere. For clang-tidy specifically, there's an extension for that. I haven't used it so no idea how good it is. It looks good enough that I'm going to install it when I get back to work next week, at least. For different linters, cppcheck is pretty popular. Visual Assist also has some linter features and is more natively integrated into VS, but you need a Visual Assist license.
|
# ? Jan 10, 2018 16:14 |
|
Since I don't see a Windows thread, I guess I'll ask here What framework would you use to make a Windows UI? Outside of Qt, which my coworker has no experience in, and the first to say "HTML" will be shot in the face
|
# ? Jan 17, 2018 09:47 |
|
Electron.
|
# ? Jan 17, 2018 10:01 |
|
hackbunny posted:Since I don't see a Windows thread, I guess I'll ask here https://juce.com/doc/tutorial_main_component is an alternative to Qt that also works on all platforms. The people who make it market themselves to the music industry niche, but it has all of the same bells and whistles as Qt and doesn't get nearly as much air play because Qt sucks all of the air out of the room. Love Stole the Day fucked around with this message at 10:09 on Jan 17, 2018 |
# ? Jan 17, 2018 10:06 |
|
sarehu posted:Electron. Sentence: death by firing squad Love Stole the Day posted:https://juce.com/doc/tutorial_main_component is an alternative to Qt that also works on all platforms. Pass. I don't see any advantage over Qt, and the disadvantage that I have no experience in JUCE while I have quite a bit with Qt
|
# ? Jan 17, 2018 10:28 |
Any requirements for real Win32? Portability? Compiler support? I think C++/CLI with WPF might be one of the less crazy things to use, if C++ is a requirement, and being stuck on MSVC and technically .NET is acceptable. C# with WPF is less horrible to write, and integrating with a class library written in C++/CLI for lower level stuff might make sense. There are a couple thin wrappers around Win32 using modern C++ that should be less bad than MFC, I've never used any of those myself. For really simple stuff, pure Win32 perhaps with DIALOG resources might not be so bad. Cross-platform that's not Qt, uh wxWidgets?
|
|
# ? Jan 17, 2018 10:51 |
|
nielsm posted:Any requirements for real Win32? Portability? Compiler support? Visual Studio 2017 is the only hard requirement. Ease of deployment a plus, so I'd like to avoid gigantic frameworks with their own installer (unless the gigantic framework is .NET). Other than that, go hog wild nielsm posted:I think C++/CLI with WPF might be one of the less crazy things to use, if C++ is a requirement, and being stuck on MSVC and technically .NET is acceptable. C# with WPF is less horrible to write, and integrating with a class library written in C++/CLI for lower level stuff might make sense. Yes, C++ is a requirement, because the UI will interface with a pre-existing native core with a C++ API. The UI developer already erred on the side of a .NET UI over a native core, although he wanted to use Windows Forms, which I've never heard much good about, and isn't it unmaintained anyway? I'll tell him to have look at WPF before we commit to Windows Forms nielsm posted:There are a couple thin wrappers around Win32 using modern C++ that should be less bad than MFC, I've never used any of those myself. Just in case, can you name any? The only one I know is WTL... which I'm glad to see is still being actively worked on
|
# ? Jan 17, 2018 11:28 |
|
hackbunny posted:Since I don't see a Windows thread, I guess I'll ask here Tell your cow-orker to learn Qt? Plenty of resources around.
|
# ? Jan 17, 2018 12:27 |
|
Slash posted:Tell your cow-orker to learn Qt? Plenty of resources around. Yeah, this. I mean, if they have no experience in Qt, but they also have no experience in any other C++ GUI toolkits, why not just go with Qt rather than some weird offbrand alternative with less available documentation? They're going to have to learn something either way.
|
# ? Jan 17, 2018 12:48 |
|
|
# ? Mar 29, 2024 03:10 |
|
Licensing hurdles, the less than svelte installation size and the not-quite-native feel of the result (the reason we aren't doing a cross-platform UI in the first place). WPF seems like the best choice Comedy option: Java with SWT (we do have the JNI bindings ready from Android...)
|
# ? Jan 17, 2018 12:54 |