The Daily WTF: Curious Perversions in Information Technology

2007-11-22 Reply Admin

rawr:
I am pretty certain I could hack up a program in an interpreted script language that works faster than some of my friend's C/C++ code, even with the compiler optimizing as much as possible.

That's because those interpreted languages are (usually) written in C or C++ by programmers who know what they're doing. Yes, that means you can go as fast or faster in pure C/C++, but that doesn't mean that it'll be easy. It's entirely practical to write terrible code in any language, and compilers can only clean up so much of the mess; for example, string handling is something that many low-level programmers get disastrously wrong and where many high-level languages gain efficiency by virtue of knowing more about the general intentions of the programmer. Of course it doesn't have to work that way, but it does on the ground.

2007-11-22 Reply Admin

Zygo:
Imagine a monkey is following you as you code, adding spurious references to members of your structs that you can't see, and ensuring that they're used almost at random throughout your code. That's what binary compatibility in C++ is like.

The problem is that the details of the layout of the internal details of structures and classes gets embedded in code that just uses the library. Which means that any time the internals change, it's a recompile because you've got no idea what has changed otherwise. (Note that this is not the same as source-level API compatibility; though related, the problems aren't the same.) As an application author, having to do a full rebuild just because some eejit in charge of a library you use moved around some private fields... That gets real old real fast.

2007-11-22 Reply Admin

T.T.:
Note that some C++ compilers translate to C before compiling (Comeau C++ does that IIRC).

That's cfront-style compilation, and it says nothing at all about ABI management. C just makes dealing with that stuff easier, but not automatic, and C++ has many features that make ABI control hard. Specifically, anything that ends up inlining structure/class field offsets is a problem (in either language) and that includes stuff relating to virtual method tables. And yes, dealing with this stuff does involve a performance hit and a great deal of care.

2007-11-22 Reply Admin

they invented a bycicle. Mayn modern languages, for example Delphi, do have "properties" in their objects, and property's getter and setter can be either member-variable or member-method, or just null to disallow getting or setting a value. That does not have binary compatibility (if you change binary library setter or getter from one type to another - you need to recompile whatever is using the library), but in object code and source it looks the same and just need to be quickly recompiled. Thus you can avoid breaching the security, not to waste CPU calls if it is important, and introduce a subroutine as getter or setter as soon as you need it.

or you can use seom virtual machine (JavaVM, MS CLR, etc) which i hope are smart enough to JIT-compile primitive getter/setter stubs to direct access to the corresponding member-variable.

Nelle · 2007-11-22 Reply Admin

m:
I've always thought that private/protected/public thing was less than useful. If you have a class that is useful and well-written, chances are its implementation never changes. and any change to the class usually involves a re-write to the entire structure anyway, because seldom is the implemenation/interface as clear-cut as everyone wishes.
Has anyone EVER actually changed the private implementation of a class, and not have to re-work all the stuff dependent on it? Or are my suspicions correct and this is something that lots of thought goes into for little-to-no long-term benefit?

i worked on what you might call a big project, where couple of departments in the firm had to cooperate. first the interfaces were drawn (public methods) and they were made fixed, so there was no way you could re-work all the stuff dependent on it. i was not even there when the entire thing was designed i just got the documentation of the interfaces and proceeded to write private methods that implemented the behaviour. if i needed to change any of the public methods (including the modifiers) i had to fill a form in triplicate and sacrifice seven ounces of my blood to the god of application design and wait until a joint commission of the departments involved had a meeting and gave their blessing.

i somehow managed never to do such a thing.

brazzy · 2007-11-22 Reply Admin

Someone:
And as for "enforcing" correct use. If the variable is clearly documented as read only, then the only way people could incorrectly use it is intentionally.

Wrong. There is also "accidentally". Do you always and without exception read the entire documentation of every member of every class you use? Do you never use code completion and just assume that you can safely infer what something does from its name?

As seen above, you can already do that with the preprocessor.
I don't think "don't use the variable in a way explicitly forbidden by the documentation and comments" is an unreasonable request - I thought we were dealing with trained programmers here, not children on a theme-park ride.

Ever heard of something called the "Principle of least astonishment"?

If something fundamental like the fact that you're not supposed to write to a field can only be learned from the documentation or comments, it's simply a badly designed API. If it were written in the name (i.e. prepending them with "readonly_") it might be acceptable, but then why not go the full distance and make it a keyword enforced by the compiler?

2007-11-22 Reply Admin

Spectre:
Well, since it's in the standard library chapter, it looks like it only applies to standard headers.

If the third-party header file you are trying to hack includes a standard header, then you're violating this rule anyway. And, no, you cannot redefine #include. ;-)

2007-11-22 Reply Admin

What really sucks about most comments here is that everyone keeps repeating how that C++ private/protected/public crap is actually any good. I mean header files that define private variables that you can see the names of but not use, that's just stupid. Why not use a proper OOP language with seperate interface/source files, like Ada or Modula-3? Then you won't need to have any of this private variable stuff, if they're not in the interface file, you won't even know they exist, let alone read/write to them.

Btw, Oberon (another Pascal descendant) has read only fields.

2007-11-22 Reply Admin

Right on... I only use public byte arrays for speed reason of course

real_aardvark · 2007-11-22 Reply Admin

dkf:
rawr:
I am pretty certain I could hack up a program in an interpreted script language that works faster than some of my friend's C/C++ code, even with the compiler optimizing as much as possible.
That's because those interpreted languages are (usually) written in C or C++ by programmers who know what they're doing. Yes, that means you can go as fast or faster in pure C/C++, but that doesn't mean that it'll be easy. It's entirely practical to write terrible code in any language, and compilers can only clean up so much of the mess; for example, string handling is something that many low-level programmers get disastrously wrong and where many high-level languages gain efficiency by virtue of knowing more about the general intentions of the programmer. Of course it doesn't have to work that way, but it does on the ground.

Nope, that's because rawr hangs around incompetent idiots, for some reason best known to himself. Perhaps it's the sense of danger. I'd so love to challenge him on this, but unfortunately he/she is below my unevent horizon.

Nothing wrong with scripting languages. But, if you're a big ol' optimisation sucker, and you don't care about correctness, then you almost certainly lose out both ways.

real_aardvark · 2007-11-22 Reply Admin

Bored Bystander:
What really sucks about most comments here is that everyone keeps repeating how that C++ private/protected/public crap is actually any good. I mean header files that define private variables that you can see the names of but not use, that's just stupid. Why not use a proper OOP language with seperate interface/source files, like Ada or Modula-3? Then you won't need to have any of this private variable stuff, if they're not in the interface file, you won't even know they exist, let alone read/write to them.
Btw, Oberon (another Pascal descendant) has read only fields.

Actually, with minimal care, you can use the Bridge pattern to hide all that crap from the user. Which is not something you'd waste time over, unless you were writing a library. Which is not something that more than 1% of programmers in any language do.

A few queries on definitions here:

(a) What exactly is a "proper OOP language?" (For once in your pitiful little life, Do Not give examples.) (b) How important is it, in the general sense, that you can see the name of a variable? Can you see the name of God? Are you bathed in the blood of the Lamb?

Oops, sorry, got distracted there. 'Nother topic. (c) Do you know how to spell "separate?" If not, can you look it up?

BTW, and it's not worth much, C++ has read-only fields too. They're called "const" or "mutable", depending upon whether the object/class can write over them or not. Tiny and pointless language semantic difference, there. And, language flames aside, I believe that Java, .NET flavours, etc, have exactly the same basic ideas.

Oberon? You're having a laugh. Come back when you've worked in the real world, with a real world language. Or failing that, write one yourself, and convince us that it's worth wasting our time to learn.

2007-11-22 Reply Admin

Btw, Oberon (another Pascal descendant) has read only fields.

Even Fortran has read only fields. Sad, but true.

2007-11-22 Reply Admin

real_aardvark:
Bored Bystander:
What really sucks about most comments here is that everyone keeps repeating how that C++ private/protected/public crap is actually any good. I mean header files that define private variables that you can see the names of but not use, that's just stupid. Why not use a proper OOP language with seperate interface/source files, like Ada or Modula-3? Then you won't need to have any of this private variable stuff, if they're not in the interface file, you won't even know they exist, let alone read/write to them.
Btw, Oberon (another Pascal descendant) has read only fields.
Actually, with minimal care, you can use the Bridge pattern to hide all that crap from the user. Which is not something you'd waste time over, unless you were writing a library. Which is not something that more than 1% of programmers in any language do.

A few queries on definitions here:

(a) What exactly is a "proper OOP language?" (For once in your pitiful little life, Do Not give examples.) (b) How important is it, in the general sense, that you can see the name of a variable? Can you see the name of God? Are you bathed in the blood of the Lamb?

Oops, sorry, got distracted there. 'Nother topic. (c) Do you know how to spell "separate?" If not, can you look it up?

BTW, and it's not worth much, C++ has read-only fields too. They're called "const" or "mutable", depending upon whether the object/class can write over them or not. Tiny and pointless language semantic difference, there. And, language flames aside, I believe that Java, .NET flavours, etc, have exactly the same basic ideas.

Oberon? You're having a laugh. Come back when you've worked in the real world, with a real world language. Or failing that, write one yourself, and convince us that it's worth wasting our time to learn.

My point was if you want to enforce proper data protection, which is the point of this wtf, you should use separate interfaces. Just because C++ is a real world language (go on, define real world language, moron) does not make it perfect. Its method of enforcing proper data protection is quite inadequate.

Separating interfaces from the definitions is not a Tiny semantic difference. In fact, if you had bothered to actually do any reading about Modula-3, you would discover that its compiler will only recompile modules if any interfaces they use have changed, which was also a topic mentioned earlier.

So with regard to your questions: (a) There probably is no perfect OOP language, but in as far as this discussion has been about data protection and maintaining public definitions, Modula-3 is far superior to C++, since it offers partial types and separate interfaces.

(b) Why not just put all the source code in the header files? How about readability? Or maintainability? What happens if add my own class to the list of friend classes in a header?

Can you see the name of God? Are you bathed in the blood of the Lamb?

Wow, that's just stupid. Really stupid.

(c) Wow, I misspelled a word. Do you want a medal? You tell me to look up the spelling of a word and then tell me that having separate interfaces is a tiny semantic difference. Did you even look up any of the languages I did mention?

So you work in the "real world", do you? I suppose you would have told the people you developed Java the same thing when it was first released. Or C++ for that matter. And in case you don't know, and obviously you don't, both Oberon and Modula-3 have influenced the development of Java.

Have you even tried using any language that isn't a "real world language"? People like you who work in the "real world" and only use "real world languages" don't develop the languages you use.

I have actually written my own language, but it's more suitable for scripting so is not relevant for the problem in this wtf. So unlike you, I'm perfectly capable in saying that it's not at all the correct language in this case.

How about you? Have you written the language you use? No? Then SHUT UP, SIT DOWN and type away at whatever language someone else TOLD YOU to use. You're not going to improve things for anyone else, let alone yourself.

2007-11-22 Reply Admin

[quote user="real_aardvark"][quote user="Bored Bystander"] BTW, and it's not worth much, C++ has read-only fields too. They're called "const" or "mutable", depending upon whether the object/class can write over them or not.[/quote]

Sorry, I missed this when I replied last time. What I meant to say about Oberon is that it has read only exporting, i.e. variables that are fully writable within their defining module but only readable from outside it.

So yes, another reason why you're a moron.

2007-11-23 Reply Admin

snoofle:
X-lib had the exact-same-comment in all of its ("C") data structures: this field is private, so you should not change it - and people didn't, because if they did, X became unstable and inevitably crashed.
I find it interesting that the more you attempt to hide something, the more people seek it out and try to access it just to see what happens.

I just tell everyone to leave my privates alone...

2007-11-23 Reply Admin

I've never commented here before (in my 2 years of reading it), but the pure stupidity of the assertions people are making about C++ has forced me to act.

(1) Languages have nothing to do with the performance of a given program (which is obvious; however, it must be said because apparently it's not obvious to the people here).

(2) C++ does indeed have "read only" variables. It's called const. (Although yes. One cannot have a variable be publicly const while privately mutable without the aid of a function)

(3) I would like to be shown where in the C++ standard it says that an implementation cannot inline non inline functions? (Well, I already know that it doesn't, but you people really should look anyway).

Of course we do actually live and program in the real world. In which languages are actually compiled and have finite performance.

Which is great, because all major C++ compilers currently support IPO. gcc intel msvc llvm (btw, llvm can JIT also... so good bye DLL/ABI problems)

I'm sure there's more misinformation to correct, but It's too painful to read through the comments anymore than once.

Moral of the story: nothing is constant (except for const variables! :P (well actually, you can hack around that...)).

2007-11-23 Reply Admin

Mycroft:
m:
Has anyone EVER actually changed the private implementation of a class, and not have to re-work all the stuff dependent on it? Or are my suspicions correct and this is something that lots of thought goes into for little-to-no long-term benefit?

I agree - I hate getters/setters with a passion, they had a use (GUI builders - read back in the history) and people just ran riot with them pointlessly.

Interfaces, with methods that do genuine things are the right way. Getters and Setters that expose atomic, internal data of an object break encapsulation just as much as just declaring those variables public.

Ah yes. So, without any getters and setters - what do you do when later on you decide to be more sensible than just "expose(ing) atomic, internal data" and want to add code which does some sensible checking before setting data or create defensive copies of instances of types which are mutable and in fact shouldn't be?

It seems that you might be talking about Java (because of the terms "getter" and "setter"): Did you ever waste a thought, why all the setters in java.util.Date are deprecated? And why this doesn't solve the problem, because a deprecation warning never has hindered any given dork to use deprecated APIs anyway? You can solve this problem by defensice copying, though. But this can only be done if your field of type Date is not public, because you have to code this somewhere.

If an API is published without being thought through properly (e.g. leaving stuff public just for "convenience" or "performance"), it is extremely hard and often impossible to revert these wrong decisions later on.

2007-11-23 Reply Admin

Devi:
real_aardvark:
And the difference between a cpp file and an hpp file would be ... er ... what?
Seriously, though. If your tender sensibilities are outraged by the concept of an inline escaping from a cpp file, then :

(a) Use the usual horrible manifest constants to guard against inclusion of a cpp file (well, you wouldn't want that to happen, would you?) (b) Design the bleeding thing right in the first place.

There. Problem solved.

And, as a side-note, that's not "just-in-time" allocation (whatever that might mean) -- that's the genuinely scary Singleton Pattern.

In C++, please replace 99% of cases of this with a namespace. You'll feel better.

I believe that "Link Time Code Generation" is functionally equivalent to "template instantiation," which various other C++ compilers/linkers have had since around 1994. Nice to see Microsoft catching up. I might be mistaken, though.

O Lord, one more thing. RAII. At least use a fucking auto_ptr.

A cpp file is processed by the compiler, a hpp file is included in cpp files by the preprocessor. HPP files are essentially a hack designed to bypass the fact that old compiler/linker systems couldn't inline functions that weren't defined in the same post-preprocessor files as they were called in. I never said inlining functions defined in cpp files was a bad idea, just that in many circumstances it's not posible.

Just-In-Time allocation is a term I made up, which means that the system allocates memory when it needs it rather than during an initialization phase. The code example is not an example of the singleton model, this is the singleton model:

class MySingleton { private: // Private constructor blocks new instances being made MySingleton(){}
  // singleton instance
  static MySingleton ms_Instance;
public: // Singleton accessor static MySingleton &GetInstance() {return ms_Instance;} };

I guess you could mess around with name-spaces to achieve the same result, though I don't see how that would give you any particular advantage.

Finally, you have no idea what link time code generation is.

http://msdn.microsoft.com/msdnmag/issues/02/05/Hood/

What you call "Just-In-Time allocation" and what you made that term up for does already have a name: "lazy loading", or more specifically "lazy initialization" (or "lazy instantiation" in OO, as opposed to "eager ...")

BTW, most versions of the Singleton Pattern do additionally use some variation of lazy instantiation, therefore the getInstance()-method looks similar to the "Butt"-example you quoted, and I'm sure that it's author MoronBoy intended just that. Otherwise I think he wouldn't have talked about the "need to wrap that getButt in a mutex".

And that's very probably the reason why real_aardvark pointed this out - no reason to diss him for that :o)

real_aardvark · 2007-11-25 Reply Admin

Michael Spencer (bigcheesegs aejfnase gmail 9j3cf83c com):
I've never commented here before (in my 2 years of reading it), but the pure stupidity of the assertions people are making about C++ has forced me to act.
(1) Languages have nothing to do with the performance of a given program (which is obvious; however, it must be said because apparently it's not obvious to the people here).

Well, apparently we like quibbling. Which is silly, to be honest. Welcome to another C++ defender, btw.

Michael Spencer (bigcheesegs aejfnase gmail 9j3cf83c com):
(2) C++ does indeed have "read only" variables. It's called const. (Although yes. One cannot have a variable be publicly const while privately mutable without the aid of a function)

Y'know, I tried const/mutable on my local gcc compiler, and realised, much to my dismay, that "mutable" makes no difference to external access. My God, how could I not have known that? Might be something to do with ten years of never exposing raw data members to the outside world, I suppose. Or maybe I'm just a degenerate idiot who should be using Modula-3 instead.

Michael Spencer (bigcheesegs aejfnase gmail 9j3cf83c com):
(3) I would like to be shown where in the C++ standard it says that an implementation cannot inline non inline functions? (Well, I already know that it doesn't, but you people really should look anyway).
Of course we do actually live and program in the real world. In which languages are actually compiled and have finite performance.

Which is great, because all major C++ compilers currently support IPO. gcc intel msvc llvm (btw, llvm can JIT also... so good bye DLL/ABI problems)

I'm sure there's more misinformation to correct, but It's too painful to read through the comments anymore than once.

Moral of the story: nothing is constant (except for const variables! :P (well actually, you can hack around that...)).

I know what you mean. It's late, and I'm tired, and I have to travel to Bracknell tomorrow, and I can already hear the sound of my soul being sucked dry as a raisin in the Sturt desert.

Being a masochist, I think I'll go back and read the previous comments before I commend my soul to an obviously ungrateful God.

real_aardvark · 2007-11-25 Reply Admin

Bored Bystander:
My point was if you want to enforce proper data protection, which is the point of this wtf, you should use separate interfaces. Just because C++ is a real world language (go on, define real world language, moron) does not make it perfect. Its method of enforcing proper data protection is quite inadequate.
Separating interfaces from the definitions is not a Tiny semantic difference. In fact, if you had bothered to actually do any reading about Modula-3, you would discover that its compiler will only recompile modules if any interfaces they use have changed, which was also a topic mentioned earlier.

OK.

A "real world" language is a language that is used in the real world.

Good enough definition for you?

Now, granted, this includes things like Java and VB6 and Cobol and even TRS-Basic, which I find incomprehensible but will accept because they give people warm and fuzzy feelings, and it doesn't really include functional languages from Lisp through Scheme to Haskell (or vice-versa -- I forget); although I dearly wish that it would.

It doesn't really include Oberon or Modula-3, though.

Nice to know you've written your own language. At least, now, you have somebody to talk to.

Nobody told me to use C++. I happen to find it useful in my line of work. I also use Perl, where appropriate, and Python, where I'm allowed to do so. And anything else that comes up.

Really.

Don't get your panties in a twist.

snowman · 2007-11-26 Reply Admin

real_aardvark:
Y'know, I tried const/mutable on my local gcc compiler, and realised, much to my dismay, that "mutable" makes no difference to external access. My God, how could I not have known that? Might be something to do with ten years of never exposing raw data members to the outside world, I suppose.

I find 'mutable' useful for private members that need to be modified from const functions... ie: a cache or acceleration value that is computed on first request... as long as the externally visible state of the object is not changed then it's all sweet... I'm fairly sure this is exactly what the mutable keyword is for *and nothing else*.

As for 'const' members, I find those useful too.. and NOT because I want to leave a member public so that client code can get to it... sometimes you really do have members that should never be changed after the object is created... common examples for me are most functor members and things like an id.

2007-11-26 Reply Admin

C++ has an "inline" directive to put on functions. So, "inline" functions don't have be in the headers class Name {...}; block. We can write the function in a .cpp file, like this:

inline int Name::get_some_int() const { return this->some_int; }

This makes the class definition in the headers easier to read. This also helps hide the implementation details. Such practice is good for a C++ library, where the header files are shipped with the final build to compile & link.

Patrick:
Let's assume for a second that this is C++ and this class defines absolutely no inline functions at all. Then a function like this:
int the_class::get_some_int() const
{
    return this->some_int;
}
actually ends up being a push on the stack, which can add up to lots of overhead just accessing a single integer. In Java or C# the runtime usually sees those trivial calls and inlines them, but when that code is separated into a .cpp file it's compiled and executed as a normal function, thus leading to lots of indirection. I worked at a place once which strictly forbade using inline functions (those functions defined in the header) and the performance noticeably suffered because of it. The real WTF was why the management, who understood nothing about programming, forced this upon us. They claimed that it safely hid the implementation details. They had no idea that the .h files weren't shipped with the final build of the software.

2007-11-27 Reply Admin

real_aardvark:
Bored Bystander:
My point was if you want to enforce proper data protection, which is the point of this wtf, you should use separate interfaces. Just because C++ is a real world language (go on, define real world language, moron) does not make it perfect. Its method of enforcing proper data protection is quite inadequate.
Separating interfaces from the definitions is not a Tiny semantic difference. In fact, if you had bothered to actually do any reading about Modula-3, you would discover that its compiler will only recompile modules if any interfaces they use have changed, which was also a topic mentioned earlier.
OK.

A "real world" language is a language that is used in the real world.

Good enough definition for you?

Now, granted, this includes things like Java and VB6 and Cobol and even TRS-Basic, which I find incomprehensible but will accept because they give people warm and fuzzy feelings, and it doesn't really include functional languages from Lisp through Scheme to Haskell (or vice-versa -- I forget); although I dearly wish that it would.

It doesn't really include Oberon or Modula-3, though.

Nice to know you've written your own language. At least, now, you have somebody to talk to.

Nobody told me to use C++. I happen to find it useful in my line of work. I also use Perl, where appropriate, and Python, where I'm allowed to do so. And anything else that comes up.

Really.

Don't get your panties in a twist.

Great definition, "it's a real world language because I say so". In my original post, which you obviously did not read correctly, I did not say that Oberon and Modula-3 were widely used languages. However, they are usable languages, for a lot of the situations where C++ is used. So why not use them? If more people used them, then would you consider them a "real world language"?

You use Python? Until relatively recently (compared to Perl, C++, etc), Python was unheard of. What made you decide to use this "real world language"? A language that changes its semantics nearly everyday? Have you even looked at any non-"real world languages"?

To recap:

I named some other languages which some people here may have not heard of before. I gave some (albeit very brief) information about why they may be more suitable for data protection. Both languages are stable and there exist some decent development tools for them. Maybe, just maybe, one reader here has decided to look them up and adopt them, even for a small project.

On the other hand, you ranted on about the real world, said something stupid about sheep, and corrected a spelling mistake. You told me to go write my own language for some reason (after a post where I gave examples of other languages I thought were good specifically for data protection). When I told you I had, you said something about talking to someone, whatever that was supposed to mean.

All in all, do the world a favour and shut up.

2007-11-27 Reply Admin

Bored Bystander:
real_aardvark:
Bored Bystander:
My point was if you want to enforce proper data protection, which is the point of this wtf, you should use separate interfaces. Just because C++ is a real world language (go on, define real world language, moron) does not make it perfect. Its method of enforcing proper data protection is quite inadequate.
Separating interfaces from the definitions is not a Tiny semantic difference. In fact, if you had bothered to actually do any reading about Modula-3, you would discover that its compiler will only recompile modules if any interfaces they use have changed, which was also a topic mentioned earlier.
OK.

A "real world" language is a language that is used in the real world.

Good enough definition for you?

Now, granted, this includes things like Java and VB6 and Cobol and even TRS-Basic, which I find incomprehensible but will accept because they give people warm and fuzzy feelings, and it doesn't really include functional languages from Lisp through Scheme to Haskell (or vice-versa -- I forget); although I dearly wish that it would.

It doesn't really include Oberon or Modula-3, though.

Nice to know you've written your own language. At least, now, you have somebody to talk to.

Nobody told me to use C++. I happen to find it useful in my line of work. I also use Perl, where appropriate, and Python, where I'm allowed to do so. And anything else that comes up.

Really.

Don't get your panties in a twist.

Great definition, "it's a real world language because I say so". In my original post, which you obviously did not read correctly, I did not say that Oberon and Modula-3 were widely used languages. However, they are usable languages, for a lot of the situations where C++ is used. So why not use them? If more people used them, then would you consider them a "real world language"?

You use Python? Until relatively recently (compared to Perl, C++, etc), Python was unheard of. What made you decide to use this "real world language"? A language that changes its semantics nearly everyday? Have you even looked at any non-"real world languages"?

To recap:

I named some other languages which some people here may have not heard of before. I gave some (albeit very brief) information about why they may be more suitable for data protection. Both languages are stable and there exist some decent development tools for them. Maybe, just maybe, one reader here has decided to look them up and adopt them, even for a small project.

On the other hand, you ranted on about the real world, said something stupid about sheep, and corrected a spelling mistake. You told me to go write my own language for some reason (after a post where I gave examples of other languages I thought were good specifically for data protection). When I told you I had, you said something about talking to someone, whatever that was supposed to mean.

All in all, do the world a favour and shut up.

You would do well to follow your own advice. Both of you are boring me to tears.

2007-11-28 Reply Admin

mudkip:
You would do well to follow your own advice. Both of you are boring me to tears.

Accepted. Still, I can't believe you read all that.

2013-12-15 Reply Admin

Sometimes programmers run their programs on more than one system. Sometimes the differences between systems cause differences between fully optimised machine code.

Sometimes programmers use really shitty compilers/linkers. If your compiler/linker can't automatically inline accessors of every variety, don't use it. Find one that performs this optimisation, which shouldn't be difficult considering the complex optimisations most common compilers/linkers perform (eg. dead code elimination).

If it turns out that your compiler/linker is poor, but you can't change your choice, then that's a small wtf. Profile your code to determine which functions to look at optimising. If you don't perform this step, then you're committing a much larger wtf. As computers/compilers/linkers can vary so significantly, it may be that the optimisation you're choosing to perform manually may cause other parts of the system to slow down. How would you know, unless you were to take the time to produce and compare profiler stats of the program before and after?

If it turns out that there's a more significant optimisation to perform, you probably won't even need to perform this micro-optimisation. If profiling and testing proves that the optimisation produces no negative affects, then I suggest finding an open-source C++ compiler so you can modify it to perform the micro-optimisation automatically.

2013-12-15 Reply Admin

I know what you're trying to say here, and it's a good thing, but...

Please show me where in the C# specification it says that C# fields are "insanely fast racing C++ fields"?

Please show me where in the Java specification it says that Java is a "RAD system"?

2013-12-15 Reply Admin

Please show me what part of the C++ specification (n3337.pdf, IIRC) makes you believe that function "actually ends up being a push on the stack"?

Safety Critical Encapsulation

Leave a comment on “Safety Critical Encapsulation”