|
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
3. No sys-admin, networking, "how do I setup XYZ" questions. For those use the SysAdmin[^] or Hardware and Devices[^] forums.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
modified 16-Sep-19 9:31am.
|
|
|
|
|
A reply to me elsewhere on the Internet
"You'll get there, I've noticed you don't just do coding...you try to torture it into telling you why...with as few expressions as is feasible."
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I'm basically slowly posting a very large codebase article by article, section by section.
I'm not even tying them together as a series because some of the code is more general, like my IndexedQueue class, or my CodeDomUtility or CodeDomVisitor code.
I do it so i can link to them from my more meaty articles that use them, but they don't get votes.
Still, I think I'd rather have them posted than not. I just think it's a little funny how these little code bits go so unnoticed by themselves, but working together they make magic happen. 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Many moons ago, before I retired, for many decades, I programmed embedded devices (8 / 16 bit) in both plain C and Assembler. In the early 1980s I even programmed my first PC in Assembler. This was one of the first genuine IBM PCs that they produced in Scotland. It's processor was an Intel 8080 running at the stunning clock speed of 4.7 MHz! At the time that was considered revolutionary!
Since my retirement a decade ago, I have been dabbling with C# just to keep the grey cells busy. Lord knows I have lost too many of them due to the stoopid aging process! 
But lately I have been looking around for another challenge. Learning 64 bit Assembler sounds interesting. Checked Amazon for not-too-expensive books on the subject, but some of the better books are for the Linux operating system. I just don't have the energy left to learn both Assembler and Linux. 
Can any of you recommend any good resources covering 64 bit Assembler programming on Windows, preferably using Visual Studio?
Please understand that I have done a Google search. Got plenty possibilities from Google. But I would like options that come with your personal recommendations, please. It is so much easier to pick options that your trusted friends recommend.
|
|
|
|
|
Everything I've found on windows programming in 64 bit assembler leads me to the windows DDK.
That's both expensive and hard to work with.
Offhand - and this is just one witch's opinion - using the basics of linux is easy. Enough to run an assembler. And OS level programming in asm is going to be far less arduous in linux even if you're not familiar with the driver model and such, just because they don't have all the info on it paywalled like MS does.
I'd recommend familiarizing yourself with linux. you only need a little bit, and i think it will pay for itself for you in terms of effort invested if you want to code 64 bit asm code that actually does stuff.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Hi,
Cp-Coder wrote: Can any of you recommend any good resources covering 64 bit Assembler programming on Windows, preferably using Visual Studio?
64 bit inline assembler isn't supported in Visual Studio. But you should have no problem compiling ASM files. I would recommend The MASM Forum[^] as a great resource.
Best Wishes,
-David Delaune
|
|
|
|
|
Is a thieving Alligator a Crookodile?
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I don't know, perhaps we should have an investi-GATOR look in to it.
“The palest ink is better than the best memory.” - Chinese Proverb
|
|
|
|
|
sounds like a load of croc to me
this internet has become nothing but fake news.
... time to fix it, time to get back to the fax!
|
|
|
|
|
A "croc of sh*t", possibly!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Whether amphibian or tellin' you the truth, the scale of such remarks is be-caymian questionable.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
They take a bite out of crime
They call me different but the truth is they're all the same!
JaxCoder.com
|
|
|
|
|
This TOTD is off the scales!
/ravi
|
|
|
|
|
Maybe is a case of reptile allies
|
|
|
|
|
|
I need to think about that - can I get back to you - in a while?
Or maybe I will just see you later...
I, for one, like Roman Numerals.
|
|
|
|
|
Best make it snappy ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
So I need to resolve the "type" of a this reference, but I cannot do it without knowing how my object was created because what type arguments were used? This is where generics ridiculously complicate things.
I know how the C# compiler does it internally. Each generic instantiation is given its own "name" and type entry.
In the CodeDOM this just *can't* work that way. At least not in any fashion I can figure out. There is only one CodeTypeDeclaration for any given type, even if it is generic.
To make it otherwise would break the CodeDOM. I'm trying to use "userData" tags to mark up the codedom with extra information, but frankly, I don't even know how to "trace" the this reference back to the create object statement that brought it to life.
*scratches head*
I've taken breaks. I've even coded different stuff to cleanse my mind. It's just not coming to me.
I'm so frustrated right now. This project is an absolute bear.
Edit: I'm not even 100% sure this is the right approach even if I do figure it out.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
When I squint at C#, it kinda looks like C++.
If you know the Class to which the function in question belongs, isn't this a Class*, possibly const?
For a C++ class template instance, I treat it as its own class, although it knows the template from which it was instantiated.
|
|
|
|
|
Greg Utas wrote: If you know the Class to which the function in question belongs, isn't this a Class*, possibly const?
I do, and it is, though C# has no const modifier in that context.
The trouble is when generics (c#'s answer to C++ templates) are used.
I'd like to treat each template instantiation as its own class but I have nowhere to even put this alternative nametable i'd have to use, and to explain why would involve explaining the CodeDOM and my source up to this point.
It could be that I've painted myself into a corner. That's not unlikely as this is preliminary code I wrote in order to learn how to do this thing.
I don't know yet though. This whole thing is so confusing to me. It's basically the middle part of a compiler (type, member resolution, etc) because C# requires that in order to even be parsed properly.
It has a similar issue that C does in regard to parsing types, but it goes deeper. They just said to hell with simplifying parsing.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Just in case it will help, here is a sketch of how I handle it in C++.
Classes and class templates have type Class, one of whose members is an optional list of template parameters (e.g. <T>).
Class template instances have type ClassInst, derived from Class. Rather than generate mangled names, I allow punctuation that can appear in a template argument list to be valid in an internal identifier. That identifier, with each of its constituent names fully qualified, gets added to the symbol table.
|
|
|
|
|
The only trouble with that for me right now is I need to get the CodeDOM to be able to handle that. I may have to resort to namemangling due to the nature of CodeTypeReference but maybe not. It's making my brain hurt right now so I should probably back away. I'll chew on your tactic though.
I've still got to figure out where to keep all those symbols.
I've also been considering importing *all* types from a given namespace import rather than playing go fish, and if i do that, then I'll end up with a table for my generic instances as well. So we'll see.
There's so much here that's still TBD i think i need to outline or something.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I hope this is not a programming question disguised as an interjection. Horrors!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
I don't even know how to phrase this level of suffering as a question 
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
This question was asked at work yesterday, and a couple of our developers are firmly in the camp that if we were to rewrite the back-end (currently C# with WCF [gross] to handle the endpoint calls and with SQL Server, no ORM, just using Dapper) they would write it in Node with TypeScript.
Conversely, I'm in the camp that if I'm writing anything on the back-end, it's going to be C# / .NET, whether it's a DLL or ASP.NET Core or a simple console app.
So what's you're take? Why would you use one vs. the other for back-end development?
Assuming your 7 year old back-end is written in .NET, if you had to rewrite it, would you switch from .NET to Node?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
