C# annoyed me today, so I took revenge.



  • Being forced to put static variables in class scope makes me a sad panda.


  • Discourse touched me in a no-no place

    I wonder if you can make a partial class in two different languages. Have most of your code be C#, and the method with the static variable be in C++.

    Off to the Evil Ideas thread!



  • As long as you use multiple projects, it may be doable. VS doesn't like mixed language projects.



  • so the first appearance of m_frame is evaluated before the assignment?

    Oh that's dangerous.

    Probably undefined behavior. Of course nothing in C# is undefined, because it's proprietary.



  • Assuming the commented-out code is what you replaced with the snippet immediately underneath it, I'm not seeing why o_Frame needs to be static. Why can't it just be an ordinary local variable inside TimerProc?



  • That awkward feeling when you start trying to politely explain to someone why they're an idiot only to suddenly realize that you're an idiot... 😓

    I shall leave this thread up as a memorial to my dumbassery.


  • BINNED

    @dookdook said:

    That awkward feeling when you start trying to politely explain to someone why they're an idiot only to suddenly realize that you're an idiot...

    You should get yourself one of these, they really do wonders for realizing such stuff before posting to a public forum:

    In case you didn't catch the reference:

    That said, it's not like I haven't done that before... 😄


  • Discourse touched me in a no-no place

    @abarker said:

    As long as you use multiple projects, it may be doable. VS doesn't like mixed language projects.

    I discovered that a while back. For no particular reason I tried to make an assembly out of both VB and C# classes. The only way I could find to do it involved using the command line to build separate netmodules and link 'em together.


  • Discourse touched me in a no-no place

    @abarker said:

    VS doesn't like mixed language projects.

    http://i.imgur.com/SwfNTmx.jpg



  • Was I unclear? Mixed language solutions are ok. Mixed language projects are not permitted.



  • @Onyx said:

    Rubber duck debugging

    I explain it to my other personality. Is that okay?


  • Discourse touched me in a no-no place

    @dookdook said:

    forced

    Hmmm..


  • ♿ (Parody)

    @abarker said:

    Was I unclear? Mixed language solutions are ok. Mixed language projects are not permitted.

    That's not really any clearer to anyone who doesn't use VS. THIS ISN'T A REQUEST TO EXPLAIN IT TO ME. But I probably won't yell at you if you can't resist the urge to expound on VS's implementation details.



  • @boomzilla said:

    THIS ISN'T A REQUEST TO EXPLAIN IT TO ME.

    Fine, be that way.

    @boomzilla said:

    But I probably won't yell at you if you can't resist the urge to expound on VS's implementation details.

    So I'm good to go? Well then, here it is:

    VS considers a project to be a single group of code files that can be compiled together. Each project can be configured to be compiled into a DLL or an EXE. In the case of web projects, you end up with one or more DLLs which are linked to your aspx pages. Each project can only use one coding language, with the possible pedantic exception of web projects. Web projects generally apply the "one language" exception on a per folder basis. Even then, it may be argued that two languages are used because of the mixture of the preferred coding language for the logic and aspx for the structure.

    A solution, on the other hand, is a collection of projects. Solutions make it easy to group related projects together for more complicated programs. Unlike projects, solutions may contain projects that utilize different programming languages.


  • Java Dev

    So it cannot build cross-language DLLs or EXEs but it can build a solution containing multiple EXEs and DLLs which are in a mix of languages.


  • Discourse touched me in a no-no place

    @abarker said:

    VS considers a project to be a single group of code files that can be compiled together.
    [...]
    A solution, on the other hand, is a collection of projects.
    [...]

    OK, I still feel a bit “WAT” but it's not aimed at you, but rather at the crazy way that VS works. The rest of the world doesn't organise itself that way, or use those words like that.



  • @dkf said:

    OK, I still feel a bit “WAT” but it's not aimed at you, but rather at the crazy way that VS works.

    Why?

    It seems perfectly sensible to me. What terminology would you prefer?


  • Discourse touched me in a no-no place

    @blakeyrat said:

    It seems perfectly sensible to me. What terminology would you prefer?

    I don't know. It just seems weird that there's this separation between languages, and that this in turn forces all sorts of complexity in the structure of how things are done.

    By contrast, I just have projects. They contain things in various languages (sometimes four or five in the same project) that get deployed in various ways to make the application work correctly when it is installed. (Unfortunately, the most complex projects are currently private. Oh well. They're doing things like pushing SQL at databases and JS at browsers and connecting the bits together across a cluster.) But that's using the word “project” differently to VS.

    I truly hate it when words are used to mean different things. It only promotes confusion as people say words and think they understand each other but don't really. Discovering and cleaning up such confusion is one the harder parts of my job…


  • Java Dev

    I feel you. Here it's the word 'metric': It means subtly
    different things depending on who is saying it.



  • @dkf said:

    I don't know. It just seems weird that there's this separation between languages,

    The separation is languages is entirely incidental to the question I asked.

    Oh and BTW, what abarker said about web projects-- the language separation only apply to files that are compiled (by VS). There's no particular rules about where to put your HTML/CSS/JS files, they can go literally anywhere in any project.

    I'm wagering the limitation that you can have only one .net language-per-project is more related to wiring-up the Intellisense than anything. As someone posted, the .net compiler supports it with some finagling.

    @dkf said:

    By contrast, I just have projects. They contain things in various languages (sometimes four or five in the same project) that get deployed in various ways to make the application work correctly when it is installed.

    So you have no organizational level higher than a project? That's what a "solution" is in Visual Studio.

    For an example, a web service and an application that makes use of it might be two completely different projects, but (using VS) they could go into the same solution. This is handy, because you can set up your references in the application to the web service and VS knows what to build when you hit Run.

    @dkf said:

    (Unfortunately, the most complex projects are currently private. Oh well. They're doing things like pushing SQL at databases and JS at browsers and connecting the bits together across a cluster.) But that's using the word “project” differently to VS.

    I'm not 100% sure they are. The difference is that Visual Studio has a higher level of hierarchy.

    @dkf said:

    I truly hate it when words are used to mean different things.

    I think you need to actually use Visual Studio for an hour, because you got some weird-ass ideas in your skull.

    EDIT: also if "the rest of the world doesn't do it this way", then they certainly should, because it works very well.

    @dkf said:

    Discovering and cleaning up such confusion is one the harder parts of my job…

    If you don't use the term "solution" at all, then why is it a problem that Visual Studio defines it differently? (Also: differently than what? You're not using it!)


  • Java Dev

    I think the word 'project' just means something different in every IDE.

    All we get are makefiles. The next higher level up is also a makefile. It's pretty horrible. Some non-code components go for shell scripts instead, which is just as horrible.



  • @PleegWat said:

    All we get are makefiles. The next higher level up is also a makefile. It's pretty horrible. Some non-code components go for shell scripts instead, which is just as horrible.

    That was my experience of Java projects when I had the misfortune of having to work with those. Bleargh.


  • Discourse touched me in a no-no place

    @PleegWat said:

    I think the word 'project' just means something different in every IDE.

    Yes. 😧 😕


  • Discourse touched me in a no-no place

    @blakeyrat said:

    That was my experience of Java projects when I had the misfortune of having to work with those. Bleargh.

    Make is entirely the wrong tool for Java. Ant is better, and Maven et al are much better still. (Provided you buy into the Maven way of doing things. Otherwise they're a lot of annoying things that just don't work well. I wouldn't be at all surprised if you hate Maven, though I'd be a bit more surprised if you hate it from having used it…)



  • @dkf said:

    Make is entirely the wrong tool for Java. Ant is better, and Maven et al are much better still.

    My point wasn't that it was a Make file using "make" specifically, the point was that *the only thing that associated files together was the folder tree and some NOT USING MAKE SPECIFICALLY BUT USING SOME OTHER TOOL THAT OPERATES SIMILARLY TO MAKE YOU FUCKING PEDANTIC DICKWEED build script in some random place in the folder tree.

    Have scientists developed a way to turn off the pedantic dickweed gene yet? Christ that shit's annoying.

    @dkf said:

    (Provided you buy into the Maven way of doing things. Otherwise they're a lot of annoying things that just don't work well. I wouldn't be at all surprised if you hate Maven, though I'd be a bit more surprised if you hate it from having used it…)

    The entire Java ecosystem is defined by "a lot of annoying things that just don't work well".

    For the record, I believe the project I worked on used Maven. I remember distinctly because it didn't fucking work whatsoever. I'd link you to the DailyWTF thread about it but OH HEY it's gone.

    Here's it's URL, according to Google: http://forums.thedailywtf.com/forums/p/25396/274194.aspx So there's that I guess. THANKS ALEX FOR DELETING MY POSTS I REALLY APPRECIATE IT!


  • Java Dev

    There's 2 main things particularly horrible about make:

    • Tabs have semantic meaning, which is not carried by any equivalent number of spaces
    • Your build instructions are all over your source tree. Particularly bad if a lot of your tree basically works the same.

  • FoxDev

    @PleegWat said:

    All we get are makefiles

    VS projects are basically makefiles on steroids. And saved as XML.



  • @blakeyrat said:

    NOT USING MAKE SPECIFICALLY BUT USING SOME OTHER TOOL THAT OPERATES SIMILARLY TO MAKE YOU FUCKING PEDANTIC DICKWEED
    Like, say, MSBuild? Or DevEnv /build?



  • @blakeyrat said:

    the only thing that associated files together was the folder tree

    Eclipse projects have references to other projects in the workspace. The workspace is just all the projects you have open. There is no equivalent to a VS solution. I don't feel like I'm missing out there. VS can only open one solution at a time, Eclipse can have whatever sets of dependencies you want to set up between your projects.

    I don't know about other Java IDEs.

    @blakeyrat said:

    I believe the project I worked on used Maven

    Maven can help manage the inter-project dependencies and update the Eclipse project file with those dependencies.

    Maven is a whole... thing. There are some things it really wants you to do, and you're going to have a hard time if you resist. A really hard time. You get the most value from the tool by simply accepting these things and moving on. It is highly opinionated software. I have created Maven-based projects in the past because it was the best tool at the time. It did just fine, we are still maintaining those projects with Maven. I probably wouldn't use Maven on a new project today though because that style of dependency management and project comprehension has been integrated in so many other tools that are easier to use.

    Sorry your posts are gone, I can't answer any specific questions when I can't read them.



  • @RaceProUK said:

    VS projects are basically makefiles on steroids. And saved as XML.

    With a nice gooey interface (possibly made in Visual Basic) for maintaining options.



  • @PleegWat said:

    Your build instructions are all over your source tree.

    They don't have to be.

    Everybody who uses make should have read Recursive Make Considered Harmful. You might be offended by it, but you should have read it.



  • @flabdablet said:

    Recursive Make Considered Harmful.

    If you haven't read Recursive Make Considered Harmful, you don't know how to make.

    Rules of Makefiles is also worth a read if you do want to understand make. (It's not particularly hard to use make, it just comes from the 70s and has weird 70s baggage on it...)



  • @another_sam said:

    VS can only open one solution at a time

    I'll try to remeber that tomorrow when I'm toggling between two different VS 2014 solutions. Sure, they're in different VS instances, but why would I need two solutions in the same instance?



  • @abarker said:

    why would I need two solutions in the same instance?

    You wouldn't need them, I guess. I have Eclipse open with all my shit right there all the time. When I go ask the .net guys here to do stuff they seem to never have the code open already and have to open VS. Not really a big deal.



  • @abarker said:

    why would I need two solutions in the same instance?

    All this talk of projects inside solutions inside instances reminds me of how things used to be in the days before Unix made filesystems with hierarchical directories popular. Members inside partitioned datasets inside volumes... good times. Or not.



  • @tar said:

    It's not particularly hard to use make, it just comes from the 70s and has weird 70s baggage on it

    I wonder how long it will be before all of XML (or anything descended from SGML, come to that) can be dismissed as weird 90s baggage. Looking forward to that.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    For the record, I believe the project I worked on used Maven.

    OK, couldn't remember what you'd worked on. 😄

    Maven's annoying as hell, but once one has coaxed one's build tree into the form it likes, it works really rather well. Migrating into it is deeply painful though, and sometimes finding out how to do sophisticated things can be tricky. About the only thing in its favour are that doing the same things with other tooling would be worse; it handles complex projects well including all the dependency management, testing and deployment. (Googling indicates that there's nothing really like it for the .NET world, and that people make do with a whole combination of things cobbled together. Which must really suck; instead of “how do I get Maven to do XYZ” it's “what tool can do XYZ and work with the other tools I'm using” which is a harder question by far.)

    It amuses me quite a bit that the standard tooling for Java environments is something that so many people dislike, but that everyone who tries to replace it finds that, no, that's really very difficult to do indeed.


  • Discourse touched me in a no-no place

    @flabdablet said:

    Looking forward to that.

    Yeah, but I think it'll be a long time. We still need those sorts of structured trees and the alternatives (json, yaml, probably other things too) still run into problems with things like namespacing (which matters a lot in complicated documents, unfortunately).


  • ♿ (Parody)

    @dkf said:

    Migrating into it is deeply painful though, and sometimes finding out how to do sophisticated things can be tricky.

    Yeah, we have an ant-based project and have looked into going maven and every time we just throw up our hands as not worth it.



  • @another_sam said:

    VS can only open one solution at a time,

    It's really hard to even have a discussion with someone THIS ignorant about a product. I mean, if I told you VS could open as many solutions as your computer had memory to support, what would you reply with next? "Yeah, well, VS is a purple chicken!"

    @another_sam said:

    Sorry your posts are gone, I can't answer any specific questions when I can't read them.

    The basic problem I had was it was not deterministic in the least. The build would produce a working site about a third of the time-- the rest of the time it'd "forget" to send the new .js files to the web server, or perhaps send the new .js files but "forget" the Java classes. It was an unreliable mess.



  • @another_sam said:

    When I go ask the .net guys here to do stuff they seem to never have the code open already and have to open VS.

    That's the reason you... ugh. Unbelievable.

    Obviously if your co-workers didn't have the "code open already", that means VS doesn't support opening more than one solution at a time. THAT MAKES SENSE.

    Hey did you know Windows doesn't support French? I looked at all my co-workers' computers and every single one was in English! YOU CAN'T ARGUE WITH LOGIC LIKE THAT!



  • @dkf said:

    it handles complex projects well including all the dependency management, testing and deployment.

    So does a VS project/solution file. ("solution" because the convention is to put all unit tests in their own project, I don't think that's strictly required though.)

    @dkf said:

    (Googling indicates that there's nothing really like it for the .NET world,

    Unless there's a huge part of functionality you didn't mention, the standard project file in the .net world does all that shit easily.

    @dkf said:

    and that people make do with a whole combination of things cobbled together. Which must really suck; instead of “how do I get Maven to do XYZ” it's “what tool can do XYZ and work with the other tools I'm using” which is a harder question by far.)

    I'd love to see an example of a "thing" VS can't do but Maven can.


  • ♿ (Parody)

    @blakeyrat said:

    I'd love to see an example of a "thing" VS can't do but Maven can.

    Does VS have a way of declaring external dependencies and downloading / managing them?


  • FoxDev

    @boomzilla said:

    Does VS have a way of declaring external dependencies and downloading / managing them?

    Via NuGet, yes ;)


  • ♿ (Parody)

    @RaceProUK said:

    Via NuGet, yes

    As in...

    @dkf said:

    a...combination of things cobbled together.

    Though there are obviously things VS does that maven doesn't, since maven isn't an IDE at all.


  • FoxDev

    If by 'cobbled together' you mean 'one extension', then yes 😛



  • @boomzilla said:

    Does VS have a way of declaring external dependencies and downloading / managing them?

    Yeah, Nuget became standard in 2010ish.

    (You can also just copy the .dlls into the project, which is a much better idea since it doesn't tie the functionality of your program to a server owned by someone else.)

    @boomzilla said:

    As in...

    Nuget isn't "a thing that's cobbled together", it's been a standard feature shipping with VS for years at this point.

    And, again, keeping the dependencies of your project on a server owned by someone else instead of just putting them in your project is a questionable idea to start with. At the risk of giving a Linux-user response: yes it has the feature, but you don't need/want it.


  • ♿ (Parody)

    @blakeyrat said:

    Nuget isn't "a thing that's cobbled together", it's been a standard feature shipping with VS for years at this point.

    Ah, OK. I thought it was a 3rd party thing.



  • It started out as one years and years ago.

    Shocking revelation: things change over time!!!


  • FoxDev

    @boomzilla said:

    Ah, OK. I thought it was a 3rd party thing.

    IIRC it was originally before M$ bought it and brought it internal.

    ....

    damn. :hanzo:'d by Blakey.


Log in to reply