• 0

is c# better then c++?


Question

Recommended Posts

  • 0

I would argue that only professionals have any true reason to use C++. Newbies have no need for pointers, assembly, or manual memory management.

I would suggest learning C# with C (not C++) on the side. C will teach you low-level programming so you understand what's happening under the hood, while C# will teach you everything else and is the language you're more likely to use day to day.

The problem with C++ is a matter of poor design. It has so many hurdles and traps that it's a language that takes years to master.

  • Like 3
  • 0

Given the choice, Java is a better option than C# for cross-platform support.

I agree, for cross-platform support, java is better. But otherwise I find C# better. Visual Studio is a superb IDE and I find it far more polished than eclipse. Another thing to note is that Java is interpreted as far as I know while C# is not. So if you are counting on performance then Java is perhaps not the way to go.

Syntax wise, C# and Java are almost twins... libraries are obviously different though.

  • 0

I would argue that only professionals have any true reason to use C++. Newbies have no need for pointers, assembly, or manual memory management.

I would suggest learning C# with C (not C++) on the side. C will teach you low-level programming so you understand what's happening under the hood, while C# will teach you everything else and is the language you're more likely to use day to day.

The problem with C++ is a matter of poor design. It has so many hurdles and traps that it's a language that takes years to master.

I absolutely agree with this. I have seen enough horrible code in my lifetime made by coders that don't understand the underlying processes, thinking that the framework would "just do it" for them (which, most of the time it does, just not in an efficient way if you don't really know what's happening).

  • 0

I've heard that from Herb Sutter and it's quite amusing. Yes, most of C++'s library has its complexities documented, but maybe because there isn't much more than containers and algorithms in the C++SL... Containers and algorithms in .NET also have their algorithmic complexities documented, but there is no point documenting the algorithmic complexity of a Printer or Socket class.

I think you got it wrong. Due to the fact, that .NET and Java use OO and a whole lot of interface cruft for their containers' interfaces (opposed to C++'s container definition) you actually can't rely on the complexity of the containers in them - especially if you're using collections that are returned from foreign code. For example what does the List<XYZ> guarantee in terms of complexity in Java? Well nothing really, as it's an interface, List<XYZ> may actually be an array (class ArrayList) or it may be a linked list -> totally different complexities (and memory layouts -> access patterns) are involved here! You have no way of telling which one it is based on List<XYZ>. A similar thing happens in .NET?

Let's compare that to std::list<XYZ>: what does it guarantee? Well quite a bit:

1. The elements are stored in a double-linked list - there is no way around that bit!

2. Every operation on this list has a well defined complexity that no standard conforming implementation is allowed to break

2a. Insertion at front and back: O(1)

[3. Compared to Java: this list is really type safe (opposed to Java's type erasure "hack") - at least that one Microsoft got right?]

  • 0

I think you got it wrong. Due to the fact, that .NET and Java use OO and a whole lot of interface cruft for their containers' interfaces (opposed to C++'s container definition) you actually can't rely on the complexity of the containers in them - especially if you're using collections that are returned from foreign code. For example what does the List<XYZ> guarantee in terms of complexity in Java? Well nothing really, as it's an interface, List<XYZ> may actually be an array (class ArrayList) or it may be a linked list -> totally different complexities (and memory layouts -> access patterns) are involved here! You have no way of telling which one it is based on List<XYZ>. A similar thing happens in .NET?

Let's compare that to std::list<XYZ>: what does it guarantee? Well quite a bit:

1. The elements are stored in a double-linked list - there is no way around that bit!

2. Every operation on this list has a well defined complexity that no standard conforming implementation is allowed to break

2a. Insertion at front and back: O(1)

[3. Compared to Java: this list is really type safe (opposed to Java's type erasure "hack") - at least that one Microsoft got right?]

List<T>, ArrayList and LinkedList<T> are three different implementations in .NET, not interfaces; you are probably thinking about IList<T>, ICollection<T> and co. If you go through the MSDN documentation of each class you will see that their complexities are well documented.

  • 0

List<T>, ArrayList and LinkedList<T> are three different implementations, not interfaces; you are probably thinking about IList<T>, ICollection<T> and co. If you go through the documentation of each class you will see that their complexities are well documented.

1. I was talking about Java -> look it up these are the names of an interfaces (List) and two implementations (ArrayList, LinkedList)

2. In your code you have the following function:


public List<XYZ> getXYZList();
[/CODE]

What guarantees do you have for the result of [i]getXYZList[/i]? [b]None![/b] You have no idea what complexities the methods on this object actually have!

  • 0

1. I was talking about Java -> look it up these are the names of an interfaces (List) and two implementations (ArrayList, LinkedList)

2. In your code you have the following function:


public List<XYZ> getXYZList();
[/CODE]

What guarantees do you have for the result of [i]getXYZList[/i]? [b]None![/b] You have no idea what complexities the methods on this object actually have!

Ehm. Does it matter what complexities or whatever the things have? You know that whatever the result might be, it always has all the functionality specified in the List interface. If you want to be sure check what it is with an instanceof, or just create an ArrayList or whatever, and fill it up by iterating over everything in the List.

  • 0

Ehm. Does it matter what complexities or whatever the things have?

If you care about performance: definately yes! if you don't care about performance: F*** you! You're one of those scumbags that slow down PCs worldwide!

You know that whatever the result might be, it always has all the functionality specified in the List interface.

Which doesn't help at all in terms of performance?

If you want to be sure check what it is with an instanceof, or just create an ArrayList or whatever, and fill it up by iterating over everything in the List.

Hardly useable considering there are countless implementations of an interface. Don't forget: it's highly unlikely you're implementing everything in the application => you'll get objects via interfaces where you'll have no idea about their implementation in Java and .NET?

  • 0

I would argue that only professionals have any true reason to use C++. Newbies have no need for pointers, assembly, or manual memory management.

I would suggest learning C# with C (not C++) on the side. C will teach you low-level programming so you understand what's happening under the hood, while C# will teach you everything else and is the language you're more likely to use day to day.

The problem with C++ is a matter of poor design. It has so many hurdles and traps that it's a language that takes years to master.

I disagree. IMO all developers should know the concept of the stack vs heap and memory management, especially given that it's a core part of how most object-oriented languages work (C# included). Knowledge of memory management, even at a basic level gives understanding of how GC works, the difference between value types vs reference types in .NET, and so on.

However, for people just looking to make quick apps, learning a lower level language is probably excesive. If the user is looking at taking it up programming as a profession, knowledge of how this stuff works at a lower level should be mandatory (again, IMO). The OP didn't really specify though, so it's hard to give a good answer.

I don't think there's any value in learning C over C++ either. C++ is basically everything that C is, but you get all the benefits of OOP.

There are pointers in C#. And reference vs value types is basically the same idea as pointers vs values in C/C++.

Just because you can, doesn't mean you should. Doing pointer stuff in C# is a sin :p.

  • 0

I'm surprised nobody has said Java yet. Eclipse is a great free Java IDE, Java and C# are almost the same language, and Java is perfectly cross-platform, including GUI's.

I'm studying Applied IT and have been writing Java since september now. I've always used Eclipse with it, but I feel right at home in Visual Studio using C#. No reason to limit yourself to Microsoft with C# right from the beginning.

(in fact, C# is strongly 'inspired' on Java. But Java sort of forces you to write cleaner code (in my opinion), which will help you later on)

Java and C# are similar, but not at all the same languages. Java is missing so many language features that I use on a daily basis that I don't know if I could ever go back to Java after coding in C# for the last few years.

Properties, delegates, lambdas, events, anonymous classes, partial classes, reified generics, generators (yield return), extension methods, expression trees, and language-level async support (in .NET 4.5) are just a few of the C# language features that would be hard to live without; not to mention some of the functionality in the .NET framework like LINQ, Parallel Extensions, Entity Framework, MVC, etc...

About the only things I prefer about the Java language are the way they handled enums and enforcing exception handling at build-time.

  • 0

1. I was talking about Java -> look it up these are the names of an interfaces (List) and two implementations (ArrayList, LinkedList)

2. In your code you have the following function:


public List<XYZ> getXYZList();
[/CODE]

What guarantees do you have for the result of [i]getXYZList[/i]? [b]None![/b] You have no idea what complexities the methods on this object actually have!

Ahh Java, sorry missed that. I've thought a lil bit more about what you said and I do understand your reasoning now. Thing is one of the roles of interfaces is to hide implementation details. There is not much you can do in .NET (or Java) if a 3rd party library returns an IList<T> to the caller instead of a List<T>.

  • 0
Thing is one of the roles of interfaces is to hide implementation details.

True, but once you try to develop efficient - performance/watt - you sooner or later realize that heavy abstraction as provided by interfaces is actually the worst thing you can do! It's not even the dynamic dispatch (virtual function call) [though I even experienced that one too to become a problem?] , but the fact that you abstract away any information that will be suitable for creating the most efficient solution (e.g. linked-list vs array -> I think I don't have to say anything?)

  • 0

I disagree. IMO all developers should know the concept of the stack vs heap and memory management, especially given that it's a core part of how most object-oriented languages work (C# included). Knowledge of memory management, even at a basic level gives understanding of how GC works, the difference between value types vs reference types in .NET, and so on.

However, for people just looking to make quick apps, learning a lower level language is probably excesive. If the user is looking at taking it up programming as a profession, knowledge of how this stuff works at a lower level should be mandatory (again, IMO). The OP didn't really specify though, so it's hard to give a good answer.

I don't think there's any value in learning C over C++ either. C++ is basically everything that C is, but you get all the benefits of OOP.

That's why I suggested learning C, so you learn how things work "under the hood". The reason I recommend C over C++ is, as I said, poor design. C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#. C is also more low-level, requiring you to use malloc / free instead of new / delete, printf instead of cout << endl, structs instead of classes, and so forth.

  • 0

C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#.

Is it possible you only focus on the negative side of C++? How about the stricter type system - something that C could 99% of the time take a real advantage of - or the lack of stupid features (VLA come to mind?) . Or the fact that C++ is still relevant outside of kernels and embedded system - hell even there C++ is gaining ground (sans the "heavy" features [exceptions, virtual calls,?])?

requiring you to use malloc / free instead of new / delete, printf instead of cout << endl,

Apart from minor differences these solutions are interchangeable - i prefer the iostream-approach as it is way cleaner and typesafe? (I despise C-style IO)

structs instead of classes

they are virtually the same?

  • 0

Is it possible you only focus on the negative side of C++? How about the stricter type system - something that C could 99% of the time take a real advantage of - or the lack of stupid features (VLA come to mind?) . Or the fact that C++ is still relevant outside of kernels and embedded system - hell even there C++ is gaining ground (sans the "heavy" features [exceptions, virtual calls,?])?

Apart from minor differences these solutions are interchangeable - i prefer the iostream-approach as it is way cleaner and typesafe? (I despise C-style IO)

they are virtually the same?

That's why I suggested learning C, so you learn how things work "under the hood". The reason I recommend C over C++ is, as I said, poor design. C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#. C is also more low-level, requiring you to use malloc / free instead of new / delete, printf instead of cout << endl, structs instead of classes, and so forth.

I'm recommending C# for regular development, and C only for LEARNING low-level programming. C++ is such a hassle that there's no reason for a newbie programmer to use it over C#. C is a better language to learn how things work under the hood because it's much more exposed (e.g. there is no 'delete' keyword to automatically destruct an array of objects).

  • 0

...

Mono is an implementation of open standards just like gcc or clang. I don't know what you mean by "pure C#", as Microsoft's .NET itself is written in C++.

...

What part? As the CLI (JIT Compiler) is C++ and Assembly, but the framework itself is C#... You can see this using .NET Reflector or the .NET symbols when debugging in Visual Studio...

Also: http://stackoverflow.com/questions/1324919/what-language-is-net-framework-written-in

  • 0
I think you got it wrong. Due to the fact, that .NET and Java use OO and a whole lot of interface cruft for their containers' interfaces (opposed to C++'s container definition) you actually can't rely on the complexity of the containers in them - especially if you're using collections that are returned from foreign code. For example what does the List<XYZ> guarantee in terms of complexity in Java? Well nothing really, as it's an interface, List<XYZ> may actually be an array (class ArrayList) or it may be a linked list -> totally different complexities (and memory layouts -> access patterns) are involved here! You have no way of telling which one it is based on List<XYZ>. A similar thing happens in .NET?
If you specify a container type as IList<T> (in .NET), you are specifying that you don't care what the concrete type of container and its performance characteristics are! If you do care, then you should write LinkedList<T>, List<T>, etc., which are concrete types with documented complexities just like the concrete types std::list and std::vector.

The fact that collections in Java and .NET implement interfaces simply mean that it's possible to treat them as more generic types while ignoring their performance characteristics, not that this is necessarily what you want to do. So I don't really understand your point. I don't think the design of the .NET class library in general (can't speak for Java) makes it difficult to know what the concrete type of collections are; generally, when a method returns a container, it is a concrete type.

Just because you can, doesn't mean you should. Doing pointer stuff in C# is a sin :p.
Well, it's not idiomatic, but it enables some high-performance features to be done in C# like bitmap manipulation in Paint.Net or the like. At least C# makes it clear with all the syntactic evilness (unsafe, fixed, stackalloc, etc) that you'd better know what you're doing when you use pointers.

As for C vs C++ for the purpose of learning pointers and manual memory management, I think I'd side with Xinok on the issue; C is a simple and coherent language which can't be said of C++. How many different ways are there to create a pointer in C++11?

C-style (evil, deprecated, don't use! but wait all the standard library uses it...)

auto_ptr (bad, deprecated, don't use!)

reference (almost the same thing but not quite, if you can use it use it)

unique_ptr (expresses ownership of the resource - what happens when you copy it exactly? Stroustrup himself was confused on the issue at a recent talk)

shared_ptr (expresses shared ownership of the resource - but may lead into leaks because of reference counting cycles, for which there is...)

weak_ptr (breaks cycles of shared_ptr)

Ugh... what's a pointer again?

  • 0

What part? As the CLI (JIT Compiler) is C++ and Assembly, but the framework itself is C#... You can see this using .NET Reflector or the .NET symbols when debugging in Visual Studio...

Also: http://stackoverflow...work-written-in

Correct, I was over-generalizing. The point still stands that .NET is not "pure C#" in the sense of being purely written in C#.
  • 0

Correct, I was over-generalizing. The point still stands that .NET is not "pure C#" in the sense of being purely written in C#.

Agreed. I was merely offering clarification, but the base point is correct.

  • 0

The reason I recommend C over C++ is, as I said, poor design.

I honestly disagree! It may be true - to some extend - for C89 (aka ANSI-C), but IMHO any later standard is just an abomination?

C++ only overcomplicates things like object-oriented programming, things which would be much easier to learn in C#.

I disagree again! C++ is not about OO, C++ is about effective abstraction! The people that think that C++ is just about OO are those that actually are getting it wrong - just as those who think that OO means: "everything has to be a class/method"?

C++ is such a hassle

Actually it's easier to learn than C - provided you learn idiomatic C (which more or less requires not to learn C as C++ got all the features that make C good, yet avoids some of it's deadliest pitfalls via a stricter type system? Sure if you learn C and try to use C with Objects you're lost. People that follow that path are those that overuse new and delete - something that's rarely used in modern C+!

(e.g. there is no 'delete' keyword to automatically destruct an array of objects).

There's free? And as I said modern C++ does not rely on new/delete in usercode?

If you specify a container type as IList<T> (in .NET), you are specifying that you don't care what the concrete type of container and its performance characteristics are! If you do care, then you should write LinkedList<T>, List<T>, etc., which are concrete types with documented complexities just like the concrete types std::list and std::vector.

Well that doesn't work as the way of thinking - at least in the Java world - is that you should NEVER use the concrete type in the interface?

generally, when a method returns a container, it is a concrete type.

Nope, it's an implementation of an interface which is no concrete type for which you can rely on for complexity guaranties?

How many different ways are there to create a pointer in C++11?

It depends! (The beauty of options?) Do you mean raw pointers or smart pointers? (There's a reason for the distinction!)

C-style (evil, deprecated, don't use! but wait all the standard library uses it...)

Nope, if you know what you're doing they're perfectly valid - you shouldn't overuse them.

auto_ptr (bad, deprecated, don't use!)

Deprecated yes, but if you know it's limitations - which boils down to one fatal in certain situations - you may still use it. Whilst auto_ptr has it's problems it's still a tool that can be used in certain situations. Given the option, one should prefer unique_ptr?

reference (almost the same thing but not quite, if you can use it use it)

Actually references are more like aliases - but hey it all boils down to memory addresses anyways?

  • 0

unique_ptr (expresses ownership of the resource - what happens when you copy it exactly? Stroustrup himself was confused on the issue at a recent talk)

He is? (source??) Well let's look into the spec: Hey, unique_ptr is NOT COPYABLE, which makes sense as it's expressing sole ownership?

shared_ptr (expresses shared ownership of the resource - but may lead into leaks because of reference counting cycles, for which there is...)

weak_ptr (breaks cycles of shared_ptr)

So you're arguing we should use a tried and tested way to manage cyclic dependencies without having the burden of a garbage collector?

Ugh... what's a pointer again?

A memory address, every smart pointer you listed is there for a purpose. The purpose is simply: to simplify the memory management of the application! Compare it to C: you only have raw pointers. How do you free the following structure:


int * ptrs[1000];
[/CODE]

Every ptr in ptrs points to a random object in memory, it's possible (actually likely) that several pointers point to the same object.

For comparison in C++

[CODE]
std::array<std::shared_ptr<int>, 1000> ptrs;
[/CODE]

will be deleted automatically if it goes out of scope [RAII]?

  • 0
I wouldn't recommend using C# or dotnet outside of Windows. Its support is sketchy at best, and most Linux distributions are blacklisting it (Mono) due to precarious licensing issues. Furthermore, the proprietary Windows Forms also won't be available outside of Windows, so if you intend on writing a GUI application, you will have to use something else.

The most popular Linux distribution shipped with two Mono-based applications until just recently, and the reasons for replacing the apps with native ones were based on their own merits. Mono is used on several commercial projects including by large companies such as EA, has been actively developed for almost as long as Microsoft's .NET by a team of professionals, and for all the fear-mongering about Microsoft patents, after ten years Microsoft is, if anything, showing more openness towards open-source than ever, recently making ASP.NET open-source for instance.

You will have to use a cross-platform GUI toolkit for writing cross-platform applications regardless of language choice, so the point that WinForms (or WPF) isn't cross-platform is kinda moot. It's also inexact since Mono does implement Windows Forms (if poorly).

In fact, .NET is currently one of the best cross-platform solutions, especially for games: I don't what other environment allows you to target Windows, WP7, Xbox360, Mac OS, Linux, Android and iOS with the same code and that's exactly what XNA/MonoGame does.

  • 0

Well that doesn't work as the way of thinking - at least in the Java world - is that you should NEVER use the concrete type in the interface?

That's a blanket statement and I'm sure you can find plenty of counter-examples in the Java library itself, which I'm not familiar with - in .NET, off the top of my head, File.ReadAllLines returns an array of string, not an IEnumerable<string> or whatever. You don't want to use a concrete type if what you want is flexibility at the expense of not knowing the concrete type (and its performance characteristics); if you don't need the flexibility then why use anything else than a concrete type? That seems like an extreme design rule, and certainly not a limitation of the .NET (and probably not of the Java) library.
It depends! (The beauty of options?) Do you mean raw pointers or smart pointers? (There's a reaso
I understand why there are many options in C++, but what I'm arguing is that from the perspective of learning pointers, having all these options is counterproductive because it creates confusion.
He is? (source??) Well let's look into the spec: Hey, unique_ptr is NOT COPYABLE, which makes sense as it's expressing sole ownership?
http://channel9.msdn...sk-Us-Anything- at around 33:45. I spoke a bit quickly, Stroustrup was confused about passing a unique_ptr by value, not specifically copying it. Still, if the language designer is unsure about how his own feature works, how do you expect someone learning pointers to make sense of all that?
So you're arguing we should use a tried and tested way to manage cyclic dependencies without having the burden of a garbage collector?
Again, I'm just saying that all these options are confusing to someone learning pointers, and that they would be better served, for that purpose, with a much more simple language.
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Removed the blue and underline as you did not post a link. This would also  be considered spamming.
    • Why it's almost impossible to produce a smartphone in the United States by Hamid Ganji If you look at the back of some Apple products, you can see the famous phrase “Designed by Apple in California, Assembled in China.” This phrase appears on products from one of the largest smartphone brands in the United States. These products are designed in the U.S., but their manufacturing takes place in China, India, Vietnam, or even Brazil. But why can’t Apple, as one of the largest American tech companies, produce its iPhones on U.S. soil? The idea for this topic came to me after the Trump Foundation launched a smartphone called the T1 and claimed that it was designed and built with American values in mind. However, this claim did not last long, as it was revealed that Trump’s phone was actually a rebranded HTC U24 Pro, with only a gold case and minor internal component changes. You see? Even a phone that is supposed to represent American values is manufactured in China. With a gross domestic product (GDP) exceeding $32 trillion, the United States is currently the world’s largest economy, while China ranks second with around $20 trillion. On the other hand, the United States is by a wide margin the global leader in various technological fields, and American companies spend hundreds of billions of dollars annually on research and development. From Apple and Google to Microsoft, Lockheed Martin, Boeing, and others, American tech and industrial giants lead their foreign competitors in many sectors. The United States also has no shortage of smartphone brands. Apple, Google, and Motorola are among the major brands in the smartphone market, collectively holding a significant share. However, the vast majority of their products are manufactured outside the United States. So why is it that the world’s largest economy, home to the most advanced technology companies and industrial powers, cannot produce a smartphone on its own soil? Let’s explore this question together. Even threats to impose tariffs won’t work After Trump entered the White House as the 47th President of the United States, his administration adopted strict tariff policies. One of these policies was the imposition of a 25% tariff on smartphones manufactured outside the United States. Trump said he “had a little problem” with Apple CEO Tim Cook over producing smartphones outside the U.S. So he thought that threatening a 25% tax on imported phones might force Apple to bring manufacturing back to the United States. “I have long ago informed Tim Cook of Apple that I expect their iPhones that will be sold in the United States of America will be manufactured and built in the United States, not India, or anyplace else,” Trump wrote on Truth Social. Image via The White House Although Apple currently manufactures some of the iPhone’s chips in the United States with TSMC's help, it still shows no willingness to shift full iPhone production to the country. At the time, renowned Apple supply chain analyst Ming-Chi Kuo wrote on X, “In terms of profitability, it’s way better for Apple to take the hit of a 25% tariff on iPhones sold in the US market than to move iPhone assembly lines back to the US.” However, manufacturing a smartphone in the United States is not as easy as it might seem, and many technical and economic barriers are involved. The lack of necessary manufacturing hubs There is a clear reason why many companies prefer to manufacture their products in China. China has established itself as the main global manufacturing hub for international companies, and over the past few decades, large contract manufacturers have emerged there, allowing companies like Apple to outsource production. One such example is Foxconn, which also manufactures some Apple products in India. Building the infrastructure required to produce smartphones in the United States would require tens of billions of dollars in new investment. Factories would need to be built, essential manufacturing equipment would have to be installed, and, most importantly, a skilled workforce capable of operating these systems would need to be recruited and trained. The United States currently lacks the core infrastructure needed to manufacture smartphones, and for this reason, many companies prefer to outsource production to Chinese contractors rather than spend tens of billions of dollars to build that infrastructure, which is significantly more economically efficient. Additionally, building such infrastructure in the United States could take up to a decade, ultimately leading to a significant increase in the product's final price for consumers. Shortage of trained labor in the U.S. compared to China Decades of serving as a global manufacturing hub have allowed China to build a massive talent pool in the production sector that is almost unmatched worldwide. Today, if a company chooses to manufacture its products in China, it can be confident that the workers involved in production have years of experience in their respective roles and are capable of producing high-quality goods with minimal errors. Even if we assume that tens of billions of dollars were invested in building smartphone manufacturing infrastructure in the United States, finding skilled workers would remain highly challenging. Apple CEO Tim Cook visiting the iPhone 6 assembly line in China in 2014. Image: Tim Cook on X In a 2015 interview on CBS’s 60 Minutes, Tim Cook said the main reason Apple isn’t producing in the US is a lack of skills. "China put an enormous focus on manufacturing, in what you and I would call vocational kind of skills. The US over time began to stop having as many vocational kinds of skills. I mean you could take every tool and die maker in the United States and probably put them in the room that we're currently sitting in. In China you would have to have multiple football fields,” Cook said. Also, in 2017, at the Fortune Global Forum in Guangzhou, Cook once again emphasized the importance of highly skilled Chinese workers. “China has moved into very advanced manufacturing, so you find in China the intersection of craftsman kind of skill, and sophisticated robotics and the computer science world. That intersection, which is very rare to find anywhere, that kind of skill, is very important to our business because of the precision and quality level that we like. The thing that most people focus on if they’re a foreigner coming to China is the size of the market, and obviously, it’s the biggest market in the world in so many areas. But for us, the number one attraction is the quality of the people,” Apple CEO said. Higher labor costs in the United States Producing almost any product in the United States is more expensive than in many other countries, and one of the main reasons is the higher cost of labor in the U.S. According to the Bureau of Labor Statistics, median weekly earnings of full-time workers in the United States were $1,235 in the first quarter of 2026. Meanwhile, the average annual salary in China's private sector in 2025 was RMB 71,590 (US$9,961). In many parts of the world, the weekly wage of an American worker is equivalent to several months of income. Another important factor to consider is that in the United States, the workforce capable of working on a smartphone assembly line is highly specialized and therefore commands higher-than-average wages. According to an estimate by Bank of America, producing an iPhone in the U.S. is technically possible, but “iPhone cost can increase 25% purely on higher labor cost in the U.S.” However, this 25% increase applies only if final assembly is performed in the United States while components are still sourced from China or elsewhere. In this case, the price of a base iPhone would rise from $799 to around $1,000. But in another scenario, if Apple were to produce the required components for the iPhone within the United States, production costs could increase by more than 90%. Trump’s dream for a “Made in the USA” iPhone might never come true In a free-market capitalist economy, one of the primary responsibilities of any CEO is to maximize profit. Using Apple as an example, Tim Cook’s role is to maximize the company’s profits so that it can fund research and development for new products and invest in areas such as artificial intelligence, while also keeping shareholders satisfied. Therefore, it is entirely understandable that Apple would choose not to bring its manufacturing back to the United States and instead keep production in countries where labor is cheaper, and products can be manufactured at a lower cost, thereby maximizing its profit margins. What is your opinion about manufacturing smartphones in the United States? If you are an American citizen, would you be willing to pay hundreds of dollars more for a smartphone made domestically in the USA? Let us know in the comments.
    • Cheers everyone for the replies. It's been very useful. 👍
  • Recent Achievements

    • Conversation Starter
      jessse3334 earned a badge
      Conversation Starter
    • Reacting Well
      JuvenileDelinquent earned a badge
      Reacting Well
    • One Month Later
      Excellence2025 earned a badge
      One Month Later
    • Week One Done
      Excellence2025 earned a badge
      Week One Done
    • Week One Done
      flexorcist earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      506
    2. 2
      +Edouard
      196
    3. 3
      PsYcHoKiLLa
      153
    4. 4
      Steven P.
      72
    5. 5
      FloatingFatMan
      65
  • Tell a friend

    Love Neowin? Tell a friend!