Everything transmitted over any public network (be it the telephone system or the internet) is insecure.
It's not a public network, it's not funded by the government. I pay a private enterprise for communication with my peers be it by phone or by internet.
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
because you get all the things I mentioned: type safety, abstraction & all the good things that go along with that.
Sure, you could limit yourself to C developers, but I'd say that if you're capable of learning the good programming practices that the above features help you with, then you're capable of learning how to implement them in C++.
the point is that when you compile it to native code you instantly remove the portability of the original source. in order to run on a different machine you need to recompile. with a portable bytecode (like java/.net) you only need to compile once.
also, there's no interpreter, the JIT compiler is effectively the same as the second stage of a regular compiler, the main difference is that it runs in the same process as your program, it's the only non-portable binary in the equation.
most manufacturers do not release details of their hardware (or open source drivers) because in most cases they do not own all the technology they would be releasing. In most cases part of the technology is licenesd from other companies.
it doesn't really have anything to do with monopoly, it's just simple market economics. i'd say driver availability pretty much follows relative market share.
i'm sure you could do it quite easily. We're using.NET and building with VS.NET, so we just embed the/.svn/entries XML file as a resource in the exe, and query the revision # at runtime using xpath. I'm sure you could extract the revision # at build-time if you're using something more powerful like ant.
nice. you might add, for clarification, that reference types are instantiated on the heap and value types are (usually) instantiated on the stack. boxing is the operation that moves a value-typed object's data from the stack to the heap. unboxing moves it back.
you can create a reference to a value-typed object either explicitly by passing its stack location as a 'ref' parameter, or implicitly by boxing.
on the other hand, that might not end up being any clearer than what you had;-)
close, but no biscuit. there's plenty of stuff you can do in MSIL (even CLS-compliant stuff) that you can't do with C#. The closest natural representation of MSIL is managed-C++.
With Linux, you use the newest version which is only a couple of months old when installing, with Windows, you get bugs that are years old because a) Windows isn't realeased nearly as often and b) you don't want to waste money on security upgrades.
You're contradicting yourself here. On one hand you say linux is good because it's never more than a few months old, and on the other hand you say windows is bad because it's either old, or you have to download new stuff.
So which is it? Keeping your OS up-to-date is good, or bad?
Yeah, I love the fact that there's a revision number that's global to the whole repository.
We embed that number into each build of our product and our testers file bugs against a particular revision. If I can't repro a bug against my current code, I can just create a new branch at the given revision, compile, and I know I'm using exactly the same code that the tester was running.
i should add: I'd definitely recommend installing TortoiseSVN. Having the SVN operations available as a shell extension is a godsend. For example you can use SVN from within any FileOpen dialog. The only thing it's missing is a directory-diff, but on XP you can show the SVN status of files in explorer by configuring the attribute columns in the details view.
Also, I'd recommend downloading perforce's p4win 3-way merge tool. It's a little better than the one built into TortoiseSVN.
I've just decided. My next machine is going to be absolutely useless for the things I want to do with it, and on top of that, I'm going to bitch about how I can't do those things with it...
Nyquist only works in general if you consider a long duraition (T = 1/lcd(Fin,Fsamp)) of the input. An oscilooscope doesn't have this mathematical luxury, it has to show what it sees right now, hence the innacuracy.
Slashdot Mirror
and when they fail to wiretap your neurons...
The really funny thing about all this is I'll probably get modded as a troll...
Sure, you could limit yourself to C developers, but I'd say that if you're capable of learning the good programming practices that the above features help you with, then you're capable of learning how to implement them in C++.
also, there's no interpreter, the JIT compiler is effectively the same as the second stage of a regular compiler, the main difference is that it runs in the same process as your program, it's the only non-portable binary in the equation.
[1] as long as you disable exceptions & RTTI and stay away from virtual/multiple inheritance & pointers to member functions.
Ah, you're forgetting one important thing: in the US you can sue for $millions in damages, just for the sheer inconvenience.
most manufacturers do not release details of their hardware (or open source drivers) because in most cases they do not own all the technology they would be releasing. In most cases part of the technology is licenesd from other companies.
it doesn't really have anything to do with monopoly, it's just simple market economics. i'd say driver availability pretty much follows relative market share.
i'm sure you could do it quite easily. We're using .NET and building with VS.NET, so we just embed the /.svn/entries XML file as a resource in the exe, and query the revision # at runtime using xpath. I'm sure you could extract the revision # at build-time if you're using something more powerful like ant.
}
Yeah, it's sugar, but so is C++ (you're still getting an exception frame created, and the destructor called when its unwound).
you can create a reference to a value-typed object either explicitly by passing its stack location as a 'ref' parameter, or implicitly by boxing.
on the other hand, that might not end up being any clearer than what you had ;-)
close, but no biscuit. there's plenty of stuff you can do in MSIL (even CLS-compliant stuff) that you can't do with C#. The closest natural representation of MSIL is managed-C++.
Windows NT had, from the start, both a security model (far more comprehensive than Posix's) and the ability to run processes as different users. rtfm.
So which is it? Keeping your OS up-to-date is good, or bad?
so?
We embed that number into each build of our product and our testers file bugs against a particular revision. If I can't repro a bug against my current code, I can just create a new branch at the given revision, compile, and I know I'm using exactly the same code that the tester was running.
Also, I'd recommend downloading perforce's p4win 3-way merge tool. It's a little better than the one built into TortoiseSVN.
If you want to start svnserve as a windows service, google for srvany.exe, it allows you to run a regular win32 exe as a service.
I've just decided. My next machine is going to be absolutely useless for the things I want to do with it, and on top of that, I'm going to bitch about how I can't do those things with it...
exception: divide by zero (a-b)
Nyquist only works in general if you consider a long duraition (T = 1/lcd(Fin,Fsamp)) of the input. An oscilooscope doesn't have this mathematical luxury, it has to show what it sees right now, hence the innacuracy.