|
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
|
|
|
|
|
My customers are willing to pay for me, but they'll never admit it 
Although I've had one saying "Sander, I trust you. If you send me an invoice I can be sure you're charging an honest price and that it's not too expensive."
Which of course raised his invoices by 10% (no really, I'm joking!)
I recently had a talk with two customers (from the same company) and one of them said "Sander, it's very nice what you've made for us, but that invoice was quite high."
To which the other person replied "Think of it like this, [name], if it wasn't for Sander we wouldn't have it at all and we really need it."
Despite me costing a lot of money, I'm don't think I'm expensive.
I add direct value with my custom software and most of my competition is slower and/or more expensive
All in all it's a fun job and haggling is just a part of it.
|
|
|
|
|
I'm a jerk i guess.
I don't haggle. I charge based on how much I like the project, and I don't take jobs I don't like.
I am fair about my invoices, and I itemize my time, but again, I don't haggle. Pay me or find someone else.
I cost what I cost, and I'm always told I'm worth it when I'm told anything.
One of my current clients actually told me I "walk on water" so I had to reduce his expectations for fear of drowning.
Real programmers use butterflies
|
|
|
|
|
I wish I had that luxury, but to me (work > no work) and many of my potential customers rather work with Excel, an old system or even paper than pay "too much" for their custom software 
My hourly rate is fine though, so there's some room for haggling, but only for specific projects.
I don't doubt that if I'd cut my rate in half they'd still haggle though
And sometimes bringing a customer in is more important than money if I know they'll bring me more work in the future.
At the end of the day I've got bills to pay and the only way how is with paying customers.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
