|
|
Most users don't need it. But developers certainly do, some programs do not have a UI of any sort, graphical or otherwise, beyond command line arguments, and it may not make sense to add one (like most compilers), so developers and power users need a way to interact with them (creating and editing a shortcut is not an acceptable solution).
|
|
|
|
|
It shouldn't, and I hope it doesn't, but I expect to give Win8 a pass anyway so it doesn't really matter to me.
I currently use Win7 and I spend most of my day at the command line because I write mostly console apps and backend code.
One of the things that struck me as odd about the Macintosh (80s, 90s) was that it didn't seem to have a command line and I wondered how anyone could do any serious development on it. I understand that the more recent Unix-based Mac OS does have a command line, so I hope that shows how important the command line is.
Personally, I still want an OS that will boot to and be usable at the command line without loading the GUI.
|
|
|
|
|
PIEBALDconsult wrote: Personally, I still want an OS that will boot to and be usable at the command line without loading the GUI.
You can configure Linux to do that I think, and switching between multiple text and GUI shells is easy (something like Ctrl+Alt+F[number of the shell], I don't remember exactly if those are the correct modifier keys). Every Linux based OS I've used had at least two (maybe four?) text-only shell sessions available by default, and usually a couple GUI shells too. You don't even need to log off/lock your session/etc. to switch users using that.
|
|
|
|
|
For most linux installs I do here at work and even at home I do not even install the GUI at all. It's certainly not needed for a fileserver that is not normally used at the console. > 99% of the time I do administration via a ssh session usually from windows putty and use screen to have many virtual console windows inside a single ssh connection.
John
modified 8-Aug-12 10:29am.
|
|
|
|
|
I know a lot of developers who do already, and a lot who don't.
*shrug*
|
|
|
|
|
Considerable efforts have been invested by many different organizations in the past on the development of coding standards for the C programming language. The intent of this standard is not to duplicate the earlier work but to collect the best available insights in a
form that can help us improve the safety and reliability of our code. By conforming to a single institutional standard, rather than maintaining a multitude of project and mission specific standards, we can achieve greater consistency of code quality at JPL. Want to write code for spaceships? Start here.
|
|
|
|
|
Rule 16 (use of assertions)
Assertions shall be used to perform basic sanity checks throughout the code. All functions of more than 10 lines should have at least one assertion.
|
|
|
|
|
For what their doing, it's probably better to crash the program than to use incorrect values in and crash the hardware...literally.
|
|
|
|
|
oh sure.
but what if you can't find something to assert on in those ten lines?
|
|
|
|
|
That's why it says "should" not "shall".
|
|
|
|
|
right. but you should have one in there. so you'll be searching for a place to put one.
seems like a distraction.
|
|
|
|
|
Chris Losinger wrote:
but what if you can't find something to assert on in those ten lines?
You split the function. Especially in C, ten lines is about as long as a function should be. Anything longer already looks like a bug nursery.
OTOH, I'm not so sure about assertions in production code in C. Occasionally a function might not be able to do its work, but some function up the call stack might be able to recover sanely - and this might be desirable.
Therefore I prefer a different approach: always check your input, always return an int error code, to let the caller know whether the call completed successfully, and return computation results in a preallocated buffer. This is in fact the way most C code is written. And enforce a rule that return values should always be checked.
|
|
|
|
|
"Do not use goto , setjmp or longjmp ."
Bah. You're no fun anymore.
/ravi
|
|
|
|
|
Now that Visual Studio 2012 is done, we’re busy figuring out what we should do next. For Web optimization, there are a few key scenarios that we know we want to support moving forward. There are also a whole bunch of other scenarios that we’ve either heard from different people or come up with during brainstorming. Here are some of our ideas. What do you want to see in ASP.NET Web Optimization?
|
|
|
|
|
Six years ago, I wrote an article about validation in WPF on Code Project. I also wrote a custom error provider that supported IDataErrorInfo, since, would you believe, WPF in version 3.0 didn't support IDataErrorInfo. Later, I worked on a bunch of open source projects around WPF like Bindable LINQ and Magellan. I was even in the MVVM-hyping, Code Project-link sharing club known as the WPF Disciples for a while. As I look back at WPF, I see a technology that had some good fundamentals, but has been really let down by poor implementation and, more importantly, by a lack of investment. I'm glad those days are behind me.
|
|
|
|
|
Technologies that come from Microsoft's "devdiv" division tend to be short-lived. If you want to invest in a technology that MS takes seriously, look what they use for Windows and Office. That is not going away any time soon.
modified 7-Aug-12 11:45am.
|
|
|
|
|
did they use Winform for Office? or is it Win32/MFC?
dev
|
|
|
|
|
Win32. It predates MFC.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Anna-Jayne Metcalfe wrote: Win32
That is correct for Office client, although there is also a lot of ATL/WTL there. No MFC as far as I know.
Office Server (SharePoint) nowdays uses C# with ASP.NET Web Forms.
|
|
|
|
|
I'm sure some ATL/WTL sneaked in later in parts. With MFC it tends to be harder to do that as it's so monolithic.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
what about recent versions of office? Office 2010?
dev
|
|
|
|
|
Couldn't say - all I know is what's been published on the subject (which is not that much, really).
I'd be very surprised if there was any MFC in the core products though - it just isn't suited to retrofitting in that way.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
I wonder, what's done with WPF ... I've done couple projects using WPF, feels like a waste of time if M$ eventually decides to can it
dev
|
|
|
|
|
I've no idea.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|