|
It's frustrating that this is basically system level code - driver code necessary to use the hardware for the proprietary** SoC it runs on.
** how it works isn't actually a secret, but nor is it easy to dig through a mountain of technical specs written in chinese to write a custom DDK and SDK package for this hardware.
Real programmers use butterflies
|
|
|
|
|
This reminds me of Flon's Axiom from 45 years ago: "There does not now, nor will there ever, exist a programming language in which it is the least bit hard to write bad programs."
|
|
|
|
|
I like how it was phrased in one of the Star Trek movies. I think it was #3. Anyway, the president of the Federation said, "Let us define progress to mean just because we can do a thing does not mean we must do that thing." I take that approach to a large amount of stuff when it comes to programming. Especially new language features. So far, I have seen exactly one thing in C++17 that I really, really like and use often : inline static variables with initialization.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I hear you. The one "must have" feature in C++ that isn't actually in C++ but should be is real forward type declarations.
Remove the restriction where I can only declare things like a pointer to a type before the type itself is fully declared.
It might require using a GLR parser or something equally complicated to parse your code (like C# does) but given the complexity of a standards compliant C++ compiler already, what's changing the parsing engine used by most C++ compilers to something more advanced in the big scheme of things?
Basically to bottom line it, I want to be able to declare my types anywhere in my files and use them anywhere in my files.
Real programmers use butterflies
|
|
|
|
|
You mean like this?:
class FWD;
struct STR {
FWD *fwdPtr;
};
int main() {
STR tst;
return 0;
}
|
|
|
|
|
No. I mean like this:
struct myForward;
std::unordered_map<std::string,myForward*> m;
...
Except I'd even go as far as to eliminate the forward declaration entirely.
The above won't work, BTW on most implementations of the STL, although there's nothing in the spec that says it won't work but nor does it guarantee it does. It works in Boost's unordered_map, but because they went out of their way to make it work in how they implemented unordered_map.
Strangely enough, the above will usually work if you replace it with std::map
Real programmers use butterflies
|
|
|
|
|
This is supported by all compilers I use, clang, gcc and msvc.
Just curious, what did you use that didn't support this?
BTW, if you don't like forward declaration, perhaps you need an untyped language.
Here, the type of "m" depends on the type "myForward", there's no way around this, and it's not just in C++.
|
|
|
|
|
I wouldn't say C++ has gotten more complicated. Au contraire - I would say it's never been as easy to learn and use as it is now, I almost never have to rely on raw pointers, manual memory management, and all the stuff that C++ haters love.
The problem of C++ is that it has become so feature rich, that it's virtually impossible to know all of it, and there really are a lot of features, which, although I'm sure somebody out there uses, but I don't see them as belonging in the standard.
It's just so freaking huge.
But, of course, you don't really need to know and use all of it. Unless you're a C++ compiler developer.
|
|
|
|
|
afigegoznaet wrote: But, of course, you don't really need to know and use all of it. Unless you're a C++ compiler developer.
Or need to read someone else's code (or your own, later). Oops.
|
|
|
|
|
Well, that's not really language specific.
I find myself reading online documentation even when reading bash scripts.
|
|
|
|
|
Hey now. Bash scripts get arcane. I just got done writing a "bash course" for a client of mine (technically a client of an outfit i work for from time to time) who is trying to educate their own customers on how to use it. Talk to me after you've passed what bash calls an "array" to a function. 
Real programmers use butterflies
|
|
|
|
|
Of course, I had to do some lookup.
Nevertheless:
my_array=(foo bar)
print_array(){
for i in $*
do echo $i
done
}
print_array ${my_array[*]}
|
|
|
|
|
I'd argue that this *is* added complexity.
Every layer you use to abstract away pointers and other C++ arcana removes you that much further from what your code is doing.
And you know, std::auto_ptr works fantastic, until it doesn't. And when it doesn't you better know exactly how it's spec'd to function.
Things can be complicated and easy to use at the same time. Hell, that describes the average IoT device these days.
Real programmers use butterflies
|
|
|
|
|
Well, no.
It is added complexity if you don't know how to use raw pointers.
If you do - you really appreciate the simplicity added by RAII, smart_ptrs and optionals, RAII makes sense in any language, actually.
P. S. std::auto_ptr, really?
|
|
|
|
|
afigegoznaet wrote: P. S. std::auto_ptr, really?
What? You just said you liked RAII. 
Real programmers use butterflies
|
|
|
|
|
std::auto_ptr was deprecated even in C++11 it's not valid C++ anymore.
And RAII is not smart pointers.
modified 9-Feb-21 7:53am.
|
|
|
|
|
I mostly agree, except about PLINQ. If LINQ is like shoveling money into a brazier, PLINQ is like hiring a gang of temps to shovel the money in even faster.
|
|
|
|
|
Hahaha, that's fair I suppose, but at least it scales out, allowing you throw hardware at the problem since the software sucks as a matter of course.
Real programmers use butterflies
|
|
|
|
|
LINQ was engineered by the same person (s)? that engineered inline SQL in FoxPro.
That was the part I missed the most after abandoning FP / VFP ... and rejoiced when LINQ arrived.
If you write LOB apps, particularly ERP, you will understand.
LINQ sucks for those that think "partitioning" a problem is for weenies. They also mangle SQL; assuming the "optimizer" will always sort out their mess.
(soap box off)
Paradox: sometimes you have to write "more" code to get better performance.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
modified 8-Feb-21 15:46pm.
|
|
|
|
|
honey the codewitch wrote: It creates too many objects too quickly
Can you elaborate?
As far as I know you have an extra enumerator per operation, so for example:
foreach (var whatever in whatevers)
{
if (whatever.IsValid)
{
filtered.Add(whatever);
}
}Has one enumerator, while
var filtered = whatevers.Where(x => x.IsValid).ToList(); has two enumerators (the Where will call "the original" enumerator, while the ToList will call the WhereEnumerator).
Other than that it's the same except that the LINQ example has an extra anonymous function (which isn't anonymous after compilation) and an extra function call for each iteration, but if the where clause is complicated enough you may do this in example 1 too.
That's hardly a performance penalty, but you just won 7 lines of code and made it more readable to boot.
The readability further increases when you do stuff like
whatevers.Where(x => x.IsValid)
.Select(x => new { Name = x.Name, Age = x.Age })
.OrderBy(x => x.Name)
.Take(10)
.ToList()at the expense of three extra enumerators.
Object instantiation is cheap, or so I've been told.
You also missed one, LINQ to Entities (or LINQ to SQL), which is also LINQ, but won't enumerate at all because the entire structure is compiled to an object structure and parsed into SQL.
Let's not talk about the performance implications on that one 
For most operations it's not significantly slower though, while it saves a ton of time of SQL development and makes your database connection strong typed meaning less bugs, etc.
The extra milliseconds the user is waiting is won back in hours of development time
|
|
|
|
|
Great. Now try using it to generate a LALR(1) table or for that matter, even compute FIRST and FOLLOWS sets.
You'll see my issue with LINQ really quickly. Especially if you benchmark it.
I guess it all depends on what kind of code you're writing. These days I don't do a lot of bizdev, and I haven't touched a real database in years.
Adding, I don't think you're considering all the extra overhead of LINQ not actually combining all the operations that can be combined into a single iteration eg: iterating twice where once would do.
It just isn't smart enough. It's also problematic (and this isn't specific to LINQ but more of a general problem with functional programming) to do certain kinds of queries because some queries can be orders of magnitude faster if you're allowed to keep some state around. There's just no facility for that in LINQ. I don't blame LINQ for that, since it's more of a functional programming paradigm issue, but it still keeps me from being able to use it for a lot of what I would like to use functional programming constructs for.
Real programmers use butterflies
|
|
|
|
|
|
Sander Rossel wrote: For my customers a few extra objects, iterations and even MB's are no issue at all (they don't even know it exists), but my hourly rate is 
Yeah I can understand that, but also I'm glad that's not my situation. I like having to cram as much functionality I can into modest hardware.
Real programmers use butterflies
|
|
|
|
|
My customers like having me cram as much functionality as I can into modest invoices 
|
|
|
|
|
My customers are willing to pay for me because the alternative is worse.
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
