If you release your own software under GPL, you must release the source code. Otherwise you haven't released it under the GPL, and FSF can sue you for trademark violation.
Not true: GPL isn't a trademark, and is a redistribution license. The General Public License doesn't place any restrictions on the copyright holder and cannot legally do so.
The GPL only grants rights, and it specifically only grants certain redistribution rights, provided certain conditions are met. If you cannot meet those conditions you cannot redistribute the software. You couldn't legally do so anyway.
If you are the copyright holder, then the GPL doesn't apply to you at all: it is something that you decided should apply to people when they redistribute your software. If you don't give them the ability to satisfy the GPL in order to redistribute your software, then they still cannot redistribute it.
But: If they do get the ability to satisfy the GPL, they can redistribute it- they don't have to, but if they do redistribute it, they must make it possible for whoever they redistribute it to, to satisfy the GPL of the thing that was redistributed.
I still don't understand why the source distribution is compulsory in the way that it is. I would argue, and I'm sure others have, that from a purely "end-user" perspective, including the source code is both confusing and superfluous.
With the GPL, source distribution isn't compulsory. You really should read it. End users don't care about source code and they probably would never ask for it.
In fact, if you're not redistributing someone elses' work, but instead have released your own software under a GPL redistribution license, nobody can redistribute your software unless they have the source code, and you are completely free to decide whether or not you're going to give anyone your source code.
However, once you do give someone the license and ability to redistribute your software to the satisfaction of the GPL, anyone they redistribute your software to automatically gets those same rights.
In this case, Linux isn't your software. It isn't GP2X's software either. They are redistributing it, and as a result, need to provide that written offer. It seems like people want to take them up on it- presumably those that have received the binary, and these people are entitled to do it!
Re:C/C++ dying? What are they smoking?
on
Demise of C++?
·
· Score: 1
Thusly, nobody can figure out C++, and it follows that those people that think they know C++ actually don't.
wait, who's 'post-hoccing' whom, here?
I provided justification in the previous paragraph:
It's too complicated for the thousands of people working on the Linux kernel, and it's too complicated for my audit work. It's too complicated for Bjarne to get even simple details right about, and it's too complicated for Microsoft to avoid these "buffer overflows" that are purportedly so easy to avoid.
You say that these people are simply doesn't know the language, and yet many of these peoplare strong advocates for C++!
I suggest this paragraph with sardonicism, and I hope that's obvious from the next paragraph:
Or, we can simply accept that there are places that having a thin, well defined, and well understood runtime are appropriate, and places where people can get away with not having such.
Whoa there, cowboy! How to do you know MS programs have to "parse more"?
Obviously, because they have bugs! You are probably misreading my statement to say "Microsoft presently does more parsing than is necessary" when I'm actually saying "Microsoft has to do more parsing than they're presently doing" because by not sanitizing input enough, they are making more bugs, and likewise, by being more paranoid, they're leaving themselves open to implement more, new bugs.
In contrast, by selecting a format that doesn't demand a complex parser to prove correctness, there is less code written, and it's easier to audit and there are frequently fewer bugs.
It's possible to have a bloated, more complicated-looking format that might be just as easy or easier than a simpler-looking format to parse.
I think you are making things up and there does not exist a complicated looking format that demands less parsing than a simpler looking format. Please give an example to demonstrate I am wrong.
My guess is that parsing MS formats really isn't that difficult or long for MS's algorithms, given how quickly the average office file loads.
Why would you think for a moment that complex file formats take longer to load?/etc/passwd is colon-delimited and is an extremely simple format to load and save. Nevertheless, on a large site, with tens of thousands of users, doing even simple lookups in it can take an enormous amount of time.
In contrast, some systems use DBM databases for storing password information. DBM is a much more complicated format than/etc/passwd, but does load faster. Fortunately, the various DBM-formats have been under review long enough that most people generally accept that at least some DBM are just complicated enough to get the job done, and not "over" complicated.
Even if Office secretly latches onto the OS somehow for a performance boost, loading that file into memory still requires CPU cycles and hard drive reads to load into memory.
You're basing this on the assumption that complicated formats have to load more slowly, which I have demonstrated to be incorrect.
Additional parsing does incur a performance penalty, but hopefully by selecting a more complicated format, the persons involved were interested in overshadowing that penalty by the structure itself being faster for common usage.
Nevertheless, this doesn't have very much relevance: I don't suspect for a moment that Microsoft used OLE streams in an effort to make things slower, but to make things faster. But by doing so, they've made things less secure.
An often used middle-ground (well, often outside of Microsoft) is to cache the in-memory structure (perhaps in this case, the OLE streams themselves) in a per-user per-machine location such that these cached streams would always be considered "trustworthy".
Unfortunately, this behavior doesn't encourage lock-in, which is why Microsoft has rarely used... But this is less relevant here I think...
They don't fix bugs they know about so they don't break compatability with programs that rely on the bugs.
Unless the bugs are vulnerability vectors this is called 'doing business'. Unlike FLOSSies, software companies write code for profit and part of that means finding workarounds for stupid design mistakes (like using undocumented internals) made by other companies that write software for your platform. Breaking some shareware author's tray icon is not the same as killing Photoshop or Lotus Notes. Read Raymond Chen's blog, you'll be surprised at what lengths they go to to cater to the likes of Symantec, Corel, etc.
They often become vulnerability vectors, and it is admittedly difficult to take a company seriously that says that they are interested in making a secure system when they cannot even factor that into the "cost of doing business".
They don't submit their code for review by the public.
That's a nice philosophical point, but philosophical nonetheless. If I follow your logic then Firefox would have had zero vulnerabilities the day it was released, and that's not the case now, is it? The "many eyes no bugs" mantra goes south in a hurry when you have a 10-million line codebase and a few hundred actually qualified people looking at it.
Post hoc, ergo propter hoc: One doesn't follow the other.
Having the code available means a larger number of people can find vulnerabilities and a larger number of people can contribute fixes. It does not follow that a less vulnerabilities will be found, although it might follow that a less number of vulnerabilities will be exploited.
However, it may also be that the reason a less number of vulnerabilities are exploited are due to the lower deployment size.
Consider then Apache which has a larger deployment than IIS but fewer critical vulnerabilities.
They don't follow security best practices, like turning off services by default.
They didn't, but they do now. Server 2003 ships seriously locked down.
That's still under debate, although I suspect you'll refer to your first argument for rationale.
They make their OS less secure by obfuscating design to make it difficult for competitors.
Yes... no one writes applications for Windows because its design is "obfuscated". Yes.
Very few people write applications that directly compete with Microsoft.
They use propriety data formats.
There you go again with the philosophy.
By having additional lockin, Microsoft surely makes it harder for people to compete with them. This does indeed represent a security risk because formats, when understood, can reveal a great deal of information about the programs that interact with them.
In general programs that parse more, tend to have greater bugs.
By intentionally attempting to make their formats more complicated, they have certainly blocked compatability, but they've also decreased security by (again) making their software more complicated.
They alter the OS to make it work with their programs instead of designing a solid OS so that anyone can make programs run with it.
First you complain on (1) that they don't fix bugs to avoid breaking applications and now you postulate that they break compatibility whenever they feel like it so that it works only with theirs. Which is it?
The parent doesn't postulate that at all. You are again exhibiting faulty logic.
By altering the operating system to meet the needs of the applications, they are introducing more parallel, nearly identically developed subsystems, all with increased potential for bugs. This does indeed cause security problems.
Re:C/C++ dying? What are they smoking?
on
Demise of C++?
·
· Score: 0
and given that ~0.01% of all programming os OS kernel development, and one guy doesn't know the language enough to work out how it can work for his kernel, then the language sucks?
Moron post hoc, ergo propter hoc.
The parent said he didn't know why anyone would use C when C++ was available given certain criterea.
I say, here's my reasons, and here's someone elses' reasons why people would use C instead of C++ despite other criterion.
Ergo, the actors must be ignorant to the language.
I suggest an alternate rationale: C++ is simply too complicated. It's too complicated for the thousands of people working on the Linux kernel, and it's too complicated for my audit work. It's too complicated for Bjarne to get even simple details right about, and it's too complicated for Microsoft to avoid these "buffer overflows" that are purportedly so easy to avoid.
Thusly, nobody can figure out C++, and it follows that those people that think they know C++ actually don't.
Or, we can simply accept that there are places that having a thin, well defined, and well understood runtime are appropriate, and places where people can get away with not having such.
By the way, the authority on C++, Bjarne himself, admits that using C is often easier than porting C++ to targets where memory constraints or timing constraints are important.
GNUstep runs on X11, Cairo, Win32/GDI, and it can also be recompiled on MacOSX.
WxWindows might be able to target lots of platforms, it just does none of them well.
QT on the other hand, is written in a non-standard programming language ("moc C++") in an effort to add features available to Objective-C users for years. Better still: Programming Cocoa in Java or Python isn't anywhere near as unpleseant as writing WxWindows or QT applications in those languages. That's not subjective either.
So being as how GNUstep spans multiple platforms and languages, while WXWindows spans the lowest-common-denominator of multiple platforms and languages, and QT works on less platforms than GNUstep, and in less languages, I'd say that you're completely wrong and have no idea what you're talking about.
That said, I never knew anyone could actually say that this "looks better" than this, but you're welcome to be the first, and if that's how it is, at least I'm productive in the latter...
It started life as a kludged on Modula extension to C.
Simula67, not Modula.
Although it's just Java for Windows, C# is a much more elegant language than C++.
That's like saying a dead badger is more elegant than a dead weasel. I'm not sure it's useful though:)
Everything else here I completely agree with.
Re:C/C++ dying? What are they smoking?
on
Demise of C++?
·
· Score: 2, Informative
Especially since C++ has vastly better techniques for dealing with those [memory leaks and buffer overflows] particular problems.
The compiler allocates memory behind your back, and as a result the programmer has no direct means by which they can free that memory. Buffer overflows are trivially avoided in C, and in my experience (of looking at other peoples' C++ code) they seem to be as common, if not more common.
But seriously, there is absolutely no reason why properly-written C++ can't be precisely as efficient as straight C, and as an added bonus, you get a more strongly-typed language with extra features.
Wow. You sound like Bjarne.
He's wrong too:
2884 Dec 21 16:09 hello1 3836 Dec 21 16:14 hello2
Compiled both with -O2 and -s -- just like he said he did. Guess which one was written in C++?
I've been writing in C and C++ for close to 20 years,
Funny being as how C++ hasn't been stable for 20 years. It hasn't even been stable for 5 years- there are many C++ programs from 15 years ago that won't compile with C++ compilers anymore.
and C++ is just plain a better language than C.
That's subjective. Objectively, C++ has a thicker runtime, requires more memory, is harder to port to new targets than a C compiler, is younger (and less mature) and is a much more complicated language (measured by keywords and syntactic verbosity).
and frankly, I can't understand why anyone with sufficient programming experience, and a real working knowledge of both languages, would voluntarily choose plain C over C++.
Obligatory Linus quote:
* the whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
Of course, I have my own reasons: C++ is simply harder to audit for security purposes because program logic in what is considered authoritatively correct C++ (as per Bjarne himself) is spread out over such a large area.
When writing secure software, that is, software that represents a zero-potential attack vector - but STILL has to cross security boundaries, C++ is simply too complicated. No, this does not have a single thing to do with buffer overflows and memory leaks- parent is right, those are trivially avoided in C, and less so in C++.
I recommend that people use Objective-C when they want to intermix language-assisted object oriented constructs with C code because it accomplishes many things that C++ attempts to do with less verbosity, can do many things that C++ cannot do, and is much easier to audit from a security-standpoint.
No you cannot. std::cin is a global variable. You can overload >> in the class istream but that's not the same thing at all.
That's what's known as overloading streams, which is what cin is.
But that's not what you said, you said... overload cin- something that is actually possible in a language like Objective-C (although I don't know of any Objective-C programmers that would dare to call it "overloading"), but that is not possible in C++.
You can subclass istream and then cin = new istream_descendant provided nobody uses cin in their global constructors (do you know if they do?).
You can also provide a operator>> to a another class or type, and I'm fairly certain this is what you mean by overload- because at this point, cin>>foo can do something useful, but it affects other istreams elsewhere. That is also, often very desireable.
But, there's no way in C++ to actually replace cin with some subclass and make certain that every other class happens to see it that way.
Oddly enough, this is possible in Smalltalk, Objective-C, Java, and Simula67 (IIRC).
I have no idea what you mean by "decomposing" your programs.
Specifically, using object orientation and functional blocks to make everything simpler. i.e. not having a 40,000 line app in one file. C++'s big advantage is that I can do all this without using macros. C++'s big disadvantage is having to use pointers to do this, but C suffered from this as well
qmail is a "mere" 17,040 lines of source, but the longest file is 1,621 lines and the majority are under 20 lines long. There are a total of 305 #define statements, 60 of which qualify as actual macros- none of which are for typing, but simply mere wrappers to avoid typing quite so much- I don't think that's objectable as both GCC's C++ library and Microsoft's MFC use macros for similar reasons.
I don't see how C++ would be needed for any of this. But at this point, it's a little off topic- just my own curiosity.
It's not as safe as Java, and it's a little slower than C.
Accepted.
Near as I can tell, the methodology of C++ is to get as far away from assembly as possible while still maintaining acceptable performance.
Except that moment you need a runtime type-check, a JIT has the ability to beat your performance as it can actually patch the runnable sections.
I used to think this was mere theoretical stuff here, but Java has come a long way...
In any event, I reject that definition of C++'s methodology. Bjarne says:
"I wanted to write efficient systems programs in the styles encouraged by Simula67".
This of course, is not what most C++ programmers do: Using the features styled after Simula67 leads to extremely poor performance, and I don't think (hope?) that's in dispute with anyone except Bjarne himself.
His best quote has to be:
"There are only two kinds of languages: the ones people complain about and the ones nobody uses".
You've admitted puts is better than cout in at least one way.
In any event, this thread is not about whether C++ is better or worse than C, it's about whether rumors about performance and size penalties in C++ are justified, and in many cases it appears the answer is yes.
On top of that you can overload cin.
No you cannot. std::cin is a global variable. You can overload >> in the class istream but that's not the same thing at all.
I like decomposing my programs. C++ lets me do this in a way C cannot.
I have no idea what you mean by "decomposing" your programs. This thread is not about comparing C to C++ as languages, or even comparing puts to cout<<. It's not about what everyone's favorite language is, it's about the problems with C++ - not the language itself- because those problems exist in other languages too- but with the public's general perception of C++.
The perception is that it's not as fast as C, and not as safe as Java. I wasn't going to touch on the latter because I'm of the experience that safe code has very little to do with language itself, but performace IS important.
If the methodology of C++ is to perform operations that are costly in performance and size, then perhaps some attention needs to be given to reposturing C++, changing the methodology of C++, or moving on.
...but it is *you* who is comparing apples with oranges,
Absolutely not. I am comparing two distinctly similar things: The accepted authoritative methodology that is C++ versus the accepted authoritative methodology that is C.
That difference methodology has produced rumor mills similar to the ones you have heard (about all functions being invoked through indirection)- but it isn't the difference in implementation. Consider that Objective-C uses a large amount of message passing, but there's no confusion whatsoever about what a->foo(); does in Objective-C!
I effectively started talking about the speed of C and C++ statically linked code being the same with all things being equal.
I already mentioned that I agree: When you write the subset of C code that is acceptable in C++, most C++ compilers will run at the same speed, with about the same startup time, and the sizes will be about the same. They might even be equal if the compiler is worth anything.
So Bjarne being a lying SOB has nothing to do with my original argument.
It most certainly does! People get this idea about C++ being slower than C because Bjarne says something wrong, people test it, and find out he's a lying SOB.
You started out saying people got these crazy ideas about C++ from some rumor mills of sorts (vtables for procedure calls, for example), and I'm saying no: they got these crazy ideas right from the horses' mouth!
Of course puts() and cout << aren't equivilent. They don't have to be. C++ doesn't have a puts() and the Authority on C++ says calling C's puts() isn't writing C++.
I also hate lots of [other] C++ stuff as well. But in general I like what I can do with it over and above C, and it has made my life a lot better.
That's important! It's really important, and would be a good reason that you could use to urge people to take a look at other parts of the C++ infrastructure instead of what is otherwise considered Modern C++, and especially so considering that you don't like Modern C++ either.
Re:Balkanization
on
Demise of C++?
·
· Score: 1, Redundant
Why on earth are you discussing speed of a SYSTEM CALL!
puts() isn't a system call on UNIX. I don't know what Operating System you're referring to.
What's being compared and discussed is the authority of C++: Bjarne repeatedly states this is the way to go, and that it is not slower nor larger than in C. Bjarne is extremely confused on that point.
No matter what else it does the slow part is entering kernel mode and printing characters to the screen.
No it isn't. Profile it and see for yourself.
You are discussing a 20ns optimization on a 1ms call.
Absolutely not. Profile it and see for yourself.
In any event, the point is not that puts() is faster than cout << but that Bjarne Stroustrup says that cout << is how to write to standard output and that it's not slower or takes up more space than C-code.
I never said that V-tables were as fast as code without them. It is a given that they are not (unless you have some deep machine logic to perform fast v-table lookup)
Accepted.
What I was saying was that the C code will run the same if it is compiled under a c++ or c compiler, whereas a lot of people thought that c++ automatically inserted v-tables and hence was presumed to be slower.
Actually, a lot of C code cannot be compiled by C++ compilers as C++ isn't a strict superset of C. In any event, I hope nobody ever thought what you suggest here, because if C++ compilers DID do this it would make linkage with C code extremely complicated.
You example is flawed as you are comparing apples to oranges. The use of stream insertion will bring in all sorts of crap into the equation while "puts" will not. Hence your "puts" will run faster.
No. The C++ recommended "Hello World" as per Bjarne Stroustrup himself is to use cout. The C recommended "Hello World" as per Kernaghan and Ritchie is to use puts.
I'm not comparing the performance of puts versus puts, nor the performance of C++'s C-linkage versus C's C-linkage, I'm comparing what the inventor and authority of C++ says versus what the inventor and authority of C says.
The authority on C++ is to write code slower than the authority of C. Period.
But try and overload your puts example to output custom data on a generic class by class basis and see how much extra code you have to add
Why would I want to do that? Sounds like you really want to compare apples to oranges.
Once you start using feaures of one language that are not implemented in the other, then simple speed comparisions go out the window.
Why would I want to do that? Sounds like you really want to compare apples to oranges.
Re:We just got tired of being insulted
on
Demise of C++?
·
· Score: -1, Flamebait
We, C++ programmers, just got tired of being insulted all the time, so we don't talk much any more. After all, every time we mention C++ we are told how bad it is and how stupid we all are for using it. Sure, we can rebut all those arguments, but there are so many loud people declaiming them that nobody ever hears us. So, we just shrug, shut up, and go back to writing code. If you don't want to listen, you are only hurting yourselves and your employers.
We, people of Faith, just got tired ot being insulted all the time, so we don't talk much any more. After all, every time we mention our personal God, we are told how bad it is and how stupid we all are for using it. Sure, we can rebut all those arguments, but there are so many loud people declaiming them that nobody ever hears us. So, we just shrug, shut up, and go back to our prayer circles. If you don't want to listen, you are only hurting yourselves and your afterlife.
When the inventor of C++ stops lying about C++, perhaps then we can have rational discourse, but until then, I completely realize that talking to you about C++ is about as useful as talking to you about Santa Clause.
You are now free to return to your alternate universe that requires four different kinds of cast and all kinds of deep magic just to keep up.
Re:Balkanization
on
Demise of C++?
·
· Score: 2, Informative
People incorrectly assuemd that C++ always uses V-tables in order perform any function call
So what is going on here?
cout << "Hello World!" << endl;
The above code uses V-tables, and the above code is what is recommended by C++'s "inventor". The above is slower and produces more machine code than:
puts("Hello World");
Period.
Supporters love to say that's a bad use of C++, or that the compiler could recognize this special code, or that the compiler should do some kinds of deep inlining at compile-time, or that some special CPU will be invented and become general purpose that will make indirect procedure calls (with a possible processor exception) as cheap as direct procedure calls.
The problem is that this is the recommended form of C++, and that if compilers recognized this form, they'd miss others, and that current C++ compilers don't do the kind of deep inlining required, and that special CPU doesn't exist.
But you can't get support for it or put it on the Internet. That's a big difference because you can purchase support for a Linux system on that hardware, but Microsoft (the vendor who brought you that Windows 95) won't sell you support for it.
Can I extend the life of this old 386 with Windows?
Of course! If you'll run a version of windows that isn't supported, and never put it on the Internet, then yes! Depending on how much time and learning you're willing to do, that support can still not be purchased from anyone.
Can I extend the life of this old 386 with Linux?
Of course! You can even get support for it and put it on the Internet! Depending on how much time and learning you're willing to do, that support can be purchased from reasonable commercial entities.
Honestly, nobody asking this question has 300$ to give to Dell.
If you talk to your customers like this, no wonder they hate you.
Ok, so weird stuff MIGHT happen when you perform m.a or m.b or m.c if they are properties because you are actually calling a method, that's undeniable.
Not only that, it's also a problem. If the programmer doesn't know what's going on by reading the code, how is this a good thing? Why is it good to hide even more from the programmer?
But unless reading the property fails entirely,
That's just it, consider a read-property that reads from a database. Now the database is down so the read-property loads garbage but never checks its error- simply "returns 0" or something.
Programmers do this crap all the time in API and nobody ever notices until it starts causing a problem. The programmer using the API might've either assumed that it throws an exception, or that the values were loaded by an earlier call (The constructor?) that checked for errors. Who knows.
There is no chance that reading m.b might suddenly result in a string, if you expected an integer.
So what? Type checking isn't the issue. Type checking isn't even a problem!
What is a problem is that reading m.b might take a long time, draw on the screen, read from the disk, or send data to the network, and nobody will know because the programmer thinks they're just reading a memory location.
The only time the programmer might notice is if they single step into the assignment operation and see their debugger jump into some assembly dump.
And that is just wrong.
Why is it even needed? Because putting () all over the place is ugly?
And you know what? People can read it with or without seeing the documentation or the headers- they understand exactly what would be going on, and that we've got a lot of message send operations (maybe something to optimize there), and several classes/selectors that might be involved.
Introduce properties, and it looks like this:
m.key.value = m.key.value + n.key.value;
And it doesn't cary ANY of the semantic information that either of the two previous examples had. The programmer won't know how fast or slow this'll run (and assume pretty fast), and won't know either getting the value can fail, or have side effects, or etc.
The end result is that we've confused the programmer, and they'll make a mistake. I'm sure the C++ example is hard to read to some people (even some C++ people), so they say the problem is that our C++ here needs to take advantage of overloading and properties so that it'll be easier to read INSTEAD OF making the API itself better, or using intermediates, or anything else that can make the code better, faster, and easier to follow.
Meanwhile, in Objective-C, that construct is fairly common and nobody complains. nil rocks.
Office documents can have executable macros. Microsoft makes this mistake this a lot.
Yes, but they're generally sandboxed to some degree or another. Well, at least they are nowadays.
But they weren't designed that way, and when MS made the change to do that, macros broke. If you have to break legitimate use in order to "fix your problem" then your problem was that you didn't design it well in the first place.
And there are very legitimate reasons for macros in office documents
I completely agree- Files I edit in VIM frequently have lines at the end that invoke some vim commands, but these commands are only able to set presentation options for the file I'm currently working on. Auto-execute or not, there's no vim option that runs an "arbitrary program" for some crazy "extensibility" goal to be met.
Microsoft Office macros on the other hand, can actually gain access to ActiveX controls- and in some cases, can even "install them" (although these days it seems like they have to be signed)- the goal may have been to make it possible to extend the macro system in ways they didn't anticipate, but that's not what happened! What happened was Microsoft introduced a generic mechanism for discovering attack vectors.
Defenders could claim that WMF was invented before the widespread use of networking
And they do (see the other parts of this thread)!
They miss the point. WMF isn't a good design at any point because it's another file format that people are encouraged to TRUST as being content and not code- just like DOC and XLS files are supposed to be documents-- content- and not a program.
It's like someone sending you a JPG file- you don't think for a moment whether you have to trust the sender.
As a result, Microsoft thought of WMF as a JPG as well- and MSIE and MSN messanger load it immediately and transparently.
So apparently, Microsoft was SO CLEVER to make WMF the ultimate extensible graphic format that they FORGOT that it's not a graphic format at all- it's not even a document/content file, but instead a code/program file.
If Microsoft isn't smart enough to know which files are code/program and which ones are document/content how can regular users be expected to know the difference?
True story: My mother in-law used Windows at one point and kept getting virus'd. The advise from everyone was always the same "don't open executable attachments" and she swore she didn't.
One day, I happened to watch her open a executable attachment from her email client and I said "I thought you never opened executable attachments" and she said "It's not! It's a HTML file"
It didn't end in.EXE or.COM or.LNK or.PIF anything like that- and she knew those file extensions were dangerous. But what other ones? What about this ".HTA" file? How was she to know?
Okay, so now she knows about ".HTA" for next time.. What else?
See, the problem here is that she doesn't know. Not only does she not know, but Microsoft doesn't know either. Everyone's screwed because at one point Microsoft thought that the distinction was unimportant.
So these people that say that WMF's were a feature or designed correctly or etc, are missing the point. WMF was and is something that people didn't understand.
Do we stop using.HTA files? No. They're still here, only now they're considered an executable format. What makes WMF so different?
WMF is different because Microsoft made ANOTHER bad choice: and that was that Server Administrators didn't know what they were doing with their MIME types. Of course, they did, but once Microsoft stopped looking at the MIME type and started using the EXTENSION and magic typing, they didn't have to, and so they didn't.
This was introduced also, to solve a problem that didn't exist (do you know of any WMF files that needed some magic extensions?), but once they in
You just repeat your previous statements, still ignoring the fact that when this feature was designed the design was a valid design choice given the requirements at the time.
I never conceded that this was a valid design choice and I still don't. It was NEVER a valid design choice, and it was ALWAYS bad engineering.
Unless of course, your PURPOSE is to confuse the hell out of your users, and if Microsoft wants to state such a thing, I MIGHT concede it was a valid design choice for that.
Comparing UN*X and Windows (especially at the time the choices where made) in this case is actually silly, they're built with completely different approaches.
Absolutely not!
UNIX is of a design over 30 years old, and it's still good. Microsoft made some decisions 20 years ago, that aren't good today.
These are design decisions- not mere implementation problems.
Comparing things this way will allow anyone to call anything "bad engineering" (like american cars for example).
Absolutely not!
You say the feature was desired at one point. So what. If they took a system with features designed in that fashion and tried to shoehorn them into a system that was considered "modern" in the 1970's and THEY COULDN'T DO IT RIGHT, then that's absolutely called "bad engineering".
They didn't engineer bringing their Windows 3.0 technologies into Windows NT well, and it is easy to say that they did it poorly. That's "bad engineering" by any definition of the word- not the subjective form that you bring up.
First of all, in practice there is never any doubt whether you are using a property or a variable. You can not be handed a variable and not know if you are really dealing with a property.
Sure there is. There's doubt as to whether a was a member or not- Even though I repetedly referred to API issues with properties in this thread.
In all other cases you will be explicitly stating which object you want to use the property from. It would look like this: 'myObject.a:= myObject.a + myObject.b'. This is not much different from the case where a and b are methods of myObject, the only difference is that myObject.a accepts assignments. Again using Delphi as model, this is just a shorthand notation for writing 'myObject.SetA(myObject.a + myObject.b)'.
Nobody is talking about Delphi except for you. Delphi is trying to be a better pascal, and if you ask me, that's not a very difficult thing to do.
C++ on the other hand, is trying to be a better C. In C, m.a = m.b + m.cNEVER means anything but m.a is equal to the machine-sum of m.b and m.c (which of course includes things like overflows).
It doesn't mean assign(&m.a, sum(&m.b, &m.c)) and nobody thinks it should either. That's why properties were invented, so that people wouldn't have to think it should mean that.
Properties can not be global. They are always part of some class. And it is always obvious which class they belong to.
Sure they can: That's what a static, public property would be.
If + was overloaded, it would in fact be a member function of the property 'a'.
I say properties are bad, I'm no where saying overloading operatiors is good. That's not good either for all the same reasons I'm giving here.
How about blaming the designer of the api/lib/whatever for his misuse/abuse of properties instead of the properties mechanism itself?
Because it's not the API fault: They could be using the tool completely correctly (by someone's definition of the word) and someone looking at code calling that API wouldn't know it.
They might get curious if they see something like this:
while (a = b);
But chances are they'd think that they meant == instead of = - and THAT's the fault of the mechanism itself.
By the way, I use goto and when I do, people can see exactly where any why I'm using it. Not so with properties, which is why I said comparing the two doesn't work very well...
That bridge was already crossed back when operator-overloading was first allowed. Your example statement "a = a + b" might be invoking operator+() and operator=(), which could randomly throw exceptions or take a long time to complete.
I think operator overloading is a bad idea for the same reasons.
The bigger objection to properties is that they do a poor job of emulating true public member variables. The goal of properties is that they allow necessary side effects to happen when a member is changed.
That's why I recommend when writing code intended to do those kinds of side effects (in your example code) you'd write a:
IM_EXPECTING_SERIOUS_MAGIC (or something like that)
Slashdot Mirror
If you release your own software under GPL, you must release the source code. Otherwise you haven't released it under the GPL, and FSF can sue you for trademark violation.
Not true: GPL isn't a trademark, and is a redistribution license. The General Public License doesn't place any restrictions on the copyright holder and cannot legally do so.
The GPL only grants rights, and it specifically only grants certain redistribution rights, provided certain conditions are met. If you cannot meet those conditions you cannot redistribute the software. You couldn't legally do so anyway.
If you are the copyright holder, then the GPL doesn't apply to you at all: it is something that you decided should apply to people when they redistribute your software. If you don't give them the ability to satisfy the GPL in order to redistribute your software, then they still cannot redistribute it.
But: If they do get the ability to satisfy the GPL, they can redistribute it- they don't have to, but if they do redistribute it, they must make it possible for whoever they redistribute it to, to satisfy the GPL of the thing that was redistributed.
I still don't understand why the source distribution is compulsory in the way that it is. I would argue, and I'm sure others have, that from a purely "end-user" perspective, including the source code is both confusing and superfluous.
With the GPL, source distribution isn't compulsory. You really should read it. End users don't care about source code and they probably would never ask for it.
In fact, if you're not redistributing someone elses' work, but instead have released your own software under a GPL redistribution license, nobody can redistribute your software unless they have the source code, and you are completely free to decide whether or not you're going to give anyone your source code.
However, once you do give someone the license and ability to redistribute your software to the satisfaction of the GPL, anyone they redistribute your software to automatically gets those same rights.
In this case, Linux isn't your software. It isn't GP2X's software either. They are redistributing it, and as a result, need to provide that written offer. It seems like people want to take them up on it- presumably those that have received the binary, and these people are entitled to do it!
I provided justification in the previous paragraph:You say that these people are simply doesn't know the language, and yet many of these peoplare strong advocates for C++!
I suggest this paragraph with sardonicism, and I hope that's obvious from the next paragraph:Which is really what you had problems with.
Whoa there, cowboy! How to do you know MS programs have to "parse more"?
/etc/passwd is colon-delimited and is an extremely simple format to load and save. Nevertheless, on a large site, with tens of thousands of users, doing even simple lookups in it can take an enormous amount of time.
/etc/passwd, but does load faster. Fortunately, the various DBM-formats have been under review long enough that most people generally accept that at least some DBM are just complicated enough to get the job done, and not "over" complicated.
Obviously, because they have bugs! You are probably misreading my statement to say "Microsoft presently does more parsing than is necessary" when I'm actually saying "Microsoft has to do more parsing than they're presently doing" because by not sanitizing input enough, they are making more bugs, and likewise, by being more paranoid, they're leaving themselves open to implement more, new bugs.
In contrast, by selecting a format that doesn't demand a complex parser to prove correctness, there is less code written, and it's easier to audit and there are frequently fewer bugs.
It's possible to have a bloated, more complicated-looking format that might be just as easy or easier than a simpler-looking format to parse.
I think you are making things up and there does not exist a complicated looking format that demands less parsing than a simpler looking format. Please give an example to demonstrate I am wrong.
My guess is that parsing MS formats really isn't that difficult or long for MS's algorithms, given how quickly the average office file loads.
Why would you think for a moment that complex file formats take longer to load?
In contrast, some systems use DBM databases for storing password information. DBM is a much more complicated format than
Even if Office secretly latches onto the OS somehow for a performance boost, loading that file into memory still requires CPU cycles and hard drive reads to load into memory.
You're basing this on the assumption that complicated formats have to load more slowly, which I have demonstrated to be incorrect.
Additional parsing does incur a performance penalty, but hopefully by selecting a more complicated format, the persons involved were interested in overshadowing that penalty by the structure itself being faster for common usage.
Nevertheless, this doesn't have very much relevance: I don't suspect for a moment that Microsoft used OLE streams in an effort to make things slower, but to make things faster. But by doing so, they've made things less secure.
An often used middle-ground (well, often outside of Microsoft) is to cache the in-memory structure (perhaps in this case, the OLE streams themselves) in a per-user per-machine location such that these cached streams would always be considered "trustworthy".
Unfortunately, this behavior doesn't encourage lock-in, which is why Microsoft has rarely used... But this is less relevant here I think...
They often become vulnerability vectors, and it is admittedly difficult to take a company seriously that says that they are interested in making a secure system when they cannot even factor that into the "cost of doing business". That's a nice philosophical point, but philosophical nonetheless. If I follow your logic then Firefox would have had zero vulnerabilities the day it was released, and that's not the case now, is it? The "many eyes no bugs" mantra goes south in a hurry when you have a 10-million line codebase and a few hundred actually qualified people looking at it.
Post hoc, ergo propter hoc: One doesn't follow the other.
Having the code available means a larger number of people can find vulnerabilities and a larger number of people can contribute fixes. It does not follow that a less vulnerabilities will be found, although it might follow that a less number of vulnerabilities will be exploited.
However, it may also be that the reason a less number of vulnerabilities are exploited are due to the lower deployment size.
Consider then Apache which has a larger deployment than IIS but fewer critical vulnerabilities. They didn't, but they do now. Server 2003 ships seriously locked down.
That's still under debate, although I suspect you'll refer to your first argument for rationale. Yes... no one writes applications for Windows because its design is "obfuscated". Yes.
Very few people write applications that directly compete with Microsoft. There you go again with the philosophy.
By having additional lockin, Microsoft surely makes it harder for people to compete with them. This does indeed represent a security risk because formats, when understood, can reveal a great deal of information about the programs that interact with them.
In general programs that parse more, tend to have greater bugs.
By intentionally attempting to make their formats more complicated, they have certainly blocked compatability, but they've also decreased security by (again) making their software more complicated. First you complain on (1) that they don't fix bugs to avoid breaking applications and now you postulate that they break compatibility whenever they feel like it so that it works only with theirs. Which is it?
The parent doesn't postulate that at all. You are again exhibiting faulty logic.
By altering the operating system to meet the needs of the applications, they are introducing more parallel, nearly identically developed subsystems, all with increased potential for bugs. This does indeed cause security problems.
and given that ~0.01% of all programming os OS kernel development, and one guy doesn't know the language enough to work out how it can work for his kernel, then the language sucks?
Moron post hoc, ergo propter hoc.
The parent said he didn't know why anyone would use C when C++ was available given certain criterea.
I say, here's my reasons, and here's someone elses' reasons why people would use C instead of C++ despite other criterion.
Ergo, the actors must be ignorant to the language.
I suggest an alternate rationale: C++ is simply too complicated. It's too complicated for the thousands of people working on the Linux kernel, and it's too complicated for my audit work. It's too complicated for Bjarne to get even simple details right about, and it's too complicated for Microsoft to avoid these "buffer overflows" that are purportedly so easy to avoid.
Thusly, nobody can figure out C++, and it follows that those people that think they know C++ actually don't.
Or, we can simply accept that there are places that having a thin, well defined, and well understood runtime are appropriate, and places where people can get away with not having such.
By the way, the authority on C++, Bjarne himself, admits that using C is often easier than porting C++ to targets where memory constraints or timing constraints are important.
GNUstep runs on X11, Cairo, Win32/GDI, and it can also be recompiled on MacOSX.
WxWindows might be able to target lots of platforms, it just does none of them well.
QT on the other hand, is written in a non-standard programming language ("moc C++") in an effort to add features available to Objective-C users for years. Better still: Programming Cocoa in Java or Python isn't anywhere near as unpleseant as writing WxWindows or QT applications in those languages. That's not subjective either.
So being as how GNUstep spans multiple platforms and languages, while WXWindows spans the lowest-common-denominator of multiple platforms and languages, and QT works on less platforms than GNUstep, and in less languages, I'd say that you're completely wrong and have no idea what you're talking about.
That said, I never knew anyone could actually say that this "looks better" than this, but you're welcome to be the first, and if that's how it is, at least I'm productive in the latter...
let me clarify: sure I can code objective-c on my windows/linux/whatever box. But I wont have a decent API (cocoa). So why, please?
It's called GNUstep and yes, it works just fine.
It started life as a kludged on Modula extension to C.
:)
Simula67, not Modula.
Although it's just Java for Windows, C# is a much more elegant language than C++.
That's like saying a dead badger is more elegant than a dead weasel. I'm not sure it's useful though
Everything else here I completely agree with.
Especially since C++ has vastly better techniques for dealing with those [memory leaks and buffer overflows] particular problems.
The compiler allocates memory behind your back, and as a result the programmer has no direct means by which they can free that memory. Buffer overflows are trivially avoided in C, and in my experience (of looking at other peoples' C++ code) they seem to be as common, if not more common.
But seriously, there is absolutely no reason why properly-written C++ can't be precisely as efficient as straight C, and as an added bonus, you get a more strongly-typed language with extra features.
Wow. You sound like Bjarne.
He's wrong too:
2884 Dec 21 16:09 hello1
3836 Dec 21 16:14 hello2
Compiled both with -O2 and -s -- just like he said he did. Guess which one was written in C++?
I've been writing in C and C++ for close to 20 years,
Funny being as how C++ hasn't been stable for 20 years. It hasn't even been stable for 5 years- there are many C++ programs from 15 years ago that won't compile with C++ compilers anymore.
and C++ is just plain a better language than C.
That's subjective. Objectively, C++ has a thicker runtime, requires more memory, is harder to port to new targets than a C compiler, is younger (and less mature) and is a much more complicated language (measured by keywords and syntactic verbosity).
and frankly, I can't understand why anyone with sufficient programming experience, and a real working knowledge of both languages, would voluntarily choose plain C over C++.
Obligatory Linus quote:
* the whole C++ exception handling thing is fundamentally broken. It's especially broken for kernels.
* any compiler or language that likes to hide things like memory allocations behind your back just isn't a good choice for a kernel.
Of course, I have my own reasons: C++ is simply harder to audit for security purposes because program logic in what is considered authoritatively correct C++ (as per Bjarne himself) is spread out over such a large area.
When writing secure software, that is, software that represents a zero-potential attack vector - but STILL has to cross security boundaries, C++ is simply too complicated. No, this does not have a single thing to do with buffer overflows and memory leaks- parent is right, those are trivially avoided in C, and less so in C++.
I recommend that people use Objective-C when they want to intermix language-assisted object oriented constructs with C code because it accomplishes many things that C++ attempts to do with less verbosity, can do many things that C++ cannot do, and is much easier to audit from a security-standpoint.
But that's not what you said, you said
You can subclass istream and then cin = new istream_descendant provided nobody uses cin in their global constructors (do you know if they do?).
You can also provide a operator>> to a another class or type, and I'm fairly certain this is what you mean by overload- because at this point, cin>>foo can do something useful, but it affects other istreams elsewhere. That is also, often very desireable.
But, there's no way in C++ to actually replace cin with some subclass and make certain that every other class happens to see it that way.
Oddly enough, this is possible in Smalltalk, Objective-C, Java, and Simula67 (IIRC).
Specifically, using object orientation and functional blocks to make everything simpler. i.e. not having a 40,000 line app in one file. C++'s big advantage is that I can do all this without using macros. C++'s big disadvantage is having to use pointers to do this, but C suffered from this as well
qmail is a "mere" 17,040 lines of source, but the longest file is 1,621 lines and the majority are under 20 lines long. There are a total of 305 #define statements, 60 of which qualify as actual macros- none of which are for typing, but simply mere wrappers to avoid typing quite so much- I don't think that's objectable as both GCC's C++ library and Microsoft's MFC use macros for similar reasons.
I don't see how C++ would be needed for any of this. But at this point, it's a little off topic- just my own curiosity.
It's not as safe as Java, and it's a little slower than C.
Accepted.
Near as I can tell, the methodology of C++ is to get as far away from assembly as possible while still maintaining acceptable performance.
Except that moment you need a runtime type-check, a JIT has the ability to beat your performance as it can actually patch the runnable sections.
I used to think this was mere theoretical stuff here, but Java has come a long way...
In any event, I reject that definition of C++'s methodology. Bjarne says:This of course, is not what most C++ programmers do: Using the features styled after Simula67 leads to extremely poor performance, and I don't think (hope?) that's in dispute with anyone except Bjarne himself.
His best quote has to be:How true that's become of C++ today.
OK. puts is faster.
Accepted.
compared to cout, puts sucks.
You've admitted puts is better than cout in at least one way.
In any event, this thread is not about whether C++ is better or worse than C, it's about whether rumors about performance and size penalties in C++ are justified, and in many cases it appears the answer is yes.
On top of that you can overload cin.
No you cannot. std::cin is a global variable. You can overload >> in the class istream but that's not the same thing at all.
I like decomposing my programs. C++ lets me do this in a way C cannot.
I have no idea what you mean by "decomposing" your programs. This thread is not about comparing C to C++ as languages, or even comparing puts to cout<<. It's not about what everyone's favorite language is, it's about the problems with C++ - not the language itself- because those problems exist in other languages too- but with the public's general perception of C++.
The perception is that it's not as fast as C, and not as safe as Java. I wasn't going to touch on the latter because I'm of the experience that safe code has very little to do with language itself, but performace IS important.
If the methodology of C++ is to perform operations that are costly in performance and size, then perhaps some attention needs to be given to reposturing C++, changing the methodology of C++, or moving on.
...but it is *you* who is comparing apples with oranges,
Absolutely not. I am comparing two distinctly similar things: The accepted authoritative methodology that is C++ versus the accepted authoritative methodology that is C.
That difference methodology has produced rumor mills similar to the ones you have heard (about all functions being invoked through indirection)- but it isn't the difference in implementation. Consider that Objective-C uses a large amount of message passing, but there's no confusion whatsoever about what a->foo(); does in Objective-C!
I effectively started talking about the speed of C and C++ statically linked code being the same with all things being equal.
I already mentioned that I agree: When you write the subset of C code that is acceptable in C++, most C++ compilers will run at the same speed, with about the same startup time, and the sizes will be about the same. They might even be equal if the compiler is worth anything.
So Bjarne being a lying SOB has nothing to do with my original argument.
It most certainly does! People get this idea about C++ being slower than C because Bjarne says something wrong, people test it, and find out he's a lying SOB.
You started out saying people got these crazy ideas about C++ from some rumor mills of sorts (vtables for procedure calls, for example), and I'm saying no: they got these crazy ideas right from the horses' mouth!
Of course puts() and cout << aren't equivilent. They don't have to be. C++ doesn't have a puts() and the Authority on C++ says calling C's puts() isn't writing C++.
I also hate lots of [other] C++ stuff as well. But in general I like what I can do with it over and above C, and it has made my life a lot better.
That's important! It's really important, and would be a good reason that you could use to urge people to take a look at other parts of the C++ infrastructure instead of what is otherwise considered Modern C++, and especially so considering that you don't like Modern C++ either.
Why on earth are you discussing speed of a SYSTEM CALL!
puts() isn't a system call on UNIX. I don't know what Operating System you're referring to.
What's being compared and discussed is the authority of C++: Bjarne repeatedly states this is the way to go, and that it is not slower nor larger than in C. Bjarne is extremely confused on that point.
No matter what else it does the slow part is entering kernel mode and printing characters to the screen.
No it isn't. Profile it and see for yourself.
You are discussing a 20ns optimization on a 1ms call.
Absolutely not. Profile it and see for yourself.
In any event, the point is not that puts() is faster than cout << but that Bjarne Stroustrup says that cout << is how to write to standard output and that it's not slower or takes up more space than C-code.
I never said that V-tables were as fast as code without them. It is a given that they are not (unless you have some deep machine logic to perform fast v-table lookup)
Accepted.
What I was saying was that the C code will run the same if it is compiled under a c++ or c compiler, whereas a lot of people thought that c++ automatically inserted v-tables and hence was presumed to be slower.
Actually, a lot of C code cannot be compiled by C++ compilers as C++ isn't a strict superset of C. In any event, I hope nobody ever thought what you suggest here, because if C++ compilers DID do this it would make linkage with C code extremely complicated.
You example is flawed as you are comparing apples to oranges. The use of stream insertion will bring in all sorts of crap into the equation while "puts" will not. Hence your "puts" will run faster.
No. The C++ recommended "Hello World" as per Bjarne Stroustrup himself is to use cout. The C recommended "Hello World" as per Kernaghan and Ritchie is to use puts.
I'm not comparing the performance of puts versus puts, nor the performance of C++'s C-linkage versus C's C-linkage, I'm comparing what the inventor and authority of C++ says versus what the inventor and authority of C says.
The authority on C++ is to write code slower than the authority of C. Period.
But try and overload your puts example to output custom data on a generic class by class basis and see how much extra code you have to add
Why would I want to do that? Sounds like you really want to compare apples to oranges.
Once you start using feaures of one language that are not implemented in the other, then simple speed comparisions go out the window.
Why would I want to do that? Sounds like you really want to compare apples to oranges.
You are now free to return to your alternate universe that requires four different kinds of cast and all kinds of deep magic just to keep up.
People incorrectly assuemd that C++ always uses V-tables in order perform any function call
So what is going on here?
cout << "Hello World!" << endl;
The above code uses V-tables, and the above code is what is recommended by C++'s "inventor". The above is slower and produces more machine code than:
puts("Hello World");
Period.
Supporters love to say that's a bad use of C++, or that the compiler could recognize this special code, or that the compiler should do some kinds of deep inlining at compile-time, or that some special CPU will be invented and become general purpose that will make indirect procedure calls (with a possible processor exception) as cheap as direct procedure calls.
The problem is that this is the recommended form of C++, and that if compilers recognized this form, they'd miss others, and that current C++ compilers don't do the kind of deep inlining required, and that special CPU doesn't exist.
Actually I CAN run Windows 95 on my 486 66Mhz,
But you can't get support for it or put it on the Internet. That's a big difference because you can purchase support for a Linux system on that hardware, but Microsoft (the vendor who brought you that Windows 95) won't sell you support for it.
If you talk to your customers like this, no wonder they hate you.
Ok, so weird stuff MIGHT happen when you perform m.a or m.b or m.c if they are properties because you are actually calling a method, that's undeniable.
Not only that, it's also a problem. If the programmer doesn't know what's going on by reading the code, how is this a good thing? Why is it good to hide even more from the programmer?
But unless reading the property fails entirely,
That's just it, consider a read-property that reads from a database. Now the database is down so the read-property loads garbage but never checks its error- simply "returns 0" or something.
Programmers do this crap all the time in API and nobody ever notices until it starts causing a problem. The programmer using the API might've either assumed that it throws an exception, or that the values were loaded by an earlier call (The constructor?) that checked for errors. Who knows.
There is no chance that reading m.b might suddenly result in a string, if you expected an integer.
So what? Type checking isn't the issue. Type checking isn't even a problem!
What is a problem is that reading m.b might take a long time, draw on the screen, read from the disk, or send data to the network, and nobody will know because the programmer thinks they're just reading a memory location.
The only time the programmer might notice is if they single step into the assignment operation and see their debugger jump into some assembly dump.
And that is just wrong.
Why is it even needed? Because putting () all over the place is ugly?
I've seen real code that looks like this:
m.update(m.key(),
m.add(m.value(m.key()),
n.value(n.key())));
That in Objective-C would be written as:
[m update:[m key]
withValue:[m add:[[m key] value]
to:[[n key] value]]];
And you know what? People can read it with or without seeing the documentation or the headers- they understand exactly what would be going on, and that we've got a lot of message send operations (maybe something to optimize there), and several classes/selectors that might be involved.
Introduce properties, and it looks like this:
m.key.value = m.key.value + n.key.value;
And it doesn't cary ANY of the semantic information that either of the two previous examples had. The programmer won't know how fast or slow this'll run (and assume pretty fast), and won't know either getting the value can fail, or have side effects, or etc.
The end result is that we've confused the programmer, and they'll make a mistake. I'm sure the C++ example is hard to read to some people (even some C++ people), so they say the problem is that our C++ here needs to take advantage of overloading and properties so that it'll be easier to read INSTEAD OF making the API itself better, or using intermediates, or anything else that can make the code better, faster, and easier to follow.
Meanwhile, in Objective-C, that construct is fairly common and nobody complains. nil rocks.
Yes, but they're generally sandboxed to some degree or another. Well, at least they are nowadays.
.EXE or .COM or .LNK or .PIF anything like that- and she knew those file extensions were dangerous. But what other ones? What about this ".HTA" file? How was she to know?
.HTA files? No. They're still here, only now they're considered an executable format. What makes WMF so different?
But they weren't designed that way, and when MS made the change to do that, macros broke. If you have to break legitimate use in order to "fix your problem" then your problem was that you didn't design it well in the first place.
And there are very legitimate reasons for macros in office documents
I completely agree- Files I edit in VIM frequently have lines at the end that invoke some vim commands, but these commands are only able to set presentation options for the file I'm currently working on. Auto-execute or not, there's no vim option that runs an "arbitrary program" for some crazy "extensibility" goal to be met.
Microsoft Office macros on the other hand, can actually gain access to ActiveX controls- and in some cases, can even "install them" (although these days it seems like they have to be signed)- the goal may have been to make it possible to extend the macro system in ways they didn't anticipate, but that's not what happened! What happened was Microsoft introduced a generic mechanism for discovering attack vectors.
Defenders could claim that WMF was invented before the widespread use of networking
And they do (see the other parts of this thread)!
They miss the point. WMF isn't a good design at any point because it's another file format that people are encouraged to TRUST as being content and not code- just like DOC and XLS files are supposed to be documents-- content- and not a program.
It's like someone sending you a JPG file- you don't think for a moment whether you have to trust the sender.
As a result, Microsoft thought of WMF as a JPG as well- and MSIE and MSN messanger load it immediately and transparently.
So apparently, Microsoft was SO CLEVER to make WMF the ultimate extensible graphic format that they FORGOT that it's not a graphic format at all- it's not even a document/content file, but instead a code/program file.
If Microsoft isn't smart enough to know which files are code/program and which ones are document/content how can regular users be expected to know the difference?
True story: My mother in-law used Windows at one point and kept getting virus'd. The advise from everyone was always the same "don't open executable attachments" and she swore she didn't.
One day, I happened to watch her open a executable attachment from her email client and I said "I thought you never opened executable attachments" and she said "It's not! It's a HTML file"
It didn't end in
Okay, so now she knows about ".HTA" for next time.. What else?
See, the problem here is that she doesn't know. Not only does she not know, but Microsoft doesn't know either. Everyone's screwed because at one point Microsoft thought that the distinction was unimportant.
So these people that say that WMF's were a feature or designed correctly or etc, are missing the point. WMF was and is something that people didn't understand.
Do we stop using
WMF is different because Microsoft made ANOTHER bad choice: and that was that Server Administrators didn't know what they were doing with their MIME types. Of course, they did, but once Microsoft stopped looking at the MIME type and started using the EXTENSION and magic typing, they didn't have to, and so they didn't.
This was introduced also, to solve a problem that didn't exist (do you know of any WMF files that needed some magic extensions?), but once they in
You just repeat your previous statements, still ignoring the fact that when this feature was designed the design was a valid design choice given the requirements at the time.
I never conceded that this was a valid design choice and I still don't. It was NEVER a valid design choice, and it was ALWAYS bad engineering.
Unless of course, your PURPOSE is to confuse the hell out of your users, and if Microsoft wants to state such a thing, I MIGHT concede it was a valid design choice for that.
Comparing UN*X and Windows (especially at the time the choices where made) in this case is actually silly, they're built with completely different approaches.
Absolutely not!
UNIX is of a design over 30 years old, and it's still good. Microsoft made some decisions 20 years ago, that aren't good today.
These are design decisions- not mere implementation problems.
Comparing things this way will allow anyone to call anything "bad engineering" (like american cars for example).
Absolutely not!
You say the feature was desired at one point. So what. If they took a system with features designed in that fashion and tried to shoehorn them into a system that was considered "modern" in the 1970's and THEY COULDN'T DO IT RIGHT, then that's absolutely called "bad engineering".
They didn't engineer bringing their Windows 3.0 technologies into Windows NT well, and it is easy to say that they did it poorly. That's "bad engineering" by any definition of the word- not the subjective form that you bring up.
First of all, in practice there is never any doubt whether you are using a property or a variable. You can not be handed a variable and not know if you are really dealing with a property.
:= myObject.a + myObject.b'. This is not much different from the case where a and b are methods of myObject, the only difference is that myObject.a accepts assignments. Again using Delphi as model, this is just a shorthand notation for writing 'myObject.SetA(myObject.a + myObject.b)'.
Sure there is. There's doubt as to whether a was a member or not- Even though I repetedly referred to API issues with properties in this thread.
In all other cases you will be explicitly stating which object you want to use the property from. It would look like this: 'myObject.a
Nobody is talking about Delphi except for you. Delphi is trying to be a better pascal, and if you ask me, that's not a very difficult thing to do.
C++ on the other hand, is trying to be a better C. In C, m.a = m.b + m.c NEVER means anything but m.a is equal to the machine-sum of m.b and m.c (which of course includes things like overflows).
It doesn't mean assign(&m.a, sum(&m.b, &m.c)) and nobody thinks it should either. That's why properties were invented, so that people wouldn't have to think it should mean that.
Properties can not be global. They are always part of some class. And it is always obvious which class they belong to.
Sure they can: That's what a static, public property would be.
If + was overloaded, it would in fact be a member function of the property 'a'.
I say properties are bad, I'm no where saying overloading operatiors is good. That's not good either for all the same reasons I'm giving here.
How about blaming the designer of the api/lib/whatever for his misuse/abuse of properties instead of the properties mechanism itself?
Because it's not the API fault: They could be using the tool completely correctly (by someone's definition of the word) and someone looking at code calling that API wouldn't know it.
They might get curious if they see something like this:
while (a = b);
But chances are they'd think that they meant == instead of = - and THAT's the fault of the mechanism itself.
By the way, I use goto and when I do, people can see exactly where any why I'm using it. Not so with properties, which is why I said comparing the two doesn't work very well...
That bridge was already crossed back when operator-overloading was first allowed. Your example statement "a = a + b" might be invoking operator+() and operator=(), which could randomly throw exceptions or take a long time to complete.
:)
I think operator overloading is a bad idea for the same reasons.
The bigger objection to properties is that they do a poor job of emulating true public member variables. The goal of properties is that they allow necessary side effects to happen when a member is changed.
That's why I recommend when writing code intended to do those kinds of side effects (in your example code) you'd write a:
IM_EXPECTING_SERIOUS_MAGIC (or something like that)
Immediately surrounding your second foo() call.
properties won't fit well in C++.
Preaching to the choir...