|
I guess you may already know this but still, it's pretty annoying for me.
Dudes just introduced breaking change in the order of startup methods in a framework used by really lots of people because of... um... oh... whatever reason.
|
|
|
|
|
I had to create a template ASP.NET Core 3 project just to figure out why things were breaking in the whole startup process. Geez, they changed a lot.
And then I also discovered that they switch to their own JSON deserializer -- apparently they had been using Newtson, and that broke things.
Then I discovered that the way I was coding a SQL where clause with EF "linq-ish" syntax no longer was supported.
I hate open source.
|
|
|
|
|
Quote: And then I also discovered that they switch to their own JSON deserializer
This thing "wow, this new JSON serializer is so fast" really annoys me. Of course, it's fast, it lacks features Newtonsoft has. There are lots of other fast serializers with a lack of features i.e. Utf8Json, why not compare with them.
It's worth noting that one can use Messagepack to serialize things fast.
Quote: I hate open source.
I wonder whether this is open source or just sloppiness.
|
|
|
|
|
I've been debugging my first Windows shell extension, and just realized the problem with the following:
_TCHAR *buffer = new _TCHAR(buffer_size); No compiler warnings or errors either.
Software Zen: delete this;
|
|
|
|
|
 C++ is too often like that. You write something that compiles, but it doesn't do what you think. Recently I was answering a question where a newbie had written
if(a && b < n) believing that it meant
if((a < n) && (b < n))
|
|
|
|
|
It is probably possible that some UML somewhere will cater for that...
Do what I mean, not what I say.
My plan is to live forever ... so far so good
|
|
|
|
|
UML is good for documenting something complicated after it has stabilized.
|
|
|
|
|
Yeah, I've seen that. Wasn't that the same posting which tried to express a pair using the syntax (a,b)? 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Yes, you contributed an answer to that one[^], where (a, b) was the syntax for a function definition's unnamed arguments!
|
|
|
|
|
C++ tried it's best to be compatible with C at the beginning, including it's idiosyncrasies. What's the point in the compiler guessing what the programmer's intention might be?
|
|
|
|
|
I do not think a compiler should be guessing at what a programmer's intention should be. It should give them a warning (or error) that what they are asking makes no since. The compilers job is to turn your text into a program that runs on the given platform.
There are two major issues with the compiler making dissensions for you:
1) You are not learning how to tell it what to do.
2) Your are learning that even if you do not understand how it works, that someone (way smarter than you) has figured out how to make it work - even if you don't.
The main problem is that their solution to the problem (#2) may result in a solution that breaks what you intended. You'll never become an expert in the language of your choice if the compiler is deciding what you intended to do, as apposed to what you actually told it to do.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
|
John R. Shaw wrote: It should give them a warning (or error) that what they are asking makes no since.
I suppose you wanted to say "makes no sense"?
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
One major difference between the TCP/IP protocol suite and the OSI protocol suite is that the former asks you to try to make sense of whatever you receive, one way or the other.
OSI follows the principle that a protocol error is fatal, you cancel the connection. Disconnect is mandatory; if you continue operation trying to keep it going, then you are not conformant to the standard. Those sloppy, haphazard implementations are kicked out. If you want to exchange data, you better do it in the proper way!
Of course it makes it more difficult to be an eager student who has not yet learnt proper behavior; before he goes out in the wide open world he must know what to do. The Internet lenient philosophy is fair enough while you are still playing in the sand pit, but not when you grow up.
Programming languages are similar. They should define clearly what you can and cannot do. They should specify clearly all the issues that the compiler is required to detect, those that the generated code / runtime system is required to detect, and those that cannot reasonably be detected neither at compile time nor run time but is nevertheless an error. I know of one language specifications that includes all three, the Z.200 CHILL language. Unfortunately, CHILL never made it as a mainstream language (nobody really tried to make it!) - it was a language design of excellent quality. But I guess most programmers moving from C to CHILL would feel the strict discipline as a straightjacket.
|
|
|
|
|
That's one of the problems that don't fit modern coding standards: When your (valid) syntax doesn't properly express what it does, then your choice of syntax is bad. In your example, it would be better to use some function like
template <class T> T* makeCArrayOfLength(size_t length) { return new T[length]; }
whereas the functionality you invoked should be represented by
template <class T> T* makeObjectFromValue(T const& value) { return new T(value); }
That syntax not only will give you much better insight on what you are doing, it might also cause compiler warnings or errors when used incorrectly.
Of course, it's a little more effort to write
_TCHAR *buffer = makeCArrayOfLength<_TCHAR>(buffersize);
But that effort pays off in the long run.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
To my mind, the code I wrote should have triggered a compiler diagnostic. The expression on the left side of the assignment operator is a pointer to _TCHAR while the right side is a single _TCHAR constructed from the value buffer_size. Barring perversions of the assignment operator, those two aren't the same thing.
Of course, I am using a very old version of Visual Studio for this project, so...
Software Zen: delete this;
|
|
|
|
|
Unfortunately, new creates an object on the heap, and it does return a pointer. That corresponds to the left hand side. Also, it's not obvious to the compiler to understand what you intended. If you had constructed a class instance instead, it would be quite reasonable. While creating an integral type on the heap is quite unusual, it might still make sense if that code is part of a template implementation:
template <class T>
T* copy(T& const source) {
return new T(source);
}
This code works for any kind of class, but also for integral types. So why should the compiler complain?
However, the crux of the problem is that C/C++ treat {addreess to first element of array} the same as {address of object}. It doesn't differentiate the two, and that is why your assignment doesn't even raise a warning.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Aha! Thanks for the explanation. I sometimes forget subtleties because I'm constantly switching back and forth between C++ and C#.
Software Zen: delete this;
|
|
|
|
|
Stefan_Lang wrote: However, the crux of the problem is that C/C++ treat {addreess to first element of array} the same as {address of object}. It doesn't differentiate the two, and that is why your assignment doesn't even raise a warning.
const char *c = "Hello world!";
std::cout << "*c = " << *c << "\n";
std::cout << "size of *c = " << sizeof *c << "\n";
std::cout << "c[0] = " << c[0] << "\n";
std::cout << "size of c[0] = " << sizeof c[0] << "\n";
std::cout << "c = " << c << "\n";
std::cout << "size of c = " << sizeof c << "\n";
std::cout << "&c[0] = " << &c[0] << "\n";
std::cout << "size of &c[0] = " << sizeof &c[0] << "\n";
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
So for the C++ illiterate, what's wrong with that line of code? Or did you mean new _TCHAR[buffer_size]; ?
|
|
|
|
|
Precisely. As written, it casts buffer_size as a _TCHAR and allocates only one of them.
|
|
|
|
|
This man, Mr. Arnab Chakraborty has taught me so much about parsing. His videos are incredible. They're basically class lectures on advanced CS topics, like this one on viable prefix computation in shift reduce parsing.
Viable Prefixes and Valid Items - YouTube[^]
It appears he's not a doctor - not that it matters, but it's just startling to me given the variety of advanced subjects I've found him lecture on. I'd think he'd make a great CS professor anywhere.
I'm not really here to plug his site, but he's such a valuable resource at the same time i don't want anyone to miss out. I usually google with "tutorialspoint [topic]" if i want to find him in particular.
I don't even usually like videos to teach things, but in some cases seeing him whiteboard it is very helpful.
Real programmers use butterflies
|
|
|
|
|
|
NPTEL seems to be great resource for online learning.
If you are not criticized, you may not be doing much.
|
|
|
|
|
Forget digresses! Either he knows what he it talking about or he does not. I've been telling computers what to do for over 30 years and do not have a degree. But then again, there was no degree's on the subject when I stated.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence." - Edsger Dijkstra
"I have never been lost, but I will admit to being confused for several weeks. " - Daniel Boone
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
