Moving forward with a career: C++ or C#?

I'm not asking if C++ is better than C# or vice versa. But if given the option of moving into a new job that exclusively used C++ or one that exclusively used C# (or .NET in general), which would you choose? And I'm looking at this entirely from the view of being a Windows programmer either way.

I ask because I currently use both languages almost evenly and I somewhat feel like if I gave up using C# for C++ only that I would be dooming myself to be stuck with older technology. For example, you're never going to see someone create the latest and greatest web app (or whatever) in STL C++. (I know there is C++.NET, but I'm not counting that.)

Edit: Just to clarify, I'm not talking about which one to learn. I'm already very fluent in both languages.

From stackoverflow

• In terms of future development, I would imagine C# (and .NET in general) as being much more competitive than C++.

  RussellH : But I think it really depends on what kind of software you want to write. If you love mySQL storage engines, or the FreeBSD kernel C/C++ is the only way to go.

  SnOrfus : mysql works perfectly fine under c# - and in fact, the software we write at my workplace is in c# with mysql for storage.

• C# is pretty tightly bound to MS so I would go with C++. Once you've learned it you can apply it to many domains and not just MS specific ones.

  Naturally if you are going to only focus on microsoft technologies then C# is your choice. It's what MS has chosen so it would most likely be best to follow suit.

  Matt J : Does Mono factor into this at all? C# may not yet be as strong a cross-platform choice as C++/Qt/Boost/etc, but to say that its advantages as a language and runtime system cannot be harnessed outside of Windows is a bit disingenuous, no?

  tunnuz : What about Mono?

  Michael Meadows : I'm not sure I agree with the logic. Just because C++ isn't tied to Microsoft doesn't mean that there are going to be more or better job opportunities. Also, C++ tends to get very proprietary because of the liberal use of macros and frameworks, so C++ skills are not completely portable.

  Syntax : I'm not going to cover 'mono' controversy. Naturally the domain changes aspects of the language. However the same patterns, practices, syntax, and use come into play in most if not all domains for C++. The domain changes things, its a given. Search for C++ jobs - then mono and c#. Let the #s talk

  senfo : I'll give you that Microsoft owns the majority of the C# market, but there is often a lot to overcome to make even cross platform libraries truly cross platform.

  srand : Don't forget that Java is pretty similar to C#. So if you want to develop a cross platform application as a C# programmer, picking up Java shouldn't be ~to bad~.

• My personal preference in that situation (I'm in a roughly similar situation with C#, Java, and C++) would probably be to pursue the C# avenue. I'm not sure why, other than it feels like there are more options available in that direction. (You mentioned web apps, for one.)

• I'm pretty sure you'll get plenty of C# votes just because SO is .net-aligned (don't argue - it really is). But I reckon C++ jobs are more techy in the sense of being more related to low-level algorithms and such. Not always, of course, but I think if you like the highest level of challenge in terms of coding, C++ could do it for you.

  Jeff Yates : Don't argue? That's supposed to stop us arguing? It's aligned to whatever happens to be popular when it comes to asking questions. There are more questions for C# because it hasn't been around as long as C++. That's all. Don't argue...because I said, "don't argue". ;)

  Adam Haile : Don't argue about arguing...it's redundant ;)

  rmeador : It's aligned with the readers of Jeff and Joel's blogs, which happen to have a decidedly MS focus, and that's where the majority of SO users come from... I agree with Dmitri.

  David Thornley : SO is certainly not hostile to non-MS issues, but it sure looks more MS-aligned than otherwise.

  Alan : Maybe because .NET devs are less self-sufficient than others ;)

  Erik Forbes : Or more social. =)

• My 2 cents:

  If you currently have job experience with both languages, it doesn't matter which you choose, as you will be able to take a position in the future since you have experience with C++/C#.

  C# is a bit more dynamic, in that the .NET platform has evolved more lately, as it is a newer language, compared to C++; however the fundamentals of each language remain the same.

  If you are a good engineer, it won't really matter what your last job was.

  Ismael : The good programmers can write good solution in any language. Even vb6.

  Ismael : Also should be able to learn quickly whatever tool does his jobs more productive, be it a particular language, IDE, or OS.

  Mark Ransom : A good programmer can write a good solution in any language, true. But can they get a good job in any language? The hiring process is stacked against you if you're not playing to your most recent experience.

  SnOrfus : A good programmer picks a language appropriate for the task at hand.

• You aren't going to see someone create the latest and greatest web application in STL C++, but you will see some amazing desktop applications written in C++ (I believe all of the Microsoft Office products are C++, just to mention a small subset).

  It all really depends on you. Personal preference and career objectives.

  I, personally, would never give up C# for C++. I love my C#.

• If you have the time, I would say learn C++ well first. It makes other OO languages appear a lot simpler to understand :)

  Adam Haile : Already there...that's the point. Considering knowledge of both completely equal, which to choose?

  Andrew Rollings : Make yourself available for both. No reason to artificially limit yourself.

  Andrei Taranchenko : Word. C++ is insanely complex. The other languages almost feel like toy languages after it. HOWEVER, learning frameworks, etc, will require additional effort.

• C# is tightly coupled with MS, and MS is prone to radically changing technology every few years. Remember when ActiveX was supposed to take over the world?

  If you'd like a language that will stay relevant for the next 20 years, go with C++. C# may provide slightly better ROI for next 5 to 7 years, until MS changes their mind again.

  Michael Meadows : That argument has a hole in it. If C# (and Java) are abandoned, it will not likely be because of a return to C++. C++ is where it is now because it is too low level, and therefore too difficult to solve busines problems. Look for an even higher level solution to replace C#.

  David Thornley : You can do high-level stuff with C++; many (not all) of the things that got it a bad rep are not problems with a modern implementation and modern approaches.

  Michael Meadows : By low level, I mean that you're forced to write low level code, like memory management and pointer referencing. These things don't relate directly to solving business problems. .Net still forces a lot of low-level code too, but less than C++, so LOB development is cheaper.

  David Thornley : Memory management on C++ is a mostly solved problem, along with other resources GC does nothing about. I almost never write anything like "delete" or "*p" any more. New-style C++ is much better than old-style.

  Arkadiy : @Michael Meadows - I did not mean that MS will go back to C++. And you're right - C# will be replaced with same or higher level language. My point was, whatever replaces C#, we can be sure that C++ will still be there.

• It really depends on what you like to do. I see C++ still living around for a long time, not necessarily in web apps with the latest flashiest technologies, but very specific systems (think Air Traffic Control, railroad systems, embedded systems, etc).

  Stick with what you like most, if you're good at it, you will do good (considering, like I said, that C++ will be around for a long time, IMHO.)

• It depends on what type of a programmer you want to be. If you're looking to develop client applications or line-of-business applications, .Net (most likely C#) is definitely the way to go.

  If you're looking to do more low-level programming, like device drivers, then you should do C++. C++ is out of fashion and will probably never come back in for client applications.

• C++ is becoming more niche every day. The managed languages are becoming more powerful and they are faster to develop in. This is slowly relegating C++ to fewer and fewer spaces. If you have to choose one for the long haul, there will be more C# jobs than C++ jobs out there.

  That said, if you are asking what to learn, learning C++ would be better because you can move from C++ to C# easily. The opposite is not true. Knowing C++ makes you more flexible.

• I currently work extensively in C# and only reluctantly in C++. But, if I had to pick only one to move forward in my career with, it would have to be C++.

  I love my C#. I can work faster in it and build more powerful applications out of the ready-made building blocks in the .NET library than I would be able to in C++ at any time in the foreseeable future. Still, if I had to stick with exactly one language, C++ has a much larger installed base, runs on far more platforms, and is not dependent on a single company for its survival.

  Fortunately, I don't have to pick jobs based on such limiting criteria. I'll stick to working in C#, C++, C, VB.net, Python, Ruby, PHP, LISP, JavaScript, and whatever other languages I can solve problems with.

• I would say that it depends on what you want to make or what kind of job you want. If all you want to do is be a software developer making windows software/applications, then I'd say that c# is your way to go but if you want to get a little closer to the grain, then c/c++ has some advantages there while still allowing you to develop against win32 or the clr.

• I would say that it depends on what you want to do. As an application developer I see no reason to do anything by .Net code (and my preferred route is C#). But outside of the Quickens and Excels and Words and other ubiquitous apps of the world (all of which can be done fairly easily in .Net at this point) what is there left to do?

  Custom apps for data management are always easy enough to do in .Net (+1 for C#) but if you want to flex your muscles more and go with performance based apps like games or server side processes (+1 for C++) or delve deeper in the inner workings of Windows and do device drivers or other OS goodies then C++ is pretty much the only way you can go. I've gotten lazy, haven kept my C++ skills polished and have been caught hook, line and sinker into .Net. It turns out that I'd rather query a relational database than write one.

• In terms of entry level Associate Software Engineer type jobs, I see way, way, way way more C# jobs these days. But for more sophisticated technologies, C# does not seem to be as preferred.

• It's not really hard to jump from one to another (though probably harder to go C# to C++ than C++ to C#).

  I did all my schooling in C++ but then ended up doing C# programming without missing a beat.

• It depends. Neither language is going to die out tomorrow. C# is definitely more popular in application development on Windows, but C++ still has a lot of uses. It works on any platform, it works better with legacy C/C++ code, it gives you more control over the system, which can be essential in high-performance applications.

  So rather than asking which is better for your career, the question is which direction you'd like your career to go.

• 1. Open your favorite job search site
  2. Search for c# jobs
  3. Search for c++ jobs
  4. See which language has more openings

  I would guess c# would be a better career path. In my market there are significantly more jobs in .Net/C# than C++.

  David Thornley : Career paths should be determined by more than snapshots of raw job offerings.

• I'd chose the position that offers you more interesting tasks and more chances to push your personal limits. The langauge is - after all - just the tool of your craft. What you do with it is what really matters!

• Obviously, depends on the type of work, but I can say at our office (lots of back-end apps, some website work, some agent-type code) that our C++ stuff has definitely become more specialied. We now only write C++ when we have to (either maintaining existing C++ code, or stuff that's going to run on non-Windows platforms). We used to have solid C++ skills throughout the team, now we have maybe 1/4 of the staff that can write reasonable C++.

• Take the job you like the most, and use the language that comes with it.

  Don't pay too much attention to numbers of jobs available currently in a given market; that can come and go, and there's no good way to filter out the jobs of interest to you (whatever that is, but probably not exactly the jobs of interest to me).

• I was in a very similar position 3 years ago; picked the C++ route, and never looked back.

• Personally, I would go with C# because it is far easier to program with than C++ at times. You also get so much more exposure to different areas such as web and fat client user interfaces, and latest breed in SOA using WCF from Microsoft. However, I would still pick up C++ because when something doesn't run fast enough in C# on a users machine. You can write it in C++ to make it run faster. Also some of the other comments on multiple platform developement do hold true as well. C++ can pretty much go on any type of box out there from a Mainframe to a small integrated processor box. Good luck on whichever you choose.

• Picking a job or employer by the language they use is probably one of the WORST ways I can think of. It is certainly a good way to weed out jobs, but never use it to CHOOSE one.

  Pick the employer based on the environment, the problem domain, turnover at the employer, what you can learn on the job, the people there, commute distance, salary, benefits, vacation time, allow dogs at the office, work from home, etc. But never choose based on the coding language. That is as bad as an employer choosing someone for their specific language knowledge.

  Pick another metric.

• It's a tough question.

  From the MS support, "corporate push" perspective, C# is definitely newer, and more likely to be in vogue. For a while MS thought they could kill C++ for Windows development (which would have made your choice very easy), but recently they have been coming back to the idea that "real" apps will continue to be written in C++ for various reasons. So, I see it as 50/50 in terms of future Windows development support (slightly favoring C# though).

  As a few people said, C++ certainly opens more potential job avenues, with multiple platform support and variety of applications. You probably also want to consider the type of apps you're going to be employed to write: C++ will be more hardcore, run everywhere, or legacy; whereas C# will be more internal tools, web services, or client UI. It's a toss up for number of opportunities, but personal preference could push the decision to one side.

  If I were you, I'd look for a job which allowed (or preferably paid you more) for your ability to do both, but admittedly that's kinda a cop out. I see C#/C++ as 50/50 for future Windows development at this point, more or less.

  Addendum: I write both in my job (although I focus on C++), and my company would pay more for candidates which had knowledge of both. However, we would be more likely to hire a C++ programmer with C# knowledge rather than visa-versa, because there seem to be far fewer bad C++ programmers these days than bad .NET developers. Just an observation which might be relevant.

• I guess I would disagree with the sentiment that just go with "the best job" or "what interests you most".

  For me personally, at the end of the day I work to live - I don't live to work. If there are twice the C# jobs available as C++ (I'm making up numbers here, no flames please), then I would go with C# on the assumption that if I ever did need a new job, I would be more marketable.

  So see what is in demand out there and at the very least take that data into account.

  Nemanja Trifunovic : You are forgetting the supply side of the equation. There are more C# programmers on the market and they are cheaper.

• I agree with the others who say that other factors in choosing a job are far more important than whether the tech being used is C# or C++. I work professionally with both languages, and I find C# development on average to be far more pleasant than C++ development. But if you had a job between, say, developing a sales web site in C#, or developing a cutting edge video game in C++ for the same salary and benefits, which would you be more inclined towards? :)

• C# is now a productivity language like VB used to be - its favored for developing Line of Business applications, you know - the departmental apps, the ones that are dull and boring and often don't even make any sense. The same ones that pay well and always seem to be in demand. Rarely are those undertaken in C++. I dont see as much demand for C++ as there may have been back in lets say - 1999.

• It all depends on what your doing, or want to do. If you are going to be doing low level development like drivers or other system level applications where you need to have direct access to the memory then you use C++, if you want to do line of business or web apps and you don't need direct access to memory then c# is a better fit(garbage collection is a good thing).

  As far as cross platform use java or c# (mono for linux/unix), unless you really like writing everything in ANSI c++ otherwise porting c++ is a nightmare. The first c# development I did was in mono, I've used the LAMA stack, c# works great in both Linux and windows if you take the time.

  Most importantly learn good development practices and then the language becomes secondary. switching from one C style OO language to another is fairly simple and it doesn't mater if it's c++, java, c#, and php is a lesser degree.

• Want to code something safety critical? Learn C++ Want to learn something easier but useful for many desktop applications? Learn C#

  I would definetely recommend this order: C++ and after that C#.

• You can't choose C++, it chooses you. Have a try C++ and see If you are one of the chosen ones. Above all, read this C++ link.

• I don't think of C++ as older technology really, but from what I see it is not commonly used in typical corporate I.T. shops. C# is far more common there. If you want to use a lot of C++ at work, you'll probably be in engineering, scientific, or aerospace realms.

• I wouldn't go for a job that limits you to either (unless I had good reason). It depends on what you like to do though. Since you write in both, you know what they are used for generally. C# is great for GUIs, C++ is great for anything other than GUIs. If you love GUIs go for Java/C#. If you love "drivers/embedded/pointer fun" go for C++. The real key is to be such a good developer that the language is secondary, just a tool on your belt. Design is the primary tool.

Flex : Displaying the Advanced DataGrid data in Pages

I have a flex application where Im displaying login data using an advanced datagrid. Is it possible to show the data in this advanced datagrid, by a page wise way? if so do you have any sample coding to do this. thanks

From stackoverflow

• Here's an example I think might help you: http://gurufaction.blogspot.com/2007/02/flex-datagrid-paging-example-with.html

  SWF: http://develop.gurufaction.com/App.swf

  MXML: http://develop.gurufaction.com/src/App.mxml

• You can use the "filterFunction". Write a custom function to filter data according on which "page" you are browsing.

  Another solution is to split the original array to get several array which will be assigned according to the current page.

How to open real popup window in Flex

I need to open popup window in my flex / air application that will be displayed like normal application window. All I could manage is to open a window which is displayed inside my main flex window.

Is it something like that possible, and is there some workarounds if not?

From stackoverflow

• You'll have to use a NativeWindow for that. More info the API docs: http://livedocs.adobe.com/flex/3/langref/flash/display/NativeWindow.html

  import flash.display.NativeWindowInitOptions;
  import flash.display.NativeWindowSystemChrome;
  import flash.display.NativeWindowType;
  import flash.display.NativeWindow;
  import flash.display.StageAlign;
  import flash.display.StageScaleMode;
  import flash.geom.Rectangle;
  
  var windowOptions:NativeWindowInitOptions = new NativeWindowInitOptions();
  windowOptions.systemChrome = NativeWindowSystemChrome.STANDARD;
  windowOptions.type = NativeWindowType.NORMAL;
  
  var newWindow:NativeWindow = new NativeWindow(windowOptions);
  newWindow.stage.scaleMode = StageScaleMode.NO_SCALE;
  newWindow.stage.align = StageAlign.TOP_LEFT;
  newWindow.bounds = new Rectangle(100, 100, 800, 800);
  
  newWindow.activate();
  

• For a Flex application, you'll want to use mx.core.Window. For a non-Flex ActionScript application, you should use flash.display.NativeWindow.

  Dev er dev : Thanks, mx.core.Window did the trick.

• There is a good example here for flex 3.

BufferedImage's getSubimage performance

I'm working on a Java 2D rendering program (running on 1.6.0_11), which uses external images for its UI rendering. These large images contain several UI graphics parts at the same time, which I extract now with the BufferedImage.getSubimage(). Assuming an average desktop system (with our without enabling DirectX/OpenGL acceleration), my questions are:

• The getSubimage() is a memory efficient call, as it shares the underlying image data, but does this affect the rendering speed of these sub images with the Graphics2D.drawImage()?
• If the images use 8 bit per pixel color palette mode, what would be the gain/loss of using RGBA mode (e.g. 4x memory) or relying on the palette color model (e.g conversion time)?

From stackoverflow

• As far as I know, getSubimage(...) shouldn't have any significant effect to the rendering.

  Converting image data is slow and usually it is better to try to avoid doing it on the fly.

  ---

  With images slowness can be divided to two categories:

  • Disk I/O
  • Data processing

  And disk I/O can easily be the slowest part.

  If you are going to use only part of the image, it would be best to be able to load only part of the image from disk.

  My experience is that JAI is better at doing only what is really needed than the standard library stuff.

  kd304 : It's not the disk I/O time, because the source image is fully loaded into memory. A sample of this composite image can be seen at http://karnokd.uw.hu/open-ig-starmap.png . All UI graphics components are extracted from this kind of images.

  kd304 : I accept this answer because it states clearly - although not in detail - what I too found out since then plus suggests an alternative way of handling images. Thank you.

How to make my applications "skinnable"?

Is there some standard way to make my applications skinnable?

By "skinnable" I mean the ability of the application to support multiple skins.

I am not targeting any particular platform here. Just want to know if there are any general guidelines for making applications skinnable.

It looks like skinning web applications is relatively easy. What about desktop applications?

From stackoverflow

• Keep all your styles in a separate CSS file(s)

  Stay away from any inline styling

  xan : Succinctly put :)/

• The basic principle is that used by CSS in web pages.

  Rather than ever specifying the formatting (colour / font / layout[to some extent]) of your content, you simply describe what kind of content it is.

  To give a web example, in the content for a blog page you might mark different sections as being an:

  1. Title
  2. Blog Entry
  3. Archive Pane

  etc.

  The Entry might be made of severl subsections such as "heading", "body" and "timestamp".

  Then, elsewhere you have a stylesheet which specifies all the properties of each kind of element, size, alignment, colour, background, font etc. When rendering the page or srawing / initialising the componatns in your UI you always consult the current stylesheet to look up these properties.

  Then, skinning, and indeed editing your design, becomes MUCH easier. You simple create a different stylesheet and tweak the values to your heat's content.

  Edit:

  One key point to remember is the distinction between a general style (like classes in CSS) and a specific style (like ID's in CSS). You want to be able to uniquely identify some items in your layout, such as the heading, as being a single identifiable item that you can apply a unique style to, whereas other items (such as an entry in a blog, or a field in a database view) will all want to have the same style.

• It's different for each platform/technology.

  For WPF, take a look at what Josh Smith calls structural skinning: http://www.codeproject.com/KB/WPF/podder2.aspx

• It really depends on how "skinnable" you want your apps to be. Letting the user configure colors and images is going to be a lot easier than letting them hide/remove components or even write their own components.

  For most cases, you can probably get away with writing some kind of Resource Provider that serves up colors and images instead of hardcoding them in your source file. So, this:

  Color backgroundColor = Color.BLUE;
  

  Would become something like:

  Color backgroundColor = ResourceManager.getColor("form.background");
  

  Then, all you have to do is change the mappings in your ResourceManager class and all clients will be consistent. If you want to do this in real-time, changing any of the ResourceManager's mappings will probably send out an event to its clients and notify them that something has changed. Then the clients can redraw their components if they want to.

• Depending on how deep you wish to dig, you can opt to use a 'formatting' framework (e.g. Java's PLAF, the web's CSS), or an entirely decoupled multiple tier architecture.

  If you want to define a pluggable skin, you need to consider that from the very beginning. The presentation layer knows nothing about the business logic but it's API and vice versa.

• Skins are just Yet Another Level Of Abstraction (YALOA!).

  If you read up on the MVC design pattern then you'll understand many of the principles needed.

  The presentation layer (or skin) only has to do a few things:

  • Show the interface
  • When certain actions are taken (clicking, entering text in a box, etc) then it triggers actions
  • It has to receive notices from the model and controller when it needs to change

  In a normal program this abstraction is done by having code which connects the text boxes to the methods and objects they are related to, and having code which changes the display based on the program commands.

  If you want to add skinning you need to take that ability and make it so that can be done without compiling the code again.

  Check out, for instance, XUL and see how it's done there. You'll find a lot of skinning projects use XML to describe the various 'faces' of the skin (it playing music, or organizing the library for an MP3 player skin), and then where each control is located and what data and methods it should be attached to in the program.

  It can seem hard until you do it, then you realize it's just like any other level of abstraction you've dealt with before (from a program with gotos, to control structures, to functions, to structures, to classes and objects, to JIT compilers, etc).

  The initial learning curve isn't trivial, but do a few projects and you'll find it's not hard.

• Implementation varies by platform, but here are a few general cross-platform considerations:

  • It is good to have an established overall layout into which visual elements can be "plugged." It's harder (but still possible) to support completely different general layouts through skinning.
  • Develop a well-documented naming convention for the assets (images, HTML fragments, etc.) that comprise a skin.
  • Design a clean way to "discover" existing skins and add new ones. For example: Winzip uses a ZIP file format to store all the images for its skins. All the skin files reside in a well-known folder off the application folder.
  • Be aware of scaling issues. Not everyone uses the same screen resolution.
  • Are you going to allow third-party skin development? This will affect your design.
  • Architecturally, the Model-View-Controller pattern lends itself to skinning.

  These are just a few things to be aware of. Your implementation will vary between web and fat client, and by your feature requirements. HTH.

• This should be relatively easy, follow these steps:

  1. Strip out all styling for your entire web application or website
  2. Use css to change the way your app looks.

  For more information visit css zen garden for ideas.

• It seems most of the people here refer to CSS, as if its the only skinning option. Windows Media Player (and Winamp, AFAIR) use XML as well as images (if neccesary) to define a skin.

  The XML references hooks, events, etc. and handles how things look and react. I'm not sure about how they handle the back end, but loading a given skin is really as simply as locating the appropriate XML file, loading the images then placing them where they need to go.

  XML also gives you far more control over what you can do (i.e. create new components, change component sizes, etc.).

  XML combined with CSS could give wonderful results for a skinning engine of a desktop or web application.

• You shouldn't. Or at least you should ask yourself if it's really the right decision.

  Skinning breaks the UI design guidelines. It "jars" the user because your skinned app operates and looks totally different from all the other apps their using. Things like command shortcut keys won't be consistent and they'll lose productivity. It will be less handicapped accessible because screen readers will have a harder time understanding it.

  There are a ton of reasons NOT to skin. If you just want to make your application visually distinct, that's a poor reason in my opinion. You will make your app harder to use and less likely that people will ever go beyond the trial period.

  Having said all that, there are some classes of apps where skinning is basically expected, such as media players and imersive full screen games. But if your app isn't in a class where skinning is largely mandated, I would seriously consider finding other ways to make your app better than your competition.

Unix vs. Windows rendering of characters

I have a text file that display differently when opening it in FreeBSD vs. Windows.

On FreeBSD: An·lisis e InvestigaciÛn

On Windows: Análisis e Investigación

The windows representation is obviously right. Any ideas on how to get that result in bsd?

From stackoverflow

• How is the file encoded? I would try re-encoding the file as UTF-16.

• This is not pure ASCII. It's utf-8. Try freebsd editor with utf-8 support or change locales.

• The problem is that it's not ASCII, but UTF-8. You have to use another editor which detects the encoding correctly or convert it to something your editor on freebsb understands.

  Jacek Ławrynowicz : "it it's probably ISO-8859-1". 'á' is displayed as '·', so it must be multibyte encoding (utf-8 or utf-16).

  Ant P. : It's definitely UTF-8. An easy way to tell is that those funny-looking accented A's will show up when encoding characters just outside the first 128 in Unicode.

  Georg : Right, sorry. Didn't see that.

• The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)

• From the way the characters are being displayed, I would say that file is UTF-8 encoded unicode. Windows is recognising this, and displaying the 'á' and 'ó' characters correctly, while FreeBSD is assuming it's ISO-8859-1, which results in these characters being displayed as 2 seperate characters (due to the UTF-8 encoding using 2 bytes). You'll have to tell FreeBSD that it is a UTF-8 file, somehow.

• So after doing a bit more digging if 1) Open the csv file in excel on mac and export it as csv file and 2) then open it in textmate, copy the text, and save it again it works.

  The result of: file file.csv is

  UTF-8 Unicode English text, with very long lines

  The original is:

  on-ISO extended-ASCII English text, with very long lines

  This workaround isn't really suitable as this process is supposed to be automated, thanks for the help so far.

• It doesn't matter which operating system you're using when you open the file. What matters is the application you use to open it. On Windows you're probably using Notepad, which automatically identifies the encoding as UTF-8.

  The app you're using on FreeBSD obviously isn't doing that. Maybe it just can't read UTF-8 and you need to use a different app. Or maybe you just have to tell it which encoding to use. Automatic detection of character encodings is far from universal (and much farther from perfect).

How to select an element that has focus on it with jQuery

How can you select an element that has current focus?

There is no :focus filter in jQuery, that is why we can use something like this:

$('input:focus').someFunction();

From stackoverflow

• Really the best way to do it is to setup a handler for the onFocus event, and then set a variable to the ID of the element that has focus.

  something like this:

  var id;
  
  $(":input").focus(function () {
       id = this.id;
  });
  

  redsquare : Why $(this).attr('id') use this.id

  cbp : Becareful because the window can also receive focus, which means this code won't work as expected in all cases.

• Have you tried

  $.extend($.expr[':'], {
      focused: function(elem) { return elem.hasFocus; }
  });
  
  alert($('input :focused').length);
  

  akaihola : `document.hasFocus()` does exist, but such a method or attribute is not available for elements. Tried in Firefox and Chromium.

• alert($("*:focus").attr("id"));

  I use jQuery.

  It will alert id of element is focusing.

  I hope it useful for you.

  kingjeffrey : Perfect answer!