|
Valar Morghulis! 
|
|
|
|
|
The only reason i can think of for this is that Name can be specified but empty, which seems silly. I wonder if there was a design issue further downstream that required support for empty names?
Real programmers use butterflies
|
|
|
|
|
Or ReadBoolean masks a bit and they put the other 7 bits to good use. 
|
|
|
|
|
If that were the case I would be skinning someone come code review time.
Real programmers use butterflies
|
|
|
|
|
But but but...it's a binary file. 
|
|
|
|
|
Database people have been discussing variants of non-existing, empty and zero-length strings for at least 30-40 years.
There is a difference between not knowing whether a value for the attribute exists, knowing positively that it is void, and knowing that there is a defined value, but it is of zero length.
The strangest passport I ever saw was for the son of friends of mine: It stated birthdate as unknown, sex unknown, name unknown, no photo or fingerprint available. When the mother, US citizen living in Norway, is pregnant with a baby, and plans a trip abroad with the baby a few weeks after the delivery, you must start the process of applying for a passport before those details are known.
So for this baby's middle name, before his birth, nothing was known, not even if he would have a middle name at all. If he has one, I do not know it, so I could treat it as a defined name attribute with unknown value. If I learn that he certainly does not have a middle name, it would be a known value of zero length.
There may be better examples to illustrate various null/empty/… values; this is just the first one dropping into my mind. There may be cases where there is no semantic difference between optional omitted, included but unknown, included with a known length of zero and included with a positive length value. Yet there are other cases where the semantic difference may be very significant.
|
|
|
|
|
Empty is not the same as "unknown". If it is unknown, then that is what it should state.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
mmmm... while you are arguing for 1 wasted byte at offset 0, did you noticed the wasted 1MB at offset 43512?! 
|
|
|
|
|
I’m sure the serialization inefficiencies could be waved away with a layer of arithmetic coding compression using a specialized model trained on the wasted bits of this format, but I worry that this is just basically sweeping technical dust under the rug …and overengineering for such a trivial problem. 
|
|
|
|
|
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)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
